Military Model VI

[Mark_Everson]

Go Militia Go!

Hi Laurent, good framing of the issues! I like your approach, and will mostly only respond briefly where you cited problems. I think we can likely get it in for D7.

Originally posted by LDiCesare
1) How many units should be spawned?
I'd say it amounts to a percentage of the population would rise. I think something around 5%. For a 10,000 pop square, 5% leads to 500, which is currently one element. This means a 100,000 pop builds the equivalent of a warriorband or horde, and 1 million builds ten of these.
Are these figures okay? Should the 5% be tweakable based on EG preferences/policies?

I think we should do it right from the start (Gary's influence upon me. Geez, what a bloody do-gooder )

IMO that means there should be a pool of "militia-eligible" ME population, and only those can turn into militia. The ME population in each EG would grow slowly toward a steady-state value of 5%-10% or so. As you say this should vary by EG culture, although we can skip this for now. When the militia unit is created the ME is set to 0, and of course the overall EG population is reduced. Any ME that survives is returned to the ME pool when the unit is disbanded.

Off the top of my head 10% seems better as a default since otherwise militias will only infrequently come into play.

There are a few loopholes there. Mainly:
4.1)Militia should be spawned only once, when an opponent comes in. Then, it will remain for as long as the opponent is in the square, (and the militia is alive). It mustn't respawn a new one on the following turn if the enemy stayed there.
4.2)There is a little abuse available, as you can attack a square, reduce its population thru fighting militia, withdraw, come back and start again. This is probably not an issue, but I thought it worth mentioning.

I think my proposal above takes care of these exploits.

4.3)The detail I mentioned at the start is not a small detail the more I think of it. If Carthage conquers Massilia on turn 4, and a big militia rose against them but was crushed, I don't expect a militia to rise against Roman liberators if they come on turn 5. Actually, a militia could rise again to help the Romans. This leads to point 5) below.

This one is complicated. For now we should use your EG-indexing for who is supported as you suggest. There are of course details to work out.

5) When does the militia spawn, and for who; does it fight?
Militia shouldn't spawn if it is badly outnumbered. Maybe they will fight if spawning gives them at least 1 vs.2 odds, not otherwise.

Sounds good to me for now.

Militia should fight for the civ their ethnic group prefers. Is that info available in the code? Note this can in theory lead to situations where militias form for both the defender and the invader. I like it in theory, it could even give good event messages in the military events, but will I be able to reduce each EG population accordingly?

There used to be a majorityEG or some such for each civ in the code. After a short look, I believe it has been commented out in the code after Gary's refactoring of the social model. Is this accurate Gary? In any case we could skip the EG-civ effect for militia formation for now IMO.

There's also an ethnic tolerance setting in the social stuff. If A conquers B's city but is good to the B EG... when the B army returns, the chance of militia generation should be reduced.

[Gary Thomas]

Is this accurate Gary?

Can't remember.

I once suggested that cities should be separate from the square they are in, having in fact many of the characteristics of an extra map square. Mark decried the idea, but without any reasons. I now have reasons for separating them.

The reason is a seige, in which the square is controlled by one civilization and the beseiged city by another. At present there is no provision for this to happen. And I believe that it is a very important part of history.

I also believe that the city should have a separate economy object, infrastructure, population ethnicity, and militia.

I really don't have the time for big battles, but if there are good reasons for not doing this I will be interested in hearing them.

Cheers

[Mark_Everson]

Hi Gary:

Originally posted by Gary Thomas
I once suggested that cities should be separate from the square they are in, having in fact many of the characteristics of an extra map square. Mark decried the idea, but without any reasons. I now have reasons for separating them.

How odd that I would decry separate cities, since I have at times thought it was a good idea myself. Methinks sir, you mistook "not now" or "there are issues..." for something more serious. And since you produce no evidence I must consider myself pure as the driven snow, wrapped in the flag, in this matter

My best recollection was that I said "wait for polygons" since that allows for a much more natural approach to separate cities. Cities would just be a small polygon.

My issues with separate cities are mostly practical. The biggest is that the Economy is already very data and computationally expensive. Unless cities are rare, they will compound the problems. I am counting on polygons that are much bigger on average than squares to get us down from about 10,000 economies per world to a more practical 1000 or so!

[LDiCesare]

