Post mortem Age of Empires

Once I heard a conversation in a computer store that made me very laugh. I stopped with a display case to look at the top ten games for PC and overheard the following dialogue between the two guys:

“What do you think of this Age of Empires ?” Asked the first.

His friend replied: “Oh, corporate robots from Microsoft simply combined Warcraft and Civilization to steal some money.”

As always, trying to increase our sales, I took the opportunity and told these guys that AoE was not the product of a huge corporation, but a small group of talented people living with them in the neighborhood.

For us Age of Empiresit was not only a game of epic proportions, it was an epic journey of a small team who decided to turn the idea into a real game development company. On this journey, we laughed and cried, destroyed tons of pizza and caffeine, and learned a lot about how games are made.

Recreating the past

Obviously, Age of Empires initially looked completely different than the final product. Despite the accusations, Dawn of Man (first name AoE ) was not supposed to be a clone of Warcraft II . (Actually, Warcraft II was released when AoE was still under development).

Design has evolved and improved over time. Several important events have occurred along this path. It seems to me that it is best when the employees of a gaming company play a lot of different games.

That was exactly what Ensemble employees were, and we were greatly helped by the habit of programmer Tim Deen to buy almost every game released for PC. It was Tim who drew the attention of the rest of Ensemble toWarcraft II . Many AoE game elements took shape at that time , such as resource management, empire building, and technology research.

However, we could not decide what to do with the battles. Warcraft II became a cold shower for us, it woke us up and showed how interesting real-time battles can be. Several times a week, our team stayed at work and played multiplayer Warcraft . Such impromptu meetings continued until AoE became more interesting than Warcraft .

Another major change occurred around the middle of the development process, when designers looked at AoE localization plans.. They realized that AoE would be sold in Asia, but there wasn’t a single culture in the game from that region.

We convened a general assembly and decided to add Asian civilizations to the already created early European, African and Middle Eastern tribes. Although such an addition required even more work by artists and designers, the increased attention paid to the game in Asia proved that this was a profitable solution.

All these changes were made because the designers of the game were not afraid to listen to reviews of other employees about the design. We aimed to create a game that everyone in Ensemble would be proud of, and that wasn’t just empty words. Probably the best example of such a commitment was the Wonder of the World, a building that a player could build and use to win the game.

At the beginning of 1997, AoE looked great compared to its competitors, but everyone felt that the gameplay needed something more. We tried and discarded many ideas. Then our network programmer, Mark Terrano, came up with the idea of ​​creating Doomsday Clock, which would make players quit and solve a new problem. In AoE lot of small ideas and strokes, invented by artists and programmers. Their participation in the creation of the design markedly increased the sense of ownership and pride in working on the game.

The designer’s work on balancing the gameplay remained truly underestimated. Designers spent many months adjusting prices, forces, speed and other parameters, trying to create a game that would be interesting to play, and in which there would be no “loopholes” and cheats.

At this point, I realized that Tim Dean is really a real gamer. If during the development process some kind of iteration of the AoE design gave one player advantages over others and made the game one-dimensional, then Tim certainly found this out.

And when we did not believe his estimates, he proved it to us, winning against us with the help of such tricks. Most of the time, balancing gameplay was a priority, and it yielded results: AoE lived longer and provided better gameplay than other games in the RTS genre.

Multiplayer trail

Support for multiplayer was an integral part of the design from the very beginning, and AoE was built in such a way that most of the game did not pay attention to the differences between live and computer players. When DirectX was released, it turned out that DirectPlay would be the best choice for implementing data transfer between different connection options.

To support a large number of mobile units, we used a modified synchronous game model in which the entire game was simultaneously running on all machines. Cars exchanged only movements, changes and commands among themselves. This approach made it possible to minimize the amount of transmitted data.

When using this model, there was a danger of a condition in which the game on one machine is out of sync with the game on other machines. This led to very difficult to track bugs in AoE .

The process of determining the connection speed necessary for transmitting game updates was carried out before the completion of work on a computer AI, and was based on a data transfer model received from live players. As a result, we first missed the fact that computer players can sometimes give a large number of teams in a short period of time.

However, we fixed this oversight with the first patch. AoeBetter than expected, showed itself in dynamic adaptation to delays. The shifting window overshadowed the use of the team, so all the players had time to receive the team and did not require a pause to complete them.

The problem of processing the status of players thrown out of the game was a serious obstacle for Mark Terrano. Since it is impossible to predict the exit from the game, there is usually no way to find out what happened. The problem could be in the game logic, Winsock, physical connection or provider, and occurred on the side of the sender or receiver. It was very difficult to get the game to properly handle player crashes and state transfer always for all machines.

