Military Model VI

[Richard Bruns]

Originally posted by 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.

The Warrior unit that killed the hero had a Health value of 0.016. Fractional health was something I was used to. Is it a problem to put in an option to turn off that provision? I don´t see how it causes a problem, anyway. I assume that the code now is:

attack = element attack * number of elements

That would mean that one of those two wounded elements would die swiftly, since they each get their full attack, which would wipe out the little health that remains.

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.

I have been testing and tweaking this for two days now. Combat between two Warrior units with attack, defense, and health of 1 each works perfectly, as I described in the Scenarios thread where I posted my small number combat scenario. The Hero had exactly the same stats they did. Download the file to see that combat in action. It doesn´t include the Hero unit, though.

I certainly plan on altering the default military.xml file so that the weakest unit in the game has stats of 1 in most things.

[Richard Bruns]

I gave the Hero unit ten health and it still died in one hit. It is impossible that a fraction of a Warrior unit could deal 9 damage in one round of combat, when a combat between two such warriors usually lasts for about two turns, taking dozens and dozens of rounds even when they have 1 health each.

[LDiCesare]

The 1 limit really helped at a time. I am quite sure it would lead to endless fights if removed. One weakness of the combat model is that you are never actualy outnumbered more than 2 vs. 1, which means killing off a small party should take some time.
About the hero, that is the hero unit stats which I am interested in.
The attack of an element is attack*manPower (number of men), not attack*health (and damage is dealt to manPower, after being divided by nominal health).
When I suggested big values, I thought of 100, then 1000 if it doesn't work and so on. Then adjust damage divider if needed.
I don't really want to tune the system for units with manpower of 1 vs. units of manpower of 1000. At 1 vs. 1000, you should lose IMO, so I won't spend much time testing it myself unless you really find it extremely annoying.
I hope you haven't noticed yet that when I say I will not fo something unless it is really extraordinarily unprobable that I change my mind, I tend to do it right afterwards.

[Richard Bruns]

Originally posted by LDiCesare
The 1 limit really helped at a time. I am quite sure it would lead to endless fights if removed.

It seems to me like a remnant from the times of fixed-man elements. I don´t think it is useful anymore. After all, a fight between two severely damaged elements with manpower of 2 each should take just as much time as combat between two healthy units of manpower 20000 each.

One weakness of the combat model is that you are never actualy outnumbered more than 2 vs. 1, which means killing off a small party should take some time.

That could be a problem. If my Hero remained alive, he would only be able to kill two Warriors each tick, so they would take forever to die. Where does this limitation come from, why don´t units face more enemies? I thought combat was a matter of applying the attack power, dividing by defense and armor, and taking off that much total health from the elements in the front row.

About the hero, that is the hero unit stats which I am interested in.

I am not sure what you mean. I posted the Hero stats above. The Warrior stats were posted in the new scenario thread, the attack and health are both 0.001 and there are 1000 of them in a unit.

damage is dealt to manPower, after being divided by nominal health).

I see now. The Warrior unit did 0.001 damage to the manpower of Hero, which was rounded up, causing him to vanish. When his Health was ten, the Warrior unit did 0.0001 damage to the manpower, but it was still rounded up for instant death. If the damage didider is increased by a factor of 100, the Warrior unit does 0.000001 damage, and then Manpower is reduced by one.

When applied to the normal combat with Warriors with health of 0.001, this system works fine. Damage of 0.005 is divided by the health of 0.001 to do five damage to manpower, just as if a damage of 50 divided by a health of 10 does five damage to manpower. I also understand why you had to round up the manpower damage. If it ever got rounded down, than elements might never die when the attack was a lot smaller than the health.

Basically, the system seems set up so that each attack much deal an integer amount of damage to manpower. This causes problems no matter which way the damage is rounded.

Instead of dealing damage to manpower, could you deal damage directly to the health of the unit and then calculate the remaining manpower based on the health, rounded up to the nearest whole person? That way the two tiny units would still be able to kill each other but a strong element is not killed in a single hit from a weak one.

[LDiCesare]

Richard, damage is never rounded. Manpower is a float, so you can have 1.5. The only rounding is that manpower < 1 is killed, and not health < 1 as I thought. I think that explains all. This provision was because I didn't really want to have armies of 1 man running around after a fight. I'll comment it away and we will see what it gives.

