Military Model V

[LDiCesare]

I now managed to have a compiling code, which is much shorter than this morning, and does less things only as far as combat() method is concerned. Trimming Unit down was really a good idea, thanks Gary.
A few points arise as we switch from Unit-based combat to Element-based.

One is the fact that you cannot keep Units in reserve, only elements. I don't think it is a pity, but I would mention it.

More important, morale checks: They worked based on the damage suffered by the unit, in terms of dead elements. I have to change that since elements will want to flee by themselves to keep the coding simple. One thing that was missing was an appraisal of opposition: You wanted to flee when you were hurt, but not when you were outnumbered.
I suggest the odds to keep ground are: (morale + mobility/2 + training)*5%, multiplied by the ratio of offensive powers: If you are twice less powerful, you want to flee twice more. Note this is checked after one round of fight, so armies at that stage are able to appraise the opposing firepower. I also discount damage because I am not sure whether you are more affected by one dead in your century or by the fact that the century next to you was annihilated to the last man...

Also, about dealing damage. Krenske's model used a number of hits, each of which dealt some (1) damage. The number of hits being an int is a problem. I thus suggest it be changed. We can have damage set to (0.1* old number of attacks). Note chance to hit is quite low unless troops are experienced/trained.

Another point, is experience. I don't like it much the more I think of it. Although it makes sens in real life, on the time scale we consider, experience seems ridiculous. A same phalanx will probably fight 20 or 30 years away, and it would retain the experience of its members? I think experience was in civ because it was a way to force people to build barracks. I think training is more interesting than experience to model, and it has almost the same role in the model, so I'd rather use only training, not experience. It is interesting in the sense that a less-than-appropriate payment for a unit would reduce its training first, thus reducing its efficiency in an easily modelled way.

Now, on deployment of elements.
Each army when they meet have their front, support and reserve (non fighting) lines. If outnumbered, front lines will flank and attack support first, then remaining front lines. I suggest reserves be attacked last. The only elements which will typically be in reserve (unless we provide tactical control to the player, but that is too much micromanagement from my point of view) will be engineers and other not-so-fit-for-fighting elements. They can probably be left alone until the attackers are done with the fighters.

As a last note: Although Krenske's model manages fights at various ranges, this still won't get coded until we get past medieval era in clash.

I'll start coding the new combat soon (1 or 2 days) and hopefully see what the results look like by the end of the week.

[Gary Thomas]

More important, morale checks: They worked based on the damage suffered by the unit, in terms of dead elements. I have to change that since elements will want to flee by themselves to keep the coding simple.

Presumably the impulse to flee is calculated at the time of combat. Could you not have the unit flee if enough elements want to?

Mainly, I don't want to have units split up into fled and unfled elements.

Another point, is experience. I don't like it much the more I think of it. Although it makes sens in real life, on the time scale we consider, experience seems ridiculous. A same phalanx will probably fight 20 or 30 years away, and it would retain the experience of its members? I think experience was in civ because it was a way to force people to build barracks. I think training is more interesting than experience to model, and it has almost the same role in the model, so I'd rather use only training, not experience. It is interesting in the sense that a less-than-appropriate payment for a unit would reduce its training first, thus reducing its efficiency in an easily modelled way.

Very good point, and I agree.

I'll start coding the new combat soon (1 or 2 days) and hopefully see what the results look like by the end of the week.

See my email - it might take some of the burden off!

On all the other things you mention, I agree with your conclusions.

Cheers

[Mark_Everson]

I pretty much agree with the preceeding discussion, except I must go ballistically crook on experience.

I think experience is Quite important and would like to see it maintained. Please remember that the military timescale is one turn = one month. (The rest of the game can function as if 5 years or a lesser period of time has gone by.) Viewed in this context experience of units is easily commesurate with human lifespans. I also think experience serves a game function of giving the player special units that will draw them in more to the military part of the game. I view training and experience as Complementary. Well-trained units are not the equal IMO in well-trained and Experienced units. Essentially there should be two scales (although the player only need see one experience level). Have I convinced anyone?

[LDiCesare]

