Population Model

[nolongerinuse]

I will reply, I promise. Just haven't had the time to really respond.

Don't worry; we've all got jobs (or at least something that keeps us off the streets).

The basic factory interface looks nice and functional, and the same could work for labs and such, at least for now. Next up are starting a task of sorts, and displaying the current task?

I've been thinking about morale and such, as well as population death and jobs (mostly taken from other games), and I've got some idea's and basic lists ready for when you're going to start on that.

I also managed to check out your code using TortoiseSVN and take a peek using Visual Studio, and I read in person.h that individuals are not considered objects. Why is that, or what solution were you thinking off? I'm familiar with Python and the Matlab language, and have played around with Arduino's and such, so I can read C++ without too much effort, but I'm not yet familiar with C++ architecture, so I'm sorry if that's a dumb question.

[leeor_net]

The Person class is just a stub. I haven't done much with the population model. At the time when I built that class I wasn't sure if I wanted to go with a more sophisticated population model where each Person is represented individually or if I wanted to go with what the original game did which I'm pretty sure was just a bunch of numbers and not much else.

The more I think about it, the more I want each individual person to be represented with more depth than a simple number. So that stub class will be fleshed out better later on.

You should head over to our new Redmine installation (http://redmine.outpostuniverse.org/) and sign up. I'll add you to the OutpostHD project and you can start posting both in its Wiki and create new tasks to discuss these things. That way we can keep everything in one place.

[Hooman]

I kind of feel that individual colonists is a needless complication.

Unless perhaps you're designing Sims: New Terra.

[lordpalandus]

I agree with Hooman. Tropico games had individual citizens and it barely added anything to the game really. Not really in my opinion worth your time to invest in making citizens individuals.

[leeor_net]

Going with just numbers does simplify things... but then the following questions arise:

How do I know when a 'child' has matured into an 'adult'?

How do I know when that 'adult' has been in a university long enough to become a 'scientist'?

Should everybody just be a scientist after so many turns?

By fleshing it out I didn't mean that I wanted to give them names and lives and so on, just that it would probably make it easier to know when a colonist is born (e.g., age < 1), when they can be considered a working 'adult' (roughly 900 turns or so)... wait... that doesn't work off the bat. Going to have to work on what exactly the turns mean... in Outpost they were undefined units of time. In OutpostHD I wanted to equate them to roughly one week but to wait 900 turns for a single colonist to be useful is... excessive to say the least.

Still though, I would think something like 50 - 100 turns for infants to mature into productive adults and then from productive adults something like 100 or so turns in a university in order to become scientists. Would mean they would have something like a 500 to 600 turn life span not barring any environmental pressures (like disasters, food/water shortages, stress, etc.).

[nolongerinuse]

You should head over to our new Redmine installation (http://redmine.outpostuniverse.org/) and sign up.

Thanks, just did!

I kind of feel that individual colonists is a needless complication.

I might (might) disagree; having a pool of people is required, and the game would need to store certain values, such as gender, age, job, education. Putting those in a large matrix or a set of arrays could work, but it feels to me like that'd be kinda inviting indexing issues and limitations. Using a class of 'people' allows for easy-to-understand and relatable individuals (which should make the code easier to understand), while also allowing for a lot of freedom in terms of the data these individuals carry.

As a sidenote: I tend to track individuals in Tropico. I might be weird, but I like the stories behind the citizens, and there's quite a bit of depth if you're looking for it.

[nolongerinuse]

Simultaneous post!

but then the following questions arise:

Both solutions are still possible, and a massive matrix might be easy to implement, but I agree that these questions are easier to answer in individuals as objects. Giving them lives goes too far, but making use of the objects-within-a-class ability of C++ would be good here.

Going to have to work on what exactly the turns mean... in Outpost they were undefined units of time. In OutpostHD I wanted to equate them to roughly one week but to wait 900 turns for a single colonist to be useful is... excessive to say the least.

I did some thinking on that, especially considering the alien planet and physical stresses and such, and came up with the following as some base guesses:
0-16; child. No working. Thrown at a job at sixteen, because alien planet etc.
16-24; university, if available. Individuals don't have individual stats, so a constant period would be good enough.
24-60 (or 16-60, if no university was available), workin'. Death at sixty, due to the physical stresses.
A simpler solution could actually come from Tropico; allow individuals to do a study whenever they want, as long as the critical jobs are filled and there are universities available.
One turn per week amounts to (52 * 16 = ) 832 turns before adulthood, and (52 * (60 - 16) = ) 2288 working turns. No gameplay element there.
One turn per two months gets us some more useful values: (6 * 16 = ) 96 turns before adult, (6 * 8 = ) 48 turns of studying, and (6  *(60 - 16) = ) 264 turns of working.

[leeor_net]

And you're now activated.


For now I'll just do what Outpost did and have turns mean different things in different contexts. When I think about the construction of a building, 10 weeks sounds reasonable for some buildings and 4 weeks sounds reasonable for other types. Especially when you consider how fast we're putting up structures these days. Granted alien environment but with robot assist and structures that are already designed, parts can be fabricated pretty quickly especially if there are a lot of universal parts.

As for the population, I'm going to stick with using a Person object to represent an individual. It just makes sense to me. They don't need to be anything more than an easy way to store data about the population but it allows for a more natural way of thinking about and representing the population. Going into detail where they have wants, needs and desires other than the basics (life support and food) is too much detail for Outpost. I think.

By using a pool of Person's, each individual can be affected with slightly different modifiers... e.g., someone is a trained scientist but they're working in a factory. Their morale is going to suffer and with that their stresses go up. Plus, because they're on manual labor and they work on the surface, they are being exposed to various environmental stresses including radiation that will inevitably shorten their life span. Throw a well staffed medical facility into the mix and now his longevity is going to be extended somewhat.

Of course there's also the random factor... randomly dropping dead for whatever reason (heart attack, embolism, stroke, aneurysm, whatever). Having that kind of 'random sudden death' factor as a different value for each Person helps to add a bit of realism if you ask me.

I think it will also make morale an easier thing to work with and may even add a bit of challenge. Instead of just straight up number modifiers, the entire population's individual morale's are averaged out.

[nolongerinuse]

Activated; yay, thanks!

I already did some thinking and made some notes about morale and lifetime, and it would seem you're thinking similar thoughts (or should all this go on redmine?):

Death:
Upon death, individuals are removed (object deleted) and the relevant data is stored, if needed. This for possible stats like 'number of dead colonists'. Otherwise every call needs to incorporate the boolean 'mDead', and most data is useless anyway.

Age:
In your code, you used maxAge, but this introduces numerous limitations. Repurposing of maxAge as a chance-based calculation: every turn every individual has a chance of dying, given by the following formula (simple example, assuming 3200 is the max age): (1.1 ^ (x / (3200 / 48 ))) - 1. This starts out very close to zero, and slowly increases until it hits 100 just after 3200 (too lazy to figure out when it exactly hits a 100, I think the inverse equation should end up somewhere around log1.1(101)/3200 or something).
In the case of a shortage of food, for example, the chance can be simply increased by 5, or one of the parameters can be changed. When medical research advances, the parameters can be changed slowly. This would produce a somewhat realistic death rate, and allows for easy messing.
Another approach I've seen, would be to let a 'death' - variable increase by a constant amount every turn. When it reaches 100, game over (for that individual). Somebody working on the surface could have a 0.5 increase on top of the standard 0.1 increase, and somebody working in the mines would get a 0.6 increase every turn. This allows for messing as well, but there's less of a 'chance' involved. Bonus: hardcoded events, such as a lab explosion or mining accident, could get a mention in a message box of some kind, like the Outpost newspaper. "Explosion causes death of nine lab technicians; cat to blame?"

Morale:
Morale is defined between 0 and 1000. Simple constraints/assumptions; 0 for three turns == suicide. morale < 250 results in progressive depression, leading to less production. Morale > 750 results in progressively more production, up to around a factor of, say, 1.2. Anything in between should not impact anything too much. I think some different methods for different industries might be best: laboratories and recreational centres have a linear relationship with morale all the way, while factories only show stuff above and below certain thresholds. That way, stuff works in all but the most extreme situations, but there's still a bonus to increasing morale in small steps.

There's a detail here; fixed morale is quite boring, so I propose the following: modifiers don't have to be static values, but can decay. This means two details need to be stored; the modifier, and the start of the modifier. I'll demonstrate with a random assortment of modifiers:
Residential area available: 200. Decays 0.1 every turn until it reaches 100.
Upgraded (through research, the fancy wheel one) residential area available: 300. Decays until 250.
Job (baseline): +50. Does not decay. Job in a lab gives +100, which decays until 75. Job in education starts at 50, but increases until 100 (gets used to the kids).

Jobs:
At every turn, jobs are organized based on priority. For example; agridome>smelter>lab
If 10 jobs are available in all three, but there are only 20 people available, then the lab will be empty (10:10:0). If a person in the agridome dies, then the distribution will be 9:10:0, which is a problem; then the person with the least job experience (i.e. the lowest work-duration) should be picked from the smelter, leading to 10:9:0 again. When conversely a person is added to the pool in the 10:10:0 situation, who doesn't have education (i.e. we have an 'extra), then the list is searched for the person with this education and the lowest experience. This person is moved to the lab, and the extra gets put in the spot that just opened up.

[Hooman]

As the population grows, you won't be able to tell the difference between simulating each individual versus simulating the population as a whole using abstracted population parameters. Did you really feel the system in Outpost 2 was that lacking? I always thought it felt reasonably natural. If you have a population of 10, then it might make sense to simulate individuals. Heck, at those numbers you can even have issues with all babies being born the same gender, but would that make for a fun game if by random chance you had no hope of future survival? If you have a population of 50 to 100, I think you're just wasting memory and processing cycles by simulating individuals.

As for max age, there is no real such thing. Humans don't have a max age. At best, we have a probability distribution. I once came across a paper that found at extreme age, the chance of death approaches 50% for any given year. Think of it as an asymptotic limit on the probability of death. People don't all die at some hard set age, but rather the population thins quite quickly past a certain age. Your chance of living another 10 years at such a point is about 1 in 1000. The chance of living another 20 years is about 1 in a million. The chance of living another 30 years is about 1 in a billion. Now consider there are about 7 billion people in the world. Not surprising that some people live 30 years or more past normal life expectancy. And there's likely no secret behind having such long lives, other than getting lucky.

[nolongerinuse]

As the population grows, you won't be able to tell the difference between simulating each individual versus simulating the population as a whole using abstracted population parameters.

Agreed; both methods can perform similarly for the end user.

However, individuals as objects is easier to understand, which means coding will be easier, which means less and easier-to-deal-with bugs.
Let's say we've got 100 individuals, each with twenty different variables (age, gender, current medical issue, job, etc.). Solutions:

• Big 100 by 20 table.
• Individuals as objects, leading to 100 objects with 20 variables.

Note that the data or behaviour doesn't change; it's just the organisation that differs.

However, it would be an issue if this slows the game to a crawl. But from my understanding, it shouldn't matter, since there's no extra data. Detail: it was my understanding that this might actually speed things up, due to C++ liking objects.

At best, we have a probability distribution.  I once came across a paper that found at extreme age, the chance of death approaches 50% for any given year. Think of it as an asymptotic limit on the probability of death.

That sounds like a logarithmic function, which is easier to implement than the complicated thing I thought of earlier. More realism, due to it more closely approximating real-life conditions, and a simpler function to boot!

[lordpalandus]

Humans don't die from old age. They die from organ failure (dying in one's sleep is often a result of brain or heart failure). Therefore, a maximum age wouldn't make much sense as its entirely dependent on when organs fail. That's why some people only live to the age of 60 and some to over 100. With futuristic medicine, you'd think people could last for even longer.

