Military Model V

[LDiCesare]

Frontage is (dispersion * number of elements) in Krenske's model, thus an element's frontage is equal to its dispersion. I am pretty sure there will be different frontages. For instance, light cavalry and phalanx surely don't have the same dispersion. English/Zulu is an even better example.

[Mark_Everson]

Laurent:

Oops, thanks for correcting my mistake on frontage not being in the model now . Too many %$#@#$ details to keep track of!

But going forward (at least for Demo 9) maybe elements should each have their own dispersion/frontage, although this would be only a secondary effect, so maybe we should skip it.

[Gary Thomas]

Assuming then that frontage is a useful concept, here are my notions on combat resolution.

Present situation: An attempt is made to group elements in order to try and make frontages match. This has a number of problems:

• The matching is very approximate
• It does not reflect what actually happens on the battlefield
• The means of dealing with overlaps is obscure
• The code is Byzantine

Here is the way I would prefer to deal with it:

Detailed combat resolution

Partial Combat
Define a partial combat as follows:
A partial combat takes place between ooposing elements, using an actual frontage.
Call the opposing elements the blue and the red elements.
Their frontages are given by frontage_red and frontage_blue.
Calculate proportions as follows:
p_red = actual frontage / frontage_red
p_blue = actual frontage / frontage_blue

Now calculate any required proportional values for the elements, for example:
a_red = p_red * attack strength_red
a_blue = p_blue * attack strength_blue

Some values will not be proportionate, for example mobility or armour penetration.

Finally, conduct a combat with these proportionate values, and save any damage inflicted for later application.

Main combat

The primary combat is conducted as follows:

1. Arrange the opposing elements in lists.
2. Calculate the total frontage of each.
3. Divide the total frontage by 2, and find the elements which include the mid-point. Set the current position to this mid-point.
4. Move up the list from the current position, compating the partial frontages of the opposing elements. Select the smaller vaue as the actual frontage, and apply a partial combat. Move the current position up by the actual frontage.
5. Repeat the above process until one force runs out of elements.
6. If the smaller force is in a defensive position (and their general is not too stupid) finish the upper half.
7. Otherwise, continue on up the larger force, but work back down the smaller force, so its flank elements fight twice.
8. When the larger force runs out of units, or the centre is reached, finish the upper half.
9. Repeat the process for the lower half.
10. Apply all the damage values.

This procedure has some advantages:

• It is exact as far as frontages are concerned.
• It deals reasonably realistically with mismatched forces.
• It requires (once the lists are constructed) a single pass through the elements.
• It is not too difficult to code.

Cheers.

[LDiCesare]

Gary, I think I don't understand your procedure. I rephrase here what I understand and you can tell me if I am wrong:
e.g. Having defender (10 elements), attacker (16 elements), all frontage = 1/element:
Split: I have 4 sublists (right wing/left wing, I bet): 5 elements twice for defender, 8 twice for attacker.
Step 4: Do you compare element-wise? If so, I have 5 partial fights going (1 vs 1), then attacher has 3 elements left.
Step 6: Why do defenders get a bonus here? I could go for a bonus for the army which got the best manoeuvre output or if there were fortifications, but I am not sure why that should finish.
Step 7-8: The 3 elements left fight the outermost elements.

Now another question: How do you manage support fire and reserves? I can forget reserves since they will be dealt with if I can deal with support units. I guess I group 1 support element behind 1 front line element if I can. Is it OK? But then consider the following:
defender: 10 front line elements, 6 support elements.
attacker: 12 front line elements.
I should get a front line of 12 elements on each side, 2 defending support elements being actually flanked and coming unwillingly to frontline. The remaining support elements should probably be at the center. The outflanked support elements will be on the sides.
This allows to have a difference between support fire and flanking elements.
What do you think?

[Mark_Everson]

In general I like the new proposal a fair bit.

But I've got another problem with the proposal, Gary. Its the front line itself. The proposal still doesn't do any justice to Brits vs Zulus. One rifle element would span many Impis frontage. The way you have it if the Impis outnumber the rifle (the only fair fight) a few sacrificial impis would be matched up vs the brit front, getting massacred, and the end rifles would have Piles of impis attacking. I think you can resolve this if you make your proposal just a bit more detailed. The defender is chosen as the standard, and all his sub-fights will be by element. Then you use frontage, and your partial-frontage forumulae to fill in any number of opponents that match the frontage. So in my example it might be one rifle frontage matches that of 5.2 impis.

Another issue is whether the troops can form in a circle, meaning that nobody can be flanked at the start, and also limiting the space available for attackers. Thats another piece of typical rifles vs impis battles that's not quite right.

[Gary Thomas]

Laurent:

I rephrase here what I understand and you can tell me if I am wrong:

