Ethnically Correct Population Growth - Improving Immersion [IMPLEMENTED]

Do you like the idea?


  • Total voters
    37

raystuttgart

Civ4Col Modder
Joined
Jan 24, 2011
Messages
9,672
Location
Stuttgart, Germany
Hi guys,

@Ramstormp already has something like this in his mod PTSD.
But well, I want to make this a bit more elegant ... (sorry, not intended as critics).

----

I want to introduce an XML balanced "Ethnically Correct Growth System".
(It will be a new XML file Civ4PopulationGrowthInfos.xml - not included in the Civ4UnitInfos.xml directly.)

1. Which "Children" will be generated by which combination of "Parents" . (Of course referencing Civ4UnitClassInfos.xml)
2. Statistical Chances (base values used for randoms) based on the amount of "Partent Units" in the City.

So in a Colonial City not only "Europeans" will be born anymore.
(Unless the complete population of the City is also "European")

Those UnitTypes can be "born" (by Population Growth - depending on actual Population):

Born Free:
(Simple cases where "social status" and ethnicity stays the same.)

1. Free Settler (All "European" Colonists - except Criminals and Indentured Servants - see below)
2. Converted Natives (Converted Native + Converted Native)
3. Freed Slaves (Freed Slave + Freed Slave)

Born Unfree:
(Simple cases where "social status" and ethnicity stays the same.)

4. African Slaves (African Slave + African Slave)
5. Native Slaves (Native Slave + Native Slave)

Born Disadvantaged:
(Simple cases where "social status" and ethnicity stays the same.)

6. Indentured Servant (all combos for Indentured Servants and Criminals.)
7. Mestizo (Mestizo + Mestizo)
(Social Status similar to Indentured Servants)

The other "Parent Combinations":
see below.

----

So there is also one new Unit: Mestizo
(which is not completely free but also no Slave - simiar to Indentured Servant)

  • It can also become and Expert using "Learning by Doing"
  • It can also run away like an Indentured Servant
  • It has similar (or the same) Bonusses as a Converted Native
----

Also we have a special cases for "Child Unit" with some random:
(Will be configurable in the XML.)

European + Converted Native / Mestizzo:
(Their "social status" but ethnicity are not sure.)
  • 50% Chance : European --> "born free"
  • 50% Chance : Mestizo --> "born disadvantaged"
Converted Native + Mestizo:
(Their "social status" but ethnicity are not sure.)
  • 50% Chance : Converted Native --> "born free"
  • 50% Chance : Mestizo --> "born disadvantaged"
Freed Slave + Mestizo:
(Their "social status" and ethnicity are not sure.)
  • 50% Chance : Freed Slave --> "born free"
  • 50% Chance : Mestizo --> "born disadvantaged"
Converted Native + Freed Slave:
(They keep theirs "social status" but ethnicity is not sure)
  • 50% Chance : Converted Native --> "born free"
  • 50% Chance : Freed Slave --> "born free"
Native Slave + African Slave
(They keep theirs "social status" but ethnicity is not sure)
  • 50% Chance : Native Slave --> "born unfree"
  • 50% Chance : African Slave --> "born unfree"
Native Slave + Mestizo:
(Their "social status" and ethnicity are not sure.)
  • 50% Chance : Native Slave --> "born unfree"
  • 50% Chance : Mestizo --> "born disadvanted"
African + Mestizo:
(Their "social status" and ethnicity are not sure.)
  • 50% Chance : African Slave --> "born unfree"
  • 50% Chance : Mestizo --> "born disadvanted"
----

So the main difference to PTSD is only this:
I will make the complete System XML configurable.
 
Last edited:
Why would mestizos try to run away?
Their status was between a full blood european (spanish) and a full blood native, so they had some privileges but not all compared to a european colonial officer. They were not slaves.
Most colonial powers did not send many woman to the colonies, so most of the colonists took, married (or raped) native women and the offspring were mestizos. European parents usually supported their mixed offspring and did not put them into slavery.

