Ten years of games, one real lesson

Super Mario Bros. is forty years old and people still argue about the jump, not about the story of the Mushroom Kingdom. That is the correction a long stretch of design analysis keeps handing back. The games that feel settled in memory are usually settled because of one action the player performs hundreds of times, not because a premise was clever on a slide.

The obvious reading of a long study of games is that you come away with a catalogue: ten lessons, eleven fixes, a genre map. What actually sticks is a habit of distrust. A mechanic is not good or bad on its own, a difficulty mode is not a moral position, and an enemy that seems clever is often just an enemy that refuses to die. The rest of the notes are examples of that habit, taken from games that already shipped.

The first thing a decade of design analysis teaches you is that nobody arrives knowing how games work. The people who look like they do have simply been wrong in public for longer.

Part of that is scale. Design spans mechanics, level structure, difficulty and accessibility, player psychology, genre convention, production constraints, and the pile of surprises that only shows up once the thing is playable.

But a handful of ideas keep coming back, whatever the game and whatever the year. Compressed into ten, they look like this.

What the player can do is what the player feels. Setting and plot dress the experience; the mechanics are the experience.

Compare Far Cry 2 and Far Cry 4. On paper they are near twins: a civil war in an invented country, a magnetic villain, camps to take, dangerous wildlife, and two shared words in the title.

Play them and they are not alike at all. Far Cry 4 runs like a blockbuster because ammo is plentiful, enemies can be tagged, and an outpost you clear stays cleared. Far Cry 2 grinds because guns jam, vehicles die, malaria interrupts you mid-plan, and a bad fight can throw you back to the last save station.

Same premise, opposite feeling, and the difference lives entirely in what the game gives you, what it takes away, and where it pushes back.

A mechanic is only ever right or wrong relative to a particular game. Asked whether high scores and leaderboards still belong in modern games, the honest answer is that it depends on the game.

The same feature can carry one design and sabotage another. That goes for scoreboards, for lives, for fixed cameras, for run-based progression, and for nearly every choice on the list.

Two instincts get designers into trouble here. One is bolting a mechanic on because it is what everyone is shipping. The other is throwing one out because it smells like the past.

Neither instinct answers the only question that matters: does this feature push the player toward the experience you are building?

Design for a defined audience, not for yourself. Judging a game purely by whether it suits your own taste produces weak criticism, and it produces weaker design.

Insomniac's first Spider-Man is the case study. Its web-swinging asks very little of you: hold a button and Manhattan flows past, with physics assists working quietly underneath to smooth the arcs and keep you off the sides of buildings.

To a player who loves movement systems with a punishing skill ceiling, that reads as a missed opportunity. But that player was never the brief. A blockbuster superhero game has to hand a very wide audience the feeling of being Spider-Man within minutes.

Seen that way, the assists are not a compromise. They are the design hitting its target.

Pick the players you are building for, then tune the mechanics around what those players can do, want, and will understand without being taught.

Choosing a target audience does not mean writing everyone else off. Layered optional content lets a single game hold a beginner and an expert at the same time.

Nintendo does this routinely in modern Mario games. Families and first-timers can reach the credits, while the players who want a fight go looking for the extra coins, the brutal bonus stages, and the secret worlds stacked behind the main route.

The split is what makes it work. The critical path stays gentle enough to protect the broad audience; the optional path is where mastery gets tested and paid.

You end up with one game that stretches across skill levels without diluting what it is.

Accessibility and authored difficulty are not opposites, as long as the game is clear about what it intends. A hard game can earn its fear and its triumph through struggle, and still let a player change the terms.

Celeste shows how. It is an exacting precision platformer with an unusually broad Assist Mode, and the framing does the heavy lifting. Before you turn anything on, the game tells you plainly how it was built to be played. Then it lets you adjust anyway.

That matters for players who are new, players with disabilities, players who came for the story, and anyone else the default settings were not shaped around.

Difficulty settings and accessibility options do not have to erode intent. The work is in steering each player to the version that fits them while being honest about the shape of the original.

A genre describes a resemblance, not a specification. Players will argue forever about what counts as a roguelike or what makes a soulslike, and those arguments are more fun to have than to design from.

The danger is treating a label as a checklist lifted off one famous game. Copy the list and you get releases that feel interchangeable before anyone has finished the tutorial.

Plenty of games chasing Dark Souls fell into exactly that. Souls as currency, bonfires, the healing flask, the recognisable furniture, all present, with little sense of why those parts held together in the first place.

Hold the label loosely instead. Add things, drop things, cross ideas over, and keep returning to the experience you want to produce. A genre is a place to start, not a set of walls.

Enemy behavior is judged by the play it produces, not by how convincing it is. There is no Turing Test to pass here.

A guard, a rival, a squadmate, a simulated townsperson: each of them is there to serve the experience. Sometimes that calls for cleverness. Often it calls for something else entirely, such as being readable, exploitable, theatrical, unpredictable, or simply consistent enough that the player can form a plan.

Behavior that feels uncanny in play is usually assembled from far simpler parts than players assume. The craft is in the arrangement, not the sophistication.

The strongest answer to a hard design problem is rarely the deepest simulation. It is whichever version gives the player the better moments.

You cannot evaluate a game in your head, because your head is a poor simulator. Ideas run flawlessly in the imagination and nowhere else.

The mushy controls, the dead thirty seconds between the good bits, the rule nobody parses, the exploit the whole thing collapses into: none of that is visible until the game exists and somebody plays it. The fastest way to find out whether a design works is to get a build running and try it.

Treat that as good news rather than a warning. A large share of the best ideas in any game arrived during production, as a bug worth keeping, an unplanned interaction, or a mechanic that quietly outgrew the pitch it started as.

Until a prototype has proved it, an idea is still a guess.

Playtesting is how a designer learns what a game is actually communicating, which is why it belongs at every stage rather than at the end. Even a working prototype is broken in ways its author is the last person to notice.

Players get lost. They misread controls, overthink the simple puzzle and undercook the hard one, bring assumptions nobody anticipated, and walk routes you were sure were sealed.

Design is largely problem solving, and the loop is short. A mechanic produces behavior, testing shows whether that behavior matches the intent, and then the mechanic, level, tutorial, interface, pacing, or reward gets adjusted until the result comes out right more often than not.

You are building for other people. Other people have to be in the game early, and often.

The last lesson is that none of the others is permanent. Tools move, audiences move, the industry moves, your own taste moves, and sometimes the conclusion was just wrong.

So hold all of it provisionally. Mechanics shape experience, but a different audience may need different mechanics. Genres help until they harden. Accessibility widens a game, but only when it is framed with care. Prototypes tell you things, and you still have to read them correctly.

Collect as many design lessons as you can, then check each one against the game in front of you. The creator playing the build is the test that settles it.

The designers who last are not the ones with the tidiest set of rules. They are the ones who keep building, keep watching players, and change their minds when the evidence tells them to.

Pick one lesson and put it on screen before you collect the other nine. In the Flockbay app, describe a single room whose only job is the verb you care about: a jump, a shove, a shot that also moves you. Approve the brief, play the room, and throw the room out if the verb is not the thing you notice. A list of lessons will not tell you that.

A 2D platformer template is enough for a jump. An AI platformer maker is the place to ask for the room.