The GD-4 is when production starts. After the kickoff meeting at the end of GD-3, the team should have buy-in on all the different Clarities. This doesn’t mean that the Cone of Uncertainty is completely closed however; just that its outer limits are now well defined. This is where nuts and bolts game design occurs: levels are mapped out, players stats designed and enemy difficulty curves balanced. As opposed to other phases, where we work towards a specific deliverable, in GD-4 we have a constant stream of deliverables based on the nature of the project, all the way until the game ships. For the same reason, exactly what these deliverables are can change wildly based on the project. Here are the ones I favour, but check out the Tools section to options work best for you.

  • Feature briefs
  • Detailed Design
  • Playtesting
  • Balancing
  • Polish

Meetings and presentations.

For certain documents, such as Feature Briefs, I like to shop them around representatives of each discipline before presenting them in a meeting. This allows them to give you really candid feedback one on one, and adjust the design before showing it to everyone.

Feature Briefs

Feature briefs are small documents that explain a submodule of the project. They are meant to be a high level overview of the specific systems and describe the expected behaviours and components. You should avoid, however, going into details of the variables associated to these components. For example, in a feature brief, you would mention the types of weapons a player could wield and how they work, but you would not mention the exact damage, ammo capactiy, reload speed, etc… A good way of thinking of it is that the feature brief should have enough information to get the Engineers, Artists, Audio, etc.. started on working on the feature; but not enough to balance it.

You can find all the details on feature briefs here.

Feature briefs should always be presented to the team that will be implementing the module, as they are the ones who need to have a clear understanding of it.

Detailed Design

Once a feature brief has been approved by all team members, we can go into detailed design. This is where the specifics of the submodule are set; what this means highly depends on the submodule we’re talking about. Detailed level designs, balance curves, parameter & variety matrices are just some examples. This design should be enough for a Designer to be able to balance the mechanics and systems.

Detailed designs are generally too in-depth to be presented and mostly consist of various documentation. Make sure to send your designs to anyone who needs that information; but if you send it to everyone it might be overwhelming. It is better to check at the end of a feature brief who needs what and send it only to them.

Often in projects there will be a mid-project lull for design. The modules that were required for the game have been designed and now we are waiting in implementation. At this stage it is important for design to stop making new designs and start playtesting, balancing and polishing. Remember, every new feature you design creates more work for everyone; so we only want to design the minimum necessary to create the best game our team can make.

Playtesting

Playtesting is a huge topic into itself, and you can learn more about different playtesting techniques in the tools section. For now, it is important to remember that playtest is a continuous process, and that you should not wait until the end of the project to do so. There are multiple types of playtests, and during a GD-4 you will go through several as the project matures. Early on feedback from designer tests and internal playtesting would help guide and iterate the design, while later on usability test and external playtests will help you see how players react to the game. As soon as there is some implementation you can start these processes.

Remember to keep a good record of your playtest questions & results. The game will change based on feedback and it is often useful to go back to them to discover why you made certain desicions.

Balancing

With detailed design in hand and playtesting validating it, you should be looking to fine-tuning the gameplay. There is however, no such thing as perfection and, to be honest, we’re not trying to get the perfect balance as much as make an engaging experience. In my experience, the best approach is to timebox different waves of balancing and fine-tuning. So for example, give yourself a week to balance, then wait some time while the game is more complete, and then give yourself another week to do it again. The game will always be evolving, so you won’t get a “final” balance until near the end of the project, but that doesn’t mean you can’t get closer little by little.

Polish

During the whole production it is important to constantly play the game you’re making. It is only until the later stages of the GD-4 where you get to be nitpicky about it, though. As mentioned up top, we want to make sure that the game has a solid foundation and all systems are built up to MVP standard before trying to reach beyond.

What does polish look like? For starters, that’s where all the scope breakdowns of the created in feature briefs come into play. If there is additional time, resources and budget it is time to pick the most important modules and take them to he next scope phase.

Another option is to add a juicyness pass to the game. Juice is the term for all the bells and whistles (VFX, art, animations, SFX, etc… ), that make the game feel more impactful to the player. It doesn’t affect gameplay or functionality, but it can add a ton to the overall game experience.

If the GD-4 encompasses two phases of standard production, why not keep them separate them in DGD? In real production there isn’t a clear cut moment where production stops and balancing begins. It is better for the design team to continuously balance the game, in as much as possible,  to where the current features are then to wait until they are all implemented. This way, if the game developments gets sped up or has to be cut short, there will be no mad rush at the very end to balance things.

Next GD-5