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

Earlier this year, a small hunting simulation called DEER HUNTER shocked the industry by rocketing to the top of the sales charts for three months. Presently, it's still selling well and shows every indication of continued good sales. While most hardcore game players stick up their noses at such value-priced games, the truth is that there's still a huge untapped market of computer users who do little with their PCs but write letters, send e-mail, and play solitaire. Death rays and world conquest hold very little interest for them, and they're still waiting for a game they'll enjoy playing.

Although I'm not inclined to debate the merits of games such as DEER HUNTER, let me at least point out a few facts regarding the game that might help to tip the balance of opinion in its favor.

• DEER HUNTER was the first game to attempt seriously to simulate the strategies involved in deer hunting. If you're snidely thinking that there is no strategy to swigging down a beer and storming through the woods after a buck while blasting away with your shotgun, then you have no real knowledge of hunting on which to base a valid opinion. Before I sound too sanctimonious, I should point out that before I worked on DEER HUNTER, I had little knowledge of hunting myself, and shared many of the same prejudices.
• DEER HUNTER is a value-priced game. It costs only $20 and includes $20 worth of value. Many people tend to compare this product against games costing two to three times as much, with budgets often 10 times or more what we had to work with. DEER HUNTER's total development cost was around $75,000. Remember to compare apples to apples.
• DEER HUNTER was targeted specifically at non-enthusiast game players. This meant that both controls and game play were kept as simple as possible. This wasn't only expedient; it was a requirement determined at the outset of the project.
• DEER HUNTER was developed from the ground up by three programmers (one was a college intern) and a part-time artist in less than three months.

It's this last point that I really want to focus on, because it is one of the more interesting aspects of the game, the remarkable sales notwithstanding. How the game sold after it shipped was a shock to everyone, including us, but the development cycle was something that was controllable. At this point you may be saying to yourself, "So what if a small game such as this was written quickly? The product I'm working on is much more complex, has many more features, yada, yada."

This could very well be true. However, many of the lessons learned in a compact development cycle can be applied to any sort of game development project. I've had the opportunity to analyze and fine-tune our development process through five games in one year. Even if a project is expected to require a year and a half to complete, the same strategies can be applied to individual milestones within the project, or even to project components over a much longer period. The techniques don't necessarily have to be used to speed up development, either. They can just as well be used to get more from your existing timelines.

In this article, I outline some of the salient aspects of our development cycle. Some of the points are undoubtedly common sense, but all too often common sense gets ignored in the face of tradition or other external pressures. Other points, however, fly in the face of conventional design approaches. While it's true that not every project could or should attempt to utilize some of these principles, the fact remains that, using these techniques, Sunstorm rapidly produced hit after hit in quick succession.