Deer
Hunter's
Three-Month Development
Cycle
Dynamically and in Parallel
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 |
The original idea for DEER HUNTER was actually simpler than what ended up on store shelves. I joined Sunstorm in May of 1997 with a rough idea of what I'd be working on, but no real knowledge of hunting. My first assignment was to design a deer hunting game. You might imagine how thrilled I was at the prospect of designing a game based on a "sport" that consists mostly of sitting and walking around in the woods for hours on end, waiting for a passive animal to show up so you can shoot it.
The initial game idea wasn't much more than many of the other hunting titles seen previously - that is, blasting a deer when it happened to meander across your path. As development progressed and I became more knowledgeable of the intricacies of hunting and stalking deer, I realized that we could, with a slight change of focus, turn the game from an arcade gallery into a simulation with the addition of an overhead map view and a dynamic scene generator. The biggest reason for DEER HUNTER's success was that we were the first company to make a serious attempt at creating a realistic simulation. Our dynamic development process allowed us to shift focus enough in mid-development to capture this market.
 [zoom] |
Although some projects have failed due to the lack of a strong design, we found that taking a flexible approach to game design worked in our case, and it might be worth considering on your next project. I'm not advocating that you turn your 3D shooter into a real-time strategy game halfway through development. Rather, try prioritizing design elements by their expected completion date and finishing designing these elements first.
For instance, if the user interface is rather straightforward but the game play still needs some work, let a programmer and an artist start moving forward on this aspect of the project while others hammer out the details of game play. This is an example of designing in parallel with the project. Because the components have a logical separation from other aspects of the design, this process makes perfect sense and avoids down time.
Likewise, in-house development tools can often be started long before other portions of a game are completed. It may even be a requirement. (For more on this point, see Game Developer's October 1998 Postmortem of Monolith's SHOGO to see what can happen if custom tools aren't given enough attention early in the development process.) If design issues are still up in the air, make sure the tool programmer makes allowances for additional functionality that might be added. The time wasted in having to change a file format is more than made up for by the fact that the programmer didn't have to wait another month for the design specifications to be finished.
Dynamic design - altering the design during development - might also bear consideration. Again, use some common sense - I'm not talking about changing the entire course of a project. We found that it doesn't pay to try to anticipate every problem that may come up during the course of development. Instead, we set goals to attain and expected both the artists and programmers to be creative enough to reach those goals on their own. Many times during the course of a project, we thought of a better way to achieve the goal that we'd set out to reach. One of the more interesting effects in the game is the zoom lens on the rifle scope and binoculars. Although the design of this effect was originally intended to be a simple pixel doubling, I realized that we could make the effect much more convincing if we could preserve the sprites' highest level of detail by using a technique we hadn't thought of earlier. By focusing on the goal instead of the process or the details, those of us working on the project could enhance the game significantly while still maintaining the original schedule.
