Military Model V

[Mark_Everson]

It's time for Military Thread V!

For reference, the beginning of the immediate predecessor, the Military IV discussion, is here.

A brief status report is in order, and seeing as there's no one in charge of the military model design at the moment, so I'll do it.

[edit] Actually Gary has just signed up to be Mil model lead. Thanks for taking this on Gary! Now, how about updating all Krenske's stuff and putting it on the Clash Web Page in your copious spare time

The current model:

For an overview of what has gone before you should look at the Military Page at the Clash web site. For a brief idea of what we're doing, look at the introduction there. After that, the next important thing you should check out is the battle and units model worked out by Harli and Krenske. Here is a link to the Scouting Model of their design. Don't follow the links in it, more current links to the other modules (Manuver, Assault, and Units) are found in the Updated Model.

Although we have a lot of the bare bones of the model, there is an Enormous amount of specification, and refinement, to be done. We are interested in getting whatever comments people have at any level on the basic models, or things that were set in the other discussions. But the most important part is that we will soon have code to test further parts of the model, which leads to ...

Demo 5, with the new military model is being launched just about now. Laurent has gotten the new military code off the ground. In a day or two, please download demo 5 and let us know what you think.

[LDiCesare]

In Demo 5, units are grouped into TaskForces which are a physical grouping of units in a square AND a command-oriented structure (they are given one task).
This causes some confusion in the code, and prevents some moves like having the various units run to a given point, with the fastest arriving first.
To make life better for the programmer and the player, Gary suggested that we have a distinct Command structure which is not related to physical location of the unit.
This Command structure, at the lowest level, is the task force, containing units which can be scattered but to which you give the same orders.
At higher levels, you could have commands of commands (think army-brigade-regiment-...)
I think it would be cool for the AI to be able to use these objects and give them high level orders, each subcommand giving more specific orders to its own constituants.
That way, units take orders from their command (task force) which takes order from its own command (e.g. brigade) and so on, till there is no command left on top, in which case it is either the player or top-level AI which gives the orders.
For a first drop, the propagation of orders can be dumb (pass move orders downwards).
In such a structure, does anyone see a point in having commands containing both commands and units or can I make them two different things?

[LDiCesare]

Units need a cost to upkeep, they should also cost something to heal: Casualties must be replaced by rookies, equipment rebuilt etc.
Note this is radically different from civ2 where it costs nothing to heal (except lose a turn in a barracks).
I suggest the price of healing a unit be the price of building its dead elements (maybe a little less?). Just to remind, a unit is made of elements. I don't speak about healing a dead unit, since a new one should be rebuilt. The healing rate would then depend on how much the econ is ready to pay. It could be considered as part of the upkeep cost, so after a battle the upkeep cost of armies would rise, and the econ would decide what to pay, and how to pay: how much for "normal" upkeep + extra sum for repairing/replacing dead elements. I can consider that the upkeep of the unit is kept constant, and the part beyond what is needed by the living elements is used to create new elements. That way, you couldn't heal an underpaid army.
I am not sure about when to implement that, but what do you think about how to handle healing/repairing wounded units?

[Gary Thomas]

I feel rather strongly that, at the bottom level, a command should apply to just one unit, rather than a list of units. Otherwise we have two different knids of list to manage, and this is what has caused problems in the D5 model. A single unit command would have the same interface as a higher level command, but different data fields (a reference to a single unit). The access method should be such that, at construction, ONLY a unit can be added, and ONLY one unit.

A t the higher levels, there should be a command class which holds a list of lower level commands (much as task force works now). This class should have a protected constructor, but otherwise be general.

Then, and this is a matter for discussion, my preference would be to call the lowest level class (the one that commands a single unit) a Brigade. I would then extend the command object to a Division class (with an add method that will only accept Brigade objects), an Army class (to which only Divisions can be added), then ArmyGroup, Front, HighCommand using the same principle.

The reason for the strict structure is to make it possible to construct a reasonable GUI to allow the player to shuffle these around. It has the advantage that the tree has a constant depth. Where for some reason, it is desired to attach a brigade directly to an army, a divsion with a single brigade can be constructed as an intermediary.

I don't think much can be gained by inserting a Corps level.

On the interaction between command objects and units, only command objects will contain orders. The unit will follow the orders of the immediate command object. If those orders are empty it will look at the next higher level, and so on. In effect, lower level orders override higher level ones.

Focussing downwards, each unit will record its location, and a list of elements (without trying to share the command level code for a list of lower level commands). Commands and units have nothing in common.

Combat is between elements. It does not take place at any other level. At present there is some amalgamation of elements into temporary task forces. I am not sure why this is done - it doesn't seem a good idea, and enormously complicates the code.

