We don't have a complete model of how nutrition, sanitation, medicine, etc affect popluation growth... Is that what you mean by us not having a model for population?

In terms of demographics there has been some discussion (in the govt/econ thread). This covers percentages of population that are upper, middle and lower class. Axi's spreadsheet also has a model (not necc. accepted yet) of how these percentages change with time.

If you get busy in all those issues simultaneously, you're gonna mess up bigtime.

Population is a very tricky thing. Almost every model messes with population and almost every model lead has made hard decisions about it. To write a "population model" in a jar, without previously checking out it's implications would be wasted time. One must proceed very carefully and in good coordination with the rest of the team.

As far as I know:
1) Mark's econ model relates population growth with excess food production.
2) The govt/econ interconnections part we are currently discussing adresses income and class distribution of the population at a province level.
3) F_Smith's Object Builder (which is important, since it's coded already) for the time being counts population as a data element at the square level, but nothing more.
4) Rodrigo's social model is until now lacking the Migrations submodel.
5) TK's disease model will probably provide quite alot of modifiers for pop growth and overall population health, but I'm not very familiar with it.

By "demographics" I meant ages, not social status. Sorry for the misunderstanding.

I think we do need to do some tracking of ages. At the very least we should define what percentage of the population consists of minors who are not working or reproducing. If we don't do this, we could easily get a situation where the workforce doubles in ten years with no immigration. This happened in Lords of the Realm 2, and it made the game look pretty silly.

axi: I think your post demonstrates the need for someone to make a unified population model. If everyone has their own way of doing population, there will be a big fracas when the models are put together.

Anyway there are lots of models that could really use kept tracking of atleast the basic 3: Children, Adults, Aged. Why is this nessary? You can't compute population explosions like the 'baby boomer' episode in America and the cycles of them having children when they come of age without this. There are other reasons such as for work force, military force consciptions, etc.

This proposal outlines a model that can be used to define any race and track the demographics of that race through age-based cohorts. By demographics, I mean the characteristics of the age based cohorts. I will outline the race creation process, the system for defining the characteristics of the race's cohorts, and some of the equations used to change the cohorts over time.

I think that the population system outlined here will quickly provide relevant population information to be used by the social, economic and military models. Hopefully, it is flexible enough to handle any turn length and can be used to create different races for any science fiction or fantasy scenario.

That said, this is a first draft and it probably has some bugs. Input would be greatly appreciated, as this is a new model and it will impact a lot of the game.

Race Creation Process

The first thing that must be defined is the way the members of the race are created. There are three options: Reproduction, Manufacture, and Derived.

Reproduction will be the most common. Here, the size of the first cohort depends on the reproductive percentage of the other cohorts. This will be detailed later, in the cohort characteristics section.

Manufactured races are produced in factories. Androids in a science fiction scenario or golems in a fantasy scenario are examples of manufactured races.

Derived creation depends on another race. If a member of the first race has died, is about to die, or reaches a certain age, it could be turned into a member of the second race. Examples include zombies or ghosts in a fantasy scenario and cyborgs (created from terminally ill or critically wounded patients) in a science fiction scenario. This could also be used to model metamorphosis or evolution.

Note that it is possible for members of a race to created in more than one of these ways; A derived race might also reproduce.

After the creation method is selected, the cohort size is assigned. The cohort size is the age span that will be assigned to one cohort. The scenario maker assigns the cohort size of a Reproduction race, but the cohort size must evenly divide into or be a multiple of all turn lengths. If the turn length started at five years and then went to two years, the cohort size could be one or ten years but not two or five years.

Manufactured races must have a cohort size equal to some multiple of the length of the economic turn. Derived races must have a cohort size equal to the cohort sizes of all originating races. (If there are multiple originating races, they must all have the same cohort size.)

Cohort Characteristics

This is where the majority of the characteristics of the race are assigned. Each cohort has the following characteristics:

Number and Age Bracket
Gender/Type
Method of creation
Base Mortality and external impacts on mortality
Base Economic Potential and external impacts
Base Military Potential and external impacts
Base Reproducion Average (if applicable) and external impacts