Experience: I can have experience for units which continually fight, but how long is a turn of idleness for the military?
When you don't fight, or move, does the one month really mean something? The phalanx built in 350BC, if it still exists in 400AD, has little reason to have experience if it didn't fight recently.
The real problem is we should be able to identify campaigns or war-times so that experience builds up during those periods, and is reset afterwards. I have no idea how to do that.
For the player to have special units, I don't think experience is the good thing to do in Clash. It was in MoM, where you cannot learn new kinds of units, so you keep your armies for a long time, but what's the point of a veteran archer when you have riflemen? And even in MoM, there were heroes, which were the real special units. I'd much rather allow to precise when issuing orders to create a unit that this turn I want a highly trained one, than wait for one to acquire experience in a somewhat random way (you will always have scarred veterans, i.e. units that lost elements).

[Mark_Everson]

Originally posted by LDiCesare
Experience: I can have experience for units which continually fight, but how long is a turn of idleness for the military?

Its like one month of idleness I'm just trying to be consistent. The different time scales thing is tough, but the other alternatives are worse. Experience should slowly decay during times of idleness or even moreso during demobilization.

but what's the point of a veteran archer when you have riflemen?

Absolutely none. But there are Long periods, where military technology will remained fixed. In these periods experienced units will be especially important.

I'd much rather allow to precise when issuing orders to create a unit that this turn I want a highly trained one, than wait for one to acquire experience in a somewhat random way (you will always have scarred veterans, i.e. units that lost elements).

Its not either/or! I am not saying we dont need Training. Training is, I agree, at least as important as experience. But especially at low levels of training experience will make a great deal of difference in effectiveness, especially the ability to hold a tough position.

Rather than have us go on and on about this, can we just Provisionally keep experience? If most agree in playtesting that its not worthwhile we'll get rid of it. I think in this discussion we've already 'spent' the coding time to either handle or remove experience .

[Gary Thomas]

Rather than have us go on and on about this, can we just Provisionally keep experience? If most agree in playtesting that its not worthwhile we'll get rid of it. I think in this discussion we've already 'spent' the coding time to either handle or remove experience