Answering a post from another thread.
Gary said elements should define the characteristics, not the number of men/elephants... of an army type. This sounds good except I am concerned that if we have one element per man in the army, the game will be unplayable due to memory concerns. So we would have ElementArchetype = 1 man. UnitArchetype = XXX men of different types.
If I use an Element with an argument number in it which basically multiplies all values in ElementArchetype, then it looks feasible, as a Unit would be made of one Element per ElementArchetype, but having a specified number.
Now the question is: how does damage affect units? Currently, an element functions at 100% efficiency until its death. Thus having 10 elements or 1 10-times bigger makes a difference, although it is an artefact in the code. With this system, how do I scale the characteristics down with casualties? I feel like I will have to compute fronting of the element based on its health/number of men, and other figures on a same basis. It also looks like health and number of men are related, however the health of an elephant is much more than that of a man, so I may have to reduce the number of men by 1 when the health gets down by a given amount (I can do the same thing with floats, but we will have to be careful not showing the player a unit now has 503.43432 men in it because they will wonder what the .43432 means). Does that sound OK? I just hope noone wants more detail.

[Mark_Everson]

Originally posted by LDiCesare
If I use an Element with an argument number in it which basically multiplies all values in ElementArchetype, then it looks feasible, as a Unit would be made of one Element per ElementArchetype, but having a specified number.

Yeah, that's what I always thought Gary wanted. It will simplify things in the long run, although it will be a bit of a pain in the short run.

The rest of what you say sounds ok to me! I never did like the idea that an element fights at full power till it dies...

[Gary Thomas]

If I use an Element with an argument number in it which basically multiplies all values in ElementArchetype, then it looks feasible, as a Unit would be made of one Element per ElementArchetype, but having a specified number.

This is exactly how I envisaged it.

Now the question is: how does damage affect units? Currently, an element functions at 100% efficiency until its death. Thus having 10 elements or 1 10-times bigger makes a difference, although it is an artefact in the code. With this system, how do I scale the characteristics down with casualties? I feel like I will have to compute fronting of the element based on its health/number of men, and other figures on a same basis. It also looks like health and number of men are related, however the health of an elephant is much more than that of a man, so I may have to reduce the number of men by 1 when the health gets down by a given amount (I can do the same thing with floats, but we will have to be careful not showing the player a unit now has 503.43432 men in it because they will wonder what the .43432 means). Does that sound OK? I just hope noone wants more detail.

I imagined that health would be an index in the range 0 to 1, and the effective manpower is just the manpower times the health, and that the manpower dependent values would be multiplied by this factor for such things as effective attack strength or frontage.

Cheers

[LDiCesare]

I imagined that health would be an index in the range 0 to 1, and the effective manpower is just the manpower times the health, and that the manpower dependent values would be multiplied by this factor for such things as effective attack strength or frontage.

It is trickier. For men, it works fine, but I don't think it applies correctly to elephants. Elephants are probably 10 times harder to kill than a man, and they will go on fighting, and probably even more fiercely, if they are wounded. Decreasing their stats before they die is IMO inaccurate, though I will probably end up doing it for the sake of simplicity.
The health value may also be more than one for various reasons (steroids, elephants, donkeys vs. warhorses, berserkers?...). It is precised in the element definition.
Thus I'd deduce effective manpower from current health divided by base element health, but I feel I am not doing a favour to elephants.

[Gary Thomas]

I don't think that the model should over-emphasize elephants. Outside of the ongoing ancient Burma/Siam conflict, I don't think that elephants ever had any significant impact on warfare. I know of no battle that was settled by elephant power. Mostly, at the first wound, or loud noise, they turned around and charged back through their own ranks. The Indian army at the Hydaspes had elephants and apparently expected all enemy cavalry to run away at the sight of them. They lost the battle anyway.

Cheers

[Gary Thomas]

I would really like each element to have a description, indicating what the element is supposed to do. Then the details dialog could be improved to give a breakdown of the constituents of a unit, with a description for each type of element.

Cheers

[Gary Thomas]

I have been investigating the movement of ships. It appears to me that a ship moving to a land square will have to remember the square it came from, and can only move back to that square. Otherwise a ship will be able to cross an isthmus.

Cheers

[Mark_Everson]

Spot on with the ships, IIRC we discussed that earlier too. (Even D4 had it way back when...) The only quibble I'd make is that you shouldn't have to put to sea to exactly the square you came from. I think any square adjacent to the one from which you entered should work. Definitely insta-canals are to be avoided

[Gary Thomas]

I think any square adjacent to the one from which you entered should work.

Too hard to code. I will prevent diagonal movement onto a land square. You can just move to an orthoganally adjacent land square. This is reasonable, and implies that the port is in the middle of the square. I certainly do not want ships moving, diagonally, onto a land square whose only connection with the sea is at a single corner.

Laurent, I think that we ought to implement the suggestion made earlier of recording, for all units, the last square they were in. This could then be the retreat square - I do not think any unit should ever retreat more than one square in a single move, after all, a retreat of 100km is some retreat! Subsequent retreats should be, as much as possible, in the same direction (rather than back to the square they just retreated from!).