In todays Mexico probably about 50% of population could count as mestizos ...

Indentured servants instead were voluntary slaves for a number of years to pay for the shipping from europe to the colonies. They usually only tried to run away if the environment was life threatening (unhealthy swamps, disease, famine), work was too hard or punishments by masters were too cruel. In early Jamestown most of the servants (as well as many other colonists) perished in the first years. Servants were usually less productive than other colonists since they worked for a company or master and not for themselves.
The game is actually missing an option for the player to set indentured servants free so that they can work their "own" land and be more productive. But since servants can learn from natives, this is not really a problem.

(I guess that in real life every colonist would try to run away if the environment is deadly.)

Without wages/upkeep, the system of indentured servants does not make much sense in colonization anyway. It is more a historical detail for flavor.
Old col said that the servants lacked education so they were less productive and could be set "free" via school/college/university education (or by native training).
 
Last edited:
Why would mestizos try to run away?
For the same reasons that "Indentured Servants" do.
For being treated unfairly / disrespectful / not being considered fully free.

They were not slaves.
That is exactly what I wrote. :thumbsup:
But they were also not treated as "equal".

----

But I agree, Mestizos should not revolt. :)
(Which is why I have them balanced for gameplay similar to "Indentured Servants".)

Which Indentured Servants also do not revolt.
But Slaves and Criminals for example do revolt.

----

Also I would directly give Mestizos the capability to become "Experts".
So they do not need to get free first - like Indentured Servants do

-----

The game is actually missing an option for the player to set indentured servants free
That is wrong !
There is the LbD feature: LbD Free.

Maybe it does not work like you want it.
But Indentured Servants can become free.

Old col said that the servants lacked education so they were less productive and could be set "free" via school/college/university education (or by native training).
I have really no idea what you are talking about ... :confused:
It is 100% the same in WTP considering "Indentured Servants".

1. They have lower productivity (in City Jobs)
2. They can use the Education System (at lower Productivity)
3. They can use Native Training. (Just like Free Colonists)

----

Maybe you confuse them with "Criminals"... :dunno:
(Those are infact more restricted.)
 
Last edited:
The game is actually missing an option for the player to set indentured servants free so that they can work their "own" land and be more productive..

I think you are missing something fundamental about how units progress. Indentured servants already progress to free colonists. If there was an option to set them free (to free colonists) then they might as well not exist.
 
...
1. Which "Children" will be generated by which combination of "Parents" . (Of course referencing Civ4UnitClassInfos.xml)
2. Statistical Chances (base values used for randoms) based on the amount of "Partent Units" in the City.

So in a Colonial City not only "Europeans" will be born anymore.
(Unless the complete population of the City is also "European")

Those UnitTypes can be "born" (by Population Growth - depending on actual Population):
...
Also we have a special cases for "Child Unit" with some random:
(Will be configurable in the XML.)

European + Mestizo:
(Their "social status" but ethnicity are not sure.)
  • 50% Chance : European --> "born free"
  • 50% Chance : Mestizo --> "born disadvantaged"
Converted Native + Mestizo:
(Their "social status" but ethnicity are not sure.)
  • 50% Chance : Converted Native --> "born free"
  • 50% Chance : Mestizo --> "born disadvantaged"
Freed Slave + Mestizo:
(Their "social status" and ethnicity are not sure.)
  • 50% Chance : Freed Slave --> "born free"
  • 50% Chance : Mestizo --> "born disadvantaged"
Converted Native + Freed Slave:
(They keep theirs "social status" but ethnicity is not sure)
  • 50% Chance : Converted Native --> "born free"
  • 50% Chance : Freed Slave --> "born free"
Native Slave + African Slave
(They keep theirs "social status" but ethnicity is not sure)
  • 50% Chance : Native Slave --> "born unfree"
  • 50% Chance : African Slave --> "born unfree"
