Military Model VI

[LFS]

though seriously armies wandering past each other did happen, yes fix the bug, but don't remove the ability to reintroduced a more controlled way of allowing the enemy to slip past.

[LDiCesare]

The armies slipping past one another can happen if you make a forward march and just crash into opponents, who can't really retreat... I must just make sure that static armies on sentry duty don't allow armies to pass by them easily because it would spoil the strategic aspect of chokepoints.

Now good news. In the last hour I implemented experience, healing units and changing the amount of damage dealt during fights. Most things were already almost coded, so it was quite fast. I still have to provide feedback for experience levels (ranges 0-5, progression as a square root. 1 fight = 1, 25 fights = 5, will need some divisions because 1 turn of fights is actually 10 fights so you get veteran too fast).
The good news is that a pyrrhic factor of 0.5 provides HUGE differences. To be sure, I will have to provide the xml customization so anyone can tweak the figure and see what effects are. I think using a lot of archers in big armies accounted a lot for the little damage I withstood (enemy units suffered huge ranged damage when they were 5000 men vs. 30000, like 4000 dead).
Then I changed the amount of damage dealt. I have a divider at some place in the code that I'll probably expose too so by changing the xml you can change how fights occur. The previous value was 10 and provided for fights lasting 1 or 2 turns. I set it to 100 (ten times less damage per turn, add healing of half damage sustained to that), and the fight between Scipio and Hannibal lasted at least 5 turns before I got rid of the last Carthaginian scum.
So now I have to put these things into an xml file. With the tech rehaul, I will try to get some tech output for Richard and we should have a good testbed to tune the various scenarios.

[Mark_Everson]

Sounds Great Laurent, I can't wait to play the version once its stable! Good Stuff!

[Richard Bruns]

Sounds really good. Hopefully I can start doing real work with the testbed soon. Note that the feature requests here are for future versions; I don´t want the testbed to be delayed. I have built up quite a big "wish list" of features that may or may not already be on the drawing board.

I have been hunting for details on the military model, following links form this thread and the website, but all I seem to get is really old write-ups from people who aren´t in the project anymore. There seems to be a disconnect between what is written up in the model, what I see in the logs, and what is in the xml file. For example, there is nothing in the xml file that describes how an element´s long range power is different from its melee power. I see that archers have the support order instead of the attack order, but that seems to be the only difference.

Do the fortifications that engineers build follow the same rules as the fortifications built through the econ GUI? I noticed that engineers and their forts have been in the game a lot longer than the siege model.

I have a question about the Orders available to a unit. Suppose I am designing a scenario and I want my primary attack element to have a small amount of wall-breaching capacity once a certain technology is discovered. This would be done by setting the basevalue to some high knowledge level and tuning the effect so that the value of the breach command is zero when the tech has a knowledge of zero.

If I add this breach order and value, will it execute both commands during a siege, or just one? Will it breach the wall and then attack, or only do one? I wouldn´t want the breach comand to stop it from attacking, since that is its primary function.

Would there be any negative effect associated with attempting to execute a Breach order that has a value of zero?

Also, can technology change the cost of something? That´s a question, not a request. It isn´t really important, but it might be nice to use.

Can we make the health recovery rates, the pyrrhic factor, different for each element, describing it as an individual attribute rather than a global one? That way some elements could heal better than others, and it could use the already existing mechanisms for application effectiveness due to knowldge.

How do experience levels work? It sounds like it uses a seperate mechanism than the tech model. IMO it would be good to link the two, but it isn´t necessary.

Ideally, each unit would have an attribute that describes which activity it feeds RP´s to after a battle, and a number that multiplies the base battle RP generation. That way a militia levy could only provide a small benefit to the Infantry Activity, but an elite cavalry unit provides a big boost to the Cavalry Activity.

In addition to giving these battle RP´s to the civ, each unit also remembers how many RP´s it has accumulated. These RP´s serve as the unit´s experience. The unit starts at a knowledge of zero in all techs that its activity feeds RP´s to, and raises that knowledge using the same mechanism as the tech model, including the use of helper techs. When the time comes to calculate the application effectiveness of the unit, the civ´s knowledge is added to the unit´s knowledge. Obviously this is a big, long-term change, but I think it could be worth it. We´ll see how well the current system works.