You are right. The important points are that the system also works if frontages are not equal to one, as Mark has insisted. It is based on the idea that it is a lot easier to spilt elements (partial combat) than to combine them. Also, this partial combat becomes the only kind of combat, units and commands do not need to know, directly, about combat. This, in turn, reduces dependencies and makes the code easier to manage.

How do you manage support fire and reserves?

How is support handled at present?

Mark:

But I've got another problem with the proposal, Gary. Its the front line itself. The proposal still doesn't do any justice to Brits vs Zulus. One rifle element would span many Impis frontage. The way you have it if the Impis outnumber the rifle (the only fair fight) a few sacrificial impis would be matched up vs the brit front, getting massacred, and the end rifles would have Piles of impis attacking. I think you can resolve this if you make your proposal just a bit more detailed

The system can be made as detailed as possible. However that will turn Clash into a wargame, with a detailed tactical battle system. Is that the intent?

Another issue is whether the troops can form in a circle, meaning that nobody can be flanked at the start, and also limiting the space available for attackers.

It is easy enough to provide a test of whether a force can be flanked. Later.
Cheers

[LDiCesare]

How is support handled at present?

Here is how that works now: Front lines are matched, then at most 1 support unit per front line unit is put behind 1 front line army, and the same for reserves.
Support add their firepower to the army, but are not damaged. When front line units are destroyed, if there are more support units than front line, the extra support are put in front, and the extra reserves are put in support if needed.
What is important IMO is that flanking units and support units should deserve different treatment, otherwise artillery would be quite pointless to use.

Another issue is whether the troops can form in a circle

I agree that may be a concern. I think that we should not worry about that now. The current system uses scouting and manoeuvering phases to give a bonus to the best manoeuverer. It would be possible to decree that a high enough manoeuvre result prevents flanking.

[Gary Thomas]

Here is how that works now: Front lines are matched, then at most 1 support unit per front line unit is put behind 1 front line army, and the same for reserves.

I have just looked at the code, and have a better idea of what currently happens.

I don't think it would be too difficult to modify the system to accomodate support, using frontages, simply by adding two more lists, and working up them in the same (partial combat) way. The support line will never extend beyond the front line. When doing the flank attack part, I am inclined to have them attack the support first (if there is any at that point in the line).

Again, my main purpose was to avoid the difficult task of grouping things.

Cheers

[LDiCesare]

I also think adding support lines should be quite easy.
Currently, I start out putting front line units, and support and reserve as they prefer, then, if they are in lesser number (frontage), support and reserve are brought back to front line.

On partial combat, I want to check if I understand well:
If I have 10 frontage 1 impis against a frontage 6 rifleman, I'll get 6 partial combats of (1 impi vs. 1/6th of a rifleman) and then 4 fights of 1 impi vs. helpless rifleman. I guess the actual factor that would be multiplied is the hit percentage (there is currently a hit number and a hit percentage - the first one can't scale down since it is an integer).
I also think the way I currently handle damage (damage immediately, tidy later) will have to change, although that's mainly a code issue. As you say, we can keep the damage stored in a list, and then applied at end of combat.

(Edit)
I would like to suggest one change in the proposed command modelization: Rather than have a civ registered in each army as in D5 code, I'd like elements to only know their unit, units and commands to only know their mother command. There would be one civ-wide command, which actually would replace the MilitaryInfo class. That's mainly a code issue, but it would make things much simpler if we want to allow changing of civ of units, e.g. when a civ splits in two: There would be only a limited number of commands to check for civ change.

[Gary Thomas]

On partial combat, I want to check if I understand well:
If I have 10 frontage 1 impis against a frontage 6 rifleman, I'll get 6 partial combats of (1 impi vs. 1/6th of a rifleman) and then 4 fights of 1 impi vs. helpless rifleman.

That is right.

