Breaking it Down
The whole idea behind incremental development is to keep the time between compiles as short as possible. You want to take small baby steps for two reasons:
Reading the above two points, we can begin to define the term "baby steps" into something workable. Obviously incremental development emphasizes constant compiles, but the problem is deciding when to compile. Obviously you don't want to spend half of your total development time compiling the project, even if it can drastically reduce errors. There is a point where incremental development can actually become time inefficient, and that's when you spend more time compiling than coding or debugging.
Another thing to consider when deciding build points is that when you compile the project, you want the new build to run and actually do something on top of the old build. Don't do a compile just to debug a routine that isn't even called yet in the execution. Wait until you've added a whole game function. For example, if you had a space game, you might compile to simply display the player's ship. Then you would code in all the weapons programming and then compile to test and debug the shooting of the lasers. You wouldn't compile the project until you were able to actually shoot the lasers. For example, compiling to display the guns themselves would be a waste – they should have been shown with the ship the first time or you should have waited until the lasers could fire. Just showing weapons adds nothing of testable value to the previous build.
With this is mind, it's a lot easier to decide when to compile. Keep in mind these guidelines:
If you need an example, I made a small Asteroids demo in SDL. It didn't do much except display a ship that moved and rotated and fired a laser that did nothing, and asteroids were careening around and there was a parallax star field effect. This was my first project in SDL and it only took me three days, a few hours each day, to get this far. Here was my build order:
This was taken from the main source file, and only progresses up to the game's current state – there are actually 20 main builds but, as you can see, each game object has its own builds assigned to it. Here's an excerpt from the Starfield class source:
I would like you to notice Build 3. Even though at this time there was no player ship to be seen on the screen, the build still called for implementation of the arrow keys to simulate player movement. It's important to realize that you shouldn't have to mix up the building of objects because of dependencies. This is discussed more in the next section.
On average, each of these builds created about 5-10 errors. Debugging was as tedious as ever, but was made easier by the fact that I knew what code to look at for mistakes. The hardest part of debugging is knowing where to start, where to look. When you know where the new code is, it can greatly simplify the problem.