Military Model VI

[Gary Thomas]

I want to discuss three related matters here. All relate to movement. These are:

• Loading and unloading ships.
• The fact that horses outrun other units in the same task force.
• Apparently roads are not working (I haven't seen this myself, and, frankly, it seems unlikely).

At present the movement system works as follows:

The path finding code is passed a set of element archetypes, without duplicates, and uses these archetypes to determine the cost (in ticks, 10 ticks to a turn) of moving to a potential destination square. Having, by this means, determined the best path, the path is encapsulated in a movement order which is then stored in the task force command. When movement takes place, the list of units of is scanned. If a unit has movement orders, it, and all the othe units affected by that order (that is, all the units in the task force) are moved, one by one, and marked as moved.

The problem with this system is that the movement path depends only on the element archetypes, and not on the units themselves, and the actual implementation of the moves is oriented around the units, and not the task force.

The reason that the special list of elements is used is that most units consist of a large number of identical elements. So a list is assembled, without duplicates, for path finding purposes, thus cutting the path calculations
to a small fraction of the amount that would otherwise be needed. For example, a task force of ten identical units could well contain 100 identical elements, all of which will produce the same path. This issue is part of my reason for preferring a single element of each type in a unit, with a size factor (which does not affect movement).

All this means, unfortunately, that in the calculation, any characteristics of the unit are unknown. In particular, the fact that a sea unit is in port can be handled, but the fact that it came from a specific previous square cannot. What happens if two ships enter port from opposite side of an isthmus - they are now in the same square, and can be put into the same task force. Then the task force is given orders to move out. Ouch!

Also, in order to keep a task force together, the movement scan must be by Command, not just scanning the units. This means a substantial refactoring of the movement order execution system.

I estimate something like a week's work to fix all this. On the other hand, that will also fix the three problems noted at the start.

Cheers

[Mark_Everson]

Hi Gary:

Thanks for the code fixes, I'll check 'em out shortly, and merge our xml files for Dawn.

Originally posted by Gary Thomas
Apparently roads are not working (I haven't seen this myself, and, frankly, it seems unlikely).

I have seen it myself, and its very easy to demonstrate. Roads in fact seem to never make a difference in the current code. At least every time I've attempted to test their function they do nothing. The only reason they appear to work upon casual inspection is that roads are built along the same default paths used by units (one of the infantry ones IIRC). So a Phalanx will tend to look like its using the road, but only because the road was built along the path the phalanx would use anyway, road or no road.

Here's how you can see that roads do nothing. Pick any two points such that the path between them will have at least two equal-movement-cost alternatives. The easiest case is all the same terrain, using a "knights move" from chess (considering a knights move as a two-square process with one common-edge move, and one diagonal). For concreteness I'll specify that the path NW then W gets to the target square. Take a unit and see what the path obtained by the A* is. When I did it in Dawn the NW then W path is the preferred one. However the same unit has an equal-cost path of W then NW. If a road were to break the symetry then the unit should prefer to go on the road. Steps of the demonstration are;
1. Find prefered path for the unit
2. Cancel units orders so it dosn't actually take preferred path
3. Build a road on the non-prefered path. (must use two segments to get it to build this way, otherwise it wants to be on the preferred path.)
4. Now order movement to the target square.

The unit will still take the previously preferred path over the one with the shiny new road. I have done this for a Warrior with all-grassland and also for a rolling-broken-broken path in Dawn.

Roads are either not used in pathfinding, or their effect on the cost is at least very often zero. Which is the problem, I don't know.

On current movement approach...

Wow, I had no idea it was done that way. I admit I'd always assumed that a TF was treated as a whole, until the Hannibal thing came up. Do you intend to make it so? It seems from your post that you do, and I agree, but I just want to make sure.

And what is your approach for how to save the naval conunrum? Can we just prohibit naval units from merging if they come from topologically different coasts? I hope you know what I mean, I can elaborate if needed.

[Mark_Everson]

Originally posted by Mark_Everson
The unit will still take the previously preferred path over the one with the shiny new road. I have done this for a Warrior with all-grassland and also for a rolling-broken-broken path in Dawn.

Oops, just realized rolling-broken-broken doesn't really have equivalent paths since one will be diagonal rolling-broken, and the other across a square edge. I just redid it with all rolling and the result was the same.

[LDiCesare]

Originally posted by Mark_Everson
Longer-term we need a way for little squares to have a chance of automatically surrendering, but we ain't there yet. FE if the provincial capital is taken, and x% of the rest of the province, and the military balance is working against, a lot of squares could just willingly change hands.

This would involve some social and governmental factors as well as military ones. I think its important we have this to fulfill our low micromanagement pledge to players also!

I agree with that and would like to add that these chances are probably based on the same factors as those needed to know whether the square will raise a militia for or against an invading army. Doing that first in-square and then extending it to "neighbouring squares" or province looks like a good way to go.

[Gary Thomas]

There is a problem with the code, arising from someone noticing that Hannibal's cavalry outran the rest of the army. In the way the code worked at the time each unit followed its own orders, regardless of others. So orders could be given to a task force, but each unit would interpret the orders individually.

To prevent the outrunning bug, I refactored the movement system so task forces move together. Because there was no way, using the gui, to give individual units orders, I didn't see any problem with this, and bypassed individual unit orders.

Unfortunately the military code, when a unit retreats, gives the unit an order to move. Because I had thought of orders as "orders from headquarters" I had not covered this situation. The way the code is at present such orders are never executed.

There are a variety of ways of fixing the problem:

• Revert the code to the way it was, which leaves the outrunning bug.
• Leave the code the way it is, but check for individual unit orders and execute them, a lot of work.
• Take the retreat code outside the order system and deal with it separately.

I am in favour of the last, because I envisage the orders system as covering situations in which a higher command issues an order, and no higher command is going to issue an order to "panic and run away".

My personal preference is to merely teleport the retreating unit to the destination square which will be the one it was last in and hence an adjacent square to the one in which the combat occurred. As far as the code is concerned it will take less than two minutes to implement this.

Cheers

[LDiCesare]

Take the retreat code outside the order system and deal with it separately.

I am in favour of the last, because I envisage the orders system as covering situations in which a higher command issues an order, and no higher command is going to issue an order to "panic and run away".

My personal preference is to merely teleport the retreating unit to the destination square which will be the one it was last in and hence an adjacent square to the one in which the combat occurred. As far as the code is concerned it will take less than two minutes to implement this.

I am against teleportation. This is because retreat takes time and shouldn't be instantaneous. It allows attackers to hunt down enemies until they manage to leave the square, thus getting one or two more ticks of fight. It is important because otherwise, the combat will end soon and you will never be able to destroy an enemy army, which leads to terrible gameplay.

The higher command has to adjust its orders anyway, so I would rather keep the order system. In this view I can do it two ways:
I could remove the units from their previous command and put them into a new one, "fleeer command". I could use it for one turn and would have to put the units back into their original commands once they have retreated correctly.
Or I could look for the order which effectively gives the order and change it. Is it possible to locate rapidly these "stack" commands?

I have to say that the outrunning bug was IMO mostly a display bug, i.e. we displayed all the units of the TF instead of all units in the square. The "moving fast" part never bugged me. Would it be possible to revert to the old code but display properly as an alternative? I am afraid that long-term we will have trouble making high level commands with the current system, which effectively limits us to stacks.

[Gary Thomas]

I have been rather working toward a system in which a task force is always in a single square. I realize that this is a reversal of my previous view, but at the time I was overly influenced by the code that existed at the time. Now that we have a flexible command system, an order like "assemble at Rome" can be given at a higher level, although there is no gui to do that now, I hope this will be available reasonably soon.

Accordingly, my preference is to transfer a retreating unit to a new task force and give that task force the retreat order.

put them into a new one, "fleeer command"

Apart from my suspicion that "fleeer" isn't English, we do not want all the fleeing units (which may be a continent apart) to be in a single task force. I would have a task force per unit and give the task force the same name as the unit. Multiple units retreating from the same square will nevertheless not have sufficient organization left to form a coherent task force and should be in separate task forces.


Cheers

[LDiCesare]

I thought of one command per square, not one for all. It is actually easier to put each unit in a different TF. I would like them to return to their previous TF after the fight, because players won't like to regroup them all in a single TF. I will try that and see if there are problems when the reformed TF tries to resume its orders.

[Gary Thomas]

It causes the whole task force to retreat, not just the fuyards.

Cheers

[Mark_Everson]

Hi Gents, I hope my comments are still timely...

First, Laurent, I have to apologize, but you weren't available when Gary and I discussed the refactoring to make the TFs work as expected. IMO its quite clear that the outrunning bug is not simpy a display bug. The TF is really broken up into different packets which can then attack a square separately. This is quite distinct from the desired behavior of a TF attacking all at once. Since the combined-forces TFs when split up are militarily less powerful than the whole TF, the outrunning bug has serious effects on gameplay. That's why we thought it needed to be fixed. I think we should not return to the old code where different TF components go at their own speed and by their own routes. That leaves us with the issue of what to be done about retreating units.

On the topic of how to handle retreating units, I have my own proposal, that takes some elements from each of your positions. First, I want to make a distinction between units or even elements that flee from battle, and tactical or strategic withdrawls that take place under the normal military command structure. Units that flee from battle IMO should not leave the square immediately. They have just broken off from battle, and are in some position that is removed from the battle location. IMO the best way to handle fleeing from battle is just to mark the unit as being outside the scope of the battle temporarily. (They might be back in the battle on the next tick). The case of the local command making a decision to break off from battle is utterly distinct from a morale failure that leads to units withdrawing. When the local commander orders breaking off, it would cause the entire friendly force to try and disengage. It would then leave the field, and have to make for another square. This would be done by TF similarly to what Laurent has outlined above.

In more detail, my proposal is:

Retreating units are marked as outside the battle. Laurent may already have a way of handling this, and I just don't know what it is... I think it best that units with broken morale remain in their TF and simply do not contribute to the combat values of it. There are many details that need to be sorted out eventually such as: under what conditions can a victorious army hunt down these units; and when might a unit with broken morale recover to the extent that it can rejoin the battle in a subsequent tick. But for now, we can just take them out of the battle without being out of the square. Units with broken morale do not leave the square on their own or as part of a newly-constituted TF.

I think the decision to break off, which is a local Command decision, can be handled sensibly in the general way Laurent outlined that we've been discussing for quite a while. It consists of three steps.

1. AI simulating local commander makes decision as to whether to try to break off/ retreat
2. If answer to 1 is yes, an attempt is made to avoid battle (if it hasn't started yet) or disengage (if battle has started and odds have gone against them) This is what is now like a 25% chance as I understand it. This would become more nuanced in time.
3. Orders are given to withdraw to a particular location by a specified route. These orders replace whatever previous attack orders the unit may have had. Long-term I am with Laurent that the units withdrawing should not teleport away, but as a temporary expedient, I don't have any major problems with it.

I've got to run, will try to add to this later.

Cya,

Mark

[Mark_Everson]

I think I ended up covering most of the important stuff in my previous post. I'll just have to wait to see if the two of you think that approach is workable.

Laurent, on your criticism of teleporting (in terms of it taking too long to wipe out an opposing army) we can IMO just change the chances for a successful break-off to give decent play balance pending doing things right.

Also, I have a question. Do the current attack-odds limitations apply before the TF moves into the square? FE if I send a two-Legion TF to beat on a single legion, and then four more join the single one before my TF moves in, is it smart enough to know not to make the final move? If not, that is an important part of having the automatic attack odds stuff work right.

[LDiCesare]

Hi Mark!

First, I want to make a distinction between units or even elements that flee from battle, and tactical or strategic withdrawls that take place under the normal military command structure. Units that flee from battle IMO should not leave the square immediately. They have just broken off from battle, and are in some position that is removed from the battle location. IMO the best way to handle fleeing from battle is just to mark the unit as being outside the scope of the battle temporarily. (They might be back in the battle on the next tick).

That is how it works in the code. Elements who didn't make a morale check are removed from the fight for this tick and stay in the square. Then, at the end of the tick, the command looks at its odds and decides whether to flee or not. It is always successful now, subject to playtest. Its order to retreat allows it to flee. Note that if ALL elements fled in a fight, the command will always want to flee and leave the square. Subject to change.

The odds are taken into consideration only when in-square, thus fights are fought, but the army will try to disengage after a single tick. Since move is simultaneous, it would be hard to do it otherwise. It is possible, but in some situations, you would move when you shouldn't and vice versa.

[Mark_Everson]

Thanks for the quick response Laurent! Its good to be back in communication.

Originally posted by LDiCesare
That is how it works in the code. Elements who didn't make a morale check are removed from the fight for this tick and stay in the square. (snip)

That sounds sensible to me. My only quibble is that they automatically succeed in withdrawing (I think that's what you're saying). It should IMO only be a chance. In the future the chance should depend on force composition and other factors. But for now it can certainly be just a fixed percentage.

The odds are taken into consideration only when in-square, thus fights are fought, but the army will try to disengage after a single tick. Since move is simultaneous, it would be hard to do it otherwise. It is possible, but in some situations, you would move when you shouldn't and vice versa.

I see your point. The thing that really bothers me is when fights start that just wouldn't happen because the're Stupid . I think the two sides moving into the square is ok because of the complications you cite. But as I understand it the first check of whether someone wants to withdraw is not made until after the battle has run one tick. how about making the first tick of a battle special, in that there would be a Pre-battle withdrawl check? That way the local commander is making a decision whether to go forward with an attack based on whatever info is available (now the information is perfect, but that will change in the future). If the odds were not good enough to go forward with an attack, the TF would attempt to withdraw immediately, and should have a fairly good chance to do so IMO. They would also get chances to withdraw after the battle has been joined, but this can be a lot more difficult.

[Mark_Everson]

naval / land combined TFs

This isn't essential for D7, but I wanted to put up the idea before I forgot it.

Gary said in email:

[He, in the current code,] stopped land and sea units being combined in the same TF.

It seems to me that forming a TF of land/naval units is a rational way to allow loading of troops onto ships. You would only be able to form the TF if the land units could be carried with the ships.

On a related note, in Demo 4 we used to have combined military/land TFs that could have any composition, but then could only move on coastal squares. (That was the case if there were more land units than the boats could carry.) Post D7 I think we need a way to keep naval and land TFs quite close to each other. Ideally a land force and naval force should be able to proceed along a coast together in some fashion. This is a thing that was very common in ancient warfare as I understand it.

Presently there is no graceful way I can see to do that. This is an unforseen effect of requiring a naval unit to go straight out to sea, rather than moving directly from coastal to coastal square. One possible fix is to loosen the restrictions on naval movement so that naval units can move along a coastal square. I think if we consider carefully we can have a system where naval movement is a little less rigid than having to move directly out to sea to the square you came from as it is now, and yet still render impossible ships jumping over isthmuses.

What do you guys think in general? I definitely Don't want to slow down D7 with a detailed discussion of this now.

[Gary Thomas]

It seems to me that forming a TF of land/naval units is a rational way to allow loading of troops onto ships. You would only be able to form the TF if the land units could be carried with the ships.

Then the land units would fight like ships.

I have already had to fix a few oddities in the system, like loading a land unit onto a trireme, then loading that trireme onto another trireme, and another again...

Presumably if we had a land transport unit we could then load the whole lot onto a wagon and transport it overland.

On a related note, in Demo 4 we used to have combined military/land TFs that could have any composition, but then could only move on coastal squares. (That was the case if there were more land units than the boats could carry.) Post D7 I think we need a way to keep naval and land TFs quite close to each other. Ideally a land force and naval force should be able to proceed along a coast together in some fashion. This is a thing that was very common in ancient warfare as I understand it.

It wasn't as far as I know. In any case, they could not fight together. If they were in the same task force we get the peculiar situation of a battle with heavy infantry, cavalry and triremes in the front line, supported by archers in the second line.

Troops loaded on triremes (which, of course never happened) could assist them to some extent, but there is no way that a trireme could help in a land battle.

Since the triremes move a lot faster than troops, moving out to sea them back will not cause them to lag behind.

Soon (ha!) I will implement the notion I had in designing the command system. There is nothing to prevent a higher level command having a land and a sea element, and getting a single move order which will cause them to move together if they are able.

I am not sure how the fighting takes place now. The Encounter class just gets all the units belonging to a civilization and in the same square as a single undifferentiated list.

On another tack, I am having a great deal of difficulty with loading units onto transport. The problem is that loading is done on a unit to unit basis. So, in general, a land task force will get split up among different sea task forces, perhaps going to different destinations, and perhaps with some left behind. With disastrous results.

My preference is to restrict boarding to the task force level. That is, an entire task force boards another task force and thus stays together. There is nothing to stop someone splitting the land task force up if they want to, and putting it on different sea task forces. Splitting up the sea task force will automatically also split up any land task force it is carrying.

Cheers