 |
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
I looked for some thread or model on poplation and found little or nothing. The most complete piece fo information I have is in axi's poll about how much detail we want to go in for population/ethnic group modelling. That is, nothing in terms of models.
I want to code population uprising when enemy troops try to invade. I don't want to have all the population to fight, and cannot use only a percentage of the population to fight, as from one turn to the next, the number of fighting men would artificially grow.
So I want to code population along these lines:
In an ethnic group, keep track of fighting/nonfighting. This I translate into men/women and adult/children. One could also add elders, but I will not because they didn't always stop fighting when they got old, and we are still in ancient age modelling.
What I really want is to say I have f.e. 10000 inhabitants in a square. How many can fight? The military/social/riot models will decide how many do fight when there is an uprising, an army is drafted, etc.
What are the effects on population on the turn following a loss of male population?
How is growth affected?
How many children become mature?
How many mature die?
Does the presence of military units (males) in the square affect the population growth (there will be bastards, marriages with local women...)
State of the code (as far as I understand - Mark and Gary can correct me here-)
1)Population in square is divided by ethnicities. Ethnic groups have a population figure. How both are related is totally opaque to me.
2)Growth depends solely on food. The growth formula is unclear to me. If the method names are to be trusted, excess food simply turns into people.
3)Military units take population from a square. They just take what they need, with no distinction of sex or ethnicity.
4)When disbanded, half of military personnel is added to the square.
Suggestions and needs
1)Population in square to be divided by ethnicities, each ethnicity by sex and age category, age category being either child/adult or child/adult/old. The rationale for having sex population per ethnicity is that when BigBadWolves invade SheepLand, the Sheep male population will raise to fight them. Those who die will probably be replaced by BigBadWolves. When Sheep come to liberate their country, only BigBadWolves will try to fight them. Surviving Sheep will raise to help the liberators. Also, historically, the Saxon killing of Celts in Britain and the Breton slaying of male Armoricans require a male population ethnicity to be followed. This raises the question of: what decides the ethnicity of a child. Father? Mother? Mostly because of conquests, it was father, but there are populations where it is the mother who matters (semites, some polynesians, amerindians).
Codewise, how do Population in squares and EthnicGroup population data member relate? Is some code obsolete or is there a third party class somewhere?
2) Population growth model?
We need mainly food and women to have population growth. Men are needed too, but not as many as women. What is the effect of a lack of men on population growth? What effects marriage policies have on this? (Does strongly enforced monogamy lower fertility?)
Also, how many young become mature, how many mature die (or turn old, and olds die) in one turn?
3) Military would take from mature male population, no ethnicity distinction yet. Long term, ethnicity could be taken into account.
4) All population would be put back to the square, ethnicity to be determined.
Not adressed points.
There are many. I want to point some of these here but NOT discuss them because they won't be coded soon. I just log them, please speak about them only if you think they have to be coded right now for some reason.
There is the effect on social classes. Should they matter as far as army drafting goes (fighting aristocracy, serfs...)
Child death. All children don't make it to adulthood. How many die? The disease factor comes here too.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
I just wrote an extensive post that was lost before I could post it.
I try again:
Proposal:
Don't separate population by sex.
Separate population by EG.
Separate population by young/mature.
Growth:
Currently, pop(t+1) = food(t). I find this a bit crude, but OK as an upper limit on population.
There is an unused equation in the code which uses Food per Head and a 4% growth factor.
I want to do a growth computation every 5 years.
I separate young/mature as 0-14/15-60 years.
This means over 5 years, 1/3 young become mature and 1/9 mature die.
Reproduction rate should allow for MAX increase of population over 5 years. For instance, in order to double population in 50 years, MAX = 0.07. I propose that figure. The unused code uses 0.04. Proposals?
Considering a flat ages pyramid, 3/4 of population breeds so:
Pop(T+5) = Pop * (1+MAX) = Pop * (11/12 (deaths) + births)
births = (1/12 + MAX) = 0.16.
This gives:
Young(T+5) = Young(T)*2/3 + Mature(T)*0.16
Mature(T+5) = Mature(T)*8/9.
Making 2/3, 0.16 and 8/9 parameters that can be tweaked.
Then we must consider food: The above computed population is maximum population. Compute food per head (FPH) for it and if FPH<1, multiply figures by FPH.
This is a quite simple model. At least simple to code, and with only 3 variables to tweak (MAX growth in 5 years, age for adulthood and for average death of "old age").
I would make all variables global to start with. We can fiddle with adulthood/death age later based on whatever EG/medicine tech we want.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
Now if we have an adult population, all calls to population from the economy and military (and other models except disease or such) should draw upon it instead of total population. This can disturb existing scenarios a bit as it would lower production by 1/4th. If my proposal is accepted, I will check Dawn and Delenda to make sure they still work mostly the same. That probably means I will have to do things in the economics, or I can provide a getWorkForce() method to be used instead of population which just puts the additional 1/4th in so the scenarios see nothing.
Raising military units will thus have more impact on the economy as it will remove from the active population (1/4th more impact than before).
Then I will be able to decide a proportion of the attacked population in a square will decide whether it is worth revolting when an invader comes by. I would do it only when an army enters the square. What should the proportion of population of a given EG ready to take the arms in order to defend itself be ? Maybe 1/3rd? They would take arms only if by doing so they provide their side odds of 2 vs 1 or more, and would be shabby warriors (revolting roman peasants would be warriors and not legions). Is that 1/3rd figure OK or does anyone has a better proposal? This figure being totally arbitrary.
I will start coding as soon as I can (which can start anytime between monday evening and friday evening), so please give feedback.
In particular I need feedback on how the code EthnicGroup population figure relates to the PopulationData figures. I didn't see any obvious link.
|
|
|  |
 |
