|
I have two games, ‘Test Cricket Manager’ and ‘Dangerous Danika’, among several that I have worked on.
‘Test cricket manager’ is a cricket management simulation that has was started in 2009 in the language of PHP; it is multiplayer only. This game is 90% complete (or is it?) and the release date is unknown.
‘Dangerous Danika’ is a puzzle game that was started in July 2013 and was the first game I made in Gamemaker, it was released in August 2014.
So why the difference in the amount of time? Is a multiplayer sports simulation that much harder to do? Does Gamemaker really make that kind of difference?
The simple answer is that the Sports game has no Design Document while Danika does.
So why can’t I do a design document the cricket game? Simply because I am too far along to sit back down and draw everything out; every time I code the game it grows organically in my head but the simple truth is that Design Document should not be organic – you need to kill it and write it out on a piece of paper so everyone can look at it (including yourself) and understand what the designer (even if you are a one person team) is trying to achieve.
The Danika game had a design document from day one and has been going ahead according to the milestones I had set. I can only work on the game part time so I have factored that into the design.
There are other reasons for having a design document
Allowing others to read it and get a full understanding of what is going on (and what they need to do if they are a part of the team).
Get your ideas on paper and see any conflicts (design bugs) early.
Ability to express your ideas and come back to them a week later to see if you would play the game. And yes, this has happened to me where I had a great idea, wrote the design document, read it again a week later and realised that it was a stupid idea. The advantage here is that I could make an important decision (to pull the project) before wasting time on producing a demo.
What needs to be included in the design document?
You really need the basics of the game. You need gameplay, how it all fits together, overall story line, what will be included in the game, required artwork, music, sound
What’s a ‘Technical design document’ and do I need it?
The exact specifications are in the ‘Technical design document’ which you can probably get by without – unless you have over ten people working on the game!
Design document will be 2 to 15 pages; technical document will be 30 to 1,000 pages.
A design documents will show that what artwork needs to be done (a girl, a dingo, a crocodile e.t.c) while the technical document will explain the size of each piece as well as the format, which folder it goes into e.t.c
Milestones
Milestones need to be finished and working before the next section of a game is attempted; each milestone should be set out in the design document and explain what can and cannot be done in the game.
Example milestones for the Danika game –
Milestone 1 – Have Danika walk around the map and all environmental aspect work (she can’t walk through walls for example).
Milestone 2 – Have opponents on the map and have correct interactions with them all (Danika dies if touched by an opponent unless she has a weapon; all opponents kill, or be killed, by other opponents according to design).
Milestone 3 – Put all other parts into the game; this includes high score, lives e.t.c
Milestone 4 – Online highscores.
Milestone 5 – Release game on the PC.
Milestone 6 – Release game on Android.
There is no specific milestone for bug finding because this should be done before you can safely say the milestone is completed; let me repeat this because it’s important – A milestone is only complete when it is BUG FREE; realistically that should be all bugs.
I have not followed my own rules only to kick myself.
A prime example was when I didn’t fully test the code for when Danika gets to the exit (because it was so simple to program I tested it exactly once).
I proceeded to next milestone and put opponents into the game; and when testing this I noticed that sometimes when Danika got to the exit the game would crash. The only thing I could think of was that the exit code was wrong; it was only 6 lines of code and yet it gave me nightmares for over a week!
I changed each line of code separately and tested; I took each line out one at a time and tested it all again; but after each time the bug stayed.
Finally I could see a pattern yet it took another hour to work out what was causing it – if an opponent was dying from being killed by another opponent then the game would crash; I had been testing the wrong code all along.
If I had completed milestone 1 and fully tested it I would have instantly recognised that the exit code was fine so I should have concentrated on the opponent code first, this would have saved me 30 hours of valuable time (and when you have a family every hour is valuable).
Some big studios don’t use them so why should I?
To put it simply, they are the studios that run over time and budgets.
I’ve read enough post mortems on professional game companies to realise that the design documents were never rated as important.
In fact one of the most common items of what went wrong was that the design document was not written down so everyone could refer to it.
Why do I need one?
So you know what the heck you are trying to achieve; if you have no goal then you can’t make a path to it.
You can drive anywhere; but if you want to drive to the nearest service station for petrol/gas/diesel then you need a plan to get there. If you simply drive randomly in the hope of finding the station then you may run out of fuel before that, and that ruins everything (trust me, been there and done that!).
Is a design document written in stone?
No. It can be changed, altered, thrown out at any time; it is only there as a guide.
|