Preparation

The Concept

Make sure that your game idea is something that sets your imagination ablaze. You are going to be working on this project for a long time hence, and if it doesn't positively tickle your fancy right now, you can be sure that any tickling will end after the honeymoon. Talk to your 'game playing' friends and see what they think. If you can't get them excited about it after five minutes then your idea probably isn't that good. The initial thrill of the concept is what gets people to buy games, and if you can't thrill your partisan friends, how can you expect the gaming community to be thrilled by the description on your box or web-site?

Coming up with a great idea is one thing, but you also have to be realistic with your vision. You know what you are capable of achieving, don't fool yourself into thinking you're better than you are. Design with your limitations in mind and you'll have a much easier time when you finally start to code. Never let your imagination run completely off the leash and then try to stretch your technology to fit it, you will end up with the computer game equivalent of a fat man in spandex.

Have a brainstorming session with anyone that you feel has good insight into games. Come up with as many 'cool' additions to your concept as you can and be sure to write everything down. After the session, take your notes and carefully craft a feature list from the ideas that please you most, only you truly know which are going to be feasible. Split your list into three sections: Required, expected, and hoped-for. All of the ideas that you believe are needed to make your game complete should be flagged as 'required'. Any ideas you know would add greatly to your game but are not essential should be 'expected'. And finally, those far-out and possibly difficult to implement features that you've conceived should be labeled 'hoped-for'. Later, when identifying your milestones and deadlines, take these three categories into account. You must ensure sufficient development time to include all of your 'required' features and as many 'expected' ones as possible. If you have time left over afterward, try your hand at some of the 'hoped-for' ideas, but don't get too attached to them incase you have to let some go as the deadlines draw near.

The Design Document

There are divergent theories regarding the purpose and creation of the design document. As I see it, for the small developer it does not matter so much how you make your design document so long as you make it concise and complete. Ensure that your design doc describes everything in your game, from top to bottom. If you're going to have to program it, record it, or draw it, it should be in this document. Describe the functional specifications first, and only when this is finalized should you create the technical component. Describe every algorithm you intend to employ and every solution you intend to implement. If you can't think of a solution for it now, don't include it in your game. Never assume that you'll "figure it out when you get to it."

Keep your design doc as modular as possible so that it can be easily added to or subtracted from. If you need to make changes to it down the road you should be able to do so without disrupting any unrelated items. Having said that, I must now emphasize the importance of sticking to your document once it's complete. Of course it is wise to allow for the possibility of change, but as much as possible you should keep your design static. It is very difficult to hit a moving target, and we all know that hell hath no fury like a programmer scorned.

Once your design doc is complete, coding should be a breeze. You'll already have all of your solutions identified and you'll have a complete list of items that need to be implemented. Just go through the list (in order, have discipline!) and barring any major design changes, your game development shall press forward like little girls at a Backstreet Boys concert.

Deadlines and Milestones

Even the one-man army must make milestones and deadlines for himself. Whether you have a publisher or not, it is a beneficial practice. When you pass a milestone it's kind of like getting a pat on the back, you know you've done well and it makes you feel good to know that things are progressing. Additionally, the presence of deadlines and schedules will entice you to do what needs to be done and to do it on time. Without these constructs the development path becomes blurred and you will find yourself straying to work on items further down the path simply because that's where the 'fun bits' are. Development is undoubtedly most efficient when undertaken logically and sequentially, so make your design such that this process will be as painless as possible.

Peruse your technical and functional documents and extract what seem to be the most important milestones. Apply to these milestones reasonably generous deadlines wherever possible. There is nothing worse than the feeling you get as you see your deadlines flying past and you realize that you are slipping, so keep this in mind.

If your project has no set ship date, allow as much time for testing and QA as you can. It is impossible to predict what problems may arise during these times, so it is best not to try to compress the schedule. You will know when you are satisfied with the quality of the product, so ship when you're good and ready - one of the advantages of being an independent one-man army.