What Went Right

Contents

Catching Up What Went Right What Went Wrong The Show Goes On

We did what it took to make AoK a triple-A game. While the decisions to take an extra year and reset the units to an AoE baseline were tough in the short term, they were the right decisions to make. The commitment of Ensemble Studios to exceed the quality of its prior games never wavered. To realize our goals, we added the additional programmers, artists, and designers that we needed. When we needed to stop, take a hard assessment of what we were doing, and kill our own children if need be, we did just that. We pushed ourselves hard and we came together as a team.

1. Addressed the major criticisms of the first game

Despite AoE’s success and generally glowing reviews, there were two things about the game that were repeatedly criticized: the artificial intelligence of the computer players and the pathfinding and movement of units. And to be honest, they were right. Because these issues got so much press, we knew going in that if we didn’t address them in a visible and obvious way, AoK was going to be raked over the coals by reviewers and users. It didn’t matter that other popular RTS games had pathfinding that was just as bad, or that our AIs didn’t cheat and theirs did — we weren’t going be judged against them, but rather against ourselves.

A 3D Studio Max model of the Mameluke character. Twenty thousand polygons got reduced down to several hundred pixels for the final game.

To handle the computer-player AI, we hired Mario Grimani, an industry veteran with significant AI experience under his belt. The computer-player AI from AoE was thrown out, and a new, expert-system, script-based AI was developed. While Grimani was doing the coding, Sandy Petersen led the design team in developing scripts for the new AI. Input from the whole company was encouraged, and various people contributed scripts that were pitted against each other in an evolutionary fashion to develop a computer player that could race a human player up through the ages and react to his tactics.

For the pathfinding problems, nothing less than an all-out blitz was ordered up. The game engine’s movement system was redesigned and no fewer than three separate pathfinding and two obstruction systems were developed, requiring five different people working on them at various times. A high-level pathfinder computes general routes across the world map, ignoring such trivial things as people walking, which were handled by lower-level pathfinders that could thread a path through a closely packed group of units. In the end, we were so successful in ridding the movement problems that hampered AoE that reviewers and players couldn’t help but take notice and acknowledge the improvement.

2. We innovated within the genre

While in the end AoK stayed much closer to its AoE roots than we had initially envisioned, we pushed the RTS gaming experience forward with a host of improvements. Some of these were interface-only improvements, such as the “Find Next Idle Villager” command, completely customizable hot-keys, and the extensive rollover help. Other improvements changed the game play itself, such as the Town Bell (ring it and all your villagers run inside the Town Center to defend it), in-game technology tree, and of course, Automatic Formations. One of the most praised features, Automatic Formations, caused a group of selected units to automatically arrange themselves logically by putting the strongest units up front and the ones needing protection in the rear. They stay in formation while traveling, replacing the “random horde” that players had become accustomed to in RTS games. Programmer Dave Pottinger originally set out to create a formation system incorporating characteristics of a turn-based war game’s formation system, but as the game progressed and our understanding and vision for the game matured, a complicated formation system gave way to a simpler system that better served the game.

A 3D Studio Max model for a male villager. For AoK, female villagers were also added.

When I wrote the graphics engine for AoE, I used a 166MHz Pentium at work and tested on my 486 at home. A 2MB video card was my target, but the game would run with only 1MB of video memory. Today I have a 32MB TNT2 card in my 500MHz Pentium III system. These changes in the typical game player’s system are mirrored by the increase in player expectations for a great visual experience. In AoK, I’m proud to say, we met and exceeded game players expectations. The first thing that you notice upon playing AoK is the scale. The units in the game are about the same size, but the buildings and trees are no longer iconic. They are large structures with a scale that looks as if the units could comfortably reside inside them. Castles and Wonders are now gigantic, imposing structures that fill the screen. And the art itself is just so much better. Our entire art staff gained a great deal of experience and skill with AoE and RoR, and AoK became a showcase for their improved talent. It wasn’t just the units and buildings, though. In AoE, the terrain had something of an Astroturf feel to it and the need to make transition tiles by hand limited the game to four terrain textures. For AoK, a whole new terrain system was developed, allowing us to mix terrains together, shade elevation in 3D, greatly increase the number of textures, and even alpha-blend textures such as water. The highest compliments came at the 1999 E3 show when we were unable to convince people from some of our biggest competitors that AoK was still a 256-color game.

