Obviously, “anim” is short for “animation”. Simply put, an anim file is a text file that tells the game which models and textures to use for a particular proto object. Every visible proto object defined in proto2.5.xml (or any other version of the proto) has an associated anim file. The name on the anim file must be exactly the same as the proto name of the object in order for the two to be linked. For example: proto object with name=”XYZ” must have anim file with name “XYZ_anim.txt”.

Anim modding in its pure form does not involve the creation of new art assets such as models, textures, and audio files nor does it involve editing the game data (proto, techtree, etc.). Pure anim modding is the rearrangement of existing art assets from the game to make new assets.
Anim modding is closely linked to data modding and shares basically the same skill set. Actions defined in the anim must come from object attributes or actions defined in the proto (more on this later). As I mentioned in the introduction, the anim is a link between art assets and data. The logic with which AoM handles objects can be broadly presented like this:

Data --> anim --> art

Data is at the core of the structure because the proto defines an object’s attributes (tags) and actions. The anim takes the tags and actions and links them to 3D models and audio files. But wait, there’s more. The anim can also change the textures that appear on a model or change the time during an animation at which a proto action is performed (for example, inflicting hack damage) or at which an audio plays (for example, a hack sound). If you haven’t done any modding before, you may find all this a bit difficult to understand, but don’t worry, the best way to learn anim modding is simply to open up an anim file and start messing with it!

Notepad++

https://notepad-plus-plus.org/download/v7.5.html

This is a simple text editor and integrated development environment (IDE) which we will use to pull texture names from model files. Once you download the app, open it and go to Plugins>Plugin Manager>Show Plugin Manager. Then scroll down to HEX-Editor, check it, and click install.

A basic understanding of data modding is required if you’re going to be successful in modding the anim. If you haven’t done any type of modding before, I strongly recommend that you read Stephen Caine’s comprehensive guide to modding[aom.heavengames.com] specifically sections 3.2 and 3.3 on proto object attributes and actions as well as chapter 5 on anim editing where he does a line-by-line dissection of the Jason anim file.

Another useful reference for data modding is Warrior Mario’s guide which comprehensively lists and describes proto and techtree tags and actions.

In your file explorer, navigate to wherever you have Steam installed. Then go to Steam\SteamApps\common\Age of Mythology\mods. In your mods folder, make a new subfolder and name it whatever you want, ex. “My Awesome Anim Mod”. Inside your new folder, make a subfolder called “anim”. Now go back to your Age of Mythology root and access the anim folder (Steam\SteamApps\common\Age of Mythology\anim). You should see a bunch of folders with version numbers on them. These folders were introduced in a patch in 2016 to separate files based on patch version. Everything 2.0 and higher is post DLC.

Let’s use the Hoplite as an example. Run a search in your file explorer for “hoplite” and the result will be a file called hoplite_anim.txt. Right click the file and go to Properties. Under the General tab, in Location you will see the file’s directory. The directory should be Steam\SteamApps\common\Age of Mythology\anim\version1.0. Now we know that the most recent version of the hoplite anim file is found in the version 1.0 folder (which means the devs haven’t touched it). Now let’s copy the anim file and go back to our mods folder. In our new anim folder, we need to make a subfolder called “version1.0” (if you’re unfamiliar with modding, this is so that we’ve replicated the directory in our mods folder so the mod manager knows where the file is supposed to be). Inside our new version1.0 folder, paste the hoplite anim file.

