Rome: Total War (idea)

Rome – Total War (RTW), developed by The Creative Assembly and published by Activision, is a game of empire building and grand strategy set around the rise of the Roman Republic and its transformation into an empire spanning the known world. Gameplay is divided in two sections: the strategic empire-management “world map” component, and the tactical army combat. The strategic component is played out on a three-dimensional map of Europe as it was around 0AD, and is concerned with high-level city management, diplomacy and army maneuvering. The tactical component is a game unto itself, as the player commands his armies against his opponent, with potentially thousands of individual soldiers on either side. Due to the highly discrete nature of the two parts of the gameplay, this case study will examine one design aspect from both, namely, the world building of the strategic element, and graphical concerns in the tactical element.

The world building elements of Rome – Total War are designed to be as accessible and alterable as possible, and such allow a great deal of insight into the methods and reasons used. Although the world map is fully 3D, it is rendered by the game engine from data composited from a series of images that function like height maps (including one that is a height map). Although each image defines different aspects of the map, each holds to the same conventions. Each image is either the same size, twice the size, or twice plus 1 pixel, and each pixel holds the data for a different tile in the world map grid. These images include:

Map_heights.tga
This mostly greyscale image defines the area of the map that is rendered as sea area (the blue colour) and includes all the data on how high each spot on the map grid is, with pure black being sea level and white being the highest mountain top.

Map_regions.tga
This image is the “political map” of the game, defining the borders between each region, and the location of every city and port facility. The image is limited to 255 colours, and since each region must be have a different, however slight, RGB value, there are a maximum of 200 regions in RTW.

Map_ground_types.tga
This image holds the data for what kind of terrain each tile is, like impassable mountain, plains, swamps, forests, shallow coastal water or deep ocean water. Each different terrain type has a different RGB value, with shades of red for ocean depths, shades of green for the varieties of forested or clear terrain, white for beaches (the only areas ships can disembark troops), blue for swamps, greys for mountainous areas, and others.

Map_features.tga
This image holds the data for the location of specific terrain features not defined by other images, like rivers, cliffs and volcanoes. Black area is, for the purposes of the image, featureless, and yellow is for cliffs, blue for rivers, and so on.

Map_climates.tga
This image is the last of the ‘key’ image files, and defines the climate types for each tile. Climates are represented by different RGB values, and alter whether that tile gets snowy in winter, whether fighting there in the summer causes heat exhaustion for troops and other effects both cosmetic and otherwise.

On game load, the engine takes the data from all of these image files and a collection of text files and compiles them into a cache file called ‘map.rwm’, which is then always used by the engine to save load time. The only time this file is updated is when it has been deleted and the game must recompile it. These design choices, though perhaps not the most efficient, definitely achieve a goal that Creative Assembly has always seemed to pursue: making the game as expandable and moddable as possible. While using a prerendered map would have marginally sped up loading and rendering times, the game sells far more copies with the vast amount of user customization that is possible. Indeed, Rome - Total Realism, a major mod that has just released v6.0, has had over 100,000 downloads (80,000 of those in one day), and has been featured on the cover of magazines like PC Gamer-UK.

Another interesting facet to the world building of RTW also relates the exposed nature of the game data. Almost everything that is not graphical is stored in plain-English text files in the game’s subdirectories, from projectile ranges and damages, to animation and skeleton definitions to the set up of the world.

When it comes to the set-up of the game world, everything is stored in a series of text files that cover everything. Once the engine has finished creating the render data for the game world, it gathers all the ‘political’ information from these text files, including territory and city names; initial army placement and composition; city populations, growth rates, and developments; AI settings; diplomatic relations; character names, ages and personality ‘Traits’, and; victory conditions. All of this data is then added to the map.rwm file and the game is loaded. Also note that the game allows for multiple different game worlds to be accessible, each with their own maps, settings and environments, although graphical assets and unit statistics are universal.