If it doesn't do anything in the code, get rid of it. When the model and how it works is properly developed (and I don't believe it is yet) put it in then. Non-functional code causes enormous time wasting. It is true that putting in the code doesn't take long. Worrying about it, checking that it doesn't impact on anything else (when in fact it doesn't do anything), and updating it when there are changes to other things, does take a long time, and our coding resources are not so great that we can afford that sort of waste.

If it is in there merely as a bookmark, put a @todo in the Javadocs, and get rid of the code. At least then a coder will not spend an hour or two trying to figure out how it works.

I have no problems with keeping experience in the model, not in the code, unless it can be made fully functional immediately.

Cheers

[LDiCesare]

I have been coding the proposed model.
Here is some detail:
When an army's front line is outnumbered, all its support elements will go in front line until they match the opponent. This means they will get flanked first, at least when I tweak the code correctly.
I consider a reserve line is a line of non-fighters, like engineers, who build fortifications and then hide. They are attacked last.
I changed Krenske's model in the following way in order to get rid of the int in his model (number of attacks):
When someone hits, they deal (formula to compute the number of attacks, not rounded) * 0.1 damage. 0.1 is arbitrary, 1 being the health of a (standard) element. It will mean a bit slower fights, but gives the same results in the long run. The damage is also multiplied by the opponent frontage/attacker frontage thing as explained by Gary.

[Mark_Everson]

I don't know that this is a big deal, but if you are slowing the fights by a factor of 10 that seems extreme. Why not 0.5 or so. But we can tweak later as needed.

[Mark_Everson]

Return on Military Investments

One thing I would like to get into Demo 5.1 is return on investment (ROI) for military builds. For now that means military units. Later we will need to handle things like fortifications, strategic transportation, etc. I'm going to put my thoughts out, and see what good suggestions I can get from others. I'll just cover the high-level issues here, without too much in the way of specifics. What we need is a crude way to estimate the benefit of adding a military unit. Then we can figure out the net benefit by subtracting the costs (support). Here are my thoughts on the big issues for the benefit of a unit.

1. Balance of power -- How does my military stack up to the neighbors, especially those I am most likely to fight? I have some thoughts on a simple algorithm that could give a crude answer on this. The attack power of units being built would also weigh in this.

2. Alternatively, the player may choose an ideal "force profile" to achieve. When significantly below the desired amount, extra units of a type that is wanted would be given a high benefit value. When the force profile level is reached, the benefit of additional units would be fairly small, and would drop off rapidly as the force increased above profile. This could also be done for high-level military commands in the future, so the player could pick a force profile for the "Western command", and all the other commands independently. My feeling is that probably letting the player pick the weighting between a "force profile" approach and a "keeping up with the neighbors" approach.

3. Fraction of GDP or expenditures -- You can simply say that the support for already existing military units should be on average some percentage of total expenditures. If well below that level, benefit of units would be high, above that level benefit would shrink to zero.

4. Insert your suggestion here...

All above still preserve the good features of the system of using ROI. If you issue a civ-wide order for more legions to legions will be preferentially built where they are cheapest. Again we can reduce micromanagement because the player does not have to look for the best places to build things, there are automatically selected (unless overridden) by the economy gov't orders model. For demo 5.1 number 1 or 3 would be relatively easy to implement. The other one would take some GUI work.

Personally I like 2 a lot longer-term, with 1 as a fallback for people who want almost no military micromanagement. What do you think?

[Gary Thomas]

1. Balance of power -- How does my military stack up to the neighbors, especially those I am most likely to fight? I have some thoughts on a simple algorithm that could give a crude answer on this. The attack power of units being built would also weigh in this.

The new military command system allows a summary of combat data at any level. At present it gives the sum of the attack strengths, defense strengths, and health. This can be immediately accessed for any level of command up to a civilization high command. Actually, it can be accessed for all units of all civilizations combined - I cannot see what use this is in the immediate future, but it migh be helpful if power circles are properly scaled at some stage.

The force profile system could probably be easily added to this system, though perhaps it is more in the bells and whistles department.

Cheers

[Gary Thomas]

I am about to code the movement system for the new military command structure. The model I propose to use is as follows:

1. Each command will have a target square (more on this below).

2. The actual units in the command will be grouped by square, and the group in each square will move together, but separate from those in other squares.

3. If some arrive before others, they will wait for the others before continuing with later orders.

4. If some meet enemy troops, they will still attempt to carry out their overall orders (if they survive). If this is inappropriate it is the player's or the ai's responsibility to change the orders.

The target square, once set, will not change. Thus "move to the nearest enemy" is interpreted as: "at the time this order is given, get the square with the nearest enemy and go to that square". By the time they arrive, the enemy may have moved.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
The target square, once set, will not change. Thus "move to the nearest enemy" is interpreted as: "at the time this order is given, get the square with the nearest enemy and go to that square". By the time they arrive, the enemy may have moved.

I'm with you until this last. If the target square being set won't change, we'll deal with it till something better is available. But this makes the order "move to the nearest enemy" basically worthless, and I think we should remove the order, or word it very carfully so as not to mislead players.

I hope that in the long run we can have a true attack/intercept X enemy command that will intelligently try to engage enemy. I realize this will take just a bit of time. Perhaps by next Tuesday?

[LDiCesare]

On ROI:
For short term, I think -3- is the best.

1) Yes, but how do you know your opponent's strength? If facing a huge empire (e.g. Alexander vs Persia), there is no way to know the whole enemy forces. We can use the known enemy forces and then set a factor, but that will always be inqaccurate, and I don't like to cheat by knowing the actual numbers and feeding them to an unsuspecting RoI calculator. It could be funny to have a "known" opponent force and "supposed" opponent force, though. This is typically what led the U.S. to build lots of nuclear warheads: they supposed the USSR had lots of them... until they sent satellites and saw they were quite ahead.
2) Good for the player in the long run, but how does the ai compute this? cf 4 below.
3) Seems easy to code and understand.
4) I would like to be able to issue orders on a grand strategic level (make war with X/take city Y), then the ai decides what forces they would like (probably based on -1-) and the budget voted (based on -3-). The player can of course just fill in numbers in the appropriate panel.

Now for long long-term (and ai):
I also think RoI must be considered not only from an economics point of view, but from a military one: Is it better to build an army in (x1,y1) or to move one from
(x2,y2)? The method -1- can make for appropriate forces inappropriately deployed. We should provide a value to an army being in some place, and to a place being without an army. Based on that value, we would have a RoI more easily. Also, this value is from a military standpoint, and you can scale it based on the budget you want to spend if you want to limit the budget.
Say you would like to have troops in square X, knowing that when you reach enough firepower you'll move them to attack square Y, and you know that you want to keep/have armies in square Z to defend it. Moving armies could then be viewed as an economic thing: Building armies has a RoI when the unit is built, moving it returns investment when the army has moved. With that system, a low military budget entails more moving of existing armies, while a high budget means building more armies.

