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