The attack limited to 2 vs.1 is because at melee range you can't mop up on a man at 10 vs.1. e.g. A line of 10 men is attacked by a line of 20+: 10 flankers can go round the line of 10, who can attack only one opponent but are attaked from the front and flank. Thus the limit of 2 vs. 1.
Now in one tick, there are several rounds of fight (up to a limit now set in the xml file, I think 20 or 30 by default). So an element of 1 can kill at most 20 or 30 opponents in one fight.
The system is not designed to mimic 1-man fights, and I don't want to make it more complex or less realistic for mass fights in order to allow it.

[Mark_Everson]

Hi Laurent. My recent play of several scenarios leads me to believe the combat is slowed down too much. I just commented on this yesterday in the New Scenarios thread re: Jericho, and its even worse in Attila. I don't know what exactly the changes were that lead to it, but I thought I should let you know my opinion. IMO part of the problem in Attila is. . .

The attack limited to 2 vs.1 is because at melee range you can't mop up on a man at 10 vs.1. e.g. A line of 10 men is attacked by a line of 20+: 10 flankers can go round the line of 10, who can attack only one opponent but are attaked from the front and flank. Thus the limit of 2 vs. 1.

What about the rear? And there are two flanks. . . Not to mention other things like rotating in fresh troops that are possible when one has the preponderance of force. I think there should be able to be at least three or four to one odds have affect.

If nothing else its boring and frustrating having battles that are foregone conclusions last forever. That is what we have in Attila now. Is this easy to change? If not, some other things to make combat quicker, like giving advantages in the early-phase bonuses for power superiority could give similar results.

[Richard Bruns]

I have found that combat speed is entirely due to scenario design. In the current testbed, low tech combat is long but combat in delenda is very quick and deadly. But in my tech tree, high tech combat actually took more time than low tech combat until I cut down the armor of later units. I have fixed it so that most fights take a couple turns, but a powerful force can mop up a smaller one in only one turn, and that combat is relatively constant over all tech periods. It is a matter of balancing attack versus defese and armor in the unit design.

So combat speed is very easy to change in the xml, and no coding solution is required. I would also like the option of getting rid of the 2-1 limit, though. Can you fix it so that it reads from a tag in the military defaults with a name lime "MaxOutnumbering" so the designer can play with it and see what happens?

What happens to attack numbers when manpower is rounded? Does an army with 10.5 men have an attack of 10.5 times element attack?

And I don´t see any major difference between armies of 1.5 men and armies of 0.5 men running around after fights, so I vote to keep that commented out. Anyway, the smallest army I have seen is 16 men. If endless fights are a problem, the attack can be rounded up to the nearest whole man so that 0.02 men versus 0.1 men is over swiftly.

[LDiCesare]

As Richard said, there are now lots of figures that can be used to tune combat. There are militaryConstants in military.xml. Touch the damagedivider and heal rate and you should be able to move from deadly fights to no fights.
I changed one thing to allow units with manpower lesser than 1, that is to round to nearest higher integer the "frontage" of units.
About flanking, 2 vs. 1 is about the max you'd get on a line: (a for attacker, d for defender, in compact formation):
_aaaaaaaaaaaaaaaaaaaaaaaaaaa_
addddddddddddddddddddddddddda
_aaaaaaaaaaaaaaaaaaaaaaaaaaa_
Additional elements provide increased firepower if they have ranged fire.
It should be possible to provide customization of the 2 factor, but I am not sure it is needed, as other factors can speed up the fights, and healing rate gives the attacker a diminution of the casualties anyway.

[Richard Bruns]

Melee combat rarely happens in a nice line; it is usually more like a mob, and it is entirely possible for people to be outnumbered by up to nine to one or worse in such a situation:
aaaaaa
adaada
aaaaaa

[LDiCesare]

The situation you describe doesn't match what happened in armies like phalanxes. There were lines, walls, you couldn't flank in the middle of a line. Greeks used a shield bearer and a spear bearer for instance. Pikemen, the Swiss of the Renaissance for example, fought in tight formation. That is also true of roman legions. The battle of Hastings also showed this kind of behaviour: Armies are not mobs.

I think, however, an improvement could be made to allow different frontage in attack and in defense, allowing an attacker to regroup itself more than usual if they outnumber their opponent. The examples I gave were mostly about infantry formation, defensive formations. Cavalry are different, and for cavalry, your example could be good. Since I thought cavalry had little to differentiate it from infantry anyway (better mobility is currently not very useful), it could be an option to allow cavalry to better regroup, and thus flank enemies more effectively. Since cavalry was a flanking weapon, I think that would be accurate.

