Coding the "Society Model"

[Mark_Everson]

I agree with Gary's approach... I don't see anything else that make sense. I had been using the civ name as a temp placeholder since that is what was in the code I took over. Using a pointer to a civ seems to be the best approach. Rodrigo, what can't be done with the model if that approach is taken?

[Gary Thomas]

Another point that I neglected to mention is that the fact that a civilization has no territory does not mean that it is destroyed. The Dutch colonial empire was all but destroyed in the Second World War (saving, I think, only a small colony in South America). After the war it was reinstated, though perhaps not as successfully as it would have liked. This was not a newly created civilization, it has the same social factors as the previous one.

In a similar way, the Aztec civilization might has been resurrected, in which case it would have the same characteristics as it had had before the Spanish conquest, with possible modifications by the affected ethnic groups. The fact that it did not take place is a matter of hindsight - the civilization should only be considered destroyed when there is nobody left who consider themselves to be of that nationality.

Cheers

[roquijad]

Gary, if the discussion is about defining the thing as a string or as a pointer, then it's your call. I can't do nothing but confuse you with decisions like that.

But since I agree with your last post, I wonder how a pointer would do in those situations.... If the aztec and the inca civs (govts) disappeared, all aztec and inca EGs would have null pointers. If a "neo-aztec" empire comes to life, how can you identify aztec EGs from inca EGs?

If the above question sounds strange to you, that should be a sign that we're not working with the same idea of what a civilization is...

Anyway, all I'm saying is don't connect EGs to a thing call "civilization", where civilization here means a thing with a govt, provinces, techs, etc. If you do that there'll be trouble. (sound like a threat, but I just mean we're gonna face some problems! )

[Lord God Jinnai]

There's something else in that reguard...what about new EGs that are created through diversions of the population...there wasn't always a USA EG or a Canadian EG...so at what point to the pointers switch from England to USA or Canada?

[ogj20]

Right, another one of my excessively long posts trying to revive a discussion.

First of, would it be possible to see a copy of the equations documents that are mentioned above by Gary.

Secondly, it seems that some clarification/rationalisation of the method of handling ethnic groups is required, partly because having read this thread I'm really not sure exactly how things are supposed to work, and partly because I suspect that the model is in danger of either requiring huge storage and processing, or failing to provide for ethnic diversity and cultural evolution, in which case it seems to lose much of the benefits which make it worthwhile to implement.

So, to put the cat among the pidgeons, restate other peoples ideas, go over ground that has already been discussed and agreed, and generally make a nuisance of myself, I'd like to have a recap of the issues and suggest an idea.

I would suggest the following are the essential points.

* Ethnic groups essentially have a population, religion and cultural background, and need to be located in a map square, in order to allow populations to change hands by conquest.

* Ethnicity is the combination of religion and something which is almost but not quite as simple as nationality (call it culture?).

* It should be tracked at province level to limit storage and processing requirements, and processes should exist to allow evolution of preferences, creation of new ethnic groups and probably the disapperance of old ones.

I suggest the following model would allow this:

level object / class

World culture religion
(nationality name + prototype attributes) (religion name + ideal attributes)
| \ /
Province Ethnicity (cultural attributes stored at this level)
| |
Square EthnicGroup (actually, only really when moved about,
normally just part of the populationData ethnic distribution)

The key to this is that ethnicity objects would be created at province level that hold cultural attributes. Two ethnicity objects would represent people that are nominally from the same ethnicity if they had the same nationality and religion, though two such ethnicity objects from different provinces could have markedly different cultural attributes, since they would evolve independently. The interesting things would go on when people from one ethnicity meet other people from a supposedly equivalent ethnicity.

Putting an Ethnic group into a province

If you placed an ethnic group from one province into another (by migration, conquest, colonization or redrawing of province borders etc.):

Attempt to find an equivalent ethnicity (culture + religion combo) which is already present in this province

1) If none is present you would add it, simple. (e.g. add Roman pagans where there are none, get roman pagans)

2) If one is present you would check to see how different the cultural profiles are (e.g. by sum of absolute or square differences between the factors). Decide if they are too different to be compatible, either based on a cut-off level, or by a random check based on the level of difference and the number of ethnicities in the game, with aim of keeping this to a managable level.

