Found at http://gametea.wordpress.com/2010/09/13/game-design-process/
Credit to whomever credit is due.
Talking about concepts and theories is fine up until a certain point, but eventually, I feel that there’s an obligation for me to attempt a more nitty-gritty, technical kind of post. Now, I’m all kinds of not technical, and I expect the average person to be just as untechnical in this area, so I’ll make the focus of this post be on a topic that is easily understood, but detailed enough to warrant an explanation: writing a game design document.
(Note: The concept of a game design document (hereafter: “GDD”) is neither exclusive to apps, nor does it cover all types of apps, but the basic mechanics can be applied to any non-game apps pretty easily. With that in mind, this post will focus on GDDs as a game concept.)
The first step in making a game is drafting up a GDD. But what exactly is a GDD? Well, as the name implies, it’s a document which details all of the particulars of a game’s design. (There’s actually a partner document called a technical design document which outlines a game’s coding, but that’s ironically too technical for me to go into detail about in this post.) From a one line explanation of the game’s basic concept to the specifics of its scoring system, a GDD is meant to cover every single situation and detail that can occur within the game.
I could just link to a bunch of GDD templates and walk away from this post wiping my hands together in a manner suggesting a job well done. But! I’m a man of the people who knows that no one wants to read document after document of not only similar, but also dry material, so I’ll do my best to condense the information into a shorter, more internet-generation friendly post.
First of all, when planning your GDD, you should know that each one will end up being unique; the GDDs of Pong and Call of Duty will differ drastically since both games have radically different design goals. But even if every snowflake is unique, there’s still enough uniformity for them to all be grouped together as snowflakes. For GDDs, those universal elements generally include sections such as overview, game flow, game mechanics, player mechanics, and player goals. If you’re unsure of which elements you’ll want to include in your GDD, it might help to look at templates and actual GDDs to get an idea. Most games will require long GDDs like the first two linked above, but for the scope of tiny app games a la Fruit Ninja, something more akin to the third linked template would likely suffice.
An average GDD will open with a quick overview of the game. This section can be anywhere from one sentence to a couple paragraphs. It’s easy to think of it as an elevator pitch, in which an entire idea must be summarized to a point where you can pitch it to someone stuck on a short elevator ride with you.
After that, it’s kind of open to personal preference in terms of the order in which you present the remaining information. But it’s probably best to lead right into the game flow. In that section, you detail what the gameplay experience is like for the player. It’s a little awkward trying to explain it, so let me share a quick sample. In Super Mario Bros. the game flow is play through a four thematically related, side-scrolling levels; fight a boss at the end of the fourth; move on to the next world of four differently themed levels; rinse and repeat through a total of eight worlds. Obviously, you’d actually write something more detailed, including mentions of level-warping and time limits and other such things, but that’s the general idea.
Next it might be best to move onto the game mechanics section. Like pretty much every section, game mechanics defines itself by just its name. Going back to Super Mario Bros. you’d mention things such as how Mario runs from left to right and jumps on enemies to get points, how the life system works, and how the scoring system works.
For the player mechanics section, refer to the picture at the top of this post for an idea of what should be included. But more than just explaining which button does what, it’s important to also mention in this section how the player’s actions effect the world around them. I guess I’m kind of stuck on Super Mario Bros. but think of how when Mario has eaten a mushroom and is large, how he can destroy blocks by hitting them, and how he can’t when he hasn’t eaten a mushroom and is small. Y’know, stuff like that.
Honestly, by now, I’m sure that you have a decent handle on the basics of writing a GDD. Really, the best way to learn how to do it is by just doing it. Now that I’ve provided you with a barebones overview, you should be up to the task. And don’e forget, if you ever have any questions regarding writing a proper GDD, do hesitate to contact me, because I’m no expert.
