Interesting, I use a very different technique for Game Design Documents.
First thing, is that you have spelling issues. such as the first sentance of your dgg, "by" => "buy".
Second thing, is that after reading the first paragraph, I had no feeling of how the game worked. I really like what I read, which is great from an advertising perspective, but it lacked a good feeling what the game will be like.
I have a book on Game Design/Marketing that is in review now, and *hopefully* will be published soon, and I'll try to water down a few concepts from it into a short message here.
[30 Second Commercial]
The first paragraph is great, but I recommend another section called 30 Second Commercial, directly after.
- You write out a script of what would be covered in a commercial of your game. Imagine you had 30 seconds of time to show a player a video of your game, to try to get the interested enough to try it out. 30 seconds is not much, but considering all the games out there, and your probable budget for advertising, 30 seconds is a lot. in this you would typically have 5 to 10 second sections showing off a key area. NO WORD Montages (I.e. Flashing a bunch of buzzwords on the screen. Game Goliaths can say things like that because people already know they can back it up.) Describe what the players will see and hear.
- Focus on the key things about your game that current similar games don't provide, while still expressing the basic game play.
- This is really good for conveying not just the general idea, but the core concepts of how the game runs and *feels*. For instance, starcraft and warcraft 2 have different feels to them, even though the game play is very similar.
- Use this 30 second commercial as a guiding post to NOT WASTE TIME. I.e. you need to get something out soon, anything really. Trying a 3 year concept without pay will probably have everyone lose interest in your project. If an idea or concept you are considering does not help you create a game that the commercial shows, don't do it. Put it in a bucket of things to add to a version 2, or a version 1.1. or 0.2 even.. The point is, figure out the most important things about your game, (just a couple) and get them done.
[Why is it fun]
The 30 second commercial usually does a pretty good job of describing the appearance of the game, how it feels for instance, and a couple key features of it. this section now aims to express what the key factors of making it fun are. Its not fun because its a game. We've all played "games" that we stopped almost immediately, because it was terrible, not fun at all. Also, we've played games where its fun in one area, but another area really losses that feeling.
- Its important to figure out the key features of fun, and then anytime your designing, programming or thinking about the game in the future, you can try to make sure the idea or thing your working on helps to bring that out or reduce it. For yours, it sounds like identifying patterns in how people act or times people move. This means that in your data for your player to review, maybe they have access to all the tapes from a night. It would be booring to make them sit their and watch each video from start to finish, but it also takes the fun away to just present the time that every 15 minutes past the hour, a guard walks through X hall way. Another thing about your game might be how you layout the game plan. The players get to work out ideas of what time ranges they have to get through a section, and should be able to see it work out a bit prior to executing it. Seeing their game plan operate, like X's on a blue print moving around. These things need to be considered.
- The idea sounds fun over all, but your game design document isn't to sell the public on what your doing, its to keep everyone developing it on the same page. I.e. one player might imagine it like rainbow 6, for planning things out, while another might imainge it more like Ghost, where you find things out as you sneak around. Figure out what the fun parts are, what the players will enjoy the most. Don't worry as much about the details of how its done, but instead the underlying theme of what makes it fun.
[Why it will sell]
I add this section to my GDD's to make sure me and everyone else on the team know how the game will make money. This could be as short as "Planning on posting it to XBox Live for 7$, with a demo that has these key features..." or it could be "Free to play, but payments will be made in Microtransactions, to give players bonuses in play."
- if its a demo, then sell, you need to consider what this demo really needs to have. your dev team should really understand the key differences between the demo and the sold version. Is it the same engine with different levels? Separate these two. Also express clearly the goals of this demo. How can it get people excited about a certain style of game play, but make sure they understand there is more to get?
- If it is a Micro-transaction based system, then consider what will the balancing system be. I.e. if a player pays a buck, and then gets awesome powers, and they annihilate other Free players hard work, despite having played less, you've probably just lost yourselves a bunch of potential purchases. You need to make sure your keeping in mind how to balance paying vs free.
- If it is monthly payments, or arcade/credit style, you need to have a plan in mind of what will make the people come back and keep paying up, instead of leaving and moving on to some other game.
- The key idea, is that just like everyone understanding what is fun about the game and applying it where ever they can, they also need to keep in mind its sales points and make sure that any reasonable spot of the game that can promote your needs, does.
[Player Stories]
- Player stories has no direct link to a "plot", but instead to different modes of game play. A good example of a story is an the classic Zelda 2 from NES.
Story: travel the country - In this, the player will travel around, exploring areas, from an overhead view. All very high level perspective of country side and mountains and rivers. (Note that this story said nothing about battles or sales?)
Story: travel the country (Monsters) - While travelling the country side, monsters may appear around you and chase your character. If you don't avoid them you will get pulled into a forest Scene loaded with extra monsters to fight.
Story: travel the country (Fairies) - While travelling the country side, rarely a fairy may appear, and if you capture it, you are taken to a forest with only a Fairy and no monsters. The Fairy heals your magic and Health.
Story: In a Village/town/forest - In this, the game is now a side scroller where the player can jump, battle monsters and gain items.
Story: Healing Houses - In this, the player can enter some houses that will either heal the Health or Restore the Magic.
Story: Using Magic - The player can pause the game, and choose to invoke a magic at almost any time where they might also do battle. MAgic comes in different forms and will aid in different ways.
Normally, the stories would have a bit more description, but not a lot. What makes Stories helpful is it identifies the core screens to code in the game, and the key events that make them help transition them. This should not do the programmers job; it should not tell them to use a HashTable or store everything globally. it should only tell them what the user will see. Once that basic feature is built, it can always be clarified, and them more sub features can be added.
Aside from including some graphics idea, usually near the 30 second commercial, that is the majority of the game design doc I use. You don't want to add to much detail or people won't read it, and you want to make sure they key values come across well.
