sponsors gamedev.net search:

Putting it Together Now that we've learned how to break a project down into builds spaced realistically apart, let's look at actually putting them all together. Several problems can arise from incrementally developing your project. As I briefly touched upon in the last section, dependencies can be a hindrance. In the Starfield class example, I had to make sure the star field would animate properly when the player moved, however I had not yet implemented the player object. I could have skipped the build, built the player object up to the point where it would function in this case, and then have come back to do Build 3 of the Starfield class. This is an acceptable option, but in some cases, like this one, it's just easier to emulate the object you're dependent upon. Plus, this emulation allows you greater control over the input given to the object being tested. Another thing involving dependency is the calling of non-existent routines by an object. The object may need the data provided by these routines to function properly. Again, you could jump ahead and develop the object containing these routines, but again, a better way exists. Just like the emulation method, supplying dummy routines for the object is a great way to control the data the object receives from the routines. Think stubs - instead of coding the actual routines, you can just have them return values. Since you can then manually tweak the values, you can stress test the heck out of the object. You would not have had this level of control if you had gone ahead and built the actual object. As your project gets larger and larger, the possibility of getting a lot of errors even with small additions to the existing code increases. If you've planned your builds carefully, you should be able to determine exactly where the new code interacts directly with the old code. These contact points should be listed as hotspots for debugging. Keeping a record of these contact points for each build is invaluable to the debugging process. This is because you can then use these contact points as a map to trace your way back through the build order to locate problems at various junctures when necessary. It also creates a structure for the project - you can chart the points visually and determine, for example, if changing this routine will affect the function of another. You can easily work around dependency problems like those described above by planning in advance. If you set up a "scaffold" around the code being built, you can create a controlled environment for testing. This scaffold would support the existing code by providing input that the code uses to perform its functions. The above two problems are solved using this scaffold example. Scaffolds can remain in place as long as necessary, usually until they are replaced with the actual code that performs the functions they are emulating, and should be simple constructs to ease in the debugging since they are really non essential components. Having a scaffold in place is important in team environments because each person will be working on a different portion of the code. A team member may be constructing an object that requires input from another object being worked on by another team member. Instead of hassling that team member to finish or provide the latest build of the object, he can just use the scaffold to emulate the input. Conclusion Incremental development helps to reduce errors and speed up construction. It allows you to identify architectural problems sooner rather than later thanks to the constant building and checking. It can provide a map of checkpoints allowing you to trace the relationship of objects. It can improve testing by providing to objects highly tunable input. Sure, it's common sense to build the project every now and then to check for errors, but not everyone may actually take the time to determine when the best time would be to build and check. Furthermore, not everyone stops to determine how these incremental builds can help them in other ways. Hopefully this article has given you a broader sense for what incremental development can really do to make construction of a project, big or small, much easier. Drew Sikora is a part-time writer residing in New Jersey. He's written a total of 19 articles and interviews, 3 of which are appearing in Game Design Perspectives, published May 2002 by Charles River Media. Click Here to check it out! As always, questions and comments can be sent to gaiiden@gamedev.net

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