Unfortunately due to the nature of design documents I am unable to show current examples of my design documents, however, I can walk you through my process and how I use certain tools to construct and develop design documents.
The design process I follow changes depending on individual projects, this is primarily due to the fact that games take so many different forms and some ideas are easier or more fun to flesh out in different ways.
There is, however, a particular component that determines how I go about initial design, and that is whether I have an initial idea or not.
I use rapid prototyping when I need to come up with an ideas to further flesh out.
There are a number of options to accomplish this from the simple “brainstorm session”, to my favourite post-it pick n mix.
This involves picking a couple topics of a game you want to focus on, genre, art style, input method, platform, target demographic, theme, anything you want to focus.
For each of your topics you randomly write 6-10 ideas on their own post-it and number each one.
Now the fun part! we roll dice!
Roll a dice for each topic and take the post-it with the resulting number and put them all in a pile, continue until you have a number of piles.
Now this method will generally result in very strange and random ideas and indeed will produce some rubbish, however it can yield incredible ideas you may never have thought up otherwise and you will almost always come away with an idea, be it something that comes up in a pile or something inspired by one of the piles.
Now, this is very much not the best method in the world and is most definitely not the only method I Implement, it’s just my favourite and can be a lot of fun!
Creating Developed Designs
Once I have a solid idea for a game I will begin work on the design document.
Again, design documents will vary depending on the project, and industry folks know there is no standard when it comes to design docs.
When I start with a design document I focus on two things, theming and blocking
For example, For Ballerina Battle Arena, the main themes are Dance and Fighting.
Once the major themes have been defined they can be used as the foundation for everything else, and this is were blocking come in.
Keeping these themes in mind you can block out all major aspects of the game in very basic terms, for example….
Characters and enemies
What does the theme tell me about the characters?
They are dancers, and they are fighters, both of these are very physical activities, they are both rhythmic and both can be choreographed, this presents a very obvious solution to simply meld the two together, each character will have they’re fighting moves based on the dance discipline they follow, e.g. break dancers use a lot of spinning based attacks etc, this provides a huge amount of real world reference, and as you research this reference it can result in ideas and moves you may not have thought of before, it also provides a good amount of variation whilst still keep a consistent theme within the world.
What does the theme tell us about the levels?
As we’ve just established we have all these enemies that are based on dance styles, this presents the opportunity to create a consistent theme through each level or chapter.
Say we look at individual dance styles, quite often these styles will be part of a larger category.
For instance, we could look at flash mobs, conga dance and line dancing, these dances come under the category of group dance, so we could block out a “group dance” chapter within our game, this gives us both consistency and avoids monotony.
This graph shows the structure of chapters within the game and blocks out what each level will focus on within that chapter.
After broadly blocking as much as possible I begin to create more detailed design documents for each block, that will later be collated into one final design doc.
Again each block’s design doc will vary depending on what it requires as a character design is vastly different to a level design.
For the actual document I will use as many tools as I have at my disposal, and wherever possible I will illustrate a problem, be it with a diagram, a drawing, UML, or graph it if possible.
Visualization is the easiest possible way to clearly convey an idea to another person.
I use Visio and other diagram software to organise things from level structure, boss fight, software structure.
For example here is an example of a simple phone app flow
Or this mock dialogue tree I made for demonstration purposes
Diagrams can even be as simple as stick figures drawn in MS Paint, for example…
There as many many many other things to consider when developing and maintaining a GDD but these are some of the methods I currently use, I hope to learn more about documentation and improve my practices as I progress.
As I said before, I apologise for not being able to show any of my full GDDs but they are still in development.
I hope that this page has given some kind of hint as to how I like to operate and what my experience is.