I realize this is very complex and needs more thinking.

[LDiCesare]

On movement:
Will you include a "forced march" so that each unit moves at full speed?

To answer Mark on slowing fights:
I'll reduce the chance to flee successfully if I see that fights take too long. It is usually the factor which causes a fight to end, and the success rate is quite high for now. If I increase the damage dealt, it would lead to too many "lucky strikes" like when your civ-1 diplomat successfully defended himself against a cruiser and sank it.

[Gary Thomas]

I hope that in the long run we can have a true attack/intercept X enemy command that will intelligently try to engage enemy. I realize this will take just a bit of time. Perhaps by next Tuesday?

The present system doesn't have any easy way to identify a particular enemy unit, so has no way of saying "Attack the VIIth Legion". Nor has it a method of saying "Attack the Roman units in that square, and follow them if they move" - after all they may go in different directions. What it does have is a "Move to the square that the nearest enemy unit is in". This could be modified to "Follow and attack the nearest enemy unit", provided it stays with the first chosen unit, without much trouble.

The problem here is that these movement orders were not designed for human players, they were designed for an extremely rudimentary AI. If the move to nearest enemy order were modified as noted above, the human player could send a lone cavalry unit near to the main enemy army, which would then follow it to the ends of the earth, effectively taking the main enemy army out of the game.

It is necessary to think rather carefully about the difference between human player orders and AI orders. Because of the time pressure for D5 I just made the AI orders available to the human player - there are no orders specifically designed for the human player, except the red line on the map, which the AI doesn't use.

Before getting too elaborate about ways in which the human player can issue orders, I think that, in fairness to the computer directed civilizations, that some more effective AI should be developed. That really is the next substantial (as opposed to fiddling round the edges, like adding roads or triremes) improvement that Clash needs (Mark, are you there?).

Laurent: yes, there will be a move at best pace option, and no, it will not be a forced march, which is a different thing and will depend on training, supplies, and such.

In passing, it has now taken me 10 minutes to try and post this reply. "Try again later" is all very well, but I don't want to have to save the text, then paste it in.

Cheers

[Mark_Everson]

Well, my forum access was nonexistent today This is the first try where I got anything other than "go away".

Originally posted by Gary Thomas
Before getting too elaborate about ways in which the human player can issue orders, I think that, in fairness to the computer directed civilizations, that some more effective AI should be developed. That really is the next substantial (as opposed to fiddling round the edges, like adding roads or triremes) improvement that Clash needs (Mark, are you there?).

Well... I'd rate getting technology and the social stuff basically working above significant work on a more effective AI. Perhaps Diplomacy too, although without diplomatic AI, diplomacy would be pretty boring. I know I owe an AI spec for D6, but I was thinking to do this later in the D6 cycle after some of the other elements were there. I would rather do the big military AI model in one concerted push rather than incremental tweaks on what you have now. What is your position?

[Gary Thomas]

Hey! I am just the ever so humble coder. You are the AI designer.

Nevertheless, I would like to see the computer controlled civs a little smarter, at least with the ability to group their newly built forces for an attack (or a defense).

As far as movement orders for the human player are concerned, I think clever orders should wait until after the Command gui is developed. We can live with what we have now for the moment.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
Hey! I am just the ever so humble coder. You are the AI designer.

I'll remind you of that when your first salvo hits my AI design!

Nevertheless, I would like to see the computer controlled civs a little smarter, at least with the ability to group their newly built forces for an attack (or a defense).

Oh, if that's what you want, that won't take very long. I even had some pretty useful balance-of-power calculations for When its a good time to attack in D4 that could be ported over fairly easily when Diplomacy comes on line.

As far as movement orders for the human player are concerned, I think clever orders should wait until after the Command gui is developed. We can live with what we have now for the moment

Agreed.

[LDiCesare]

I added a few things, and tested a few existing things, in the code.
The current system seems to be more deadly than D5 code. Maybe we can lower the number of ticks to address that, or look at the following causes.

