Trying to be a wise game developer, I started with the game design document for Game Tower before writing the first line of code. This is a crucial part of game development and not having one is one of the reasons why so many developers fail to finish their game projects. And here is why.
Of course my fingers are itching to get started with the real thing, and I am aching to see something other on-screen than black letters on a white background. But I know better than that. I vow to do this right. I will not even create a new project folder in Unity before the design document is complete.
I don’t want to fall into the trap of starting to implement a game before it is all fleshed out. That is how games get abandoned after the initial tech test is implemented. Writing a game design document means working out your game start to finish on paper first.
Don’t start creating a prototype right away!
Having to go back to design the meat for the bones of a game after you created a working prototype is not as much fun, and it can feel like a step backwards. So, as a result, many projects get postponed indefinitely at this point. This is how you end up with a folder full of tech demos and unfinished game projects. Been there, done that, and went there again a hundred times during High School. With the design written all out beforehand, you make it as easy as possible for yourself to keep going after that initial push.
I look at it as delayed gratification. Do the necessary but cumbersome leg work first, then enjoy the fun parts of actually implementing your game. There is a saying in Germany that describes this concept perfectly: “Erst die Arbeit, dann das Vergnügen.” – There is an English one with the same meaning: “Business before pleasure.”
There is always the risk I might lose interest halfway through a project. A game design document can protect me from wasting my time like that in the first place. It takes time to complete it – I mean really complete it, not just write a few lines and ‘add the rest later’. After I have finished it, the initial hype and excitement about the project will have worn off. If I still like a game idea after that time and work is done, then I know I will have the stamina to finish the complete game.
In larger teams a GDD (Game Design Document) is a must anyway. It’s the best way to communicate a design to all members of the team, and serves as a reference when questions come up. It can also come in handy when you need something to point to in an argument: “But you told me you wanted the gravity gun to work that way!” – “But that’s not how I meant it!”
Yes, arguments like that happen in real-life game studios. It’s always better to have a GDD.
A design document makes you think about all those little details of your game that go beyond the basic gameplay idea. So you want your character to be able to jump? Ok, but how high, exactly? Will he be able to jump higher when the button is held down? What about a double jump? Can you still change his direction while he is in the air? Will jumping be faster than running? Can you shoot while jumping? And what if your character is in the middle of reloading and the player presses the jump button?
If you are a coder, you know how important it is to know these things beforehand when starting to design the code that makes the character jump. (And if you are a wise coder working in a larger team, you also know better than to trust the GDD and you will implement the system to be as flexible as possible anyway – to be prepared for that day the designer will invariably change his mind.)
As you write, you will notice the little holes or flaws in your design. You get a chance to fix them before you start with the code design. It is much easier to change a paragraph on a page in the design document than to rewrite an entire game system because it no longer works with your current design. Since this is a one-woman show, too many major rewrites would be even more detrimental. I don’t want to waste my time if I can prevent it.
Even in a one-woman project like mine a GDD is important. I am now on page 14 of the GDD for Game Tower. Like I said, I had this on my mind for a while and it all just flows out now.
The first major design decision I put into writing was that the player will not directly choose the genre or type of game that the virtual game studio will create. I want the main focus to be on the management aspect. Instead the game designs are created by game designers that work in the Tower. The player can look at their designs and either decide to trash them, or develop the game in his studio.
Writing this down forced me to think about how the game designs my little virtual designers create should look like. There is no need for a genre or topic. Yes, that’s right, nothing but a title and an icon. Since the success of a game cannot be predicted by those factors anyway, anything else just seems like useless information. Instead, the game design will have information relevant to managing its production: The amount of work that is required from various departments to finish the game and it’s projected revenue.
My idea is that the player can build different department floors into the tower that can perform the individual work. Then he can assign the game to the appropriate floor. This works the same as the patients in Kapi Hospital, in case anyone has played that. It’s a browser game in which you manage your own hospital. You have to build specialized treatment rooms to treat the various illnesses of your patients. If you don’t have the right rooms for all of them, you can still release the patient, but he will only pay you for the things you actually cured.
This will be possible in Game Tower as well.
If you release your game before all the work is done, it will not make you a lot of money. But you can do it.