One of the lessons learned from the multiplayer game process was that you need to maximize the use of data exchange testing tools, such as automated logs and checksums. In addition, we found that a simple data transfer simulation program offers great benefits and isolates network code from the rest of the game.

DirectPlay also had problems. Hard-to-reproduce bugs, strange behavior, and poor documentation made things even more complicated. One of the most notable examples was guaranteed packet delivery for IPX. At CGDC, Microsoft promised to add this feature to DirectX 5 and even included it in beta.

However, after the release of DirectX, this feature was nowhere to be found. The price of the lack of a single element was the time that had to be spent on writing our own system for guaranteed package delivery and a program for generating bad packages for its testing.

Color the world

All two-dimensional AoE sprites began their lives as 3D models. Age of Empires had 20 MB of game sprite graphics. Even though everything was two-dimensional, from the very beginning we decided that the graphics in the game would be taken from three-dimensional models. To create the graphics, we used 3D Studio and 3D Studio MAX.

Since 3D rendering was time consuming, each artist used two machines. Usually it was a 200-MHz Pentium Pro with 128 MB of RAM. At that time, such "hardware" was more powerful than that of our programmers. Game objects were created as 3D models from two thousand to one hundred thousand polygons. Then all the models were textured, animated and rendered into a .FLC file (Autodesk Animator) with a fixed 256-color palette.

Prior to this step, the process I described is similar to that used in many other games. But after him, the artists added another long process. .FLC files were transferred to a 2D specialist who divided the animation into frames and “cleaned” each image in Photoshop.

The cleaning process consisted of highlighting parts and smoothing the corners of inappropriate shapes. Since most AoE sprites were only 20-100 pixels on screen, improving graphics quality was an important step. When AoE was shown at E3 1997, artists received many compliments about their work from their colleagues from other companies.

The use of 3D models for game objects gave advantages when working on other artistic elements: they could be used in static background scenes appearing in menus, status screens and various cinematic inserts. Video inserts, including a three-minute introductory video, were themselves a full-blown project.

The 256-color palette (actually 236-color) also posed a problem. The palette was chosen and adopted at the very beginning of the project, even before the creation of most models and textures. As a result, it turned out that some parts of the color spectrum, for example, brown for wood textures, did not have enough colors to ensure high quality graphics.

The palette was not revised during the development process, because it would require re-rendering and processing of all the images in the game, which is too time-consuming. On the other hand, the palette had a wide and well-balanced range of colors, giving the game's graphics a bright and welcoming look. If we were to make another 8-bit game, we would generate a palette a bit later in the development process.

Speed ​​up

Performance is a problem in all games except the most primitive. So it happened with AoE . When I came to Ensemble, the game was still in its initial form and was very slow. The two biggest problems were the graphics engine (it slowed down) and various update procedures, leading to random pauses in the game up to one second.

If we were going to sell the game not only to owners of powerful computers, then serious optimization was required. This is where the story becomes personal, because I did most of the work on this part of AoE .

I started by trying to understand the work of more than one hundred thousand lines of C ++ code (until the end of the project, the source code grew to 220 thousand lines). Having spent several weeks studying the ready-made code, I proposed to carry out a large-scale processing of the structure of the graphics engine, including rewriting most of it in assembler.

The AoE development team asked if it would be possible to increase the frame rate from the current 7-12 fps to 20 fps. I answered positively. But in my heart I panicked and hoped that I could handle such a volume.

I couldn’t just take and cut out the whole old graphics engine, otherwise I would interfere with the work of everyone else, so I spent the next five months mainly creating a new engine. In the process, I managed to make small changes that increased the frame rate to 10-14 fps, but the real breakthrough came after one sleepless night, when I realized the last part of the new architecture.

To my surprise, the benchmark now ran at 55 fps. It was amazing to return to the office the next day and see how the animation that had slowed down earlier began to play very smoothly. But my job was not only in the graphics engine.

I spent a lot of time parsing and optimizing a lot of game processes. The game took place in real time, so many improvements were distributed over several cycles, and did not stop the game until its completion. In the end, the optimizations paid off and allowed us to increase the default resolution from 640x480 to 800x600.

From this experience, I learned the following lesson: the closer to completion, the more braking and overloaded the game can become. Often in the early stages of development, the engine showed high speed, but the game has not yet been completed. Then, simple test levels were replaced by complex final ones, AI, interface, various functions and capabilities were added, and performance could decrease significantly. With AoEthere was the same story. Before the completion of the project, when we closed all the holes, many of the tricks for increasing productivity were exchanged for new functions.

What we managed

