quote: At the very least we should define what percentage of the population consists of minors who are not working or reproducing

Minors who arent reproducing? You mean that people wont have sex until they are 18? Now we're talking about something SLIGHTLY unrealistic!

(This was intended as a joke. You do not need to tell me that this would be too hard to implement.)

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.
  

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.

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

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.

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.

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.
  

Does that explain it?

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:

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.

2. 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.

3. 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.

4. 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.
   

Outstanding. Really, Richard. That's one of the most concise and useful test cases I've ever read. I can work with that. That's a perfect test case. You win the cookie.

I love the definitions at the top of the case, too. That way, I don't have to go look up anything, it's all there.

Okay. I'll code this up starting tonight. Once I produce the first alpha in a day or three, ya'll are going to have to be available to bang around on it and tell me where I screwed up, so don't go to Fiji or anything (unless you take me with you).

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.

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

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.

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.

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.

A couple of points regarding your tests related to the social model:

1- Please forget about the fertility vs celibate thing for the moment. I consider it a detail and I would never include it. Of course some day in the future we can talk and see if we want it, but since I don't have anything like that in the social model and you'd push me to include it with your test, I ask you to please leave it.

2- Your model should look at EG's cultural profile and not to religions directly. Culture already takes into account religion factors, so the correct way to do it would be IMO to look at culture values.

3- Aggressiveness (0-100) is the cultural attribute your military fitness factor should take into account.

4- Individualism and/or Asceticism (both 0-100) are the attributes you should use for your EP variable.

My opinion: The model looks great for what it was meant to be. That is, it allows huge flexibility and the possibility to play very detailed games, sci-fi stuff and so on.

My pick for the default game: Mark's choice.

The one thing I'd get rid of: "Derived" races. I think it will show to be hard to model in terms of equations. Just a guess.

Rodrigo, is there any combination of existing cultural attributes that could be used to determine birthrates?

I think we should go ahead and make and test the detailed system now, even if we will probably decide to use the simple one on the default game.

Perhaps we could have the following demographics detail level options in the game:

0: No demographics, for battle scenarios
1: Simplistic headcount system, like civ2
2: One cohort, medium functionality
3: One cohort per gender, full functionality
4: Full Multi-cohort system

Of course, this system allows people to design any detail level they want for scenario purposes.

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

This is actually exactly how it is done in epidemiological research. It works - it is not weak!

I see a potential problem in running gender-specific cohorts. The reproductive capacity of one cohort would then depend on what is going on in other cohorts (enter doctor modeIn general terms it takes a man to get a woman pregnant, you know exit doctor mode ). So if all male cohorts were empty, female reproductive capacity would be zero. IOW: It is without meaning to asign a reproduction average of females; it depends on the number and reproduction average of males. How to put it OOwise: The data is not encapsulated?
One way of solving this is to assume that females mate males of a similar age, combine them into one cohort, and give a description of the gender distribution in the combined cohort. The reproduction would then be determined by the number in both sexes. If you want to model gender specific mortality, you would have to have a male-mortality and a female-mortatlity. And similar for other variables you would like to be separately modelled for each sex (like military and work-force). I realise that this is not as flexible as the system with gender-specific cohorts, particularly if you want to have more than one 'gender' or type (the insects).
Another way around this is keeping the gender-specific cohorts, but making reproductive capacity an attribute of the population object in stead of the cohort object. It would then be calculated as a function of the mix of different cohorts. Just like the economic potential and the military potential.
Or we could put another layer in the object hierarchy, combining the two approaches: An EG has a mixcohort has a gendercohort. The mixcohort would then have methods of calculating a reproductive average based on a base reproduction number, and the relative distribution number of males and females in the gendercohorts. Overall reproduction is then calculated as before, based on the mixcohorts. Genderspecific values of military capacity etc could still go in the gendercohorts, and it would be relatively easy to add more 'genders'. For simplicity I would recommend that the newborn are divided equally between the two gendercohorts (IRL 51% of newborns are male, but boys have slightly larger infant mortality, so that when they reach their reproductive age the genders are of equal size).

Richard you mention that soldiers at no point will be taken out of the population. I think the recruitment of soldiers require some more thought. Sometimes a major part of the male population of a province would be assigned to military duty far away. It seems unreasonable to include them in the province-population. There are several implications of this, that we should address at some point, but now is probably not the time.

In general I like the idea of the full demographic model. It is detailed, but it is not detail that requires the attention of the player. Most of the time the demographic info will only yield flavor to the game, being outside the player's direct control. In terms of reproducing the effects of having large parts of the male population on a war footing it certainly has potential.

I was certainly planning on having births depend on both genders. Basically, the model would multiply the population and RA for each gender, and the number of births is the smallest value of the two. So if there are no males, then the smallest number is zero and nobody is born. I think this would easily give the proper result without mixing the cohorts or creating more objects.

Test Case #6, Births:

Allow the tester to manually alter the population and RA of the two genders and see what happens as a result. The model should give a reasonable number of births.

I already changed my mind about the soldiers. See test case #2. When I first built the model, I assumed that all soldiers would be garrisoned in their province of origin. But then I realised that was a silly assumption, so I decided to take them out of the population at unit creation.

