The GD-3 is the next stage of pre-production. The goal of this phase is to give enough information to all disciplines in order to obtain Clarity of Implementation. It is normal for Art, Engineering, Audio, Production, etc… to have a lot of questions after the GD-2. They’re probably going to start pointing out many Risks with the project. GD-3 is the moment where we start de-risking stuff proper. Here the process slows down and, depending on the resources available, it might be important to time box this phase.

  • A prioritized Module list
  • Prototypes
  • High-level design documentation

Kickoff meeting with the main stakeholders, where the results are presented.

  1. Create a Module Map
  2. Prioritize the Modules
  3. Create Prototypes
  4. Breakdown the scope
  5. Create additonal design documentation
  6. Organize a Kickoff meeting
Create a Module Map

A Module Map is a tool that is used to define the elements the game requires. This exercise is generally led by either Production or Design, but it is important every discipline participates. At the end of the day, there are certain modules that are only visible to certain disciplines (for example, it’s always Engineering who brings up network security). In my experience, it is better to give team members some time to think of the modules the game consists of and then gather everyone in a meeting to discuss them.

Prioritize the Modules

Once all the Modules and submodules have been defined, we need to prioritize them. We need to prioritize the modules into two separates lists: one based on what is most integral to the game, and one based on how much Risk there is in each module. The order in which aspects of the game are tackled will be a combination of where a module falls in these two lists. In most cases you want to first tackle the core aspects over more secondary ones, and you first want to tackle the riskiest aspects over the ones that are safer. It is not always evident how they will fall; sometimes a core aspect is relatively safe and it needs to be compared with a secondary (but still important) and risky part of the game.

If something is highly risky and not core at all, consider if the project really needs it at all. It might be better suited for a sequel or a different project altogether once Risks can be lowered.

Create Prototypes

Once we have a list of the Riskiest Modules, it is time to start prototyping. In DGD, prototyping is meant mainly to de-risk aspects of the game; not to emulate the game itself. Prototypes take many forms, it all depends on what is needed to de-risk; they can be a paper prototype for mechanics, a stress test for frame rate, a visualization for art style, etc… What is important to remember is that they have to be the minimum necessary to de-risk the issue at hand. They should never be used as part of the production proper; but only as throw away work. This helps us make them faster and not to feel bad, when they fail.

Breakdown the scope

As prototypes and research starts to close the Cone of Uncertainty; it is important for Design to create different levels of scope. The idea here is that cutting game mechanics and systems semi-randomly because time/money is tight is a terrible strategy; this usually leaves gaps in the player experience that make for a lesser product. Instead, a better strategy is to make several incremental designs of the game; each higher scope than the last. You start by designing a minimum viable product, then a quarter scope, half scope, etc. version of the game. Each new version would have more and more complex systems until you reach the full scope version, which has everything. As a designer we want to make sure that each scope version of the game is still a cohesive whole that creates a good experience. If we do this, and develop the game following the scoped order, then we can always fall back to the prevous version if times get tough.

This should not be just adding/removing mechanics; it is often that for a game to work well in smaller scale, some of the secondary mechanics need to be transformed. For example, if the smaller scope version of a game has fewer currencies, then having a crafting system might not make sense and it’d be better to transform it to a shop.

Create Additional Design Documentation

This is also the moment to start digging a bit deeper into the design. Our goal is still to obtain Clarity of Implementation, so exactly what kind of documents vary depending on the needs and uncertainty of the team. Personally I like to make a mechanics map and a player journey, as in my eyes how systems work together and making sure players’ gameplay evolution is guided are always big risks. That being said, depending on the type of project resource loops, rough level sketches, narrative beat outlines, etc… may be needed. We should be wary of going into too much detail at this point however (there will be time for that), right now we want to solidify only as much is needed to make sure the rest of the team knows what will be needed to implement.

Organize a Kickoff Meeting

The kickoff meeting is a very important part of the process. It marks the end of pre-production and the beginning of production proper. At this stage the shape of the game should be well known, there shouldn’t be any large existential Risks left. Now this doesn’t mean there aren’t any unknowns, large part of the design is still left to be done after all, but these unknowns are not large enough to disrupt the overall production of the game.

Next GD-4