<![CDATA[Stories by Stanislav Stankovic on Medium]]> https://medium.com/@stanislav-stankovic?source=rss-5c3f0bb4eddc------2 https://cdn-images-1.medium.com/fit/c/150/150/1*7_0-YHB1TTUcSkUPbXsU9A.jpeg Stories by Stanislav Stankovic on Medium https://medium.com/@stanislav-stankovic?source=rss-5c3f0bb4eddc------2 Medium Thu, 05 Nov 2026 05:35:21 GMT <![CDATA[Monopolies in Games Industry]]> https://stanislav-stankovic.medium.com/monopolies-in-games-industry-e77c47ad2e1b?source=rss-5c3f0bb4eddc------2 https://medium.com/p/e77c47ad2e1b Mon, 28 Sep 2026 06:01:01 GMT 2026-09-28T09:37:00.952Z

I am a game designer, and all I want is to make games. I also want people to play them. That is the whole point, and it sounds almost too obvious to write down. However, there is one crucial step hiding between "we made a game" and "people are playing it" and its a landmine. The success of every single game depends on it and us game makers have very little control over it.

This notorious step is publishing, and the reason why we have so little control over it is because we are working inside someone else's storefront, under someone else's revenue distribution rules, following someone else's review process.

The global games industry consists of several partially overlapping domains. PC, console and mobile are, by far, the three biggests. Some games cross all three. Most studios, especially smaller ones, pick one, maybe two, and live there.

Each of these domains is dominated by a relatively small number of companies that get to set the rules. In effect they decide which games launch, when, and how visible they get once they do. That is simply the operating environment inside of which we need to operate.

People throw around the word monopoly a lot when they talk about Steam, or Apple, or Tencent. Other people roll their eyes and tell you it's a free market, that anyone can publish anywhere, that competition sorts it all out. I am a game designer, not an economist, and I used to assume both of these were just opinions you pick based on temperament. They are not. They actually have clear definitions with solid data, and a research framework behind them.

Enter CR4

No, not Cristiano Ronaldo. That is CR7. The letters CR stand for *concentration ratio*, and the number behind them represents the number of companies that define it. It is one of the oldest, simplest tools in industrial organization economics.

You calculate it by taking the market shares of the four largest companies in an industry and add them together. That's it. If the top four smartphone makers hold 30, 25, 15 and 10 percent, your CR4 is 80 percent.

The method traces back to American economist Joe Bain, who used concentration data alongside profit rates across dozens of American manufacturing industries in the 1930s and 40s, published as "Relation of Profit Rate to Industry Concentration: American Manufacturing, 1936–1940" in the Quarterly Journal of Economics in 1951\.

He found that firms in concentrated industries earned persistently higher profits than firms in fragmented ones. Industries where a handful of firms controlled most of the output behaved differently, and made more money doing it, than industries where output was spread across many competitors.

That single observation became the seed of what economists now call the structure-conduct-performance paradigm, and it gave American antitrust regulators a number they could actually use. The Department of Justice started leaning on CR4 as a primary concentration metric in the 1960s, back when the US government still cared about the health of their free market economy.

Once you have your CR4 number, there's a rough, widely used classification for what kind of market you're looking at:

CR4 Market structure:

  • Under 40% — Fragmented / competitive
  • 40–70% — Loose oligopoly
  • 70–90% — Tight oligopoly
  • 90–100% — Near monopoly to outright monopoly

Simple table, simple math, and yet almost nobody in games discourse seems to be aware of it before declaring a platform a monopoly or dismissing the idea entirely. So, for your benefit, I tried to aggregate the data. Here's what the numbers say, segment by segment.

I’ll also mention another measure, CR2. It is CR4’s older meaner brother. The number 2 indicates two companies. SImply put CR2 measures how much do two largest companies dominate their market. In other words it says how close each market is to a duopoly. In the same way CR1 indicates the level of monopolization of a market by a single company.

Gaming Industry and CR4

A few honest caveats first. Public financial disclosures are patchy, several of these companies bundle gaming revenue with unrelated business lines, and analyst estimates disagree with each other by several points depending on methodology. The right response to that is holding the numbers loosely and citing where each one comes from. I also split this analysis in two parts for each of three main domains into two slices, analysis of storefronts and publishers.

Mobile storefronts

I am starting with mobile platform as I spent most of my career working on mobile games. This domain is obviously dominated by two mayor players. Outside of China, Apple and Google control more than 95 percent of the app store market between the App Store and Google Play. There effectively is no third or fourth player at global scale, which means CR4 here rounds to the same number as CR2, and CR2 sits above 95. That's about as close to a pure duopoly as a global digital market gets.

Mobile publishers

This is the one that surprised me most. Tencent led mobile publishers by revenue in 2025 at $8.75 billion, followed by Scopely at $2.96 billion and Century Games at $2.73 billion, against a global mobile games market that reached $108 billion in 2025\. Add a fourth publisher in the same range and you land a CR4 somewhere around 13 to 15 percent. Mobile storefronts are a near-duopoly. Mobile publishing, the actual business of making and releasing the games, is closer to fragmented than to oligopoly. Two very different market structures sitting on top of each other in the same industry segment. This fact is probably what muddies the discussion the most. The market is essentially a duopoly.

PC storefronts

Steam controls roughly 75% of the PC gaming digital distribution market, with Epic Games Store holding 8 to 10%, Microsoft Store and Game Pass combined at 6 to 8%, and GOG at 2 to 3%. Add those four together and you get a CR4 somewhere in the low-to-mid 90s. Tight oligopoly bordering on near monopoly, and one company, Valve, accounts for most of that share by itself.

PC publishers

Here the data gets thin enough that I won't hand you a fabricated number. What the evidence does show is a long tail: Steam alone added over 18,000 new titles in a single year, and most of that catalog comes from small and mid-size studios rather than a handful of majors. Publisher concentration on PC looks structurally closer to mobile than to the storefront layer above it, fragmented at the top even while distribution sits in one company's hands. This situation parallels the one on mobile, tight concentration of storefronts and much freer publishing layer.

Console platforms

This is the cleanest case in the whole industry, because there are only three companies to measure. Sony holds an estimated 45% of the console market, Microsoft's Xbox 27%, and Nintendo Switch approximately 24%. Three firms, effectively 100% of the market between them. CR3 and CR4 are identical here because there is no fourth firm to add. This is what a strict, closed oligopoly looks like when you can actually see all its members in one glance, and it exists because the barrier to entry is a physical console plus a certification process that only three companies on Earth currently clear.

Console publishers

Sony's own platform revenue dwarfs any individual third-party publisher on its own hardware, and the same dynamic repeats on Xbox and Switch, where the platform holder is also the biggest first-party publisher. Layer Microsoft's acquisition of Activision Blizzard on top of that and the third-party console publishing landscape, EA, Take-Two, Ubisoft, and the rest, has to compete for shelf space against companies that also own the shelf. I won't put a single clean percentage on this row, the segment reporting is too inconsistent across companies to defend one, but directionally this sits closer to tight oligopoly than to anything fragmented.

Industry overall

If we zoom out now and take a look at the industry as a whole, we can see that Sony, Tencent and Microsoft together account for roughly 44% of the entire global games market, which is already a CR3 that would raise eyebrows in most manufacturing sectors Bain ever studied. Extend that to the top ten publicly traded gaming companies and estimates put the combined share around 60 percent of global revenue. For an industry people still describe as a wide-open creative frontier, the money says loose-to-tight oligopoly at the top, sitting on top of a genuinely long tail of small studios who see almost none of that revenue.

Put it all together and the shape of the industry is not one market, it is several markets stacked on top of each other with wildly different concentration levels. Distribution is a near-monopoly on mobile and a tight oligopoly on PC. Hardware is a closed three-firm club on console. Publishing itself, the part we actually do for a living, is the most fragmented layer in the whole stack, on mobile and PC at least. We are the competitive part of an otherwise concentrated industry, standing on gatekeeper infrastructure that is anything but.

Nobody has to pick up the phone

People arguing about monopoly or collusion in games discourse tend to assume both words require a room full of executives agreeing on numbers. Because that room obviously doesn't exist, they conclude the market must be healthy. Economics has disagreed with that assumption for over sixty years.

Coordination among firms that occurs without an explicit agreement has a name in economics: tacit collusion. Standard theory predicts that cartels and tacit collusion are more likely in oligopolistic markets, where a relatively small number of producers recognize direct, mutual interdependence in their pricing and output choices. George Stigler formalized this in his 1964 paper "A Theory of Oligopoly," arguing that in a market with few enough players, each firm can simply watch what the others do and adjust, no phone call required, because the number of players is small enough that everyone's moves are visible to everyone else. American courts got there even earlier: in Interstate Circuit v. United States (1939), the Supreme Court found that parallel conduct plus knowledge that competitors were likely to follow suit was enough to establish an unlawful agreement, without a shred of direct evidence that anyone talked to anyone.

Apply that lens to a three-firm console market or a two-firm app store duopoly and the absence of a smoking gun stops meaning very much. When Apple sets its commission rate and Google's ends up in the same neighborhood, when one storefront's revenue split becomes the reference point every developer negotiates against, oligopoly theory treats that as the predictable equilibrium of a small, visible market, where ignoring what the others charge carries real cost and undercutting them into a price war carries more.

A confession

I have spent fourteen years on the inside of this stack, most of it on the mobile side, working on SimCity BuildIt, one of Apple and Google's storefront-dependent titles like every other mobile game in existence. I take a cut from every player's purchase, and Apple and Google take a cut of mine. Every design meeting I can remember spent its energy on drop rates, onboarding funnels, and retention curves. The 30 percent platform fee sitting underneath all of that math simply never came up as a design problem, and I suspect that's true for most of the people reading this too. We are all fluent in the mechanics of our own games and mostly illiterate in the market structure that decides whether anyone gets to play them.

Key Takeaways

  • CR4 sums the market share of the four largest firms in an industry, a tool that goes back to Joe Bain's 1951 work correlating industry concentration with profit rates, and it became a standard antitrust metric for the US Department of Justice in the 1960s.
  • Mobile storefronts are effectively a two-firm market. PC storefronts are a tight oligopoly dominated by one company. Console platforms stay a closed three-firm club because hardware certification is the barrier that keeps it that way.
  • Publishing itself, on mobile and PC, is far more fragmented than the distribution layer sitting above it. We work in the competitive part of a concentrated industry.
  • Tacit collusion doesn't require a meeting. In a market with few enough visible players, parallel pricing behavior is a predictable equilibrium, not necessarily evidence of a conspiracy, a point going back to Stigler's 1964 oligopoly theory and to US antitrust case law from 1939 onward.
  • The point of the exercise is measurement, not moral verdict. Concentrated markets show up in plenty of sectors outside games, and measuring beats arguing from priors.

Links and references

]]> <![CDATA[AI Skills for Game Design - Production Decisions]]> https://medium.com/babel/ai-skills-for-game-design-production-decisions-9ec9511c247a?source=rss-5c3f0bb4eddc------2 https://medium.com/p/9ec9511c247a Mon, 21 Sep 2026 14:01:05 GMT 2026-10-07T17:22:40.086Z

This text is a ninth 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:

Every other text in this series has been about making something better. This one is about deciding whether to make it at all, and about what to remove from it if you do.

There is a moment in every project that I have come to think of as the point of no return, and it is not the moment production starts. It is a couple of weeks earlier, when everyone in the room quietly stops asking whether the thing is a good idea and starts asking how to build it. Nobody announces the transition. There is no meeting where it happens. But after that point the questions change, the tone changes, and challenging the concept starts to feel like obstruction rather than diligence.

The skills in this batch are for the window just before that door closes, and they are deliberately uncomfortable:

  • design-red-team-audit
  • game-design-one-thing-to-remove
  • game-design-unknown-unknowns-prototyping
  • game-design-feature-prioritization
  • game-design-kpi-coverage-audit
  • game-dev-team-gap

I should be upfront that four of these six have appeared in earlier installments, in different company. That is intentional and I am not going to re-explain them here. Grouped this way they do a different job. Individually they are analysis tools. Together they are a checklist you run when something is about to become expensive.

One more note before we start. This is the last text in the series. Nine installments, roughly sixty skills, and I have deliberately ended on the least glamorous one, because production decisions are where good design most often dies and where the least is written.

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.

Assume It Failed

Skill: design-red-team-audit

This is the spine of the pack and the skill I would run first.

It is a pre-mortem. You do not ask whether the idea might fail. You assume it already did, and then work backwards to find the most credible explanations. That inversion matters more than it sounds like it should. Asking a room whether a feature could fail produces polite hedging. Telling a room that it failed and asking why produces a list, and the list is usually accurate, and someone in the room has been sitting on half of it for weeks.

The skill's working stance is the part I care most about, and it is the reason the file exists in the form it does. It is instructed to be hard on the idea but not sloppy, and specifically to reject vague negativity. Every criticism has to name a mechanism.

The file spells this out with examples. Not acceptable: players may not like this, this seems risky, this could be confusing. Acceptable: the feature adds a second optimization layer but never gives the player enough feedback to know whether their decisions are good, so it produces opacity rather than mastery.

The difference is that the second one is actionable and the first one is just a mood. Anyone can be negative about a design. Being usefully negative is a skill, and it is rarer in review meetings than you would hope.

It runs eleven lenses. Goal failure, player value, UX and comprehension, systemic design, content and scalability, production, prototype and validation, MVP, KPI and measurement, rollout, and strategic. A few of those deserve calling out.

MVP failure asks what essential element is likely to get cut, and whether the stripped-down version removes the exact thing that would have made the concept work. This is the mechanism behind an enormous number of features that tested badly and were killed for the wrong reason. You cut the connective tissue to fit the sprint, tested the remains, and got a false negative on a good idea.

Rollout failure asks what happens when this meets real players, and whether the plan depends on perfect tuning, perfect communication, and perfect segmentation. Then the sharp version: is the team prepared only for success? Most launch plans are.

Strategic failure asks the question that nobody wants to be the person who asks. Even if this works exactly as designed, is it worth doing? Is it a distraction from something more valuable? A feature can be well designed, well built, well received, and still have been the wrong use of a quarter.

The output ends with a verdict on a five-point scale from worth exploring down to not worth pursuing in current form, then the failure modes with early warning signs attached, then the weak assumptions, then what would have to be true for it to work, then the fastest ways to test the biggest uncertainties.

Those early warning signs are the part I would actually take into production with me. A predicted failure mode you can recognise three weeks in is worth considerably more than one you can only confirm at launch.