Open the copied hoplite anim file in a text editor. I usually use regular old Notepad for this but you may use your fancy new Notepad++ if you like. The anim file consists of three optional sections: imports, definitions, and animations. I say that these are optional because you don’t need an import section or a definitions section or an animation section but you need at least a definitions or an animations section. Fortunately for us, the hoplite anim has all three! At the very top of the file there is a header which has been “commented out” (any line of code starting with // or /* is only there for us to read [a comment] it doesn’t have any effect in the game). Typically, the header will just show the name of the file (although the devs were very lazy about this and you will discover that many anim files have incorrect header names). Because it’s commented out, the header has no bearing on the file so we can even delete it if we like.
Below the header is the imports section. Here, we see that the hoplite anim is importing two other anim files, namely Greek_Large_Shield_anim.txt and spear_defines_anim.txt. If you look in your AoM anim folder, you will find these files and if you open them up, you will see that they only consist of definition sections. The reason we import other anim files is therefore to save space. Imports are almost always used for weapons and shields. Instead of defining the same weapons and shields in the anim of every unit that uses them which would waste space, we can just have one line that imports those definitions from another anim file. By convention, imported anim files only contain definitions sections and no animations sections.

Now if we scroll down, we find the definitions section. This is where we define any attachments that aren’t imported. We see that the only attachment defined in the hoplite anim itself is called “Head”. If we were to look in the Greek_Large_Shiled anim and the spear_defines anim, we would see other attachments called “LargeGreekShield” and “spear” respectively. What are attachments? They’re just other models that attach to the base object model. They were made as individual models because several units use them (for example, lots of units use the spear anim). It would have been more cumbersome to design the weapons and shields as part of each unit’s models so instead, the 3D model of the unit just has “attach points” where other models can be attached. Attachments and attach points are the bread and butter of anim modding and you will quickly learn the frustration of discovering a unit’s weapons are part of the unit’s model instead of separate attachments (for example, most hero models have the weapons and head included with the body instead of separate attachments which is quite annoying and can only be fixed using a 3D modeling program). The types of attachments you will typically see are weapons, shields, heads, and embellishment objects or SFX.

If we scroll down further, we will find the animations section starting with the “Bored” animation and ending with the various “Cinematic” animations. All proto objects must have an animations section with at least a “None” or an “Idle” animation. Only anim files for attachments such as spear_defines are allowed to just have a definitions section. Now let’s look in detail at the definition and animation sections syntax.

Syntax is very important in any coding environment. Mess up the syntax and bad things happen so it is important to make sure you understand the basic structure and aren’t leaving out any } or misspelling anything in your anim file.

Both the definition and animation sections are broken into entries separated, by convention, by a bit of this //=====. Each entry in the definitions section starts with the word “define” and is followed by a word of your choosing that will be the label for that attachment for the rest of the anim file. Attachment names aren’t case sensitive so the “Head” for the hoplite can also be referred to as “head” elsewhere in the anim. Each entry in the animations section starts with the word “anim” but the next word is not arbitrary. There are only a limited number of animation classes used by the game. The full list can be found here.

Under these opening lines, there are bunch of nested { and } but you will notice a pattern that the nesting usually** goes: define/anim>SetSelector>set hotspot>version>Visual. Inside a SetSelector, you can have any number of set hotspots and inside a set hotspot you can have any number of versions however each version can only have a single visual model file. For the definitions section, we don’t need any SetSelectors unless we use logic tests (more on that later) but every entry in the animations section needs to start with a SetSelector.

The lowest level of the nesting will be a model file and will look something like this “Visual Infantry G Hoplite Head Standard” where Infantry G Hoplite Head Standard is the name of a model file (a BRG specifically) which you can find if you look in your models folder.

Note that in each entry, for every opening { there is a closing }. This is very important.

**see the wave_anim.txt file for an interesting exception to the nesting convention discussed in this section. This anim features an unsual hotspot SetSelector nested under a Visual line.

Now let’s return to that interesting line under the first SetSelector in define Head. It looks like this: TechLogic none/Medium Infantry/Heavy Infantry/Champion Infantry. This is called a logic test and it tells the game to use different set hotspots based on certain conditions. For TechLogic, the conditions are what technologies are active for the player. The set hotspots that follow a TechLogic or any other type of logic test are sequential meaning that the first one is for the case of “none” the second one is for the case where “Medium Infantry” is active, and so on. Some logic test are numerical, for example, the ConstructionLogic 0 25 50 75 which will use different set hotspots when a building is 0% complete, 25% complete and so on. In the case of the hoplite, this TechLogic line is telling the game to use different head models for different levels of technology.
If we scroll down to the anim Bored entry, we see that there are two tests being used, a CinematicLogic and a TechLogic. The first test: “are we in cinematic mode?” “no/yes” and the second test “do you have these technologies?” “1/2/3/4/5…”. Any logic test, such as CinematicLogic, which doesn’t have a series of techs separated by / or a series of numbers following it, is assumed to be “no/yes” or “false/true” and the order is important – the first SetSelector following the logic will be for the case of cinematic mode false and the second SetSelector will be for cinematic mode true (we can verify this by looking at the model names, in the first SetSelector we see Visual Infantry G Hoplite_BoredA and in the second SetSelector we see VisualGranny Hop_idleA, the granny files are a special animation type used for high detail cinematic models).