The external impacts mentioned above will be equations based on the other game models. There will be many of these, and some examples are: Technology and infrastructure levels will impact mortality. The economic potential of certain cohorts is adjusted by your civ's view of child labor or the proper retirement age.

The cohorts are numbered for computational purposes and assigned age brackets for interface purposes. The age brackets are based on the cohort size defined earlier. If the cohort size was five, then Cohort #1 would be ages 0-4, #2 would be 5-9, #3 would be 10-14, and so on.

A race can have one or more sets of cohorts based on gender or type. Each set of cohorts is tracked seperately and has different characteristics. Manufactured races would probably have one set, humans would have two, and hive insects could have as many as half a dozen sets of cohorts representing different types of individuals in the species.

The method of creation will define how population is assigned to that cohort. The first cohort of the race (Cohort #1) will have the most complex definition, and all other cohorts will usually have their method of creation defined as: aging from the previous cohort.

Mortality defines the percentage of the cohort that dies before becoming a member of the next cohort. In the standard game, the Base Mortality percentage assumes a healthy agrarian lifestyle, primitive medical care, and no major epidemics or natural disasters. An average level of disease and accidents is included.

Unsafe jobs and crowded, unsanitary conditions will increase mortality while technology and better infrastructure and medical care will decrease it. Disasters, plagues, and war are seperate events that will take effect before the population model runs its equations.

Economic Potential defines the average labor that one person in the cohort will provide. An economic potential of 1 is defined to be the labor that a healthy adult working X hours a week can provide. The economic potential of a cohort is altered mainly by social attitudes, work hours, and health. It does not include unemployment, but it does include people who do not want to work.

In the equations section, I will explain how this number produces the labor L available in a square.
(Mark, I need you to decide what X should be after you go over the rest this model. I think it should be somewhere around 40)

Military Potential defines the quantity of soldiers that the cohort can willingly provide. It is the probability that a person in the cohort will make a willing, medium quality soldier. It includes voluntary enlistment and a small level of conscription. It is possible to draft beyond the military potential, but the people will not like it and the soldiers will not be as good. This attribute is altered mainly by social attitudes and health. In the equations section, I will explain how this determines the size of the military force that can be raised without excessive drafting.

Reproduction Average is the average number of children that a person in the cohort will have. It is altered mainly by social attitudes.

Other Racial Characteristics

The scenario writer can define additional things that make a race special. These should be innate characteristics, not things that could be covered by the social model. Also, they should not duplicate things that were covered in the cohort characteristics section.

Equations

Convention: V represents a calculated value. In a multistep calculation, there will be many V values, designated V1, V2, and so on.

These equations are run at intervals based on turn length and cohort size. They are run every C years in the game timeline, where C is the cohort size. If the cohort size was five years and the turn length was twenty years, the equations would be run four times per turn. If the game switched to one month turns, the equations would be run once every sixty turns.

Obviously all of the equations cannot be run at the square level. They will be run at higher levels and the square data will be inferred from these calculations. There are four options for the level at which the population equations will be run:

By civilization (least detail)
By social group (good for modeling the effects of the social model)
By province (more detailed, but does not differentiate between different social groups)
By province and social group (maximum detail and accuracy)

If the civ or province option is chosen (no seperate tracking of social groups), then the social attributes are determined by a weighted sum based on social model data. If social groups are tracked seperately, then each social group uses its unique attributes determined by the social model.

The creation equation describes how population fills the cohort:

First Cohort, Reproduction: The modified Reproduction Average for each cohort is multiplied by the population of each cohort. The results are summed and the result is the population of the first cohort.

First cohort, Manufactured: Economic outputs from the previous X turns, where X is the cohort size divided by the turn length.

First cohort, Derived: This can depend on many things, including technology and data from the originating race.

Subsequent Cohorts, normal calculation for all races: The population of the previous cohort is multiplied by the adjusted Mortality of the previous cohort.

Special cases could result in equations similar to the equations defining the first cohort of a Derived race. For example, genetic engineering could add population directly to the fifth cohort of a Reproduction race.

The Economic Potential is used to calculate the manpower available in each square as follows:

For each cohort, the number of people in the cohort is multiplied by the the modified Economic Potential of the cohort. The resulting values are summed to provide V1, a measure of the total labor available in the population.

V1 is divided by the population to provide V2, a number representing the percentage of workers and the amount of work they will do.

The population of each square in the province or civ is multiplied by V2 to provide the labor available in the square. This L value is inout directly into the economic model calculations.

If social group values and populations are tracked seperately, then these values will be found for each social group. The V2 values for each social group will then be multiplied by the population percentage of that social group. Then, these values are all added together to get the number used to calculate L.

The Military Potential values determine what cohorts the soldiers will come from and how many soldiers are available without causing social problems. The relevant calculations are:

The Military Potential of each cohort is multiplied by the cohort's population to determine V1, the number of soldiers that will come from the cohort.

These values are added up to determine the total recruitment V2. Each cohort's V1 is divided by V2 to get V3, the percentage of soldiers that come from each cohort. Each V3 value is stored until the next population recalculation.

In the case of excessive drafting, soldiers are pulled from the cohorts in the same ratio defined by the previous calculation. If this causes all of a cohort to be drafted, a highly unlikely situation, then no more conscription is possible.

Soldiers are not removed from the population until they are killed. For each cohort, the number of military deaths is multiplied by V3 to find the number of people to be removed from that cohort.

Order of Calculation

There will be deaths every turn, but this model will not always run every turn. All civilian deaths due to disaster and war are assumed to be spread equally over all of the cohorts. (If a cohort has 15% of the population, it will suffer 15% of the losses) This way, the ratio of the populations in the cohorts stays the same.

Disease is different. It has different effects of different cohorts. These effects are baased on the adjusted Mortality of the cohorts. Cohorts with higher Mortality, like children and elderly, will get hit harder by disease. I will have to work the exact details out with Toubado_Koomi.

Like other types of death, war deaths will also happen every turn but their effect on the demographics cannot be calculated until the model is run. Demographic data is only updated every C years.

When people die every turn and the model is not run every turn, we could run into problems. A possible solution is as follows:

The calculations run in the model are assumed to be a summation of the previous C years. Therefore, we can assume that the deaths happened in the middle of the C year time span.

The total number of deaths per cohort is calculated. Half of these deaths are taken out before the calculations, the model runs, and the other half are taken out of the new cohorts.

After thinking about this solution, I have decided that it should work but I have no way of mathematically proving that it will give good data. This is the weakest area of the model, so if someone else has a better idea here it would be appreciated.

Couple things about the model though....eventually any type race could repodruce itself, including manfactured and derived, though manufacted would obviosuly be differnt.

Also, nothing on here for creating cross-breeds....maybe that's just too technical, but i'd like to see it.

There is one cohort per gender. As age is not tracked, there is no need to limit the calculations to the proper times. The model is recalculated once per turn, regardless of turn length.

The cohort has the same data and uses the same calculations as the cohorts in the full system. The figures are averaged out over the entire age span of the population.

There are two changes to the equations:

The Mortality and Reproduction Percentage are based on a time period of one year.

The turn time is taken into account by multiplying the Mortality and Reproduction Percentage figures by the turn length in years.

Would this work for the simple system?

This is my first attempt to create an object oriented model implementation. Hopefully it will help me understand the OO and Java concepts. Of course, I will need correction and feedback for this to work, so if you know about OO design please help me with this.

The Object Classes:

Population
RacialCharacteristics (optional)
Cohort
Mortality
EconomicPotential
MilitaryPotential
ReproductionAverage
MapSquarePopulation

The population object class is essentially a collection of cohort objects and general population characteristics. It should have functions that calculate the population's Economic Potential percentage and recruitment percentage data based on cohort data. It should also define how often the model is recalculated.

The Cohort object class is the central focus of the model. In addition to containing the four classes thet define population characteristics, this class stores the following data as primitive classes: cohort number and age, cohort type/gender, and cohort population.

I'm not sure, but it seems that Cohort could be a Base Class and specific types of cohort, like Male Cohort #3, could be Derived Classes.

Each cohort class must also have a Cohort Creation function that is called whenever the demographics are recalculated. This function uses data from the Mortality or RA objects from other cohorts.

The Mortality, EconomicPotential, MilitaryPotential, and ReproductionAverage object classes store and recalculate data about the Cohort objects. They all require data from the other game models. Each Cohort object needs these objects. I haven't been able to figure out the technical terms for this kind of hierarchy.

Each mapsquare has a MapSquarePopulation object associated with it. This object class stores the population of the square and the Labor available in the square as primitive objects. Te class should also have equations that determine these two numbers based on the data from the Population object.

I think it's great, you jumping into this.

It'll be easier to learn than you think. It's almost impossible to master, I still feel like I've got so much to learn. But the basics take mostly a new way of looking at things.

Anyway -- I think you're pretty close, altho if I may make a few translations into geeky 'OOA' jargon:

• Population EthnicGroup
  
  
  
  • Ethnicity Culture,
    
  • Cohort One
    
    
    
    • Gender vals
      
    • Age vals
      
    • Number of individuals
      
    • Mortality
      
    • EconomicPotential
      
    • MilitaryPotential
      
    • ReproductionAverage
      
    
    
  • Religion
    
  • Group Tendencies
    
  • Other Attributes
    
  
  

The italics is what I've named those classes in my object builder. This is the object structure that the beast uses.

The only difference is I have the 'number of individuals' currently in the Population/EthnicGroup 'parent' class. But that's the beauty of this OOD componentized approach -- all I have to do is 'disassemble' this number, and reassemble it when I need it. Store the pop info in the 'cohort', and loop thru and add them all up when necessary.

Only other difference is that I store this Population/EthnicGroup object at the mapsquare level, and keep it's group's number of individuals (population integer) in the same object. But you can store it at whatever level you want.

* * *

What I'm saying is, you did a great job of doing an OOA on your Cohort ideas. The sign of a good OOD is that it can snap into any similar system -- if you don't mind, I can easily 'snap' those Cohorts into my mapsquare level Population/EthnicGroup object to test it. You can, later, only use the object only at the Civ level.

And that definition of 'Cohort' you have there is very good. With this, I can code this up in an evening or two, and be testing by next weekend.

A few terms you might like to know:

The 'Population' object 'encapsulates' population characterists, and a collection of 'Cohort' objects. Each 'instance' of a
'Cohort' in this collection will have it's own, distinct 'encapsulated' data. And the 'Cohort' object has 'dependencies' on data from several other models.

Or am I totally off my cap?

* * *

I'm not sure what you mean by 'function calls'.

The 'methods' necessary actually define themselves:

public void setThis(Object this);
or
public void addThis(Object this);
depending on which makes most sense

public This getThis();

For each object an object 'encapsulates'.

So, for Population, you'd have

public void setEthnicity(Ethnicity e);
public Ethnicity getEthnicity()

public void addCohort(Cohort c);
public Cohort getCohort(String name);

In Java, it's 'methods', which is the java equivilant of a 'function', altho it has to be tied to an object.

The equations come in another piece of code, after the data is all arranged.

The object hierarchy in your post looks good, but it is only one of the options I had hoped to have in the model. I wanted to be able to give the player the options of running the model at either the civ or province level. I also wanted the option of not tracking the ethnic groups seperately.

So there are four possible hierarchies:

CivPopulation, Cohorts
CivPopulation, EthnicGroup, Cohorts
CivPopulation, ProvincePopulation, Cohorts
CivPopulation, ProvincePopulation, EthnicGroup, Cohorts

I know it is easy to rearrange the hierarchy during the programming process, but does Java have the ability to change this hierarchy at run-time? If not, we will have to agree on one default game setting out of these four.

I am attempting to turn the following equation into a Java method. Please don't laugh:

First Cohort, Reproduction: The modified Reproduction Average for each cohort is multiplied by the population of each cohort. The results are summed and the result is the population of the first cohort.

public int Births(CohortTwo.ReproductionAverage, CohortTwo.Population, CohortThree.ReproductionAverage, /*and so on/*){

arg1*arg2 + arg3*arg4 + /*and so on/*

We'll be using several tricks to allow pop info to be run at one of several settings 'on the fly', at game time.

First, we'll use 'state triggers'.

The player selects the gametype they want, which sets 'triggers' that store 'gamestate' (booleans like pop_at_prov = true, usually).

We'll likely be doing this for a variety of reasons, from grafix detail to AI settings.

Then we either store all the info at the lowest level and build it up when needed (element-atom-molecule approach) or we give each level it's own 'population' objects collection and only use the one required.

* * *

I'd likely code it like this:

In the 'CohortTurnHandler' class:

code:

---

public int yearlyBirths(Enumeration cohorts)
{
     int total = 0;     
     while(cohorts.hasMoreElements())
     {
          Cohort c = (Cohort)cohorts.nextElement();
          total += c.calculateBirths();
     }
     return total;
}

---

Then, in the 'Cohort' class, you need the method:

code:

---

private int calculateBirths()
{
     return this.getPopulation() * this.getReproductionRate();
}

---

Now, 'Enumeration' is just one possible method for looping thru a bunch of things. The newer 'Iterator' is even better. Or they can be stored in an object array. Or a linked-list. Whatever.

The idea is, tho, that a 'collection' of 'Cohort' objects is passed to the method, and they are looped thru one at a time. Then each 'Cohort' tells you it's births (the calculations for Cohorts should always take place inside class 'Cohort').

F_Smith:

I don't understand the complex stuff like enumeration and I probably won't for a while. So, let me try something simpler, like the method for determining the population of one of the later cohorts:

The cohorts after the first one have their creation method defined as aging from the previous cohort. Their population is the population of the previous cohort times the mortality of the previous cohort.

In the Cohort class:

public int aging(PreviousElement)
{
return previous.getPopulation * previous.getMortality
}

Could you correct that syntax?

code:

---

public int processAging(Cohort previous)
{
     return previous.getPopulation() * previous.getMortality();
}

---

In that case, the Cohort class would look somthing like this:

code:

---

public class Cohort
{
     private int number_of_individuals;
     private int mortality;
     
     public Cohort(int n)
     {
          setNumberOfIndividuals(n);
     }
     private void setNumberOfIndividuals(int n)
     {
          number_of_individuals = n;
     }
     public int getNumberOfIndividuals()
     {
          return number_of_individuals;
     }
     public void setMortality(int m)
     {
          mortality = m;
     }
     public int getMortality()
     {
          return mortality;
     }
     public void doAging()
     {
          return getNumberOfIndividuals() * getMortality();
     }
}

---

To avoid confusing you (I'm sure there is a typo), when F_Smith wrote:

code:

---

public void doAging()     {
    return getNumberOfIndividuals() * getMortality();     
}

---

I think he meant:

code:

---

public void doAging()     {
    number_of_individuals = getNumberOfIndividuals() * getMortality();     
}

---

since a void method in the first example can't return anything by definition. Although in my stab at it mortality seems to have the opposite from the usual meaning... So perhaps it should be -= to subtract mortality*pop from population.

Mark is exactly right.

Sorry.

quote: Yeah, oddly enough the 'population' model, the very first, most important model that the entire rest of the game will be built on, was not done.

That was written by F_Smith in the social model. He started coding the Object Builder about a month before I did the population model. He seemed to like my population model, so I figured it would be put in.

By the way, I didn't know that F_Smith had written a population model when I made this. He never said that he had a population model when I created this thread. This would be yet another example of a communication problem.

I think it is because F_Smith believes that to do the game right you need to OO model the real world. I believe that you simply need to OO model the 'game' world. I characterize the game world as an internally consistent view of the world in the game. The game world does not necessarily match the real world. In this example, I consider modeling just undifferentiated people as acceptatble for a game. He (and I think you) don't.

The problem is, my experience in building similar data systems suggests to me that the existing architecture in the Demo 4 code would not work for a full game. It was not scalable, for a variety of reasons -- in my opinion.