AI Skills for Game Design - Social Design
This text is an eighth installment in a series of texts about application of AI in game design. If you are interested in the previous texts you can find them at the following links:
- AI Game Design Skill Bundle
- AI Game Dev Skill Bundle — Skills for Beginners
- AI Skills for Building Your Prototype
- AI Skills for Game Design — Concept Clarity
- AI Skills for Game Design — Creative Ideas
- AI Skills for Game Design — Player Motivation & Audience
- AI Skills for Game Design — Feature Adoption
- AI Skills for Game Design — Fairness, Failure and Memory
Somewhere in a design document near you, there is a line that says "add social features."
It is usually in a section about retention. Underneath it there are three bullets, and the bullets are chat, friends, and a leaderboard. Everybody nods. It goes on the roadmap. Six months later the game has chat, friends, and a leaderboard, and it is exactly as lonely as it was before, except now there is more UI.
I have watched this happen. I have also participated in it, which is the more honest way to put it.
The mistake is treating social design as a category of feature rather than as a design goal. Chat is not social design. Chat is a text box. What makes a game social is whether players end up with something to feel about each other — rivalry, gratitude, belonging, envy, obligation, recognition, or the specific pleasure of being seen doing something well. Those feelings do not arrive because you shipped a text box. They arrive when the systems give players a reason to matter to one another.
This installment is about that. It contains six skills:
- game-design-multiplayer-feature-audit
- game-design-social-satisfaction-matrix
- game-design-prosocial-session-chapters
- game-design-leaderboard-audit
- game-design-leaderboard-builder
- game-design-player-segment-perception-audit
You will notice two of them are about leaderboards specifically, and there is a reason for that beyond my own history with the subject. Leaderboards are the most commonly shipped social system in mobile games and the one most often built without any social intent at all. Somebody wanted a competitive feature, a list of names sorted by a number was the cheapest thing to build, and nobody asked what it was supposed to make anyone feel. So they get their own treatment here.
The other thing worth flagging up front: this pack overlaps with earlier installments more than any of the others, because social systems are where fairness, motivation, and audience all collide. I am going to cross-reference rather than repeat. If a section feels like it is about to explain something and then points at a link instead, that is deliberate.
The skills in this library are compatible with the Anthropic Claude system and OpenClaw framework. However, they are contained in a series of .md files which you can use to create templates for pretty much any modern AI LLM system. You can find individual skills at Clawhub or clone the repository from GitHub.
As usual, let's dive into what each of these skills is meant to be doing.
What Are You Actually Promising?
Skill: game-design-multiplayer-feature-audit
This is the big one in the pack, and it starts by making you say out loud what social fantasy you are selling.
That sounds trivial. It is not. Try writing it in one sentence for a feature you are currently building. Compete for rank against peers. Cooperate with a small squad on hard content. Contribute to a group goal while still pursuing your own. Show off your taste. Feel the presence of others without any hard coordination. These are genuinely different promises, they attract different people, and a surprising number of features are quietly promising two of them at once in ways that cancel out.
The tensions the skill watches for are the ones I have personally shipped into: calm self-expression versus destructive PvP. Casual mobile bursts versus rigid appointment play. Individual authorship versus committee-driven collaboration. Each of those pairs looks fine on a slide and produces a feature that satisfies neither half of its audience.
From there it audits six motivation buckets — competition, collaboration, collaborate-to-compete, belonging, vanity and status, and knowledge exchange — and it insists you judge which ones are actually doing work versus which are merely implied. That distinction matters. Most guild systems claim belonging. Rather fewer of them earn it.
Two parts of this skill I use constantly.
The first is the time model audit. Realtime synchronous, non-realtime synchronous window, asynchronous competitive, asynchronous collaborative, or hybrid. Then the questions: must players overlap in time, what happens when someone misses the window, and can this audience actually sustain that coordination burden? A socially wonderful idea can be completely wrong for your game purely on this axis. Appointment play is a big ask, and mobile audiences are the worst possible place to ask for it.
The second is the depth ladder, which runs seven rungs: awareness that others exist, comparison, indirect exchange, communication, coordination, collective strategy, and finally community identity. You state where your feature sits now, where it wants to sit, and whether the gap between those is credible.
And the skill is explicit that deeper is not better. Every rung up adds friction, moderation burden, onboarding cost, and design risk. This is the single most useful corrective I know for the "add social features" line in the design document, because that line almost always means jumping four rungs at once.
The failure shapes it names are worth memorising. Social wallpaper, where there are many social features and no social meaning. Coordination overkill. Status fog, where prestige exists but nobody can read it. Guild shell, where groups exist with no actual purpose. Comparison numbness, where ranks exist but movement means nothing emotionally. And solo fantasy violation, where the social layer actively damages the core fantasy instead of extending it.
There is also a whole section on adding social play to a mostly single-player game, which recommends a migration path rather than a leap: observe others, then compare with others, then exchange, then group, then collaborate to compete, and only then consider tightly synchronized modes if the audience has proven it wants them. If you take one thing from this section, take that ladder. Most social features fail because somebody started at step five.
Which Social Features Actually Matter
Skill: game-design-social-satisfaction-matrix
The previous skill asks what you are promising. This one asks which of your social elements deserve attention, and it does so with a distinction I find genuinely clarifying.
It sorts social features on two axes: how much satisfaction they can create, and how much dissatisfaction they can create. Those are not the same axis, and treating them as one is the root of a lot of bad prioritization.
Four categories fall out:
- Basic — low delight potential, high frustration potential when missing. Friend lists, stable party formation, baseline group management, access to reporting. Nobody has ever loved a friend list. Everybody notices a broken one.
- Critical — high on both. Voice chat, open text chat, matchmaking surfaces that determine teammate quality, public reputation. These are the make-or-break systems: enormous social value, enormous capacity for harm, and the outcome depends almost entirely on how carefully they are built.
- Booster — real upside, little downside if absent. Lightweight gifting, celebratory emotes, playful acknowledgements. Cheap warmth.
- Secondary — low on both. Matters to a niche, does not move the overall social experience.
The landscape questions in step 6 are where the value concentrates. Is the game overinvested in risky critical systems with weak guardrails? Is it missing basics? Is it adding boosters before the basics work? And the one that catches the most teams: is the social experience purely functional and dry, with no boosters at all?
That last pattern is extremely common in mid-core mobile. Everything works. Nothing is warm. There is a friend list and a guild and a donation button and not one single moment where a player does something small and nice for another player for no reason. Boosters are cheap and they are the difference between a functioning social system and one anybody likes being inside.
The skill also refuses to chase zero risk. Its stated sweet spot is significant satisfaction with manageable dissatisfaction, handled through guardrails rather than avoidance. Voice chat is dangerous. Removing it is not automatically the right answer.
Prosocial Behaviour As An Arc
Skill: game-design-prosocial-session-chapters
This one is narrower than the rest and it says so itself. It is for session-based multiplayer — matches, runs, missions, rounds — and it explicitly tells you to use it selectively or not at all if you are running a persistent world or a mostly asynchronous game. I appreciate a skill that knows its own limits.
Its premise is that prosociality should be designed as an arc rather than hoped for as an accident, and it splits that arc into three chapters.
Setup is everything before the pressure starts: matchmaking context, lobbies, loading screens, expectation setting, early trust cues. The job is to make helpful behaviour feel plausible and normal before anyone is stressed. The warning sign is pure mechanical onboarding with no social framing at all, where strangers are faceless and disposable and no expectations get set until after the first conflict.
Little Loops are the small repeatable prosocial actions inside the core loop. Revive, heal, ping, cover, share, rescue, assist, acknowledge. The job here is to turn helping into a habit rather than an aspiration. The warning signs are sharp and specific: teamwork that is theoretically required but mechanically unsupported, helping actions that are too rare or too costly or too invisible, and — the brutal one — a loop that creates blame faster than it creates trust.
Long Tail is what survives after the scoreboard disappears. Commendations, social memory, reconnection surfaces, ways to keep playing with the people who were good to you. The warning sign here is the one almost every multiplayer game is guilty of: players can report harm but cannot meaningfully acknowledge help. We build elaborate machinery for punishing the worst behaviour and almost nothing for remembering the best.
The diagnosis step asks whether the three chapters actually connect. Does Setup prepare players for the Little Loops? Do the Little Loops produce moments worth carrying into the Long Tail? Does the Long Tail feed back into future Setup by making good teammates easier to find again? The common failure is not an absent chapter. It is three chapters that exist and have nothing to do with each other.
The Board Nobody Checks
Skill: game-design-leaderboard-audit
Now we get to my old friend.
One of the first full features I ever designed on my own was a leaderboard system for SimCity BuildIt. I wrote up what I learned from it years ago in Building Better Leaderboards, and the short version is that a leaderboard is not a list. It is the start of a metagame, and its quality is measured by whether it generates real competition for the player sitting in the middle of the pack, not by whether it correctly sorts the top ten.
This skill turns that into a structured audit across seven dimensions. The two I would run first on any existing board:
Stagnation. How fast does the score move? Can it change meaningfully within a single session? Does it ever reset? Could a player starting today ever catch a veteran of equal skill? The verdict scale runs Healthy, Borderline, Stagnant, Dead — and Dead is specifically the lifetime-accumulated score with no reset, where veterans are permanently untouchable and everybody else is watching a monument. This is the most common leaderboard failure in the wild and it is fatal, because it makes every other design decision irrelevant.
Scale. How many players are on one visible board? Where does a median new player land? Is position 156,342 an emotionally meaningful number? Can the player see their immediate neighbourhood — the people just above and below them?
Get Stanislav Stankovic’s stories in your inbox
Join Medium for free to get updates from this writer.
The goal density section maps the structure against four goal tiers: overtake my neighbour, reach the next reward bracket, earn promotion, reach the top of the ladder. Plus the defensive one, avoiding demotion, which generates as much tension as any of the others. I have written about density of goals at length elsewhere and will not re-derive it here; what matters is that a good ladder structure produces all of these tiers automatically, from one system, without you designing them individually.
The named anti-patterns are the fastest way to use this skill. Stagnant board. Scale blindness. Goal poverty. Reward desert, where most players finish a round with nothing and the effort feels wasted. Reward flood, where everyone gets something and prestige collapses. Whale capture, where one dominant spender destroys the competitive dynamic for their entire group. Global vanity board. Empty summit. Chore motivation, where the rewards are the only reason anyone participates. And the sandbagging loop, where the reward structure makes deliberately losing the rational play.
On the motivational side, the audit checks the intrinsic and extrinsic balance and asks a question I like a lot: would a player who receives no rewards at all still find this leaderboard engaging? If the honest answer is no, the rewards are not amplifying your competition, they are substituting for it. I dug into how those motivational layers stack in a leaderboard specifically in Layers of Motivation, so I will point rather than repeat.
The Only Builder In The Library
Skill: game-design-leaderboard-builder
And here is the odd one out, not just in this pack but in the whole library.
Every other skill I have written audits something, extracts something, or generates options. This one produces a specification. You feed it inputs and it hands back a leaderboard design that a designer could take to an engineer.
It asks eight intake questions first, and each has a documented default so you can proceed when you do not know yet. What is the score and how fast does it move. How large is the active pool. How long is a round. What is the game context. What rewards can you offer. What is your player mix. What is your complexity budget — Simple, Standard, or Full. Random groups or matched.
The reason for the intake, and for treating Q1 as the most critical input, is the stagnation problem from the previous section. Get the score velocity wrong and no amount of clever ladder architecture will save the design. Everything downstream depends on it.
Then it builds ten components: group structure with sizing rationale, the league pyramid calculated from your pool, promotion and demotion thresholds, round structure and reset policy, reward brackets, group composition with anti-exploitation measures, a top-of-ladder strategy, a goal density verification table, an economy output summary, and a risk register.
A few of the opinions baked into it, since they are mine and you should know they are arguable:
Group sizes of fifty to a hundred. Smaller is more intimate and more volatile; larger is more stable and less personal. My experience says a hundred is a good default and I said so publicly years ago, so at least I am consistent.
Reward coverage around fifty percent of a group, with one percent taking the top prize and the bottom half getting nothing. That bottom half is not cruelty, it is the cut line, and the cut line is what makes the middle of the board tense.
Weekly rounds, because it is the most tested cadence in mobile and it balances urgency against feeling like a real campaign.
And three named strategies for the empty summit problem — expanding ladder, periodic full reset, or a prestige layer sitting outside the ladder — each with its tradeoff stated. The reset option comes with a warning I want to underline: it has to be designed in from day one and communicated as a season system, because introducing it later produces veteran backlash every single time.
The component I would not skip is the risk register, which comes pre-populated with the failure modes that actually happen: sandbagging, whale dominance, top-league stagnation over a six month horizon, reward inflation, reset backlash, and low participation in early rounds when there is nobody to compete against yet.
Being the only generative skill in the set, this one is also the best illustration of where I think this whole library is heading. The audits are useful because they ask better questions. This one is useful because it does arithmetic you would otherwise do badly on a whiteboard at four in the afternoon.
Who Is Watching You Compete
Skill: game-design-player-segment-perception-audit
The last skill in this pack has appeared before — I covered it in the Player Motivation installment, where it was about update communication and which cohort hears about a feature they cannot reach. I will not re-explain the mechanics of it.
I am including it again because social systems give it a second and rather different application, and it is the one I would actually reach for here.
Social features are the only features in your game where being seen is the entire point. Your rank is not private. Your guild contribution is a public number. Your trophy shelf, your city, your loadout, your season badge — these exist specifically to be looked at by other people. Which means the question shifts from "who will hear about this feature" to "who will see this player, and what will they conclude?"
Run that on a status system and interesting things fall out. A prestige badge that reads as aspirational to a midgame player might read as unreachable to a new one and as meaningless to the veteran who has had it for eight months. A guild contribution leaderboard makes your best player feel appreciated and your most casual member feel like a liability — same screen, same numbers, opposite emotional outcome. A visible spend-adjacent cosmetic tells one segment that success is purchasable, which is a message you may not have intended to send.
The middle cohort matters here for the same reason it always does, and it is worse in social systems, because the middle is where most of your actual social graph lives. Your top players have each other. Your new players have not formed attachments yet. Everyone else is the community, and they are the ones reading the status signals hardest.
Conclusion
The line I keep coming back to is that social design is not adding friends, guilds, and chat. It is shaping how players feel about each other.
Everything in this pack is a different route to the same question. The multiplayer audit asks what social fantasy you are selling and whether the coordination cost is one your audience will actually pay. The satisfaction matrix asks which of your social elements are foundations, which are dangerous, and which are cheap warmth you are neglecting. The session chapters ask whether helping behaviour is primed, rehearsed, and remembered, or just hoped for. The leaderboard skills ask whether your competition means anything to the player in the middle. And the segment audit asks who is looking at all of it and what they conclude about themselves.
Make no mistake, this is the pack where I am least confident that AI analysis is sufficient. Social systems produce emergent behaviour, and emergent behaviour is exactly the thing a language model reasoning about a design document cannot see. Your players will find the exploit you did not model. They will form a culture you did not design. They will use your gifting system for something you never imagined, and it might be lovely or it might be a harassment vector. No audit anticipates that. Community managers and moderation data will tell you things these skills cannot.
What the skills are good for is the part that comes before the emergence: not shipping the obviously lonely thing. Catching the guild that has no reason to exist, the leaderboard that is dead on arrival, the status signal nobody can read, the collaboration that costs more to organize than it returns.
And one last thought, which is the reason I care about this cluster.
Every other system in your game is between the player and you. The social layer is between the player and other people, and those people will still be there after they have exhausted your content. That is the whole reason social design punches above its weight in retention numbers. You are not competing for their attention against other games at that point. You are competing against them losing touch with somebody.
Key Takeaways
- Social design is a goal, not a feature category. Chat, friends, and a leaderboard is a shopping list. It is not a plan for how players will come to matter to each other.
- State the social promise in one sentence. If two incompatible promises come out — calm self-expression and destructive PvP, casual bursts and appointment play — that is your finding.
- The time model can sink a good idea on its own. Ask what happens when a player misses the window, and whether your audience can sustain that coordination burden at all.
- Deeper is not better on the social ladder. Every rung from awareness up to community identity adds friction, moderation load, and onboarding cost.
- Adding social to a solo game should be a migration, not a leap. Observe, compare, exchange, group, collaborate-to-compete — and only then consider synchronized modes.
- Satisfaction potential and dissatisfaction potential are different axes. Basics prevent frustration, critical systems do both at high volume, boosters are cheap warmth, and most dry mid-core games are missing the boosters entirely.
- Most multiplayer games can report harm but cannot acknowledge help. We have built elaborate machinery for punishing the worst behaviour and nearly nothing for remembering the best.
- A leaderboard that only matters to the top ten is a monument, not a feature. The measure is what the player in the middle of the pack has to play for.
- Score velocity is the input everything else depends on. A lifetime-accumulated score with no reset is a dead board regardless of how good the ladder structure is.
- Ask whether the leaderboard would work with no rewards at all. If not, the rewards are substituting for competition rather than amplifying it.
- In social systems, being seen is the point. The same status signal reads as aspirational, unreachable, or meaningless depending on which cohort is looking at it.
- This is the pack where AI analysis is least sufficient. Emergent community behaviour is invisible to a model reasoning about a design document. Your community managers know things these skills cannot.
Links
This series
- AI Game Design Skill Bundle
- AI Game Dev Skill Bundle — Skills for Beginners
- AI Skills for Building Your Prototype
- AI Skills for Game Design — Concept Clarity
- AI Skills for Game Design — Creative Ideas
- AI Skills for Game Design — Player Motivation & Audience
- AI Skills for Game Design — Feature Adoption
- AI Skills for Game Design — Fairness, Failure and Memory
Platforms & repository
My previous writing on these topics