Hopefully you are beginning to see the vast creative power of anim modding. The devs never used more than three levels of nested logic tests for any object in the game. The reason for this remains unknown but there is no theoretical limit to the number of logic test variations you can utilize in your mod. For example, we could have a hero that has different models for the number of kills he got (experiencelogic) and the amount of damage he has sustained (damagelogic) and whether or not he’s carrying something (carrylogic) all running at the same time for each animation. Of course, this would make for a very long anim file and lots of unique textures and models would need to be made, but there is no reason it couldn’t be done.

A complete list of logic tests along with examples of their use can be found here.

It is important to note the different outcomes you get when you separate models by SetSelector vs. set hotspot vs. version. Models separated by SetSelector are also separated by the logic tests therein. Models separated by set hotspot aren’t separated by any logic tests so the game will simply chose one or the other at random and use that model until the action is complete (for example, a human soldier tasked to attack an enemy with one of two attack animations will use one or the other until the enemy is dead or the soldier is retasked). If we separate models only by version, then the game will chose randomly between them WHILE the action is being completed. We see this in the hoplite anim Attack where there are two versions under each set hotspot so that the hoplite switches between his spear thrust animation and his shield bash animation. If we were to separate the versions into their own set hotspots, then the hoplite would use one or the other attack until his task was complete.

Before we discuss the functions under the model, we first need to address an important point about how to call model files in the anim. Age of Mythology has four types of model files which are called in different ways. Looking at the Hoplite anim, we see that most model files are called with "Visual" but the cinematic models are called with "VisualGranny". Here is a list of other functions for calling models:

Visual - calls a BRG file (the most common model file type)

VisualGranny - calls a GRN file (high poly, skeleton animated models for cinematics)

Visuallightning - calls a LNG file (lightning bolts and Petosuchus beams)

VisualParticle - calls a PRT file (SFX, particles, user interface)

VisualNone - calls a DCL file (AutoCAD dialogue control language description, not a 3D model file, can be opened in notepad, controls shadows and selection circles), sometimes followed by the word "jimmy" which indicates no model

There are several other types of model calls defined in aomx.exe including VisualMesh and VisualSprite but these are unused.

Now let’s look at the other stuff under the Visual model name at the lowest level of nesting. These lines are called functions and there are a couple different types.
The connect function is used to attach attachments to different attach points on the visual model. For example, in the Hoplite’s Idle animation, there are three attachments for each tech level. They are attaching the spear, the LargeGreekShield, and the head to some attach points called RightHand, LeftForearm, and TopOfHead respectively. If you were to open up the Hoplite idle model in 3DS Max, you would see all these attach points and several others. Indeed, the hoplite along with other mortal infantry units is one of the most dynamic models in terms of anim modding because it has so many attach points. Any attachment that was defined in the definitions section or in an imported definitions section can be attached to any attach point.

Replacing textures on models is another key component of anim modding which allows us to make new objects that look completely new even though they’re using existing models and textures. As shown in Figure 3, the old texture name is separated from the new texture name by a “/”. Like the connect function, replacetexture isn’t case sensitive.

Obviously not all textures will look good on all models. Without viewing the textures in 3DS, we have to use a bit of trial and error in discovering which textures work.

Notice that for the Hoplite’s Idle animation, the first version doesn’t replace any textures and the subsequent three do. These are the different textures used by the hoplite at different technology levels. From looking at these replacetexture functions, we can tell that the base texture is Infantry G Hoplite Standard. The name is logical: G=Greek, E=Egyptian, N=Norse, X=Atlantean (x-pack), C=Chinese. Standard indicates that it’s before any technologies. But what if there weren’t already replacetexture functions to tell us what the base texture is? How would we replace the texture? Well, we could do a search in the textures folder and hope that the texture name uses the same logic as the hoplite textures (which most of them do). But we could also find the name of the texture with absolute certainty by checking the model file.

Go to the models folder and run a search for Infantry G Hoplite_IdleA. The result will be two BRG files with the same name (apparently it was updated in version2.0). Right click on the file and select open with Notepad++. You will see some random symbols and numbers and a bunch of NUL things. This is what an encrypted 3D model file looks like. Obviously it’s not much use to us. Now go to Plugins>HEX-Editor>View in HEX and scroll down to the bottom of the file.
Here, you will see a line that says MTRL followed by some texture names. These are the textures applied to the model.
For the hoplite body idle model, there is only one texture, but for some models like heroes, myth units, or buildings, there may be multiple texture files applied (typically, heroes and myth units will have two textures for the body and head). Now that we know the name of the base texture on the model, we can go back to the anim file and replacetexture to our heart’s content.