Thus I propose to leave the system as is for infantry, and to provide a mobbing value for cavalry (actually this would be per element, so you could give it to infantry too if you like). Note the flanking units model works quite well in CtP2. What do you think?

[LFS]

I'm not entirely sure what this 2-1 limit is about, but at least in melee battles (i.e. pre gunpowder) flanking and rear attacks were devestating (they still are )- its a morale thing as much as anything else, but also the loss of formation for the victim - you just can't maintain a phalanx (elite units may coprfor a while) when fighting to more than one side, and most disciplined units rely on a formation (phalanx being the extreme example) for effectiveness.

What i'm saying is once you are hit in the flank or rear (all other things being equal) you are likely to lose rapidly. Of course other things are seldom equal - but don't treat a flank/rear attack as simply a way of getting extra attacks on someone.

[Richard Bruns]

A mobbing value assigned to each element would be good. That way elite troops can mop up weaklings better than ordinary units.

If we want to get really detailed, we can assign a formation value to each element, and the maximum outnumbering can be the attacker´s mobbing value divided by the defender´s formation value. If the formation value is bigger than the mobbing value, the maxoutnumbering could actually be less than one, which would simulate things like the Greek phalanxes being able to take out massive numbers of unorganized Persians because the Persians couldn´t fight them all at once. Terrain would provide a nice bonus to this formation value, simulating the fact that difficult terrain prevents flanking.

[Richard Bruns]

Replying to comment in the other thread:

Originally posted by Mark_Everson
Hi Richard. I think Laurent's approach [units with many different elements] is better. First it makes individual units not be hamstrung by being too one-dimensional, and thus losing combat effectiveness. Second its the way brigades and such work in the real world. To finetune overall number of skirmishers or scouts in an army you certainly could have dedicated skirmishing/scouting units that could be added in addition to the normal scouting strength of a unit.

The problem is that each individual element has a different tech requirement, which meant that if a unit had multiple elements it could not be built until all the element prerequisites were met. So instead of pushing to Ranged weapons 2, getting archers, and adding them to a TF with Warriors, you would have to hit knowledge 2 in a lot of different things and then build a generic "Army level 2."

Forcing the player to get a lot of different prerequisites for each unit drastically limits the player´s options. If we already have all of the seperate elements available to build, then there is absolutely no point in making a unit that has several types of elements together, especially when a unit is nothing more than a bunch of things thrown together, with no cost benefit or combined arms bonuses compared to building them seperately and combining them in a TF.

And if we do not have the seperate elements available individually, then the players options are reduced even more. Making a seperate default unit for all kinds of different possible element combinations would be a mess, and would still not allow the player to customize the army.

The only benefits I see to putting a lot of different elements together in a unit is flavor for individual civs, and as a crutch for an AI that cannot handle combined arms properly. The former is good for scenarios but bad for a generic default file, and the latter is rapidly being corrected by other means.

[Mark_Everson]

Originally posted by Richard Bruns
The problem is that each individual element has a different tech requirement, which meant that if a unit had multiple elements it could not be built until all the element prerequisites were met.

That certainly is a problem, and I have to admit I hadn't thought about it.

Forcing the player to get a lot of different prerequisites for each unit drastically limits the player´s options. If we already have all of the seperate elements available to build, then there is absolutely no point in making a unit that has several types of elements together

How about, its a lot easier to build a few types of multi-purpose unit than having to assemble lots of little pieces by hand? I personally have absolutely no desire to do it the way that you think is best.

. . . especially when a unit is nothing more than a bunch of things thrown together, with no cost benefit or combined arms bonuses compared to building them seperately and combining them in a TF.

But nonetheless a single unit can only have combined arms characterstics under the way it currently works. Your approach would eliminate that possibility. I feel this is a serious defect in the way you want to do it.

And if we do not have the seperate elements available individually, then the players options are reduced even more. Making a seperate default unit for all kinds of different possible element combinations would be a mess, and would still not allow the player to customize the army.

On your first point, there will be nothing to stop the player from doing it the way you advocate once the unit workshop is available. I just think that 80% of players won't want to do it that way. YMMV.

Lets see what Laurent and others think about these issues and we can at least work out a default approach for the near-term.

[LDiCesare]

