Military Model VI

[Mark_Everson]

It's time for a new Military Model thread. The discussion here continues from the Military Model V thread. There are links to a synopsis of the model at the beginning of that thread.

There is also a wealth of detailed info on how the model works in terms of parameters and what they represent in the Military coding status thread. If you want the real details, give it a look!

[Mark_Everson]

I was in the throes of reworking how the aggregation over an entire province of build points for a military unit works, when I ran into an issue.

Right now we require 5000 population in the relevant square to go into building a military unit. (Although build points are harvested across the province, the build still happens in a singel square.) I think we're going to have trouble with this in the Dawn scenario. Even if your starting square has enough population to build the unit, it could be severly depopulated. I think we are ok for now if there is Just the starting square, since the build would go so slowly the population would likely get to 12k before it was finished.

The thing I'm more worried about is that if there was a province with a lot of low-population squares. FE this might happen in Dawn from population diffusion and player-ordered settlement. Together the squares in a province could build units fairly fast using the aggregated military build available at the province level. But each of the squares could still have relatively low population. So when the build actually takes place it would be a catastrophe for the square that actually did the build.

My proposed solution to this is to have the population to build the unit come from across the province. It would allow military units to be built gracefully even in areas with low population density. In the future we could even require certain ethnicity requirements if the player desires, and again this will be easier if done over the entire province.

Does this sound ok to everyone? If so we need a function in AreaAdministration or ProvEconomy to handle population withdrawl.

[LDiCesare]

This sounds correct. You should hae to be able to choose the square in which the unit appears then.

[LDiCesare]

[snipped from other thread where I posted by mistake]
I don't remember anything about unit upgrading / unit updating in the military model or threads I read. A quick search was also inconclusive.
As Mark pointed out, upgrading units should be done in cities or near cities. I would tend to say that upgrading cities can be done if the square in which the unit is can produce some infrastructure. This means it is not currently occupied by enemy troops or there is no fighting going on inside, and it is controlled by the unit holder's civ.
I think square-control is in itself still problematic so I won't discuss it in more details now.
Upgrading should be done by alotting some resources to it. I'd tend to consider it the same thing as healing units. Note currently units are never healed.
I discuss healing first:
Healing an undestroyed element costs half the cost to build it * %age of damage taken.
Healing a destroyed element (creating a new one) costs the normal cost to build it.
Updating a unit means replacing it by a new unit. It means I either scratch all elements and replace them all or look at what elements remain the same and scratch and replace the rest. I'd tend to favor the second option, which will lead to less costs. The cost to replace elementA by elementB would be elementB cost minus half elementA cost.
Note that it would be easier for me to upgrade units only if they are already healed, but this would actually raise the upgrade cost in some cases.
Examples:
Suppose Unit1 is made of 3 Element1 (cost 10) and 7 Element2 (cost 20).
Suppose Unit2 (the upgrade) is made of 4 Element1 and 6 Element3 (cost 20).
Building Unit1 costs 170, Unit2 160.
A damaged Unit1 with all elements at half health costs 42.5 to heal. Call it damaged1.
A damaged Unit1 having lost 1 element1 and 2 element2 costs 50 to heal. Call it damaged2.
A healthy Unit1 costs 60 to upgrade.
damaged1 would cost 102.5 if healed and upgraded, or 95 to upgrade, + 7.5 to heal the 3 damaged elements that remain: total of 102.5 if upgraded then healed. Gee! The same cost.
damaged2 would cost 110 to heal then upgrade, or 90 simply to upgrade. This is much less expensive.
So we could use the following method:
1) Funds go to heal partially damaged elements. That cost is neutral vis a vis upgrade, but it is probably less exensive and doesn't have to be done "in full".
2) Upgrades take place. While a unit is being upgraded, it shouldn't move or fight because it will be a mess in the code if it loses an element and has part of its cost already done. The cost would change and the unit would be half-upgraded... So a unit being upgraded shouldn't do anything but upgrade. If it is interrupted, it should be considered as not having upgraded. All $ invested in it can either be saved or lost. I'd rather lose them, because I think it is easier to code (bad reason).

