(Off-Topic) Most of the time the lead game designer doesn''t make the engine. The lead programmer does. But when he writes a design document how is he able to describe how the game will playout? (On-Topic) In my humble oppinion. Gameplay and character development are the most important factors. You need to create a protagonist that will stick in the gamers head. A memorable protagonist usually gives the game a great deal of popularity. The characters abilities can fit right under the gameplay. In one of my ideas. The protagonist is an inter-galactic outlaw who is looking for some mysterious treasure locked away in the core of a giant planet. The protagonist is a bipedial brown dog who is equipped with a Mega Man-like suit which has a country-load of features. He can fly with it, shoot cannons, plant bombs, swim fast, etc. Hes an outlaw so he''ll be able to steal other people''s spaceships to get to his destination faster. "A programmer being told to ''''go to'''' hell sees the ''''go to'''' part of the sentence as the bad part."

The Design Doc is an overview of the project that can sometimes go on for 15-30 pages but I dont really think thats what you''re after. The Design Doc is not what you want to present your dev team with and expect them to come up with what you are describing. Take the overview of the design Doc and then the design team (generally in a non-funded environment that means YOU heh) hammers out ever little detail of every engine, formula and database of the project breaking each down into micro projects with goals for pre-alpha, alpha,beta and then of course retail. These goals can be muddied together to cut down on paper work but if you even accomplish the pre-alpha stage of your project odds are the alpha/beta stages will be pretty self explanatory.

Good luck

Mark

1. Gamplay is not one of the most important parts of a design because it is not something you put into a game but something you get out - if you put the right things in. You don''t design gameplay but instead focus on designing a number of other elements of the game, which if done correctly will result in the user experiencing good gameplay.

You can''t say to an artist "draw me some good gameplay" or to a programmer "you''re coding some gameplay today". You need to identify the elements that can actually be created, which when done well will result in good gameplay.

The following are all key elements of a design:
User interface
Depth of gameplay
Learning curve
Side with the player
Consistant design/environment

In addition to these (and others) your design must also include clear objectives for each element of the program. For example in an Indy Car racing game the 3D engine would need to render a larger number of cars. With a Rally game you only need one or two on screen at the same time. By setting specific objectives at the start it is much easier to measure your progress and make decisions in the heat of development.

Dan Marchant
Obscure Productions

Loftyideals
"Side with the player" means that you code the game to favour the player, not the computer. Remember that they pay your wages, that they should enjoy the game and that the computer wont sulk if it loses.

A good example of this is MOHAA - A truely excellent game in all respects except one. The enemy AI is far too accurate. This is fine in most cases (standard firefights with MG or SMG) but on the level where you have to pass through a town full of snipers the game falls down badly. As soon as you stick your head around a corner you get hit by a sniper you can''t see. This would be acceptable with SMG fire but a sniper rifle is often fatal with one shot so we are talking about an instant death situation, which is never a good game design feature. The AI should have been tweaked to miss or wing you on the first shot to at least warn you that there is a sniper ahead (you have a medic with you who can heal you if you suffer a non-fatal shot).

This problem was highlighted in most of the reviews and info on the Spearhead add-on is that the AI has been tweaked in this respect.

Dan Marchant
Obscure Productions

Chronos,

The original poster was asking what the important elements of "the design document" are - "document" being the important word. My response was aim specifically at that.

The purpose of the design document is to give as much *useful* information to the development team in the most *efficient* method. So it should describe in detail how features should be implemented and those descriptions should be set out logically so that they are easy to find. There is no useful information that can be listed under the heading of gameplay that could not be more accurately or efficiently listed under another heading.

As I mentioned in my previous post learning curve is something that has a specific impact on gameplay. You are right that designing the learning curve is designing for gameplay but you are still designing the learning curve and not the gameplay.

A well structured design doc would be splits into programming, art, audio, story/script, level design. Nothing that fits under one of those headings would be more efficiently placed under the heading of gameplay. The best place for learning curve within such a structure would be level design>level list>learning curve - the section on level one would have its own specification/objective for the learning curve and might cross reference to level two. Level two would have the same and may cross reference those sections for level one and level three so that the designer of level two could see how their level fits into the overal design.




Dan Marchant
Obscure Productions