The most obvious thing to do when planning is to figure out just what exactly you are going to do your game about. The process of coming up with game ideas can last entire textbooks and varies widely from person to person, but the planning process is universal. Write your ideas down so that others may take a look and offer intelligent critique for you to base further improvements on. This vessel of ideas can be as simple as a few lines that detail the main concept of the game to a full-blown design document! It depends entirely on your preferences.

Speaking of design documents, many people do not know how to write one for a game they are working on. It's an essential skill that anyone attempting to be a professional designer should learn, so here's the parts of a well-thought out and complete design document:

• Pitch/Premise is the first part of the document, normally, and consists of the marketing buzzwords and PR that everyone has come to know and love. This is your introduction, so use it to sell your game.
• Technical is where you detail the technical aspects of the game, such as procedurally generated content, middleware engines used, and other such elements.
• Most players want a Story, so there is normally one in a design document. While not essential to a game, if the game does have a story, it is essential to the design document. Be concise and descriptive, and don't be vague or cryptic. You are explaining the world, not pitching it. See pitch/premise.
• Gameplay is the basic gameplay of the game. Is it an RPG? A platformer? A first-person shooter? What sort of environments can you expect? These are all questions asked regarding the gameplay section, and they should be answered clearly.
• Detail is the most difficult part of the design document, as it is also the most tedious. You must go through and add detail to the gameplay and concepts until everything is accounted for. So while in gameplay you may say the game has 10 guns, in the details you must lust the names, stat values, and such of the weapons.
  

Alongside building a good design document is the importance of milestones. Milestones are, simply, the goals that the developer strives for before the newest version. For example, when a new milestone is reached, the version may jump from 0.9 to 1.0. These are the important parts of the game, and usually involves tasks grouped with other like tasks (do basic AI for milestone 3, do HUD design for milestone 4). Milestones can be both technical (getting the engine working) and art-related (getting the visual assets in-game, composing the music).

On top of milestones is the amount of time taken to complete it. For some people, this is an absolute necessity, as without a cut-off date they may never finish the game! Developers work fastest when facing an urgent deadline, after all. Deadlines help maintain an even flow from milestone to milestone while keeping the product on its track for a speedy release. However, this only works well up to the testing phase, in which you can kiss deadlines goodbye. When a bug cripples your game from functioning, you don't have any choice but to violate the deadlines.

As mentioned in the ambition article, team members are good for larger projects. However, do not just hire willy-nilly off the street! Your team should get along well with one another, listen effectively, and understand the viewpoints of a disagreeing party without becoming rude. In other words, make sure to plan who you invite to the project and don't just go get help from the closest person. Teammates that hate each other will never get anything done, while teammates that enjoy the company of their colleagues will often get more done in less time!

The aspects of planning and coordination are greatly accentuated by the planning member being an artist or coder themselves as well. A single person acting as the team leader and the team leader alone is usually ineffective at garnering the loyalty of their colleagues. After all, he's not doing the hard work of translating the idea into a tangible format! A good plan to do when you want to make a game is learn part of the process, such as coding or art, and then find team members. Nobody likes a slacker, after all.

All this really boils down to is this: the more complex your project, the more you need to plan it out to keep yourself on track. You can lose valuable time just fooling around, and with long, complicated games, this can mean months lost to the vagaries of design. Naturally, with less complicated projects (such as a clone of Galaga that replaces all enemies with different senators), you don't need a drawn-out plan. But with games like Cave Story or Iji, you better believe that they planned ahead! And so should you.

Or else.

For more coverage on indie games and the scene, keep an eye out for Indie Showcase at the same bat time, same bat channel. Also check out Freeware Friday and our indie category for some excellent freeware games and indie news, respectively.