Cut One Thing

Skill: game-design-one-thing-to-remove

I covered this skill in the Creative Ideas installment as a creative tool, and I want to make a different argument for it here.

In an ideation context, subtraction is a way to sharpen an idea. In a production context, subtraction is how you survive. Every project reaches a point where the honest options are cut scope, extend the schedule, or ship something worse, and the third option gets chosen by default whenever the first two feel politically expensive.

What the skill does is force the cut to be argued rather than negotiated. It identifies the single highest-leverage removal — the element whose absence would most improve the design — and then it has to justify why that cut beats all the others.

Two parts of the output matter especially when the pressure is on.

It states what you lose. A good cut still removes something useful, and the skill is explicit about that. This is what separates a designed cut from panic descoping. If nobody can say what was lost, the decision was not really made.

And it offers a value-preserving alternative — a lighter substitute that keeps the upside without the problematic whole. This is the move that gets cuts approved in practice, because it turns "we are removing your feature" into "we are keeping the part that mattered."

Then the verdict: remove now, prototype without it, or keep for now and cut if testing confirms.

The reason I put a creative skill in a production pack is that late-project cuts almost always get made by whoever is most tired, on the basis of what is easiest to remove rather than what is least valuable. Those are very different criteria and they produce very different games.

What Are You Actually Uncertain About?

Skill: game-design-unknown-unknowns-prototyping

The premise here is one line and it is the most useful sentence in the file: preproduction handles known unknowns, prototyping explores unknown unknowns.

Known unknowns are the questions the team already knows to ask. They are on a list somewhere. They will get answered in the normal course of work. Unknown unknowns are the hidden design problems, emergent opportunities, and unexpected interactions that only become visible when someone actually plays the thing — and they are the reason prototyping exists at all.

Which leads directly to the instruction: do not prototype to mimic production. Prototype to expose uncertainty.

The skill maps a concept across four quadrants — known knowns, known unknowns, unknown knowns, and unknown unknown *suspects*. That last phrasing is deliberate and I want to defend it, because it looks like a fudge and is not. You cannot list a true unknown unknown. If you could name it you would already know it. What you can do is reason about where hidden uncertainty tends to live in a design of this shape, and go look there. The quadrant is a search area, not an inventory.

The step that changes how teams work is turning fog into prototype questions, with the rule that a prototype question describes what must be *learned*, not what must be *built*. The difference is not academic. "Build a playable version of the crafting system" is a task. "Can players understand the crafting system without explanation?" is a question, and only the second one tells you when you are done.

The examples in the file are good enough to steal directly. Does this create a stronger feeling of X? What breaks first when X is layered with Z? Does X reduce friction or merely relocate it? Is the fun in A, or in the choice around A? What new problem appears after the obvious problem is removed?

It also pushes back on the default of building a playable digital prototype for everything. Experience prototypes for feel and pacing, interaction prototypes for comprehension and readability, systems prototypes for economy and balance, content pipeline prototypes for production feasibility, and Wizard-of-Oz fakes for testing behaviour before anything is really implemented. Pick the cheapest artifact that exposes the specific uncertainty.

And then stop criteria, which nobody defines and everybody needs. Prototyping without a stop condition does not end. It just gets absorbed into production one commit at a time.

Now Or Later Or Never

Skill: game-design-feature-prioritization

Covered in the Feature Adoption text, so briefly.

Candidates in, scored on impact, cost, strategic fit, risk, and timing, then classified: do now, test first, do later, discard for now.

The reason it belongs in this pack rather than only in that one is the interaction with the red team audit. Run adversarially first, then prioritize. A feature that survives a hostile pre-mortem and *then* scores well is a different proposition from one that scores well because nobody stress-tested the assumptions underneath the impact estimate. Most impact scores are guesses dressed as numbers. Red-teaming first at least tells you which guesses are load-bearing.

The other thing worth repeating in this context is that "test first" is a real verdict. In a production decision meeting, having a third option between yes and no is enormously valuable, because the real answer is very often that nobody knows yet and the cheapest way forward is to find out.

Can You Even Tell If It Worked?

Skill: game-design-kpi-coverage-audit

Also covered in Feature Adoption, and it earns its place here for a specific reason: it is the counterweight that stops the rest of the pack from becoming a machine for killing unglamorous work.

Run red-teaming and prioritization together, aggressively, and you will systematically eliminate exactly the features whose value is real but diffuse. Connective tissue. Clarity work. The thing that makes six existing systems easier to understand. None of that survives a hostile review and a scoring matrix, because none of it can point at a headline metric it will move on its own.

That is a failure of the evaluation framework, not of the work. This skill audits the measurement framing rather than the feature, and asks what kind of value is on the table and whether the metric being used captures any of it.

The red team audit has its own KPI lens, which asks whether success metrics are weak, gameable, or indirect, and whether the team is measuring activity instead of value. There is a genuinely nasty version of that question in the file: could this look successful in dashboards while actively harming the experience? Run those two together and you cover both directions — the feature that cannot prove its value, and the feature that will prove a value it does not have.

Who Is Going To Build This?

Skill: game-dev-team-gap

The last skill in the pack, and the most mundane, which is why it gets forgotten until it is a crisis.

I wrote about this one back in the beginners installment, where it is aimed at someone with an idea and no team. It does a different job at the production decision point: given this specific feature, at this scope, does the team have the coverage to actually build it?

The distinction it draws that matters most is between a role being fully missing and a role being weakly covered. Fully missing is visible. Everyone knows there is no audio person. Weakly covered is the dangerous one — there is technically someone, they are technically doing it, and they are doing it at fifty percent capacity alongside two other jobs. That does not show up on a staffing plan. It shows up eight weeks later as a schedule slip nobody can explain.

It also names single points of failure and hidden workload cliffs. The cliff is worth dwelling on. Features do not distribute their cost evenly across disciplines. A system that is trivial to program can be a content monster, and the person who discovers this is usually whoever has to produce the two hundred assets nobody scoped. The red team's content and scalability lens catches the same problem from the other side; this one catches it from the staffing side.

And the honest question it forces: does the team you actually have match the milestone you actually promised? The skill is instructed to say so directly when the answer is no.

Conclusion

The six skills in this pack are all versions of the same act, which is deliberately making yourself less confident at the exact moment when confidence is most socially rewarded.

That is genuinely hard. By the time a feature is heading into production, people have invested in it. Someone pitched it. Someone defended it in a roadmap review. Someone has already started sketching. Raising a serious objection at that point costs you something, and it is much easier to keep quiet and let the project find out the expensive way.

This is the real argument for having a machine do it. Not that the AI is smarter than the people in your room. It is not, and it does not know your game the way they do. But it has no stake in the outcome. It did not pitch the feature. It is not worried about how it will look when the thing it advocated for fails. It will tell you the MVP is going to cut the exact element that makes the concept work, and it will do it without any of the social calculation that stops a human from saying the same sentence.

Make no mistake, this is not a substitute for a team culture where people can say hard things out loud. If your studio cannot survive an honest pre-mortem, an AI audit is not going to save you — you will just have a document that nobody acts on, which is arguably worse, because now the failure is on record and was ignored anyway.

Used well, though, it changes what the conversation is about. Instead of one person having to be the one who raises the objection, you have a written list of credible failure modes on the table, and the discussion becomes which ones are real rather than whether anyone is allowed to have doubts.

And that brings this series to a close.

Nine texts, sixty-odd skills, and one idea running underneath all of them: none of this does the thinking for you. The frameworks are old, mostly borrowed, and available to anyone who reads. What the skills provide is structure and framing for a conversation, and the discipline to ask the same good questions consistently instead of only on the days you remember to.

The feedback you get from AI is only as good as the questions you ask. That was true in the first text and it is still true here. What has changed over the course of writing these is my sense of where the leverage actually is. It is not in the clever answer. It is in refusing to skip the boring question — what is this really for, who is it for, what does it ask of them, what happens when it goes wrong, what should we cut, and can we tell if it worked.

Thank you for reading. Go make something, then go find out how it fails.

Key Takeaways

  • The point of no return is not the start of production. It is the earlier, unannounced moment when the room stops asking whether the idea is good and starts asking how to build it.
  • Assume failure and work backwards. Asking whether something might fail produces hedging. Asserting that it failed produces a list.
  • Every criticism must name a mechanism. "This could be confusing" is a mood. Naming which feedback is missing and what opacity it creates is a finding.
  • The MVP often cuts the thing that would have made the concept work. That produces a false negative, and a good idea gets killed on the evidence of a version that was never going to work.
  • Ask whether the team is prepared only for success. Most rollout plans quietly depend on perfect tuning, perfect messaging, and perfect segmentation.
  • A designed cut states what is lost and offers a lighter substitute. If nobody can say what was given up, that was panic descoping, not a decision.
  • Late cuts get made by whoever is most tired. They optimise for what is easiest to remove rather than what is least valuable, and those are very different criteria.
  • Prototype to expose uncertainty, not to mimic production. A prototype question states what must be learned, not what must be built.
  • Define stop criteria before you start prototyping. Without them, exploration does not end — it gets absorbed into production one commit at a time.
  • Red-team before you prioritize. Impact scores are guesses dressed as numbers; a hostile pass tells you which guesses are load-bearing.
  • Aggressive prioritization systematically kills connective tissue. Keep the KPI coverage audit in the loop or you will eliminate exactly the work whose value is real but diffuse.
  • Weakly covered is more dangerous than missing. An absent role is visible. A role held at half capacity by someone with two other jobs surfaces eight weeks later as an unexplained slip.
  • The value of an AI audit is that it has no stake. It did not pitch the feature and it will not look bad when the feature fails, which is exactly why it will say the sentence nobody in the room wants to say.

Links

This series

Platforms & repository

My previous writing on these topics

AI Skills for Game Design - Production Decisions was originally published in Babel on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[Two Variables Is One Too Many]]> https://medium.com/design-bootcamp/two-variables-is-one-too-many-ce9fb559637d?source=rss-5c3f0bb4eddc------2 https://medium.com/p/ce9fb559637d Mon, 14 Sep 2026 14:01:05 GMT 2026-09-14T18:50:58.967Z

Consider Angry Birds.

A slingshot game involves aiming and launching something at a target. The player needs to optimize his shot using two variables: the angle and the velocity, i.e. the strength of the shot.

How do most people go about completing this task? Ninety-nine percent of them will first try shooting at full power and optimizing the direction of the shot. Only after some trial and error will they switch things around, fix the angle of the shot, and try to optimize the power instead.

Watch someone play. Watch yourself play. It happens so consistently that it stops looking like a preference and starts looking like a reflex.

Why do people behave this way, and why does it even matter?

It Is an Optimization Problem

People behave in this way because this is an optimization problem. More specifically, it is a two variable optimization problem, the optimal value for power of the shot and the angle at which the bird should be launched. People have at their disposal one of the very best optimization engines in the known universe, their brains, and yet people are really bad at two variable optimization problems.

This is not because people are stupid, or because our brains are inadequate. It is because the task is genuinely, mathematically hard. There is an entire field of mathematics dedicated to multivariate optimization, and the problem is far from being solved in a satisfactory manner. Most optimization strategies work by simplifying the problem — by reducing dimensionality, i.e. reducing the number of variables being manipulated at any one moment.

One of the simplest strategies operates in exactly the same way as most Angry Birds players do. It fixes a value for one variable and optimizes only the other. Then it swaps, fixes the second variable at its new best value, and optimizes the first. Then it swaps again, and keeps going until it stops improving.

This has a name. It is called coordinate descent, and it is a legitimate technique that people get paid to implement.

I find this genuinely delightful. Nobody teaches players coordinate descent. Nobody explains it in the tutorial. And yet a person who has never heard the phrase, handed a slingshot and a pig, will independently derive one of the standard approaches to a hard mathematical problem within about four attempts.

Players are not doing arithmetic. They are doing something much better: they are recognising, without being able to articulate it, that a problem with two moving parts is unmanageable and that a problem with one moving part is not.

Why Full Power First

Now, coordinate descent tells you that players will fix one variable. It does not tell you which one.

And it is always power. Nearly nobody starts by fixing a mid-range angle and hunting for the right strength. They pull the slingshot all the way back and then wave the bird up and down until something works.

The reason, I think, is that power has an obvious anchor value and angle does not.

Full power is a natural, salient, unambiguous extreme. It sits at the end of the slider. You can reach it without deciding anything, and you can be certain you have reached it. Ask yourself what the equivalent anchor for the angle would be. Forty-five degrees? That is the textbook answer for maximum range on flat ground, and precisely nobody who is not an artillery officer holds it as an intuition.

So the player fixes the variable that has a free, obvious value, and searches over the one that does not.

This generalizes further than slingshots, and it is worth stating as a rule: when players are asked to tune several things at once, they will pin whichever one has an obvious extreme and search over the rest. If you have a design with three sliders and one of them has a natural maximum, you have effectively built a two-slider design and given the third away.

There is a secondary reason too. Maximum power produces the flattest trajectory, and a flat trajectory is easier to reason about. The arc is closer to a straight line, so aiming becomes something like pointing. Players are not just fixing a variable. They are fixing it at the value that makes the remaining problem as close to linear as possible, which is another thing they were never taught and do it anyway.

The Error Signal Is Doing a Lot of Work

Here is the part I think is most underrated in this whole discussion, and it is the part that matters most for design.

Optimization is only possible if failure tells you something.

When you miss in Angry Birds, you do not receive a message saying "incorrect." You see where the bird landed. Short. Long. Left. Over the structure and into the empty space behind. That is a rich, signed, directional error — it tells you not only that you were wrong but in which direction and roughly by how much.

That is the whole game. Take that away and no amount of intuitive coordinate descent will save the player, because they have nothing to descend towards. Mathematicians call the version without a gradient derivative-free optimization, and it is dramatically harder than the version with one.

This is why the two-variable problem is tolerable in a slingshot game and intolerable in, say, a stealth game where the failure state is an alarm and the player has no idea which of their six decisions caused it. Same number of variables. Completely different difficulty, entirely because of the quality of the feedback.

I have written before about how players attribute failure and how much design damage is done when they cannot tell whose fault a loss was. This is the optimization-flavoured version of the same problem. A player who cannot attribute an error cannot improve, and a player who cannot improve is not playing a skill game, they are pulling a lever.

Design rule: if you ask the player to tune something, show them the direction of their error, not just the fact of it.

Why It Still Takes So Many Tries

If coordinate descent works and the feedback is good, why does anyone need eight attempts?

