sponsors gamedev.net search:

Introduction Everyone wants to make games, but few people actually end up making them. Why is that? This can be attributed to several factors, such as skill, knowledge, dedication, and goals. You can take those four variables and assign them any values you want and mix them up every which way, but doing so will still not reveal whether a person will succeed or fail. See, all those attributes describe the person's willingness and ability to achieve what he or she has set out to do – but it says nothing about how he or she goes about actually doing it. And that's where a lot of people trip up. This article will introduce you to a method of development that will supplement the four previous properties in order to enable you to achieve your goals. This isn't some new-age method I thought of – it's a tried and true formula. Perhaps you've already thought of it yourself, since it's nothing complex. If you haven't, or just have no idea what the title of this article means, then read on. Why Planning is Good I know you're just itching to click on that link that says "Incremental Development" so you can find out just what the heck I'm blabbering about. Well be patient with me for a while longer as I take a little time to explain why planning your projects is important. And I don't just mean big projects. Don't stop reading this because you're doing a dinky tic-tac-toe game. If you think of constructing games as constructing a building, you'll get a good idea of what will be expected planning wise. The first thing that goes into making a building is laying down requirements. These requirements are then used as guidelines in creating the blueprint. The blueprint is then used to determine, before construction begins, if there is anything that looks wrong. What do you think is easier, changing the placement of a wall on a blueprint or moving the actual wall itself? Finally, the blueprint is used during construction to create the actual building. To complete the analogy lets look at constructing a game. Instead of requirements we have rules. These rules are then used as guidelines to create the design document, which in turn is used to help create the technical specs. These two documents are our blueprints. You can guess where it goes from there, onto construction and debugging and testing and so forth. Yeah sure, you may think extensive planning for a game of Snake is unnecessary, that you may spend more time planning that it would take to actually code the game. This may be so for some people. However, that shouldn't matter. The fact is that you will be forced to plan out larger projects, so why not practice on the smaller ones? It's important to get into the habit so you can't rationalize your way out of planning later on. I would also wager that those who choose to dive straight into coding would actually end up spending more time sifting through buggy and disjointed code than it would have taken them to plan it first and code it second. It's hard for people to believe that planning is a timesaving method, because they think of the hours spent with pencil and paper or in Word, drafting or typing up the rules and specs as a total waste. The common belief is to fix bugs when they pop up, instead of trying to squash them before they ever even manifest themselves. Even with simple projects, you'll start out with a clear idea of how everything will work. This "big picture", however, will soon become muddled in your head once you get knee deep into code. Having hard copies to look at while coding is well worth the time and effort. So now that we know planning is good, let's learn how to take our planning to the next level: construction. Incremental Development The concept of incremental development centers on the construction phase of the project. By now you have already completed the design document, the technical specification, and the architecture (which is sometimes blended with the tech spec). It's important that you have these things because they will aid you during development, as that is their purpose. Loosely translated, incremental means "bit by bit". Therefore you can assume that we're talking about steps in development. "Oh great!" you think. "Milestones!" Not quite. Milestones are a bit too big for our purposes, both in terms of length and importance. Checkpoints would be a better description, although I prefer the terms "builds". Let's take a scenario where you are attempting to program a simple game of Breakout in DirectX. You briefly sketch out the interface and list the modules you'll need, such as CBall, CBrick, CPaddle, and so forth. You then start constructing these modules one by one, laying out their headers and filling in the routines with executable code. Then you create the main source file and integrate everything. Finally, when everything is in place, and with a flourish of the hand, you start the compile. Sure, you're bound to get errors – let's be realistic here. But, you figure, you can just go down the list and wipe them out one by one. The compile finishes. No, it aborts. You have so many errors that the compiler refuses to continue. No problem, you say, it'll just take a while. This is the whole point of debugging right? You find a missing semi-colon and recompile. Only 115 errors now. Ha! You fix another error and recompile. Now you have 124 errors. What?? I'm sure you all know the story. A lot of people think they can get away with build first, debug later, not realizing that fixing one error doesn't mean more won't pop up. Even if you were to compile the first time with only 3 errors, you would most likely fix those three (say, missing header files) and all of the sudden end up with 98 real errors. This can create quite a devastating feeling for the programmer. The point of incremental development is to prevent this from happening. Breaking it Down

Contents   Introduction   Breaking it Down   Putting it Together   Printable version   Discuss this article