One thing I would like to see in the future is to differentiate between a "Move" command and a "Move and Engage" command. The former would work like movement does now, but if the latter is selected, the unit would actively seek out fights, even moving to a different square to fight an enemy. This could help prevent armies sliding past each other. A "Pursue" command would also be nice, so that the TF checks the lication of a certain enemy TF every click and moves to intercept. Earlier military write-ups mentioned zomething about a Zone of Detection; it would be good to implement a TF fighting anything that comes into its ZOD.

I also think that it would be good if the population to build a military unit to come form all over the province. That was mentioned earlier in this thread, but population to build the unit still only comes from the province capitol.

[LDiCesare]

Originally posted by Richard Bruns
I have been hunting for details on the military model, following links form this thread and the website, but all I seem to get is really old write-ups from people who aren´t in the project anymore. There seems to be a disconnect between what is written up in the model, what I see in the logs, and what is in the xml file.

The best place to look at is the following thread: Military Coding status. It might be worth linking to it from the web page? http://apolyton.net/forums/showthrea...threadid=40836

For example, there is nothing in the xml file that describes how an element´s long range power is different from its melee power. I see that archers have the support order instead of the attack order, but that seems to be the only difference.

Wrong. There is the Distance tag. It replaces Attack at long distance, and is used for the support order.
One day I may implement Long/Medium/Short Distance and Melee attack strengths (4 instead of 2). Or something more complex, but I think the model is already quite complex.

Do the fortifications that engineers build follow the same rules as the fortifications built through the econ GUI? I noticed that engineers and their forts have been in the game a lot longer than the siege model.

No. They add to the defense if you have come out winner of the manoeuvering phase. I am not sure they are very useful the way they are now. Krenske's model was a bit fuzzy there. They make a difference, but I am not sure it is very noticeable.

I have a question about the Orders available to a unit. Suppose I am designing a scenario and I want my primary attack element to have a small amount of wall-breaching capacity once a certain technology is discovered. This would be done by setting the basevalue to some high knowledge level and tuning the effect so that the value of the breach command is zero when the tech has a knowledge of zero.

If I add this breach order and value, will it execute both commands during a siege, or just one? Will it breach the wall and then attack, or only do one? I wouldn´t want the breach comand to stop it from attacking, since that is its primary function.

Right now it will ust try to breach walls. With 0 value, it will be pretty useless. However, I don't want units to both attack (or support) and breach, because that would be too powerful. I can change that if you have ideas about it. I also need a way to have only ranged attacks against breachers with counter fire when the attackers will be trying to breach but not to assault. Mostly needs coding, but ideas are welcome: What do melee units do? Probably nothing. Who is hit by the defenders'weapons (crossbows, catapults): Everyone, only breachers, breachers and counter-firers?

Would there be any negative effect associated with attempting to execute a Breach order that has a value of zero?

As I said above, yes. I can easily check for the 0 value, but a 0.1 value wouldn't be very good either, and the breacher would still not attack while breaching. If a 0 test suits you, I can do it very fast.
Note also that I want to be able from the UI to provide "tactical" orders to units however, so that you could tell a unit which can do attack and breach that they should attack instead of breach, or one which can support and attack to attack instead of support, etc. By default, elements always chose the order they can do which keeps them farther from the front.

Also, can technology change the cost of something? That´s a question, not a request. It isn´t really important, but it might be nice to use.

No but I think that could be done. Just check with Mark if the econ doesn't stock a pile of possible orders once and forever, but I think it repeats getCost() calls so that should work.

Can we make the health recovery rates, the pyrrhic factor, different for each element, describing it as an individual attribute rather than a global one? That way some elements could heal better than others, and it could use the already existing mechanisms for application effectiveness due to knowldge.

We could. I have just finished coding it as gloabl stuff, however, so that will wait a bit because I want to move on, but your point is worth taking into consideration.

