As you’ll figure out while reading the process, DGD focuses on discovering and solving issues with the design of a game. Our first order of business then is to start getting clarity on what is to be done. However, this clarity can be divided into five aspects which would need to be discovered in order.

Clarity of Goals — First off, we need to have a good understanding of what we are trying to achieve with our game. This can be abstract (i.e. We want to experiment with this new technology and push its boundaries) or concrete (i.e. We need to >$500K revenue after year 1 of release); it’s all fine as long as we have a very clear idea of why we’re making the game.

Clarity of Constraints — Once we know the why, then we need to know what opposes us. A constraint is any limitations to the scope of the project. These generally include human resources, budget and time; but can also include other constraints based on the project (for example new technology, game engine restrictions, IP licenses, etc…)

Clarity of Assumptions — Assumptions are an important part of the DD process; we all have them and usually they go unnoticed. It is necessary to take a step back and list out what your assumptions are at the start of a project. These can range from your target audience, to the gameplay to factors outside of your project (for example if you’re expecting a grant to come through). One of your key tasks throughout the project is to validate these assumptions and make sure they are real.

Clarity of Vision — After listing out our assumptions, we need to define the vision of the game. The vision is what the game is about in a nutshell. We want to be able to boil down the experience we are trying to create to its essense. In other words, this is the what of the project.

Clarity of Implementation — Finally once we know what and why; we can take a look at the how. At the start of a project, there are generally a lot of unknowns, this is called the cone of uncertainty. This uncertainty will prevent your team from knowing how everything will be implemented. This is normal and ok; what’s important is to have in mind what are the biggest unknowns and how to reveal them. As you learn more about the project, tech and gameplay, the cone will shrink and your path of implementation will become clearer.

It is important that, when defined, each of these is written down and discussed with the rest of the team or, if the team is large, the leads of each discipline.