A goal without a plan is just a wish.

The first step in making your game is creating the plan.  I cannot stress how important having a plan to follow is and how much more likely you are to finish the project if you have one.

If you’re a solo developer then you might be able to complete a simple game without having anything written down. For larger projects and certainly for people working as part of a team, then having a written plan to follow is essential.

The plan gives everyone involved with the project a point of reference and helps communicate ideas and concepts.

In the games industry these plans are called Game Design Documents (or GDDs for short) and they have been a cornerstone of game development for decades.

Traditionally GDDs are a word processor document, but I find using a Trello board as well makes keeping everything updated easier.  Wikis are also a popular alternative to a written document.

What goes into a Good GDD

What needs to be in the GDD depends on what type of game it is you are making.  It is normal for a GDD to start with a description of the game.  It only needs to be a few paragraphs long and should not contain any technical stuff.  Think of this as your elevator pitch.

If you are going to be pitching your plan to investors or publishers, it would be a good idea to include target audience and targeted platforms, and touch briefly on your monetization strategy next.

The next section should be setting the scenario for your game.  Describe the world, backstory, characters etc.  Obviously, this is would be more in depth in an epic Skyrim style RPG than in a casual mobile game.

Next comes styling, where you can describe themes and appearance.  Again, I prefer using a brief description of how you visualise the graphics, before breaking it down into smaller sections where you are free to describe individual aspects in greater detail.  I like including mock-ups or sketches in this section to really help people understand exactly what I am hoping to achieve.

It is also worthwhile to pay similar attention to the music and sound effects.  Listing any music which needs composing, and special effects which need creating.  It would also be a good idea here to reiterate any relevant information here from other sections which would help whoever is creating the audio.

Gameplay is next.  Start with a brief overview, before breaking each element down into its own section.  You will want to include things like player movement, scoring, win/lose conditions, enemies and how they behave etc.  Depending on how complex the game your making is, this section can get quite large.

Having described the themes and gameplay, its now time for the User Interface/Controls.  As always, start off with a summary describing the theme/aim of the UI, before dividing it up into more detailed descriptions of the individual elements.  I find that sketches/mock-ups of UI layouts can speed up development no end, and gives a head start on developing the user experience before too much of it is coded.

I like to include a more in depth look at your monetization strategy next.  If you are simply looking to sell your game for a fixed amount then this is not so important but is for other business models such as Freemium.

Keeping the GDD updated

As I said earlier on in this post, I find using a Trello board to be a very helpful tool in keeping your GDD up to date and making sure that each member of the team knows what they are doing.

I usually set up the Trello board with the following columns – Bugs/Know issues, Planned tasks, In Progress, Under Review and Completed.  Planned tasks would usually consist of cards made up of the individual points detailed in the GDD.

Each team member chooses there next task from the Planned tasks column, moves it to the in progress column and signs their name to it, then when it’s completed, it gets moved into the under review column for checking.

Progress is discussed in fortnightly meetings and any changes to the GDD can be bought up then.  If the team member needs something clarifying, or if it is decided to change an element or mechanic.

It is usually best that only one team member is responsible for keeping the GDD up to date.

Conclusion

I hope this has helped to explain just how important it is to have a solid plan to follow when developing a game and given you insight into what needs to be included in it.  I’ll be posting some example GDDs later in the week, as well as sharing the GDD for Flappy vaders.

If you have any questions, then either leave them in the comments below, or pop over to the forum and ask them there 😊