[leeor_net]

'maxAge' was a value that I used to provide an average life span. Various factors would change this including access to good health care, advances in medical technology, disasters and environmental stresses. The general idea is that in a stressful environment, you would generally expect people to live to be roughly 65. This could be sooner or later. It's a case of simplifying the model enough that things don't take forever to calculate.

I opted for the individual Person object approach because... really... I don't like complex math. Numbers are scary... oddly enough I can do abstract math very very well and I can think in terms of computers down the the transistor level but actually coming up with math numbers... giant weakness for me.

If a population can be represented as a single set of numbers, I'm game. I just have no idea how I'd go about doing it.

[nolongerinuse]

Population in a big matrix is certainly possible, but I'm still not sure there are benefits.
A slight performance gain might be a benefit, but this feels negligible; how slow is it to poll 1000 objects at the end of a turn, compared to polling a big matrix for the exact same data?

Are there other benefits, assuming the data in the two approaches doesn't change?

[Hooman]

Interesting video. Actually looks playable.

Do you have anything for the population model so far? Perhaps more important, do you have any specs on how it should behave? How does your game use population to affect gameplay? What sort of growth pattern you might expect? Or more simply, where do they start, and where do they end up? You can come up with numbers by figuring out how many people are needed to run a colony of a given size, and figure out how long the player should be playing to reach such a point.

