Contents  Introduction  Why Assembly  Language?  Win32 ASM Basics  The Design  Document  Code Framework  Until Next Time  Printable version     The Series  Part 1  Part 2  Part 3  Part 4  Part 5  Part 6

The Design Document

Time for something a lot more fun ... designing the game. This is a process that is often neglected simply because people want to start writing code as soon as they have an idea. Although this approach can work for some people, it often does not. Or, if it does work, you end up re-coding a good portion of your game because of a simple oversight. So, we will cover exactly how to create a design document that you will be able to stick to, and will end up helping you with your game.

First, you need to have an idea of what you want the game to be, and how you want the game play. In our case this is a simple Tetris clone so there isn't too much we need to cover in the way of game play and such. In many cases though, you will need to describe the game play as thoroughly as possible. This will help you see if your ideas are feasible, or if you are neglecting something.

The easy part is finished, now we need to come up with as many details as we possibly can. Are we going to have a scoring system? Are we going to have load/save game options? How many levels are there? What happens at the end of a level? Is there an introductory screen? These are the kinds of questions that you should be asking yourself as you work on the design of the game. Another thing that may help you is to story board or flow chart the game on a piece of paper or your computer. This will allow you to see how the game is going to progress at each point.

Once you have all of the details complete, it is time to start sketching the levels out. How do you want the screens to appear? What will the interfaces look like? This doesn't have to be precise just yet ... but it should give you a realistic idea of what the final versions will look like. I tend to break out my calculator and estimate positions at this point also. I have actually ran out of room while creating the menu screen before. This was my own fault for not calculating the largest size my text could be and it took a few hours to re-do everything. Don't make the same mistake, plan ahead.

The final stage is just sort of a clean-up phase. I like to go back and make sure that everything is the way I want it to be. Take a few days break from your game beforehand. This will give you a fresh viewpoint when you come back to it later on. Often times, you will stare at the document for so long that something extraordinarily simple will be glanced over and not included in your plan -- for instance, how many points everything is worth and the maximum number of points they can get ( Not that I have ever found out halfway through the game that the player could obtain more points than the maximum score allowed for, or anything like that ).

Whether you choose to use the process I have outlined, or one of your own making, it is imperative that you complete this step. I have never been one for wasted effort -- I do it right the first time if possible, and learn from my mistakes, as well as the mistakes of others. If this weren't necessary I wouldn't do it. So, do yourself a favor and complete a design document no matter how simple you think your game is.

Next : Code Framework