Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Profiling, Data Analysis, Scalability, and Magic Numbers, Part 2: Using Scalable Features and Conquering the Seven Deadly Performance Sins
View All     RSS
July 12, 2020
arrowPress Releases
July 12, 2020
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Profiling, Data Analysis, Scalability, and Magic Numbers, Part 2: Using Scalable Features and Conquering the Seven Deadly Performance Sins


August 16, 2000 Article Start Previous Page 3 of 3
 

When we had finally squeezed as much performance as we could out of AoK for the minimum platform, we were still left with aperformance deficit in the area of terrain drawing. We couldn't make the feature optional since players need to see the terrain, yet we couldn't make it any faster, either. The only alternative was to provide different implementations of terrain drawing or different levels of terrain detail.

We decided to offer three different terrain detail settings: a fast algorithm with low detail for the minimum platform, a medium detail (but slower) one for mid-range platforms, and a high detail (slower still) for high-end platforms. This allowed AoK to run on a lower minimum platform, but still give the user on the high end additional visual quality to look forward to. This was a tactic used for a number of features in AoK.

Scalable features least likely to confuse the player are those that fit directly into the context of the game, such as the number of players or the game map size. In total, there were six scalable features, four of which fit the game context. In the game, these are not called "scalable features," but "game options" (Figure 5). These options are as follows:

Figure 5. Game play and feature scalability.
Number of players 2 to 8. in any combination of human or computer
Size of map 2 to 8 player sizes and "giant" size
Unit population cap 25 to 200 units per player
Civilization sets Western European, Eastern European, Middle Eastern, Asian
Resolution 800X600
  1024X768
  1280X1024
Three terrain detail modes High detail - multi-pass, fast lower-quality filtering, RGB color calculation
  Medium detail - multi-pass, faster lower-quality filtering, RGB color calculation
  Low detail - single pass, 8 bit- color lookup

Number of players. The simplest scalable feature within AoK is the number of computer-controlled or human opponents or allies that a person chooses play with, which is up to eight players per game. The more players, the higher the performance required by each player's system. Up to four human or computer-controlled players can play on a minimum-specified system.

Map size. Related to the number of players is the size of the map. The map size is expressed in terms of numbers of players (for example, two-player map, four-player map, and so on). The number of players supported by a specific map size was determined by the distance that our game designers felt should be between player starting positions. But map size is independent of the number of players, so you can have a two-player game on a big eight-player map. This gives players the choice to accept our recommendations, space themselves out further, or squeeze in tighter. Based on our choice of four players for the minimum platform, the default map size is for four players.

Briton Wonder fortified by bombard cannon towers.

Population limit. The unit population cap sets the maximum number of units the player can build during a game. By default, this value is 75, but it can range between 25 and 200 units. Again, the user does not see this as scalability, but as a tweakable option for creating the perfect game. We chose to make 75 units the default population cap because game performance on the minimum platform degrades too much at the next higher population limit.

Different artwork. In addition to these scalable game options is also an implied, but generally unrealized, scalability in AoK's art assets. Each of the 13 civilizations in AoK is assigned to one of four sets of building art. Each building art set represents the area of the world where the civilization is from. For example, the Japanese use the Asian building art set and the Britons use the Western European building art set. There are also Eastern European and Middle Eastern art sets. These art sets not only have their own styles, each also has different styles of buildings for each of the four evolutionary ages in AoK: Dark Age, Feudal Age, Castle Age, and Imperial Age. In other words, an Asian Dark Age house looks different from an Asian Feudal Age house, or an Asian Castle Age house.

This "upgrade" of buildings within each art set as the ages progress creates an interesting memory allocation curve. In the beginning of the game, all the players use the Dark Age version of their particular art set. As the game progresses, players advance through the ages at different rates. Since the advancement to the next Age causes the building style to change for the player, new art must be loaded and displayed. This increase in memory allocation continues until all players again reach the same age.

Assuming all players start in the Dark Age and survive to the Imperial Age, the memory allocation exhibits bell curve behavior. The worst case is when there is a player in each of the four Ages at the same time, which sometimes happens in the middle of a game. If all the players in an eight-player game select civilizations from different art sets, they use at least twice as much memory as if they had chosen civilizations from the same art set.

Display resolution. This, along with the terrain detail (which is explained in a moment), is one of two scalability options within AoK that is outside the scope of the game's design concept. The default display resolution is 800x600, and can scale up to 1280x1024. Again, the lowest resolution was chosen for the minimum system.

Terrain detail. A terrain detail setting was introduced to reduce the amount of processor time required to draw 2D isometric terrain on slower computers by reducing the visual quality. Three levels of terrain detail are provided. The terrain highest detail setting uses multiple rendering passes, anisotropic filtering, and RGB color to bring out the best detail. The medium-detail setting replaces anisotropic filtering with a lower quality but faster filter; the low-detail setting uses flat shading and an eight-bit color lookup table similar to the terrain in the original AoE. No matter which terrain detail setting is used, the final display output only uses 256 colors.

The choice of which level of terrain detail to display is made automatically by AoK the first time it runs. Since all rendering is performed on the CPU, this decision is made quickly by using a test that gauges the CPU speed. Players can change the setting later using an in-game menu.

Unfortunately, scalable features that fall outside of the game design (such as the last two options above) are less likely to be understood by players. This lack of understanding can lead players to change settings, resulting in a negative impact on their game experience without them realizing what they did, and leave them unable to restore the original settings.

Key Lessons

After analyzing and improving the performance of AoK, our team learned some essential lessons that we hope to use to improve the quality and performance of our future products.

We hope it will improve your future games, as well. These lessons are:

  • Obtain objective performance information.
  • Don't leave performance issues until the code's completely done. Work to improve it throughout the course of the project.
  • Don't fall prey to the Seven Deadly Performance Sins.
  • Create a saved game, scenario, and/or recorded game system to capture performance workloads.
  • Make performance statistics easy to collect, see, and use.
  • If performance statistics aren't easy to use, they won't be used.
  • Set performance targets. If you don't know how far you should go, how do you know when you've gotten there?
  • Use a single memory allocation scheme.
  • When all else fails, create scalable versions of features.

 

Herb Marselas currently works at Ensemble Studios. He helped out on Age of Empires II: The Age of Kings. Shhhh! Please don't tell anyone he's working on a secret 3D-engine project called [deleted]. Previously, he worked at the Intel Platform Architecture Lab where he created the IPEAK Graphics Performance Toolkit. You can reach him at [email protected]

For more information and awknowledgements please refer to Profiling, Data Analysis, Scalability, and Magic Numbers: Meeting the Minimum Requirements for Age of Empires II: The Age of Kings


Article Start Previous Page 3 of 3

Related Jobs

Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[07.10.20]

Programmer (Character Technology team)
Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan
[07.10.20]

Experienced Game Developer
Klang Games GmbH
Klang Games GmbH — Berlin, Germany
[07.09.20]

AI Engineer (f/m/d)
Remedy Entertainment
Remedy Entertainment — Helsinki, Finland
[07.08.20]

Technical Director





Loading Comments

loader image