Cheers

[LDiCesare]

Unit.getMovementData.getLastSquare(). Already in.
I should also try to use it for retreat if the lack of picket is really problematic.

[Mark_Everson]

Moved over from the D7&8 Planning thread since it belongs here...

Mark Said:

Delenda is somewhat more challenging with the new econ orders. At least as the Romans if you don't mount a reasonable defense you can get overpowered.

I played one game as the Romans for about 20 min, and it was some fun! The biggest problem I had was the enemy being able to pass through my substantial pickets without much damage. I guess what happened is a brief battle got fought, and then the enemy moved on to the square beyond that was in their movement orders. I was wondering if we need a rule to the extent that unless you win the battle, you can't continue your movement. A unit that did not win (and these were so outnumbered I'm sure they couldn't have won) would be prevented from continuing its movement, and either have to stay and fight, or retreat back along its path of advance.

I realize this is more a military matter, but I was concerned about it in the specific context of D7, so I put it here. If the passing through of opponents bothers only me, I'll just deal with it. But if it makes the game for others less pleasurable also, it would be worth addressing.

Gary Said:

I realize this is more a military matter, but I was concerned about it in the specific context of D7, so I put it here. If the passing through of opponents bothers only me, I'll just deal with it. But if it makes the game for others less pleasurable also, it would be worth addressing.

It bothers me. Any combat should cancel all orders.

Do you want me to do this?

Cheers

Mark Said:

Yeah, that sounds good Gary, but we should wait first to hear what Laurent thinks.

So if the orders are canceled when the battle begins, I assume when the battle is over and the smoke clears that new orders for whatever seems appropriate will be issued? The problem is for the players' armies it could be irritating to have the orders canceled. That always used to bug me in civ2. Or do you mean that the orders are just ignored until the battle is over? The last one seems the simplest to me for now. We can certainly better refine things in the future beyond D7.

Gary Said:

I think that computer controlled orders should be completely cancelled, and replaced on the following game turn. Player controlled ones could remain. However, their execution will wait until the next turn. At some stage we might allow an overrun - if the enemy force is tiny, it will not slow down the troops.

On another topic, I believe quite strongly that each province should have a capital, and all troops should be raised there. The thought of ordering troops and having them show up in a random square leads to a strategic and logistic nightmare. The capital does not have to be a city, it can be any square, and providing the means to shift the capital requires very little coding.

Cheers

Laurent Said:

I don't like orders cancelled for the player. I also don't like the idea that we check if that is the player so we must cancel or not, because the player could pass thru a picket and the AI not. I should look at the result of the fight, and, if lost, cancel orders and give a retreat order instead, if drawn, cancel all orders or (better) delay them.
(edit)
I will cancel orders until I get a method that allows delaying them. The retreat decision can be based on the result of the fight (did the army flee or was wiped), but I think after the fight I will check the odds to attack/defend and decide whether to flee or not based on that. It will be more accurate. The question remains for units which have been created in a square, are then attacked and want to flee: Where do they go? For now, they will stand their ground.

Mark Said:

Originally posted by Gary Thomas
I think that computer controlled orders should be completely cancelled, and replaced on the following game turn.

Seems we're all agreed on this one!

Player controlled ones could remain. However, their execution will wait until the next turn. At some stage we might allow an overrun - if the enemy force is tiny, it will not slow down the troops.

OK by me. Laurent, Because player order execution is held up, there is IMO no big asymmetry between player and AI. Player's troops can't shoot through, because if there is still a fight in the square, the move orders get delayed. Is this ok with you Laurent?

On another topic, I believe quite strongly that each province should have a capital, and all troops should be raised there. The thought of ordering troops and having them show up in a random square leads to a strategic and logistic nightmare. The capital does not have to be a city, it can be any square, and providing the means to shift the capital requires very little coding.

The reason I did the by-square was anticipating low-centralization cultures where every square is largely on their own. For now, and in the long run for centralized states, I agree with your changes. If you go ahead and implement, I'll rejigger the econ code to do the right thing.

Laurent said:

I will cancel orders until I get a method that allows delaying them.

I guess canceling is ok as a temp thing, but I think players will dislike it. So I hope a fix that can preserve player orders will be available soon!

The question remains for units which have been created in a square, are then attacked and want to flee: Where do they go? For now, they will stand their ground.

For now I think these units should plot a course to the nearest friendly city, and retrieat into the first square of that path.

Since we're getting down to a lot of details, we should IMO move this discussion to the military thread. Since it was my fault we kicked it off here, I'll do the busy-work of copying it over.

[Mark_Everson]

I think we've already discussed this, but I wanted to make sure it was mentioned here.

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!