Because the two variables are coupled.

Coordinate descent is excellent when variables are independent. Optimize the first, optimize the second, done, no need to revisit. It degrades badly when the variables interact, because improving one changes what the best value of the other would have been. You fix power, find your best angle, then reduce power — and now your carefully found angle is wrong again.

In a slingshot, range depends on both angle and velocity, and it depends on their product in a way that makes them thoroughly entangled. So the player zigzags. Adjust angle, overshoot. Adjust power, undershoot. Adjust angle again. Each pass gets closer, and the convergence is slow enough to be frustrating and fast enough to feel like progress, which is, not coincidentally, a fairly good description of a satisfying puzzle.

This gives you a dial. Independent variables make a system feel clean and learnable. Coupled variables make it feel deep and difficult. Neither is correct in the abstract. But if your players complain that a system is fiddly and opaque, check whether you have coupled things that did not need coupling — and if they complain that a system is shallow, check whether everything in it is separable.

Adding a Third Dimension

Raising the number of dimensions only increases the complexity.

This is why 3D artillery games have such a poor track record. Worms went 3D in 2003 and the series eventually went home to two dimensions and stayed there. Scorched Earth's descendants did the same. The 3D versions are not badly made. They are solving a harder problem.

In a 3D slingshot, the player needs to optimize two angles and a velocity. Three variables. And the trouble is not merely that three is more than two. The trouble is that the player's usual trick has stopped working. They can still fix the power at maximum, exactly as before. But that leaves two angles to optimize simultaneously, and now they are back where they started, facing a two variable problem with no obvious anchor for either variable — because neither azimuth nor elevation has a free extreme value the way a power slider does.

So the player is dumped straight into the situation they were instinctively avoiding, and given no tools to escape it.

Worse, the error signal degrades too. In 2D you see the miss from the side and the direction of error is legible. In 3D, judging depth from a camera behind the projectile is genuinely hard, and "I missed by that much" becomes much harder to read. So the problem gets harder in exactly the same move that makes the feedback worse.

That is a double penalty, and it is enough to sink a genre.

How Games Cheat

Every successful game in this space is doing something to reduce the dimensionality on the player's behalf. Once you know to look, the tricks are everywhere.

Discretize a variable. Golf games are the cleanest example. Aiming a golf shot is a full three variable problem, and golf games solve it by turning one variable into a short list: you pick a club. Club selection is really a power choice, but rendered as fourteen discrete options rather than a continuous slider, which converts an infinite search space into a menu. The remaining continuous variables are then handled one at a time by a swing meter.

Sequence the inputs. A swing meter, a pool cue, a charge-and-release — these all force the player to lock one variable before the next becomes editable. The design is imposing coordinate descent rather than hoping the player invents it.

Preview the outcome. A trajectory arc turns trial and error into direct manipulation. This is enormously powerful and it is why so many mobile puzzle games show a dotted line. It effectively hands the player the gradient.

Remember the search. Angry Birds leaves the trails of your previous shots on the screen. That is not decoration. It is the game storing your optimization history so you do not have to hold it in your head, and it is one of the smartest small design decisions in the genre.

Each of these is the same move: take the multivariate problem the player cannot solve, and hand them a sequence of single-variable problems they can.

This Is Not Really About Slingshots

Everything above generalizes to any system where a player faces several continuous, interacting choices at once. Which is to say: most progression systems, most build systems, most economies.

Give a player five stats to distribute and they will not evaluate the space. They will pick the one they understand, push it, and leave the rest near default. Give them a loadout with six interacting slots and they will optimize one slot at a time and never revisit the first. Give them an economy with four resources and three conversion rates and they will find one loop they trust and run it forever.

This is not laziness. It is coordinate descent, and it is the correct strategy for a creature that cannot see the whole surface.

It also explains something about the way communities behave. A published build guide, a tier list, a wiki page with an optimal rotation — these are precomputed solutions to a multivariate optimization problem that individual players cannot solve for themselves. That is why guides appear the instant a system exceeds about two meaningful variables, and why the appearance of a dominant meta is not a sign that your players are boring. It is a sign that you set a problem that was too hard to solve alone, and someone solved it once for everybody.

If you want players to actually explore your build space rather than import an answer, the lever is not more content. It is fewer coupled variables, or better feedback per variable, or both.

The Plateau

One last consequence, and it is the one that shows up in retention numbers rather than in reviews.

Coordinate descent gets stuck. It converges on a point where no single change improves things, even when a better solution exists that would require changing two things at once. In the mathematics this is a local minimum. In your game it is a player who has found a build that works, cannot improve it by adjusting any one thing, and concludes that they have finished learning.

They have not finished learning. They have exhausted the strategy available to them.

A player in this state does not complain. They do not write a review saying the optimization landscape has trapped them in a local optimum. They just get slightly bored, and then they stop.

If you want them out of it, you have to break the one-variable-at-a-time approach for them: a respec, a forced constraint, a limited-time mode that bans their pinned variable, a new item that only makes sense alongside a different stat. Anything that makes the player change two things simultaneously and see what happens.

Conclusion

There is a version of game design that treats the player as an agent who evaluates options and picks the best one. It is a comfortable model and it is wrong.

The player is not evaluating your option space. The player is running a cheap search over a surface they cannot see, using the only strategy available to something with a working memory of a handful of items: hold everything still, wiggle one thing, see what happens, keep the improvement.

That single fact explains an enormous amount. It explains why they pull the slingshot all the way back. It explains why 3D artillery games feel wrong in a way that is hard to name. It explains golf's fourteen clubs, the dotted trajectory line, and the ghost trails of your previous birds. It explains build guides, dominant metas, and the specific flavour of boredom that arrives when a player has optimized as far as one-variable thinking will take them.

We are not, as a species, well equipped for multivariate optimization. What we are extremely good at is finding a way to only have to do one thing at a time.

Design for that player, because that is the one who bought your game.

Key Takeaways

  • Aiming a slingshot is a two variable optimization problem, and people are bad at those — not through stupidity, but because the problem is genuinely hard and mathematically unsolved in the general case.
  • Players spontaneously invent coordinate descent. Fix one variable, optimize the other, swap, repeat. Nobody teaches it and nearly everybody does it.
  • They pin the variable with an obvious extreme. Full power sits at the end of a slider; no angle has a comparable free anchor. Any variable with a natural maximum will be pinned rather than explored.
  • Maximum power also flattens the trajectory, making the remaining problem closer to linear. Players simplify without knowing they are simplifying.
  • Optimization requires a directional error signal. "You missed, and by this much, in this direction" is workable. "Incorrect" is not. The same number of variables becomes far harder when the feedback is unsigned.
  • Coupled variables are what make it take eight tries. Independent variables feel clean and learnable; coupled ones feel deep and fiddly. Choose deliberately.
  • A third dimension breaks the player's escape route. Fixing power still leaves two angles with no anchor, and depth perception degrades the error signal at the same time. That double penalty is why 3D artillery games keep returning to 2D.
  • Successful designs impose dimensionality reduction on the player's behalf — discretize a variable into a menu, sequence the inputs, preview the trajectory, or remember the search history for them.
  • Build guides and dominant metas are precomputed solutions to a problem individual players cannot solve. A meta forming is a signal about your variable count, not about your audience.
  • Coordinate descent gets stuck in local optima, and a player stuck there does not complain — they quietly conclude they have finished learning, and leave.

Links

Two Variables Is One Too Many was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[AI Skills for Game Design - Social Design]]> https://stanislav-stankovic.medium.com/ai-skills-for-game-design-social-design-c2518dde27bb?source=rss-5c3f0bb4eddc------2 https://medium.com/p/c2518dde27bb Mon, 07 Sep 2026 14:01:03 GMT 2026-09-07T17:40:16.968Z

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:

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?

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

Platforms & repository

My previous writing on these topics

]]> <![CDATA[Hexagons vs. Squares]]> https://medium.com/design-bootcamp/hexagons-vs-squares-ea1407914f13?source=rss-5c3f0bb4eddc------2 https://medium.com/p/ea1407914f13 Mon, 31 Aug 2026 14:01:02 GMT 2026-09-02T08:02:51.832Z

Today's text is a result of discussions I had with my fellow game designers some years back, when our studio was embarking on a new prototyping spree. We specialized in city builder design and many of our ideas revolved around various builder game mechanics.

One of the pretty fundamental design decisions that needs to be made when starting to work on such a game is about the underlying grid your game is going to use. A rectangular grid seems like the obvious choice, the one you will most likely pick out of inertia and without thinking. However, there are loads of games that do not take this path. Unless you are doing something really experimental, your only remaining choice will be the hexagonal grid.

You may think that the choice between hexagons and rectangles is purely aesthetic, and that you are free to pick one or the other based simply on your personal preference. However, things are not quite as simple as they seem. The choice of underlying grid has much more profound implications on many aspects of game design. Choosing one over the other without being aware of these implications might come back to haunt you mercilessly down the line.

What follows is my attempt to lay out what you are actually choosing between.

Tessellation

Above all, let's first examine why we have just two choices. The answer to this question lies directly in the fabric of our universe, or at least in the way we are hardwired to perceive it. For reasons we do not quite fully understand yet, we feel most comfortable perceiving our universe in three spatial dimensions and describing it using so-called Euclidean geometry. Sorry, fans of Lobachevsky, Riemann and other eldritch horrors.

In this framework, a 2D plane is defined by three points. In other words, you can pick any three points and construct a plane over them. Three points obviously define the vertices of a triangle. A triangle is thus the first geometric shape that we can use to populate the plane. If we remove one of the points of the triangle, our plane collapses into a one dimensional line. All other shapes with straight edges can be constructed as a combination of two or more triangles.

The process of filling up a 2D plane with geometric shapes is known as tessellation. One of the defining prerequisites of tessellation is that the underlying plane is covered completely with shapes, without overlap and without gaps between them. If we are constructing a grid, we are trying to do exactly this: cover an area with a set of cells, i.e. shapes.

Furthermore, we are imposing one stricter requirement, namely that all shapes representing cells need to be identical and regular. Since we do not want any gaps in our grid, all angles meeting at one vertex, a point in the grid, need to add up to a full circle, i.e. 360º.

That single constraint does all the work. Run through the regular polygons and check their interior angles:

  • Equilateral triangle — 60º. Six of them meet at a vertex. 6 × 60 = 360. Works.
  • Square — 90º. Four meet at a vertex. 4 × 90 = 360. Works.
  • Regular pentagon — 108º. Three give you 324º, four give you 432º. Neither is 360. Fails.
  • Regular hexagon — 120º. Three meet at a vertex. 3 × 120 = 360. Works.
  • Regular heptagon and everything above — the interior angle keeps growing past 120º, so three of them always overshoot 360º and two always fall short. Everything from seven sides up fails, forever.

Three shapes. That is the entire list, and it is not a matter of taste or convention. It is arithmetic. Anyone who has ever asked why strategy games do not use octagons has run into this wall — the answer is that octagons leave gaps, and gaps are not a grid.

Wasted Space

The reason equilateral triangles themselves are rarely used as grid elements in games has to do with the usable area of the polygon.

We are probably going to use our grid to visualize something in our game, presumably a map. This means we are going to place visual assets onto our grid tiles. If we do not want bits of our visual assets to stick out over the edges of the tile, the maximum size of the visual asset will be roughly determined by the area of the inscribed circle — the largest circle that fits inside the cell.

For the three polygons in question, the ratio between the inscribed circle and the polygon itself works out as follows:

  • Equilateral triangle — 60.5%
  • Square — 78.5%
  • Regular hexagon — 90.7%

In other words, using triangles wastes roughly forty percent of every cell. Whatever you place in a triangular tile has to cower in the middle of it, and the three sharp corners are dead space you paid for and cannot use. Squares and hexagons thus remain the only two viable choices.

Notice something else in those numbers, though, because it is the first point in this whole discussion that runs in favour of hexagons: the hexagon is the most efficient of the three. It is the closest of the tessellating polygons to a circle, which means it wastes the least space around whatever you put inside it. It also has the lowest perimeter for a given area, which is precisely why bees build honeycombs out of hexagons rather than squares — less wax for the same storage.

So if the argument were purely about geometric efficiency, hexagons would win outright and we could all go home. The argument is not purely about geometric efficiency.

Scaling

An interesting quirk of geometry is that these three shapes do not behave in a similar way when you try to combine them.

We can combine four squares to create a bigger square. Likewise, you can combine four equilateral triangles to create another, larger equilateral triangle. However, you cannot combine any number of regular hexagons to create a bigger regular hexagon. It simply does not work. Seven hexagons arranged around a central one produce a lumpy, non-convex flower shape, not a hexagon.

This property has important implications on several fronts, from the way people perceive these grids to the way visual assets can be organized.

It is easy to imagine a game asset representing a small building that can be replaced with a four times bigger asset representing a similar but much larger building. We can do this several times over to create larger and larger structures. This natural scaling property can be used in all manner of ways in games to achieve various gameplay features. Upgrade a house into a block. Merge four plots into an estate. Zoom the map out one level and have four tiles become one.

This is simply not possible with a hexagonal grid. Combining several hexagonal shapes will quickly break up the perception of regularity.

If your design involves multi-cell structures, upgrade paths that grow a building's footprint, or level-of-detail systems where the map aggregates as you zoom out, this single property may decide the whole argument for you before any other consideration gets a hearing.

Neighbours and Distance

Now we come to the part of the argument that hexagon partisans consider decisive, and they are not wrong to.

On a square grid, every cell has four neighbours across its edges. It also has four more that touch it only at a corner. That immediately forces a decision that has no clean answer: are diagonal cells adjacent or not?

Say no, and movement becomes blocky. Units shuffle in right angles like they are navigating a city grid, and a "range of three" looks like a diamond.

Say yes, and you have imported a problem. The diagonal is longer than the edge, by a factor of √2, roughly 1.414. If a diagonal step costs the same as an orthogonal one, then a unit moving diagonally covers about forty percent more ground for the same price. The optimal way to cross any distance becomes a zigzag, which is both unrealistic and slightly silly. A unit that marches fifty kilometres a day north suddenly manages seventy kilometres if it goes northwest instead.

Games have patched around this for decades. Charge 1.5 movement points for diagonals. Alternate the cost between 1 and 2. Forbid diagonal movement through two blocked corners. Every one of these is a workaround for a problem the geometry created, and each of them adds a rule the player has to learn.

