Creative Assembly and Moddability


It is unquestionable that, along with high production values and excellent gameplay, the incredible moddability of the Total War franchise games is the reason for their success and enduring fan base. The enabling and encouragement of user-created content (some of which has achieved more recognition, acclaim and playtime than the vast majority of console titles ever made) is accomplished in a number of ways, even when these techniques actually make for more work for Creative Assembly. However, these techniques are not without their apparent flaws, many of which Creative Assembly, oddly, continues to repeat with every iteration of the franchise.

The first and most important method Creative Assembly uses in insuring their games are as moddable as possible is by exposing most of the game files in plain-English text files. While the main game logic and all the calculations are hard-coded and untouchable in the .exe file, almost all of the variables and data used in the logic, like unit statistics and abilities, are exposed. This makes minor modifications quite simple, if perhaps a little time-consuming. Like the unit stats, everything from the names used for characters to the distribution of resources on the map to the setup of the game factions is exposed and easily modifiable.

Since such a major part of any strategy game modification consists of more than just altering unit behaviour and balance, the games’ graphics files have, in each iteration of the franchise, become more and more exposed. In Shogun and Medieval, the unit graphics were sprite files that were arranged in large arrays inside single images, while in Rome, each unit has its own 3D model and separate skeletal animations. While in none of the games were the graphical components immediately exposed and modifiable, Creative Assembly worked with fans to develop community-maintained tools to accomplish this, like uncompressors and 3D Studio Max plugins. Offering the support and time of the actual series developers to the community where other companies have delivered ‘cease and desist’ orders has only helped their products sell and maintain an unusually long shelf life.

The other major component of the Total War games is the ‘strategy map.’ As the first iteration, Shogun’s campaign map was nigh-unalterable without significant effort. After a great deal of research and experimentation, Medieval’s campaign map was completely alterable with the aid of community-made tools. In the latest game, Rome, the campaign map is now both completely 3D and easily modifiable. Instead of requiring a rather arcane and pre-compiled image file to turn into the campaign map like Shogun and Medieval, Rome instead compiles the campaign map at runtime out of a collection of height-map images and similar images containing the information in easy-to-create colour-code format. For example, the terrain is built of a grayscale height-map, the tileset information is defined by another image based on the RGB value of each pixel, and the region borders and city locations by another image, again based on pixel RGB values. Needless to say, modding Rome is so well-supported that it has created a community of literally tens of thousands.

However, for all this continually increasing support and encouragement of modding the Total War games, Creative Assembly has continued to repeat a predictable pattern and perplexing pattern with each game. That is not to say it is entirely bad, however.

Every Total War game to date has had a couple patches released, and then an expansion. With the initial release, the elements designed to make the game moddable are reduced or more difficult to access, but become increasingly available with each patch, and then the expansion is released and the proverbial floodgates are opened. The perplexing part of this pattern is that it appears as though they deliberately do not include all the elements they used on the previous game, and wait for a whole new round of community response before incorporating many of the exact same elements and features as they did in the previous game’s patches. (Incidentally, this is the exact same pattern they go through with the opponent AI, although that is beyond the scope of this analysis.)

While there is no real ‘official’ explanation for this recurring pattern, there is a likely explanation from a game designer perspective. As mentioned above, building the game engine to be as moddable as possible actually increases the amount of design work and time for the developers (though incidentally reducing turning, balancing and iterating time), which is exactly why the vast majority of games are not released with this kind of capability. With this in mind, the initial release of the game is built on the very valid assumption that patches will have to be released anyways, and the community feedback on the moddability will be, while somewhat a repeat of previous games’ feedback, directly informative on what the community wants and needs that was not provided for in the initial release. This would greatly reduce the amount of guesswork required on the developers’ part, reduce the amount of unnecessary or redundant work and, thus, allow the developers to focus on exactly what they need to.

While it may not seem so on the surface, the process Creative Assembly appears to go through when designing and expanding their games with the modder in mind is actually quite efficient and purposeful, and leads to better games with far greater modding potential than might otherwise be realized.