How do experience levels work? It sounds like it uses a seperate mechanism than the tech model. IMO it would be good to link the two, but it isn´t necessary.

Experience levels worked (and I recently reintroduced them) by giving 1 XP after a fight to an element who survived. The experience level is sqrt(XP), max 5. It provides to-hit bonuses. There is also something called training which lurks in the model and does about the same thing as experience except you have to pay for it instead of fight for it. Currently, there is no way to tell you want trained troops in the UI, however. Note that Military Tactics does somehow acts as a global experience tech for the whole civ. Note that I am not much of a fan of experience for units. I'd rather have training only if I had only one, but experience needs no UI so it was easier to plug in.

Ideally, each unit would have an attribute that describes which activity it feeds RP´s to after a battle, and a number that multiplies the base battle RP generation. That way a militia levy could only provide a small benefit to the Infantry Activity, but an elite cavalry unit provides a big boost to the Cavalry Activity.

That is a good idea.

In addition to giving these battle RP´s to the civ, each unit also remembers how many RP´s it has accumulated. These RP´s serve as the unit´s experience. The unit starts at a knowledge of zero in all techs that its activity feeds RP´s to, and raises that knowledge using the same mechanism as the tech model, including the use of helper techs. When the time comes to calculate the application effectiveness of the unit, the civ´s knowledge is added to the unit´s knowledge. Obviously this is a big, long-term change, but I think it could be worth it. We´ll see how well the current system works.

Maybe. Note that the current system is interesting in that experience and training both behave in the same way, which would be hard to model for training with your method. Also, but that is less of a problem, they affect a parameter that is otherwise unaffected by unit stats, which is the to hit chance (normally 30%, + (experience + training) * 4, so up to 70%).
Your solution would work greatly for a role-playing scenario, however, though that is not our focus.

One thing I would like to see in the future is to differentiate between a "Move" command and a "Move and Engage" command. The former would work like movement does now, but if the latter is selected, the unit would actively seek out fights, even moving to a different square to fight an enemy. This could help prevent armies sliding past each other. A "Pursue" command would also be nice, so that the TF checks the lication of a certain enemy TF every click and moves to intercept. Earlier military write-ups mentioned zomething about a Zone of Detection; it would be good to implement a TF fighting anything that comes into its ZOD.

Yes, we wil need more high level orders to give to units, taskforces and whatever other command levels we may have.

I also think that it would be good if the population to build a military unit to come form all over the province. That was mentioned earlier in this thread, but population to build the unit still only comes from the province capitol.

Yes. Mark?

[Mark_Everson]

Glad to see all the solid discussion. Lots of good points and clarifications. . .

Laurent, if we don't do the square-within-a-square thing soon, I'd like to see automatic starvation of the garrison in a siege after some arbitrary number of turns. This would just be a kludge to allow sieges to work almost normally. What do you think Laurent? OTOH if the square-within-square is a simple as Gary seemed to think when he mentioned it, we should just do it right the first time.

Originally posted by Richard Bruns
I also think that it would be good if the population to build a military unit to come form all over the province. That was mentioned earlier in this thread, but population to build the unit still only comes from the province capitol.

Hey Richard, it already works that way. You can see it easily in Jericho or Dawn. Population is withdrawn proportionally to existing pop from the entire province when a military unit is built. However it is possible that the check for enough pop looks at only the build square. If so that's a bug.

[Richard Bruns]

Originally posted by LDiCesare
One day I may implement Long/Medium/Short Distance and Melee attack strengths (4 instead of 2). Or something more complex, but I think the model is already quite complex.

So what is happening here in the log, in a fight between warrior units?

Fight at range Long Range with 2 vs 1 elements.
Fight at range Long Range with 2 vs 1 elements.
Fight at range Long Range with 2 vs 1 elements.
Fight at range Distance with 2 vs 1 elements.
Fight at range Distance with 2 vs 1 elements.
Fight at range Short Range with 2 vs 1 elements.
Fight at range Short Range with 2 vs 1 elements.
Fight at range Melee with 2 vs 1 elements.
Fight at range Melee with 2 vs 1 elements.