There is a subtler version of the same problem, and it matters more than the distance does. On a square grid, two diagonal cells touch at a single point, not along an edge. Does fire spread through that point? Does a wall built on both diagonals block movement between them? Does a zone of control extend across it? Does a flood fill leak through? There is no correct answer, only a decision, and you will make that decision separately for every system in your game and get it slightly wrong in at least one of them.

A hexagonal grid has none of this. Every hexagon has exactly six neighbours. All six share a full edge. All six are the same distance away. There are no corner-contacts anywhere in the entire grid, because three hexagons meeting at a vertex all mutually share edges. The ambiguity does not get resolved — it never exists.

This is why hexes became the standard for tabletop wargames long before video games existed, and the reason the military adopted them for map exercises. Distances are honest. A range of three tiles describes a shape that is roughly circular rather than a square or a diamond. Artillery ranges, line of sight, movement allowances and zones of control all behave the same way in every direction, without a table of special cases.

There is a cost, of course. Six directions rather than eight. Some players experience this as a loss of freedom, and defensive lines that were leaky on a square grid become genuinely difficult to breach on hexes, which changes tactical play considerably.

Perception

As I have stated many times in my writing, video games are where mathematics and psychology meet to have a party. Pure mathematics provides just the basics. The psychology of human perception is where the true magic happens.

We perceive graphics constructed on a rectangular grid as more orderly, and graphics constructed on a hexagonal grid as more organic. This is rooted in the difference in scaling properties of squares versus hexagons. Combining several hexagons results in quasi-organic looking non-convex shapes.

This property of hexagonal grids can be exploited if we are aiming for exactly that, for example if we want to create a natural, irregular landscape. A hexagonal grid allows us to do this while keeping a relatively simple and elegant mathematical structure underneath.

On the other hand, if our goal is to create a more rigid, regular looking map, a rectangular grid might be the better choice.

This is evident in the genres where each grid type dominates. Compare the classic hex wargame — Panzer General and the whole Avalon Hill lineage it descends from — with a city builder like SimCity. In the wargame, the map is terrain: rivers, ridgelines, forests, none of which have any business being straight. In the city builder, the map is a city: blocks, roads meeting at right angles, rectangular buildings on rectangular plots. One subject matter is organic and the other is rectilinear, and the grids follow accordingly.

That is not a coincidence and it is worth stating as a rule of thumb. Match the grid to the geometry of the thing you are depicting. Nature is not rectilinear. Human construction very much is.

Furthermore, for some reason we humans seem to intuitively prefer rectangular shapes. Could it be because we are essentially quadrupedal creatures? Would insects prefer hexagonal spaces?

Rectangular houses are one of the most common features of architecture across a great many human cultures, followed closely by round floor plans of various huts. Hexagonal houses are extremely rare. Beehives, on the other hand, share a basic hexagonal plan.

Words for Directions

Try aligning four cardinal directions North, South, East and West to hexagons. Try giving movement instructions on a hexa map?

Simply put, our mental models seem to be better tuned to rectangular maps. Regardless of whether this is a result of our biology or simply a cultural artifact, it is reflected in the language we use.

Almost all languages have words that unambiguously describe movement in rectangular space: up, down, left, right. No language has unique words for six directions in hexagonal space. Movement in rectangular space is easier to translate into words.

Ok, fine, I am fully prepared for some wiseguy to point out a language of some obscure rainforest tribe that has words for six cardinal directions, but that is an exception that just reinforces the rule.

This is not a trivial matter, and I think it is the most underrated item on this entire list.

Your tutorial may need to give clear movement instructions. "Move two tiles to the right" is a sentence. The hexagonal equivalent is not. You end up saying "up and to the right," which is two words for one direction and is ambiguous about which of the two upward diagonals you meant.

More importantly, players talk to each other. They coordinate, they plan strategies, they write guides, they argue in forums about the correct opening. All of that runs on language, and hexagonal space does not have the vocabulary. Watch any hex-based community and you will find they have invented their own conventions — clock positions, compass headings, coordinate callouts — precisely because the natural language was not there.

If your game involves any meaningful amount of player-to-player communication about position, this is a real cost. It is invisible in a design document and extremely visible in a Discord server.

Finally, the quasi-organic appearance of hexagonal grids may have adverse effects on the overall user experience. As I already mentioned, rectangular grids tend to be perceived as more orderly. Piling and placing objects onto a hexagonal grid can result in a cluttered appearance. This becomes a significant problem if the player is expected to constantly locate particular items or locations on the grid.

Incidentally, this is a known tension in hex design. The Civilization V team deliberately obscured their tile borders and let terrain bleed between hexes to get a more organic look — and players immediately complained that they could no longer tell where the tiles were. Legibility and organic feel pull against each other, and you cannot have both at full strength.

The Cost of Building It

Everything above is design. This section is production, and it is the part that gets discovered three sprints in.

Coordinates. A square grid is a two dimensional array. Cell x, y. The neighbours are x±1 and y±1. Any programmer can hold the entire mental model at once, and every engine, tilemap tool and level editor supports it natively.

Hexagons need a coordinate system, and there are several, none of which is obviously correct. Offset coordinates look like a normal array but the neighbour offsets change depending on whether the row is odd or even, which is a permanent, inexhaustible source of off-by-one bugs. Axial coordinates are cleaner. Cube coordinates, where three axes sum to zero, make distance and rotation mathematics genuinely elegant, but require conversion at the boundaries and are unintuitive to anyone encountering them for the first time. This is all solved and well documented — Amit Patel's hexagonal grids reference is the canonical resource and I recommend it unreservedly — but "solved" is not the same as "free." It is a tax on every engineer who touches the map for the lifetime of the project.

Art. Square tiles pack into a texture atlas with zero waste. A hexagon inside its bounding box occupies exactly 75% of it, so a quarter of your tile texture memory is transparent corners. On top of that, seamless tiling art is harder on hexes, and any structure that spans multiple cells is a nightmare, because there is no rectangular multi-cell shape to build against.

Rotation. Square pieces rotate in clean 90º increments and a rotated square footprint is still a rectangle. Hex pieces rotate in 60º increments, and a multi-hex shape rotated by 60º occupies a genuinely different set of cells. If your game lets players rotate anything, budget for it.

Map edges. A rectangular grid has a rectangular boundary. A hex grid has a ragged one, and you will either accept the raggedness, mask it with terrain, or write special cases for the border rows.

Everything around the map. Screens are rectangular. Inventories are rectangular. Build menus, card hands, shop grids, and every other piece of UI in your game is on a rectangular grid whether you like it or not. A hex map is a hexagonal island in a rectangular ocean.

None of this makes hexes wrong. It makes them a decision with a price tag, and the price is paid by people who were not in the room when the decision was made.

The Civilization Case

The best available case study is Civilization, because it is the same design team, the same genre, and the same audience, and they switched.

Civilization I through IV ran on squares. Civilization V moved to hexes, and Civilization VI and VII have stayed there. The reasoning given at the time was exactly the argument in the adjacency section above: honest distances, no diagonal exploit, and — the marketing language of the era — more organic landscapes.

What makes it genuinely instructive is that the grid change did not arrive alone. Civ V also introduced one unit per tile, and those two decisions are load-bearing for each other. Building a defensive line on a square grid with diagonals is close to impossible, because there are always corner gaps to leak through. On hexes, six clean edges make a line an actual line. The grid change enabled a combat design that the old grid could not support.

That is the lesson worth taking. The grid was not swapped because hexes are prettier. It was swapped because a specific mechanic the team wanted became possible. And the trade was real: players lost two movement directions and spent a good while complaining about it.

If you cannot name the mechanic your grid choice is enabling, you are probably choosing on aesthetics, and that is fine — but be honest with yourself that this is what is happening.

So Which One?

There is no universal answer, which is why this text is longer than "use hexes" or "use squares." But the decision does decompose into a handful of questions with fairly clear answers.

Choose squares when:

  • You are depicting human construction. Buildings, roads, plots, city blocks, farms, factories. Rectilinear subject matter wants a rectilinear grid.
  • Your design needs multi-cell structures, footprint upgrades, or aggregation when zooming out.
  • Players will need to talk to each other about position.
  • Readability under clutter matters — the player must repeatedly find a specific thing on a busy board.
  • Your team is small and the engineering budget is tight.

Choose hexes when:

  • You are depicting terrain. Landscape, wilderness, territory, anything nature made.
  • Fair distance in all directions is mechanically important. Ranged combat, movement allowances, line of sight, area of effect.
  • Adjacency itself is a design resource — six neighbours give you a richer set of relationships than four, which is exactly how Civilization VI's district adjacency bonuses work.
  • You want to eliminate the corner-contact ambiguity entirely, which matters enormously for propagation systems like fire, disease, influence or supply.
  • Zones of control and defensive lines need to actually hold.
  • You feel superior to other humans.
  • You are addicted to board games.
  • You hate yourself.

And in the interest of completeness: there is a third path, though the draft version of this text claimed there were only two. You can abandon the regular grid. Frostpunk arranges its city radially around a heat source, which is a grid derived from the fiction rather than from geometry. Townscaper builds on an irregular quadrilateral grid that produces charmingly wonky results. Cities: Skylines lets you draw roads freely and derives the plots afterwards. All of these cost more to build and none of them are safe defaults, but "unless you are doing something really experimental" is doing a lot of work in my opening paragraph, and it is worth knowing that the experimental door exists.

Conclusion

The grid is the most quietly consequential decision in this class of game, and it tends to get made in the first week by whoever set up the prototype, on the basis of what was easiest to code that afternoon.

That is what makes it worth writing about. Almost every other early decision can be revisited. You can retheme a game, rebalance an economy, redesign a progression system, and replace an art style, all painfully but all possible. The grid is different, because everything else is built on top of it. Movement rules assume it. Art assets are cut to it. Multi-cell structures are shaped by it. The UI is laid out around it. By the time anyone realises the grid was wrong, changing it means rebuilding the game.

So it deserves an hour of explicit discussion before anyone opens an editor. Not a long hour. Just long enough to answer: what are we depicting, does fair distance matter, will things grow across multiple cells, and will players need to talk about where things are.

Answer those four and the grid chooses itself.

Key Takeaways

  • There are exactly three regular tessellations, and it is arithmetic, not convention. Triangles, squares and hexagons. Pentagons and everything above seven sides cannot close 360º at a vertex.
  • Triangles waste about forty percent of every cell, which is why they never survive contact with an art pipeline.
  • Hexagons are geometrically the most efficient at 90.7% usable area against the square's 78.5%. If efficiency were the only criterion, hexes would win outright.
  • Squares scale and hexagons do not. Four squares make a bigger square; no number of hexagons makes a bigger hexagon. If your design has footprint upgrades, multi-cell buildings or zoom aggregation, this may decide everything on its own.
  • The diagonal problem is the strongest argument for hexes. On squares, a diagonal step is 1.414 times longer than an orthogonal one, so equal-cost diagonals reward zigzagging.
  • Corner contact is the subtler and more damaging version of that problem. Diagonal squares touch at a point, so every propagation system in your game needs its own arbitrary ruling. Hexes share only edges and the ambiguity never arises.
  • Match the grid to the geometry of what you are depicting. Nature is not rectilinear; human construction is. That single heuristic resolves most cases.
  • No language has words for six directions. If players must communicate about position, hexes impose a permanent, invisible tax on your tutorial and your community.
  • Legibility and organic feel pull against each other. Obscure hex borders for a natural look and players lose track of the grid.
  • Hexes carry a real production cost in coordinate systems, texture waste of twenty-five percent, rotation, ragged map edges, and the mismatch with an otherwise rectangular UI.
  • Civilization switched grids to enable a mechanic, not for looks. One unit per tile needs clean edges to build a line. If you cannot name the mechanic your grid enables, you are choosing aesthetically.
  • The grid is nearly irreversible. Everything else in the game gets built on top of it, so spend the hour arguing about it before anyone opens an editor.

Links

Hexagons vs. Squares was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

]]> <![CDATA[AI Skills for Game Design - Fairness, Failure and Memory]]> https://stanislav-stankovic.medium.com/ai-skills-for-game-design-fairness-failure-and-memory-9e2a329bdc5b?source=rss-5c3f0bb4eddc------2 https://medium.com/p/9e2a329bdc5b Mon, 24 Aug 2026 14:01:04 GMT 2026-08-24T16:42:58.438Z

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:

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.

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

Platforms & repository

My previous writing on these topics

Frameworks referenced

]]> <![CDATA[AI Skills for Game Design — Feature Adoption]]> https://stanislav-stankovic.medium.com/ai-skills-for-game-design-feature-adoption-2053662fdb33?source=rss-5c3f0bb4eddc------2 https://medium.com/p/2053662fdb33 Mon, 17 Aug 2026 14:01:05 GMT 2026-08-17T15:08:18.088Z

This text is a sixth 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:

There is a very specific flavour of misery that comes with shipping a feature nobody uses.

You know the one. You spent a quarter on it. The design was solid. The reviews went well. Art did lovely work. QA signed off. It went live, the update notes celebrated it, and then you opened the dashboard a week later and found that eleven percent of your daily actives have ever tapped the entry point. Eleven percent. And of those, most tapped it once, out of curiosity, and never came back.

Then the post-mortem happens, and someone says the players just don’t want it. And everyone nods, because that is the easiest explanation available and it lets everyone go home.

I have been in that meeting more times than I would like to admit, and I have said that sentence myself. It is almost always wrong. Or rather, it is almost always incomplete in a way that stops you from learning anything. Players are not sitting there rejecting your feature on the merits. They are not evaluating it at all. They are busy doing whatever they came to do, and your feature failed to intercept them.

The previous installment was about who your players are and what kind of motivation your design creates. This one is about the far more mechanical question that comes right after: given that they want the thing, will they actually do the thing? Because wanting and doing are separated by a surprising amount of machinery, and almost all of that machinery is invisible from inside a design review.

This batch of skills is about that gap. It contains:

  • game-design-fogg-behavior-audit
  • game-design-friction-journey-audit
  • game-design-player-perspective-reframe
  • game-design-thinking-fast-and-slow-audit
  • game-design-goal-density-and-immediacy-audit
  • game-design-feature-prioritization
  • game-design-kpi-coverage-audit

The first five skills are diagnostic. They look at a feature that exists, or is about to exist, and ask why the behaviour is or isn’t happening. The last two are about the decision layer above that, which is arguably where most adoption problems are actually born. A feature that should never have been built will not be rescued by better prompting.

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.

Motivation, Ability, Prompt

Skill: game-design-fogg-behavior-audit