I think having to assemble skirmishers with melee units by hand is not good from a micromanagement point of view. You are just pushing the problem anyway, since I can't combine a unit of 2000 melee-ers + 200 skirmishers if I don't have a unit of 200 skirmishers, and adjusting the cost orders of all the various units to get one good task force would be a nightmare for me. Particularly if/when units heal, where I would have to replace a damaged unit in a taskforce by a new one instead of letting the unit heal all by itself.

I also don't mind needing 2 techs to be able to build a unit.

[Mark_Everson]

I think one obvious compromise would be to have two nearly-identical scenarios where one uses Richard's approach for the units with the other one using the spec that we've had up until now. Of course that won't close the deal either way since all the gui capabilities that will affect the practicality and feel one way or another aren't there yet. But still it might be instructive.

For the bulk of scenarios I'd still prefer the way Laurent and I are promoting, but at least we could get some feel for how the other way works.

[Richard Bruns]

Ideally, a player would be able to build both combined units and individual elements, allowing both instant armies and customization. But the problem is images. I´ve already used all the images we have for the individual elements. If I get permission to use more images, I´ll gladly throw in some combined units.

[Mark_Everson]

Originally posted by Richard Bruns
Ideally, a player would be able to build both combined units and individual elements, allowing both instant armies and customization.

Hi Richard. I'm not sure this is the ideal anyway, since it might well present most players with too many choices. IMO we need to pick one approach as the default or we'll just have too many unit picks, at least for starting players. We can check out your ideal way and see what everyone thinks if the images problem goes away.

But the problem is images. I´ve already used all the images we have for the individual elements. If I get permission to use more images, I´ll gladly throw in some combined units.

Yeah, if you want to do this you'll need to find someone who's willing to let us use a fairly complete set of civ2 units. I don't think that should be very hard though. If you run dry on Apolyton, I can suggest another civ site or two that have some good stuff.

[Martin the Dane]

This post actually belong in several threads, but since it has mainly to do with military units, I'll post it her.

There are currently two versions of the military.xml. One for Richards unified system, and the older "official" version. I think it's time we decide on one or the other as the standard.

Personally I prefer Richards lower attack-values, to the humongus numbers in the "official", but I would like them to be in the 10-100 range for one unit, not in the 1-10 range. Furthermore I like the addition of anchient ~250 men-units.
The only thing I realy dislike is the name Mob/Mobster for the ancient "wariors". To me it sounds to much like Mafia.

For the long term it might be relevant to have several versions of military.xml and a more complex include system. This would allow easier creation of several scenarioes over a given theme, with shared units, technology, etc.

[Mark_Everson]

Originally posted by Martin the Dane
There are currently two versions of the military.xml. One for Richards unified system, and the older "official" version. I think it's time we decide on one or the other as the standard.

I agree completely! How about it guys? The two areas of disagreement seem to be unit values and whether units should be combined arms or monolithic. . .

Personally I prefer Richards lower attack-values, to the humongus numbers in the "official", but I would like them to be in the 10-100 range for one unit, not in the 1-10 range. Furthermore I like the addition of anchient ~250 men-units.
The only thing I realy dislike is the name Mob/Mobster for the ancient "wariors". To me it sounds to much like Mafia.

I think I'd be happy with the numbers exactly as Richard has them now. Sure, every once in a while a stat will be below 1 at the start of the game. But the alternative is to have things 10x or so larger for the rest of the game. One possible compromize, only the mob or militia type unit could have 1 and even warriors could start with 2 or so. I also dislike the mob name and would rather stick with militia.

As I have already expressed earlier in this thread I think the standard units should be combined-arms for now. We could test Richard's ideas using a single scenario as I've suggested before.

For the long term it might be relevant to have several versions of military.xml and a more complex include system. This would allow easier creation of several scenarioes over a given theme, with shared units, technology, etc.

I agree, but that could be messy to code and buggy. So while I think its a good long-term aim I would like to keep it simple on that score for now. Laurent is in the best position to say how tough or easy he thinks such a change would be. Personally I'd rather have him spending his time on AI . What do you think Laurent?

[Richard Bruns]

Now that I can use more pictures, I will add combined arms units. I may also experiment with the combined army units being composed of a picture of more than one person. But 7.7.1 might take a couple weeks, since I will be gone for a while, starting in a few days.

[Mark_Everson]

Originally posted by Richard Bruns
Now that I can use more pictures, I will add combined arms units.

