Population and Demographics

[F_Smith]

Richard:

Right now,

[*]the basic ethnic group objects are defined and coded. Altho more methods will need to be added to support the added functionality of 'birthrates' and such.
[*]the 'turnhandlers' for ethnic groups are defined and coded. There's a 'one year' method that currently only processes the EGs 'ideology' decisions. But this is where all the methods/procedures you're talking about will go.[/list]

So the 'framework' for the population model is in place. But no numbers have been filled in.

[F_Smith]

Richard:

Actually, I am of the opinion that your system should be rolled into the game code before any 'higher level' functions are. The entire game will rest on the population. So we should flesh out the 'ethnic group' object as fully as we can before moving on.

That's why I'm not moving on with the beast -- I'm going to have to make much of this up myself (and I know you don't want that!). For the govt model alone, demographics info is going to be needed . . .

[Richard Bruns]

Oh No! Anything but that!

Okay F_Smith, what do you need from this model? I'll see what I can work in.



Note to Mark: I am not willingly going over your head. As is plainly evidenced by the post above, my offer to work on this model before Demo 5 was made under extreme duress

[F_Smith]

I, too, would rather wait for Mark to decide if this is the direction he wants to move next.

But just so you can be thinking ahead, in case Mark agrees (or for whenever we do move this direction), we'll need to flesh out the 'ethnic group' object and turnhandler.

So first make as comprehensive as possible a list of 'behaviors' we will want the EG to have (aging, reproduction, etc). We'll define blank methods in the EG and turnhandler to support those functions, and determine when they get run.

Then, as the last step, we'll flesh out and add equations to those methods.

[Mark_Everson]

Sure, go for it. If I don't agree, F_Smith will spend so much time fixating and posting that this 'Vital' thing hasn't been done that it is probably a wash in time anyway... I Still don't understand why this is needed now, but I will just have to cope with lack of understanding. And it probably would be good for learning purposes to start on something relatively simple.

Just note, I have Not bought into all this complexity you (F_Smith) are proposing as anything other than optional. I'll have more to say about that subject in my post on overall project direction due tomorrow.

[This message has been edited by Mark_Everson (edited September 22, 2000).]

[Richard Bruns]

So we don't need the cohort objects and their functionality for Demo 5. The "population model" that is so vital bears no relation to the population model I wrote. Same name, different system. We can worry about this thing later.

[Richard Bruns]

So what is the decision? Should I be working on including this model?

[Richard Bruns]

Okay, I think that was a bug in the forum. Mark's reply on this topic was not listed until after I posted. Neither my browser nor the library computer's browser showed that this topic had a second page.

[Mark_Everson]

Hi Richard:

Sorry, I missed your simplified system way back when. I support the simplified system, although I would prefer to see a single cohort as the default. Combining male and female. Again it is an abstraction, but I don't think we need the extra complexity.

Like F_Smith says, for scenarios the multi-cohort version could be cool.

[F_Smith]

Richard:

I need you to work up 'test cases' for coding the pop model.

A 'test case' is a quick explanation of desired functionality. Something like

[*]People's production and consumption need to be calculated once per year.
[*]Production is calculated by dividing pi by the phase of the moon.
[*]Blah blah, bla bla bla.[/list]

Does that explain it?

I will code according to the test cases. When all test cases run, then the coding for the model is finished. Then, later, when we add other functionality, if we make any changes in this part we run these test cases again -- just to make sure we don't screw something up by accident.

[Richard Bruns]

F_Smith: Test Case Expert? Uh, okay, thanks, I guess. I never wrote one before; I was sort of guessing what to put down.

Mark: That functionality is already listed in the model, so I figured it would get programmed anyway. I didn't want to nag and accidently start another fracas I'll repeat it here for convenience:

Multi-cohort:

These [demographic] 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.

Single Cohort:

The model is recalculated once per turn, regardless of turn length.

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.

And here is some other timing info:

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

The [demographic] 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.

For more details, refer to the Detailed Model and the Simplified Model.

[Mark_Everson]

Richard:

I just emphasized the time thing as a test case since almost all the models will need this, and I wanted to raise awareness about it.

quote: 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)

Oops, missed that way-back-when