This is the anchor of the pack, and it is built on BJ Fogg’s behaviour model, which states something almost annoyingly simple: a behaviour happens when motivation, ability, and a prompt converge at the same moment. Miss any one of the three and nothing happens, no matter how good the other two are.

I dealt with the motivation half at length in the previous installment, so I am going to skip lightly over it here. What I want to talk about is the other two thirds, which in my experience get roughly a tenth of the attention in most design discussions. Please take a look at my previous texts on this subject here and here.

Ability first. Ability is not “is the player capable of this.” Ability is the total cost of doing the thing right now, in this context, on this device, with this much attention available. Step count. Cognitive load. Time. Prerequisites. How many taps from where they currently are. Whether they need to remember something from three days ago. Whether they need to leave what they were doing. A feature that requires the player to exit their current activity, navigate two menus deep, and understand a new resource before the first meaningful action is not a feature with a motivation problem.

Then the prompt. The prompt is the one that gets designed last, usually by whoever is left, usually as a badge. And prompts are enormously sensitive to timing in a way that badges are not. A prompt that arrives when motivation is high and ability is high produces the behaviour. The exact same prompt, arriving thirty seconds earlier while the player is mid-task, produces an annoyance and a dismissal — and worse, it teaches the player that this particular badge is noise.

The skill forces you to name the exact target behaviour before it will analyse anything, which sounds like bureaucracy and is actually the whole trick. Try it. Take a feature you are worried about and write down, in one sentence, the specific action you want a specific player to take at a specific moment. If you cannot do it, that is your finding. A distressing number of features are trying to cause four behaviours at once and are therefore causing none of them.

The output separates the three factors, then names the bottleneck. That last part matters. Teams love to fix all three at once, which means shipping a bigger reward, a shorter flow, and a louder badge simultaneously, and then having no idea which one worked.

Good Friction and Bad Friction

Skill: game-design-friction-journey-audit

Ability, as Fogg defines it, is one number. Real player journeys are not one number. They are a chain of steps, each with its own small cost, and the interesting failures happen in how those costs stack.

This skill maps the journey step by step and classifies the friction at each one. Productive friction, harmful friction, or mixed.

That three-way split is the reason I built it rather than just leaning on Fogg. The instinct when someone says “friction” is to remove it, and that instinct is wrong often enough to be dangerous. Some resistance is doing real design work. It creates commitment, anticipation, tradeoffs, and the feeling that a decision mattered. Strip all of it out and you get a game that plays itself, which is a different and worse problem than a game that is slightly annoying.

Harmful friction is the stuff that produces confusion, dead time with no meaning, arbitrary blocking, unreadable requirements, repeated admin work, and punishment without learning. And the mixed category is the honest one, because in practice most friction is a good idea implemented at the wrong intensity. Not the wrong mechanic. The wrong dial setting.

Each friction point gets rated on intensity, visibility, and how fair it feels. The visibility axis is the one I would point at if you only take one thing from this section. A mild friction that is hidden is more dangerous than a severe friction the player can see coming. Players will tolerate an enormous amount of cost if they understand why it is there and can plan around it. What they will not tolerate is discovering, after investing effort, that there was a requirement nobody told them about.

Then it looks at accumulation. This is where the value is. Any single medium friction in your flow is survivable. Three medium frictions stacked in the same thirty seconds — a resource you are short on, plus a timer, plus a requirement that isn’t clearly labelled — is a wall. Nobody designed that wall. It emerged, because each of the three constraints was added by a different person solving a different problem, and no single review looked at the flow end to end.

The Same State, A Different Story

Skill: game-design-player-perspective-reframe

This one is the odd one out in the pack and it is probably my favourite of the seven.

Every other skill here assumes the fix is structural. Change the flow, move the prompt, cut a step. This one deals with the case where the player has perfectly good options available and simply cannot see them as worth doing. Not blocked. Stalled. The mid-game player who says nothing is happening, while sitting on top of six systems they have stopped noticing.

The skill generates alternative readings of the same game state without changing a single mechanic. Role reframes, where you shift who the player is right now — builder becomes optimizer, collector becomes curator, grinder becomes planner. Goal reframes, where success itself is redefined from expansion to refinement, or from speed to elegance. Constraint reframes, which turn a limitation into a challenge premise: what can you do with only what you already have? System reframes, which surface a layer of meaning that was always present — this is not waiting, this is production planning. Plus narrative and social variants.

Now, here is the part that made me actually build it, and it is a guardrail rather than a feature.

Reframing is one keystroke away from gaslighting your players. There is a version of this technique that consists of telling someone their starved content phase is secretly rich, that their progression wall is a meditative interlude, that the twelve-hour timer is an opportunity for reflection. We have all seen games do this. It is contemptible and players smell it instantly.

So the skill is built to refuse. Before it generates anything, it checks whether the problem is interpretive or structural, and it is explicitly instructed to say so bluntly when the honest answer is that the economy is over-constrained or the loop is broken. Every run ends on a verdict — strong fit for reframing, partial fit with system fixes mattering more, or weak fit because this is structural. I have had it come back and tell me my reframe was lipstick on a broken progression wall. That was the correct answer and I did not enjoy receiving it.

Used honestly, it is a tool for adaptive missions, re-engagement messaging, and dynamic guidance. Used dishonestly it is a way to make players accept things they should not accept. The skill knows the difference. Make sure you do too.

Fast Brain, Slow Brain

Skill: game-design-thinking-fast-and-slow-audit

Based, as the name gives away, on Kahneman. The premise is that players do not think in one uniform way. Some moments ask for rapid pattern recognition and instinctive response. Others ask for deliberate comparison, explicit planning, and careful tradeoff evaluation. Neither is better. What matters is whether the mode your design demands is the mode your design supports.

The failure patterns split neatly in two, and both are common.

Fast-mode failures are reaction demands that outrun the available clarity. Hidden information inside high-speed play. Too many simultaneous priorities. Snap judgments punished by information the player could not reasonably have processed in time. This is the category that produces the specific rage of dying to something you never saw.

Slow-mode failures are more insidious because they look like depth. False complexity with an obvious dominant answer. Too many variables to compare meaningfully. Long planning phases that are cognitively expensive and emotionally flat. Systems that imply deep strategy and resolve shallowly. If you have ever built a loadout screen with fourteen parameters where everyone picks the same three, you have shipped this.

But the section of the output I actually reach for is the transitions. Mode handoffs are where designs get genuinely ugly, and almost nobody reviews them, because the fast part and the slow part are usually owned by different people and reviewed in different meetings. Long slow-mode interruptions that kill fast-mode momentum. Fast-mode punishment for decisions made in a badly supported planning screen. Deep reasoning demanded under time pressure by an interface that offers no support for it. Cognitive whiplash, essentially, and it is a very common reason a feature gets abandoned by players who cannot articulate what was wrong with it.

There is also an audience dimension worth flagging. Expert fluency hides beginner disasters. A system that feels intuitive to the team that built it can be an exhausting analytical burden for someone in their third session. That mismatch alone can sink adoption while every internal playtest reports the feature feels great.

Is There Anything To Do Right Now?

Skill: game-design-goal-density-and-immediacy-audit

This one builds on a concept I have written about at length before, so rather than re-derive it I will point you at the original text on Density of Goals and at the follow-up on RPG mechanics, which shows the same principle running through a live game.

What the skill adds is the immediacy axis, which I think is underrated relative to density.

Density asks how many meaningful goals exist at once, spread across short, mid, and long horizons. Immediacy asks a narrower and more brutal question: when the player opens the app, how many seconds until they know what they are doing? Not how many things are available. How fast the right one becomes obvious.

These come apart more often than you would expect. A mature live game usually has enormous goal density — dozens of things a player could legitimately pursue — and terrible immediacy, because all of them are competing for the same screen and none of them is clearly the answer to “what now?” The player opens the game, faces a wall of badges, and closes it. That is not a content problem. Adding a fourteenth system will make it worse.

The audit also covers two things I think are chronically underdesigned. Safe stopping points — can the player leave without losing something, or does the design punish them for having a life? And return triggers — what specific piece of unfinished business is pulling them back tomorrow?

If your honest answer to the second question is “the notification,” you have a finding.

Should This Exist At All?

Skill: game-design-feature-prioritization

A confession that will surprise nobody who has worked with me: I think a large share of adoption problems are actually roadmap problems wearing a disguise.

The feature nobody uses often wasn’t badly built. It was badly chosen. It was the loudest idea in a room, or the one a stakeholder was attached to, or the one that felt safe because a competitor shipped something similar, and nobody ever laid it side by side against the three alternatives it beat out.

This skill is the deliberately unglamorous one. Candidates in, scored on impact, implementation cost, strategic fit, risk, and timing, then classified as do now, test first, do later, or discard for now.

Two things keep it from being a spreadsheet.

First, it explicitly refuses to pick by raw score. Roadmap sequencing, enabling value for future work, and opportunity cost all get weighed, and the skill is comfortable concluding that a lower-scoring option is the smarter move because of what it unlocks. Its working principle says it plainly: the locally optimal choice is not always the strategically best one.

Second, “test first” is a real verdict rather than a polite way of saying no. A lot of features do not need a decision, they need a cheap experiment, and having that as a first-class output makes it much easier to say out loud in a room where everyone is expecting a yes or a no.

The Things You Can’t Measure

Skill: game-design-kpi-coverage-audit

And this is the counterweight to the previous one, because prioritization frameworks have a well-known pathology: they systematically favour whatever is easiest to attribute.

You have seen this. The flashy self-contained system with a clean revenue line gets green-lit. The connective tissue work — the thing that makes six existing features easier to understand and reduces the reason players get confused and stop — gets deferred, because nobody can point at a single KPI it will move on its own. It gets deferred again next quarter. Eventually it gets done in a crisis, badly, under time pressure.

This skill audits the measurement framing rather than the feature. What kind of value does this work actually create? Is it direct monetization, direct engagement lift, retention support, reduced friction, improved comprehension, connective tissue, future feature enablement, reduced support burden? And does the metric currently being used to judge it capture any of that?

The blind spot patterns it looks for are painfully recognizable. Features dismissed because they cannot move a headline KPI alone. UX work treated as optional because it lacks clean attribution. Enabling systems undervalued precisely because their entire function is improving the performance of other things.

I want to be careful here, and so is the skill. This is not an anti-metrics argument, and it explicitly refuses to invent fake measurable certainty for support work just to get it approved. Its style rules say to diagnose the limits of KPIs, not to dismiss them. The recommendations are mostly about fairer framing — use a mixed scorecard, classify enabling work honestly as enabling work instead of forcing a bogus direct metric onto it, protect some capacity for high-value hard-to-measure work rather than letting it lose every quarterly fight it enters.

Which is relevant to this whole pack, because adoption work itself is exactly the kind of thing that loses those fights. Removing three steps from a flow does not have a launch trailer.

Conclusion

The thread running through these seven skills is that “players didn’t want it” is nearly always the wrong diagnosis, and it is wrong in a way that ends the conversation instead of starting it.

Wanting is one of three ingredients. The other two are whether the action was cheap enough at that moment, and whether anything asked at the right time. Underneath that sit the questions of whether the friction was legible, whether the cognitive demand matched the moment, whether the player could even find a goal in the first ten seconds, and — going all the way up — whether this was the right thing to build and whether you were ever measuring it fairly.

Make no mistake, none of this will tell you what happened in your game. These skills reason about your design. They cannot see your funnel. The single highest-value thing you can do with any of them is feed in real numbers — where the drop-off actually is, what the entry point conversion actually looks like — and let the skill reason against something true. Structured reasoning over real data beats structured reasoning over vibes, every time.

There is one more thing I want to say, and it is the reason I care about this pack more than its slightly dry subject matter deserves.

An unused feature is not a neutral outcome. It is a permanent tax. It sits in your UI competing for attention. It occupies a slot on a screen. It has to be balanced, localised, QA’d, and migrated forever. It makes the next feature harder to find, which makes the next feature harder to adopt, which is how games slowly become unreadable to everyone except the people who built them.

Adoption is not a launch problem. It is a compound interest problem, and it is running whether you are paying attention to it or not.

Key Takeaways

  • “Players didn’t want it” is a conversation-ending non-diagnosis. Motivation is one of three factors. Ability and prompt timing account for most of what actually goes wrong.
  • Name the target behaviour in one sentence before analysing anything. If you cannot, the feature is probably trying to cause several behaviours at once and is causing none.
  • Find the single bottleneck. Fixing motivation, ability and prompting simultaneously means you learn nothing about which one mattered.
  • Not all friction is bad. Good friction creates commitment and tradeoffs. The useful question is which resistance is doing design work and which is just in the way.
  • Hidden friction beats severe friction for damage done. Players tolerate high costs they can see and plan for. They do not tolerate requirements discovered after the effort was spent.
  • Watch for friction stacking. Three medium constraints in the same thirty seconds is a wall nobody designed, assembled by three people solving three different problems.
  • Reframing is not a licence to lie. If the loop is structurally broken, say so. A reframe that romanticizes a progression wall is worse than no reframe.
  • Mode transitions are where designs get ugly. The handoff between fast play and slow planning is rarely reviewed, because the two halves usually belong to different people.
  • Density and immediacy are different problems. Mature games often have enormous goal density and terrible immediacy. Adding a fourteenth system makes it worse.
  • Many adoption failures are prioritization failures in disguise. The feature nobody used was frequently the feature that should never have won its slot.
  • KPI frameworks quietly punish connective tissue. Work whose value is enabling other work loses every attribution fight unless you frame it honestly as enabling work.

Links

This series

Platforms & repository

My previous writing on these topics

Frameworks referenced

]]> <![CDATA[AI Skills for Game Design — Player Motivation & Audience Pack]]> https://stanislav-stankovic.medium.com/ai-skills-for-game-design-player-motivation-audience-pack-201163f89bf0?source=rss-5c3f0bb4eddc------2 https://medium.com/p/201163f89bf0 Mon, 10 Aug 2026 14:01:04 GMT 2026-08-10T17:04:16.955Z

After a summer break it is time for me to return to writing. You might remember that I have already written about application of AI in game design. This is a fifth installment in a series of texts about this topic. If you are interested in the previous texts you can find them at the following links:

In the previous text we were dealing with the blank page problem, generating ideas when you don’t yet have any. Before that we were focused on clarifying the concept you already might have. This time we are going to zoom in on something else entirely. This time we are dealing with people.

The psychology of games is on of my favourite topics. So brace yourselves. You have been warned.

