The game mechanics describe the game play in detailed terms, starting with the vision of the core game play, followed by the game flow, which traces the player activity in a typical game. The rest is all the infinite details.

Making my design document, but I ahve no idea what to put under game mechanics. Do I need to take all the game features I ahve came up with a descibe how they work in detail or what do I write for game mechanics? Someone please help!

Also some others as well.

Core Game Play In a few paragraphs describe the essence of the game. These few words are the seeds from which the design should grow. Planted in the fertile soil of a known market, they should establish roots that anchor the vision firmly in place and help ensure a successful game. This is similar to the description section in the game concept, except that it's non-narrative and usually expressed clearest in bullet points, though this could vary depending on the type of game.

Game Flow Trace the typical flow of game play with a detailed description of player activity, paying close attention to the progression of challenge and entertainment. If the core game play is the root of a tree, the game flow is the trunk and the branches. All activity should actualize and extend from the core game play. Be specific about what the player does, though try to use terms like "shoot", "command", "select" and "move" rather than "click", "press" and "drag". This keeps the description distinct from how the actual GUI will work, which is likely to change. Refer readers to specific pages in the User Interface section when you first mention a GUI element such as a screen or window or command bar.

It's just as Sol said. How you word your document and present it is simply a matter of personal taste. Some people like to write pages and pages of material, others like to keep it simple and illustrate their words with diagrams and examples.

You should know what to write, otherwise you don't even have a concept yet, which means you shouldn't be working on a design doc. A design doc must provide full detail. That means if I were to read your document, I would know everything there is to know about your game with no hidden surprises. The only thing I won't know (and I won't care either) is how you implement it. For example, you may say something like "The player list will be sorted in alphabetical order", but I don't give a rats how you sort it. Save that for the implementation docs.

Here are some examples of game mechanics: 1) The player has 9 weapons to select from.

2) The Pistol. The default weapon carried by the player at all times. It has a 9 round clip and a maximum ammo capacity of 32 rounds.

It's just as Sol said. How you word your document and present it is simply a matter of personal taste.

Wrong, you word and present your document to communicate your vision and ideas in the best way possible to the intended audience. If you don't structure a doc in a way that is clear for others to follow AND to refer back to, then you will be the only person reading it. Your personal taste will shape your judgement of what structure is most effective, but it should never be the sole reason for your choices.

Game Mechanics are, in essence, the set of actions available in a game, and the rules and limitations that govern them. I would stay away from anything like precise numbers, but I would include a description of the intended effect of the rules. Don't say how many rounds a pistol has, but what kind of behaviour and damage you expect it to do, and when/why you think the player should use it.

Definitely stay away from level and mission design (other than as examples) when describing game mechanics.

Game Flow would normally be a description of how the player's actions and objectives follow one another at the mid and high level. For example, the high-level game flow of a Total War game is radically different from the flow of a campaign game like Starcraft; the mid-level game flow of a GTA-style open world game is equally different from a linear shooter like Quake.

Jare, professionalism is implied in my statement. I think it's pretty obvious you don't take a bunch of crayons and scribble crap on a piece of paper. Having said that, formatting a document is still a subjective matter. You can use examples from posted material such as on Gamasutra, but ultimately you're going to mold it into your own style.

Jare's right about keeping the game mechanics a bit vague. I was more or less thinking of the whole design doc, which should be specific. I normally do game mechanics during the conception phase of development, but when working in the design phase I get very specific.

-- edit -- I forgot to mention, a finite state machine (FSM) or flow chart is pretty handy when describing game flow.

As seen in your definition game mechanics will probably have to do with how the player interacts to gain or either loose points, and also how the latter will grow through the game... in other words what are the call/responses between the player and the game.... hope that helps :\\^)

divide your documents in to several parts like level design, gameplay, etc. Then write it down neatly. For level design you dont need to be good artist. just make a rough sketch and point out if there is something significant, rest of the work will be done by level designers. For gameplay better you use flow charts. Now gameplay can be again broken down in to parts like weapons, vehicles, ammos, etc.