|
Simon Loverix
|
|
Tongeren, Belgium
Apr 2001 time: 05:22
|
|
The demography of the ancient world is very similar to that of the present-day third world: a high rate of child deaths and few people reaching old age. I suggest linking demographic types mainly to infrastructure, to discern developed and undeveloped societies. Technology doesn't matter so much as having access to it.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
I don't bother about infrastructure and tech in this implementation. Developped societies are far in the coding so I ignore them for now.
Note that the weeding of all ages equally affects the rough age pyramid unrealistically. The model I propose is not very realistic, and cannot be unless we decide who starves to death, and such. I don't want to go into more realism however, as I don't think we need it, and we certainly don't need it now. I am only concerned by not having a mature population popping every turn out of aehter available for warfare.
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:22
|
|
Hi Laurent:
I have pondered this a bit and think that doing any serious demographics coding before demo 7.1 is released is just asking for trouble. A model with young who aren't economically productive will upset the existing balance in the economics model in non-trivial ways. I really don't want to deal with that now, since I've already got too much on my plate. And I don't think anyone else can practically track down all the angles to it in economy right now.
But I have a proposal that I think will work okay with the existing population model. My suggestion draws on some of the good suggestions you have made, and I don't think will give the game any serious instabilities. This would allow us to put off more-detailed demographics till at least D9, which I think is more like it given that there are a lot of things more important than detailed demographics to get in first.
Local defensive army formation proposed model and issues
1. Any auto-generated defensive armies will need a special status so that they will be merged back into the local population when the issue is decided in their square.
2. I think they should be handled as a separate class of unit, called militia or something, that is even worse than warriors in terms of combat effectiveness. If these units are special, it will help in facilitating item 1. Something like 1/5 of the population should be eligible to form these units.
3. I like the idea that the local self-defense forces will only appear if they can do some good. However I think requiring them to attain 2:1 odds to appear is too restrictive a criterion. I would also like to see chance play a role in this, since the locals before mustering would never know exactly the troop strength they potentially would face anyway. My first take on this is to determine the potential local troop strength by adding the strength of militia that could be mobilized to any friendly troops in the square. Then the potential local: attacker strength ratio is evaluated.
* If the strength ratio is below 0.75: 1 no militia will ever be created
* if the strength ratio is above 1.75: 1 the militia will always be created
* for intermediate cases the chance of militia creation grows linearly from 0% to 100%
4. We must ensure that the people don't fight someone they would Prefer to control the square. I'm not sure exactly how to do this at the moment. If all the current scenarios had mono-ethnic civs it would be simple to find out if the local people are disposed to like or not like an invader. However, in delenda I know at least the Romans have several different EGs in their starting civ. If this is the only problem with this proposal I suspect we can come up with something that will work at least temporarily. There might already be something in the social model that will help in this, have to check with Gary, since he's the only one that's aware of what works now and what doesn't in that model.
5. An approach like this could seriously change the balance in a scenario like delenda that has large cities. I don't think that's entirely a bad thing, but we need a keep in mind that some weak tuning of the balance of forces might be necessary if this change is made.
I do think that something like this is worthwhile to do for D7.1! However, if you accept my notion of putting aside the demographic modeling for a later time, we should probably move this discussion to the military thread.
[edit: include notion of proper timing for more-detailed demographics]
Last edited by Mark_Everson on 02-09-2002 at 21:39
|
|
|  |
 |