1. The game was divided into separate components of the engine and the game. About the middle of the development process, we had the idea that the code base in some parts had grown expansively, and each new change and addition looked like a clumsy hack. Leading programmer Angelo Loudon (Angelo Laudon) and Tim Dean in two weeks divided the code base into two separate parts: the engine (Genie) and the game (Tribe).

This transformation was very successful and allowed AoE programmers to achieve a high-quality object-oriented design. We won in that the code has become much easier to modify and extend, and this saved a lot of time for programmers.

2. We made the game manageable through a database. Thanks to the object-oriented approach, almost no objectsAoEs were not hard coded in the program code. Huge tables of information described each of the characteristics of the game objects. To control the game, designers used a system of more than forty Paradox tables. Therefore, they could constantly update and customize the game, and then test the changes without the participation of programmers.

3. We maintained close contact and worked with the publisher. I can’t find the words to express how close contact with our publisher, Microsoft, helped us develop AoE . Due to the fact that they were in the process cycle, when problems arose, they helped us, not interfere.

The best example of such development assistance is how we controlled the release schedule shift. When something took longer than planned, or new problems occurred, we quickly reported the delay to Microsoft.

Thanks to a clear understanding of what is happening and why, they continued to support us, striving to create a quality game, despite the time it would take. Therefore, instead of panicking and getting nervous, we remained professional and focused.

4. We played our game. This item may seem commonplace, but it is very important. During the development process, all employees of the company not only tested, but also played AoE out of interest.

Therefore, we clearly understood what was entertaining in the game and what people found in it. Twenty people wanted the gameplay to be strong and unlimited.

5. We have achieved good speed. Speed ​​is very important if you want to achieve widespread popularity of the game. Age of Empires worked pretty quickly in an eight-player game on the Pentium 120 with 16 MB of RAM. Compare with Total Annihilation , which for eight players needed 32 MB and at least 200 MHz. Providing this level of performance required a common effort. Programmers made special efforts to maintain low memory consumption, and looked for bottlenecks, and artists cut extra frames of animation to free up memory.

6. The company respected its employees.I must say how Ensemble Studios dealt with its employees and their families. Everyone knows that software development, and especially the creation of games, requires huge sacrifices of time and can destroy personal relationships.

The smart leadership of Ensemble understood this and invited families to frequent joint dinners at the company and to other events and made them feel at home in the office. After tense deadlines, managers insisted that employees take a couple of days off to meet families. If necessary, workers could choose flexible schedules for themselves, and flowers and other signs of appreciation were periodically sent to families.

The results of these deliberate actions were obvious: the morale and loyalty in the company were higher than I had seen in fourteen years of software development. My wife loved my work as much as I did.

7. Thoughtful localization. From the very beginning, we knew that Microsoft wanted to release AoE in six languages, including Japanese. About halfway through the development process, we added full localization support to the code base. To do this, it was necessary to cut and replace all the text lines in the source code and store all the text of the game in an external resource file.

There were also strict restrictions on rendering and displaying text. We could use only Windows GDI, from which many game developers fled like the plague. In addition, this meant that the interface elements (for example, buttons) had to be sized to fit the largest translations of their texts. This limited the list of tricks that could be applied in the user interface.

But we rolled up our sleeves and coped exactly following the instructions. To our surprise, such transformations turned out to be painless and easy. We felt even better when Microsoft translators told us that localizing AoE was their most hassle-free project.

For us, this approach was a huge advantage: for all translated versions of the game, we had the only executable file, which allowed us to avoid a huge headache from catching bugs and releasing updates for several versions.

8. We worked as a team that respects all its members. The AoE sizing project required our long, close collaboration. One of the criteria for hiring new people was the ability to respect each other.

This respect, complemented by company employee support, created an amazing sense of family and team spirit. We avoided that certain groups created a sense of isolation from the project, so relationships and morale remained at a high level even at the moments of the most intense work.

If we had conflicts and groups, I don’t think that we would have managed to release AoE in 1997.

What we failed or could have done better

1. Beta testing was done too late. The AoE public beta began in August 1997, but we were not able to fully utilize its potential. We were too close to the end of the project to make any changes to the game, despite a lot of useful feedback. The game manuals were ready to print, and almost the entire design could not be changed. We could only fix the detected errors. For future projects, we decided to conduct beta testing earlier.

2. The exchange of information with the quality control department at Microsoft was not built correctly.For the most part, the bug reporting system was managed through a database and developers could not communicate directly with testers. As a result, it took much longer to fix many errors, and new features were not tested.

An intermediate database was not enough for the exchange of information between testers and developers. In future projects, we would like to assign a separate tester to each programmer, so that they call up and exchange information.

Toward the end of development, such a system was implemented for a couple of programmers, and their productivity in testing and fixing bugs has greatly increased.

