"Why does it take so long to make a game?"
By Patrick Wyatt

Games take a long time to develop, there are no two ways about it. The time from announcement until the day the game is in the stores - or the day the game is available for you to download and play on ArenaNet's gaming network - can seem an eternity. And that time lapse isn't just felt by those waiting for the game's release. That perception of time passing applies to those of us working on the titles, too.

So why does it take so long to make a game? There are three fundamental reasons:

Tools and Technology

With every new title, we are essentially reinventing the wheel by adding and rewriting substantial portions of the game engine. This is particularly true for startups like ArenaNet, which start with zero lines of code and no artwork! Every title has new core technology, which includes libraries for the game, the network, and the database. There is new technology involved, new platforms to adapt to (Intel's IA-64 is finally here!), and so on. With the rapid evolution in technology, every game has new systems to consider and new configurations to embrace.

Before starting on the game, the programming team has to take the time to develop the various tools that allow the artists and designers to create resources for the game. These tools include model and texture converters, map editors, network monitors, and program testing agents, all of which need to be complete well before the game is ready to ship.

Programmers need to create tools to help the designers and artists drop elements straight into the world. This takes time, but in the end, it helps open the "programmer bottleneck" that can be a major slowdown in game development. If a designer or artist can pop his/her materials directly into the game, where it's immediately assimilated into the gameworld with no delay, the changes can be tested and proved sooner rather than later, and the artist's time is freed from the delay of that infamous bottleneck. Making changes to maps in Warcraft I was a laborious process, taking skilled level designers from several days to a week due to the primitive tools employed, whereas play-balancing Warcraft II and Starcraft maps benefited from much more immediate turnaround time due to their sophisticated map editors.

The first six months of coding the ArenaNet game engine was primarily focused on building art and design tools, and completing the low-level networking code, so that later work could build on those foundations.

Scalability

So, in the instance of the programmer bottleneck, some might suggest, "Well, hire more programmers. If you have a team of, say, two programmers, add two more and double the output." Unfortunately, that's not exactly how it works out. Doubling the team will generally not double the output. Rather, with the increased number of people to whom every decision, direction change, or design modification needs to be communicated and through whom it needs to flow, the output is not significantly increased. It's much easier for a smaller team to have a consistent vision and participate in the design process, something that became a nightmare when the Diablo II team grew to over fifty people at two sites. At some point during game development, usually at a smaller number than most people think, the perfect balance between total output and speed is reached.

As interesting academic paper on the subject can be found here. In it, Professors Smith, Hale, and Parrish confirm, "It is a well-accepted axiom in project management that increasing the number of people working concurrently on a task does not result in a corresponding increase in productivity. They cite Brooks' Law: "Adding more programmers to a late project makes it later." Brooks' quote comes from his study called "The Mythical Man Month" - found here. Brooks' study appraised the management and planning of a large programming effort, and analyzed the successes and failures of the project. Future game developers take note: it's required reading for many Computer Science programs.

Testing, Testing, Testing

So after the game is developed, what's left? Testing. More testing. Testing yet again. Testing first by the individual or cluster of individuals directly involved in that particular game element - be it animation, character art, or level design. Then, testing by a larger in-house team. Because what we are creating is all new, and stems from our imagination, it never turns out exactly as we anticipated. We have to test it - again and again - to weed out the bad ideas and to keep and improve upon the good ones.

An example of the iterative nature of game design is the Alpha version of WarCraft II. War2Alpha was a pre-release version sent to magazines for game previews, but it "slipped out" onto the Internet several months before the intended release of the game, and certainly well before the game was complete!

In War2Alpha, the way oil was harvested was substantially different from the final release of the game. Oil has always been collected at sea, but did you know that at one time you had to send out a ship to scout for the oil by pinging, like sonar, until the petroleum was located? We thought that was a cool element in the early stages of designing WarCraft II, until we tested it and found it required a lot of "hands on" for the gamer, and distracted him from other more important elements of the game. It required too much unit monitoring to locate the resource. In the end, we discovered through testing that it was more fun to have your units locate oil by the now-standard "greasy patch on the water" method.

Another facet of WarCraft II that was significantly changed was the number of resources. We started with four resources: gold, wood, oil, and stone. In fact, you can still see evidence of stone as a resource when Sappers blow up near a rock pile and the pile is reduced in size, similar to how a patch of forest is reduced in size as trees are harvested by Grunts and Peons. We discovered during internal testing that resource management was too time-consuming and that the game wasn't as fun, so we settled on three resources for the game's release.

In StarCraft we reanalyzed the whole concept of resource gathering again and decided on having only two resources, but we instituted what we thought would be an intriguing change to the collection process. We began with the Vespene Gas resource being collected from random "clouds" on the map. But that, too, proved a hassle for the testers, so we went to Vespene Geysers situated near the bases, which made the resource's collection more logical and more fun.

Another dramatic example of how testing can utterly change the direction of a game design can be found in the original Diablo. Diablo was, initially, a turn-based game. Blizzard North was heading towards developing it in that mode, but after team consultation, they decided to turn it into a real-time role-playing game. The team also decided that, although the game could support as many as eight players, it wasn't nearly as fun with that many. Because of the narrowness of the dungeon passageways, eight players couldn't play and fight together, so they would wander off into different areas of the dungeon and either get into trouble or walk through long areas already cleared by others. It was only during testing that we learned of this problem and then decided to limit the game to a maximum of four players.

In short, good developers want to release a game with features that have been tested and which have been proven to meet the threshold of enjoyment - the "fun factor" - that gamers seek.

Conclusion

So, there's a bit of insight into the game development process. We sincerely appreciate your patience during our development time and hope that sharing a few insights with you will shed some light on why it takes a while to put out a good title.