Post-mortem Age of Empires

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

“What do you think about this Age of Empires ?” Asked the first.
')
His friend replied: "Oh, Microsoft corporate robots simply connected Warcraft and Civilization to shake off some money."

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

For us, Age of Empires 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. In this journey, we laughed and cried, destroyed tons of pizza and caffeine and learned a lot about how games are made.

Recreation of the past

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

The design has evolved and improved over time. On this path several important events occurred. It seems to me that the best is when the gaming company employees play a lot of different games.

These were the Ensemble employees, and we were greatly helped by the programmer Tim Deen's habit of buying almost every game released for the PC. It was Tim who turned the attention of the rest of Ensemble to Warcraft II . At that time, many AoE gaming elements took shape, such as resource management, empire building and technology research.

However, we could not decide what to do with the fights. 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 improvised meetings continued until AoE became more interesting than Warcraft .

Another important change occurred around the middle of the development process, when the designers looked at the localization plans for AoE . They realized that AoE will be sold in Asia, but there is not a single culture from this region in the game.

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

All these changes were made because the game designers were not afraid to listen to the feedback from other employees about the design. We wanted to create a game that everyone in Ensemble would be proud of, and it was not empty words. Perhaps the best example of such commitment was the Wonder of the World, a building that a player could build and use to win the game.

In early 1997, AoE looked great against the competition, but everyone felt that the gameplay needed something more. We tried and dropped a lot of ideas. Then our network programmer Mark Terrano (Mark Terrano) came up with the idea of ​​creating the Doomsday Clock, which will force players to drop everything and solve a new problem. In AoE a bunch of small ideas and strokes invented by artists and programmers. Their participation in the creation of design significantly increased the sense of belonging and pride in the work on the game.

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

At this stage, I realized that Tim Dean is really a real gamer gamer. If in the process of development, some iteration of AoE design gave one player advantages over others and made the game one-dimensional, then Tim would definitely find it.

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

Multiplayer path

Multiplayer support was an integral part of the design from the very beginning, and AoE was built so that most of the game didn’t 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 model of the game in which the entire game was simultaneously running on all machines. Machines exchanged among themselves only movements, changes and commands. This approach allowed us to minimize the amount of transmitted data.

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

The process of determining the connection speed required to transfer game updates was completed prior to the completion of computer AI, and was based on the 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 mistake by the first patch. AoE is better than expected, has shown itself to dynamically adapt to delays. The shifting window laid down the use of the team, so all the players had time to get the commands and did not need pauses to complete them.

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

One of the lessons learned from the multiplayer game process is that you need to make the most of testing tools for exchanging data, such as automated logs and checksum checks. In addition, we found that a simple data transfer simulation program provides great advantages and isolates the network code from the rest of the game.

DirectPlay also had problems. Hardly reproducible bugs, strange behavior and bad documentation made it all the more difficult. One of the most notable examples was the guaranteed delivery of packets for IPX. At CGDC, Microsoft promised to add this feature to DirectX 5 and even included it in the beta version.

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

Paint 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 graphics, we used 3D Studio and 3D Studio MAX.

Since 3D rendering required a lot of time, each artist used two cars. These were typically 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 models were textured, animated and rendered to a .FLC file (Autodesk Animator) with a fixed 256-color palette.

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

The cleaning process consisted in the selection of parts and smoothing the corners of unsuitable forms. Since most AoE sprites had a screen size of only 20-100 pixels, the improvement in 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 cinematographic inserts. Video inserts, including a three-minute intro, were themselves a full-scale project.

The 256-color palette (in fact, 236-color) was also a problem. The palette was chosen and adopted at the very beginning of the project, 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, and this is too time consuming. On the other hand, the palette had a wide and well-balanced range of colors, giving the game graphics a bright and friendly look. If we were doing another 8-bit game, we would generate a palette a little later in the development process.

Develop speed

Performance is a problem in all but the most primitive games. 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 was slowing down) and various update procedures, which led 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. Here the story becomes personal, because I did most of the work on this part of AoE .

I began 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 finished code, I proposed to carry out a large-scale reworking of the structure of the graphics engine, including rewriting most of it in assembler.

The AoE development team asked if it was 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 cope with such a volume.

I could not just take and cut out the entire old graphics engine, otherwise I would have prevented the work of everyone else, so I spent the next five months mainly on creating a new engine. In the process, I was able to make small changes that increased the frame rate to 10-14 fps, but the real breakthrough came after one sleepless night, when I implemented the last part of the new architecture.

To my surprise, the benchmark now worked 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 analyzing 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 optimization justified itself and allowed us to increase the default resolution from 640x480 to 800x600.

From this experience I learned the following lesson: the closer to the end, the more inhibited and overloaded the game can become. Often, in the early stages of development, the engine showed high speed, but the game was not yet complete. Then simple test levels were replaced with complex final ones, AI was added, the interface, various functions and features, and performance could drop significantly. AoE had the same story. Before completing the project, when we plugged all the holes, many of the performance tricks were exchanged for new features.

What we managed

1. The game was divided into separate components of the engine and games. Around the middle of the development process, we thought that the codebase in some parts had grown a lot, and every new change and addition seemed like an awkward hack. Lead programmer 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 has been very successful and has enabled AoE programmers to achieve high-quality object-oriented design. We won in that the code became much easier to change and expand, and it saved a lot of time for programmers.

