This article was originally published on Game Production Lab, January 5th, 2022.

Pre-Production is arguably the most important phase in game development. It’s when you understand what to build, how much effort it will cost, what is fun or not about your game. However, most Pre-Productions I’ve seen in my career are messy, ineffective, and almost pointless. Many teams still think this early stage is about creating concept art for the game – and maybe prototypes. But they are not even clear on what prototyping means; they simply start creating the game without actually prototyping, that is, testing mechanics, validating hypotheses. Truth is, the majority of the teams have an idea for a game, start creating concepts and code, and call this Pre-Production. Is that it?

This article intends to support the idea of what exactly you should take out of Pre-Production, and why that is the case. By being extra clear and intentional about this initial phase of development, it will most definitely save your team countless hours of pain, confusion, demotivation, and crunch.

What Outcomes To Expect?

I believe Pre-Production must achieve three things for your team: validate what’s fun about your game via prototyping, generate clarity on how to build it via pipeline definition, and grant easy access to relevant and up-to-date information via smart documentation. Many teams will think of creating concept art and prototypes, but will disregard the crucial effect pipelines have on the projects and people, and most documentations become obsolete by the time you finish reading them. We shall also explore some frameworks that can raise the effectiveness of good documentation, and set your team up for a successful Production.

First thing about Pre-Productions is that they should be timeboxed. A producer has to identify and define how long this stage should take, according to the needs and timeline of the project. Naturally, as in everything else, you’re not expecting to be one hundred percent accurate in estimates here; this phase could take a little less time than intended (usually not the case) or more than expected (almost always). Even so, I believe it’s crucial that the team works with a timebox in mind as well as clear outcomes. And as we’ve started to explore, the deliverables should include the Prototype, many times called the Vertical Slice, together with the pipeline definition and documentation.

Okay, so what constitutes a Vertical Slice? You have probably heard this term many times before, and there’s no useful single definition for it. Originally, Vertical Slice is, well, a slice of the game experience that shows you a small piece of everything that is core: art, gameplay, systems. A well-understood analogy is thinking of a slice of cake, in which you have all the different layers in a single slice. If your game is a 2D platformer, a Vertical Slice could be a single level containing art that is close to final, or at least representative of it, and where you have the core systems in place: you can walk, jump, shoot, or whatever it is that is essential to the experience you want to provide for the player. Vertical Slice is the gameplay validation; it’s something you can get in your hands and play that is actually worth considering taking into full Production. Depending on what your project is about, it can get hard to identify what you should include in the Vertical Slice or not. In order to do that, it’s vital that your team is clear on what are the pillars of the game.

The pillars are the core questions or elements that your game lives by. They are the things that you turn to when you need to make key design decisions; if Intense Action is one of the pillars, do you need long, time-consuming puzzles every other room? Do you want the player to constantly stop and read snippets of text in-between fights? If Freedom of Choice is another pillar, should your player be able to move around while talking to NPC characters? The pillars help you make all kinds of decisions for your game. As a matter of fact, losing sight of the pillars is a sure way to make the game lose its identity or add confusion to the systems.

So, get the pillars straight, and then decide what is core and should be included in the Vertical Slice. But alongside that comes the importance of relevant prototyping. When you start Pre-Production, even if you are sufficiently clear about your pillars, you should almost always explore different gameplay scenarios by doing several separate prototypes. You should NOT start by simply creating the actual game from the get-go. Break your game down into its core systems. Then dedicate one or more prototypes to iterate on those systems until you understand what’s actually fun and interesting about them. How should this mechanic work? How should it interact with the other systems?

Each system in your game should be well designed and balanced in and of itself. If crafting is core to your experience, then you should build a prototype focused solely on that – maybe even a physical prototype –, until this part of the experience is as fun as you can make it. That’s why it is so important to add a timebox to your Pre-Production; you can iterate on it forever if you let it, so it’s also good to know when to stop.

Okay, now you know what to include in your Vertical Slice, and that you should not start by simply trying to create the actual game from day one, but instead explore several prototypes to find the fun in each system and their correlation to each other. Now let’s talk about pipelines.

Pipeline What?

I have seen a huge number of teams simply create a prototype, throw in some rudimentary GDD – naturally, the game designer who wrote it is the sole person to have actually read it – and keep creating art and code until hopefully they have a cohesive game launched on time. That’s almost never so simple, and it’s not so hard to figure out why. Games are such a complex endeavor that teams must consider defining (and refining) pipelines as a crucial part of the work. Well, what exactly is a pipeline, then?