Is this simply a representation of the time it takes to advance and close to melee? I understand that Warriors already have a Distance attack and use it if they have to, but prefer to close to melee. I know that they are attacking at Distance and dealing a small amount of damage for those two rounds, but what is happening at Long Range and Short Range?

No. They add to the defense if you have come out winner of the manoeuvering phase.

How was this affected by the change to variable element sizes? In the past a single engineer element added one defense, but what happens of I have 500 engineers instead of 1000?

Right now it will ust try to breach walls. With 0 value, it will be pretty useless. However, I don't want units to both attack (or support) and breach, because that would be too powerful. I can change that if you have ideas about it.

I think that each element should execute every order that it is capable of in every round. I think it is perfectly reasonable for something to attack and breach at the same time, or to breach and provide supporting fire simultaneously. After all, you already have units that are capable of scouting, skirmishing, and normal combat all in the same tick, and Engineers seem to build and then fight in the same tick. It should be fairly easy to balance things out by making these multi-purpose units less powerful in each individual order.

A player could be given the choice to build 2 different units, with the same cost. Unit A has a distance attack of 10, and Unit B has a distance attack of 7 and a breach value of 5. In a siege, unit B is superior, but in a fight on a field, the breach value is wasted and unit A will be a better choice. They both have their place, and nothing is too powerful.

Plus, of course, changing things like this gives designers the flexibility to make units like the one I described earlier, where the breach ability is a small bonus.

I also need a way to have only ranged attacks against breachers with counter fire when the attackers will be trying to breach but not to assault. Mostly needs coding, but ideas are welcome: What do melee units do? Probably nothing. Who is hit by the defenders'weapons (crossbows, catapults): Everyone, only breachers, breachers and counter-firers?

Could you just treat breaching units as front line units in a Distance fight? That way the breachers and archers can take potshots at each other until the wall is destroyed, at which point the army closes to melee. Then you may not even have to use any special code, just use the normal rules for advancing. The breaching weapons will not want to close the range because thery are more powerful at long range.

The problem with this is that the army as a whole is probably more powerful at melee, so they may foolishly want to close the range. I have an idea that could both solve the siege problem and prevent units from behaving foolishly in normal fights. Currently, an army wants to close to melee if it is stronger in melee. However, this can lead to stupid behavior. If my unit has a distance attack of 50 and a melle attack of 60, and their unit has a distance attack of 10 and a melee attack of 100, then obviously I will want to stay at distance, even backing up if they try to close to melee (Parthian tacics). But it seems to me that in the model now, my unit will close to melee.

Each army should try to stay at the range where the ratio of its attack to the enemy´s attack is highest. I think that coding intelligent behavior like this is important. Of course, you may have already implemented this without documenting it, so my point may be moot.

In any case, if units behaved like this, it would be possible to fix things so that there is no special coding needed for siege decisions. The fix required is very simple: Instead of having walls giving a bonus to defense, make them give a big bonus to melee attack power. This is logical, since it is much easier to attack a guy who is climbing up the wall on a ladder. In this situation, the attackers will use the normal advance decision calculations to avoid melee combat, staying at range until the wall falls. It also has the bonus of automatically making walls obsolete at that point in history when range attacks (guns) become more important than melee attacks. More modern forts can instead provide a bonus to range attack power, which will encourage the attackers to try to close to melee. Blowing up a pillbox by shoving a satchel charge inside is far more effective than trying to fight it at distance.

Another possibility of this is that it could automatically enable the defenders to leave the walls and attack. If they calculate that the ratio of their melee attack without the walls is higher then the ratio of distance attacks with walls, then they will want to leave the walls and close the range as per the normal rules for advancing.

Note that the current system is interesting in that experience and training both behave in the same way, which would be hard to model for training with your method.

I agree that experience and training should work the same way. But I think that it would be very easy to model training with the RP method. Simply use the training cost attribute in the xml file as the amount of money, or more accurately services, it takes to give the element one RP. The player pays some amount of money and the economy model calculates how many services are bought with that money. Then the unit gets a certain number of RP´s based on the number of services and the training number. Those RP´s are translated into the unit knowledge exactly as if they had come from a battle.