a) if compatible: merge the profiles by weighted average.
(e.g. add 1000 Roman pagans who are fairly traditional
to 2000 Roman pagans who are a bit more traditional,
get 3000 Roman pagans who are somewhere in between)

b) if incompatible: an ethnic schism would occur:
(e.g. add 1000 Roman pagans to 2000 Roman pagans
they can't stand to be in the same room with and all hell breaks loose)


Ethnic schism:

If there become two incompatible ethnic groups with the same ethnicity in a province (i.e. an incompatible ethnic group has just been added to a province) then the people of one of the two groups would be forced into breaking from their culture, and finding a new way of viewing themselves.

To accomplish this we would change the ethnic group which is furthest from the (shared) cultural prototype profile. Their ethnicity would be changed to

either:

An existing ethnicity with a different culture but the same religion that already exisits in the province if that will reduce the misfit with the cultural prototype profile -- a mechanism for eliminating cultures, representing the outcasts being driven to join a different social group whose views better fit their own.
(e.g. add 20 roman pagans who are very capitalist to
10 RP who are very socialist, and the 20RP merge with the Italian Pagans,
who are just like the 20RP, but Italian)

or else:

We would create a new culture with a prototype profile formed from the ethnic groups's profile, ensuring this is (much) closer to the ethnic groups profile than the incompatible one was. This should have a new name, ideas would be

The civ name of the civ they find themselves in
A geographic modifier (East Germans)
A meaningless modifier (White Russians)
A generic name list... etc.

In roughly descending order of preference, if they are not already taken.

This represents the outcasts, finding no support in society, creating a new identity for themselves.
(e.g. add 20RP capitalist to 10RP socialists, they becomee 20RP Northern Roman Pagans)

Revolution/independace

In addition new cultures could be created when revolutions occur, or when provinces try to become independant, e.g. if the gauls revolt against rome, they create a new civ called Gaul, but if some romans revolt against rome, they'll need a new cultural name.

These new cultures could either choose names as above, or from a list provided with the original culture (Celts -> welsh, irish, scottish etc.) if we want to add this detail.

Result of a schism

Other ethnicities with the same culture in the province could decide which side they are on in the argument, by moving them to the new culture if it makes the fit with their cultural attributes better than with the existing cultural profile (e.g. if some Roman pagans become Italian Pagans, then the Roman Christians should decide if they want to be Roman or Italian).

I think it would make sense to update the original cultural prototype to be the weighted average of the (local)ethnicities which are still part of that culture after a schism occurs, this would represent the members of the original culture taking stock and really considering what it means to be part of their culture after all.

Optionally, it could also make some kind of sense to have ethnicities of the same culture in SURROUNDING provinces also decide which way they want to jump, though this might not be a good idea.

Result

This way we limit the number of sets of preferences we have to store to at worst the number of cultures*religions*provinces, which should be more manageable than by square. In addition the number of ethnicities the player sees is at most cultures*religions which the player should be able to cope with, and we provide a fairly intuitive mechanism for ethnicites to be created, evolve and disappear.

Comments and complaints please.

[LDiCesare]

I think province vs. square is OK.

About revolution/independance, I'd rather have the province ethnicity change before they revolt. That way, you can have Americans and English in the colonies before the American revolution, thus allowing to have units which will become American or English, and not all of them turning American.
So I think every turn, if a province ethnicity is becoming too far from its cultural protoype, it would change into a new ethnicity (maybe drawing some other ehtnicities along with them, creating a new prototype). The condition for the change would be distance from cultural prototype, based on a set margin or random factor.
Thus I suggest checking every ethnicity against its cultural prototype every turn, and changing to the preferred culture or switching to a new culture if the old one no longer fits the needs. This should IMO trigger revolution (though it may not occur immediately) rather than be a consequence of it.

Also, when joining a square, number of individuals should be important. A small number of people will more likely be assimilated than a big number.

I don't know how the model handles inter-EG marriages, though that may not be important early in the game.

[Mark_Everson]

Originally posted by ogj20
Right, another one of my excessively long posts trying to revive a discussion.

You fit in very well! We tend to be a long-winded bunch . Thanks for pushing this foreword!

First of, would it be possible to see a copy of the equations documents that are mentioned above by Gary.

I just sent it, along with other documentation that may be of value.

I basically agree with many of the things you say, and the most difference is in the revolution/independence stuff. I'm primarily in agreement with the continuously-evolving view presented by Laurent. For example, before the American Civil War the American ethnicity would probably already have split into three overall ethnicities represented by those in the north, those in the South, and those in the pioneer Western Territories. I think just because there is a revolution is no reason to change the ethnicities of people. If there are ethnic fall lines upon which a revolution is based, they most likely appeared long before the said revolution actually occurred.

I think we have discussed this issue before, and the basic idea was to use a clustering algorithm to determine if something that is nominally a single culture is bifurcating. This wouldn't be much of a load on the system seeing as it would only has to be done occasionally.

Your schism stuff sounds reasonable to me, although I think it might be fairly rare. I hope Rodrigo makes it back, and we can hear what his opinions are on your proposals. BTW, I just e-mailed him letting him know about our new discussions.

Originally posted by LDiCesare
Also, when joining a square, number of individuals should be important. A small number of people will more likely be assimilated than a big number.

I don't know how the model handles inter-EG marriages, though that may not be important early in the game.

I agree with pretty much everything you said Laurent

edit to fix quoted text. Did you know that if you mix an opening "quote" tag with a closing "q" tag it doesn't consider the quote ended. I didn't!

[Richard Bruns]

I think that army units should have a listed ethnicity. That way the game knows who to add to a square when they disband. It would also be good for the militia calculations; the people can use the unit ethnicities to decide if they want to fight. Also, units should only be able to get reinforcements of the square they are in contains their ethnicity.

One thing that bugs me in the scenarios we have now is that armies can be raised right after conquering enemy territory. As Attila grabs Roman territory, he can use that territory to start cranking out more Hun units. I believe that the best way to fix this is to say that a civ can only raise units from their preferred ethnicity, so it becomes impossible to churn out units from newly conquered squares. A civ that raises a lot of units should start having problems with population depletion, like the Germans in World War 2. They could use the economic resources of the captured lands, but only Germans could (usually) be trusted to be soldiers, and they soon started to run out of Germans even though they ruled over a much larger population than before.

Of course, civs with high ethnic tolerance may get around this, but that comes a lot later in the game.

[ogj20]

I agree entirely that units are going to need ethnicity for a whole host of game mechanics to work properly. That's why I snuck it into one of the fixes I sent Mark.

Mark,

I found myself annoyed by the way that units disbanded in unoccupied squares would just evaporate, so I developed some changes that mean they will colonise the square instead, thought they bring nothing of use with them as I have it at the moment (I thought it would be best left to you to decide on an appropriate amount of capital(mostly in the form of tools, I'd have thought) that the members of a disbanded army should have).

That unfortunately led me into making some small changes to quite a few areas of the code, since I quickly discovered that though populations are supposed to ethnic groups, armies don't have.

...

I have it at the moment armies that are built get the same ethnic profile as the square they are built in (should this be province?, since I think the recruits come from the entire province). Armies that disband return their troops in ethnic groups based on the ethnic distribution. I've also had to change the code that handles building armies for scenarios, to include a new property that can be given to units, of unitEthnicity, so that units can start out with an ethnic distribution (though as it stands they can only have a 'distribution' of one option, but I didn't want to complicate this too much.)

I think this feels nicer than it did, and should provide opportunities to feed into other game mechanics, e.g. we could have armies that can rebel or defect because they could now have opinions based on their ethnic makeup, or other similar possibilities.

The down side is that it will require a little work to alter the scenario files, since wherever there was a unit creation tag there will now need to be information about that units ethnicity. I thought this might be improved by having a default ethnicity for the army high command, which would limit this to one change per civ per scenario

I'm don't think those changes are incorporated into the testbed yet, but when they are you will be able to take advantage of this by e.g. changing
Warriors to WarriorsThe People

If these changes aren't made then the units simply have a null ethnicity, and nothing breaks, (but it's a bit weird when you disband them in empty squares, because the resulting population also has no ethnicity, and as a (rather strange) result cannot be picked up by a taskforce.

[ogj20]

Damn, I take it that you can't post xml tags as straight text, is there a good way to do this..

anyway, let's try a cludge to get round this, please read square brackets as tag style angle brackets..

change [unit]Warriors[/unit] to [unit][name]Warriors[/name][unitEthnicity]Warriors[/unitEthnicity][/unit]

fingers crossed this works....

[Mark_Everson]

Yeah, posting html is a pain. BTW I had to re-format my post of last night. I ended up with a long quote that was actually new comments from me interspersed with a few quotes looking like one big quote. It came from mixing a "quote" tag with a "q" tag, which is apparently not read by the parser right.

Richard:

One thing that bugs me in the scenarios we have now is that armies can be raised right after conquering enemy territory. As Attila grabs Roman territory, he can use that territory to start cranking out more Hun units. I believe that the best way to fix this is to say that a civ can only raise units from their preferred ethnicity, so it becomes impossible to churn out units from newly conquered squares. A civ that raises a lot of units should start having problems with population depletion, like the Germans in World War 2. They could use the economic resources of the captured lands, but only Germans could (usually) be trusted to be soldiers, and they soon started to run out of Germans even though they ruled over a much larger population than before.

Of course, civs with high ethnic tolerance may get around this, but that comes a lot later in the game.

I don't know how to fix the Romans fighting for Carthaginians problem. Long-term I think we can have a fix, but it will be a bit complicated.

In the scenario as it exists, it is mostly at first Romanized Gauls fighting for Carthaginians in the case you object to, which may have worked just fine in reality. When you get to Latins signing up for the Carthaginians, that is a bit more of a stretch.

One idea is to give troops a reliability based on the units ethnic composition. If that ethnicity is treated poorly in the civ it would be:
1. More likely to break in a morale check, and more likely to undergo manpower attrition when/if we have that
2. Less combat-effective overall
3. More likely to join a revolt or switch sides to another civ.

I'm not sure this is urgent enough to require a temporary fix. What do others think? I guess each square could have a "when conquered" flag and you could only build units with ethnicities different from the civ ethnicity something like 20 turns after conquest.

[Richard Bruns]

Sounds good. How do you code for a mix of ethnicities in the unit?

You have to use the html escape sequences to get any code to work properly:

&lt; gives <
&gt; gives >

What I do is write posts in a word processor and then go through them with the find-replace command. An added benefit is that I don´t lose them if something goes wrong with the forum.

[LDiCesare]

Unit ethnicity has been coded by Owen, but is right now single-ethnicity when built from xml files.
I don't think units should be restricted from ruler's ethnicity. Legions were mostly made of non-Romans for instance, and colonial armies have been full of non-core ethnicity fighters.
I can probbaly check a unit behaviour during a fight the same way I check for militia: If the unit's preferred civ is not its current civ, then I can give it a chance to revolt and switch sides, if they believe switching sides can make them victorious. That means I need to show ethnicity details in the army details popup so the player be not surprised.

[Richard Bruns]

Mark´s plan sounds good. Allowing other ethnicities to be recruited, but only after a certain amount of time, is good. Roman legions of the late Empire may have had a lot on non-Latins, but that was only after they had held the areas for quite some time. IMO you should have to hold an area for at least one generation before you can recruit soldiers into the core army.

[ogj20]

As LDiCesare says, right now you can only assign a single ethnicity to each unit in XML, I did that to keep things simple, but units that get built during the game can have a mix of ethnicities in a single unit. If you'd like I could add the ability to have a mix for XML units farly simply, it's just a case of yet more tags, and more work for scenario designers.

As to limiting the ethnicities you can recruit...

I suggest this could most easily be implemented by having individual ethinc groups (... or whatever level we hold this on... see above) having a civilisation loyalty value, which increases slowly over time,at a rate and to an equilibirium level based on e.g. how well treated that ethnicity is, how secure the civ is, how many of your troops are knocking around the area, how close to strong opposing civ's you are.

If you conquered a square, the loyalty to you would become (1 - the loyalty to the previous owner) and you'd only be able to raise troops from ethnic groups with greater than a certain loyalty value. (plus it could affect the chances of militia appearing or rebellions occuring etc.)

That way newly taken territory won't supply you with troops (though it can be forced to help pay for them).

If you'd like I could put some outline code in that simply has the loyalty increasing at a constant rate over time up to 1, ignoring the complication of working out an appropriate rate and target level, and only lets you recruit when it's over say 0.5.

If I set it so that it increases by 0.3 a turn, then you'd have to wait three turns to recruit from newly captured territory, but of course less from territory that's been swapping hands regularly, which will oscillate around 0.5

I think modifying this to account for all the complexities of which side the people WANT to support will have to wait until we get the social and government models really sorted out, but this should let us playtest the key effects of the mechanism easily.