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 efficient to get everyone in a representation from all of the disciplines. These groups have the ultimate decision-making authority but also the responsibility for gathering feedback from the entire team, explaining and defending decisions, and building a general consensus.

4) How different is "different"?

The well-known, inherent risk of sequels is that you need to keep what is popular about earlier products while still offering something new to justify the purchase of a new product. The Age of Empires games are large and complex, and we knew we couldn't take Age of Kings and layer several new game features on top of it; we had to pull out some systems and change things to make a game that was "different." While some of us were (or thought we were) clear on what "different" meant, there were many other definitions floating about. For some members of the team, different meant, "Age of Kings, but the knights look like Minotaurs." For other team members, different meant, "There are no units, and you control the game with your mind." When a new feature didn't work right away, the differences of opinion led to a lot of pressure to revert to the tried-and-true.

For example, we went through several variations of our population model. Earlier implementations lacked houses, which for some of the team was just too great a departure. The team quickly split into two camps, one that argued for even more change in the gameplay, and another that was scared that we were moving too far from the game our fans loved and expected. The fans are not particularly forgiving in this respect, and once the game was out, they applauded some of the new features while protesting about even the smallest features that were removed, such as choosing your player color.

Ultimately, there is no ideal solution to the problem of defining what is different; games today are too complex to be fully defined by a vision statement, so there will always be some degree of opinion to factor in. We plan to try to mitigate these disagreements in the future by attempting to answer the big questions such as "How different?" early on, and then keeping these guidelines in front of the team for the duration of the project.

5) Unfinished tools

Because we were dealing with a new engine and there was no shared code from our previous titles, we made the right decision to reserve a lot of time early on to develop tools. Unfortunately, since the tools were for internal use only, it was easy to move people off of those tasks when other problems came up. Several tools were never completely finished, and the customers for those tools (typically designers) waited up until the final days of the development cycle to see if improvements of incomplete features could be added. While waiting for the tool, we hacked a lot of content in place, figuring that it was better to do some work than sit idle. A good example was the AI for computer opponents in scenarios, which came online very late, after the designers had hacked in fake AI using scenario triggers. This kind of work was difficult to unhack and left us with less time to iterate than we would have liked.

For the future, we (like everyone else in the game business) need to remember the value of tools and not skimp on their development time. We additionally need to pay particular attention to those tools that might ship with the game, such as the scenario editor, which was never completed to our satisfaction.

Here to Four

The good and bad of getting there aside, the end product of all this is our Three, Age of Mythology. Everyone at Ensemble Studios is immensely proud to have contributed to this game and we're now looking forward to the opportunity to figure out what type of beast Four will be.