The advantage of a training system linked ot the tech model is that training can now increase any attribute that can be increased by technology. The training automatically goes into whatever Activity that the unit´s battles would have supported, which in turn raises that unit´s knowledge levels for whatever techs will increase its effectiveness.

We need to decide if RP´s from training raise the entire civ´s knowledge, like battle RP´s do. My gut reaction is that they should.

Also, but that is less of a problem, they affect a parameter that is otherwise unaffected by unit stats, which is the to hit chance (normally 30%, + (experience + training) * 4, so up to 70%).

You probably already know how I will react to this. I would like this to hit chance in the xml file as an element attribute, so that it can be changed by scenario designers, be set to different values for different elements, and be affected by technology. Then the training and experience affect this variable like they can affect any other.

Mark, I´ll have to look closer at the population numbers, but it seems that it gives me the "not enough people" message in provinces that could build someone. Usually this happens in a province I took over, where the province capitol is some smaller square, the first one I took over. When I change the capitol to the main city, the unit gets built.

[Mark_Everson]

Originally posted by Richard Bruns

I also need a way to have only ranged attacks against breachers with counter fire when the attackers will be trying to breach but not to assault. Mostly needs coding, but ideas are welcome: What do melee units do? Probably nothing. Who is hit by the defenders'weapons (crossbows, catapults): Everyone, only breachers, breachers and counter-firers?

Could you just treat breaching units as front line units in a Distance fight? That way the breachers and archers can take potshots at each other until the wall is destroyed, at which point the army closes to melee. Then you may not even have to use any special code, just use the normal rules for advancing. The breaching weapons will not want to close the range because thery are more powerful at long range.

The problem with this is that the army as a whole is probably more powerful at melee, so they may foolishly want to close the range. I have an idea that could both solve the siege problem and prevent units from behaving foolishly in normal fights. Currently, an army wants to close to melee if it is stronger in melee. However, this can lead to stupid behavior. If my unit has a distance attack of 50 and a melle attack of 60, and their unit has a distance attack of 10 and a melee attack of 100, then obviously I will want to stay at distance, even backing up if they try to close to melee (Parthian tacics). But it seems to me that in the model now, my unit will close to melee.

Each army should try to stay at the range where the ratio of its attack to the enemy´s attack is highest. I think that coding intelligent behavior like this is important. Of course, you may have already implemented this without documenting it, so my point may be moot.

Great suggestion Richard. Laurent, is it doable in the code reasonably easily? What do you think?

Overall I am suspecting that fights are too predictable. Occasionally in RL armies that have a 2:1 advantage lose. I mean 2:1 with everything else equal. Maybe the problem is that we were once in a regime where say 20 elements fought 30, and part of the possible distribution of occurances would have the 20 win, maybe 15% of the time. Now things are broken down much finer (Maybe the equivalent of 200 vs 300 smaller elements of course) and the law of large numbers means the distribution of results converge to the mean. So the "superior" force always wins. I won't say any more until I get confirmation, because I could be utterly wrong about this. . .

[LDiCesare]

Well, I thik most of the thigs you say are reasonable,

So what is happening here in the log, in a fight between warrior units?

The fights at long range, distance and short range all use the distance stat. They allow to understand how fast the armies progress. Long term there should be more than one distance value. Not a lot to code, but I thik it is not urgent.

I think that you can tell a catapult to either attack walls or shoor above them to target defenders, but not both. I agree that lowering some stats or increasing the cost and allowig both attacks to be done is an option.
Let me say I don't like it again once or twice, then I will code it.

The problem with this is that the army as a whole is probably more powerful at melee, so they may foolishly want to close the range. I have an idea that could both solve the siege problem and prevent units from behaving foolishly in normal fights. Currently, an army wants to close to melee if it is stronger in melee. However, this can lead to stupid behavior. If my unit has a distance attack of 50 and a melle attack of 60, and their unit has a distance attack of 10 and a melee attack of 100, then obviously I will want to stay at distance, even backing up if they try to close to melee (Parthian tacics). But it seems to me that in the model now, my unit will close to melee.

