Military Model IV

[Mark_Everson]

I definitely think we will need 'odds ratio' numbers for both garrison and sentry troops. In fact for most orders... But I think the priority on getting that going isn't really high.

On the general implementation of the odds stuff and whether a side wants to fight a battle, or not, your take sounds as good as any at this stage. Eventually we will need to refine these things, but I don't think we need to do that soon, since a lot of the factors involved won't be in the game for a bit.

[LDiCesare]

I've sent Gary some code that will lead to this user interface for attacking/moving:
Just move there with the keys. If there is someone, fight occurs. I think it's better than hittinf F because:
1) it is easier to code ( )
2) mainly, you hit one key less
3) it strikes me as abnormal that you could send troops to a place guarded by a hundred warriors and none spot you (and fight) unless you attack them.
Of course, 3 should be tempered by diplomacy but the code could remain the same from the UI point of view. The EncounterManager class could decide to launch a fight or not based on some diplomatic relations between the armies that meet (currently they fight if their civs are different, which is already a check).

[Mark_Everson]

Thanks! I'll check it out when I get a chance. My only reservation with the way you did it, is that it mandates forming everyone into one big TF first. There is no way to move in attackers from both north and south given the way you're handling it. At least as I read your description.

My 'F' was intended to be Just for d5. As you say in the long run we need something that considers diplomatic status and TF orders. And of course the tick on which the armies get there to determine whether they'd meet at all.

[LDiCesare]

Yes, it'd be nice to attack from 2 squares.
How would you see that from a UI point of view, though?
To me the easiest is to have all armies move around, then a finish moving button, and here we go 10 fights in a row. That means you have to be careful in case a fight turns out badly since you cannot re-attack in the same turn. Is that acceptable? Is there a dusty thread where the UI of the player turn sequence was discussed (I have no access to the search button right now )?
It may be what you intended from the beginning, but I read the F as one fight.
So this sums up to:
Do you want to be able to fight and then move in the same turn, in which case you'd hit "fight" 3 or 4 times in a turn before being done, or do you want to say "done moving" and let war happen a little everywhere?
[This message has been edited by LDiCesare (edited May 09, 2001).]

[Mark_Everson]

quote: Originally posted by LDiCesare on 05-09-2001 09:26 AM Yes, it'd be nice to attack from 2 squares. How would you see that from a UI point of view, though?

My thought was to use arrows. At the beginning of the turn there are just TFs on the map. When I move a TF the TF icon moves, but it leaves a light arrow showing where it started, and each step (square) on its plotted move. I think we need something like this at least as an option to remind the player that they are Planning moves, but the moves may never even happen due to circumstances like the army was attacked on route. So if such arrows are used you can show a multi-square attack simply.

quote: To me the easiest is to have all armies move around, then a finish moving button, and here we go 10 fights in a row. That means you have to be careful in case a fight turns out badly since you cannot re-attack in the same turn. Is that acceptable?

Yes that is the basic plan. However reinforcements could show up in later ticks to reivigorate a previously losing fight.

quote: Is there a dusty thread where the UI of the player turn sequence was discussed (I have no access to the search button right now )? It may be what you intended from the beginning, but I read the F as one fight.

thread with UI... no, I don't recall one, we never got that far. Yes I meant the F as one fight, but just for d5. That's because it is not a real game yet. Just a 'fight tester' on the military side. I'll check out what you did when I get the chance. Its probably good enough.

quote: So this sums up to: Do you want to be able to fight and then move in the same turn, in which case you'd hit "fight" 3 or 4 times in a turn before being done, or do you want to say "done moving" and let war happen a little everywhere?

I had meant the former, but the latter is fine if that's the way you did it because that is the way it will really be in the future anyway!

[LDiCesare]

The code I sent Gary fights a la civ, which means when you enter a square, fight occurs, with the drawbacks you gave. For testing, it should be enough I believe, though you might have 2 armies remaining in the same square and they won't fight till someone else comes in with such a system...
The code is made so you give orders to armies, the orders specify a target square, and MoveManager manages all the armies at once, so it would be possible to put a end-of-turn button now. The button just has to tell the MoveManager which armies it manages, but that should be trivial from the Civ info and the Map/Gamedata, so we could do it that way now (provided we have the button). The problem would be the lack of feedback (the arrows you suggested) to the player.
I elaborate on your arrows idea. That seems a good way to show information, particularly if we can change a few things on the arrows, like color, arrow shape/icon to express different orders, like Fortify (go and fortify in that square), attack, support, scout, spy, whatever.

[Mark_Everson]

We may be able to do something to show orders on the arrows as you suggest. But we'll have to do it carefully so that things don't get too cluttered and confusing.