|
Gary Thomas
|
 |
New Zealand
Mar 2001 time: 17:22
|
|
For the sake of getting rid of D7.1 I really think we should leave militia out completely.
Then, for D8, use Hans Delbruck's figure of 1/8 of the population.
Incidentally, the current code holds a total population for a square, and a distribution by ethnicity. I am not really convinced that extending this model to include sex and age ratios is going to add anything to the game except unnecesary complexity. My suggestion would be to add another parameter (akin to recruitment and dispersion) called martiality or some such, being the proportion of the population who would join the militia. If extra realism seems desirable, make martiality a characteristic of ethnicity. So then those ethnic groups who favoured the civilization would provide the appropriate proportion to the militia, or if they were conquered to the invaders or partisans. The martiality would be fairly high for, say, Sikhs, and low for, say, Amish. It would be 100% for Dorsai.
I doubt that any more detail than this will contribute anything to the game.
Cheers.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
I think not managing population by ethnicity but by proportion will be a nightmare. It will lead to lots of computation just to deal damage.
F.e. A square of 1000 EG A and 1000 EG B. Proportion is 0.5A, 0.5B, population 2000. Suppose 100 A die in a revolt. Instead of having 900A,1000B, we have to compute 1900 total, 0.45A, 0.55B (making sums and divisions and keeping one additional variable).
Also, does 100% martiality mean 2-year olds attack their opponents with clubs?
Having a young/mature distinction (I don't mind about sex) allows to slow growth a bit and to force the player to wait for 2 or 3 turns before they can grow an army out of a square. Mature has the advantage (or disadvantage) to have an impact on the economics. Having an additional militaristic factor in the EG's is OK for me, but longer-term IMO.
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:22
|
|
Hi Gents:
Gary's stated approach is pretty much what I was hoping to do on demographics. That is, not much! I think more detailed demographics would complicate many parts of the game, especially economics, in a way that doesn't give players much in return. Why have all those headaches for nothing?
On militaricity I would go perhaps a tiny bit further than Gary's stated position, which I get to in item 3 below. To state my position, which is mostly what Gary had, but responding to some of Laurent's points:
1. Have a fraction representing the background level of militarily capable individuals. This is the previously-stated Militaricity or whatever. To crudely account for demographics it could have an absolute maximum of 2/3 or some such. That would effectively exclude young and very old.
2. Militaricity certainly could depend on EG, and I think that adds some good features.
3. For each EG in each Square (that is, each Population Element IIRC) the fraction currently available should be kept track of. Call this Available Militaricity for the moment. When militia are formed, or armies conscripted, the maximum population avaiable would be the Available Militaricity (AM). That way if a militia were formed in a square, and was subsequently slaughtered, immediately thereafter there would be no individuals left suitable for armies. Each time the population grows a value TBD would be added to the AM until it reaches the EG's Militaricity. In this way militarily useful individuals could be depleted but would replenish with time.
4. To a non-trivial extent men suited for military service are also those most likely to cause trouble in other ways, like riots. We may also be able to use AM in the social model as the number of potential hot-heads that might riot. I have read some speculation that one reason post-revolution France was so relatively internally peaceful, even with the wrenching social changes, was the the levee en masse put most of the potential rioters in military service! What do you guys think?
It seems to me that 3 doesn't hugely complicate things, and yet gives a natural limit to local rebellions if they are ruthlessly stamped out.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
First of all, I also agree to do nothing for D7.1.
I mean, nothing about militia. I still have to send some stuff about units costs, and I will be done.
Now Mark said:
quote: 3. For each EG in each Square (that is, each Population Element IIRC) the fraction currently available should be kept track of. Call this Available Militaricity for the moment. When militia are formed, or armies conscripted, the maximum population avaiable would be the Available Militaricity (AM). That way if a militia were formed in a square, and was subsequently slaughtered, immediately thereafter there would be no individuals left suitable for armies. Each time the population grows a value TBD would be added to the AM until it reaches the EG's Militaricity. In this way militarily useful individuals could be depleted but would replenish with time. |
That is what I want. But I want it by EG because a mixed-EG square with A's and B's will not revolt an masse against A conquerors. This means that when B's Available military suffer losses, I must keep track separately of A and B's AM, which I must then confront to previous total population and ethnic proportions in order to compute the new proportions and total population.
That is something I consider more complicated than keeping per EG figures of population and AM. Now if the social model requires these distributions, we can keep them, but I'd rather have them as output computed on demand than something I compute everytime I deal damage to the population. I would like to add the fact that if you have militaricity depend on EG, there is also something I would like to depend on EG, which is birth rate. In modern times, Europe (and probably US) demographics vary vastly per EG. This with immigration leads to right wing governments being elected in some countries, so I think it has an impact.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
I want to have militia before AI because AI will have to take militia into account, so it would be better if it was already in when we start on AI. And AI is the first thing I wanted to code in Clash so I'd rather go for it but I don't think it is time yet.
I'll add whatever methods I need in Population classes, and additional data I need in order to test. You will then change the internals as you see fit.
That is not as if it aws a lot of work either. I'll spend much more time on the actual militia stuff.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
I have started coding. This is a bit code-verbose, so I put in bold things which are of interest to non coders.
Here is what I need to know:
1)In a square how many people of each Ethnicity are able to fight.
2)For each Ethnicity how it relates to attacking and defending civ.
3)To deal damage only to the adult/fighting population of the Ethnicity.
1) I can retrieve by Ethnicity without changing the APIs.
2) I could call EthnicGroup.getNationality() but don't know how to retrieve EthnicGroup objects from the square. So I use Administration.getEthnicDiscrimination based on the civ government. Militia will rise to support either the attacking or defending government, if that government's ethnic discrimination is twice less than the other government's discrimination. If discriminations are both 0, noone rises. This sinulates a population welcoming foreigners as "libertador". They may revolt afterwards, but that is another problem (think Columbia vs. Ecuador...)
3) I have to know the number of fighting people per Ethnicity (thus in PopulationElement). This means storing additional data in PopulationData, and transmitting it to PopulationElement. I keep saying this is awkward, as we will have to replenish this fighting population based on calculus I find too complicated to do. Thus I skip a separate adult/fighting population now, and consider everyone can fight. One fifth of available population may be enlisted. This is because mainly of laziness in front of what I consider to be a complex modelization and the fact that Mark doesn't want too much detail.
I still have trouble removing population from the PopulationGroup as I have to carry on a PopulationData argument around when I only need a PopulationElement. It can be done, but I find it awkward. I will do it, but I have to complain somewhere.
As a side note:
Distinction between EthnicGroup and Ethnicity is not clear in the code (at least some APIs seem to confuse one another). I may end up renaming some methods for consistency's sake if I have to use them.
Another point is what kind of elements are created when a militia arises. Note that I say elements. This won't be a unit, and they won't profit from mixed arms tactics and such. They will be the poorest army available...
But I would like to make the element choice based on tech. When there are hunting rifles available, militia is more efficient than clubmen militia. This would mean a backward civ liberating a square of its own people may find people better armed revolting. Should there be any special tech bonus there?
I don't know the tech model enough, but are there RP's transmitted when a square is conquered? Particularly if that square is full of friendly (to the conqueror) population?
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:22
|
|
Hi Laurent:
Just a few comments...
quote: Originally posted by LDiCesare
2) I could call EthnicGroup.getNationality() but don't know how to retrieve EthnicGroup objects from the square. So I use Administration.getEthnicDiscrimination based on the civ government. Militia will rise to support either the attacking or defending government, if that government's ethnic discrimination is twice less than the other government's discrimination. If discriminations are both 0, noone rises. This sinulates a population welcoming foreigners as "libertador". They may revolt afterwards, but that is another problem (think Columbia vs. Ecuador...) |
Ummm.... This doesn't make any sense to me. The people will have an affinity for a government, possibly Despite its ethnic discrimination (ED) settings. The whole idea of ED is there is a Favored EG in each civ that is not subject to ED. The way you have it, it seems to me that if a German area in WWII were taken over by the allies, the local Germans would rise up in favor of the Allies if they had much better ED settings than the Nazis. Generally if the civ doesn't discriminate against an EG, it shouldn't bother that EG.
Until the right social model stuff is hooked up, I'd just say we should have two states. An EG in a square has "affininty" for a civ, or it doesn't. If the EG name is essentially the same as the civ name of one of the combattants then we define it as having affinity. It will welcome troops from that civ with open arms, and will fight with those troops against someone else. If there is no affinity then maybe the criterion you used in 2 could apply. However I'm not sure that's the best long-term answer. Maybe the best response of a local militia is to stay out of a fight and let the two armies potentially beat each other to death.
quote: This would mean a backward civ liberating a square of its own people may find people better armed revolting. Should there be any special tech bonus there? |
Maybe, but seems like another D13 issue .
quote: I don't know the tech model enough, but are there RP's transmitted when a square is conquered? Particularly if that square is full of friendly (to the conqueror) population? |
No, nothing like that yet.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
My point is: I want to know the Ethnicities and their relative population in the square. For each Ethnicity I want to know which civ it likes most between those that fight on its soil. If it vastly prefers one of them, then it will consider mustering a militia.
Right now, Government.getDiscrimination(Ethnicity) provides one way to find it, and EthnicGroup.getPreferredNationality() another one, except EthnicGroup objects are unreachable from my code.
Gary, if you change the whole population stuff, I also need a getFightingPopulation() method in PopulationElement or something like that. This is the amount of peopla able to contribute to the army (basically the adults). Not all of it will be taken in the militia.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
I have made a first implementation of militia. I lack things from the population point of view (no way to know what civilization a given ethnicity supports, lack of definition of available fighting population).
Anyway here are the first results:
Delenda scenario.
1/5th of the population of a square will rise as Warriors to help the defender if they give odds to win between 0.75 and 1.75 (random factor). They won't raise militia if odds are already more than 1.75. It would produce too many useless militia if Ithey rised every time.
The effects on gameplay are often little, but sometimes it makes a difference. Like when an exhausted 5000-man Hannibal attacks a slight 5000-man defended Rome. Suddenly 30000 Romans rise and rout the Carthaginians. Most of the time, however, the armies are too numerous and powerful for the militia to show their head.
When militias do appear, they rarely take much damage.
This is because they usually are used to outflank the opponent. Most damage is sustained by regular armies. I can probably change that if needed, but then all damage will probably be sustained by militia instead of regular army.
The amount of damage sustained is often 0, otherwise around 1-3% of total millitia. F.e. 830 dead in around 25000 militia and 67 in 6500 militia.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
I modified the code slightly and now it runs quite fine.
Here are 3 examples of fights where milita helped. Note these occurrences are not that many, mainly because in Delenda the armies are big and phalanxes and legions are way stronger than militia (warriors).
You can see that I have latins fighting Romans in the last example, which is silly, but hey that is why I want some Ethnicity stuff.
Battle 1)
Roman armies
lost 590 health in long-range fights
Attack: 589600 down to 530052
Defense: 22 down to 21
Health: 10000 down to 8538
Cost: 1460 down to 1291
12427 Gauls fought in militias, 3209 died.
Carthaginian armies
lost 897 health in long-range fights
Attack: 659549 down to 8325
Defense: 22
Health: 10200 down to 136
Cost: 2062 down to 27
Analysis: Carthage had an edge to begin with. Gaul milita made the difference. Thus it can affect game play as you will have to plan militias. Note militia and regular army took damage. Militia got more damage, but they are crap army to start with, so that is quite good.
Battle 2)
Roman armies
lost 798 health in long-range fights
Attack: 510128 down to 0
Defense: 21 down to 0
Health: 8245 down to 0
Cost: 1243 down to 0
Carthaginian armies
lost 350 health in long-range fights
Attack: 1041829 down to 931011
Defense: 24
Health: 16108 down to 14398
Cost: 3194 down to 2848
24969 Gauls fought in militias, 1074 died.
Analysis: Carthage had an edge but somehow the militia felt they were needed. It is a bit strange here as it seems Carthage was 2 vs 1, but there are a few more figures that go into the equation which don't show here. Anyway militia took half damage sustained by regular army here.
Battle 3)
Roman armies
lost 716 health in long-range fights
Attack: 606314 down to 25408
Defense: 22 down to 20
Health: 10000 down to 325
Cost: 1460 down to 55
Carthaginian armies
lost 460 health in long-range fights
Attack: 1363845 down to 951470
Defense: 27 down to 27
Health: 16563 down to 11128
Cost: 3385 down to 2366
31079 Latins fought in militias, 0 died.
Analysis: Latins shouldn't fight Romans during the Punic war! Again, militia rises when not eally needed. Here they took no casualty. This may be because they didn't fight much. Fights last several ticks, I log militia even if they fight only a single tick. If the militia outflanked Romans, thus reducing them to 1 vs 2, the militia wouldn't fight the following battles (ticks), which can explain the low damage. If this needs explanation in-game, I can try to add the number of ticks fought in the output, but I don't want it to grow too much.
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:22
|
|
I have gone ahead and implemented a way for the people in a square to find out if they have affinity for a given civilization. This will support figuring out if a militia will muster in a square to resist occupation, and if so whose side they fight on. It uses the ethnic discrimination (ED) value as was suggested by Laurent. (Laurent, I have sent you the code changes. All modified code has the comment tag //*M*.) there will be some implementation issues with the way I have chosen, but I wanted to keep the modifications of the existing code to a minimum. For the militia code, at least for now, we will use the civ.getGovernment().getEthnicDiscrimination(ethnicity) method of figuring out how much the people like the troops. An ethnic group (EG) can get its ethnicity using, surprisingly, the getEthnicity method. The requirements to support this in the XML scenario file are:
1. There needs to be ruler preferences set for all governments of civs. I think this is mostly true already in the scenario files. In any case I will send a new delenda file that has that included. The correct long-term way to figure out ethnic discrimination is to consult the government profile of the civ. In Gary's refactoring of the government code that has been turned off, so I just use the ruler preference for getting the ED instead. That's ruler preferences are required. The XML for ruler preferences is under civilization-government-ruler.
2. We need to set the preferred ethnicity (ethnicity that is favored by the government) in the civilization-government section of the XML scenario file. Usually it is just set to the ethnic group with the same name as the civilization.
Once these are in the scenario file, civ.getGovernment().getEthnicDiscrimination(ethnicity) will determine the given government's treatment of people of that ethnicity. Ethnicities that are a civ's preferred one have an ethnic discrimination value of 0. From a militia perspective they should always come to the aid of their civ's troops, and attempt if practical to fight off innovators. Ethnicities that are not preferred in a given civ have the civ government's default ED value. For ancient governments we are assuming that the levels of ED are fairly high, may be in the range 0.4-1. It seems to me that the higher ED value an EG has in a potential conquering civ, the stronger should be the resistance from a militia perspective. Eventually other concerns should enter into this decision, but we are keeping it simple for now
To sum up what I think has been said earlier in this thread, and where we are now... When troops whose civ has an ED of 0 for the ethnicity are fighting in the square, militia will support those troops against any opponents. This is just the case of conquered or invaded Romans fighting with the Roman legions against the Carthaginians. Militia will also resist invasion by any civ that has an ED that is nonzero with respect to their ethnicity (provided its not futile). This is the case where Romans are invaded by the Carthaginians but no Roman normal troops are available. However, Gauls, and perhaps Iberians, will resist conquest by either side. Just to be clear though, as the code currently works the Gauls will not rise up by themselves to throw out the Romans that have previously conquered them. Once the square is controlled by a civ I'm assuming that that civilization's troops can move freely through it, or remain there without being attacked by militia.
Some issues:
One problem with the current scenarios is that for instance in delenda, the Punic war scenario, both Rome and Carthage are multi-ethnic civs. As things are currently set up those of Roman ethnicity are only in a single square, with the balance of the Empire being Latins and Gauls. I think at least for the Latins they should resist Carthaginian conquest similarly to the Romans. The Gauls might actually be ambivalent between Roman and Carthaginian rule. Anyway, so that things work sensibly with respect to the militia, I propose that we change all the Latins to Romans for the moment.
Any opinion as to whether the Gauls should support Roman defense of their territory, or remain neutral? In real life it would be a complicated decision. We could assume that if there is a large ED difference between the two civs, that the militia would rise for the better side. Perhaps the amount of militia would also be proportional to the ED difference between the civs, maybe with some bias to remain in the civ they're already with.
If an independent square is invaded by foreign troops from two different sides I'm not sure what happens either. Again it's moderately complicated. Suggestions?
In a square with more than one EG, it is possible that militia could arise that splits its allegiance between two sides. I think this is only natural, but thought I would state it explicitly just so that no one is surprised when it happens. Laurent, does the code work that way?
This will get us pretty close to completing objective 2 in the Demo 7.2 Proposal thread.
Anyone interested in early playtesting of the militia features for D7.2 should let us know in that thread.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:22
|
|
Multi-ethnic squares will be able to split militia. They are actually more prone not to provide militia even if they wanted to fight together because they don't know if the other ethos will join in (e.g. if you have 5000 ethnicA and 5000 ethnicB who both support civ1, they would both fight if they knew they were 10000 to do so, but, being only 5000, they may well decide they are not numerous enough).
I think there should be ethnicity relationships of a sort, so that Latins are more "like" Romans than Gauls (maybe families/class hierarchies of ethnicities, like Indo-European/Latin/Roman - with the question of how new Ethnicities come to be - Italians from Romans, Lombards etc. for example). That could allow to decrease ED for sibling ethnicities for instance.
|
|
|  |
 |
|  |
All times are GMT. The time now is 05:22. Apolyton Time is 00:22. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|