What Actually Makes a Game: Mechanic, System, Loop, Feature

Ask someone who has just decided to make their first game what it's going to have, and you usually get a list. Crafting. A day and night cycle. Base building. Four playable characters. Maybe a boss with three phases. It's a genuinely exciting list, and it's the wrong place to start — not because those things are bad ideas, but because a list of things a game has tells you nothing about what the player actually does.

That gap is where most first projects quietly die. Not from bad code, not from bad art. From a developer building twenty good things that don't need each other.

The vocabulary is part of the problem. Mechanic, system, loop, feature, GDD — these words get used interchangeably in tutorials, forum posts and job ads, so it's easy to assume they're five ways of saying "stuff in my game." They aren't. Four of them describe how a game is built out of smaller parts, and one of them describes how the work is cut up. Once you can tell them apart, the question "where do I start?" mostly answers itself.

Four Layers, Not Five Words

Here's the whole idea in one picture:

Mechanics stack into systems. Systems drive the loop. The loop produces the experience. That's the game. A feature is not a level in that stack — it cuts across it, which is exactly why it belongs in your backlog and not in your design thinking. And the GDD sits outside it entirely, writing down what you decided.

Let's go through them properly, because the differences are sharper than they look.

A Mechanic Is One Verb

A mechanic is a single rule the player can act on. It has an input, a result, and nothing else.

"The player places a tower on an empty tile." "Pressing the left mouse button fires the weapon." "Holding crouch makes the character move quietly." Each of these is one sentence with one verb, and that's the test. If you find yourself writing "and then," or "over time," or "which affects," you've stopped describing a mechanic and started describing a system.

Mechanics are also the layer where feel lives. How long the reload takes, how heavy the character feels when they turn, how much feedback the player gets when a hit lands. None of this shows up in a design document as anything more interesting than a number, and all of it decides whether your game feels good in the hand. It's tuned by playing, not by planning.

A System Is What Happens When Mechanics Talk to Each Other

Connect several mechanics with shared state and feedback, so the result of one becomes the input of another, and you have a system.

The clearest test: does it keep running when the player isn't touching it? Does it produce situations you didn't write by hand? An economy where kills pay money, money buys towers, and towers change how many kills you get is a system. An enemy AI that reads a noise value, changes state, and generates a chase you never scripted is a system.

Systems are where a game gets depth, and they're also where solo developers lose entire months. A system is genuinely satisfying to build — it feels like real engineering, it has clean boundaries, and you can keep improving it forever. That's the trap. More on it further down.

A Loop Is the Reason Anyone Plays Twice

The loop is the sequence the player repeats on purpose, because each pass sets up the next one. Every game has three of them running at the same time, and it's worth writing all three down:

• The ten-second loop. Aim, shoot, reload. Move, listen, hide. This is the one you'll do thousands of times in a session.
• The five-minute loop. Scout, expand, defend. Read the wave, place towers, watch, adjust.
• The session loop. Advance an epoch, unlock something, face a harder version of the same problem.

If you can't write the ten-second loop for your game, you don't have a game yet — you have a setting and a wish list. And if the ten-second loop is boring, nothing stacked on top of it will rescue it. No amount of content, story or art fixes a core loop the player doesn't want to repeat.

This is the layer new developers skip most often, because it's the least tangible. You can't see a loop in the project window. But it's the thing every other decision is measured against.

A Feature Is a Production Word, Not a Design Word

A feature is a named piece of work that changes what the player can do. "Fog of war." "Four-player revive." "A new tower type with an upgrade branch."

The test is simple and slightly brutal: can you write a definition of done for it, and finish it in a known number of days? If yes, it's a feature. "Combat" is not a feature, because combat never finishes — it's a system. "Make the game fun" is not a feature either, though plenty of task boards contain something very close to it.

Features are how the work gets divided, scheduled and closed. They cut vertically through the stack: a real feature usually adds a mechanic or two, wires them into an existing system, and changes the loop slightly. That's why "which layer is this feature in?" is a question with no answer, and why designing by feature list is what produces the pile-of-parts problem from the opening.

The GDD Describes All of It, and Is None of It

A Game Design Document is the place decisions live after you make them. It isn't the game, and — despite how it's usually taught — it isn't really a plan either. It's a record.