Well, you "guessed" right. You have a perfect understanding of what's needed for a test case. Maybe your coding experience makes it second nature for you.

As far as equations, first do what you have there, exactly as you have in that 'test case 5' example.

That's perfect.

And yes, the editor will end up complete. You'll be able to define any game object in it.

I had a good, productive night last night. Another day or two, and we'll test play this.

Apart from this, I kept myself busy Playing SimCity 3000, which btw is not at all as complex as Clash will probably be. What caught my attention in SimCity 3000 is the dynamic relationship between population (workforce) and industry (jobs). Since people and industry are free to move in and out of the place at will, when the jobs are more than the workers, people move in and industry moves out. Because of the existant inertia in construction of residential and industrial buildings, this results to the opposite extreme; when workers are finally in, industry is already out. So the game keeps bouncing back and forth, giving me fluctuations of up to 40% We definitely don't want that to happen with Clash; fortunately Kapital is bound with population so (correct me if I'm wrong) this dynamic effect will no occur.

To the point now, which is a reply to the discussion about Labor computations: In the govtecon spreadsheet I had broken the 1-1 analogy between #of_people and L (labor units) by introducing WH (Working Hours) and l (labor per capita). I also had used AP (Active population percentage) to represent demographics. AP and WH were different for each SEC (socioeconomic class), resulting to a different l for each class (there was one base WH and AP for the LC and all the others were derived from it, with various modifiers such as EP, SP, SL). I had assumed an equal quality of work for everybody. All this would happen at the level where the econ model was run, for the specific EU (Economic Unit: civ, province or square).

The most straightforward thing to do (I feel F_Smith would agree with this) is make a computation for each EU*EG*cohort*SEC as follows:
Labor=Number*Active*Quality*Quantity
Number=Number of people in the given EU*EG*cohort*SEC
Active=f(BaseAP, SEC, EU)
BaseAP=f(EG, cohort)
Quality=c(EG)*c(SEC)
Quantity=f(BaseWH, SEC)
BaseWH=f(EU)

f is a given function each time (you can find the proposed functions in the govtecon spreadsheet), while c is a constant

Of course aggregations can be used too, if the computations are too heavy. So, what do you think?

Re genders

Sold

Re recruiting military units

Sorry I overlooked test case 2

But are you sure you want to model this at this point? It could easily be added later. (Looking over the shoulder: 'Right F_Smith?')

If we decide to model it now, we would have to decide what happens with the oldest cohort in the troops EG. They should retire from service at an appropriate age, and the ranks be supplemented with people in the lower cohorts.
In fact the lower cohorts should be 'derived' as a part of the general population's cohorts. The oldest cohort 'derive' into a matching cohort in the general population.
Should these recruits be taken from the square that the unit is in, from the square of origin of the unit or from somewhere else. And to where should we return the veterans.

I think we should postpone this! Demo 6 perhaps?

Rodrigo

I think the derived cohorts are much more useful than you think. See above.

Axi

Siiiim Ciiity Haaaaa Kids stuff compared to our undertaking.

For the multi-cohort plan, it is a little more complex. Every turn the demographics recalculates, we would take the people out of the military age cohorts and put them back in the older cohorts.

If a unit is supplied by the civ, it is in contact and can recieve reinforcements. And if it isn't supplied, it will collapse long before the soldiers get too old.

Given the timescale disparity, you would already have a certain group of soldiers roaming around for hundreds of years if they didn't have supply constraints. Alexander's campaigns took about five years, or sixty months. Assuming a five year economic turn, this means that his armies would be roaming around for 300 years by the economic clock.

Given that disparity, the population model can probably just assume that military units never age and are never replaced. Those Greek soldiers were not replaced by other Greeks and they didn't get much older. Soldiers are effectively put in stasis when they are created. By the time those Greek soldiers are ready to retire, someone could have put a man on the moon.

This could create some interesting situations. Suppose someone has an empire with a million people. They could could recruit a group of 20,000 soldiers every economic turn, as the demographics data recalculates the five year cohorts and easily replaces that 2% of the population taken away. After 100 turns or 500 years, they would have 100 military units, the oldest of which has aged about eight years.

If the player finished a war and then decided that the military units are no longer needed, that player would probably disband the troops and the soldiers would be added back to the population. At this time, the population would triple. There would be 2 million extra people instantly added to the workforce of the empire. These people would be healthier than average, so economic capacity would be multiplied by about five. Needless to say, this could seriously destabilize gameplay.

Other game effects protect from this possibility. There are good reasons why soldiers average to a max of something like 1% of the population over much of history. Feeding the troops and paying them consume a sizeable fraction of the budget of the govt if levels get above this. I think this will work out to be ok when the other models are implemented for the reason above and others.

quote: But it may be that soldiers at home should just be in equilibrium with the rest of the economy, and only enter 'stasis' when removed to go off and fight.

That is exactly what I am talking about. When soldiers are on the campaign trail they will be pillaging food from the other country and will probably be paying themselves by looting other places. Besides, they only need one month's worth of food and pay every five years, so your economy or the enemy's territory territory can support 60 times the fighting force it could historically.

At least, that was my impression when I read about the supply system in the mil model.