Morale:
I changed the odds to flee. They now depend on morale and the attack ratios of both opponents. I also changed the chances to successfully flee, so an outnumbered element wants to flee but, being surrounded, has problems managing it. Here is the formula I used: always at least 10%:
// For equal sides(ratio = 1): 50%
// Fleeing when having an advantage(2 to 1, ratio = 0.5): 90%
// Fleeing when having an disadvantage(1 to 2, ratio = 2): 30%
What do you think? Testing shows it may be extreme.
Also, currently, elements flee, not units. I can change that, so a unit will try to flee only if all its elements want to, which allows me to add some factor based on how much damage this unit has sustained. However, I think this shouldn't be always the case. For disciplined armies, morale should be high and units would retreat orderly (together), but barbarians, undisciplined armies, militias, should flee element-wise because they have no formation. What do you think?

Support fire:
I added an archer and tested it (NEED AN ARCHER OR CATAPULT IMAGE). It works but seems quite inefficient in comparison to an additional frontline element. This is due to 2 things:
1) Support orders, if outnumbered, are attacked by front liners, effectively preventing them from providing support fire.
2) Fights in the code always begin at close range. Krenske's model provided several ranges of fight. When that is coded, archers will be more useful, but that will not be coded in soon.

Fortifications:
I coded something for fortifications (engineer elements). That's not tested yet. I don't really like Paul's model there, because the amount of fortifications depends on a number of rounds which I find too random. That doesn't take into account existing fortifications or terrain, just field engineers (trenches and such). Any comments on Paul's model or proposal would be welcome here. I give a bonus to defense of 1/engineer for the party which won the manoeuvre phase. This needs some capping.

[LDiCesare]

Edit: Moved what I said to the AI Thread.

[Mark_Everson]

Hi Laurent. I've gone ahead and started a new AI thread. Would you copy your post over there, since it would be better to have all that stuff in one place. The new thread is AI -- the Thread. I'll respond there.

[Gary Thomas]

NEED AN ARCHER OR CATAPULT IMAGE

There is an archer image already.

Boarding: I feel very strongly that units should never be split when boarding another unit. The ramifications of some elements of a unit being in one square, while others are in a different square are just too horrible to contemplate. Also, boarding should only ever go one deep - you should not be able to load infantry onto trucks, then load the trucks onto a transport. Both should be loaded directly onto the transport.

Location and boarding (for Laurent): The MovementData object should know when the unit it describes is being carried by another unit, and which unit it is. Then the getSquare method should check to see if the unit is being carried, and, if so, return the getSquare result of the carrying unit. In the long run, there should probably be a location interface. When a unit boards another unit, its location object gets replaced by another which points to the carrying unit. This avoids the unpleasant
"if (isBeingCarried())"
type of idiom.

Triremes: I do not believe that triremes should be able to be used as transport. I know that they can in Civ, but that is the kind of inaccuracy that we are trying to avoid. Actual transport ships (round ships, in the ancient era) should be used.

Ship units: I do not know how the size scaling applies to shipping. The 5000 soldiers system does not work very well for shipping. Presumably, a transport unit should have enough ships to carry 5000 soldiers. This is in the range (for ancient times) of 20-50 ships.

Persistence of shipping: In general, ancient ships were built for a purpose, used, then discarded. I doubt whether very many lasted more than a single (economic) turn. Certainly, when the crews of ancient galleys left them (at the end of a campaign) they tended to rot away, or get cannibalized for the wood. By Roman times, or even Successor State times, some of the larger vessels may have been maintained for longer periods, but I suspect that that was exceptional.

Cheers

[LDiCesare]

Boarding: I feel very strongly that units should never be split when boarding another unit. The ramifications of some elements of a unit being in one square, while others are in a different square are just too horrible to contemplate. Also, boarding should only ever go one deep - you should not be able to load infantry onto trucks, then load the trucks onto a transport. Both should be loaded directly onto the transport.

Agree 100%. I have moved the d5 element-based code to units, which is much simpler. I haven't checked layers yet, the only thing that I strongly believe is I must take care of the size of elements in a better way for the time there are some larger than others.

Then the getSquare method should check to see if the unit is being carried, and, if so, return the getSquare result of the carrying unit.

Yes, my question is how will you manage teh move of units on the map? Will you be able to recognize that the infantry unit cannot be walking on water thus it needn't try to call setSquare() or be taken into account as far as movement rates are considered? I won't provide any method unless asked for and return the carrier's square if asked for it.

[Gary Thomas]