In many ways, game development resembles an assembly line – the output of a stage or component is the input of the next one. Before a 3D artist can model a character, a concept artist needs to sketch it. After the 3D modeling is complete, the character will pass on to the rigger, who then passes it on to the animator, and so forth, until the character is fully functional inside the game engine. This sounds simple enough, but it is an intricate process where a lot of things can – and will – go wrong and delay production; that’s why it is so important to explicitly define how the pipeline works, and to constantly improve upon it.

Here is what happens when the team doesn’t come together to think and define the pipeline: the rigger prepares the character for animation. Suddenly, the animator realizes that, in order to properly pose a character, they will need extra bones or a different skeleton structure. And there goes the rigger redo the work. But then he notices that, with the new bone structure, the 3D model will need a different topology to deform correctly. So he signals to the modeler, and there she goes modifying the polygons. See how back and forth that was? Now imagine that happening non-stop, every other week in a project with all sorts of issues. Naturally, there’s no way we can predict every single case that might affect production, but the pipeline definition will guarantee that the most relevant and visible cases are indeed covered.

Additionally, the pipeline definition must make clear what exactly are the outcomes of each stage. The modeler doesn’t just need a character concept in order to start modeling; she needs to know what materials constitute the fabric of the character’s clothes, the specific views (front, side, back), height comparison with other characters or elements in the game, and possibly a lot more. These requirements will constitute the deliverable of the concept artist’s tasks. Likewise, the modeler will need to deliver the character in a certain pose, usually a T or A-Pose, with specific attributes, orientation, and scale to the rigger. Designers need to cover a wide range of cases and parameters when designing features so that engineers know how to build them. These engineers need to compile builds for the QA team with specific requirements, and QA needs to return reports with clear specification and reproduction steps. It’s a loop. Every stage will contain these requirements, or acceptance criteria, that will define what and how should the assets be delivered to the following stage of development.

This sounds obvious. And it is, in a way. And yet we see countless productions fail at realizing and defining the pipeline so everyone is aware of and accountable for it. It’s an ongoing effort. The pipeline should be constantly changed and improved, and the team has to be reminded of it on a daily basis. Make the acceptance criteria as visible as you can; I usually will input them directly on each task as a template that the developers can double-check.

By exploring and laying out the specific pipelines of production, your team will identify and resolve several issues that would certainly cause much rework along the way. Always remember that redesigning or adjusting pipelines mid-Production is much more costly than doing so in Pre-Production, as several systems interrelate and depend on one another.

Gather your team leads and establish all relevant pipelines. These will include the creation of characters, environments, UX, visual effects, animations, text, code, and much more. By the way, programming is one of the most important and complex ones that will require establishing code and technical conventions. Other important parts of the pipeline include folder structure and naming convention – I know you remember anxiously clicking the spaghetti folders duplicated inside the project until you finally found the glorious cube_1850_gray. And it’s a sphere. WTF? So yeah, everyone messing around in the engine should be aware of and accountable for the naming convention of the assets.

So now you’re getting to the end of Pre-Production with a Vertical Slice that was built focused on the pillars of your game, based on several prototypes that were designed to find the solutions for each core system, and you have defined and aligned the pipelines with the team, so people know what they should be delivering at each stage. So, well…

How do you document all that?

In my experience, one of the only ways to guarantee smart, ongoing documentation is to bring the documenting process close to everything the team does. After all, if people are reading the GDD only 3 times during the entire project, would it be so necessary anyway?

Instead, you should aspire to have the team comment, share insights and update the documentation on a daily basis. How do we do that without adding tons of extra work to them? Well, on the one hand, there will necessarily be extra effort involved; that’s part of cleaning the house – and not letting cube_1850_gray sphere live much longer. But the key here is diluting the effort by making it a constant.

GitLab has a very interesting proposition in this regard. You can see their online Handbook that preaches documenting before taking action. That means that writing down the changes you want to make comes integrated in the process of making them.

For your project, you don’t have to document everything first, but you should include, one way or another, documenting as part of the Definition of Done, that is, a feature or piece or work can only be considered complete if the developer has properly documented it in the GDD, TDD, or equivalent. A solution like this will make sure the documentation is always up to date, developers are constantly referring back to it, and it will also facilitate onboarding new members to the team, as documents are more reliable and alive.

At last, you reach the end of Pre-Production, full glamour. You have your Vertical Slice, standing firm on top of your pillars, and ready to be mastered. The pipeline is aligned and empowered, guiding the team. And everything is being properly documented and discussed on a daily basis, not falling in the limbo. Congratulations, you have now guaranteed success in your hands, ready to make millions of dollars! — Yeah, well… sure. Creating a good quality game is just the start of the challenge – but you know that already, don’t you? Fortunately, it’s an incredible challenge, one that fascinates me deeply. So I hope we get the opportunity to talk more about game development very soon.

See you in the metaverse.