3. Better use of bug tracking software and crunch-time management

During the development of AoE, we had a single machine in the office that would connect up to RAID, a remote bug database in Redmond, Wash., via an ISDN modem. This was used to handle bugs found by testers at Microsoft. Every so often someone would fire the connection up and, if the machine at the other end was in a good mood, make hard copies of new bug reports to pass around to people. We also had a different software package for communicating bugs and issues among ourselves, but there were not enough users on the license for everyone. Suffice it to say, this system left something to be desired, but it was all we had. During the development of AoK, ThinRAID was made available to us, allowing everyone to access the bug database directly from their web browser. Having only one system on everyone’s desktop, available whenever needed, that was always up-to-date made a huge improvement in our ability to track bugs, stay on top of things, avoid redundancies, and just plain save time.

A bird’s-eye view of the AoK game world. Compared to AoE, AoK has bigger worlds with more objects and richer graphics.

The last six months of development on AoE were pretty much one continuous blur of people working nonstop. This took a heavy toll on people, sometimes even straining their health or marriages. As a company, we vowed to not let things get that bad again. To further underscore the need, the composition of Ensemble Studios had shifted dramatically away from being mostly young, single men (with presumably no life) to being dominated by married men with a growing number of children and babies on the way. To protect ourselves, we scheduled crunch time well in advance at multiple points in the development process. The hours were 10 a.m. to midnight, Monday through Friday, with Wednesday nights ending at 7 p.m. so we could go home to our families. We had weekends off and meals were provided during the week. For the most part this worked very well, although having a “family night” where family members could join us for dinner once a week proved to be more of a distraction than we would have liked. Producer Harter Ryan deserves much credit for making crunch time so much easier on AoK.

4. Better use of tools and automated testing

After AoE was finished, we developed several in-house and in-game tools to make the job of development easier. The most-used tool was ArtDesk, a multi-purpose program that converted graphics from standard formats to our proprietary formats, which allowed us to view and analyze the content of our graphics data, and generated many of the custom data files for the game. This easy-to-use GUI-based program replaced several antiquated DOS command-line utilities and automated many tasks, saving a huge amount of time over the development span. In an effort led by Herb Marselas, programming tools such as Lint, BoundsChecker, and TrueTime were used to a degree never approached during AoE’s development and proved invaluable in improving the quality of our code. Finally, in-game utilities such the Unit Combat Comparison simulator allowed the designers to balance the game in a more scientific way. Every effort made in the tools area was rewarded with either time saved or significant improvements in the product. The only glaring omission in all this was the lack of an art asset management tool.

5. We met our system requirements

A game that’s expected to sell in the millions needs to be able to run on most of the computers it will encounter. Requiring cutting-edge systems or specific video cards won’t work. With AoK being an 8-bit 2D game, meeting video card requirements wasn’t going to be very difficult. But memory and processor-speed targets were another story. All the new systems in AoK would put their demands on the computer. Optimization issues were worked on hard for the last several months of development. The eleventh-hour addition of some clever tricks and a variable graphics-detail switch allowed us to hit our CPU target of a Pentium 166MHz, MMX-supported CPU. The minimum memory requirement of 32MB was also met, but with some reservations. Large multiplayer games on huge maps would need an extra eight or 16MB to be really playable. All in all though, the minimum system requirements for AoK are some of the lowest for games released in the Christmas 1999 season, widening the game’s potential audience.

________________________________________________________

What Went Wrong