2. We made the game manageable through the database. Thanks to the object-oriented approach, almost no AoE objects were hardcoded in the program code. Huge tables of information described each of the characteristics of 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, has helped us in developing AoE . Due to the fact that they were in the cycle of the process, when problems arose, they helped us, and did not interfere.

The best example of such development assistance is how we managed to shift the release schedule. When something took longer than planned, or new problems arose, we quickly reported a 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 panic and nervousness, we remained professional and focused.

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

Therefore, we clearly understand what entertains in the game, and what people find in it. Twenty people sought to ensure that the gameplay was strong and had no restrictions.

5. We achieved good speed. Speed ​​is very important if you want to achieve widespread popularity of the game. Age of Empires rather quickly worked in a game with eight players 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 total effort. Programmers made special efforts to keep memory consumption low, and looked for bottlenecks, and artists cut off extra animation frames to free up memory.

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

Ensemble's smart management understood this and invited families to frequent joint dinners in the company and other events and made them feel at home in the office. After tense deadlines, executives insisted that employees take a couple of days leave to meet with their families. Employees could choose flexible schedules for themselves, and occasionally flowers and other signs of gratitude were 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 job as much as I did.

7. Sophisticated localization. From the very beginning, we knew that Microsoft wanted to release AoE in six languages, including Japanese. Around the middle of the development process, we added full localization support to the code base. This required cutting and replacing all text strings in the source code and storing all the text of the game in an external resource file.

There were also strict limitations on the drawing and display of text. We could only use Windows GDI, from which many game developers ran like the plague. In addition, it meant that the interface elements (for example, buttons) had to be of such size that they fit the largest translations of their texts. This limited the list of tricks that could be used in the user interface.

But we rolled up our sleeves and coped, following the instructions exactly. To our surprise, such transformations were painless and easy. We felt even better when Microsoft translators told us that localizing AoE was the most trouble-free project for them.

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

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

Such respect, supplemented by the support of the employees of the company, created an amazing sense of family and team spirit. We avoided the fact that certain groups created a feeling of isolation from the project, therefore relations and morale remained at a high level even at the moments of the most intense work.

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

What we failed or could do better

1. Beta testing was too late. The AoE public beta test began in August 1997, but we could not fully exploit its potential. We were too close to the end of the project to make any changes to the game, despite many useful reviews. Manuals for the game were ready for printing, and almost the entire design could not be changed. We could only fix the errors found. For future projects, we decided to conduct beta testing earlier.

2. Sharing information with Microsoft’s QA department was not built correctly. For the most part, the bug report system was managed through a database and developers could not communicate directly with testers. As a result, the elimination of many errors took much longer, and new functions were not tested.

The intermediate database was not enough to exchange information between testers and developers. In future projects, we would like to assign a separate tester to each programmer so that they can get together 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 errors has greatly increased.

3. Sometimes we did not manage 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 following the work of each member of their team. It was to the leaders that new requests were appealed to the team from the outside.

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

4. We did not manage to adequately test the multiplayer mode with modem connections. The development environment was unlike the typical end-user systems. During the development process, we intensively tested the multi-user AoE functions.

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, the connection was provided by the company's T1 network. But in the process of testing, we did not guess that most players will use dial-up modems and slow connection to Internet service providers.

And it happened not only in our country, the same situation arose in the Microsoft test labs. As a result, we haven't tested modem connections well enough. Harmless at low latency bugs led on slow Internet channels to disconnect users from the game. And our high-speed network concealed the fact that under certain, quite often arising conditions, AoE could require a transmission frequency of 15 Kbps. This outgoing speed is six times more than the 56 Kbit / s modem could provide.

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

5. Separate stages of development depended on products that did not have time to release on time. There was another reason why games were modestly tested on the modem: problems with the release and quality of DirectPlay Microsoft. The features promised and even added to the beta releases were not available in 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 Microsoft’s promised, but not released, functions. Waiting for the promised drivers and SDK is one of the hardest tests for the developer. Microsoft itself was our publisher, but even we had no control over it.

6. We had no plans to release patches. The patch version 1.0a, although successful, still caused problems because we did not plan it. The main argument was this: if you know what you are going to do the 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 will be able to test the game as the first 50 thousand customers. Buyers will try things that you don’t even think about, running the game on machines and with drivers that you haven’t even heard of. As far as I know, for almost every large game released this year, a patch or update has appeared.

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

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

Although many of these events were favorable for the company, we didn’t really cope with their organization and our plans failed. These breakdowns 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 by using pre-notifications and limiting the number of people who should respond to them.

8. We didn’t take enough advantage 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 watched by a second computer equipped with a development platform and a debugger. These games were randomly generated, but the sequence of all actions was recorded, so that we could repeat any game over and over until we could find the cause of the problem.

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


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

Patching

After the release in AoE production, we threw a big party to relieve some stress. But it turned out that it is too early to rejoice. Shortly after the appearance of AoE on the shelves of stores, we began to receive messages about problems with finding ways, the behavior of AI units, restrictions on the number of units and multiplayer mode.

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

Despite the fact that we had to distract from other projects and the development lasted more than we wanted, the patch was successful. He greatly improved the quality of multiplayer games, corrected errors and solved the problems encountered in the gameplay. And this is how the modern version of AoE appeared , which, I hope, is stored somewhere on your hard drive ...

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