Native Slave + Mestizo:
(Their "social status" and ethnicity are not sure.)
  • 50% Chance : Native Slave --> "born unfree"
  • 50% Chance : Mestizo --> "born disadvanted"
African + Mestizo:
(Their "social status" and ethnicity are not sure.)
  • 50% Chance : African Slave --> "born unfree"
  • 50% Chance : Mestizo --> "born disadvanted"
----

So the main difference to PTSD is only this:
I will make the complete System XML configurable.

Why use two units? The Settler unit already is displayed as a man and a woman so you would not need to calculate offspring type by using two parent units, just the percentage of units in the city. Because if not - would the exact two units you used to determine the offspring then stop being used for the next offspring created?
 
I need to know the "Parents" to know the "Types of Children" the feature can spawn at all. (Which are valid.)
The amount of different "Parents" will be used to calculated the chances for specific "Types of Children".

Summary:

I need to know what is valid as well. ;)
And I will also calculate chances for certain Parent Combinations getting a Child.
Depending on how often I find that Parent Comibination.

----

You most likely fully misunderstood me though.
I never said I need to have 2 actual Units.

so e.g.:
Just 1 Free Colonist in City:

--> validChildren[0]: Free Colonist
--> Chances for validChildren[0]: 100%

The algorithm will always create a pair of data:
valid Child + its chances to be born
(And to do so, it will check parent combos / how often it finds them.)

I am just checking the available UnitTypes and how often I find specific combos.

----

Do not worry though about the algorithm, it is not that difficult. :thumbsup:
This is just "programmers stuff". :)
 
Last edited:
Note :
Population Growth in Col is based on FOOD, not on sex ... To get only white free colonists as offspring the player just have to transport all food to a pure european settlement to realize the population growth there.

Do you plan to change the concept : Food = Population Growth?
 
Population Growth in Col is based on FOOD
Who said that it is not going to stay like that ? :confused:

My algorithm will not influence how often your population grows / how much food you need.
It will only influence which Unit it will generate. (So it will simply not always be "Free Colonist" anymore.)

I was not going to replace the food algorithm by some "sex algorithm".
But wait a minute, that might actually be interesting ... :think: ;)

Do you plan to change the concept : Food = Population Growth?
No, I do not intend anything like that. :thumbsup:
 
Last edited:
Did you read the part with "transport all food to a pure european settlement" ???
 
Did you read the part with "transport all food to a pure european settlement" ???
No sorry, I had not. :blush:
But I did now. :thumbsup:

And yes, if a player wants to use that as strategy I have no issues with it. :dunno:
If he puts efforts into it by investing transportation capacity that is perfectly fine - I see no exploit there.
I actually always like if players adjust their strategies and gameplay according to new features.

I consider it actually a bad and inefficient strategy though. :confused:
A player would have too much effort (in terms of losing time with Unit movement and lost transport capacity).
But if he really wants to take the time to "sort colonists in certain Cities" and move all that Food around ... :dunno:
 
Last edited:
Population costs in food are not fixed ... they vary between 400 and 600 on marathon, depending on the colony's buildings, health, etc. ... so moving full loads of food to a colony with low population costs is a valid strategy ...
 
... so moving full loads of food to a colony with low population costs is a valid strategy ...
But again, that is perfectly fine for me. :thumbsup:
  • He needs to invest transport capacity that he can not use otherwise.
  • And he also needs to move around his colonists to "sort population in Cities".
If a player wants to use this as strategy I have no issues with it.
(I simply would not do it myself. I really consider this a bad strategy.)
 
