Announcement

**LDiCesare** · October 22, 2001, 07:37

Command structure

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** · October 22, 2001, 08:01

Healing units

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** · October 22, 2001, 15:16

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** · October 22, 2001, 19:53

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** · October 22, 2001, 20:15

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** · October 22, 2001, 20:27

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** · October 23, 2001, 06:04

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** · October 23, 2001, 07:33

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** · October 23, 2001, 13:47

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** · October 23, 2001, 18:01

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** · October 23, 2001, 18:44

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** · October 23, 2001, 21:02

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** · October 23, 2001, 21:25

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** · October 23, 2001, 21:39

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

Announcement

Military Model V

Military Model V

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment