$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-multiplayer-feature-auditAudit a game, feature, live-ops layer, social system, or multiplayer concept for the quality and fit of its social design. Use when evaluating collaboration, competition, collaborate-to-compete structures, matchmaking, guilds/clubs, synchronous versus asynchronous play, realtime
| 1 | # Game Design Multiplayer Feature Audit |
| 2 | |
| 3 | Audit a design by asking what kind of social experience it is actually creating, for whom, at what coordination cost, and with what likely community effect. |
| 4 | |
| 5 | Use this skill when a design has multiplayer or social ambitions and you need to judge whether those ambitions are coherent, motivating, scalable, and well matched to the core fantasy of the game. |
| 6 | |
| 7 | ## Core principle |
| 8 | |
| 9 | Social design is not a checklist of features. |
| 10 | |
| 11 | A leaderboard, guild, chat channel, or PvP mode does not automatically create meaningful social play. Strong multiplayer design aligns player motivation, time structure, coordination demands, visibility, and community purpose. |
| 12 | |
| 13 | ## What to produce |
| 14 | |
| 15 | Generate: |
| 16 | 1. **Audit target** - what is being reviewed and what kind of social experience it appears to aim for |
| 17 | 2. **Social promise** - the core social fantasy or player promise |
| 18 | 3. **Motivation map** - competition, collaboration, collaborate-to-compete, belonging, vanity/status, knowledge exchange |
| 19 | 4. **Time and synchronization audit** - realtime, non-realtime, synchronous, asynchronous, or hybrid |
| 20 | 5. **Social depth audit** - how deep the interaction really goes |
| 21 | 6. **Community and status audit** - whether the system supports durable groups, identity, and readable prestige |
| 22 | 7. **Risks / failure modes** - where the design is likely to break, flatten, or create friction |
| 23 | 8. **Recommendations** - what to strengthen, stage, simplify, avoid, or postpone |
| 24 | |
| 25 | ## Process |
| 26 | |
| 27 | ### 1. Define the social promise |
| 28 | |
| 29 | State in one or two sentences what the feature is socially promising. |
| 30 | |
| 31 | Examples: |
| 32 | - compete for rank and status against peers |
| 33 | - cooperate with a small squad to solve hard encounters |
| 34 | - contribute to a group goal while still pursuing personal goals |
| 35 | - show off taste, city design, wealth, or mastery |
| 36 | - let solo players feel the presence of others without hard coordination |
| 37 | |
| 38 | If the design appears to promise incompatible things at once, say so early. |
| 39 | |
| 40 | Common tension examples: |
| 41 | - calm self-expression versus destructive PvP |
| 42 | - casual mobile bursts versus rigid appointment play |
| 43 | - individual authorship versus committee-driven collaboration |
| 44 | |
| 45 | ### 2. Map the motivation structure |
| 46 | |
| 47 | Audit the feature across these motivation buckets: |
| 48 | |
| 49 | - **Competition** - rivalry, ranking, domination, comparison |
| 50 | - **Collaboration** - helping, supporting, coordinating, solving together |
| 51 | - **Collaborate-to-compete** - teamwork in service of beating another team, club, faction, or cohort |
| 52 | - **Belonging** - identity, membership, shared rituals, durable group attachment |
| 53 | - **Vanity / status** - visible prestige, taste display, wealth display, proof of mastery |
| 54 | - **Knowledge exchange** - teaching, strategy sharing, build discussion, optimization culture |
| 55 | |
| 56 | Do not just list them. Judge which ones are truly doing work and which are merely implied. |
| 57 | |
| 58 | ### 3. Check motivational fit |
| 59 | |
| 60 | Use a Self-Determination-Theory-inspired check: |
| 61 | |
| 62 | - **Autonomy** - does the player have choice of role, pace, route, or strategy? |
| 63 | - **Competence** - can the player demonstrate mastery, improvement, contribution, or skill? |
| 64 | - **Relatedness** - can the player meaningfully connect, compare, help, coordinate, or belong? |
| 65 | |
| 66 | Flag fake-social systems that mostly create obligation, admin work, or shallow compliance. |
| 67 | |
| 68 | Examples: |
| 69 | - a guild donation button may create duty without meaningful relatedness |
| 70 | - a giant anonymous global leaderboard may technically create comparison but fail emotionally |
| 71 | - a cosmetic showcase may create status only if others can actually see and decode it |
| 72 | |
| 73 | ### 4. Audit time model and synchronization demands |
| 74 | |
| 75 | Classify the feature explicitly: |
| 76 | |
| 77 | - **Realtime synchronous** |
| 78 | - **Non-realtime synchronous window** |
| 79 | - **Asynchronous competitive** |
| 80 | - **Asynchronous collaborative** |
| 81 | - **Hybrid** |
| 82 | |
| 83 | Then ask: |
| 84 | - how long does a typical social interaction last? |
| 85 | - must players overlap in time? |
| 86 | - what happens if one player misses the window? |
| 87 | - does the audience/platform support this coordination burden? |
| 88 | - is the feature mobile-friendly, session-friendly, or appointment-heavy? |
| 89 | |
| 90 | Call out time-model mismatch clearly. A socially appealing idea can still be wrong for the audience if it demands too much synchronization. |
| 91 | |
| 92 | ### 5. Audit depth of social interaction |
| 93 | |
| 94 | Rate the design using this depth ladder: |
| 95 | |
| 96 | 1. **Awareness** - others exist |
| 97 | 2. **Comparison** - scores, rankings, visible collections, ghosts, showcases |
| 98 | 3. **Indirect exchange** - gifting, trading, donations, borrowing |
| 99 | 4. **Communication** - chat, pings, negotiation, requests |
| 100 | 5. **Coord |