The question that remains is: Do we want to upgrade healed armies? Do we need a separate econ entry to do it? I'd rather reuse the military support econ entry that already exists. The problem is it tends to adapt itself automatically, and you don't want that to happen if you have a huge army to upgrade and something else to do with your econ.

Thus I would like to have an econ entry for healing/upgrading units, separate from the upkeep entry. It might be good to merge it with the military tech entry, as it makes sense that credits used developping new weapons be switched to put them in production, but I am not sure that is a good idea either because healing would have to be a different category anyway.

[Dale]

Copied from Planning for demo 7 & 8 .............

Originally posted by Dale
I do have one major concern about unit size. 5000 men? OUCH! That's HUGE! Even by Roman standards that's 5 Phalanxs!!!! Remember how the Romans came up with unit hierarchy:

- 10 slaves = company (they would pick up weapons when attacked) (10 men)
- 10 companys = legion (100 men)
- 10 legions = phalanx (1,000 men)
- 10 phalanxs = army (10,000 men)

Even at the height of Roman power, when they controlled Europe, Rome only had 11 armys (110,000 men).

Probably for a more "accurate" depiction, is the American Indians when the Spanish got there. Both the Incas and the Aztecs could only field a couple of thousand men in battle, and that's throughout their whole empires.

During the Boer war, the Zulus had like 40,000 warriors (I'm pretty sure it was that, not certain though) and they called up old and women!

In musketeer times:
- England used to have a MAX callup army of about 210,000, and France wasn't much better.

In modern terms:
- Most military units have 1000 men (300 * 3 companies + 100 support staff)

In the context of Dawn, 5000 denizens (start size) should be defended. Therefore you must need a unit, and one to explore.

5000 = 2500 men + 2500 women
2500 men = 833.3 kids + 833.3 young + 833.3 old (just averaging here)

That means you have a military MAX pool of 833.3 young men. In the context of Clash, my suggestion is something like this:

- Start off at 500 men units.
- At the time of Sun Tzu's (maybe Military Formations technology?) increase this to 1000 men units.

BTW, I also feel warrior hordes shouldn't take much time to build at all (geeze, all they did was give them a spear or club with no training).

Anyways, that's my two cents. Sorry if I've got this all confused in the context of Clash.

And:

Originally posted by Mark_Everson
Hey Dale, your points are quite reasonable. I think for much of history, a decent approximation is that there will be a standing army of something approaching 1% of the population. (At least when they Had standing armies.) In times of emergency it can get several times larger IIRC. What I wanted to avoid when we formulated the 5k/unit thing was swarms of units, especially moving around individually. FE the 4th C Roman Empire had a standing army of something like 350k [Penguin Atlas of Modern History, p5]. Even at 5k/unit that's a LOT of units.

The units really are meant to be quite big since this is really supposed to be a grand strategic game. We don't want to get down to the fracas level . But Dawn clearly makes 5k units impractical.

Maybe we should go with 1k units for the earliest parts of history. Anyway, we should move this discussion to the mil thread. If you put your post there, I'll move mine .

Mark:

Sorry, must have had a mixup in Roman army numbers in my mind. It was actually one of the Generals who had access to 11 phalanxs, not the whole Empire.

But I do still agree that 5K for Dawn is HUGE, unless the population values are changed, or a scaled unit size is brought in.

IE:
- Beginning: 1K men
- Classic Age: 5K men
- Medieval Age: 10K men
- Renais Age: 20K men
- Modern Age: 50K men

[LDiCesare]

I will change the man-cost of units to 500/element. I still believe we could make this numkber (500) a parameter in some xml file. This can wait.
I will make the warriorband unit smaller if that is suitable. I'll probably also put an early chariot unit with 3 or 4 chariots instead of 10. I'll make them available at 0 Military Tactics level (+ horses for the chariots) and make them obsolete by the hordes and chariots available at Military Tactics of 10. The problem remains we should have a military tactics level of 10 for Rome and Carthage to start with and 0 for Dawn.
I'd also like some comments on scenario/civ-specific units. Where would it be better to put them? The standard military xml file is a bad choice as it will get cluttered. The scenario file or another file specified in the scenario file? We can live without for D7.

[Mark_Everson]

Hi Dale, thanks for moving the stuff over here. I admit I said I don't want lots of units, but I aslo don't want lots of different unit sizes through the game . Anyway, we can worry about things like the renaissance when the game gets there! So at least for now I think that two generic unit sizes will do the trick. And 1k or 5k seems reasonable. But we can change these as needed. Gary had even wanted to have variable-sized elements, which I expect we may go to in the future.

Thanks for making the changes Laurent. I think two elements might be best for the early units... What do you think of Dale's suggestion for Horde to be really cheap but really ineffective? Or should it be WarriorBand?

One other idea could be to have self-defense forces that automatically spring up when a square comes under attack. They wouldn't be very effective, but would at least mean that a weak unit couldn't automatically take over a square. Maybe not for D7 but this could work for D8.

If we can't support tech levels the right way (via the xml) we can kludge them in very easily. If you want to start testing you could even do it now. Basically if scenario name = "Carthago delenda... " then setTechLevels blah blah blah. Of course, Gary really hates the little temporary hardcoded things, so hopefully there will be a way to set tech levels for civs soon! I don't know about the best place for civ-specific units. I'd expect the scenario file for ones available to all civs in the scenario, and the civilizations.xml (currently not used) for civ-specific ones.

[Dale]

Mark:

About militia springing up automatically, this is a damn fine idea. I liked in a lot of WW2 board --> PC games, when invading another nation the square (even if it had no units) automatically got a defense of 1.

Even now, if Australia got invaded I'd have to take up arms and cause a problem.

[Gary Thomas]

I guess I should check all the threads before posting. Here is what I posted in the D7 and D8 thread (not quoted because it has inner quotations):

--------------------------------------------------------------------------------
I am back from a pretty bad bout of illness.

Since I have got so far behind on commenting on things, these remarks will be a bit scattered.

First, Dale, I was really impressed by your effort in preparing the Dawn prompts. To reproduce the various levels of text size and emphasis the text will need to be in html format (properly presented these will appear correctly in a Java frame). I can do the conversion if you like. The display panel code is written and I expect to finish debugging it today (here it is 10 am Friday).

On the subject of unit sizes (and posting in the wrong thread, seeing I am responsible for the military model), I have always felt that units (elements, actually) should be of variable size, with the size specified as the number of soldiers in the element. The present system appears to be designed with a tactical level battle system in mind. This in itself contravenes Mark's idea of grand strategic battels. I find the fixed size elemnt concept wrong in historical fact and in terms of the game objectives. It also leads to a lot of code complication, without, I feel, adding anything to game play. My preference would be for elements within a unit to be all different (cavalry, heavy infantry, skirmishers, missile troops, and so forth), rather than having an archer unit with 8 archer elements and 2 skirmisher elements, for example.

I would have no problems with a unit consisting of a single element containing 100 scouts, for example. In this way, the size of the forces could be adjusted to the context.

Hans Delbrucke is an author I have a lot of time for (though others disagree). In his monumental history of warfare series he has a lot of comments on army sizes, most of them I find convincing. In particular he gives the following figures:

Greek and Macedonian:

1. Athens total hoplites: 5000
2. Sparta total hoplites: 5000
3. Corinth total hoplites: 1500
4. Thebes total hoplites: 2000
5. Both Greeks and Persians at Marathon: 4000 - 6000
6. Plataea: 5000 Spartan hoplites, 5000 Athenian hoplites, 10000 other hoplites and 20000 unarnoured men, 40000 total, with the Persians having a similar total.
7. Granicus and Isis, Alexander about 30000 men, with the Persians probably somewhat less.
8. Gaugamela, Alexander with around 47000 men.
9. Battle on the Hydaspes, Porus had only 85 elephants.

(these from pages 63, 72, 112, 185, 210, 220 of "Warfare in Antiquity")

Roman:

1. Cannae, Romans 55000 hoplites, 8000-9000 light infantry and 6000 cavalry.
2. Cannae, Carthaginians 32000 heavy infantry, 8000 light infantry, 10000 cavalry.
3. Carrhae, Romans 36000 total.
4. Bibracte, Caesar 36000 - 40000 total.
5. Subjugation of the Belgae, Caesar 50000 combatants.
6. Alesia, Caesar 70000, Vercingetorix probably 20000, with the relieving force about the same size.
7. Civil war: Caesar 11 legions, Pompey 10 legions.

In "The Barabarian Invasions" we get:

1. Augustus's 25 legions, with support troops: 225,000 men (equals 1/3 of 1% of the population, in the tensest period of the 2nd Punic War the figure was 7.5%).
2. None of the various barabarian forces exceeded 15000 (and this was quite large). Many of the battles had less than 1000 barbarians involved.
3. By the 4th Century the Roman army had degenerated to an immobile militia, all the actual fighting was done by Germanic or Asiatic mercenaries.

With the advent of the dark ages, the ability to sustain and supply large armies disappeared, with the result that an army of 10000 was a very large one.

quote:

FE the 4th C Roman Empire had a standing army of something like 350k [Penguin Atlas of Modern History, p5]. Even at 5k/unit that's a LOT of units.

Almost all of these were actually just farmers, who had a sword hung over the fireplace. There were maybe 50000 available, effective, mercenaries, but spread over the whole empire. And unreliable too.

quote:

I do have one major concern about unit size. 5000 men? OUCH! That's HUGE! Even by Roman standards that's 5 Phalanxs!!!! Remember how the Romans came up with unit hierarchy:

- 10 slaves = company (they would pick up weapons when attacked) (10 men)
- 10 companys = legion (100 men)
- 10 legions = phalanx (1,000 men)
- 10 phalanxs = army (10,000 men)

Dale, this seems pretty fictional to me. Do you have any sort of reference. I can't accept a legion of 100 men. Nor did the Romans refer to a "Phalanx".

quote:

5000 = 2500 men + 2500 women
2500 men = 833.3 kids + 833.3 young + 833.3 old (just averaging here)

For Germanic tribes, Delbrucke gives around 1/4 of the tribe as warriors (barbarian warriors did not retire!) which gives 1250. Still a bit small for our unit.
--------------------------------------------------------------------------------

Mark, I wasn't clear from your posts whether the cost of a new unit is prorated around the province. Personally I feel that that is the way it ought to work.

Cheers

[Mark_Everson]

Hi Gary, glad to see you're feeling a bit better!

Originally posted by Gary Thomas
On the subject of unit sizes (and posting in the wrong thread, seeing I am responsible for the military model), I have always felt that units (elements, actually) should be of variable size, with the size specified as the number of soldiers in the element.

We left this as a TBD last time it came up. My opinion is still the same, something we can try eventually, but doesn't seem urgent now. Probably 1/3 of our market would actively like the ability to tactically play out selected (by them) battles. So I would like to maintain it as an option even though its something I personally would never play. Although frankly its not clear to me if the 10-spearman-element thing really would support a tactical combat model much better than Gary's single-large-element suggestion. Mostly in tactical battles I'd think you'd move units, or just the number of things to move would become overwhelming.

In short, I've got no problem with the single-element-per-type thing. But Laurent has a bit of effort invested in the current way, so we should hear what he thinks!

Mark, I wasn't clear from your posts whether the cost of a new unit is prorated around the province. Personally I feel that that is the way it ought to work.

That's the way it works.

And now, a blast from the past that I'd forgotten about that I'd like to have available in D7. Laurent said, in the Mil V thread:

I put the oddsToAttack/oddsToDefend stuff back in use, so it allows modelling the flights. These values are described in the "tactical" order given the unit.
For now, orders are not given to units, so their default order is their preferred order, which is ranged fight if available, else sentry. Sentry means you don't attack, so that is poor. I can either change all values so that for the moment, fights happen at strength ratios between 0.5 and 2, or we can plug in orders for units now. The first one requires much less code, of course. It can be interesting, though, as it would allow fortify orders, and giving various levels of attack ratios (as in D4). What do you think?

I really liked the way the oddstoattack etc. worked in D4 and would like that back. Basically it means you can prevent your armies from making boneheaded attacks or participating in suicidal defenses. The only thing we're lacking is a GUI method for the player to enter preferences.

Thoughts? A quickie simple military orders GUI?

Cya,

Mark

[Gary Thomas]

I am not sure what "odds to attack from D4" means. What is it?

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
I am not sure what "odds to attack from D4" means. What is it?

Hi Gary:

The reason behind having the 'odds system' is because it allows a more realistic lower-micromanagement combat system. For instance, in real life, an attack where the military power ratio is something like 0.3:1 is a ver foolish attack. simply because the attackers would have no hope of surviving. (Ignoring for the moment the case of feints where you are willing to sacrifice one command to make an overall strategy succeed).

To simulate discretion of a commanding officer, battles would only take place if the military power odds of the attacker to defender meets the civilization's standard minimum attack odds. IIRC the minimum attack odds in D4 started at something like 1.8:1 (this could be changed by player, and the default values would ideally be allowed to be overridden for any given command). This helps to prevent your forces being frittered away in stupid attacks. If this attack test isn't met, ideally the army would not attack at all, and figure out if reinforcements are on the way, and either hold waiting for them, or withdraw, depending on orders. But in any case the attack wouldn't be made and the forces preserved to fight another day at better odds. Eventually this decision would be made on estimated enemy troop strength, rather than simply knowing that strength as it'd be now.

Similarly on the defender side you generally don't want to engage in suicidal defenses where you lose most or all of your troops, and the enemy loses little. So, if the odds turn out to be particularly bad for the defenders, they will try and flee (again changeable or overridable per command by player). When we have rules for the defenders setting up in fortifications, like castles, then the defenders that don't have enough forces to have a chance in pitched battle would probably take to the fortifications and suffer a siege.

The "attempt to withdraw" decision could be made at the beginning of every tick or with lesser frequency, allowing the attacker to call off the attack, or the defender to flee, as the odds change during the course of the battle.

[LDiCesare]

About the number of elements. I can't see how it makes the code more complicated. Having a variable-sized element means I must check the element's size for boarding and fights. In fights, Krenske's model included a frontage variable and a dispersion variable. Frontage would be dispersion * number of men. So basically, the current model accomodates it pretty well. Except I didn't code frontage stuff yet. Also, boarding ships is based on elements rather than number of men. The code will be more complicated there, as you may have to split an element between ships and thus deal fractions of damage in a more complicated way than right now for sunk ships.
All in all, I have no problem with it, it just means I have to code more stuff. I'd rather wait D8 before tackling it however. I'll just prepare for it by putting in the xml file a figure saying how many men I must take from the population when building the element. The frontage stuff will wait, particularly because an elephant is something that has big frontage but little manpower.

About the odds to attack/defend, it just means that when you are in the same square as someone else, you avoid attacking if your odds seem low. I implemented it so that you will defend whatever the odds for the moment. The odds must be hard coded around 2 vs 1, I don't remember. See my post dated 2-3-2002 in mil thread 5.

[Mark_Everson]

Thanks Laurent, I agree with what you said. I remember you didn't want the retreat of an outmanned defender simply because it gets tedious to chase them around. The way I handled this in D4 was that if the commander wanted to retreat preemptively there was only a 50% chance you could accomplish it. (Eventually strategic movement rate of the attacker and defender should be included.) That at least would reduce the tedium. Ideally retreating units would get move orders to go to some existing friendly troop cocentration. Probably none of this is for D7, but just getting my ideas out...

You said in an email:

I changed a few things in military to have obsolescence of Legions by Cohorts, different images and Carthage-only elephants.

Light Horse, or any horseman unit should also make obsolete chariots. Sound reasonable?

Hope the computer stuff treats you kindly .

Mark

[LDiCesare]

It seems that the urgent thing to do in military code would be to have militia, i.e. when attacking a populated square, a unit would be created automatically out of the square population to defend itself from the attacker.
Barring "details" like the fact that sometime people welcome invaders (which would require some ethnic group vs. invader relation checking), how do we do it?
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?
2) The nature of the elements spawned.
I will spawn elements, which should be specified as being "militia-able" in the xml file. This allows technology changes to affect the kind of elements spawned, and avoids my hard coding a specific element into the code. If several militias are available, I will build the most "efficient" one.
3) What consequences does it have on the economy?
To make things simple, we can say as a first step that if no casualty is taken, the militia uprising causes no damage to the economy. If there are casualties, however, the population should be reduced. I can handle it all on the military side as I know all the figures and the square in which this occurs.
4) What effects on gameplay?
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.
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.
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.
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?

[Mark_Everson]

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!