Well the econ system is based on subsistence L = 1 per head (1000 people) as a population average for a subsistence workweek, which is probably more like 60-70 hours per week. To have everything come out right we need estimates of age demographics and labor effectiveness for primitive agriculture at whatever workhours should be. For the simple model with all groups rolled into one, I guess I would take X as 60 hours or so. My take on it is that you should just start with whatever values sound right to you, and we will rebalance when the new econ model is producing and we can validate that what should be subsistence produces subsistence levels of food etc.

[Richard Bruns]

quote: 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.

For the single cohort simplification, EP equals V2.

quote: 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 input directly into the economic model calculations.

When I wrote this I thought that L=1 was meant to be the average work of one person. The L produced by the se calculations would have to be divided by 1000.

So if an EP of 1 means healthy adults with 65 hour work weeks, the average single cohort population EP in ancient times would be about 0.6, considering the sick, young, elderly, and non-workers.

So a square with 1000 people produces 0.6L. I don't think that's what we wanted. If we want 1000 people to produce 1L, the average population EP should be 1. For that to happen, an EP of one should be about 40 hours of work a week. Some cohorts make more, and some make less so it averages out.

Wow, that was a big, inintuitive mess. What was I thinking?

It would make so much more sense to simply define the "man-hours" produced by an average member of the cohort every week. Note that this figure still includes the quality of the work as well as the quantity. A child working 60 hours a week would probably give about 30 man-hours of work, so if two thirds of the children were working like this the cohort would provide an average of 20 man-hours per week.

That is a much simpler and more user-friendly way of doing things. We then have hidden routines that turn the various cohort work weeks into the L in the square. For now, we can assume that 1000 people working an average of 40 hours a week equals 1L.

F_Smith, is it proper for me to give you the equations or is the programmer supposed to implement them? Maybe I should just say:

Test Case #5, Labor Calculation:

Provide the L available in each mapsquare, given the average man-hours per week of the various cohorts. Allow the tester to vary this value for all cohorts to observe the results. Also allow the 40 hours figure to be changed as a result of these tests.

After this is completed, proceed to 4C above.

Note that this change affects test case 2. As military recruitment takes away the healthy workers, the average man-hours of that cohort will decline.

Quick and probably pointless note to F_Smith: Don't forget that plagues and any kind of ill health should reduce the man-hours available.

[Richard Bruns]

Sorry, double post.
[This message has been edited by Richard Bruns (edited September 27, 2000).]

[Richard Bruns]

I'll give the Population Glossary before talking about test cases so we know what all the words mean:

Population Model: The system that determines how many people are in every mapsquare, and what the demographics of the civilization are.

Demographics: General term for attributes of the population such as age, fitness for military duty, fitness for economic labor, birthrates, and mortality rates. There are four options for the presentation of this data to the player:

• Once per civ
• Once per civEG
• Once per province
• Once per prEG

Cohort: Any group defined with unique characteristics. These are used to define the demographics. There could be only one, one per gender, or one per gender and age group.

Cohort Characteristics: This is where the majority of the characteristics of the population is assigned. Each cohort has the following characteristics:

Number and Age Bracket
Gender
Method of creation
Base Mortality and external impacts on mortality
Base Economic Potential (EP) and external impacts
Base Military Potential (MP) 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

Number and Age Bracket: The cohorts are numbered for computational purposes and assigned age brackets for interface purposes.

Method of creation: Defines 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. An average level of disease and accidents is included.

Economic Potential: Defines the average labor that one person in the cohort will provide.

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.

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

Test Cases:[list=1][*] First, general playtesting is needed to define the proper numbers for various attributes. Allow the tester to try different base values to see which ones work well.
[*] Military recruitment should result in population being taken out of the mapsquares, and the demographic data is changed to reflest the loss from the workforce. EP and MP should both decline. If we use a multi-cohort system, troops should be taken from the proper cohorts (those with highest MP, typically 20-30 year olds).

Military disbanding should return these people to the population and restore the demographic data.
[*] Disasters and plagues should be tested. Since those models are not up yet, the tester should be allowed to create them manually. FE the tester could define a plague that killed 50% of infants for three years in a row. Then we observe how population and demographics change as a result.
[*] Social impacts on various parameters should be tested:

A) Define a fertility cult and a celibacy cult in the social model. The relative prevalence of these religions should impact the birthrates.
B) Define a pacifist religion and a warlike religion. Percentage of the population following these should impact MP.
C) Define a materialist religion and a meditative/spiritual religion. Amount of followers determines EP.[/list=a]

That should do for now. More complex stuff can be tested when the other models are more devloped.