3. Sometimes we were unable to ensure coordination between group leaders.Another area in which interpersonal communication could improve development is our own development teams. Each of the groups (programmers, artists, game designers and sound specialists) had a leader who monitored the work of each member of his team. It was the leaders who were approached in the event of new requests to the team from the outside.

During the development of AoE, pressure increased and this system collapsed. People communicated directly with each other so that their requests are fulfilled faster. For this we had to pay. People did not know about changes in the code or adding new graphics to the game, the confusion grew, which led to a waste of time and distraction. Sometimes we all had to stop work to find out what was going on.

4. We were not able to adequately test the multi-user mode with modem connections. The development environment was not like typical end-user systems. During the development process, we intensively tested the multi-user AoE features .

When we played in the office, our fast machines with large amounts of RAM exchanged data over a high-speed local network. When we tested the game on the Internet, communications were provided by the company's T1 network. But in the testing process, we did not realize that most players will use dial-up modems and a slow connection to Internet providers.

And this happened not only with us, the same situation arose in Microsoft test labs. As a result, we did not test modem connections well enough. Harmless with low delays bugs on slow Internet channels disconnected users from the game. And our high-speed network hid the fact that under certain, quite often occurring AoE conditions, a transmission frequency of 15 Kbps might be required. Such an outgoing speed is six times more than a 56 Kbps modem could provide.

Therefore, reports of problems with the multiplayer game were an unpleasant surprise for us. Although our first patch solved this problem, the situation was unacceptable. After that, each developer began to use a modem and connections of several providers, because checking the operation of the modem was an important part of the testing process.

5. The individual stages of development depended on products that did not have time to release on time. There was another reason that modem games were not tested enough: problems with the release and quality of Microsoft DirectPlay. The features promised and even added to beta releases were missing from the delayed final release.

Direct X 5a became available to us only a month before the release of the game. In the meantime, our network programmer spent sleepless nights realizing the features promised to us by Microsoft but not released. Waiting for the promised drivers and SDK is one of the hardest tests for the developer. Microsoft was our publisher, but even we did not have control over it.

6. We had no plans to release patches. The patch version 1.0a, although it was successful, still caused problems because we did not plan it. The main argument was this: if you know that you are going to make a patch, then you should not release the game at all.

You can understand this point of view, but it is also clear that no developer can test the game like the first 50 thousand customers. Buyers will try things you don’t even think about when starting a game on machines and with drivers that you haven’t even heard of. As far as I know, almost every major game released this year has a patch or update.

Instead of denying reality, we needed to allocate resources and prepare for the future in order to release all the necessary updates a few days or weeks after the start of sales of the game, and not months later.

7. We did not manage to cope with “sudden” events.In the development process, several situations arose that led to a temporary suspension of the company. For example, such events were the release of a demo version and the preparation of AoE materials for the press.

Although many of these events were favorable for the company, we did not manage very well with their organization and our plans were frustrated. These disruptions mainly occurred in the later stages of development, when their influence was felt most strongly. One of our goals when releasing future games is to minimize the impact of unplanned events through prior notifications and by limiting the number of people who should respond to them.

8. We have not fully exploited the benefits of automated testing.In the last weeks of development, we set up the game to automatically battle up to eight computer players against each other. In addition, each artificial intelligence was monitored by a second computer equipped with a development platform and a debugger. These games were randomly generated, but the sequence of all actions was fixed, so that we could repeat any game again and again until we could find the cause of the problem.

The games themselves could be performed at increased speed and they were left to work all night. It was very convenient and greatly helped us in reproducing the problems and determining their causes. But our mistake was that it had to be done at an earlier stage of development. So we would save a huge amount of time and labor. Now all future development plans include automatic testing from the very beginning of the process.


Development Team Age of Empires . Matt Pritchard in the front row, second from right.

Apply patches

After releasing in AoE production, we threw a big party to relieve some stress. But it turned out that it was too early to rejoice. Soon after the appearance of AoE on store shelves, we began to receive reports of problems with finding paths, the behavior of unit AIs, restrictions on the number of units and multi-user mode.

In addition, bugs were discovered that allowed the player to exploit unfair advantages in the game. The leadership of Ensemble and Microsoft set in motion, and it was decided to release a patch for AoE .

Despite the fact that I had to distract from other projects and the development lasted longer than I wanted, the patch was successful. He greatly improved the quality of multiplayer games, fixed bugs and solved problems that arose in the gameplay. And so there was a modern version of AoE , which, I hope, is stored somewhere on your hard drive ...

[Matt Pritchard created a graphics engine for Age of Empires . He also worked on Age of Empires II , Age of Mythology and BlackSite: Area 51.]