Sooner or later, every design conversation arrives at the same two questions. Who is this for? And why would they keep coming back? Sure, you might be in love with your idea, but is it something that only a parent could love or is it something other humans might enjoy?

These questions sound simple, but rest assured, they are not. In my experience they are the two questions that produce the most confident nonsense in the entire industry. Everyone in the room has an opinion. Everyone’s opinion is based on themselves, on their favourite game, or on a slide from a deck someone saw at a conference three years ago. We are making this for casual players. Which casual players? You know… casual ones. Yeah, right.

Here is the thing that took me an embarrassingly long time to properly internalize. Engagement is not one substance. Two features can produce identical numbers in your dashboard and represent completely different experiences for the human holding the phone. One player opens the game because they genuinely want to. Another opens it because a badge is nagging them and they will feel vaguely bad if the streak breaks. Same DAU. Same session count. Completely different games, as far as the player is concerned.

I have written quite a lot about this over the years, mostly through the lens of Self-Determination Theory, which remains my favourite psychological framework for thinking about players. I told you that I was obsessed. The problem with frameworks like SDT is not that they are hard to understand. The problem is that they are hard to apply consistently, under deadline, on a Tuesday, when you have four features to review and a meeting in twenty minutes. That is exactly the kind of gap these skills are meant to fill.

This is the psychology-heavy bundle of my AI Skill library. It contains the following skills:

  • game-design-player-motivation-audit
  • game-design-granular-player-motivation-audit
  • game-design-player-need-satisfaction-audit
  • game-design-player-values-mapper
  • game-design-bartle-archetype-audit
  • game-design-big-five-personality-audit
  • game-design-systematizing-empathizing-audit
  • game-design-player-segment-perception-audit
  • game-design-player-persona-extractor

You will notice that this pack contains a lot of overlapping lenses. This is intentional. There is no single correct model of the player. Every one of these frameworks is a simplification, and each of them simplifies in a different direction. Bartle will tell you something that SDT will not. Big Five will tell you something that neither of them will. Running the same feature through several of them is not redundancy. It is triangulation.

Once again, treat these skills as conversation frames and not as a god given truth. None of them will tell you what your players are actually doing. Only your data and your user research can do that. What they will do is give you a structured way to think about what your design is asking of people, and who is likely to say yes.

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 Kind of Motivation Are You Building?

Skill: game-design-player-motivation-audit

This is the anchor skill of the whole pack, and the one I reach for most often.

It is built on the Self-Determination Theory spectrum of motivation. Not the simplified intrinsic-versus-extrinsic split that everyone quotes at parties, but the full ladder: amotivation, external regulation, introjected regulation, identified regulation, integrated regulation, and intrinsic motivation. If those terms mean nothing to you, I unpacked them at some length in my text about layers of motivation, and the short version is that they describe a gradient running from “I do this because I am told to” all the way to “I do this because this is who I am.”

The skill takes a feature, an event, a progression loop, a shop, whatever you point it at, and asks not whether it motivates, but what kind of motivation it manufactures, for whom, and at what cost.

The output has a fixed shape. It names the target behaviour you are trying to produce. It breaks down which motivation types are doing the actual work. It runs a quick check against autonomy, competence and relatedness. It produces a motivational profile, a diagnosis of how the thing is likely to feel from the inside, and a set of recommendations.

The single most useful question it asks is embarrassingly simple: if the reward disappeared, would anyone still do this?

Try it on your own live ops calendar sometime. It is a humbling exercise. A lot of features that look healthy in a review deck turn out to be almost entirely external regulation wearing a costume. That is not automatically fatal. External motivation is a legitimate tool and it is very good at activation. It is just terrible at carrying an entire design on its own, because it decays. Novelty fades, the reward becomes the baseline expectation, and what was once exciting becomes a chore your players resent but cannot quite quit. We have all shipped something like this. Some of us have shipped several.

The skill is deliberately blunt about the failure state at the bottom of the ladder. Amotivation is what happens when the player taps because the UI told them to, not because they care. Chasing arrows. Grind with no meaning attached. If the audit comes back with amotivation risks, do not argue with it. Go look at the flow again.

Zooming In on the Segments

Skill: game-design-granular-player-motivation-audit

The SDT lens tells you about the quality of motivation. It does not tell you much about flavour. Two features can both sit in healthy identified regulation territory and still appeal to completely different people.

This skill is the higher resolution version. It works with ten motivation themes — Personal Achievement, In-Game Achievement, Cognitive, Emotional Immersion, Creation and Exploration, Affiliation, Independence, Status and Rank, Leadership and Power, and Rewards — and nine player archetypes built on top of them: Steady Advancer, Curious Solver, Competitive Achiever, Imaginative Creator, Strategic Leader, Immersed Storywriter, Reward Seeker, Passionate Belonger, and Category Enthusiast.

The reason I built this one separately rather than folding it into Bartle is that Bartle’s four boxes are too coarse for a lot of modern live games. The distinctions this taxonomy insists on are the ones that actually matter in practice. A Competitive Achiever wants rank and proof of superiority. A Strategic Leader wants to coordinate, teach, and win through other people. Those two want very different things from your guild feature, and if you design for one while telling yourself you designed for both, you will be confused by your own retention numbers.

Two warnings that the skill takes seriously and that you should too.

The Reward Seeker segment produces misleading engagement signals. Ritualized reward harvesting looks like love in a dashboard. It is often just habit with a payout attached.

The Category Enthusiast is explicitly a caution segment, not a target. It is a residual bucket for people who are attached to a genre rather than to a coherent motivational profile. You cannot cleanly design for them and you certainly cannot cleanly market to them. The skill will say so. Let it.

Autonomy, Competence, Relatedness

Skill: game-design-player-need-satisfaction-audit

If the motivation audit asks what kind of motivation you built, this one asks whether the thing is actually nourishing anybody.

It is built on SDT’s three basic psychological needs and on the PENS model developed by Scott Rigby and Richard Ryan. Autonomy, the need to feel like the author of your own actions. Competence, the need to feel effective and improving. Relatedness, the need to feel connected, recognized, and part of something. There is also an optional fourth lens, benevolence, which you switch on when the design involves helping, gifting, nurturing or stewardship. In social city builders and farm games that fourth lens does a surprising amount of work.

The core proposition here is the one I keep repeating to anyone who will listen: fun is not a vague entertainment label. Fun is need satisfaction. A feature can have clean progression, a tidy funnel, a monetization hook and perfectly acceptable metrics, and still be emotionally hollow. This skill exists to catch exactly that.

What I like about it is that it audits denial as carefully as it audits satisfaction. For every need it produces both an evidence-of-satisfaction column and an evidence-of-denial column, with severity attached. Fake choice where one option is obviously correct. Guidance systems that are so helpful they have quietly taken the wheel. Feedback so noisy the player cannot tell whether they played well. Social systems where other people are visible but socially meaningless — the skill calls this a social shell and it is one of the most common failure modes in mobile games. Players are technically surrounded by other humans and feel completely alone.

Run this on your onboarding. Run it on your return loop. Run it on the first five minutes of a lapsed player’s second life. Those are the places where need denial does the most damage and gets noticed the least.

Reading Values Out of Behaviour

Skill: game-design-player-values-mapper

Now I have to admit something. This is the skill in the pack that most directly came out of frustration.

The frustration goes like this. You have segments. You have cohorts. You have a lot of behavioural data. And someone asks you what these players actually want, and the honest answer is that you have a spreadsheet full of what they did and no shared vocabulary for turning that into intent.

This skill is that translation layer. You give it observed behaviour — what the player repeatedly does, what they conspicuously ignore despite obvious rewards, where they invest time and money — and it maps that onto a set of value dimensions: Efficiency and Optimization, Progression and Growth, Aesthetics and Expression, Collection and Completion, Social Recognition and Status, Experimentation and Discovery, and Narrative and Meaning.

It weights them, and — this is the part that matters — it attaches a confidence level to each inference. Behaviour is ambiguous. The same action can serve three different values. A skill that produces a tidy value profile with no uncertainty attached is lying to you, and I built this one to refuse to do that.

The most useful section of the output is the tensions block. It looks specifically for contradictions, and asks a question that is easy to miss: is this a genuinely mixed profile, or is one value being actively blocked by your design? A discovery-oriented player repeating safe loops because experimentation gets punished is not a cautious player. That is a curious player whose curiosity your system has trained out of them. Those two readings lead to opposite design decisions.

The working principle of the skill puts it better than I can: players rarely state their values, but they leak them constantly through what they chase, what they skip, and what they are willing to suffer for.

The Old Faithful

Skill: game-design-bartle-archetype-audit

You knew this one was coming.

Bartle’s taxonomy is thirty years old, was derived from MUDs, and gets cited in roughly every second game design deck ever made, usually badly. Achievers, Explorers, Socializers, Killers. It is imprecise, it was never meant to be a personality test, and Bartle himself has spent decades patiently explaining what it is not.

It is also genuinely useful, which is why it refuses to die.

The skill treats the four types strictly as motivational lenses rather than as boxes people live in, and it rates each one as strongly served, moderately served, weakly served, or actively frustrated. That last category is the one worth paying for. It is easy to notice who your feature delights. It is much harder to notice who it quietly insults.

The imbalance patterns it looks for are the payoff:

  • Achiever trap — everything collapses into checklists, ranks, and completion pressure until the game becomes a job with better graphics.
  • Explorer starvation — the system is perfectly legible and completely dead. Nothing to test, nothing to uncover, no reason to poke it.
  • Social shell — other players are present but socially meaningless.
  • Killer contamination — competitive pressure bleeding into a space that was supposed to feel safe and expressive.
  • False inclusivity — the feature is marketed as being for everyone and meaningfully serves exactly one type.

A feature serving one archetype strongly is not a problem. A feature pretending to serve all four is. The skill is quite good at telling the difference.

OCEAN, Carefully

Skill: game-design-big-five-personality-audit

This one needs a disclaimer, and the skill itself opens with one.

The Big Five — Openness, Conscientiousness, Extraversion, Agreeableness, Neuroticism — is the most empirically respectable personality model psychology has produced. It is also extremely easy to misuse in game design, where it usually shows up as a decorative slide that assigns your players a Hogwarts house and changes nothing.

The skill is built to avoid that. It does not pretend your game can be reverse-engineered into a clinical instrument. Instead it converts the traits into five design questions that are actually answerable:

  • What kind of novelty appetite does this design reward?
  • What kind of structure tolerance does it demand?
  • What level of social intensity does it assume?
  • How cooperative or adversarial does it feel?
  • How emotionally rough, stressful, or safe is it?

Framed that way, OCEAN stops being astrology and becomes a comfort-and-strain map. Which is exactly what you want when you are looking at a feature that quietly demands daily maintenance, or public failure, or constant social presence, and wondering why a chunk of your audience nopes out of it without ever complaining.

The Neuroticism lens is the one I find most valuable and the one most likely to be skipped. It asks how punishing, humiliating, uncertain and scarcity-driven your design is, whether mistakes are recoverable, and whether failure teaches calmly or just slaps the player. FOMO mechanics score badly here. That is not a moral judgement, it is a fit judgement — but it does tell you exactly which part of your audience you are trading away.

Systems and Feelings

Skill: game-design-systematizing-empathizing-audit

This skill positions a design on two axes. How strongly does it reward system-thinking, model-building, prediction, optimization and mastery? And how strongly does it reflect an actual understanding of the player’s emotional reality — frustration tolerance, dignity, expression, humane handling of failure?

The framing is borrowed loosely from Simon Baron-Cohen’s empathizing-systematizing distinction, and I want to be clear that it is used here as a design lens and nothing more.

I built this one because of a specific blind spot, and the blind spot is mine. I mentioned in the Concept Clarity installment that deep down I am still the engineer I was educated to be. I think in systems. Left unsupervised, I will produce designs that are structurally immaculate and emotionally austere. Rules that are consistent, feedback that is legible, an economy that balances beautifully, and an experience that feels like doing tax returns for a very well-designed government.

The skill deliberately refuses to rank the quadrants. Warmth is not weakness. Rigour is not quality. A cold optimizer’s game can be magnificent. A structurally soft, emotionally generous game can be magnificent. What kills designs is not the position, it is the accident — landing somewhere without meaning to, and then being confused about who bounced and why.

So the output ends on a question about intentionality. Lean into this position, add a counterweight on the weak axis, or stop pretending the design is for everyone. All three are respectable answers. Pick one on purpose.

Who Else Is Watching

Skill: game-design-player-segment-perception-audit

This one comes straight out of live ops scar tissue.

Here is a situation that anyone who has worked on a mature F2P game will recognize immediately. You ship a feature for your elder players. It is good. It is exactly what they asked for. It goes into the update video, the store page, the patch notes, the social posts. And then your midgame players, who cannot touch it for another four months of progression, watch the whole thing and quietly conclude that the game is no longer being made for them.

Nobody did anything wrong. The feature was correct. The targeting was correct. The visibility was not.

This skill audits a feature by who will see it, not by who will use it. It separates the target audience from the visible audience, maps how new, midgame and elder players will each read the same announcement, and diagnoses the mismatch between what gets hyped and what is actually reachable.

It pays deliberate attention to the middle cohort, which in my experience is the one that gets structurally ignored. New players get onboarding attention because their numbers are scary. Elder players get content attention because they are loud and they spend. Midgame players get neither, and they are the pipeline that produces your elder players in the first place.

The recommendations are usually about framing rather than about the feature itself. Narrow the communication. Give the non-target segments a small companion value. Adjust the unlock path. Reduce visible hype for inaccessible content. Aspiration is a powerful motivator, but the gap between aspiration and resentment is smaller than most roadmaps assume.

Who Is This For?

Skill: game-design-player-persona-extractor

The last skill in this pack is a returning guest. It also appeared in the Concept Clarity bundle, and I put it in both deliberately, because it does two different jobs depending on when you use it.

In the clarity pack it answers the question at concept stage: given this design, who would love it? Here, in the audience pack, it works as the summary layer. After you have run motivation, needs, values, archetypes, traits and segments, you have a large pile of analysis. The persona extractor compresses that pile into an ideal player and an anti-persona.

The anti-persona is the part people skip and the part that earns its keep. Naming who your design is not for is uncomfortable, especially in a room where someone is hoping the answer is “everyone.” But a persona that could fit almost any game is too weak to guide a single decision, and the fastest way to sharpen one is to state the specific mismatch. Not “people who don’t like games.” Rather: wants predictable progression, but this design thrives on variance. Wants low-pressure comfort, but this loop demands constant optimization.