The model I would be inclined to use, is to line the elements of each side up (with due concern for support and reserve) and match up the middle. If one side has a greater frontage than the other, the extra units would overlap, and, in effect, execute a flanking attack.

So, I would go, outward from the centre, element by element, making the attacks. When one side runs out, the other side continues, working back down the other side (towards its centre). If the centre is reached, stop. The idea here is that only so many elements can get access to make an attack. This (crudely) simulates a flank attack.

This system would remove any necessity for combat aggregation of elements, and hence for the existence of temporary task forces.

Since only elements conduct combat, nothing else needs to know about armour penetration, etc.

However, elements are invisible to the player, and some sort of aggregation will be required simply for reporting purposes. At present only attack strength, health, and defence strength are reported, so only those should be added up (I think defence strength should added, not averaged - with averaging, as a unit is damaged, the weaker elements go first, and hence the defence strength goes up!). The command structure should also be able to perform these three aggregations in order to report some idea of the ability at each level.

To simplify this aggregation, I would intruduce a CommandData object. A CombatWorthy or Combatant interface would have only one method:

public CombatData getCombatData()

implemented by Element, Unit and Command, which would create a CombatData object, accumulating the needed value when it does. In effect the reported values will be recalculated as needed, and then the object discarded. The CombatData object constructor will be given a collection to aggregate over.

Of all of the items mentioned above, only the unit will have a location (though perhaps at a later stage commands will have a headquarters, however that will be treated as a unit, if and when). When moving, the unit consults all its elements to establish what it can or cannot do (this happens in D5). So, as now, the unit needs things like ticksRemaining(). I don't actually think that this needs to be an interface, since only units move.

I am not convinced that the same structure applies to naval units. I haven't really given it much thought, but suspect that units ought to be individual ships, with Flotilla, Fleet and GrandFleet as higher levels. This will have to be reconciled with the land system.

I AM convinced that air units need a different system. But that is for later.

Cheers

[Mark_Everson]

I thought I should say here that Gary has just signed up to be Mil model lead. I put a notice in the top of the thread, but I thought some people that have already read the top might skip over it. Thanks for taking this on Gary!

Laurent:

Your command structure comment is certainly the sort of thing I had in mind. I think it would be best to have only the lowest level of command actually contain task forces or units (whichever we decide is the thing that appears on the map). I'll say more about this when I respond to Gary's post.

On healing units, I think that units in an area that can build new elements should be able to bring the unit back up to full strength at a cost as you suggest. However, units "at the front" should require replacements being sent to them. Possibly replacements could be sent as entire units, and the task force or command can break down green units to supplement missing elements in the existing units. For now why don't we say that building new and replacing cost the same just for simplicity. IMO we can put off implementation for this for quite some time without it really hurting the game.

Gary's comments:

First of all, I do Strongly agree that there needs to be a strict structure imposed on both the physical and a command side of the military code. Laurent, I can't claim the expertise that Gary has in coding architecture, but what he says he has the ring of truth to me. However, he may be completely deluded on the details .

I feel rather strongly that, at the bottom level, a command should apply to just one unit, rather than a list of units. Otherwise we have two different knids of list to manage, and this is what has caused problems in the D5 model.

Well, I disagree fairly strongly with both these points. I believe it is equally valid for the Task Force to be the bottom piece of the physical military structure that appears on the map. However, I agree that if the TF is the thing that keeps track of where it is, and is at the bottom of physical military structure, then it Must not be possible for bare Units to exist. They would always need to be wrapped in a TF to be "on the field" or perhaps more properly, on the map. This is where I differ with your second point. The problem with the D5 military model was that bare Units and TFs could both wander around, leading to all sorts of potential bugs. I think that TFs are a better base for the military model than units. For much of history, armies mostly consisted of big masses of troops that moved mostly together in the same Clash square. Since about the Franco Prussian war and mass mobilization brought about by modern economies that hasn't been true. But nonetheless, for a huge part of the game the player may just want to send their "killer stack(s)" rampaging around the board without the possibility of some parts falling behind and their army being annihilated because it was found by the enemy when strung out across several squares. However, I will admit that if we make Commands able to have orders like "do not disperse" then there isn't much difference between my approach and Gary's.

On Brigade, Division etc. for the names, these are OK for coding IMO. But if we use these names we Must have alternatives available for early periods. Caesar's Division just doesn't cut it. However, having these levels fixed would be good because then we could come up with culturally appropriate names that can be used instead of Brigade etc. for different cultures and different periods of history.