The final aspect of RTW’s world building elements this case study covers is the interaction between the strategic world map and the tactical battle areas. Since each army is free to roam the world map at will (excepting of course impassable areas like high mountains), it would be hard if not impossible to create stock and reusable battle maps to reflect the area the battle takes place in without the repetition becoming hideously obvious and detracting from gameplay. Instead, each battle map is rendered individually based on the terrain data from the tiles occupied by the contesting armies, providing for endless replayability and a deep connection between the player’s actions and the game world. Although the actual battle is limited to a given area of several square kilometers, a great deal of terrain is rendered around the battle area, leaving visible features like ships in the nearby sea and erupting volcanoes. Also, during city sieges, each and every building and city improvement present in the city on the strategic map are present in the battle area, and any damage to those buildings carries over to the strategic map, which not only further deepens that connection between actions and consequences but also gives rise to a whole host of viable hit-and-run tactics.

Because the battle environment of RTW is fully 3D, with each of potentially thousands of soldiers rendered individually, certain graphic trade-offs and design decisions were made, decisions which greatly streamline gameplay and reduce processor demands while still making for an enjoyable game experience.

Unlike in first-person shooters and other 3D game environments, collision detection in RTW battles is extremely limited. Beyond insuring that units do not walk through, but do fall off of (which leads to some amusing emergent gameplay) walls and that soldiers do not simply pass through each other, there is little collision detection actually computed. Battering rams do not actually pound on city walls, rather they just play their battering animation while the gates play their ‘getting hit’ animation and change visible states as they are damaged. Similarly, arrows do not actually strike soldiers. Rather, the arrows fly at their target, and any units within that target area compute damage that would be received, and the appropriate number of soldiers play their death animation. It is actually possible to watch this happen on close zoom, as soldiers who were not hit by arrows die, and then count the arrows in the ground after the volley and get the same number as were fired, even if numerous soldiers died. This same mechanic is carried over into unit on unit melee combat. Units are treated as gestalt entities made up of each individual soldier. Damage is calculated against the unit as a whole, and soldiers ‘die’ at the appropriate time, regardless of what’s going on around them. Whenever two units are in contact, the appropriate animations are played and, if you don’t watch too closely and carefully, it looks like vicious combat. Soldiers, on closer inspection, just wave their weapons in the appropriate direction while their enemies do the same, much like the three-quarters technique used in film for massed battles. The only minor exception to this is for officers and special characters like named army generals. They are attached to and inseparable from their unit, but they have slightly different statistics from the rank-and-file, and so are given slightly more specific collision detection.

In a similar vein, due to the large battle areas and the potentially vast number of entities to be rendered, RTW uses several tricks to decrease processor demands. Firstly, the actual environment, with a few notable exceptions like buildings, walls and trees, is completely static and is likely only rendered much less frequently as it is quite large and huge sections of it can be visible at any one time, yet never appears to contribute to reduced framerates. For the soldiers, RTW actually uses two separate entities for each one. One is the actual detailed 3D model and the other is a much more simplistic 2D sprite. The game switches this back and forth during render depending on the camera’s distance from the soldier in question, and the render decision is actually based on individual soldiers, not units, so that it is possible for half of a unit to be sprites and the others actual models. While this is not particularly evident at first, it becomes moreso on low graphics settings where the switch line is quite close to the camera, and when using fan-made unit graphics that do not have corresponding sprites.

The final aspect of RTW covered in this case study is animation in the battle element. While RTW does use skeleton-based animation like most 3D games, it is a much more limited form, as all of the animations are arbitrary responses to given states and not free-form reactions to the game environment. Instead of the joint-based skeletons typically seen in 3D games, RTW models are simply a texture mesh weighted to a series of completely unconnected ‘bones’ and the animations are just key-framed sequences of those bones moving and pulling the mesh with them. While this does increase the difficulty level of modifying or creating new animations for RTW, it was a decision made for several reasons. First, without the need to compute the interactions between joints and the texture mesh, processor demands are reduced by a significant amount, and second, RTW uses little to nothing in the way of animation blending or even transitions. Because the player camera is generally in a bird’s-eye perspective and concerned more with the big picture and not with the actions of individuals (unlike FPS games), this amount of detail is not only not needed, but even wasteful.

As can be seen in this case study, Rome – Total War makes a number of interesting trade-offs between efficiency and detail, with the emphasis on the latter in the world building and the former in the battle element. These tradeoffs were made with the total user experience in mind, insuring playability and reducing the need for prohibitively high-end technical requirements which might have resulting from the ability to have literally tens of thousands of individual soldiers on one battlefield or having an empire spanning an entire continent or, with the user-created content available, most of this or other worlds. And by and large, the game succeeds at what it attempts.

Node your homework