On this day in 2002, Ensemble Studios released the imaginative RTS Age of Mythology. This spin-off from the Age of Empires series won great critical acclaim, but unfortunately never found an audience as large as that of the mainline games in the franchise. (It's currently available on Steam.) This postmortem, which first appeared in the February 2003 issue of Game Developer magazine, was written by two Ensemble staffers who worked on the game: designer Greg Street and lead designer Ian Fischer. Fischer is now the design director at Robot Entertainment, and Street is the design director at Riot Games.

One is pretty hard. There are a lot of things to attempt and reject, a lot of mistakes to make, a lot of lessons to learn. Without a prior success (or even a prior failure) for comparison, much of your design relies on instinct. Without an experienced team, much of your schedule operates at dartboard-level accuracy. Figuring out both how to work around long-expected pieces that don't pan out and how to capitalize on unexpected miracles is a big part of the job. Mix these factors in with the usual chaos surrounding a game company on her maiden voyage and you have a situation often referred to generously as "challenging."

Two is easier, although you may not think so at the time. With your first game out in the wild, you're able to get real world feedback on what worked and what didn't. You know more about your team and ideally have a familiar engine and tool set to work with, providing you with a much better idea of what's possible. Additionally, from the lazy designer perspective, half of your feature set is waiting for you at the start of the project — everything you ran out of time for on the first game.

Three is the end of the world. By this time you've amassed a good understanding of what people like about your games. Unfortunately, you also have fans who've played two titles in the series, plus a few expansions, and are starting to grumble for something different. At the same time, removal or alteration of any existing feature will be met with ranting emails, forum petitions, and overturned cars in your parking lot, so this is also the time when finding out that preserving everything the old games had becomes vital. The engine and tools you developed for the first game and advanced in the second are behind the technical curve by this time, so now you need to add developing and learning new ones to the to-do list. And, at some point, you're going to get a visit from a graduate of the this-trend-will-continue forever school of projection who, armed with charts showing that title One moved a million copies and Two moved 3 million, will tell you Three should move 9 million copies.

This is where the design team was at the start of Age of Mythology. The big question that haunted us was: Wow, what are we going to do to top Age of Kings?

Ensemble Studios' projects are ambitious, and we ratchet up the ambition with each new project. As the scope of the project grew, the size of the team grew. We were developing a new engine and a new multiplayer online service at the same time that we were developing a new game, a game in which we wanted to incorporate new features, such as God Powers and myth units, and a more ambitious single-player campaign.

Rather than restate the all-too-common problems of having more ambition than resources, of having marketing push for content before it's ready, and of having personnel problems every company goes through from time to time, we find it more useful to focus on design aspects in this article. Designers are Ensemble's vision-bearers, but we don't get to just ram our ideas down everyone else's throats (as attractive as that power sounds at times). The designers must keep the project in scope, keep the artists and programmers from killing each other, and make sure feedback is heard without devolving the game into a design-by-committee project.

WHAT WENT RIGHT

1) Iteration

Ensemble's basic design process is to get the game playable early and then tweak it until it's fun. This applied to virtually every feature in the game. Some features changed a million times, and we were willing to abandon things that just didn't work, even when it was painful.

Age of Mythology's God Power feature is a good example of this process in action. On paper, our initial concept of God Powers and Heroes sounded good: Heroes would have buttons on the interface to target God Powers wherever the selected Hero happened to be — simple enough.

Unfortunately, when we got the feature in the game and started playing with it, it was awful. Having to have a Hero in the place where you wanted a God Power devolved all combat tactics to selecting all your units and clicking on the enemy hero. This led to Heroes constantly getting killed, prompting comments like "The Heroes don't feel heroic." Additionally, with all God Powers targeted with your Hero, if you called down a meteor, it would land on his hand. It didn't damage him but it didn't look good.

We tried a new model where the Heroes built "lightning rods" for the God Powers (so players could kill something other than enemy Heroes to stop an opponent's God Power, and so that Heroes could get out of the way of their own God Powers). This wasn't fun. We tried another model where you could buy all of the God Powers with resources, like most everything else in the game. This wasn't fun. We tried a dozen more models and variants. 

Finally, after a lot of trial and error, we hit on the model we shipped with. Heroes were divorced from God Powers and made the thing used to kill myth units (which feels decidedly heroic). God Powers were moved to the main interface, and we made them single-use only, which made them feel large and important and kept them from landing atop Heroes at every use.

Because God Powers were so important to the vision of the game, we couldn't just yank them from the title after the sixth or seventh different model didn't work. Instead, we just continued to try different systems, brainstorming and then implementing models. Because a new approach often required new code and new art before it could be evaluated, we ended up throwing a lot of work away to achieve our end result. But we did achieve an end result we're very happy with. Ours is emphatically not an efficient process, but it continues to work for us.

2) Everyone play-tests

It's amazing how many developers rely on outside testers to tell them if the game is fun or not. Outside feedback is vital in the later stages of a project, but if your entire game is designed by polling the fans or beta testers, you end up with a mushy game with no vision. At Ensemble, everyone play-tests the game at least once a week. This strategy keeps the team bought in to the game that's being developed. There are mandatory, assigned play-test times in the morning and multiple pickup games in the afternoons or evening.

We have found that these play-tests are instrumental in keeping the team informed on the state of the project, giving them ownership of the process, making sure bugs don't slip through the cracks, and figuring out when the gameplay is fun enough to ship. The earlier implementation of God Powers described in the previous section made sense until it got out in front of our coworkers, at which time a mob brandishing torches and pitchforks strolled into our office. If the designers had relied solely on our own instinct about the model, we likely would have shipped with it.