We now know how to look up the model’s texture but we don’t know which other textures will work with that model. Fortunately, most textures work with most models. It may surprise you to learn just how dynamic texture maps in AoM really are. The title image of this guide shows the Bondi (a hoplite model) texture applied to a dwarf gatherer and then a Hero Norse (Hersir) head texture applied to the dwarf gatherer’s head. This is possible not because the dwarf gatherer uses two models for body and head (like the hoplite) but because it uses two textures for one model which includes the body and head. Notice the dark spot on the helmet in the third frame where the Hersir’s horns are supposed to be. This is the type of thing that happens when you apply a texture to a similar but not exactly the same model. Sometimes the effect is minor as in this example, and sometimes the effect is very noticeable (as when, for example, you try to apply building textures to units or vice versa). Even with 3D modeling software, the only way to really tell how a texture is going to look on a model is to try it.

A significant portion of the time I spend anim modding is spent mix and matching textures. Sometimes it won’t work out, but sometimes you find something that looks really good and completely original.

Tags in an anim file are used to edit animation times whether that’s the duration of the entire animation or the time at which data effects like damage, footsteps, or sound happen.

Let’s scroll down to the Hoplite’s anim walk entry. In the lowest level of nesting, under the model name, we see some warnings about stuff that has been auto generated by the “bang animation tool” and not to hand edit these values.
We actually can hand edit these values – the warning is there because it might look silly if we do. In this example, we see that a left footstep texture is being placed on the ground (the footstep texture is specified in the proto, there are actually quite a few footstep textures in AoM) at the 0% mark of the Infantry G Hoplite_walkA animation. Then, at the 50% of that animation, there is a right footprint. It we change these values (between 0 and 1), the footsteps will be applied at different points during the animation, which indeed, will look quite silly if we don’t also edit the model animations.

If we scroll down further to the anim attack entry, we see different tags called Attack and GenericSound. Evidently, these tell the game to apply the hoplite’s hand attack action (from the proto) at the 49% mark of the Infantry G Hoplite_AttackA animation. Likewise, the sound specified in the hoplite’s sound XML file is played at the 40% mark. Notice the word “true” at the end of these lines. This indicates that the data and audio effects of footprint, attack, sound, etc. are only to be played if the action is completed.

Another highly interesting tag is the length tag. This is applied in a different syntax than the others. The picture below shows how the length tag is implemented in the uproot 6x6 birth animation.
In this case, it increases the length of the sfx c uproot 6x6_birth animation to 3 seconds. You can set the length tag to any value you like and it will extend or shorten the duration of model animations. We can imagine implementing this tag in conjunction with a cinematiclogic test to get the effect of slow motion units in cinematic mode.

Another lesser known tag is the timeoffset tag which puts a numerical time delay between playing each animation. This is used by waves.

There are only a few types of tags available to anim modders. Not all of them are used in the Hoplite anim. Here is a list based on my preliminary investigation.

SpecificSoundSet – calls a specific soundset name from the soundsets-xpack.xml

GenericSound – calls a generic sound type from the proto, played for any player if object is on screen, no checks

FootstepLeft

FootstepRight

Attack – implements hand attack damage or the launching of a projectile

Pickup – implements pickup (e.g. Cyclops)

Throw – implements throw (e.g. Cyclops)


The SpecificSoundSet tag makes use of two types of checks for playing audio.

checkVisible – plays sound for all players if the object is on the screen

checkOwner – plays sound only for the owning player regardless of whether or not object is on the screen

The Fire Giant anim makes use a number of tags in interesting ways.
Notice that this is an Attack anim entry even though the proto entry for Fire Giant has no hand attack action. This anim entry must not be used. Note as well that there are multiple attack tags at different points in the animation, this is allowed for any tag. Finally, notice all of the commented out throw tags. It looks like ES originally intended the Fire Giant to have quite an interesting attack of some sort.