Right. I coded that as a first implementation. I can easily change that by checking sul of attack strength * defense ratio at each range. Indeed increasing attack value for walls instead of defense makes the computation much better. Should work, but there may be subtleties (aka bugs to check) for armies which get out of the wall. Also, walls should protect from archers, so there is probably both a defense and a melee attack bonus.

About fights predictability, I think Mark's analysus us correct. Increasing the random factors in scouting/manoeuvering phases and their effects would probably allow for the best change.

Overall, I think I will have to put even more things in the xml files so everything can be customized.

For the square in square thing, I need to know how much food is retained there. I can make something if I have a idea of the amount of food inside the enclosed area, and how much is consumed.

[Richard Bruns]

Originally posted by LDiCesare
I think that you can tell a catapult to either attack walls or shoor above them to target defenders, but not both. I agree that lowering some stats or increasing the cost and allowig both attacks to be done is an option.
Let me say I don't like it again once or twice, then I will code it.

The assumption is that some of them are attacking the walls and that some of them are attacking the defenders. Since we can´t give tactical orders yet, this is a good way to simplate multi-purpose units.

Let me tell you the specific unit I had in mind for a scenario. I wanted to modify Jericho so the civs progress from a simple "Mob" unit to a more elite "Warrior" unit as tech progressed. In addition, there would be a wall that is cheap enough for these civs to build at the very start, and more advanced walls later on. There would be a similar progression of siege equipment, from a simple battering ram to a more advanced catapult.

In order for a Mob to have any chance of attacking any walled cities, it would need to bring along some slow siege weapons or build them on site. But Warriors are more elite and better trained, and they know how to take out simple wooden walls by burning and/or sapping as they attack. I wanted to simulate this by giving them the breach capacity of a battering ram, so that they can take out the simplest walls without slowing down.

The only current way to do this is to make a special breaching element with no cost or upkeep, and add that to the Warrior unit. But this means that the unit will always have the same breaching power, regardless of how many Warriors have been taken out in other battles. Plus they will require additional personell.

I like the customizability of the new .xml files I got in the testbed. They let me alter a lot of things, and IMO are already very good. I look forward to the even better version.

I have a question about how the front lines are set up with the variable units. Previously, elements were matched up one to one, but some elements had more people than others. What happens now? If I have 500 elite legionaries and 500 archers and I am attacked by an element with 2000 low-grade warriors, are the archers forced into melee combat? Is it any different if they have 4 elements with 500 warriors each?

[LDiCesare]

Elements are matched per number of men. That means you can have a fraction of an element (f.e. 100 out of 2000 men) facing another element (in the example, a wounded 100-man element), while the rest (the 1900 others) are used to match other men or to flank.
There are some small limits on the number of men when computing the sizes so you must be the same size plus or minus some value I don't remember, in order not to split the elements for a single man.
Note there is provision for matching based on spread of the elements instead of just number of men (phalanx is more compact than modern infantry for instance, so maybe 1000 phalanx men would have the same frontage as 100 or 200 modern infantry).

[Richard Bruns]

So my archers are toast then?

Where is this provision for defining the spread of an element? It would be good to say that a legionary is capable of a spread of four times that of a mobster, so that they can protect those archers. It may seem bad to be outnumbered, but if the elements are clearly superior and they now have the advantage of support fire than they are better off not letting all the archers get caught in melee.

Also, can we change the assumption that an element is always one man? For example, an Elephant element would be one elephant and about ten riders, trainers, archers, etc. A single catapult element would likewise have a lot of men. Putting the number of population required to build the element in the Cost tags would be good. Most elements would of course cost one person, but it would be good to adjust that.

[LDiCesare]

