Pre-production tells you what you're building. Production turns that plan into something you can actually play. Testing is where you find out whether any of that actually holds up once someone other than you touches it — and, more often than you'd like, whether it holds up even when you touch it with fresh eyes.

Here's the uncomfortable part almost every developer runs into: you already test your own game constantly while building it. You play it every day, tweak a value, replay the same three levels a hundred times. And yet, once real testers get their hands on it, they find problems you walked right past for months. That's not carelessness on your part — it's what happens when you're carrying the entire mental weight of a project. You know the game so well that you unconsciously work around its rough edges instead of noticing them. A tester with no history with the game has none of that instinct, which is exactly why they're useful. Be ruthless about what they find. The market will be just as ruthless, and it won't explain itself the way a tester will.

That ruthlessness usually gets organized into two well-known milestones: alpha and beta.

An alpha build is the first version of the game where the core loop actually exists — the main gameplay is in, the art is in, you can genuinely sit down and play it. What separates it from beta is that it's still incomplete. Some systems are missing, some are placeholder, and a fair number of the planned features simply aren't there yet. It's also, almost by definition, full of bugs. That's fine — the point of an alpha isn't to look finished, it's to give the team a real, honest read on how the core of the game is coming together, so leads can decide what still needs to change before locking anything in further. Alpha testing is usually kept small and controlled: internal team members, or a short list of invited players, not a public release.

Minecraft is the odd exception that shows how loose that word can get. Notch sold the game directly to players while it was still labeled "Alpha," years before anything most studios would call a finished product existed — and a huge amount of what made the game what it is today came out of that period, shaped directly by the people who'd bought in early and kept telling him what felt wrong. It worked because the core loop — dig, build, survive — was already strong enough to be fun on its own, even surrounded by missing features and rough edges. That's not a strategy I'd recommend copying blindly, but it's a good reminder of what an alpha is actually for: proving the center holds, everything else can wait.

Beta comes after the alpha's problems get fixed and the rest of the planned features actually get built. At some point you hit what's usually called a code freeze — no more new features, no more structural changes, just fixing what's broken. That's the version that goes out for beta testing, and depending on the game, that might mean a small closed group again, or it might mean opening it up publicly, the way most big multiplayer games do now. The goal at this stage isn't finding out whether the game works — you should already know that — it's catching whatever bugs slipped through and, just as important, balancing the parts of the game that only reveal problems once a lot of different people are actually playing them at once.

Cyberpunk 2077 is the example the industry still brings up when this stage gets rushed. The PC version held up reasonably well, but on base PS4 and Xbox One it launched buggy enough that Sony pulled it from the PlayStation Store entirely, and refunds went out to a huge number of players. The problem wasn't that CD Projekt Red didn't test the game — they clearly did, extensively, on the platforms it ran best on. It's that testing across the full range of hardware players actually owned got squeezed by a schedule that had already slipped more than once, and the version that suffered most was the one that got the least testing time.

A few things worth building into your own process, whether you're a two-person team or a hundred-person studio:

  • Track every bug in one place, with severity and the exact steps to reproduce it — never rely on someone remembering a conversation from three weeks ago
  • Test on the weakest hardware you plan to support, not just your own dev machine
  • Keep testing throughout production too, not just in two big blocks at the end — the earlier a system's problems surface, the cheaper they are to fix
  • Bring in people who've never played the game before you open it up publicly; their confusion tells you things your own team has stopped noticing

None of this replaces good production work, but a great production phase can still ship broken if testing gets treated as an afterthought squeezed into whatever time is left. Budget for it the same way you'd budget for art or code.

Next time, I'll close out this series with the last stage: publishing — how a finished game actually gets in front of players.