Well, just to be clear, I don't think we should have both combined and mono-element units as the default for use in all scenarios. It is just too many choices, and will screw up the unit building interface IMO. If you want to have both as standard in the military file, but hide the orders for the mono-element ones in most scenarios I guess that'd work. And you could make all those orders visible in one of the scenarios so we can see how it would work. What does everyone think?

Laurent, what do you think of the scale of unit strength change proposal? One thing we could do is change the outputs to show tenths if a number is between 0 and 1.

[Richard Bruns]

If I read the dataformat document correctly, the econ xml gives me the ability to put orders in sub-categories in the GUI. So I can have combined arms units at the top level of the tree, and elements at a lower level. (or the other way around)

[Mark_Everson]

Originally posted by Richard Bruns
If I read the dataformat document correctly, the econ xml gives me the ability to put orders in sub-categories in the GUI. So I can have combined arms units at the top level of the tree, and elements at a lower level. (or the other way around)

Very Cool idea, but not implemented. And I hadn't forseen going quite that far with it. Certainly combined with Lee's tree stuff on the econ gui, it would take care of my objections to the two basic views of army units. For now you can only use the specific categories and sub-categories in the econ.xml file. That is because those correspond to existing java classes in the code.

But it might not take that much work to get where you want to be. To be specific you would be happy if there were more than one "army unit" sub-class under military? There would be an "army unit C" for combined and an "army unit E" for mono-element units. I will keep this capability in mind as I implement the more-flexible category and sub-category structure. No guarantees but it seems it can be done fairly easily.

Anyone else see any problems with the approach?

[Richard Bruns]

Originally posted by Mark_Everson
To be specific you would be happy if there were more than one "army unit" sub-class under military? There would be an "army unit C" for combined and an "army unit E" for mono-element units.

Well, I don't want to force too many layers. Some units should be in the top layer, so the player doesn't have to drill down too much. I'll respond more fully in the Econ GUI thread.

[LDiCesare]

About figures for the units:
The only value I am concerned about in Richard's mods is the health. I liked the fact that health of 1 = 1 man. Of course you can look at the personnel value, but when looking at elephant units or later at tanks etc. whose health will be very different from manpower, I thought it gave a good quick view of the strength of the units. At least have 10 for a basic unit so it is easier to make the difference between a full-strength and a wounded unit.

About different military files: It shouldn't be very hard to code. There are tags like <all/> that say which files should be used. I can change these from boolean tags to string tags so that <military/> means use the default military file and <military>scenarioname/scenarionamemilitaryfilename.xml</military> means fetch the military file in the specified folder/filename. I'll come up with something cleaner but that's easily done.

[Richard Bruns]

Originally posted by LDiCesare
About different military files: It shouldn't be very hard to code. There are tags like <all/> that say which files should be used. I can change these from boolean tags to string tags so that <military/> means use the default military file and <military>scenarioname/scenarionamemilitaryfilename.xml</military> means fetch the military file in the specified folder/filename. I'll come up with something cleaner but that's easily done.

That would be excellent. It would enable us to have several different sets of files. Would it be possible to have several different military files loaded up, to match different time periods? For example, the resurce folder would have files called ancientmilitary.xml, romanmilitary.xml, medievalmiliitray.xml, and so on, and the scenario designer could call up any or all of the files, as needed. It would keep the xml files smaller and save memory and system resources for scenarios that only cover a smaller time period.

[LDiCesare]

As long as you use one file per scenario you can do all you like. Actually, I coded it and you might even be able to use more than one file of one type if there are no dependencies between them, but that can cause problems if some constants are defined twice. I must test a bit.

[Richard Bruns]

Originally posted by LDiCesare
I consider making healafterfight a function of techs in two ways: both attacker and defender-related. That way you would have steel weapons deadlier than clubs at Cajamarca (ok I am reading Guns Germs and Steel right now), and an increase in healing rates as the defender gets better medicine.

Interesting proposal. The best way to do that IMO would be to assign a "wound" value to each element. This value would negate healafterfight in the same way that armorpen negates armor, and can of course increase with tech as all element attributes do.

There is the question of what to do if the wound value is bigger than the healing value. Should units suffer additional casualties after the battle is over, or should we keep a floor of zero for the adjusted healing value? I guess this is a tpoic for the military thread, though.

