I have dyslexia. Reading and writing takes ages for me.
I love to write this blog and I love to read new articles shared on twitter though. But it all takes twice as much time then with everybody else.
It's the same with the GDD. It's just a nightmare to read it and even worse to write it. Just so no one would read it in the end anyway.
During the development of 4 In a Blow a simple solution presented itself.
CONCEPT PITCH DOCUMENT VS GDD
Traditionally a pitch is used to show to investors or publishers.
A Game Design Document contains all the information about the game. For many people the GDD is a monster of a document.
So why should we compare them?
In many teams the GDD is abandoned after a period of time. The staff will look at the game for most information. This got me to review the function of the GDD.
To me the GDD is an improved version of the pitch document. It contains all the market research, story, game mechanics, concept art or inspiration found on the web, rough monetization strategy and the first UI design.
Think of the GDD as a seed which will grow into a tree of all kinds of documents, illustrations, frameworks and pre-visualisation.
ASSET TRACKER
After I made a short pre-vis of our game I went to a freelance artist to make all the art assets.
Just making a exel file with all the things that you want works quite well.
At the top of the document you can write about all the details like resolution etc.
More below you can make columns with:
You can make more columns ofcourse. Use the ones that fits you best.
I must mention that this is a good, straightforward and clear way of working but only if you have a small team. Larger teams will have to use task managment tools like asana and basecamp.
FRAMEWORKS
It is advisable (but not necessary) to have most of the art work finished before you make any framework.
Below are some examples. I don't think it needs much more explaining that's how efficiently frameworks are.
You can use frameworks for everything (even for 3D games). UI, tutorials, monetization, sound implementation, ...
It's much more efficient for communication with your team members, you can get feedback from players before you start coding, you can try different things before you start coding and you can show it to investors or publishers.
FOR THE FUTURE
Saying that I won't use any GDD anymore would be lying.
A GDD still is usefull at the start of a project but after a while it's pretty useless to keeping it up to date. No one is looking forward to read a 1000 page document.
I'll be using more frameworks in the future. Keeping the frameworks organised is the message.