The unit will follow the orders of the immediate command object. If those orders are empty it will look at the next higher level, and so on. In effect, lower level orders override higher level ones.

I may be being dumb tonight, but it's not clear to me this will be the best thing to do in all circumstances. But all I have is a vague feeling of unease at the back of my head. Perhaps it's a flea If nothing else, higher Command objects will certainly need to give commands to lower objects at some point. But then if the higher level object changes its mind, those lower-level commands will potentially still be there to override what the higher level says is Now needed. Anyway, I think I need to be enlightened in a little more detail on this one!

On the rest, sorry to disappoint you, but I basically agree wholeheartedly. I like the concept of elements, and think the refined model for how combat works is quite good. It will also help us to describe battle results in ways that most people will be familiar with, which is a big bonus.

Well that's my $.02, I'm waiting to see what Laurent thinks of the monster post .

[Gary Thomas]

Well, I disagree fairly strongly with both these points. I believe it is equally valid for the Task Force to be the bottom piece of the physical military structure that appears on the map.

My whole point has been that task forces try to be two things, and do both badly. A unit, as I see it, is indivisible, and hence is guaranteed to be in a single square, so it should hold the location data. What you actually appear to be talking about is the Division level command. This need not be in a single square. However, in the GUI I expect to provide a means of showing all the parts of any level of command. If part of a command is in the current square, the missing parts will be shown in the TF box, but greyed out. If they are selected, their square will become the selected square.

I had no intention of having any task forces as they exist at present. In effect the division level command replaces them. The brigade level command only exists so you can give orders to an individual brigade. If you have lots of units at the lowest level you have to change your command structure in order to give an order to a single unit. This is clearly silly.

However, I agree that if the TF is the thing that keeps track of where it is, and is at the bottom of physical military structure, then it Must not be possible for bare Units to exist. They would always need to be wrapped in a TF to be "on the field" or perhaps more properly, on the map.

My view is that a task force is an organizational thing. There is no problem with imagining a task force with its component units in different squares. Hence, it doesn't, logically, have a single location. Units, on the other hand, do.

However, I will admit that if we make Commands able to have orders like "do not disperse" then there isn't much difference between my approach and Gary's.

I assumed that "Do not disperse" will be the default. The alternative is "Forced march" which (as it did in history) will cause the units to straggle. Another way in which a command will spread out is if scouting units are sent to adjacent squares. Obviously a group units command will be required to bring them back.

On Brigade, Division etc. for the names, these are OK for coding IMO. But if we use these names we Must have alternatives available for early periods. Caesar's Division just doesn't cut it. However, having these levels fixed would be good because then we could come up with culturally appropriate names that can be used instead of Brigade etc. for different cultures and different periods of history.

Now that is an excellent idea. Each instance can tell you what it is called. This can be set by the scenario data. On the other hand, in the Roman era only legions will do - centuries and even cohorts are too small.

Cheers

[Gary Thomas]

On the questioon of command propogation, I have been anticipating, somewhat the implementation of AI.

Each Unit has to look for an order. They will go, in the first instance, to their immediate headquarters. If they get a order from that level, that will be the orders for that tick. If there are no orders there, they will go one level higher. This mechanism is, essentially, needed to make larger level commands move together - if a whole army has a movement order, the actual order has to be at that level, to prevent cavalry divisions outstripping the rest.

There is a difference between Player and AI orders here. The Player will be expected to give (or cancel) orders at the appropriate level. The AI will give orders at some level. That level will check requirements and possibly give lower level orders, down to the Brigade level. The Unit doesn't know, or care, whether it is getting AI or Player orders, the format and mechanism are the same.

The effect is that an Army says "Attack". The Division then decides which Brigades (units) attack where and how.

Cheers

[LDiCesare]

Commands having only one unit seems good to me. To please Mark, we can use the name TaskForce somewhere along the line of Command names, so some commands manipulated by the player will be task forces.

The temp task force thing is used in combat to manage grouping of elements with different frontage, and the way the model manages flanking (which is less detailed and realistic than what you propose, but relatively simple). Note that limiting the number of elements able to flank will certainly help lower armies in 2 vs 1 fight, which was one of my concerns in D5 implementation.

Mark, yes, healing can wait, but I thought of it so I made a proposal anyway.

Last, I wanted to disagree a bit. Orders: I thought initially as Gary, but then I thought it could cause problems when an Army is added to a ArmyGroup, changing all orders downwards... but then it doesn't seem to cause any problem and I can't disagree

[Mark_Everson]

