AI Skills for Game Design - Fairness, Failure and Memory
This text is a seventh installment in a series of texts about application of AI in game design, and we are now up to our chests in player psychology. I invite you to persevere. In order to do so I suggest you to read previous texts in this series. 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
Hard is fine. Bullshit is not.
That is the entire thesis of this installment and I am not sure I can improve on it, so let me just unpack why it matters.
Players will tolerate an astonishing amount of difficulty. They will replay the same boss forty times. They will lose a run they spent an hour on. They will grind a wall that a reasonable person would call unreasonable. Whole genres exist on the premise that the game will beat you repeatedly and you will thank it. Difficulty is not the problem and never was.
What players will not tolerate is not understanding what happened. Losing to something they could not see. Being punished by a rule nobody mentioned. Failing in a way that teaches nothing, so the next attempt is identical to the last one and equally doomed. Watching a random number decide an outcome they thought they had earned. That is where the anger comes from, and the technically correct thing to say in the post-mortem — the encounter is balanced, the drop rate is exactly what we specified — is true and completely beside the point.
The previous installment was about getting players to do the thing. This one is about what happens when the thing goes wrong, and about what remains in their head afterwards. Because those two are much more closely connected than they look. What a player remembers about your game is mostly assembled from a handful of emotional spikes, and failure is very good at producing spikes.
This batch contains eight skills:
- game-design-ftue-hero-journey-audit
- game-design-flow-audit
- game-design-failure-loop-audit
- game-design-attribution-audit
- game-design-perceived-randomness-audit
- game-design-fairness-frustration-audit
- game-design-peak-end-audit
- game-design-zeigarnik-effect-audit
They run roughly in the order a player experiences them. The first arc, the shape of the difficulty over time, what happens when you lose, who you blame, how you read luck, the overall fairness verdict, what you remember, and why you come back.
One structural note before we start, because it affects how you use these. The fairness audit in the middle is not a peer of the others. It is a roll-up that runs the attribution, randomness, and flow lenses together and issues a combined verdict. I built the three components separately because you often want just one of them, and then built the composite because the interesting failures are usually combinations. More on that when we get there.
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.
The First Arc
Skill: game-design-ftue-hero-journey-audit
We start at the beginning, with the part of the game that the largest number of people will ever see and the smallest number of people will ever finish.
This skill audits your FTUE through the Hero's Journey. Not as a literary exercise, but because the monomyth happens to encode something true about first sessions that a checklist of tutorial steps does not. The core proposition is that the purpose of FTUE is not to explain the controls. It is to make the player feel like the hero of their own story. Explaining the controls is a side effect.
It walks four stages. The framing, which asks whether you are treating this as the player's first meaningful arc or as a compliance exercise. The Call to Adventure, which asks whether the game establishes a fantasy worth entering before the explanation overload begins. Meeting the Mentor, which asks whether your guide creates emotional connection and gives useful gifts, or whether it is a talking head dispensing instructions. And Crossing the Threshold, which asks when the player first takes a meaningful self-directed action — and whether that action is actually meaningful or just the first yellow arrow they obeyed successfully.
I have written before about the player's journey as a way of structuring the whole game, and this is the same lens applied hard to the first five minutes.
The audit is unsentimental about the things we all keep shipping. Mandatory account creation before anyone has any reason to care. Large downloads gating the hook. Exposition delivered before the player has any context to hang it on. Long stretches of yellow-arrow obedience where the player is technically playing and actually just doing what they are told. The check it applies to Crossing the Threshold is the sharp one: is the first self-directed action genuinely self-directed, and does it satisfy autonomy as well as competence?
Most FTUEs are excellent at competence. You did the thing, well done, a number went up. Rather fewer of them let the player make a real choice in the first session at all.
The Shape of the Difficulty
Skill: game-design-flow-audit
Then the game proper starts, and the question becomes temporal.
This skill is built on Flow theory, and I want to be precise about what it does, because Flow is one of those concepts that gets stretched until it means "the game is fun." Here it means one specific thing: does challenge rise in step with player skill, over time, or does the relationship drift?
The three failure shapes are simple. Challenge above skill produces anxiety and confusion. Skill above challenge produces boredom and autopilot. And the third one, which I think is the most underrated of the three, is no visible skill growth at all — the player is neither overwhelmed nor bored, they simply cannot tell that they are getting better, and they drift away without ever complaining about anything.
What makes the audit useful rather than decorative is that it separates the skill axes. Mechanical execution, tactical judgment, strategic planning, system comprehension, attention management, social coordination. These are different skills and they grow at different rates. A design can be perfectly paced on mechanical execution and brutal on system comprehension, which is exactly what happens when a game teaches you to play beautifully and then drops an economy on you in hour six with no preparation whatsoever.
The output names specific breakpoints rather than general areas, which is a discipline I insisted on. "Difficulty spikes in the midgame" is not a finding. "The game asks for tactical judgment at the third boss but has only ever taught mechanical execution" is a finding, because you can act on it.
If you want the numerical side of pacing rather than the experiential one, I wrote about progression curves separately. The two go together. Curves tell you what the numbers do. This tells you what it feels like to live inside them.
What Happens After You Lose
Skill: game-design-failure-loop-audit
Here is a thing I believe fairly strongly: most teams tune difficulty far more carefully than they tune failure, and it is the wrong way round.
Difficulty is one number in a spreadsheet. The failure loop is a whole sequence — fail, receive feedback, pay the consequence, recover, prepare, retry or abandon — and every step in it is a place where a player decides whether there is going to be a next attempt. Nobody owns that sequence. It gets assembled out of a death animation, a results screen, an economy penalty, and a load time, each specified by a different person.
The skill reconstructs the whole loop and then audits three things against each other: what the player loses, what the player learns, and how fast they can make a better next attempt. The relationship between those three is everything. Harsh punishment is entirely survivable if clarity is high and re-entry is fast. Mild punishment is intolerable if the player has no idea what went wrong and it takes ninety seconds to get back in.
The archetypes it classifies against are the most immediately useful part, and I suspect you will recognize your own game in at least one:
- Learning loop — fast retry, high clarity, real adaptation between attempts. The good one.
- Grindback loop — too much rebuilding between real attempts. The player spends more time restoring their position than playing.
- Shame loop — public or ego-threatening failure with weak learning attached.
- Attrition loop — no single failure is bad, but the low-grade exhaustion accumulates until the player quietly stops.
- Helpless loop — repeated failure that generates no better hypothesis. The player is not learning, they are sampling.
- Mastery loop — genuinely harsh punishment justified by high clarity and real growth. Hard, and fair, and the reason certain games have the reputations they do.
The single diagnostic line I use most from this skill: if the player dreads the retry more than the challenge itself, the loop is broken. That sentence has ended arguments for me.
Whose Fault Was That?
Skill: game-design-attribution-audit
Now the psychological core of the pack, and my pick for the most underused framework in commercial game design.
Attribution theory asks how people explain what happened to them, along three axes. Locus: was the cause me or the world? Stability: is this a one-off or just how things are? Controllability: can I affect it next time?
The healthy combination for a failure is internal enough to preserve responsibility, controllable enough to support improvement, and unstable enough to preserve hope. I made a mistake, I can fix it, next time will be different.
The toxic combination is external, uncontrollable, and stable. And when those three line up, the player produces a specific sentence that anyone who has read a game's reviews will recognize instantly: the game screwed me, it always does this, and there is nothing I can do about it.
The thing worth sitting with is that a system can be completely fair in code and still generate that sentence reliably. Fairness is not a property of your math. It is a property of the story the player constructs afterwards from the evidence you gave them, and if you gave them no evidence, they will construct the story anyway, using suspicion.
The skill asks you to write the actual sentence the frustrated player would say, in their words, not a technical classification. This is a small instruction that does a lot of work. "Low perceived controllability" is easy to nod along to and forget. "The game hid the rule and then punished me for it" is harder to nod along to.
The compounding patterns are where the real damage lives. Low clarity plus high punishment. High randomness plus no mitigation. And the worst one — repeated failure plus stable external attribution, which is the mechanism by which a player's frustration hardens from a bad evening into a settled belief that your game is rigged. That belief does not soften. Once a player arrives there, they are reading every subsequent outcome as further evidence.
Reading the Dice
Skill: game-design-perceived-randomness-audit
Which brings us to luck, and to the fact that humans are catastrophically bad at it.
We see patterns in independent events. We believe in being due. We interpret streaks as intent. Show a player five bad drops in a row and a meaningful proportion of them will conclude, sincerely, that the game is watching what they need and withholding it. This is not stupidity, it is standard-issue pattern-seeking equipment doing what it evolved to do, applied to a domain where it is simply wrong.
The skill audits the psychology rather than the math. What story will players tell themselves about this randomness?
The most actionable distinction it draws is where the randomness sits relative to the player's decision. Randomness that happens before the decision is information — the board state, the hand you were dealt, the map you got. You can look at it and plan around it, and that planning is skill expression. Randomness that happens between the decision and the outcome is a verdict on something you already committed to. The skill treats the second kind as substantially more dangerous, because it undermines competence directly: the player did the right thing and got punished, and there is no lesson available.
It also looks at expectation mismatch, streak visibility, whether mitigation tools exist, and whether the mitigation you added creates exploit risk or just an implied promise you will have to keep forever.
Get Stanislav Stankovic’s stories in your inbox
Join Medium for free to get updates from this writer.
Worth reading alongside this: the psychology in play here is the same machinery that makes leaderboards either thrilling or demoralizing depending on how you scope them.
The Combined Verdict
Skill: game-design-fairness-frustration-audit
And here is the roll-up.
This skill runs attribution, randomness, and flow together and grades the result. I built it because in practice the frustrating systems are almost never failing on one axis. They are failing on a combination, and the combination is worse than the sum.
The core principle is a list of four conditions under which players accept difficulty, failure, and uncertainty: the cause is understandable, they had meaningful influence, the challenge matched a learnable demand, and luck was visible, bounded, or mitigable. Satisfy all four and you can be as brutal as you like. Miss one and you have a problem. Miss two and you have a community incident.
The compounding patterns it hunts for are the ones that turn healthy tension into a player who is finished with your game. High challenge plus low clarity. High punishment plus low controllability. Hidden RNG plus severe loss. Repeated failure plus stable external attribution. Long retry cycles plus low learning value.
Read that list again and notice that every item is a pair. Each half of each pair is a design decision that someone made for a good reason, in isolation, and that would have been fine on its own.
Use the individual skills when you know which lens you need. Use this one when a system is producing anger and you cannot work out where it is coming from — which, in my experience, is the more common situation, because if you already knew you would have fixed it.
What They Actually Remember
Skill: game-design-peak-end-audit
Now we shift from what happens to what remains.
The peak-end rule says people do not remember an experience as an average of every second they lived through. They remember the emotional peaks and they remember the ending, and those two disproportionately determine the whole memory.
For game design this is close to a superpower and it is used far less than it should be. A design with perfectly decent average quality gets remembered badly because its peaks are weak and its ending is limp. A rougher, messier design gets remembered fondly because it had one genuinely great moment and closed well. The average is not what you are shipping. The memory is what you are shipping.
The failure patterns are painfully familiar once named. A strong negative spike drowning several weak positives. A flat experience with no memorable high at all — nothing wrong with it, nothing to say about it either. A rewarding middle attached to a deflating ending. A reward ceremony too small for the effort that earned it. And my personal favourite, because I have shipped it: admin and UI sludge contaminating the exit, so that the last thing the player touches before leaving is a confirmation dialog.
The step that produces the most value is writing the remembered sentence. Not an emotional profile — the actual line the player would say to a friend a week later. "That run had one incredible clutch ending." "The fight was fine but the reward was pathetic." "That event was mostly chores and then it just sort of stopped." If the sentence you land on is bad, no amount of solid average quality is going to rescue it, and you now know exactly which moment to fix.
There is a segment dimension too, which is easy to miss. New players often experience their worst peak at precisely the point where veterans experience their best one. Same content, opposite memory.
If you want to go deeper on shaping emotional texture deliberately rather than diagnostically, that is what the emotional canvas work is for, and I covered the skill version of it back in the Concept Clarity installment.
Unfinished Business
Skill: game-design-zeigarnik-effect-audit
The last skill in the pack deals with what the player carries out of the session.
The Zeigarnik effect is the observation that unfinished tasks stay mentally active in a way that completed ones do not. Bluma Zeigarnik's original observation involved waiters remembering unpaid orders and promptly forgetting them once settled. In games this is enormously powerful: the half-finished collection, the quest at nine out of ten, the run you had to abandon, the mystery nobody has explained yet.
Now, I am aware of where this looks like it is going, and it is not going there. I have already said my piece about obligation loops and I am not going to repeat it. This section is about something more interesting, which is that open loops are not automatically manipulative, and the difference between the good kind and the bad kind is structural rather than moral.
The skill classifies the type of tension being created. Curiosity tension. Completion tension. Competence tension. Reward anticipation. Social obligation. Scarcity. Maintenance guilt. These are genuinely different things that all show up on a home screen as a red dot, which is precisely the problem.
Healthy open loops are legible, meaningful, self-directed, and finite enough that the player can imagine closing them. You can see what it is, you know how to resume it, you chose it, and you can picture being done. Unhealthy ones are noisy, ambiguous, low-value, too numerous, and attached to maintenance burden.
The diagnostic question at the centre is very clean: does the player return because they want closure, or because they want to stop feeling bad? Both produce a session. Only one of them produces a player who is glad to be there.
The clarity audit is the practical half and it is where most live games fail. One clean open loop is a hook. Fourteen competing open loops with no priority order is not fourteen hooks, it is a pile, and a pile does not create tension. It creates avoidance. The player cannot resolve it, cannot rank it, and eventually stops opening the thing that shows it to them.
Conclusion
The eight skills in this pack all circle the same uncomfortable fact: your game is not what you built. Your game is what players believe happened to them.
You can ship a mechanically flawless encounter that reads as rigged. You can ship an honest drop table that feels like sabotage. You can ship a genuinely fair difficulty spike that lands as an insult because nothing prepared the player for it. In every one of those cases the design document is correct and the experience is broken, and no amount of insisting on the correctness of the design document will change what the player took away.
That is the shared logic here. Attribution asks what story the player tells about a loss. Perceived randomness asks what story they tell about luck. The failure loop asks whether that story leaves room for another attempt. Peak-end asks which fragments of the story survive the week. And Zeigarnik asks which loose thread pulls them back into it.
Make no mistake, none of this is an argument for making games easier. I want to be very clear about that, because the fairness vocabulary gets misused in exactly that direction. Everything in this pack is compatible with brutal difficulty. Several of these skills will explicitly tell you that harsh punishment is fine when clarity and re-entry speed are strong enough to carry it. The mastery loop is in there as a legitimate, healthy archetype. The bar is not kindness. The bar is legibility.
There is one more reason I care about this cluster more than the others, and it is the memory point.
Everything else we have covered across this series operates while the player is present. Motivation, adoption, friction, prompts — all of it is about the session in progress. Memory is the only one that keeps working after they close the app. It determines what they tell their friends, what they think when they see your icon, and whether the version of your game living in their head is the one you actually made.
Nobody remembers the average. They remember the worst thing that happened, the best thing that happened, and how it ended.
Key Takeaways
- Hard is fine. Bullshit is not. Difficulty is almost never the real complaint. Illegibility is.
- A system can be mechanically fair and still read as rigged. Fairness lives in the story the player assembles afterwards, not in your math.
- FTUE is a first arc, not a control tutorial. Most onboarding satisfies competence and never once lets the player make a real choice.
- Watch the skill axes separately. Mechanical execution, system comprehension, and tactical judgment grow at different rates, and designs routinely pace one well and abandon the rest.
- The invisible flow failure is no visible skill growth. Players who are neither bored nor overwhelmed but cannot tell they are improving leave quietly and never file a complaint.
- Tune the failure loop, not just the difficulty. Loss, learning, and re-entry speed have to be balanced against each other; harsh punishment survives if clarity and retry speed are high.
- If the player dreads the retry more than the challenge, the loop is broken. Retry friction does more damage than raw difficulty.
- The toxic attribution combination is external, uncontrollable, and stable. Once frustration hardens into that shape, every later outcome is read as more evidence.
- Randomness before the decision is information. Randomness after it is a verdict. The second kind damages the feeling of competence directly.
- Frustration failures are almost always pairs. Each half was a reasonable decision made in isolation by someone solving a different problem.
- You ship the memory, not the average. Weak peaks and a limp ending will sink an experience that was perfectly fine throughout.
- One open loop is a hook. Fourteen is a pile. Piles produce avoidance, not return tension.
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
Platforms & repository
My previous writing on these topics
- Game Mechanics — Game Progress
- The Power of Curves
- Building Better Leaderboards
- Building Blocks of Fun: Emotions
- Layers of Motivation
- Density of Goals
Frameworks referenced