I'm trying to figure out how this would work from a logical (coding) perspective. I think that will make it more clear what the idea is and if we agree on the approach.

  • each UnitInfo has a growth unit
  • on colony growth, two random citizens are picked (can be the same twice as that covers 1 pop cities)
  • 50% chance of each growth unit being produced (skip if it's the same)
  • add a new xml file, which lists combos, which results in something other than 50% chance of each growth unit
  • the xml file should have an InfoArray to declare unit and chance, allowing other than 50-50 or just two units
I think that would cover what you aim for, is fairly easy to set up in xml and doesn't suffer from xml restrictions. Performance is not an issue here as unit growth doesn't happen thousands or millions of times every turn.

It would likely make sense to use UnitClassTypes rather than UnitTypes though as this will make the code even more generic for future expansions.

I will make the complete System XML configurable.
This should be a goal whenever possible.
 
I'm trying to figure out how this would work from a logical (coding) perspective.
Please let me explain from the beginning, my algorithm / logic works completely different ...
(And thus I want to create a new XML for it that configures it.)

There is this new XML:
Civ4PopulationGrowthInfos.xml

It will look something like this:
Spoiler :

--- --- <PopulationGrowthInfos>
--- --- --- <PopulationGrowthInfo>
--- --- --- --- <Growth Text> Some Text </Growth Text>
--- --- --- --- <ParentUnitClass1>Unitclass 1</ParentUnitClass1>
--- --- --- --- <ParentUnitClass2>Unitclass 2</ParentUnitClass2>
--- --- --- --- <ValidChildren>
--- --- --- --- --- <ValidChild>
--- --- --- --- --- --- <ChildUnitClass>Unitclass 3</ChildUnitClass>
--- --- --- --- --- --- <iBirthProbability>50</iBirthProbability>
--- --- --- --- --- </ValidChild>
--- --- --- --- --- <ValidChild>
--- --- --- --- --- --- <ChildUnitClass>Unitclass 4</ChildUnitClass>
--- --- --- --- --- --- <iBirthProbability>50</iBirthProbability>
--- --- --- --- --- </ValidChild>
--- --- --- --- </ValidChildren>
--- --- --- </PopulationGrowthInfo>
--- --- --- <PopulationGrowthInfo>
--- --- --- --- <Growth Text> Some Text </Growth Text>
--- --- --- --- <ParentUnitClass1>Unitclass 1</ParentUnitClass1>
--- --- --- --- <ParentUnitClass2>Unitclass 5</ParentUnitClass2>
--- --- --- --- <ValidChildren>
--- --- --- --- --- <ValidChild>
--- --- --- --- --- --- <ChildUnitClass>Unitclass 6</ChildUnitClass>
--- --- --- --- --- --- <iBirthProbability>25</iBirthProbability>
--- --- --- --- --- </ValidChild>
--- --- --- --- --- <ValidChild>
--- --- --- --- --- --- <ChildUnitClass>Unitclass 7</ChildUnitClass>
--- --- --- --- --- --- <iBirthProbability>50</iBirthProbability>
--- --- --- --- --- </ValidChild>
--- --- --- --- --- <ValidChild>
--- --- --- --- --- --- <ChildUnitClass>Unitclass 8</ChildUnitClass>
--- --- --- --- --- --- <iBirthProbability>25</iBirthProbability>
--- --- --- --- --- </ValidChild>
--- --- --- --- </ValidChildren>
--- --- --- </PopulationGrowthInfo>
--- --- --- ....
--- --- </PopulationGrowthInfo>


It will only be applied for Colonial Nations / Kings.
(Natives will not use it.)
 
Please let me explain from the beginning, my algorithm / logic works completely different ...
(And thus I want to create a new XML for it that configures it.)
How is that different from:
  • add a new xml file, which lists combos, which results in something other than 50% chance of each growth unit
  • the xml file should have an InfoArray to declare unit and chance, allowing other than 50-50 or just two units
The main difference is that you list parents while I would list the default child from said unitinfo. 20 units results in 20^2=400 combos, though if we assume A&B to be the same as B&A, then it's around 200 instead. It's still quite a lot of xml data to fill out and in reality there are way more than 20 units. Using the default growth unit, UNITCLASS_COLONIST (free colonist) would cover most and we would have a more realistic amount of combinations. I also added that if the combo isn't mentioned in xml, it's assumed to be 50% chance for each as this will reduce the need for xml entries even further.

It will only be applied for Colonial Nations / Kings.
(Natives will not use it.)
I would say let the natives use it. Natives will always have two of the same parents meaning 100% chance of the same. The end result will be the same, but by letting the natives use it, the DLL won't have restrictions and the code will be less complex.
 
20 units results in 20^2=400 combos,
Actually you are right. :think:
All the "Experts combos" would need to be set up like that as well ...

But the problem is, that you can not say:
(Because ethics also mix.)

Unit A -> Unit A

Thus it is really about Combos:

Unit A + Unit B = Unit A (50%) / Unit B (50)
Unit A + Unit C = Unit A (50%) / Unit C (50)
Unit A + Unit D = Unit E (100%)

See the Problem?
We really need a System to reflect thos Combos.

A child is not defined by biologically just one parent.
It is always both parents you need.
(And they are not always of the same ethnicity.)

----

But actually we can indeed handle it at the Units. :thumbsup:
So my new XML will not be needed.

All I need to do is just checking / comparing flags,
Which will probably be more performant as well. :)