3) Small meetings

For Age of Empires and to a lesser extent Age of Kings, we kept the entire team involved in the high-level design. In one particularly long meeting for Age of Kings we tried, as a company, to come up with a design for herd animals. Past a certain number of attendees, it became unmanageable to go around the room even once. So, as these meetings got longer, we tried to keep focus by including the various department leads and trusting them to relay the feedback of everyone on their respective teams. However, in a project the size of Age of Mythology, even the leads' meetings could have a dozen attendees, making it harder to reach a consensus on any of the issues.

Eventually we refocused the leads' meetings on task management and progress reports and implemented a new series of meetings for design brainstorming with a core group of only four to five people, half of them designers. Features, such as the list of civilization bonuses, myth unit abilities, and God Powers, were all compiled in these meetings. When necessary, we took these meetings offsite to make sure we could get our business done without distractions. We found that e-mail wasn't efficient enough, and as busy as everyone was, impromptu meetings weren't always possible. We had to be formal about scheduling these conferences, which we ended up arbitrarily calling "small pets" (after "pet features," since we needed a name that didn't sound like we were excluding anyone). Because it was important to our process that everyone have a chance to give feedback, we would announce the decisions made in "small pets" meetings to the company at large. We heard people's concerns and ideas, incorporated any changes we thought necessary, and then implemented the design into the game. Everyone still had a voice, but ultimately we couldn't rely on a large group to come up with design implementations as fast as we needed them.

4) Data-driven tools

Developing data driven tools early in the process was a strategy that really paid off for Age of Mythology. It took a lot of programmer time away at the start of the project, when we were all anxious to begin playing the game, but the resource hit paid for itself when designers could implement new content without having to wake up the programmers all the time. For example, although we targeted 36 unique God Powers, some of these were implemented in similar ways behind the scenes. Once the programmers had implemented a God Power to switch units, we could turn enemy soldiers into pigs, or allied Pharaohs into the Son of Osiris, all through data.

There is, however, a potential downside to spending so much effort on tools. For one, instead of working on higher-visibility game features, programmers spend their time on tools that players may not see. Second, you might be trading programmer time for designer time. Near the end of the project, the design team had all the tools they needed to implement some features but lacked the time to enter the changes.

5) Focus on campaign

The campaigns for Age of Empires and Age of Kings were fun but lackluster, largely completed by one or two designers. At the beginning of planning Age of Mythology, we decided that the single-player campaign would be one of the game's big features on the back of the box. We hired several new content designers, invested a lot of time in custom animations for the in game cinematics, and made two trips to Hollywood to work with professional voice actors instead of using local talent or (shudder) our own overacting.

We had never before attempted an epic, character-driven script, and we approached the task in epic fashion, appointing a story committee to review progress on the script. (In retrospect, trying to please so many people so early in the project was more trouble than it was worth.) Near the end of the project, the designers working on the campaign, often with the artists working on animations for the cinematics, met several times a day so they could all keep in touch on progress. The lead designer documented everything, ensuring changes were made before testing the various scenarios again. It was a tremendous amount of work at the end of the project, when we could scarcely afford it. But the work paid off, and we delivered well-received single-player campaign.

WHAT WENT WRONG

1) Design drove too much

Sure, the design department had all of these fancy tools, but in the end, designers ended up doing a lot of the work that a programmer might have been able to do faster then it took the programmer to develop the tool in the first place. We had early frustrations when specs didn't pan out as intended in the end product, coupled with the arrival of new people who had not worked with us on a title before. We compensated by heaping so much detail into specs that they were often not even read. We went so far as to provide descriptions for what artwork should be associated with the various icons in the scenario editor, and the various locations and states for those buttons.

Since all they were doing was connecting the dots on someone else's feature, new employees did not feel empowered. As a result of days spent writing things such as, "When you click this button, it should appear depressed until the user releases the mouse button, at which time it should revert to looking undepressed; clicking the button in this manner should cause a sound to occur, the sound should be kind of like a twig snapping…," the design department took up drinking in the middle of the afternoon. In the future, we plan to keep design driving the process, but at a higher level. We will trust people at the implementation level to fill in the details.

2) Scriptwriting n00bs

We knew we wanted a script that had all the scope and drama of The Iliad, and we knew we wanted characters who could slap each other on the back, make fun of each other, and develop relationships over time. In short, we needed a big story with a lot of dialogue. While the designers had some writing experience in various forms, none of us had ever tackled a script like this. We also had not yet figured out how the in-game cinematics would work, or how long we could make them without boring everyone.

We had no idea what we were doing. We did it anyway. The result was a lot of revisions to satisfy different opinions about how a story or characters should work. Everyone had their favorite bit character or script fragment that was impossible to delete, and deleting anything threatened to collapse the intricate story line. We eventually had to take a step back and revise with a much smaller group of just two people. In the future we will keep early feedback to a smaller group, which we hope will get us closer to nailing the correct length, number of characters, and plot intricacies with fewer revisions.

Developing this sort of material at both a high level of quality and in something resembling an efficient manner demands some pain and experience that can only be gained by actually doing it. If you're planning on doing this sort of project and haven't done it before, double your estimates for everything related to the project, then halve your plans for the content (number of characters, lines of dialogue, number of scenarios, number of special art objects, and so on). 

3) Consensus is hard with large groups

Consensus is the basis of the game design process at Ensemble. This company philosophy worked exceedingly well when there were only a dozen of us. Even when we grew to 20 or so people, getting everyone in a room (we usually all had lunch together) and hashing things out worked well. As the size of our team grew, however, it became increasingly less ef