The most useful habit here is one simple rule: for every paragraph in the document, you should be able to say which layer it belongs to. A paragraph about the feeling you're going for is experience. A paragraph about how resources feed into build times is a system. A paragraph about which C# class holds that state doesn't belong in the GDD at all — that's a technical document.

When those get mixed together, a GDD rots. A section that's part vision, part rule, part implementation detail becomes impossible to update, because changing one sentence silently contradicts another one three pages away. If you're using AI tools to help write or edit your documentation, this gets worse faster, since an agent editing a sprawling document will happily make it self-contradictory without noticing.

The Same Four Layers, Three Different Games

The mechanics change completely between genres. The shape of the stack doesn't.

Look at the middle row. In all three games, the system is the part that keeps running without the player, and it's the part that makes two playthroughs different from each other. That's not a coincidence.

Design Goes Down, Building Goes Up

Here's the part that confuses people, and it's worth being blunt about it: the stack runs in opposite directions depending on what you're doing.

Design moves down. The feeling you promised decides what the loop has to be. The loop decides which systems you need. The systems decide which mechanics you have to write. You start at the top and work down.

Building moves up. You code mechanics first, because nothing else can exist without them. You wire them into a system. Only then does a loop appear, and only then can you feel whether any of it works. You start at the bottom and work up.

Most of the "I'm overwhelmed and don't know what to work on" feeling comes from trying to do both at once. You can't. You pick a direction, and you finish the pass.

So Where Do You Actually Start?

This order exists because each step gives you the information the next one needs. Skipping ahead is what causes rework.

1. Write the promise in one sentence. What should the player feel? Everything below gets judged against this, so it needs to exist first.
2. Write the loop at three time scales. Ten seconds, five minutes, one session. If the ten-second one won't come, keep working until it does.
3. List the smallest set of mechanics that loop needs. Not the ones you want. The ones without which the loop can't run at all.
4. Decide which of them have to grow into systems. A mechanic needs to become a system when it has to remember things, give feedback, or stay interesting for twenty minutes.
5. Prototype the riskiest system first — ugly, and on its own. "Riskiest" means: if this doesn't work, the game doesn't work. Never the easiest thing. Never the prettiest.
6. Cut everything else into features with a definition of done. This is the point where you stop being a designer and start being a producer, and both jobs are yours.
7. Let the GDD follow. Write down decisions after you make them, in the layer where they belong. A design document written entirely before the first prototype is fiction.

The Two Ways First Projects Die

Feature-first. You write a long list of things the game will have and build them one at a time. Six months later you have a working inventory, a working day-night cycle, a working dialogue system, and no game. The signal is easy to spot: you could delete any single feature and nothing else would break. That isn't clean architecture. It means the loop was never there to hold things together.

Detail-first. You go deep on one system before anyone has played the loop. A beautiful twenty-five-epoch tech tree, or a noise propagation model you're honestly proud of, sitting on top of a loop that has never been tested. The system might be excellent and still be completely wasted, because the thing it was supposed to serve turned out to be something else.

Both have the same fix, and it's the most valuable habit in this whole post: build one vertical slice. The thinnest possible version of the entire loop, playable end to end, with placeholder art and one enemy and no menus. Before anything gets wide. Before anything gets deep.

Vampire Survivors is the example worth keeping in mind here. The core loop is almost embarrassingly small — you move, everything else happens automatically — and it turned into one of the most-played indie games of its era. Nobody looks at that game and admires its feature list.

One Question Per Layer

The last practical trick, and the one I'd carry into your next work session. You don't hold the whole game and the fine detail in your head at the same time. Nobody does. Instead, you name the layer you're standing in, and you only allow yourself that layer's question:

• Experience: does this make the player feel what I promised?
• Loop: would the player want to do this again in thirty seconds?
• System: is this still interesting after twenty minutes, without me adding content?
• Mechanic: is it clear, and does it feel good in the hand?
• Feature: can I finish it in a known time, and will I know when it's done?
• GDD: is this written where I'll actually look for it in three months?

When you're stuck — and you will be — say out loud which layer the problem is in. A surprising amount of being stuck is just trying to answer a loop question with a mechanic answer.

This is part of the Building your first game collection, which walks through the whole path from an idea to a released game. If you haven't read the articles on the game design document yet, they pair directly with this one — this post is about which layer a decision belongs to, and those are about where you write it down.