As discussed previously, when the game is running, it is running in one of three modes at all times: scenario, editor, and cinematic. Even the main menu is running a scenario with some overlain user interface textures and buttons. Scenario can be thought of as the default mode with editor and cinematic being special cases. There are logic tests to test if editor mode (EditorModeLogic) and cinematic mode (CinematicLogic) are active. In addition, there is an anim action called “anim Cinematic” which simply contains the models and textures for special actions that an object can perform during a cinematic as specified by cinematic triggers. If we scroll to the bottom of the hoplite anim file, we will find this entry which contains five different special animations. We see that all of these use the HD granny model files (the cinematic hoplite). All sections are separated by a set hotspot and include the name of the animation in the line above the version. You must follow this format or the game won’t read your cinematic animations in the editor.

Cinematics are special because the anim Cinematic is the only anim action that isn’t linked to either a proto attribute (tag) or action. However, cinematics can only be called while cinematic mode is active.

Just as every visible object in AoM has an associated anim file with the same proto name, every object with audio has an associated snds.xml file with the same proto name. The snds or sound file is essentially an anim file for audio so I want to briefly discuss its syntax and properties as I think it falls under the purview of anim modding.

Data --> snds --> audio

Go to your Age of Mythology\sound folder and run a search for hoplite. The result will be hoplite_snds.xml. If you wish, you may make a copy and put in your mod’s sound folder. Open the file with a text editor. At first glance, the syntax looks very different from an anim file but the logical structure is actually quite similar and very intuitive.

The first thing we need to do when editing or making a snds file is make sure the name in the title and the name in the line <protounit name="Hoplite"> both match the correct proto name. The organization of the file is very straightforward. Like an anim file, it is just a series of actions linked to soundset names (which link to audio files). The sound actions are different than the anim actions and include things like Select, Grunt, Hit, etc. Likewise, there are new logic tests such as damagetypelogic and targetlogic. Instead of SetSelectors, we now have “choice name” lines and instead of Visual before a model name we now have soundset name before a sound. Please note that these soundset names are not the names of .mp3 or .wav files that you will find in your sound folder. Rather, they are the names of entries in the soundsets-xpack.xml file which is located in your sound folder. If you open up this file, you will see all of the soundset names defined with their associated audio files. Some soundset names have multiple audio files associated with them and these are picked at random when the soundset name is called. For example, the first soundset name under the Hit action in the Hoplite snds file is called MetalSlice. If we do a search for that soundset name in the soundsets-xpack.xml file, we see that there are 12 different audio files that can be used. So, whereas the anim file contains all of the random variations within itself through the use of logic tests, the randomness in sound files is mostly contained in the soundsets-xpack.xml.

I encourage you to take a look at the villager greek_snds.xml file for a good example of the types of logic tests found in snds files.

By far the most complicated anim files in AoM are those used for buildings especially those shared by multiple civilizations. Even though buildings typically only have Idle and Death animations, they make use of an intense amount of logic tests for civilizations, ages, level of construction, and level of damage. To make these cumbersome files easier to edit, ES courteously separated the major logic test sections by commented lines telling us the civ and the age. Of course, aside from their length, building anims work in just the same way as any other anim file and follow all the same rules.

By far the simplest anim files are SFX objects and attachments. Attachment files contain only a definitions sections by convention (as previously discussed). SFX files usually have some attachments and then only a None or Idle animation. None should only be used if there is no idle animation (i.e., the object will be completely motionless). If you want an idle animation to play, use anim Idle. Obviously, SFX objects just sit there and don’t do anything so they only need an Idle animation.

As with any modding discipline, reading a guide is only a starting point. To learn the skill, you have to jump right in and start editing. Hopefully, in the course of reading this guide, you have come up with some interesting ideas for what can be done with anim modding and I encourage you to test out those ideas and share them. Furthermore, please leave any suggestions for the guide itself in the comments.

Before concluding this guide, I would like to briefly draw attention to the issue of desync-sensitive anim mods. In the original disk versions of AoM, a wide variety of anim mods were online compatible. This changed in EE when the devs flagged all anim mods as desync-sensitive supposedly because of the issue of cheating (it is certainly possible to use the anim to increase the rate at which a unit inflicts damage, for example). However, there are methods of separating harmful anim mods from benign, aesthetic anim mods. In particular, WarriorMario developed an app for making this distinction which was unfortunately never incorporated into EE. Hopefully the game’s developers will rectify this situation so that anim mods will once again be online compatible.