[leeor_net]

Actually looks playable.

It's so close!

Do you have anything for the population model so far?

Not really. Originally I was going to simulate the individual people but after a few posts back and forth in this thread I'm opting for a more simplistic model as you described. Basically, kids, workers and scientists. Still have no idea how to manage the numbers themselves but I do know what factors ought to affect them.

How does your game use population to affect gameplay?

Population is required to keep some buildings operational. E.g., a resource requirement. They're also used to staff laboratories to perform research, etc. Via residences, they will produce waste which can be used by the agridomes for a production boost (small but every little bit counts) and recycled for small amounts of raw materials (processed common and rare metals and minerals).

What sort of growth pattern you might expect?

To quote the original strategy guide, in the beginning, people will be making lots and lots of babies. It'll be needed to keep the population growing, to offset the high initial death rates and will stabilize and slow down a few years after arriving at the new planet (maybe 200 - 300 turns or so into the game). Morale will obviously have an effect on this rate but will also have an effect on death rates too.

Or more simply, where do they start, and where do they end up?

Not sure what you mean here. I guess they 'start' as kids and grow into workers which can go through the university to become a scientist. But I'm not sure that's what you meant.

[Hooman]

What I meant by that last part, is a new game of Outpost 2 starts with about 30-50 colonists, and after maybe 2 hours of play, they will grow to about 200 colonists. Knowing that, and choosing a growth model, you can tune the parameters so you model achieves the desired number of colonists after some approximate amount of play time. Basically, tune it to keep a nice pace of growth so the game doesn't progress too slowly, but also so population is not an endless resource with no requirement to manage how they're used.

