Today's post is about the all important first steps in any project, taking an idea and turning it into concrete, clear, and concise game design documents.
I spend some time browsing message boards, and they are full of budding game designers with great ideas and even greater enthusiasm. The problem is, they all too commonly fall into the same pitfalls, ultimately dooming their project. I am going to talk about some of the common pitfalls I have seen in this post.
For those who don't know, the "high concept" document is essentially a "pitch", it is a short, one or two page non-technical document aimed at sponsors, investors, or management, in order to secure funds or obtain approval for a new project. A "Design Document" is a much longer, highly technical document which details all of the art and programming features the game will have, it is also known as the "Game Bible". It should be so detailed that a designer who knows nothing about your game should be able to create it from the Design Document alone.
I am aiming this post mostly at "Indie" or Independent games developers, since that is what I am, and that is what I have experience with.

The first common mistake, is to describe your project by making reference to another project.
E.g "It's like World of Warcraft, except it's set in the future". If you have done this anywhere in youre high concept document, or arguably even in your Design Document, you are not ready to even think about beginning work on the project, or hiring team members. A game must have a unique selling point, and the high concept document is aimed at getting that point across. If you begin your pitch by comparing your game to another one that's already been done, what investor is going to want to give you money? It it's "like World of Warcraft but..." why won't players just play World of Warcraft? Designers who describe their games by comparing them to others often don't understand their idea well enough, and need to spend more time thinking about it. You may be able to get away with a few references to other games in the Design Document, if you are trying to explain a particular feature and can't come up with another way of doing it, but even then it should be discouraged. Particularly for an independent game developer, having a unique product is vital. Indie's just can't afford to spend millions on advertising to sell a product, the game has to sell itself, and if it's just a clone of something else, it won't do that.

The next thing new designers often do is the unintentionally oversell themselves. E.g. "This game features a gripping, exciting story and deep characters, sure to entice and enthrall players to the very end". The fact is that unless you are, or have hired a professional writer, or have bought the rights to their work, there is no reason to believe your story will be any better than anyone else's. Writers get paid well for what they do, if anyone could do it, they would be out of a job.
Another example is to advertise multi-platform support, and console support. In addition to the fact that console owners only allow "approved" developers access to their consoles (A string of poor games is one factor that contributed to the downfall of Atari) a PS3 Dev Kit now costs over $10,000, even after being halved from it's initial cost, a professional Xbox 360 dev kit is similarly priced. Other SDK's are less expensive, the Wii SDK for example is around the $2,000 mark, but that's still a significant investment. So, unless you've got that kind of capital, you shouldn't be claiming console support.
A high concept document should describe your Ideal game, but not a fantasy game. You will no doubt have to compromise somewhere on your original concept, due to budget or time constraints for example, and that is prefectly understandable, but everything in the high concept should be something you can reasonably hope to achieve. For example, claiming that the game has (High concept documents are always written in the present tense, as if the game already exists) 30 levels and then finding you only have time to put in 20, is not a problem. Claiming Morgan Freeman is going to do the voice over for the intro, is.

The final mistake that I have seen a lot of developers make is to fail to "bridge the gap" between an idea, and "details". Coming up with an idea is the easy part, anyone alive can sit down with a pen and paper and come up with five great, unique ideas for a game, complete with plot twists and unique characers. People have powerful imaginations, that's a given. But it takes a lot to turn an idea, into a game design. I have seen a lot of people looking for help on game development forums with what they thought was a good idea, only to get no responses. Why? Simply because an idea is cheap, and in order to consider joining a project, team members need a lot more information.
An initial request for team members might describe the project like this:
"Redemption" is a gritty, dark story about a lone hero struggling to survive in the town of "New Haven" after a nuclear war has devastated most of the globe. Dragged into a conflict that was not of his doing, he must now fight to overthrow a brutal empire bent on wiping out what is left of humanity.

That's a story that has been done to death, right? But that by itself is not the main problem. The main issue with that is that it's an idea, it's not a design document. In order to consider joining your project, most self-respecting artists, programmers, and other professionials need details.
For example:
How many terrain files are there? Is it an open world game, with one large terrain the player can explore at will? Or will there be multiple levels, each with their own unique terrain?
How many distinct character and building models will there be? 8, 10, 15?
How many weapons?
What kind of art style should be used? Bright and cheery, or dark and sinister?
What technical features will the game possess, such as streaming terrain, seamless loading of objects, persistent worlds, advanced ai, advanced physics?
Will there be multiplayer support?
What about music? How many sound effects will be required, will there be a soundtrack to the game?

The purpose of the Design Document is to answer these questions. This provides a lot more detail for a prospective team member, and shows that you, as a designer, have a clear vision for the project and not just a vague idea. Most game projects don't ever make it to completion, partiularly indie ones, and no professional wants to waste their time with a designer who doesn't know what they want.

In summary, proper documentation is important. It often means the difference between a project succeeding, and one where people waste months of their valuable time on a project that ultimately fails.