This post was originally written in Italian by Paolo Gambardella. It has been translated by an AI agent and may contain inaccuracies.
Andrew Kelley, the creator of the Zig programming language, opened a talk with an uncomfortable question: who does the software we write actually serve? The talk is called “Don’t Take the Black Pill” and it was made for an audience of developers, not game designers. But it’s exactly the question we should be asking ourselves every time we design a progression system.
A more honest measure than “fun”
Deci and Ryan’s Self-Determination Theory says that a person is doing well — in a game as in life — when three needs are being met: autonomy (my choices matter), competence (I’m improving, and I can see it), and relatedness (I’m not alone). A system can have spotless retention metrics and still deny all three. There’s a name for that too: coercive retention. The progression is there, but the player comes back because a timer is expiring or a notification dragged them back in, not because they actually wanted to.
Coercionware, outside games too
Kelley calls this category “coercionware”: software whose purpose isn’t to serve the people using it, but to manipulate them. The examples he gives don’t come from games — unsolicited push notifications, A/B tests optimising for the click rather than the experience, recommendation algorithms chasing engagement instead of value. What struck me is that he frames all of this as a design choice, not a side effect. Someone, in a meeting, decided this was fine.
The same problem, different name
In games we call it other things: gacha, limited-time events, season passes that pile on the pressure. But it’s the same mechanism: autonomy is taken away to guarantee a return. I wrote about this last week when talking about dopamine and oxytocin — the relatedness in Self-Determination Theory is, at the end of the day, the same conversation as oxytocin. A player who comes back to spend time in a world or with other people doesn’t need to be held in place by a timer.
A useful habit
There’s a simple habit I use when evaluating a new feature: play devil’s advocate with myself. Assume it fails, and ask why. The list of reasons usually includes things like “it confuses the player” or “it doesn’t convert well enough.” It’s worth adding one more: it fails because it manipulates instead of serves. That question doesn’t come up on its own in a roadmap meeting. You have to ask it deliberately, before you ship.
The next time a feature improves the numbers, the right question isn’t whether it works. It’s whether the player chose it — or got caught in it.