It's interesting that you want a high initial growth rate, but as you get more people, the growth rate slows a bit. That might actually be realistic in a way, particularly in regards to your mention of a high initial death rate.

[leeor_net]

Welp, based on the way the original game was designed and the notes from the designer himself (Mr. Balfour), I opted to go with their numbers. Basically, that when you first land, people start making babies because if you don't the species loses out. After awhile it slows down because things have stabilized and your colony is generally moving along well.

As for population, when you first started you could bring between 100 - 200 colonists... which means you started with between 50 - 100 colonists. So that's what I'm going to do. Hard == 50 colonists, Medium == 75 colonists, Easy == 100 colonists. One of many factors affected by difficulty level.

[leeor_net]

Went through the main thread and opted to split the population model discussion out of it and into its own topic especially with the development efforts very rapidly approaching this point.

So with that a few notes/thoughts/whatever.

I've opted to take Hooman's suggestion and go with what I called 'flat numbers'. There's no need to build a 'Person' object. That stated, it's also entirely probable that a PopulationPool object, as I originally envisioned, may not be necessary either. Much like the Energy Value, population can be treated as a "You have this much, this is how much you need to operate a structure."

I ran across an old topic that Hooman posted regarding Outpost 2's population model. I'll repost the relevant code here:

Code: [Select]

/* -- Growth -- */