I will have to think about this for a bit. My first impulse is to have carried units invisible on the map, but show up with some sort of "carried" indication in the TF box, inside the box of the carrying unit. Also, being carried is a physical thing - it does not affect commands - you cannot "carry" a command. So, as far as this is concerned I only have to worry about units. I would, in this case, need a list of carried units for each carrier. But don't do anything about it yet. Give me a little while to check the TF box code.

Cheers

[Mark_Everson]

I don't have anything to gripe about, just want you to know I like what you guys are saying...

Originally posted by Gary Thomas
Triremes: I do not believe that triremes should be able to be used as transport. *snip*
Ship units: Presumably, a transport unit should have enough ships to carry 5000 soldiers. This is in the range (for ancient times) of 20-50 ships.

Sounds like a good idea to me. So do we need a transport ship icon too?

Persistence of shipping: In general, ancient ships were built for a purpose, used, then discarded.

So long as we don't get annoying effects, sounds ok. Does this mean that merchants should be able to flash-build ships for a given purpose rather than needing to maintain a fleet?

[Gary Thomas]

I don't have anything to gripe about

Go see a doctor.

However, I was a little careless in my statements. A purpose could last for centuries - feeding Rome for example. Such ships would be replaced as needed, the whole fleet being more or less stable.

On the other hand, ferrying Darius' (or Alexander's) army across the Hellespont was an exercise in grabbing any shipping available and building some more as required. Whether the original owners got their ships back is problematical, though they probably did since they almost certainly provided the crews.

At no time until the Second World War did navies have specific transport components. And most of those in WW2 were requisitioned.

So, the mechanism would be (assuming the relevant technology had been achieved), first, requisition transport ships. This, I guess would be a government function (it sure ain't economics, except as far as the victims are concerned). Then, build the rest. You should probably allow around six months for this. This is economics.

Fleets were built pretty quickly, provided the knowledge was there. Getting crews was more difficult.

Merchant fleets plying fixed routes are more difficult to deal with. We really do not want to micromanage the grain fleets. Also, while there were depredations by pirates (or enemies) and loss to storms, that never really put a serious dent (in ancient times) in the flow of trade. On the other hand, the celebrated extermination of the pirates by the Romans would have made the ROI of the ships considerably higher. I would be inclined to abstract this part of shipping.

My main point, essentially, is that the maintenace cost of an ancient fleet, per year, is equal to its building cost, or at least somewhere in that ballpark. This includes non-consumables like shipwrights, that is, it takes as many shipwrights to maintain a ship as to build it.

And yes, we do need a transport ship icon.

Cheers

PS I still don't like two different time scales.

[Mark_Everson]

I've mostly finished the D6 Military Unit ROI approach. I went with the easiest one -- ROI is dependent upon the percentage of civ expenditures that go into Army Supplies. So if you have no army ROI is quite large, if you have a big army it gets worse every unit you build.

Originally posted by Gary Thomas
Go see a doctor.

I am sick, but just with a cold

PS I still don't like two different time scales.

Well, if you don't like two timescales, which of the following do you prefer...

1) ~ 50k turns (1mo/turn thousands of years)
2) 1-5 year turns in which any military unit can go anywhere on the globe
3) insert your favorite idea here (but its Really hard to get something that works well)

This has been discussed ad nauseam before in the Clash Scales thread, and links therein. (just skim a lot of the first post which isn't relevant to time scales) I'm game to discuss it yet again if you must, but I'd rather not...

[Gary Thomas]

It was a PS after all.

Cheers

PS I still don't like two simultaneous clocks. I just get confused.

[KrikkitOne]

In dealing with the timescale, (and particularly Experience)

I'd say the simplest way to explain it is Military units spend one month/turn in "action" the rest of the turn is recuperation, logisitics.

In which case the simplest method for handling experience would be to have it decay slowly over time (as in each turn there is a 1/X chance of experience dropping a level)..where X can depend on Training, the current level of experience, whether or not the unit has been in combat this turn, etc. (or it could just be a constant)

That way if a phalanx hasn't seen battle in 10+ turns, it should "reset" its experience. [the "lingering" of experience could be considered the "reputation" of the unit...its new recruits are innately better]

[Gary Thomas]

Actually, in the ancient era, most military units went back to important things between battles. You know - ploughing, harvesting, boasting...

Cheers