PART 04 OF 04

What Actually Happens During Pre-Production

What Actually Happens During Pre-Production
Photo by Leuchtturm Entertainment / Unsplash

Why you usually only hear about a game once it's already past pre-production — and what actually happens before that: the first idea, the design document, and why a rough prototype matters more than polish.

As a gamer, you've probably heard plenty of times that some big, well-known game is "in pre-production" — and that this means you shouldn't expect real news for a long while, let alone the game itself. The reason comes down to one word: uncertainty. Pre-production is the studio's testing ground, the stretch where trial and error rules, and where leads and investors make the calls that decide whether a game is worth pursuing at all. Even though you'll often hear about big titles being "in pre-production" all the time, the truth is that in the vast majority of cases, the public only learns a game exists once it has already moved past pre-production, with most of its key features locked in. That's also why you occasionally hear about an unreleased version of a game that got scrapped in its earliest stages — like that strange, never-released Call of Duty prototype set in ancient Rome.

The Idea and the First Concepts

I'll walk you through the usual sub-stages of pre-production. The first, and in many ways the most important, is the initial idea — turning a general concept into something concrete. A huge part of any game's success comes down to the strength of the idea sitting behind it, the one that eventually gets delivered to players as a polished game.

Pre-production is tied to one word: uncertainty. It's the team's testing ground, and the point where leads and investors decide whether the project is worth pursuing.

It's rarely that simple, though. Getting to a genuinely strong idea sometimes means running through the whole pre-production process more than once, just to properly test how good your first instincts actually were. This stage starts by putting early, half-formed thoughts down on paper. Usually, to communicate the director's and writers' vision more clearly, the team sketches out a handful of concept pieces and puts them together with some early descriptions into a single document — enough that anyone reading it can grasp the core idea behind the game. It's also common, right at this point, for ideas that looked great in someone's head to lose a lot of their shine once they're actually written down.

The Game Design Document

If you make it through that first stage and still believe in your idea, the next step is putting together a game design document, or GDD. Here, designers lay out the game's functional and technical details in full, and write them into the document. Almost every lead across the different departments contributes to it, working to agree on everything from big-picture choices — art style, the overall story — down to smaller details like specific systems and mechanics.

The GDD isn't set in stone, but the core, conceptual parts of it usually don't change for the rest of development. It's also not something written in one sitting at the very start — some sections get filled in later — but enough of it needs to be locked down early on that no department is left waiting on a decision that blocks their work.

There's no fixed standard for a game design document, but there's a rough minimum, and it varies with the size and genre of the game. A GDD might include sections like:

  • Title page
  • Table of contents
  • Design history
  • Part 1: Game overview
  • Part 2: Gameplay and mechanics
  • Part 3: Story, setting, and characters
  • Part 4: Levels
  • Part 5: User interface

The GDD deserves its own set of articles on its own — this is just enough to get you familiar with it.

There's no fixed standard for a game design document, but there is a rough minimum, and even that varies a lot depending on the size and genre of the game.

Beyond outlining the game itself, the document also sets the standards for how departments work together. Take a 3D model, for example: getting one from concept to fully implemented in the game takes several stages and several different people. If the software isn't chosen carefully, or one department's output doesn't match the next one's expected input, the team ends up burning time just fixing compatibility problems — wasted time and wasted people. That's why, alongside the gameplay and story details, a GDD's technical section spells out the constraints and standards each department needs to follow, along with how they hand work off to each other. Even something as specific as the audio format the sound team should export in gets defined here, since not every engine supports every format.

Prototyping

Once the design document is in reasonably good shape, it's time to actually test your idea in practice. Plenty of ideas that still sound great on paper turn out to be a lot less exciting once they're actually built. That's why prototyping has become one of the main things studios — especially on bigger games — base their decisions on.

An early prototype, sometimes called a vertical slice, is a small, stripped-down version of the game that lets you actually see its gameplay and its core systems in action. It's usually built in a short window — a few months at most, even for a big game — and typically covers just one or two rough, playable levels stitched together.

Building one still means designing and modeling parts of the game and implementing its core gameplay and mechanics, but you don't need to build everything to a finished standard. At this stage, teams lean heavily on shortcuts and quick, deliberate hacks to get through the process as fast as possible, since you might need to go through several rounds of prototyping before you land on a version of the idea that actually works. That deliberate hackiness usually means not worrying much about things like optimization, since you know that once the prototype proves itself, you'll get to handle all of that properly during real production.

You might need to repeat the whole prototyping process several times before you land on a genuinely strong version of your idea.

If you've seen the documentary Indie Game: The Movie, you'll remember that Jonathan Blow built the first prototype of Braid in about a week, in an extremely rough form — and once he realized the idea actually held up in practice, he committed to it and spent the next three years building it out. That's a pretty clean example of exactly why the prototyping stage exists.

So my advice: get your ideas down on paper first, and work out the different angles of it with the rest of your team. Then, without getting bogged down in anything non-essential, put together a first version of your game as quickly as you can. Just make sure your vertical slice actually touches every major system in the game — otherwise it won't tell you the truth about how good your idea really is. And expect to repeat the whole cycle more than once before you land on something genuinely solid. Prototyping does cost its own time and money, but it always saves you from wasting far more of both later — treat it as insurance for your project's success, never as wasted effort.

Next time, I'll move on to the production stage of building a video game.

Alien
Alien

Alien is a software engineer, full-stack developer, and software architect. Passionate about Node.js, TypeScript, and Golang, sharing insights on web development and software architecture at aien.me.