/* New Workers */
if (colonyState.active.numUniversities > 0 && colonyState.pop.num.kids > 0)
{
	growth.workers += num.kids;
	divisor = num.workers + num.scientists + num.kids;
	if (divisor <= 160)
		divisor = 160;
	
	divisor = ((divisor / 40) * 3 + 36) * 4;

	newPop.workers = growth.workers / divisor;
	growth.workers = growth.workers % divisor;

	num.workers += newPop.workers;
	num.kids -= newPop.workers;
}

/* New Kids */
if (colonyState.active.numNurseries > 0 && num.workers + num.scientists > num.kids)
{
	growth.kids += num.scientists / 4 + num.workers / 2;
	divisor = colonyState.moraleLevel->fertRate;

	newPop.kids = growth.kids / divisor;
	growth.kids = growth.kids % divisor;

	num.kids += newPop.kids;
}


/* -- Deaths -- */

/* Kid Deaths */
if (num.kids > 0)
{
	death.kids += num.kids;
	divisor = colonyState.moraleLevel->deathRate / 2 + colonyState.active.numNurseries * 40 + medCenterCapacity;

	diePop.kids = death.kids / divisor;
	death.kids = death.kids % divisor;

	num.kids -= diePop.kids;
	if (num.kids == 0)
	{
		death.kids = 0;
		growth.workers = 0;
	}
}

/* Worker Deaths */
if (num.workers > 0)
{
	death.workers += num.workers;
	divisor = colonyState.moraleLevel->deathRate + medCenterCapacity;

	diePop.workers = death.workers / divisor;
	death.workers = death.workers % divisor;

	num.workers -= diePop.workers;
	if (num.workers == 0)
		death.workers = 0;
}

/* Scientist Deaths */
if (num.scientists > 0)
{
	death.scientists += num.scientists;
	divisor = colonyState.moraleLevel->deathRate + medCenterCapacity;

	diePop.scientists = death.scientists / divisor;
	death.scientists = death.scientists % divisor;

	num.scientists -= diePop.scientists;
	if (num.scientists == 0)
		death.scientists = 0;
}

I have a fairly basic grasp of this but the real problem is in understanding some of the divisor numbers, particularly in the 'growth' section (lots of magic numbers there). This should be simulated to see what kind of populations would develop under a number of conditions including tweaks to the divisor (something that difficulty can/should have an effect on plus any research enhancements).

Additionally, OP1 had a Morale range from 0 - 1000, OP2, as I recall, is 0 - 100. Not sure how it would affect this code or if 0 - 100 is sufficient considering OP1's initial implementation.

Anyway, thoughts?

[Hooman]

The divisors do seem to contain a few magic numbers. It's probably a balancing thing. I'm not sure the numbers for the worker train rate have much meaning other than it seems to produce desired results. For your purposes, remember the Outpost 2 population growth code doesn't run every cycle. I believe it ran every 256 ticks or so. You may need to consider that if adapting the values to a turn based game.

The morale effects are based on level, such as Excellent, Good, Poor, Terrible. It's not based on 0-100 scale. Rather, sections of the 0-100 scale are divided into the various levels, and then values for that level are used. Hence why the code references values off the moraleLevel struct.

Magic numbers aside, the calculations all work the same way. There is a cyclical growth value. It increments with each cycle, and when it overflows and wraps around, that's when an event happens, such as a new child being born, or a worker being trained. The division (/) and modulus (%) handle the overflow and wrap around. The divisor is the point at which that counter wraps around. It's a moving target.

In the case of kids being trained into workers, the divisor depends on your total population, but only once your total population reaches 160 people. Essentially this rule comes into effect once you reach 160 people, and it has the effect of slowing the rate of growth at that point. Remember that an increased number of kids increases the rate of growth of workers. If that growth grew unchecked, it may become too fast to be desireable. By moving the wrap around point further along as your population increases, it will slow the rate kids are trained into workers, counteracting the large growth rate from having so many kids.