There is also an optional demographic layer, which only activates if you explicitly ask for it. This is on purpose. Behaviour first, demographics second, and only when you need publisher-facing or market-facing framing. Age brackets and territories are useful for media planning. They have never once told me how a feature should work.

Conclusion

Nine skills, six or seven overlapping frameworks, one underlying question. Who is this for, and what are we actually asking of them?

You will notice these skills contradict each other sometimes. Bartle will say your feature is Achiever-heavy. The granular taxonomy will split that into Competitive Achievers who love it and Steady Advancers who find it exhausting. Big Five will tell you the same feature demands high conscientiousness. SDT will tell you it runs mostly on introjected regulation. All four readings are correct. They are looking at the same object from different sides.

That contradiction is not a bug in the pack. It is the entire value proposition. A single framework gives you an answer. Several frameworks give you a shape.

Make no mistake, none of this replaces user research. These skills reason about your design, not about your players. They cannot tell you what people are doing in your game and they will happily produce a confident, well-structured, beautifully formatted analysis of a feature that your actual audience would ignore completely. If you have real data, real playtests, real interviews, feed them in. The skills get dramatically better when they have something true to chew on.

What they are genuinely good at is catching the thing that is very hard to catch from the inside. Every one of us has shipped a feature that hit its numbers and left the players slightly worse off. Streak pressure. FOMO windows. Obligation loops dressed up as engagement. Nobody sets out to build those. They accumulate, one reasonable decision at a time, because the dashboard cannot tell the difference between a player who wants to be there and a player who cannot afford to leave.

Not all engagement is equal. Some systems motivate. Some merely trap. It is worth knowing which one you are building.

Key Takeaways

  • Engagement is not a single substance. Two features with identical metrics can produce completely different player experiences. The dashboard cannot tell you which one you built.
  • Ask the disappearing reward question. If the reward vanished, would the player still do it? External motivation is fine for activation and terrible as a foundation.
  • Fun is need satisfaction, not a vague entertainment label. Autonomy, competence and relatedness are the practical test of whether a design nourishes or merely occupies.
  • Use several lenses on purpose. SDT, Bartle, the granular taxonomy, Big Five and the systematizing-empathizing axes will disagree. That disagreement is the useful part.
  • Behaviour leaks values, but ambiguously. Any value inference without a confidence level attached is overclaiming. Watch especially for values your own design has blocked.
  • A feature is experienced by everyone who sees it, not only by those who can use it. Target audience and visible audience are two different things, and the midgame cohort pays the price when they are confused.
  • Serving one player type strongly is fine. Pretending to serve all of them is not. Narrowness is a legitimate design choice as long as it is a choice.
  • The anti-persona is the useful half of the persona. Naming who the design will frustrate does more work than naming who will love it.
  • These skills reason about the design, not about your players. They are a complement to user research, not a substitute for it.

Links

This series

Platforms & repository

My previous writing on these topics

Frameworks referenced

]]> <![CDATA[AI Skills for Game Design — Creative Ideas]]> https://stanislav-stankovic.medium.com/ai-skills-for-game-design-creative-ideas-fbd58f81362f?source=rss-5c3f0bb4eddc------2 https://medium.com/p/fbd58f81362f Mon, 22 Jun 2026 14:01:02 GMT 2026-06-22T14:01:02.235Z

This text is a fourth 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:

In the previous installment of this series we assumed that you already have a concept that you would like to analyze. The set of AI design skills presented there is designed to help you evaluate the concept that you already consider implementing. But what if you are not quite there yet? What if you still don’t have a proper idea?

As a game designer you quite often face this challenge. You need to come up with something and are not quite sure what. Ok, granted most game designers are teeming with ideas, but we are not talking about ideas in general. We are talking about ideas that are supposed to solve a particular problem.

Quite often you are given a mandate, come up with a new feature for an Update 85, make it fun, and make it make money. Yeah, right. Or let’s come up with a feature that our players that play our Tournaments but don’t like to lose would enjoy. Or let’s motivate players that upgrade only their Tanks to also upgrade their Healer characters. Sounds familiar?

Lucky for you we now live in bright new age of AI and the next set of skills is here to help you!

Included in this batch are the following skills:

  • game-design-brainstorm-methods
  • game-design-option-generation
  • game-design-five-options
  • game-design-roadblock-reframing
  • game-design-ideal-outcome-backcasting
  • game-design-transformative-reuse
  • game-design-molyneux-lens
  • game-design-one-thing-to-remove
  • game-design-creative-unblocker

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.

In what follows, I will present what each of these skills is meant to do and how it is meant to be used.

Brainstorming Methods

Skill: game-design-brainstorm-methods

Brainstorming sessions are a staple of every game development studio. Every creative team has them. They can be especially exciting times, where new ideas are gushing out of everyone present and no one is allowed to shoot any idea down. Glee and idealism permeate everything and only sky is the limit. Fun times.

However, brainstorming sessions are notoriously hard to organize. First of all, you need a critical mass of people. Doing brainstorming alone defeats the purpose, but in a team already working on a project, relevant people are often busy. We have all been in this situation. Playing calendar tetris and trying to find a suitable slot for everyone to partake. It is not just about finding a slot in everyone’s calendar. The slot also needs to be of the suitable size. Brainstorming can’t happen in half an hour. Even an hour can make it feel cramped. Finally, time spent in the session itself is not the only thing. Participants need to be in the right frame of mind. Context switching is a mind blocker and creativity killer.

I am not going to advertise that you should use AI to replace your brainstorming sessions with actual living people. No. What I am going to propose is that you can use it to augment your current methodology. In the time that it takes you to organize one super valuable high quality brainstorming with your actual team, you can in parallel run a multitude of quick brainstorming sessions with your AI companion. These two things don’t exclude each other. They can compliment one another.

Asking AI for ideas suffers from the same problem as asking a random person for ideas. The initial output that you will get will tend to be superficial. This particular skill is designed to make AI deliberately mimic some of the best known brainstorming methods. In the same way methodologies force humans to think in a specific way, so do LLMs. The output is supposed to be more meaningful.

This skill implements nine well known methods, each with a defined output pattern:

  • SCAMPER — a method mutate an existing feature through Substitute, Combine, Adapt, Modify, Put to other use, Eliminate, Reverse/Rearrange.
  • How Might We — that is designed turn fuzzy problems into sharp opportunity prompts.
  • Crazy 8s — that forces fast volume and variation in eight quick directions.
  • Six Thinking Hats — structured discussion making across separated lenses (facts, emotion, caution, optimism, creativity, process).
  • Brainwriting 6–3–5 — intended to generate many ideas in parallel without one voice dominating.
  • Worst Possible Idea — that is designed to invert deliberately bad ideas into useful principles to break fixation.
  • Forced Connections — a method that injects novelty via random or adjacent stimuli.
  • Lotus Blossom — a method that expands one central concept into adjacent branches, then branch those.
  • Morphological Matrix — a framework that defines design dimensions, then systematically combine them into new concepts.

I am not going to go into details of each of these methods, as this is not the intent of this text. Instead, if you are interested in knowing more check out the associated links.

This skill is best applied if you give it enough context. If you have a project defined in Claude and enough documentation related to your game it should have enough understanding to provide you with the quality output, if you point it towards a specific outcome. If you do not yet have the predefined context be sure to provide as much of it in the prompt.

Generating Options

Skills: game-design-option-generation

While brainstorming skill is focused on producing ideas, the next set of skills are focused on trying to find solutions to a particular problem.

The first skill in this set is an anti-tunnel-vision tool. Its whole reason to exist is captured in the working principle: don’t confuse the first decent answer with the best available direction. You point it at a design problem when you suspect the solution space got narrowed too fast — a feature, live-ops idea, UX problem, economy issue, or design challenge where the team is circling one favorite answer and hasn’t seriously considered alternatives.

Please note that this skill is also a part of GROW methodology. You can read more about this method in one of my early texts. It literally is the “O“ in this method extracted for individual use. The intent is to frame the problem, produce three to five credible solution paths, lay their tradeoffs side by side, then recommend.

The emphasis on credible matters — this isn’t the weird-idea skill. We are not after volume. Every option is supposed to be a real, defensible way forward, not filler to pad the list.

The generation step gives you five lenses to pull options from, and the intent is to mix them so the set isn’t all variations on one theme: Five-options (compare ideas already on the table), Obstacle (imagine the main blocker gone and derive paths around it), Ideal outcome (backcast from the best player-facing result), Transformative reuse (adapt or extend what already exists), and Outside-the-box (force in at least one non-obvious option). Several of those lenses are themselves standalone skills you have — this one is the lightweight version that reaches across them to assemble a comparison set quickly.

The comparison step is crucial. Each option gets a summary, strengths, weaknesses, likely player effect, implementation burden, and strategic fit — that consistent shape is what lets you actually weigh them rather than just admiring a list. And the recommendation isn’t forced into “pick one” — it explicitly supports sequencing: test one now, hold one in reserve, discard the rest.

The next four skills in this set are essentially components of the first part of the main skill.

Skills: game-design-five-options
This skill produces exactly five genuinely distinct directions (not five flavors of the same idea), evaluates each on the standard grid — summary, strengths, weaknesses, player impact, implementation difficulty, strategic fit — and recommends the best immediate choice plus the cheapest version to test. Working principle: there’s almost always more than one viable answer, so make the alternatives visible.

Skills: game-design-roadblock-reframing
Is meant to be used when a single blocker has grown mentally larger than the whole design space around it, and discussion keeps collapsing into “we can’t because.” The move: name the blocker honestly, imagine it vanished overnight and ask what you’d actually want to build then, then derive realistic ways to approximate that unblocked state without magic — a partial version, an adjacent solution, a substitute mechanism, or a sequencing change that bypasses it for now. It’s explicitly not about denying the blocker; it’s about using its absence as a lens to find paths around, under, or over it. The working principle of this skill is don’t let one obstacle define the entire design space.

Skills: game-design-ideal-outcome-backcasting

Start from the destination, walk backward. It is meant to be used when the end-state is easier to picture than the path to it — you know the experience you want to create but not how to structure getting there. You define the best believable player-facing result (treated as a design tool, not a wish list), identify the conditions that must be true for it to exist, then retrace milestones, prerequisite systems, and sequencing dependencies back to today, and finally separate what must happen now from what can wait or be prototyped first.

Skills: game-design-transformative-reuse
Sometimes the smartest move is transforming what the game already has rather than building something new. You define the new purpose, inventory reusable materials (existing features, UI patterns, content pipelines, currencies, progression hooks, social surfaces, underused systems), then explore how each could be adapted, extended, recombined, or simply returned to serve it. Each path is weighed on player-facing freshness, implementation effort, systemic fit, risk of feeling derivative, and long-term flexibility. The discipline is in that “risk of feeling forced” check — it’s reuse for leverage, not lazy recycling.

What Would Molyneux Do?

Skill: game-design-molyneux-lens

The problem with AI generated ideas is that they tend to drift toward a safe middle ground. This can also happen with human ideas. We do tend to gravitate towards a beaten path. We do like to follow northern stars and established patterns, especially when we are pressed with realities of game production. Self-censorship and creative laziness tend to set in. They are creativity killers.

The next skill is designed as a circuit breaker for this pattern of thinking. It is designed to deliberately call you on your bullshit. It will identify the bits of your design where you drifted towards the bland safety, point dinger at them and ask you provocative questions. It is ambition-injector — a deliberately provocative critique lens, not a neutral audit. It’s modeled on Peter Molyneux-style overstatement, and the move is right there in the opening line: push a design slightly past good taste, then drag it back to something buildable.

The output runs in six beats. It judges the core fantasy (is it clear in one sentence, would a player care emotionally and not just mechanically, is it distinctive or just a genre placeholder), issues a safety callout naming exactly where the design is timid, sanitized, or forgettable, then fires 2–3 strong provocations — bold, high-upside pushes, each tied explicitly to player fantasy and the behavior or emotion it unlocks. Crucially it doesn’t stay abstract: it writes magic moments as concrete retellable scenes (“the moment the village remembers what you did,” “the moment your pet disobeys because you trained it badly”). Then comes the grown-up half — a reality check that honestly flags what’s hand-wavy, over-scoped, or technically dangerous, and a minimal viable magic step that reduces each promising direction to the smallest buildable version that still carries the spark.

The Magic of Simplification

Skill: game-design-one-thing-to-remove

You can usually tell when a feature proposal was created by a game designer without any restraints. We love systems. We love intricate details. We love sets of rules. We, unfortunately, tend to overdesign things. Sometimes the best game design is the simplest one. Sometimes you make things better by removing something.

Our next skill is designed to do exactly that. It tries to identify the one thing to remove with the highest leverage, i.e. the element whose absence would most improve the design, be it in terms of clarity, pacing, focus, emotional impact, usability, production efficiency, or strategic coherence.

The output walks a consistent arc: read what the design is actually trying to do, name the single removal candidate (a mechanic, a progression layer, a UI step, a rule, a reward type, a content dependency, or a feature that muddies the fantasy), then justify why this cut beats all the others. Then it explains the mechanism of improvement — not the lazy “it becomes cleaner,” but specifically what gets better: comprehension, pacing, motivation, readability, strategic clarity, production sustainability, onboarding burden, player trust, emotional focus. It honestly states what you lose (a good cut still removes something useful), offers a value-preserving alternative — a lighter substitute that keeps the upside without the problematic whole — and ends on a verdict: remove now, prototype without it, or keep for now and cut if testing confirms.

Fighting the Creative Blocks

Skill: game-design-creative-unblocker

The last skill in this bunch is my favorite. It is a deliberately weird one. It is meant to be used when rational design thinking has turned to sludge and another sensible framework would just deepen the rut. It is based on my Oblique Strategies for Game Design modeled on Brian Eno / Peter Schmidt-style Oblique Strategies. Oblique strategies are prompts that don’t solve the problem directly but knock it loose.

The intended trigger is a specific kind of stuck: a feature, mechanic, live-ops idea, UX flow, FTUE, economy layer, or prototype that feels stale, overthought, equally uninspired in every direction, or trapped in circular discussion. Not “I have no ideas” so much as “I have ideas and they’re all dead.” If you reach for it when you actually need divergence or evaluation, you’d be better served by the brainstorm or option-generation skills — this one is for disruption, not coverage.