I guess the actual factor that would be multiplied is the hit percentage (there is currently a hit number and a hit percentage - the first one can't scale down since it is an integer).

What is the hit number? I am worried that it is an integer - I thought that all parameters in Clash are supposed to be floats?

In any case, I don't think a partial unit will have a lower hit probability than the full unit - it will just do less damage if it hits. So the damage is the part that should be scaled.

I also think the way I currently handle damage (damage immediately, tidy later) will have to change, although that's mainly a code issue. As you say, we can keep the damage stored in a list, and then applied at end of combat.

I had thought that the obvious place is in the damaged element itself, accumulating as more and more of the elements bits complete their combat.

I would like to suggest one change in the proposed command modelization: Rather than have a civ registered in each army as in D5 code, I'd like elements to only know their unit, units and commands to only know their mother command. There would be one civ-wide command, which actually would replace the MilitaryInfo class. That's mainly a code issue, but it would make things much simpler if we want to allow changing of civ of units, e.g. when a civ splits in two: There would be only a limited number of commands to check for civ change.

This is exactly what I had in mind. I also hope to extend the "need to know" concept to other areas.

The most important thing I would like to do in this area is have a single list of units. Everything relating to combat, except orders and the display in the TF box, is independent of the command structure and doesn't need to know about it. Accordingly I suggest that there be a single list of units (I have a draft version of Units which has this. I will email it to you shortly) which can also include the material in the present UnitOrders (except the bit for the TF box, which I have removed - that is a command structure matter).

The only duplication left then is that the Unit has to know about its lowest level command, which also has to know about the unit. However, since this is a tight coupling (a unit's lowest level command never changes - it essentially represents the HQ for the unit). On could make an argument for directly incorporating this in the unit. What do you think?

There is no need for a civ to know about its units except through the highest level command (as you say). In addition, there is no need for a map square to know about the units in it. Personally, I would carry this decoupling further into other models.

Cheers

[Mark_Everson]

I like the direction you guys are headed in in terms of the frontage system and the command system. If things are arbitrarily integers, preventing decent subdivision, we should just make them floats. I want to get back to the merchant coding, so I'll keep my nose out of the gritty details .

The system can be made as detailed as possible. However that will turn Clash into a wargame, with a detailed tactical battle system. Is that the intent?

I just wanted the one more detail, which doesn't chew up much more in resources, and makes rifles vs impis work a Lot better!

[Gary Thomas]

I just wanted the one more detail, which doesn't chew up much more in resources, and makes rifles vs impis work a Lot better!

In Clash terms, there was only one rifles versus impis battle during the British/Zulu wars, the battle of Ulundi, in which one British unit defeated four Zulu units, with very little loss.

Does anyone know of a single battle in which an army formed a defensive circle?

Cheers

[LDiCesare]

Gary, I agree with most of what you say.
I just don't understand your issueOrders() method: If a unit has no orders, the civ should give it an order. BUT the civ doesn't know the unit, only its commands. So, rather than civ.unitOrders(army), I'd have army.getCommand().askForOrder() or something like that. This way I avoid duplication.
I want to clarify the way accumulation of damage takes place: I currently accumulate famage in the elements, when the health falls to 0, the element doesn't die immediately because combat is simultaneous and it strikes back. That is a cause of bugs, and why I'd rather have elements die immediately.
The number of hits is based on Krenske's model (cf http://www.usq.edu.au/users/krenske/game/g/assault.htm Step 4.1.2).
The integer can be changed to a float, the non integer part can be used as a multiplier of inflicted damage for the last attack, or something simpler can be devised.

[Mark_Everson]

Originally posted by LDiCesare
I want to clarify the way accumulation of damage takes place: I currently accumulate famage in the elements, when the health falls to 0, the element doesn't die immediately because combat is simultaneous and it strikes back. That is a cause of bugs, and why I'd rather have elements die immediately.

I see the problem... Can a dying element immediately attack at its starting strength for the round as part of the dying process? The thing I don't like is we may get bloodless victories where they shouldn't be. But in any case if there isn't a simple answer we can just do as you like. In most situations it may not make much difference, and why screw up the system for only a small detail.

In Clash terms, there was only one rifles versus impis battle during the British/Zulu wars, the battle of Ulundi, in which one British unit defeated four Zulu units, with very little loss.

Sure, there was only one big rifles vs impis battle, but this kind of disparity in frontages must have occurred in a less drastic form Many times in colonial wars.

[Gary Thomas]

I just don't understand your issueOrders() method: If a unit has no orders, the civ should give it an order. BUT the civ doesn't know the unit, only its commands. So, rather than civ.unitOrders(army), I'd have army.getCommand().askForOrder() or something like that. This way I avoid duplication.

civ.unitOrders(army) is a hangover from D5. It won't exist in D6. The way I have it in D6 is each unit asks its command for an order. If it doesn't have one it progresses up the command chain. If it falls off the top, the system checks to see if the unit is computer controlled, if it isn't the unit just sits there. If it is computer controlled, the lowest level command asks for an order. The present implementation (pending development of the AI) will have the lowest level obtain an order in much the same way as D5. This order is then implemented.

I actually have a lot of code modified along these lines which I can send you if you like. The reason I haven't is that it doesn't currently compile because of undecided matters relating to government (see the command and control thread where I am about to post a comment).

I want to clarify the way accumulation of damage takes place: I currently accumulate famage in the elements, when the health falls to 0, the element doesn't die immediately because combat is simultaneous and it strikes back. That is a cause of bugs, and why I'd rather have elements die immediately.

Provided the partial combat has both sides doing their thing simultaneously, I don't see any problem with immediately applying damage. On the other hand, the damage should never be so great as to inflict damage on parts of the element that have not yet fought. So the damage should be scaled to a maximum representing the health of the proportional part of the element. If an element is destroyed, then that element is then flanked, reasonably enough the attacking partial element does nothing.

Cheers