Unless we have other issues holding us up, I am inclined to wait for a fully functioning tick system until demo 6. That is because the enemies don't move yet, and without the other guy moving the tick system is kind of pointless. Also as you say it would be good to have the arrows or whatever we come up with working first, and we're not there yet.

[LDiCesare]

quote: Originally posted by Mark_Everson on 05-14-2001 07:52 AM Unless we have other issues holding us up, I am inclined to wait for a fully functioning tick system until demo 6. That is because the enemies don't move yet, and without the other guy moving the tick system is kind of pointless. Also as you say it would be good to have the arrows or whatever we come up with working first, and we're not there yet.

I agree. I am holding any major modification to the code right now in order not to destabilize what may already not be that much stable. I am currently looking at boarding ships as my point of interest, since that doesn't clash with the current functionalities and it will be needed at some point.

[Gary Thomas]

Could somebody verify the dim memory I have that squares are supposed to be 65km across?

If so, there is plenty of room for opposing armies in the same square who not only don't fight, but don't know the opposition is there.

On this scale, Greece is 4 squares tall by three wide, consisting only of sea and mountains.

Cheers

[Mark_Everson]

Laurent, sounds like a good plan.

Gary:
Squares are nominally 100km on a side for now. And I agree there's lots of room for two armies to bumble around and not contact each other. But remember most of the land isn't vacant, and word travels, so over several ticks (each approx. three days long) they are fairly likely to find out about each other. But I think your general thrust was that chances of evasion of one army by another are fairly good, and I agree wholeheartedly there.

[LDiCesare]

Mounts

Writing this here not to clutter the movement thread, though it may be remotely related.
As FSmith said somewhere, we could have a notion of mount for units, so you can have chariots on horses, or donkeys, and cavalry on horses or elephants. I think that could be interesting to specify this because horses/donkeys/elephants are resources, so you can't build cavalry in America until horses have been imported by Europeans.
That could also affect movement, since we could use the same cavalry unit, but the "mount" would change speed and defence, maybe assault. I am not sure whether it is better to have a cavalry element with available mounts horse or elephant, or two elements: cavalry and elephants.
What I think is important is that there be a requirement for building cavalry, that horses be available. That may be a purely tech requirement so that you can't learn horseback riding without horses.

[Mark_Everson]

Personally I think horses are the only important mount. Certainly at least until Clash gets much further along. I do think we can require horses to build chariots, although playtesting will be needed to see if its appreciated by most players

[Gary Thomas]

I think we have to be a bit careful here. There should be a distinction between battlefield transport and strategic transport. They are not necessarily the same thing. The Vikings used to steal horses for their raiding, but always fought on foot.

Cavalry horses are one example where the two aspects are the same.

On the other hand, elephants were not used to transport anything but themselves - at the strategic level, the crews walked.

The impact of camels as military transport is so minor that I cannot imagine it having any impact on the game.

In more recent times, trucks are used to get troops to the battlefield, not move them round during combat.

Clearly sea or air transport differentiates the transporting unit from the transported unit. Is is quite rae (though not unknown) for airplanes to transport airplanes.

In this context F_Smith's suggestion that there be separate transport objects is a good one, though I wouldn't carry it to the extreme of an infantry unit having a transport object called "feet".

Cheers

[Gary Thomas]

The current military model has pretty much everything as some variant of "Army". The interactions between Army, Element, Unit, TaskForce and TempTaskForce is quite labyrinthine and difficult to manage.

My instinct (not for D5 though) is to separate the physical object from the command structure. As it stands, it is not possible to have a command structure covering more than a single square - a TaskForce is the only structure, but it is treated as a physical object. This has caused me to have a lot of trouble differentiating the various pieces of information. A lot of coding effort goes into making sure that each component is located in the right square, for example.

In my view, the physical location of a unit, like its personnel and hardware, is a physical variable.

The way I would design the model is to have physical elements (Element class), which define the fighting characteristics. The elements are grouped into physical units (Unit class) which, in turn, hold the location information.

Then, units can be grouped into commands, in a variety of ways. However, the location of the unit remains with the unit.

On the other hand, the civilization that the unit belongs to is part of the command structure. Units did swap civilizations. Their allegiance is a political matter, not a physical one.

A unit, on its own, will never do anything until it is made part of a command.

In particular (as far as OO coding is concerned) a unit is not a command, and a command is not a unit. However they can both have a contained object called (say) CombatData, which covers such matters as attack strength (and the myriad other factors involved).

Whether command levels have differentiated levels (brigade, division, army, army group, front) is another issue. I would be inclined to do it that way, simply in order to make it easier for the player to grasp what is going on.

The advantage I see in this system is that it clearly separates the physical and the social factors.

Cheers

[Mark_Everson]

The approach sounds good to me. Lets see what Laurent thinks.