My friend and I are starting up a game project. We have a whole bunch of rules and activities that we need to capture in written form before we start codingbut we're having trouble keeping track of everything. It's made even harder by knowing that we will probably decided to make major changes if some of the rules just doesn't pan out well. I'm curious how the big boys capture the results of all those design meetings and communicate to the developers, so if anyone is willing to share techniques that work I'd love to hear about it and model our process after the pros.

To organize your ideas, break them down into categories and sub-categories. See http://www.sloperama.com/advice/specs.htm to get an idea of how it works.

You might also take a look at Behavior Trees as a method of organizing a large collection of ideas/requirements.

I'm not a professional, but I have found a good way of explaining game-play mechanics (rules) and flow of the game that helps with a more technical designer later on.

My method is a high level description of the flow and the game-play of a game that uses 2 types of documentation (both graphical).

The first is the game mode diagram.

This look a bit like a flow chart (and it is based on the same concept). However, rather than the logic of a program flow, you are instead showing the relationships between the various modes that a game goes through (how they are linked together).

The 2 basic Modes are:
1) Game-Play Modes
2) Menu/Shell Modes

Menu/Shell modes are typically a single screen or menu screen that reports to the player (shell type modes) or allows the player to make a selection from a list of choices (menu modes).

There is no game-play associated with these modes, so the player is not being given choices to over come challenges (see the next document type for what I mean by challenges). Examples of this type of mode are: Configuration menus (menu mode), Main Menus (menu mode), Game over screens (shell mode), Attract screens (shell mode).

The only real differentiation between a shell and a menu is that a shell typically only has one way to exit (eg: "push any key to continue") and their primary purpose is to report information to the user (eg: "game over").

Game-Play modes are the modes of the game where game-play takes place (like that is not obvious :D ). What to put as a game-play mode can be a little tricky.

Take for example a Typical scrolling shoot-em-up game. In this you might think there is only one game-play mode where the player shoots the enemies that attack them, but the usually have at least 2 (and even more game play modes). The primary game-play mode is the one where the screen is scrolling and the player is shooting enemies. the other typical one is where the screen stops scrolling and they have to shoot a boss enemy.

Why are these considered different game-play modes? Well the primary reason is that there are differences in the game-play, although subtle, there are differences.

In the scrolling game-play mode, the player is mainly attempting to gain points and power-ups (by killing enemy waves) and surviving. But in the boss fights, they are not necessarily attempting to collect points or power-ups, the main goal is to destroy a particular enemy (the boss), the points and power-ups at that point are of secondary importance.

It is this change is the game-play (from collecting points and power-ups to killing a specific enemy) that signals that the game-play mode of the game has change. This is also communicated in the game to the player by changing something about what is displayed (scrolling to stationary screens - although sometime they speed up the motion).

This means that these two game-play modes have to be shown as separate entries in the game-play mode diagram and how the player/game moves between them must also be shown.

The way you draw these is that you draw a box and write the game-play mode name in that box, then for each way to exit a mode, you draw a line (with an arrow pointing to the mode it is going to) to the more that action will take you to and write a description on the line what that action is.

Of course, using a drawing package (I use OpenOffice drawing tools to do this) on a computer means that you can easily change this as the game design progresses or if you decide to game something.

The second type of documentation is that of the Game-Play diagram.

the purpose of a game-play diagram is to show the relationship between the challenges in the game and the actions the player can take to overcome them. This is essentially a diagram that shows the relationship between the rules and the goals of the game.

With this diagram, you list the challenges in one column and the actions in another (and note that an Action might also be a Challenge and so need to be listed in both columns).

There are several type of challenges and many types of actions (pretty much unlimited actions).

The main types of challenge are:
- Economic : The player must buy/sell or trade one resource or item for another

- Reaction: The challenge involves the reaction speed of a player

- Collection: The player needs to collect an amount of a resource or item that could be hidden or otherwise hard to get (this is typically linked closely with Economic challenges).

- Conflict: The player must destroy the target or avoid being destroyed themselves by the target.

- Construction: Building, repairing and Healing are all construction type challenges.

- Accuracy: This is where the the ability of the player to princely position something on the screen or in space (Getting ahead shot in an FPS is an example of this kind of challenge).

- Logic: this type of challenge is where the player must use their mind to solve the challenge (puzzles and chess are good examples of this kind of challenge).

There are many more (like rhythm and such, but this should give you an idea of what is meant.

Next you list the action that are needed to overcome each challenge.

For example a few challenges and actions might be:
Challenge Action
Survive (conflict) <- Avoid enemy attacks
Heal Damage (construction) <- Drink Healing potion
Improve attacks (construction) <- Level up
Level up (collection) <- Earn XP
Earn Gold (collection) <- Kill Monsters
Earn XP (collection) <- Kill Monsters
Kill Monsters (conflict) <- Use attacks

As you can see, the last 4 challenges and action form a chain where an action is also a challenge that needs another action to achieve it.

As you can also see with the action of killing monsters, you can have several challenges fulfilled by a single action (Killing monsters), but you can also have multiple actions needed to fulfil a challenge.

Now, the two documents work together. For each Game-Play mode you need to create the game-play diagram for it (list the challenges and actions that can be taken in that mode). This way, you know what each of your game modes are and the game-play (challenges and actions) involved in each one.

Something to note: No Shell or Menu mode can have a game-play diagram for it. If it does, then it is game game-play mode not a shell or menu mode. Also, every game-play mode has to have a game-play diagram for it. If it doesn't, then it is not a game-play mode but a shell or menu mode.

I find these diagrams useful in helping to work out what needs to happen in a game and also to help convey the design to the more technical groups of the development team.

The game Mode diagram can be used to construct a finite state machine that controls the flow of the game (are they in the main menu, or are they in the main game, or are they at the game over screen). The Game-Play diagram allows you to know what the player has to do to achieve the goals of the game, it also helps you to find gaps in the chains of actions needed (what if you forgot to describe that the player needs to earn XP to level up, or a more subtle mistake) and also helps you to work out what rules and other mechanics are needed (how does the player buy upgrades to their watch towers? etc).

I hope this helps.

This is all very good information, and I thank the three of you in kind! I've got more than enough to get us going. Cheers!