Generally speaking, unittypes are used to define a particular unit in-game - such as a monster, a champion, a summoned monster and so on. I will begin with a general overview of the unittype container, then I will describe how to differentiate these different groups from each other - each different sort of unittype will need different tags.
First, I've posted the xml of a unit here: http://pastebin.com/raw.php?i=CUwX44qS .
Let's go through the tags from the top.
<Quote>'Any invading force will dine upon my blade.'</Quote>
These are all string values read by the engine. DisplayName dictates the name of the unit. BackStory dictates the Hiergamenon entry for the unit (listed as "history"). The Quote is the quote seen on the infocard of the unit.
These define the modelpath and the skeletons used for the unit. Note that these must "match", in the sense that the model must be built specifically for the model. Unless you are tampering with making new models, simply gather the information you need from the core files.
This defines the eye texture of the unit. Note that not all units have eyes, but this tag must nevertheless be included in all unittypes.
This defines the animationpack used by the unit. If you are copying a monster or a mount or anything non-humanoid, you'll want to copy what animationpack to use as well. For a list of all the animationpacks, visit your installation directory and navigate to ...\Elemental\data\Animations\. If you simply wish to find an appropriate animationpack for a unit, I suggest you create a new sovereign, choose a cool animationpack and then copy the tag reference from the sovereign xml.
This tag lacks purpose.
These tags define certain scales used to make things larger or smaller. However, they can be quite troublesome to use.
First, if a unit has a <ModelScale> OTHER than 1, any <gameitemtypemodel> (used to define models for items, remember?) that requires the tag <AttachmentType>Skinned</AttachmentType> will render incorrectly. This fact means that most humanoid unittypes can not simply be increased in size, because their heads are in reality gameitemtypemodels with the tag <AttachmentType>Skinned</AttachmentType>.
Secondly, <EquipmentScale> seems to scale inversely with the ModelScale used. If I were to give a unit ModelScale 2.0, I would then be forced to give it an equipmentscale of 0.5.
<ClothMapScale> appears to tell us the upper limit of the size of the unit on the cloth map. Let's say I assign a unit a ModelScale of 4. This unit would be insanely large. However, we might not want it to appear that way on the cloth map. We can then use <ClothMapScale> to override that value.
Tells us where the unit can move. Values are land, air or water. Air units may cross any tile, and may carry any unit with them while doing so. Water units may cross any water tile, and beaches, and carry any unit with them while doing so. Land units are the default type, and may not cross water or cliffs or mountains. Note that Air units still suffer movement penalty while moving through forest tiles.
Unknown. Bobbing in units is usually associated with a first person view. Possibly a hint that at one point players would be able to view the game through that perspective.
These tags all define what the tooltip and infocard of a unit will look like. ClothPoseIndex seems to reference a list, but I haven't found it in the game XML. Values can vary from 0 to 16 (possibly higher), or up to 3 for mounted units. ClothPoseIndex essentially defines what pose the unit will have on its infocard.
<InfoCardBackground> tells the game what background the unit should have on tooltips and its infocard. It is a reference to types found in CoreInfoCardBackgrounds.xml.
<InfoCardBackgroundFlipped> is a simple 0 or 1, depending on if you want the <InfoCardBackground> flipped horizontally or not (0 = not flipped).
What sound the unit plays while moving.
Note that the LevelMileStone is a sub-container of the unittype container. It contains tags of various unit stats. These milestone tags can NOT be used to define how a unit will change as it levels up - a trained unit always assumes the stats of level 1.
Milestones can be used to increase difficulty of world monsters, however. See CoreMonsterUnitTypes.xml for examples on how to make higher level monsters have different stats compared to the level 1 version.
The equipment tag defines what items the unit is wearing. Notice how the head is treated as an item, and not part of the body. If an item has a prerequisite for technology before it can be built, this is inherited by the unittype (you cannot train a legendary plate helm wearer until you've researched legendary plate helm). If the unit had hair, it would also be listed as a piece of equipment.
These tags define underlying colours of models used inside the unittype. The values are in RGB format, and the fourth value lacks apparent purpose. For a unittype, the only important things here are <Color_Hair>, <Color_Skin>, <Color_Clothing1>, <Color_Clothing2> and <Color_Metal>.
If you wish to test colours in-game, I suggest you create a custom sovereign and play around with his colours.
The first tag defines what texture will be used on the body and head of a unit. For a list of valid textures, see CoreSkins.xml. If you are designing monsters, copy the skin file call from the core files.
The second tag, again, defines what texture will be used on the eyes of the head of a unit. I suggest that you give this the same value as you gave <EyeTexture>.
First, the gender is telling us what the gender of the unittype is. This is used for two things - champions being eligible for marrying, and StartingType units (see below).
Second, the UnitModelType has already been covered in the Items section of this guide. The unitModelType helps define what pieces of clothing it can and can't wear. In addition, the UnitModelType helps assign random skins, heads, hair and clothes to a unit (see advanced section for more on this).
Those are all the "default" tags, you'll need them for any unittype. The rest of the tags are actually used to tell the engine what kind of unit this is. Now I will describe how to differentiate between the unittypes.
Treating a unittype as if it was designed by the user
<CanBeDesigned> tells us that this unit can be put in the training window - it can be trained. In addition, the tag is telling the engine that if this unit is available, it can be used to design other sorts of units based on this unittype - essentially Upgrading them in the unit design window in-game.
<UserDesigned> lets the engine know that this unittype has been designed by the user. This means it can be deleted using the Retire Button.
<CreatorFactionName> references a RaceConfig (a faction), and the unit may only be built for this faction.
Treating a unittype as if it was a champion
Take a look at CoreNPCunits.xml. I have no experience with this.
Treating a unittype as if it was a monster
The first tag tells the engine this unit can't be trained.
The second tag appears to be the only tag that defines what a monster is. The spawnrating value is defining at what research level the unit will start spawning. Note that the <SpawnRating> tag is used for champions as well, but champions have additonal tags to separate them from monsters.
Treating a unittype as if it was a sovereign
The first tag tells the engine this unit can't be trained.
The second tag defines the unittype as a sovereign, allowing it to show up when the player is choosing a sovereign to play the game with. Some unittypes will contain an <IsSovereign> tag with a value of 0. This seems to serve no purpose.
Treating a unittype as if it was a diplomacy unit
The first tag is a switch that lets the engine know this unit should ignore the additional training time associated with a certain weapon. The weapon still causes the unit to cost resources.
The <ProductionRequirement> set of tags is the same as seen in improvements or items. In this case, the unit costs 50 gildar to train.
<RequiresCityUnlock>1</RequiresCityUnlock> defines the unit as something that needs to be unlocked by a particular building in a city before it is available. What building is needed is defined in the following <Prereq> set of tags.
<CanBeDesigned> defines the unit as something that can be trained and <IsUniqueButBuildable>1</IsUniqueButBuildable> lets the engine know that this unit cannot be upgraded by the user in the unit design window.
Note that the game gathers information from the improvementtype containing the BuildingRequirement attribute, in the example DarklingRecruiting. If the improvementtype is available only when built on a world resource, the unittype will only appear in a city once it is connected to that improvementtype. However, if the improvementtype does not require a world resource to be built, the unittype will be available in every city but greyed out - for an example of this, see the Empire Sion unit.
Treating a unittype as if it was a startingtype unit
A startingtype unit is a unit that is a schematic unit that is visible when selecting a certain faction
Note that the RaceConfig defining a faction is ultimately responsible for how these units are treated, depending on what tag the raceconfig references the unittype from. More of this in the raceconfig section.
These tags are necessary for a startingtype unit:
In addition, a startingtype unit should NOT include ANY of the colour tags as listed above for all unittypes. These colours are instead inherited from the raceconfig.
These startingtype units are what the game draws from, for a faction, when the player opens up the unit design window and clicks "new unit". These startingtype units are similarly used by the AI when it automatically designs units to use.
Making a unit cost "used population"
The same use as in improvementtypes. Values may vary.
It is important to note that when you "upgrade" a unit, the tags within that unittype are all inherited to the new unittype created. This can be used to, for example, create a line of units that all have a certain skin colour. Of course, if the player upgrades a unit, then randomizes its appearance using the randomize button, the random things (discussed in the advanced section) will all be rerolled according to UnitModelType.
? If I wanted to make a startingtype unit cost 1 food, how would I achieve that? How do you think the AI would react to this?
? I have not covered how to create a unittype intended for summoning. Why do you think that is?
Making a unit "unique"
This will prevent the unit from being trained in groups. Dragons and demons are examples.
Making a unit stay in the center of the tile
This will prevent a unit from leaving the center of a tile in tactical combat. Units will by default "move to the edge of the tile" when attacking or defending. This makes them always stay in the center of the tile. It is suitable for "unique" units, or for very large units.
Making a unit cost extra turns to train
0 by default, this value can be both positive and negative. Units cost 3 turns, which is defined elsewhere, to train by default in the game. If the value of this tag was 2, the unit would take 5 turns to train.
Wage override to a value
This tag can be used to override the wage assigned to a unit when it is trained. If this value is 0, the tag is not in use. If this value is above 0, the value automatically replaces the wage cost of the unit. If I wanted to design a unit that would appear to have no wage, but still defect if there were no gildar in the kingdom/empire, I would give this a value of 0.00001.
Wage override to nothing
This tag overrides any wage the unit will be assigned when trained, and the unit will permanentally cost 0.0000000 gildar per turn in upkeep.
Making a unit's attacks use an in-game effect
With this, a unit will display an effect on an enemy whenever it attacks in tactical combat
Making a unit display an effect when attacked
Similarly, this will display a certain effect on the body of the unit if it is attacked in tactical combat
Overriding the auto-generated tooltips and infocard pictures
If you don't want to show an autogenerated picture for a unit, you can include this:
Randomized clothes, heads, hairstyles and skins
Now that you've learned what a <UnitModelType> is, and what a StartingType unit is, let's talk about how skins, clothes, hairstyles and heads are randomly chosen when designing a "new" unit.
This is an example of a head:
<DisplayName>Kingdom - Sovereign Female Head 1</DisplayName>
Note the <SupportedUnitModelType>, defining what modeltypes this face may be randomly assigned to. Note the <RandomPeasantUnitLiklihood> tag and its other formats, defining the likelihood of this particular face appearing. Lilklihood tags are weighted against each other - if three faces each have 50 liklihood, then they have a 33% chance of appearing. However, if two faces have 50 and one head has 100, the last head has a 50% chance of appearing.
Hairstyles are generated the same way
<DisplayName>Short Peasant Hair</DisplayName>
<!--Item Equip Information-->
And so are clothes.
But these gameitemtypes appear to have nothing special about them, except the liklihood tags. This is not enough to make clothes and such be automatically generated when you are designing a new unit.
In fact, the engine is hardcoded to look for certain <Type> and <Subtype> tags in gamefiles. For example, clothes all have the <SubType>Clothes</SubType> tag.
Skins are handled differently. When designing a new unit, the game draws skins from a series of UnitSkinTextureDef such as this:
<DisplayName>Male Sovereign Skin - Default</DisplayName>
If a modeltype has NO UnitSkinTextureDef assigned to it, it will always default to the <Skin_Texture> the unittype has. However, if it HAS a UnitSkinTextureDef or more assigned to it, it will always randomly change out the skin of the StartingUnit.
Caravans, traders and shopkeepers
There are more tags that will make units show non-standard behaviour.
Caravans are not referenced in the raceconfig, but traders and shopkeepers are.
A caravan will have the following tag
This tag has two functions: first the unit may not be grouped with any other unit. And in addition the unittype automatically costs "available caravans" from a city.
A trader will also have the <IsCaravan> tag. A trader is a unit that automatically replaces the caravan once it has established its route (when it reaches a city it wasn't built in).
A shopkeeper unittype is the unit that will show when the player visits the item shop in a city. It has no special tags, but is uniquely identified in the raceconfig.
? Knowing that heads are in fact randomized gameitemtypes, how can we use this to give units designed by the AI random bonuses? Why is it a bad idea to do the same for clothes and hairstyles?