So those are the flags I need. :thumbsup:

Parent Perspective:
  • bIsEuropean
  • bIsConvertedNative
  • bIsFreedSlave
  • bIsAfricanSlave
  • bIsNativeSlave
  • bIsIndenturedServantOrCriminal
  • bIsMiztec

Children Perspective:
  • bCanHaveEuropeanParent
  • bCanHaveConvertedNativeParent
  • bCanHaveFreedSlaveParent
  • bCanHaveAfricanSlaveParent
  • bCanHaveNativeSlaveParent
  • bCanHaveIndenturedServantOrCriminalParent
  • bCanHaveMiztecParent
 
Last edited:
I was not going to replace the food algorithm by some "sex algorithm".
But wait a minute, that might actually be interesting ... :think:

Well that "sex algorithm" was the way I understand it at first too. :D

To replace the existing easy food based population growth with something like this concept:
- makes things complicated (manage another aspect - jet not big deal)
- cost time and effort to implement -> while there are at least 2-3 dozen more important concepts

So I don`t think worth it for replacement of food based pop. growth. At most can be done in a quite distant future.

In the other hand if it becames another pop. growth feature ("sex algorithm" ) -> instead to complicate a simple existing that can put possible priority from very low to somewhere into the middle (still there are many far more important concepts).
 
still there are many far more important concepts
True, but I also did not say this is my "highest priority". :)

But it is also not even that much effort either. :dunno:
There is e.g. no special AI logic that needs to be implemented.

It just needs some XML attributes and and algorithm.
(Can most likely easily be done in a weekend.)

----
while there are at least 2-3 dozen more important concepts

Please let us modders decide about our own prioritities. :thumbsup:
 
So those are the flags I need. :thumbsup:
That's hardcoding the types. It would be better to make it truly xml based.

But the problem is, that you can not say:
(Because ethics also mix.)

Unit A -> Unit A
That's not what I proposed. I proposed adding a growth unit tag (or child unit tag or whatever it should be called). Your proposal for a new xml file is fine. It should however use the growth unit rather than the unitclass of the parent. That way all the experts will be listed once because they all have free colonists as growth units.

I then proposed an optional addon, which would be if the combo of two growth units is not explicitly listed in xml, then it will be assumed 50-50. If both growth units happens to be the same, the result is obviously the same.
 
I proposed adding a growth unit tag
Maybe it is easiest you suggest a simple prototype XML structure to discuss it. :thumbsup:
(Discussing with examples is always easier.)

That way all the experts will be listed once because they all have free colonists as growth units.
Not really because they can mix with other Units if other ethnicities like "Native Slaves" as well.
(In that case they are not different than the normal "Free Colonist" -> simply a "European")
 
Back
Top Bottom