The flow is short and intentionally non-linear: name the stuck point (and crucially, diagnose which kind of stuck — no ideas, too many half-formed ideas, or inability to choose), draw 1–3 oblique prompts from its deck, force an honest interpretation of each in your actual context, turn those into sideways directions (cut, exaggerate, invert, randomize, simplify, resurrect an old idea), and end on one salvageable move worth testing.

The working stance is the important part: playful, mischievous, slightly disruptive, but still useful. Prompts are nudges, not commandments — not every one will fit, and that’s by design.

The skill explicitly tells you not to dismiss a prompt just because it sounds stupid; the discipline is to take an absurd prompt seriously for ten minutes and steal the useful part. A non sequitur that exposes a hidden assumption has done its job.

Conclusion

The skills in this batch live at the fuzzy front end of design — the part before you have anything worth auditing. The previous installment assumed you already had a concept on the table. This one is for the moment you’re handed a task and the page is still blank. That’s a different kind of problem, and it needs a different kind of tool.

What ties these nine skills together is that none of them hand you a finished answer. They impose a way of thinking. The brainstorming skill forces structure onto idea generation so the output isn’t just the shallow first pass any LLM gives you by default. The option-generation bunch tries to widen the solution space before you commit to the first decent answer. The Molyneux lens drags the design off the safe middle ground that both AI and tired designers drift toward. One thing to remove skill reminds you that subtraction is design too. And the creative unblocker is there for the specific misery of having ideas that are all dead on arrival.

Make no mistake. This isn’t a replacement for a room full of your actual teammates. It’s an augmentation layer. While you’re still playing calendar tetris to schedule one good human brainstorm, you can run a dozen quick AI passes in parallel — and walk into that human session already armed with raw material. The two don’t compete. They compound.

Key Takeaways

  • These skills are for ideation, not evaluation. Reach for them when you don’t yet have a concept — when you’ve been handed a problem and need to generate, not judge.
  • Give the skills context. A defined project with documentation produces far sharper output than a cold prompt. If you don’t have that context loaded, put it in the prompt yourself.
  • Brainstorming skills augment your team; they don’t replace it. Run quick AI passes in parallel with your real human sessions and use them to compound, not substitute.
  • Don’t confuse the first decent answer with the best direction. The option-generation skills exist specifically to fight tunnel vision and keep the solution space open.
  • Insist on credible options, not volume. The five-options approach wants genuinely distinct, defensible paths laid out on a consistent grid — summary, strengths, weaknesses, player impact, implementation cost, strategic fit — so you can actually weigh them.
  • AI drifts to the safe middle. That tendency is the whole reason the Molyneux lens and the creative unblocker matter — they push past bland competence toward something memorable.
  • Subtraction is design. Sometimes the highest-leverage move is removing one thing, not adding another.
  • Take absurd prompts seriously for ten minutes. The creative unblocker only works if you resist dismissing a weird prompt as stupid and instead steal the useful part.

Links

This series

Platforms & repository

Brainstorming methods

Related reading

]]> <![CDATA[Has Data Driven Design Failed Us?]]> https://stanislav-stankovic.medium.com/has-data-driven-design-failed-us-84247eac5ba5?source=rss-5c3f0bb4eddc------2 https://medium.com/p/84247eac5ba5 Sun, 24 May 2026 19:49:06 GMT 2026-05-24T19:49:06.133Z I started my game design career in the industry at a very interesting time. It was the summer of 2012. About a month after I joined Rovio, Supercell released Hay Day. Free-to-play was swapping the mobile platforms. Soon after many of the best known and most successful games on mobile sprouted. Candy Crush Saga, Clash of Clans, etc. Game as a service wasn’t anymore something reserved for gigantic MMRPGs like World of Warcraft or EVE Online.

The whole transition brought something new and interesting, the notion of telemetry data and consequently with it the idea of data driven (or at least data informed) design. To me, fresh out of academia, the idea felt appealing. Ok, now we have a tool to anchor our decisions not only into intangible things such as intuition and personal tastes but in something that we can objectively measure.

The pendulum of creativity swung from art more towards science. Or so the manta was.

The promise was simple: by introducing objectivity into the design process we would be able to make better design choices and ultimately make better games, ones that would be more fun for players and as a consequence make us tons of money.

Over the next few years the same line of thinking, same business model and same design philosophy, like an inevitable flood drenched other platforms and game genres, from AAA on consoles to indie games on Steam.

Almost a decade and a half later and our industry is facing one of its biggest crises. (And no, do not blame AI, this one is on us) Maybe it is time to take a look back and see if that promise really panned out.

Where Are We Now

My beloved Helsinki, once a powerhouse of free-to-play mobile gaming, the place that gave birth to some of the most influential companies in this market, the place where so many of the ideas of data driven design have been pioneered, is struggling to produce a consequential game. It has been 6 years since Metacore launched Merge Mansion, arguably the last of the really successful titles, more than 8 since the launch of Brawl Stars by Supercell, 9 since the launch of Empires & Puzzles by Small Giant games. My own EA has not launched a successful mobile game since Galaxy of Heroes in 2015.

It is not for lack of trying. There have certainly been many valiant efforts. Supercell’s own Squad Busters is a recent example. It is also not for the lack of talent and expertise. Most of the people that created those gaming giants are still on the scene, still passionately working on the new designs.

Well what is the problem than? I will argue that at least part of it lies in our decision making and the way we treat the data.

Lego House

I am deliberately going to start my discussion by evoking the data LEGO metaphor that made rounds on LinkedIn for ages a year or two ago. It being LinkedIn fodder notwithstanding, what I found most egregious about it was exactly this last bit, the jump from ordered bricks to a LEGO house. I hate the presumptiveness of it, but I think it illustrates, spot on, where the key problem lies. That pile of bricks, even nicely arranged, could have been as easily transformed into a LEGO dinosaur, or LEGO airplane or any number of other LEGO creations. The bricks don’t change. Their interpretation does! The story around them is what makes all the difference.

In the similar way, the data doesn’t change. The way the data is presented and interpreted changes. This is the crux of the problem. Data by itself does not remove subjectivity from the design process. It shifts it into a corner, a particularly well fortified corner, hidden behind the wall of numbers.

Let’s see why this is so.

Looking Back

By its very nature data is backward looking. Someone needs to actually perform an action before we can register it as a bit of data. A player needs to buy an item, or equip a piece of gear onto a character, or simply open a particular UI. This means that our data is a window into the history of the player’s behavior.

This is the crucial distinction. What we try to do when we do data driven design is extrapolate on the existing data. We try to predict how players will behave in the future, and not only how they will behave if we don’t change the game, but how they will behave if we intentionally introduce the changes into the system.

Good mathematical models have predictive power. If we know enough about the system we could theoretically model it and predict its behavior under different circumstances. This is in general very hard. It is relatively easy for relatively simple systems.

Think about a Match-3 game with a linear level progression. If for example 5% of players abandon a game because they are stuck at Level 35, making that level a bit easier, perhaps by giving players 5 more moves will very probably ensure that now only 3% players are abandoning a game at that point.

This is, alas, much more complex in the loosely coupled non-linear systems which in-game economies of many other games. Good luck in predicting player behavior will change if you nerf a particular card in Clash Royale.

Furthermore, the data records actions, but not intentions. As my data analyst friend likes to say, the data can tell you what players are doing and not why they are doing it. The player psychology is a key factor in player behavior. This needs to be taken into account when extrapolation on existing data. Some of it can of course be tackled by means of behavioral economics and probabilistic modeling, that in itself can add an additional layer of ambiguity in the process.

These are two key points where the subjectivity lurks in the data driven design process. This creates an interesting situation. The data driven process still remains subjective, yet we keep treating it as something objective. Which in turn leads to several malignancies.

Consequence 1: Micro Optimizations

Some things are easier to measure and model. Take a typical FTUE of a game. Gameplay is usually pretty predictable at that point. Most often this part of the player’s journey has the strongest guide rails and the player is guided down a relatively linear path. Changes introduced there usually have immediate effects that can be efficiently measured in a matter of days. This is usually where data driven design shines.

The reason for this is that the complexity of the modeled system is relatively small, data can be obtained quickly and it can be handled efficiently.

You can AB test the hell out of your special offers, balances of progression curves, rewards in the premium pass and similar streamlined systems. This is arguably the biggest value a design team can derive from a data driven process. Evidence that this works is all around the industry. Billions made over the last decade and a half are a testament to this.

However, this approach can lead a team onto a slippery slope of micro optimizations. The team becomes really good at optimizing small changes, moving buttons, changing reward quantities, tuning timers, smoothing funnels, improving participation, reducing friction, adding reminders, optimizing offers, etc.

Inevitably this leads to a chain of outcomes. Time gets eaten up on endless AB tests about minute changes. Each new round of optimization leads to diminishing returns, as the game gets hyperoptimized. The game ends up beings seen as a sum of independent parts that can be optimized independently.

Most importantly, the big questions do not get answered. Is this game still exciting? Is this fantasy still alive? Are players emotionally invested? Are we building something players will talk about? Are we creating new desires, or harvesting old behavior?

As bad as it is, this consequence of relying on data is by far the least detrimental one. At least you end up with an optimized game. It may not be able to evolve out of its current economic niche but at least it will die as a very advanced type of a dinosaur.

Consequence 2: Game As A Problem

As we mentioned already, the key idea of data driven game design is to raise the quality of decision making. Ideally the data should tell us what in our game works and what doesn’t. It should tell us what we should expect if we make a certain change to the game and finally it should evaluate how close we were to our intended goals once we made that change.

In theory this should not be controversial. In practice, however, things seem to work a bit differently. Again ,the problem is not in the data itself. The problem is in the mindset of the people. When we put things in this perspective, we are naturally driven to see things as problems to fix. Our game becomes a set of problems, or in (slightly) better case opportunities that need to be addressed.

This would be all well and fine if we were making office software. However, we are not. We are trying to build a piece of entertainment. We are building something that is supposed to delight the people. Above all we are making something that people do not even know they need. We are not solving a problem for users. We are bringing new quality to their lives.

Sure, you can do all sorts of metal gymnastics and say that we are solving a problem of boredom, or some such. But this doesn’t address the question of the creator’s mindset, and, I will argue that this difference in the mindset is where shovelware originates.

Consequence 3: Analysis Paralysis

The previous trap that I discussed applies mostly to managing the already existing live games. The next one applies equality to both existing games and to the launch of potential new titles. It is the famous analysis paralysis trap.

The origin of this phenomenon is not that the teams have too much data that they cannot make sense of. Rather, the origin lies in the way we handle the risk taking within our industry. Making games is inherently risky. Competition is fierce. The audience is picky and fickle. Development times are getting longer and longer. Initial investments are only getting bigger. Still someone needs to make a call. A huge chunk of our corporate structure is organized in a way to achieve two things. Number one, is to minimize the risk. Number two, if number one fails, it is to dilute and disperse the responsibility, to spread it out as evenly as possible to as big a number of people as possible so that no one ends up having to bear the brunt of consequences.

The treatment of the data is part of this system. Typically this boils down to two patterns of behavior. Teams use the need for more evidence to avoid taking responsibility for uncertain creative decisions. If you have ever been in a meeting that ended with, we need more data to be able… you are in a team that is indulging in this pattern of behavior. Find a way to cut this. It never leads to anything good.

Another pattern of behavior manifests itself when approving new games or game concepts. It is searching for a product market fit. What that usually means is that either the idea is too vague to make sense or no one has the courage to take the risk of developing it without some serious hedging.

Unfortunately, analyzing market data is usually not the best predictor of the success of the future game.

Market-fit analysis often asks: What is already working? Which genre is growing? Which audience is underserved? Which mechanics monetize? Which competitors are succeeding? What benchmarks should we hit? These are legitimate business questions, but as a creative starting point, they are dangerous because they point you toward visible demand. Visible demand already has competitors, expectations, genre conventions, CPI pressure, entrenched leaders, and audience fatigue.

Once again, data shows the current or past picture of the market. You will need to guess where the market will be in a couple of years when you release your game. If you make your decisions on the current snapshot of the market this means that you are already late for the party. By the time you release your game, the market will already move into a new direction. The best you can hope for with outstanding execution and operational excellence is to be mediocre in your category. No consequential game has ever been designed starting from a product market fit. To succeed you need innovation and that simply means taking risks!

Consequence 4: Hiding Agenda

Analysis paralysis is a consequence of risk avoidance. But it can also be a consequence of other team level issues. The data is often used as a post hoc justification for decisions that have already been made for various other reasons rooted in the personal agenda.

Data can be used honestly. Here is what we know. Here is what we don’t know. Here is the risk. But it can also be used in another way. The data says no, can quite often actually mean, “I don’t like this idea”, “This threatens my roadmap”, “This is outside our comfort zone”, “This cannot be justified with existing metrics”

These statements are very hard to fight as they are hiding behind a chart, i.e. behind a veil of objectivity. The corrosive part of this approach is, of course, because it avoids dealing with the actual issues behind the decisions letting them pile up.

Consequence 5: Mismatching KPIs

Even if we remove the subjectivity out of the data design process we still have some very hard objective problems that we need to overcome. When monitoring the state of a game as a service we have two very distinct sets of indicators. Ultimately, we want to make money, i.e. to drive a successful business. We want to get as much money as possible for as long as possible.

The high level KPIs are the thing to measure. Things such as revenue, retention, player churn, life time value, ARPU, DAU, etc., etc. These are largely universal things that apply to all games run as a service and indeed transcend games and apply to any sort of application, from Duolingo to Netflix.

The other set of indicators are things that are idiosyncratic to your game, indicators such as engagement with a specific feature, numbers of items of a particular kind, the usage of a particular hero, etc.

We can directly measure both kinds of indicators. However, as designers we can directly influence only the second type of indicators, and not always even all of them! We can only hope that the change that we introduce to the game, and the direct change of game specific indicators, will result in an indirect change in high level KPIs that we actually want.

How do we map influence of game specific indicators to high level KPIs is usually where the discussion between game designers and PMs usually breaks down. As a designer I can tell you about a cool new character I want to introduce, but as PM you want to know how much more gems will be able to sell in the bundle by the end of Q4. We are not speaking the same language!

Conclusions

Data-driven design does not fail because data is useless. It fails when we forget what data is for.

Data can tell us what happened. It can show us where players dropped, what they bought, what they ignored, and what they repeated. But it cannot decide what experience deserves to exist. It cannot imagine a fantasy. It cannot take a creative risk. It cannot tell us what players might love before we build it.

That is still our job.

Data should be the instrument panel.

Not the steering wheel.

]]>