The provision is in the model. It is not coded yet. Sorry. That has quite low priority on my agenda, also.
About 1 element being 1 man, it doesn't mean much. The stats given for one element in the file are for 1 man out of that element. The code Element object represents a number of men (can even have fractions to account for wounded and make things simpler in the program). If you want to say an elephant maps to 10 men, just increase the health value and all relevant stats, and put less elements in the corresponding unit. Same for siege engines.
Now archers are still extremely useful, because if you have 1 legion + 1 archer vs. 2 legions (assuming the archer firepower and cost matched the legion, which is not the case, but try with warriors for example), then the archer will be able to shoot at the opposing legion and deal damage to them before the melee phase begins. When it starts, the archer will have part of it flanking the opponent or shooting support fire once the opponent is reduced to lower numbers. Considering archers are cheaper than most melee units, you can usually get a lot of them in support fire. The SiegeWars scenario shows that quite well. If you buid 50% warriors and 50% archers, you will end up with almost only archers because they keep in the support lines instead of the front and let the warriors suffer all the damage.

[Richard Bruns]

I like the way that element costs can be defined as a multiple of the default. Can we do the same thing for all the other stats? Being able to set things like Attack and Movement as multiples of the default would be very nice.

---

I did a few more experiments with the Military Model. I added the following element and unit to my small numbers Jericho scenario:

<Element>
  <Name>Hero</Name>
  <category>foot</category>
  <Attack><value>1</value></Attack>
  <Defense><value>1</value></Defense>
  <Movement><value>20</value></Movement>
  <Distance><value>0</value></Distance>
  <Armor><value>1</value></Armor>
  <Health><value>1</value></Health>
  <Morale><value>8</value></Morale>
  <Mobility><value>4</value></Mobility>
  <Order>Attack</Order>
  <Order>Garrison</Order>
  <Cost>
    <Food>10</Food>
    <Production>20</Production>
    <Services>10</Services>
    <Decay>0.03</Decay>
    <Training>2</Training>
    <UpkeepFactor>0.05</UpkeepFactor>
  </Cost>
</Element>

<Unit>
  <name>Hero</name>
  <Image>Centurion</Image>
  <element>
    <name>Hero</name>
    <number>1</number>
  </element>
</Unit>

Note that the Hero unit has exactly the same stats as the Warrior unit, which consists of 1000 men with attack and health of 0.001 and costs exactly 1/1000th of the Hero. I started making Heroes and using them in fights. Here is what happened:

COMBAT Turn 14, 5935BC
Combat in [1, 29] rolling won by Emars

  Jericho armies 
    Attack: 1 down to 0
    Defense: 1 down to 0
    Health: 1 down to 0
    Cost: 40 down to 0

  Emar armies 
    Attack: 0 down to 0
    Defense: 1
    Health: 0 down to 0
    Cost: 1 down to 0

Fight at range Short Range with 1 vs 1 elements.
Fight at range Melee with 1 vs 1 elements.
Element destroyed: Jericho Hero16
Unit Hero 2 in 3rd TF has been destroyed, 0 left
Jericho task force 3rd TF has been destroyed.
Fight won by Emar
==== End of combat ====

The unit that did in my Hero had exactly 12 Warriors, a pitiful amount of power. Why did they kill him in one hit? Even when I gave the Hero unit 10 health, it still died in one hit. Why does that happen?

[LDiCesare]

There is a hard coded provision in the code that kills elements with less than 1 health, in order to avoid fights between element1 with 0.0002 health vs. element2 of health 0.0004 which could last forever.
Now the amount of damage taken may be more than what you think. Increase the defense or decrease attack or change the damage divider until you have an idea of how much damage is dealt by a 1 attack vs. 1 defense unit in a fight. Start by increasing health to a huge number so you may find out how many damage he suffers. I can add more details to the fight outputs, but that will get very very verbose. I also have a program that makes a lots of fights by batch so you can tune stats, but it is very awkward to use. In last resort? If you can't find out, send me an xml file with all the units in it and I'll try to debug that.

As a side note, to answer something that has been talked about in at least 2 other threads, changing the attack figures to get them lower should be OK. They were big in the xml files because they evolved that way, but 20 was for 500 men and suddenly became the value for 1 man, so it grew in a huge manner.