OK, I can cope with the one-unit stuff since I'm outvoted, and I can see a fair amount of the logic behind it anyway... I've stated pretty much what I want out of the architecture, and I'll be basically happy if that functionality is delivered . Laurent, thanks for thinking of me, but its not necessary we keep the name Task Force. However, I would like a vote in whatever replaces it, since we're going to be saying it A Lot. But we do need a name to talk about all the levels of command together... since I don't want to have to say Brigade, or Division or... all the time. Perhaps its Task Force .

I will monitor the discussion/code, and mostly only squawk when I think something is being missed, or going the wrong way. Then you guys can straighten me out!

[Gary Thomas]

Laurent:

Commands having only one unit seems good to me. To please Mark, we can use the name TaskForce somewhere along the line of Command names, so some commands manipulated by the player will be task forces.

Of course we could use the name task force instead of command. But why use an inappropriate two word expression where an appropriate single word expression will do?

The temp task force thing is used in combat to manage grouping of elements with different frontage, and the way the model manages flanking (which is less detailed and realistic than what you propose, but relatively simple). Note that limiting the number of elements able to flank will certainly help lower armies in 2 vs 1 fight, which was one of my concerns in D5 implementation.

As I understand it, all the frontages are currently 1 per element. If we defined an element as having a frontage of one, the code is considerably simpler (BattleMatching becomes unnecessary). For units with a wider frontage, add more (possibly weaker) elements. I would have thought that the system I suggested was simpler, since it requires no grouping of elements at all.

Last, I wanted to disagree a bit. Orders: I thought initially as Gary, but then I thought it could cause problems when an Army is added to a ArmyGroup, changing all orders downwards

Any change in command structure will automatically cancel all lower level orders. One would expect them to be reissued anyway. Attaching a command to a higher level command will, in effect, assign any higher level orders to that command, and cancel any specific orders, though new ones could be issued.

Mark:

I've stated pretty much what I want out of the architecture

You have?

However, I would like a vote in whatever replaces it, since we're going to be saying it A Lot. But we do need a name to talk about all the levels of command together... since I don't want to have to say Brigade, or Division or... all the time. Perhaps its Task Force

I have assumed that the generic term would be Command (you know, like in real life). You certainly wouldn't call a command that covered the whole of the eastern front a "task force". As far as the objection to the specific terms, how about CommandLevel1 (Brigade), CommandLevel2 (Division), CommandLevel3 (Army), CommandLevel4 (Army Group), CommandLevel5 (Front) and CommandLevel6 (High Command). In any particular context the levels could be given appropriate names.

Building a little on this topic, I feel that the number of levels permitted could be a variable, dependent on technology. Certainly no more than four levels existed in Roman times (Legion, Army, Province, Empire).

Cheers

[Mark_Everson]

Elements clearly will not always have the same frontage. 500 modern soldiers have a frontage At Least 10x larger than for a phalanx. Lethality of modern weapons and all that... It may or may not have been in the original model, but IMO it it needed.

"I've stated pretty much what I want out of the architecture"
Perhaps that was overly broad, and a lot of it was "what he said..."

Variable number of levels is ok by me.

[Gary Thomas]

Elements clearly will not always have the same frontage. 500 modern soldiers have a frontage At Least 10x larger than for a phalanx. Lethality of modern weapons and all that... It may or may not have been in the original model, but IMO it it needed.

This is not the issue. As long as they have the same frontage as the elements they are fighting, for our purposes, the frontage can be taken a 1.

I cannot imagine any realistic military model in which 500 modern soldiers fight a phalanx.

On the other hand is an element fixed at 500 soldiers? And, if so, why?

Cheers

[Mark_Everson]

Elements Will Not always have the same frontage. Very frequently in history one side has a military technology or organizational breakthrough that the other side does not! English vs Zulus, Legion (in staggered formation, whatever its called) vs Phalanx, Wellington vs Napoleonic troops in the peninsular campaign (two lines vs three), the list goes on and on...

500... I can't recall exactly. You could do a forum search and look over the units part of Krenske's pages. It doesn't have to be immutable though, if that's what you're getting at. But if we ever go to a tactical system, we don't want too many elements per unit.

[Gary Thomas]

In the updated model, frontage doesn't exist. Units have dispersal, but this is used for protection from bombardment.

It may have been mentioned somewhere in the forum, but I haven't found it.

Cheers

[Mark_Everson]

Hey Gary:

You're quite right frontage isn't in the model right now. I was talking about how it should be IMO, not how it is.

I'd meant for the search for you to look for '500' in military threads. I just did it and you find some references as to why krenske chose that as the target. Here's the 500 men per element link I found.

And coincedentally if you look at the link you'll see how to point to a particular post (told you before I had no idea, but this is what the search gave me) and even how to higlight in red text in the post.

Cya

[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