I vote for the former, which would be cool and realistic. If the adjusted wound value of the loser is 0.4 and the adjusted healafterfight value of the winner is 0.3, then an additional 10% of casualties could be removed after the battle is over.

---

Currently, all elements have the following tags:

category
Attack
Defense
Movement
Distance
Armor
Health
Morale
Mobility
FlankerEffectivity

as well as orders and costs.

And they can also have the following:

BoardSpace
Breach

We already proposed above to add two more tags:

healafterfight
wound

And now I´d like to propose another change:

I would like to alter the Build order in order to give more flexibility, work with the new siege model, and make more sense. Currently, there seems to be no way to alter the effectiveness of the field fortifications that get built, and these fortifications have nothing ot do with the siege model. I would like to change this, so that anything with a build order constructs a temporary wall before the battle that works exactly like a normal wall. So the tag would change to look something like this:

<Build>
  <Defense><Value>0.01</Value></Defense>
  <Armor><Value>1</Value></Armor>
  <Health><Value>0.01</Value></Health>
</Build>

The defense and health of the wall would then be multiplied by the number of elements that build it.

I also have a question about FlankerEffectivity. Is it a direct value, or is it added ot one? If that value is one, does that mean that the maximum outnumbering is 2:1 or 1:1? And is there any plan for a Formation value that reduces the enemy´s flanking?

[jbl18]

Hi,

I'm new to Clash forum. I first wanted to congratulate you guys on some good work. I know how much dedication it takes to get a project off the ground.

I wanted to make the following suggestions (if they have already been discussed, please tell me, these threads are large for 33KBPS connection):

As far as playability I would highly recommend looking into an old game called “The Ancient Art of War”. It was fun and highly realistic. Its real-time and point to point grid but added a lot of concepts that games since have missed out, such as fatigue, armies, march orders, and supply lines. I always thought the Piece concept in Civ-like games made it it too much like chess on steroids.

Regarding this, I wanted to recommend the following changes:
a) Sightings should be 2 squares away, (makes more sense in this simultaneous movement system) after all you can see further than you can walk. Obviously on open ground only.
b) Combat engagement can occur when any unit is adjacent any other unit, rather than once they enter the same square.
c) A combat “half-turn” should occur as the battle is resolving; the army may retreat at any stage while giving a free shot to the opposition.

Additionally, I learned the following equation from Colonization, which I thought was realistic:

Military Unit = Manpower (Civilian population unit) +Armaments (Muskets or Muskets and Horses)

Have two types of units: Militia and Professional
Militia units are simply locals of a province with Armament to repulse invaders. During peacetime turns you build up the local stock of armament of each province or a general level of armament (i.e. 10,000 bows and 10,000 spears or 1 musket for every 10 population). When an enemy is sighted the local Militia will mobilize and alert. These are poorly trained and coordinated but are fighting on home turf.

Professionals need Barracks or a Garrison (replaces or supports local Militias) and must be recruited. The rate of recruitment is relative to the salary you offer vs. the average salary of the general populace.

A social issue is posed about having citizens walking around with their own weapons. It may give them the right to a vote or just to kill one another.

The armed forces need a manager. For each army you simply dictate what size and what percentage of each army should be dedicated to what kind of unit, i.e. You want 100,000 soldiers in TF#1 to have 50,000 infantry, 20,000 bowmen, 5,000 men for siege weapons and 25,000 cavalry. On the battlefield the local militia would as already in Clash support the battle and fill the ranks.

Supplies produced and population recruited during a campaign will gather at local garrisons or are automatically sent to the army (timescale issues).

Let’s say you need the militia to join your army on a long campaign, you must conscript them. This puts an economic toll on the populace in the form of temporarily lost population (while the man was away the farm can function, but growth of the population will be stunted). Extended campaigns cause this loss to be extended equally. Any loses on the battlefield then make the lose permanent. Plus it means the populace will not appreciate a long campaign.

One last suggestion:
Terrain should also include a Danger factor. It could be directly related to the terrain bonus. It represents the difficulties that come with crossing any terrain from both accidents (which occur in both the mountains and desert) and from wild animals (which occur in the forests and plains). Two things reduce the Danger factor, Roads (and other structures) and Settlement. When there are more people in a square; you are less likely to face a lion. A road means you’re also less likely to lead you’re force through a dangerous gorge. The Danger Factor reduces the effectiveness of Exploration by Military units and the effectiveness of taking a army over long distances.