Deer
Hunter's
Three-Month Development
Cycle
By
James Boer
Gamasutra
January 8, 1999
Vol. 3: Issue 1
Originally
Published in Game Developer Magazine, December 1998.
| Deer Hunter's Three-Month Development Cycle |
Introduction
Lesson
1: Don't Over-Design
Lesson
2: Don't Be Afraid to Design Dynamically & in Parallel
Lesson
3: Smart Scheduling
Lesson 4: Code Around Scheduling
Delays
Lesson
5: Create Meaningful Milestones |
In some instances, scheduling cannot be fudged enough to minimize dependencies and still give enough time for everyone to complete their tasks. Or, there may not be enough alternate work with which to fill up that person's schedule. In this case, the best thing to do is simply to code around the problem. This was somewhat of a problem in DEER HUNTER's development.
I was responsible for the deer's AI and behavior. A problem arose when the map view took slightly longer than anticipated to get functional (with as tight a schedule as we had, even a week could make a huge difference). Without a graphical view into the deer's world, it was difficult for me to maintain my schedule.
In future projects, I would learn from this mistake and create a separate application exclusively for creating and testing animal movement and reactions. The next generation of hunting games were expected to have more advanced behavior, so I needed far more time to program the AI in our later projects. I used a third-party graphics library, Fastgraph for Windows, to create this test bed, because it had native support for a flexible floating-point coordinate system. The animals all used floating-point vectors for movement in a realistically scaled world, so this worked well for me.
 [zoom] |
Your particular choice of libraries and tools doesn't really matter, as long as you maintain a clear separation between the test bed and the game code that you're writing. This distinction also has another positive side effect: it forces programmers to maintain a clean and intuitive programming interface to the code modules that they're writing, because the code must be moved from the test bed to the main project. At some point, the actual project may become incompatible with the test bed due to increasing complexities in the game itself. Don't try to maintain the two separate projects unless you're absolutely forced to do so. Simply move the code to the main project and continue working there. Keep in mind that the test bed is simply a means to an end, and once its usefulness has ceased, it should be discarded. Don't make it too pretty by wasting time on irrelevant features. Quick and dirty is the key.
