The GD-1 is the first phase of the DGD process; in traditional game development it roughly approximates to the conceptualization stage of production. The purpose of the GD-1 is to obtain Clarity of Goals and Constraints and to start obtaining Clarity of Assumptions, as well as getting buy-in from every discipline and every stakeholder. The GD-1 is meant to be done quickly and dirtly; it doesn’t have to be pretty, but just get the point across. It is normal to have multiple iterations of it, so we don’t want to spend too much time on it. At the same time, we want to start with the broadest possible diversity of ideas, so we can then start narrowing it down.

A slide deck with a collection of one-page mockups or explanations of different core designs

Pitch presentation to the team or team leads.

In most cases, this document is still too unrefined to showcase to extrernal stakeholders. We must first make sure that every discipline has given the concepts a greenlight and that none are raising any red flags.

1. Identify the Seed
2. Identify the Mandate
3. Identify the Target Audience
4. Identify the Stakeholders and their Expectations
5. Identify the Project Constraints
6. Come up with several potential game options
7. Identify Benchmark games/media
8. Present to leads

Identify the Seed

The seed is the spark from where the project comes from. These sparks can come from anywhere, from a new business opportunity that suddenly opened up, to the inspiration that came from watching a good movie. It is important for us to clearly identify where the idea for the game came from, independent of the gameplay itself — the gameplay will change and evolve as we make the game, but the seed is constant. Projects can take a long time, and it’s important to never lose sight of where they came from.

Identify the Mandate

The mandate is the reason why you’re making this game. It can be commercial goals (i.e. “We need to make $200k next quarter”), artistic intent (i.e. “I want to make a game about an immigrant coming of age in the late 90’s), or any other reason. It is crucially important to have this written down and discussed with the rest of the team; this will be the bar with which every decision will be ultimately measured

Identify the Target Audience

For professional game developers, most of the time we make games for someone other than ourselves. As hard as it is to divest our own interests and preferences from the game we’re making, it is a fact that is important to remember. Making decisions through the lens of who we’re making the game for becomes A LOT easier if we take the time to consider who our player will ultimately be.

Ideally this would come from market research, but in the rough & tumble of game dev; careful research is hard to come by. Instead, game designers have to do their best with their own research and categorization. Tools such as Bartle’s player types, personas and Quantic Foundry’s Player Motivations can prove really helpful in determining this.

Identifying the Stakeholders and Expectations

The stakeholders of the game can vary wildly. Of course there is the developer and publisher; but there might also be IP holders, clients, platform holders and the community (or communities) of players themselves. Every group or entity that has something to win by the success of the project is a stakeholder and they each have different expectations, goals and mandates. The success of a project relies on every stakeholder working harmoniously, even with different objectives, so it pays to take some time and think about who they are and what they get out of the project. This will help communicating with them and getting their buy-in when time comes to make tough desicions.

Identify the Project Constraints

Every project is constrained by reality; we don’t have infinite anything in order to finish a game. It is important to identify these constraints and mold the design around them, as this gives us the best opportunity for success. Constraints come in many forms — there are the three constraints from the production triangle: Budget, time and scope; but a project can have other constraints as well, for example if it needs to use certain technology or if the client demands a certain genre.

Come up with several potential game options

This is the meat of the GD-1. After all the previous aspects have been identified and noted, we get to start coming up with game ideas. The trick here is to come up with as many different game ideas as possible, as varied as possible, but in line with the goals and constraints planned above. Crucially, it is also important that all the ideas you eventually present to the team are ones you’d be happy working on…. you don’t want to get stuck with a project you don’t believe in.

Come up with as many ideas as you can and then reduce them to ~5 good ones. Try to include games that are as different from each other as possible within the constraints. Right now you want to cast a wide net and see where the stakeholders and team want to take the project. You also want to be fast in coming up with the ideas; we want to discard the bad ones and define a direction as quickly as possible. You shouldn’t spend more than a few days on this step.

Personally, I like to create one concept slide for each idea; this is a slide in a deck that includes an image/mockup/diagram of the game and a few bulletpoints that give it more context.

Identify Benchmark games/media

For certain ideas it is easier to include your inspiration in the deck as well; benchmark games and media are the reference points we’ll use to make sure people understand our game proposals. If the game uses many reference points add them broadly; there will be time to dig deeper into them while presenting.

Present to leads

Once you have done all this research and finished the deck with game options, you’ll want to present this to the discipline leads and producer of your team. Their job is to raise any red flags either from their department’s capabilities or from the business/client perspective. Amongst all of you, after some discussion, you will select which idea is the one that would work best.

It very well can happen that all ideas get rejected; what’s important is to learn what works and what doesn’t. If all get rejected go back to the drawing board and make a few more. It can take a few rounds but, as long as you get constructive feedback from the team, you’ll get there.