Following last month’s first edition of Making a Game, which covered the starting point of a project with the High Level Vision, we’re moving onto the next main point of call – the Game Design Document, usually abbreviated to GDD.

To help explain what a GDD is, and why it’s important, we’ve chatted with two people from the Lawn Mowing Simulator 2 team – Game Director Rick Payne, and Lead Designer Dan Scollie, who have over 30 years of game design experience between them… so who better to ask!

Setting it Up

As we learned in the last article, the High Level Vision (HLV) contains a lot of top-line ideas that will ultimately define the intentions for the game’s creation – but it’s not enough to really understand whether or not it will all hold together once it’s in development.

In order to get to that point, once the team has completed and agreed the HLV it’s over to the Design department for the next chunk of work.

“While the HLV is great at explaining the vision of the game, it doesn’t have enough detail to actually know how to make the game,” says Rick. “The HLV gives you all the bits, but it’s then to the GDD to figure out how they all go together and what is linked to what.”

“It’s meant to be written by the design department and intended for the wider team to use in order to check how features and mechanics are intended to work,” adds Dan. “It’s also the place where ideas are noted.”

All the Questions

As the name of the document suggests, there’s a lot of upfront thinking that needs to be laid out and interrogated – and this isn’t just to provide reference material for the time. It’s also crucial in creating a sensible and efficient development process, and Rick explains:

“As a designer I’ve often looked at the GDD as a way of the designers solving 90% of the game’s potential problems before the rest of the team ever get to see them.

“This is the skill and craft of a game designer – they create a design for a feature or mechanic and then need to ask hard questions about it,” he adds.

These questions will vary depending on the element of design under scrutiny, but some good examples are:

• “How does this system affect these other systems?”
• “How can the player break this or exploit it?”
• “What tools or abilities do design need in-engine to balance and tweak this feature?”

“Game designers love to find edge cases that break a feature, even if those are features they designed themselves,” continues Rick. “It’s only by writing a detailed GDD for that feature that a good designer will find these edge cases and then be able to update the design in order to avoid them.”

Breaking it Down

So what are the key sections of a GDD? This might vary from game to game, but essentially every single aspect of a game needs its own section, so that the chances of overlooking something is minimised.

For LMS2 the list would fill multiple screen pages, explains Dan. “Since our design documentation is feature based, it’s essentially a list of all of the features of the entire game – even those that didn’t make the cut for project scope reasons.”

“It’s not all text either,” expands Rick. “Designers will use whatever is the best option to get the information across, whether that’s words, diagrams, flow charts, tables, and so on. Different mechanics and parts of a game’s design are best explained using different information.”

But one of the most important elements is making sure that sections and features are linked together – because within a game’s design, the way that one thing works will inevitably impact multiple other things too.

“Every aspect of the game gets a section,” says Rick. “I always started them with broad headings and then as it was filled in this would break down to more subheadings.

“A big part of writing and managing the GDD is making sure that the elements are linked to anything else they overlap with, to ensure that the reader can easily see what needs to be considered.”

Taking the Time

Since the GDD is a crucial step in the process of ensuring coherency for the project, it’s not something you should rush – and in many ways the GDD is never really ‘finished’. And in terms of the time it takes, this will be dependent on the size and scope of the game it’s being created for.

“For the original Lawn Mowing Simulator game I wrote it all in a month,” says Rick, “but that was a lot of work – pretty much all my available time during that month. And then there are edits and updates to it afterwards as development starts or scope changes.”

Once development is underway, referring back to the GDD is generally a daily process, and it’s the design team’s responsibility to ensure that anybody else contributing to the document does so in a way that’s consistent – otherwise things can very quickly get messy.

It’s also important not to only rely on what’s in the GDD when communicating key ideas, though.

“It’s often not good enough just to provide the documentation,” notes Dan. “It’s generally a good idea to also talk people through the design intentions to make sure that what is implemented will follow that intended direction.”

For really small teams – even one-person studios – it’s tempting to feel that spending a lot of time on a GDD isn’t really necessary. But there are some cases, such as working with a publisher, where it’s a requirement – because in the end, the GDD is just an excellent way to convey a lot of key information!

***

That wraps up our look at the Game Design Document – hopefully you found it useful or interesting! Next on our list of topics to tackle is the Pre-Production Phase, so don’t forget to check back in the coming weeks!

Meanwhile, a quick reminder that we’re building up to a Kickstarter campaign for Lawn Mowing Simulator 2. It’d really help us if you’d consider becoming a Follower or even sharing the campaign to your own network!