It might help to look at some numbers. Remember the division is integer division. Starting at a value of 160, you see 160/40 = 4. That result increases to 5 (whole numbers only) once your population reaches 200.
The formula ((divisor / 40) * 3 + 36 ) * 4 = ((divisor / 40) * 12 + 144 produces the following values:
160: ((160 / 40) * 12 + 144) = (4 * 12) + 144 = 48 + 144 = 192
200: ((200 / 40) * 12 + 144) = (5 * 12) + 144 = 60 + 144 = 204
240: ((240 / 40) * 12 + 144) = (6 * 12) + 144 = 72 + 144 = 216
280: ((280 / 40) * 12 + 144) = (7 * 12) + 144 = 84 + 144 = 228
320: ((320 / 40) * 12 + 144) = (8 * 12) + 144 = 96 + 144 = 240
For the population on the left, you'll need to accumulate the number of points on the right before a kid is trained into a worker. The number of points added each cycle is the number of kids you currently have. Also note that due to integer division, those calculations are the same for the ranges 160..199, 200..239, 240..279, 280..319, 320..359. (And of course, due to the minimum population part, the first rule also applies before 160, so it really applies to the range 0..199).

[leeor_net]

I noticed the modulo operator and new as soon as I saw the formula that it was accumulating the remainder and taking that into account. It's an interesting formula and actually makes a lot of sense. It's making me think that the formula is good but the numbers will need to be tweaked. Maybe run it once every 5 turns or even modify it so it can be run every turn. Makes me wonder if the OP1 model had morale up to 1000 for similar purposes.

* leeor_net scratches head

Ugh, I hate growth mechanics. So hard to wrap my head around. I've said it before and I'll say it again, math has never been my strong suit.

[Hooman]

For a turn based game, you'd probably want population growth code to run every turn. It might not produce new colonists every turn, but you'd likely want the possibility to be there on any given turn. If you consider the Outpost 2 code was only designed to run every 256 ticks or so (I don't remember for certain), it may already work quite well in a turn based setting as is.

Math is fun. Putting in that bit of effort to understand something new makes it more fun. When it's more fun, you want to make more of that bit of effort. 

Action precedes motivation.

[leeor_net]

Math is fun. Putting in that bit of effort to understand something new makes it more fun.

This is mostly true -- when I learned trigonometry for the first time, figuring it out on my own so I could do line/point/circle/arc intersections, it was very satisfying to see it working and actually understand HOW it worked vs simply knowing that it DID.

For a turn based game, you'd probably want population growth code to run every turn.

It occurred to me last night when I was chatting about the population model on IRC that the code should run just fine every turn like that. I think it will need some tweaking (particularly in terms of the magic numbers) but generally I don't see why it -shouldn't- work.

With v0.6.0 rapidly developing, I'll be on to v0.7.0 very, very soon which is where population and morale models are implemented. I'm thinking of doing a command line unit test program so I can run various numbers through the code you provided and see what kind of results I get based on known values and perhaps adjustable values for the growth formulas as well... after seeing it providing useful numbers it shouldn't be difficult to push it into OPHD's code base where the numbers can be provided by the simulation instead of manually tossed in.

Last night I pulled all of the original PopulationPool and Person code as I figured it would be irrelevant. I think encapsulating the population code into an object is a good idea, say something like a Population object that can just be updated each turn.

I am still wondering though if I should do a pool type deal, where I have so many of each type of population but buildings treat them effective as resources like Energy (you have so much energy, this is how much is being used), that sort of deal.

It's interesting how the farther I get into it the more complex everything seems to get.

[IDMclean]

The turns in Outpost 1 are not arbitrary, but they vary depending on the stellar and planetary conditions. 1 turn means different things depending on what planet you land on; stellar year (based off of the distance of the planet and its mass) or planetary day are involved in the calculation. At the moment, I don't recall what I managed to figure out about them years ago when I was last playing the game in a dedicated fashion; I do recall that it turned out to be a significant condition in choosing starting planets and effects satellite mechanics.

A good test planet in Outpost 1 is Alpha Centauri A, Centauri II. It has a close to 24 hour day; generally speaking, the Earth like planets are 1.52 AU with a planetary rotational period near 24.6 hours.

For your population model, you are going to need to figure out your temporal model as well. Because you are almost invariably going to end up writing your population growth as a function of time.

Personally, I think doing a Monte-Carlo-like simulation on a per colonist basis will be better in the long term for maintaining your code base; you'll probably be thankful you chose it when you get around to the full research tree. Otherwise, you're going to eventually need to resort to some pretty hairy (and chaotic or Malthusian) thermodynamic statistical models of population, or you're going to need to just drop the pretense of realism and use something grossly non-representative of population growth.

Starting with the design of a unit colonist is a much simpler problem to solve programmatically. Defining simple rules for colonist reproduction is another simpler problem to solve programmatically; you might even be able to use existing genetic algorithm libraries in programming to simulate population evolution in a step-wise manner.

I think the population model for Outpost is one of the systems which needed a lot more work. There's a lot of potential improvements to the game play which could be made with a better thought out temporal and population model. If I was a better programmer, I'd be interested in trying to implement some of the ideas I have for simulating genetic genealogies, but I suspect that might be well beyond what you're trying to do here.

[leeor_net]

IDMclean, welcome to the boards! Glad to hear from you!

You have a lot of excellent suggestions. I'll try to cover everything.

The turns in Outpost 1 are not arbitrary, but they vary depending on the stellar and planetary conditions. 1 turn means different things depending on what planet you land on; stellar year (based off of the distance of the planet and its mass) or planetary day are involved in the calculation. At the moment, I don't recall what I managed to figure out about them years ago when I was last playing the game in a dedicated fashion; I do recall that it turned out to be a significant condition in choosing starting planets and effects satellite mechanics.

Except that they kind of are arbitrary. At least in their definition. There is plenty that goes on under the hood that I'm sure affects a lot of variables, but for the most part these effects didn't seem to have a lot of effect. At least not that at the time I could really see. Rotation speed of a planet would seem to have little effect on anything... though a slow speed could have a dramatic effect on, say, agricultural domes. But then again, with modern technologies and full-spectrum light sources, this may no longer be a limiting factor, just may have an effect on how much energy a dome uses. As an example.

For your population model, you are going to need to figure out your temporal model as well. Because you are almost invariably going to end up writing your population growth as a function of time.

According to the official strategy guide (and the manual), the temporal part of the population model was that each turn was considered roughly one month, but that it's the only one that fits such a clean definition. Basically, they didn't even know what it meant.

I'm kind of in the same boat. Originally I wanted to think of turns as a standard earth week. This posed a problem in that it would take a very long time for the population model to produce larger numbers of people (on the order of thousands of turns). I also considered one turn being one month, but then when it comes to resource trucking, a trucking taking one turn to move over a tile makes literally no sense (or three months for a difficult tile?).

At least in terms of resource trucking, this difficulty of terrain will need to be a different evaluation.  Basically, I'm seeing it as the number of times a truck can follow a particular route within a turn and a tile's terrain type determines the weight of moving over said tile. But that's in a different vein of development.

Personally, I think doing a Monte-Carlo-like simulation on a per colonist basis will be better in the long term for maintaining your code base;

Perhaps, but Hooman was right in an earlier statement -- as the population increases, the benefits cease to outweigh the downsides. We end up spending more and more time managing large groups of objects and wasting a lot of time and overhead doing so. Ultimately the simulation's focus is less on the individuals and more about the colony and resource management so using a matrix, as vomov described it, makes more and more sense.

Starting with the design of a unit colonist is a much simpler problem to solve programmatically. Defining simple rules for colonist reproduction is another simpler problem to solve programmatically; you might even be able to use existing genetic algorithm libraries in programming to simulate population evolution in a step-wise manner.

You actually raise a really good point here.

I think the population model for Outpost is one of the systems which needed a lot more work.

Completely agree with you. OP1's population model was poorly done, pretty much like everything else was.

There's a lot of potential improvements to the game play which could be made with a better thought out temporal and population model.

Also completely agreed.

If I was a better programmer, I'd be interested in trying to implement some of the ideas I have for simulating genetic genealogies, but I suspect that might be well beyond what you're trying to do here.

I think it's a bit beyond the scope of this particular game. It's an interesting point and would certainly be interesting for a game that is focused on population management. In the case of OutpostHD, I wanted the game to be fun without having too many details to worry about. If that makes sense.

I think I covered everything.