Hello Classy Bogan Community and welcome to Part 1 of my guide on taking your GDD to the 'Next Level!'
Today I'm going to be talking about the first thing anybody sees when looking at your GDD, the summary.
So why is the summary so important? What does it do?
Well as I mentioned before the summary is the first thing ANYONE sees when looking through your GDD. This includes not only your team but also potential clients and investors / stakeholders. The summary section of a GDD is your first, and sometimes your only chance to show clients and the rest of your team your understanding of your project. It's crucial to get your summary right prior to delving into the rest of the GDD because if your summary is wrong than you will more than likely need to rethink the rest of your GDD too.
So here are some of the most important elements you should include in your GDD.
A list of requirements
If your working with a client or investor, they have more than likely given you a brief of the project, this can be verbally or written. It's incredibly helpful to have these requirements listed at the beginning of your documentation so that the whole team understands the goals your aiming to achieve with your project.
However, if your not creating a project for a clients goals, think of why you or your team want to be undertaking this project. Is this to help you develop a specific skill set? Maybe create the greatest VR game every developed? Is your goal to frighten the unfrightenable? Or maybe just to create a more casual game to help pass the time.
Your list of requirements should contain all the goals you wish to achieve within that particular project.
The Elevator Pitch
Alright. So now we know what goals we want to achieve with this game. We can now say how we are going to achieve them, to do this, I personally like to think of it as my elevator pitch; A very short, high-level description of your project that is designed to get people hooked on your idea.
Try and address as many of the above goals in your 'List of Requirements' as possible. Don't worry you don't need to justify anything in the elevator pitch that comes later.
An elevator pitch can become so much more exciting if you place the reader into a situation, for example, if your pitching a game with the goal of creating 'a spaceship themed escape room', you can write something along the lines of:
"Imagine for a moment you are a drift in space in a one man vessel and oxygen is running out. Your surrounded by flashing buttons, levers, and switches. with your limited time you must find a way to send your distress beacon before your time runs out!"
This 'Elevator Pitch' is good for a few reasons, first of all, it gets the reader intrigued by placing them directly into the situation. Secondly, it addresses the goal, "you are a drift in space... Buttons, Levers, switches... find a way." These words and phrases help identify that this is indeed a space themed escape room. Lastly, it gives the reader an understanding of the type of things you will need to do in the game and informs them on what type of game it is, for example: "One man vessel" suggests single player. "Before time runs out" suggests a time limit, and "buttons, levers, switches" suggests that you will be using buttons, levers, and switches to achieve your goal of "[finding] a way to send your distress beacon".
At this point in the summary you've got the reader hooked, you're both on the same page in terms of the projects goal(s), now it's time to talk about some specifications, what device are you building for? Is it VR? Is it mobile? Console? Who is your target audience? How old are they? What similar games do they play? How much time do they have? How much experience do they need in terms of gaming or even specifically the headset or genre before playing this game?
It's important to specify this as it will influence your decisions and justifications for those decisions when it comes to the mechanics, audio and art style within the game. For example you don't want to be telling a client that their space themed escape room is going to have hyper realistic graphics but also run on the Sega Mega-Drive as this isn't possible with the hardware limitations of the console.
On the other hand a client might ask why you are developing the game in low poly art style. You can use things like your target audience and your intended console to back up that "young people using mobile VR for the first time don't mind a low poly art style", as well as the fact that a less intensive art style better caters for the systems limitations.
Now it's time to start describing the mechanics of the game, at this point you should know the goal of your game, the client should be hooked on the concept, and you should know who and what you are making the game for.
To describe the mechanics you don't want to be going into too much detail on the specifics of how they work at this stage, you simple want to be clearly stating what the player will be doing.
To use the space theme again it should look something along the lines of:
"players will use gaze controls to look at an interactable object, such as a switch or a lever, for long enough to activate it. This will change the flow of power within the space craft. Once the player has activated the correct combination of interactable objects the distress beacon will have enough power to activate and the player will be saved, winning the game. Some interactable objects will require power to be routed to them before they can be activated. If a player tries to activate an interactable object that doesn't have enough power it will give them a form of feedback, but wont activate.If the player fails to solve the puzzle in time the screen will fade in a blinking motion and the player will be shown a game over screen"
More in depth and a little lengthier than the elevator pitch the mechanical description describes exactly what the player will be doing and how they can succeed and fail this will be longer and shorter on different projects but everyone who reads it should still leave with the same understanding of what the player will be required to do.
Here you will be writing about not only about the art style but also about the mood you want the game to portray.
When talking about the art style it's important to not only choose an art style that is going to fit the system you will be working with and the people you will be making the game for but also to pick art style that works with your art team and is possible for them to complete within the time frame, budget and/or other limitations you may have.
However before you decide on art style you want to be sure of what mood you want to the player to feel whilst playing the game. In our example today I want the player to feel calm at the beginning but feel more and more pressured as time goes on.
I've already mentioned my low poly art style and gotten the A-OK from my artists so now it's time to discuss colour pallet, this doesn't have to specify exactly what colors you'll be using right now (that is done further along in the document) but it does have to give the reader enough of a picture in their head that they can visualize what the game will look like in the end.
For the example project, we want to be starting with a pallet of cooler colours such as whites, greys, blues and greens to place the player in more of a calmer environment to begin with. We also want to have reds and oranges that will start to become dynamically more prominent as the game continues to place the player under more pressure. How this will look in the document will be something along the lines of:
"This game will be using a low-poly art style as it works best within the projects limitations and also assists in placing the player in a sense of security from the get go as the simpler shapes of low poly are immediately less intimidating than something more realistic, it's important that the interact able assets within the game stand out more than the others, drawing the players attention, and should feature an element of colour to represent their use. the game will be going with flat coloured textures within a cool blue and white colour pallet to initially keep the player relatively calm, the game will also feature a more intense red and orange colour pallet to signify urgency, this will dynamically become more prominent within the game as the time limit runs out"
As you can see, the artistic description can become rather lengthy even with a simpler game, if your not sure if it portrays the right message, give someone who doesn't know what your game should look like the description and ask them to draw, write or describe what they think you mean in your description, if it matches your intention, your good to go!
The format of the artistic description also applies to the audio, you want to be saying the same thing in terms of how you want the audio to make the player feel, make sure you've mentioned audio when looking back over your game as audio is one of the areas many developers forget about when creating their documentation.
Finally, the last thing you need in your description is a step by step process of how your game will play from when the player starts playing the game until they finish it, restart it, lose it, etc.
One really easy option for this part is to create a game loop. Its a small diagram that details what the player will be doing within the game in the form of a flow chart, for these kinds of diagrams you should be a little vague as your describing the games process not any one particular level.
As you can see in the diagram I don't go into details in terms of what buttons the player will be pressing to solve the puzzles of each level. Simply that button pressing will be the core way that players will interact with the puzzles. it's good to also be putting in what the player will be doing outside of finishing one level. In this example, players will progress to a harder level if they succeed or they will be encouraged to try again if they fail.
If your game is a little more complex than this it also helps to have a written description of what the player will be doing to support the diagram. In the description you can also add different milestones and describe how the player will be feeling in each one.
After this you should now be able to take the summary of your GDD to the "Next Level!" In the next part I will be talking about Asset Lists and how they are more useful than you might think!