Outpost Universe Forums

Projects & Development => Projects => OutpostHD => Topic started by: vomov on October 26, 2015, 02:18:19 PM

Title: Population Model
Post by: vomov on October 26, 2015, 02:18:19 PM
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.
Title: Re: Population Model
Post by: leeor_net on October 26, 2015, 04:03:34 PM
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.
Title: Re: Population Model
Post by: Hooman on October 29, 2015, 02:16:56 AM
I kind of feel that individual colonists is a needless complication.

Unless perhaps you're designing Sims: New Terra.
Title: Re: Population Model
Post by: lordpalandus on October 29, 2015, 02:27:15 AM
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.
Title: Re: Population Model
Post by: leeor_net on October 29, 2015, 10:24:54 AM
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.).
Title: Re: Population Model
Post by: vomov on October 29, 2015, 10:26:59 AM
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.
Title: Re: Population Model
Post by: vomov on October 29, 2015, 10:55:18 AM
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.
Title: Re: Population Model
Post by: leeor_net on October 29, 2015, 11:29:10 AM
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.
Title: Re: Population Model
Post by: vomov on October 29, 2015, 12:01:07 PM
Activated; yay, thanks! ;D

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.
Title: Re: Population Model
Post by: Hooman on October 29, 2015, 10:26:54 PM
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.
Title: Re: Population Model
Post by: vomov on October 30, 2015, 02:59:18 AM
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:
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!
Title: Re: Population Model
Post by: lordpalandus on October 30, 2015, 02:46:39 PM
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.
Title: Re: Population Model
Post by: leeor_net on October 30, 2015, 11:08:23 PM
'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.
Title: Re: Population Model
Post by: vomov on October 31, 2015, 03:35:38 AM
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?
Title: Re: Population Model
Post by: Hooman on January 23, 2016, 03:23:40 AM
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.
Title: Re: Population Model
Post by: leeor_net on February 11, 2016, 02:25:24 PM
Quote
Actually looks playable.

It's so close!

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

Quote
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).

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

Quote
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.
Title: Re: Population Model
Post by: Hooman on February 11, 2016, 07:29:02 PM
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.
Title: Re: Population Model
Post by: leeor_net on February 15, 2016, 07:21:49 PM
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.
Title: Re: Population Model
Post by: leeor_net on June 30, 2016, 12:19:49 AM
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 (http://forum.outpost2.net/index.php/topic,3807.0.html) 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?
Title: Re: Population Model
Post by: Hooman on June 30, 2016, 12:35:44 PM
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).
Title: Re: Population Model
Post by: leeor_net on June 30, 2016, 07:53:18 PM
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.

/me 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.
Title: Re: Population Model
Post by: Hooman on July 01, 2016, 03:34:49 AM
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.
Title: Re: Population Model
Post by: leeor_net on July 01, 2016, 10:36:40 AM
Quote
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.

Quote
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.
Title: Re: Population Model
Post by: IDMclean on July 02, 2016, 06:32:43 PM
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.
Title: Re: Population Model
Post by: leeor_net on July 02, 2016, 10:51:01 PM
IDMclean, welcome to the boards! Glad to hear from you!

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

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

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

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

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

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

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

Quote
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.
Title: Re: Population Model
Post by: IDMclean on July 04, 2016, 01:12:25 PM
Okay, I did a rough check. I didn't keep track of when I landed my population, but I did start keeping track of the infants born; I am conducting this on Beta Hydri 1 which has a AU of 1 from the star, so it should have a year comparable to Earth; I will be conducting a second test on a 1.52 AU planet and on at least one planet with a distance farther than 1.52 AU from its star.

My first infants (6 from non-infant 48 pop and a total pop of about 54) were born around turn 25. My second set of infants (8 from about non-infant, non-student 44 pop and a total pop of about 58) were born on turn 37. That's 12 turns between the first and the second, so I think it is safe to assume that a turn is about 1 Earth month for the purposes of the Outpost population model on 1 AU planets.

I'll be tracking exact population numbers and distributions per turn on subsequent tests.

Update: Testing on 82 Eridani 1, Site 5 at 1.52 AU from its star. I lost 1 colonist on turn 19-20. I landed my colonists on turn 20 (0 infants/13 students/18 workers/18 scientists/0 retired). Lost 1 colonist for turns 22-23 (0/13/18/17/0), 23-24 (0/13/18/16/0), 24-25 (6/13/9/24/0), and 25-26 (6/13/9/23/0). The second set of infants were born on turn 36-37 (15/0/22/23/0). Infants were reliably born every 12 turns from that point on for at least 61 total turns (32/0/22/23/0).

So we can conclude rather soundly that the basic temporal model for Outpost's population model is based around a yearly cycle. This would imply that a turn is either 1 month and the infants that are born are not necessarily new borns by the time they're reported in the model, or it implies that 1 turn is about 1/12th of a 40 week gestational period or about 3 and 1/3rd weeks in length. This produces absurdities for the production times of various objects (fuel cells are produced about 1 per year or 1 per 2/3rds of a year) and the movement times for trucks over tiles.

I would say based on my experience with game designs and the game design process that this is due to a failure to pick and develop a temporal model during their initial prototyping process. Outpost was not finished when it shipped, and I think this is one of the major places where it shows.

If turns are equivalent to 1 week then a new population can be added for every 2 non-infant, non-student population every 40 turns. Simple model would have a maximum of 1/2th the total non-infant, non-student population in a 40 turn period.

If turns are equivalent to 4 weeks then a new population can be added for every 2 non-infant, non-student population every 10 turns. For a simple example a population of 100 productive members could produce 50 infants in 10 turns.


You would want to actually use a fertility rate and a gestational mortality (spontaneous abortions or miscarriages, infant mortality, maternal mortality) rate. Agrarian pre-contraception societies have a fertility rate of about 6, and most modern societies have a fertility rate of about 2.1 or lower; the fertility rate is the number of children born to the average woman in her lifetime, so a fertility rate of 6 is 6 children per woman per her total lifetime. A fertility rate of about 2.1 is just above sub-replacement and grows slightly; a fertility rate below 2 causes the population to diminish over successive generations towards extinction.
Title: Re: Population Model
Post by: leeor_net on July 07, 2016, 12:32:55 PM
Quote
so I think it is safe to assume that a turn is about 1 Earth month for the purposes of the Outpost population model on 1 AU planets.
Quote
So we can conclude rather soundly that the basic temporal model for Outpost's population model is based around a yearly cycle.

Yup. This is stated in the official strategy guide.

Quote
I would say based on my experience with game designs and the game design process that this is due to a failure to pick and develop a temporal model during their initial prototyping process.

I would agree. I wanted to pick a clean temporal model for OutpostHD as well but kind of abandoned that during the initial development. However, because resource trucking and processing hasn't been fully fleshed out or fully developed, this is still a case where it can be settled on (as discussed in the resource trucking topic). I also thought of building construction in terms of months... e.g., if a building takes three turns to complete, it's effectively a 3 month process. Obviously in the case of landers it doesn't take a month to land them but for the SEED Lander it can be seen either as it took roughly a month for the lander to land, robots to be deployed and initial structures to be started. Or we can just pretend that that first turn doesn't really count for anything other than progressing the game forward.

Quote
For a simple example a population of 100 productive members could produce 50 infants in 10 turns.

At first I thought this was far too high but then realized that this is in an ideal situation where there is no infant mortality or parent mortality. It also doesn't include colonist mortality rates in general so this seems like a reasonable set of numbers.

Quote
You would want to actually use a fertility rate and a gestational mortality (spontaneous abortions or miscarriages, infant mortality, maternal mortality) rate.

Naturally. This is something that would be influenced by difficulty and planetary hostility rating.

Quote
so a fertility rate of 6 is 6 children per woman per her total lifetime.

This is about what the Outpost strategy guide states... at least for the first 60 turns or so. After that it drops down to roughly 3 or 4. I'm not entirely sure how to set that up without special case code but if I play with the math a bit I'm sure I'll figure it out.

This is also something that should be affected by difficulty and planetary hostility rating.
Title: Re: Population Model
Post by: IDMclean on July 21, 2016, 04:37:08 AM
Realistically, various social policies and soci-economic conditions would also influence growth rates in the population model. Access to universal contraception and abortion services, comprehensive sex education, poverty (which tends to increase birth rates) or abundance (which tends to decrease birth rates), access to economic means such that a real decision can be made about children vs luxury living, and social support for parenting such a universal child care facilities and services.

In 4X games, they tend to simulate that complexity with some kind of happiness or colonial approval measure. The simple model tends to be that high happiness results in population booms and low happiness adversely effects growth and resource productivity. Happiness tends to be tied to a tax rate, but I highly encourage you to develop the OutpostHD model independent from a capitalist model of monetary exchange. Environmental (presence or absence and type of atmosphere, proximity to star, star spectrum, primary composition of the planetary crust, and similar conditions), economic (mineral, food, power, residential availability, education, and other goods and services), and social factors though should be ultimately implemented on top of the population model and interact with it.

We can really break down the more complex stuff into those three major factors, I think. Environment. Economics. Social Policy. Recently, I have been playing a game called Democracy 3 which I think is worth looking at for inspiration of how to handle the interaction between those things in a relatively simplified way. You could probably even strip down the mods for it to look at the code for study.

An economic value can likely be derived from comparing the relative resources available to the number of colonists you have. A general resources per capita measure would be useful, i think. I tend to think that having huge excesses of resources per colonist is not great generally; imagine 50 people living in a mostly unused shell of a colony built for millions of people. A ghost town. Resource shortages are kind of obvious in their impact on the health and well being of colonists. A robust model would have a way of automatically deriving [RESOURCE] per pop statistics for each resource added in the basic game or for extensions by mod.

I would encourage you to check out 4X conquer the galaxy type games. I tend to think that Endless Space has a interesting basic model; there's a lot of things I don't like about it, but the FIDS and approval systems are worth examination, and they play around with the basic mechanics a lot from faction to faction. I especially encourage you to check out the Harmony faction; they eliminate the game's equivalent of money (Dust) and approval and focus on Food, Industry, and Science; I tend to disagree with their basic approval model, but it is also worth examining if you're going to implement your own.

I will always have a special place for Sid Meier's Alpha Centauri. I loved its social policy system and future society techs that allowed for mixing and matching your own particular social model.
Title: Re: Population Model
Post by: leeor_net on July 21, 2016, 03:30:10 PM
Quote
Realistically, various social policies and soci-economic conditions would also influence growth rates in the population model. Access to universal contraception and abortion services, comprehensive sex education, poverty (which tends to increase birth rates) or abundance (which tends to decrease birth rates), access to economic means such that a real decision can be made about children vs luxury living, and social support for parenting such a universal child care facilities and services.

True, though I wonder really in the case of Outpost how much the population growth rate would match what it is in Earth today. From the manual and strategy guide, these are smart people (mostly scientists and engineers) that understand the need to procreate in order to produce enough of a population to sustain the last bastion of humanity. This basically leads to people that would normally have no children or only one or two to have many more, say 6 to 8.

After about 60 turns, or 5 years, according to the manual and strategy guide this rate drops down to 3 - 4. I'm thinking to follow a similar model and then maybe later drop it even further down and go for a growth rate that more closely follows what we see on Earth. After say, 20 years or so, the population would very much have slowed down and you now have the second generation of colonists that are producing children. Couple this with an education level, crime rates, residence capacities and a myriad of other factors... damn, this is kind of a complex model isn't it? A lot of variables to think about and account for. Going to start putting these variables into a Redmine task as I develop the prototype.

Quote
Happiness tends to be tied to a tax rate, but I highly encourage you to develop the OutpostHD model independent from a capitalist model of monetary exchange.

That would be Morale, a factor in both games. In Outpost, the morale level could range between 0 and 1000 starting at 600. In Outpost 2, the range was 0 to 100 and starting was whatever the current mission would set it to.

Anyway, I'm thinking of leaving Morale is the major value players need to pay attention to. Happy colonists mean productive colonists. Unhappy colonists means low productivity and an almost inevitable failure.

Quote
Environmental (presence or absence and type of atmosphere, proximity to star, star spectrum, primary composition of the planetary crust, and similar conditions)

To simplify this part of the model, this can be boiled down to a single value based on planet type. I'm changing the planet selection stage a bit from the original game. Instead of packing a ship and choosing a star, you instead get a choice of planets. Basically, it fast forwards to the planet selection stage of Outpost but you get more planet choices immediately.

Anyway, back on topic, the planet types themselves would determine all of those factors so that would be known ahead of time. The question is in finding a scalar value which affects the Morale level. Morale is pretty much the value in the population model that really matters -- of morale is low, you have much lower birth rates, much higher death rates, much lower production rates (both factor and laboratory), crime rates tend to soar, etc.

Quote
We can really break down the more complex stuff into those three major factors, I think. Environment. Economics. Social Policy.

Agreed, but I have to ask, what does social policy involve? Environment is easy -- planetary hostility + our impact on the environment + terraforming projects (basically like Outpost 1, it changes the atmosphere making the planet more hospitable on planets that can sustain an atmosphere). Economics is also simple enough -- availability of resources and food, residential capacity, medical capacity, education level and unemployment rates.

Social policy has me kind of scratching my head though -- I'm not sure what factors would be involved in this.

Quote
I would encourage you to check out 4X conquer the galaxy type games.

I've played and enjoy many but I'm not really sure how they fit into this game. Outpost has a lot of similarities to 4X games but it's ultimately a city construction and population management simulation game. Borrowing from some 4X games, on the other hand, intrigues me. Unfortunately I'm a better programmer than I am a designer. -_- But I'm entirely open to suggestions and thoughts about how we can make OutpostHD a fun and interesting game to play.

Quote
I will always have a special place for Sid Meier's Alpha Centauri.

This is an amazing game. I still enjoy playing it to this day!
Title: Re: Population Model
Post by: IDMclean on July 21, 2016, 08:28:41 PM
http://strategywiki.org/wiki/Sid_Meier's_Alpha_Centauri/Social_Engineering or http://alphacentauri2.info/wiki/Social_Engineering we can use this as a common reference between us for discussing social policy modelling.

We can talk about birth or growth policies specifically to start with. When you arrive at the planet, there is a default growth policy in effect which greatly increases birthrates for the first 60 turns (5 or 6 years based on the manual and experiment). After the colony reaches a point of stability, the growth policy can be more of a detriment than an assist while you tool up for the massive excavation projects necessary to house rapidly growing population. The default behavior is for the growth policy to change after that duration to a lower growth rate and stay there.

This can be left static or the player can influence it directly as part of trying to control the complex of interacting variables. In Alpha Centuari, you have four different parts of a matrix that defines your social model. Politics, Economics, Values, and Future Society. They are further subdivided in to specific social policy models. Politics has Frontier, Police State, Democratic, Fundamentalist. Economics has Simple, Free Market, Planned, and Green. Values has Survival, Power, Knowledge, Wealth. Future Society has None, Cybernetic, Eudaimonic, Thought Control. You can mix and match from the four different parts, so you can have Democratic, Planned, Power, Thought Control society or a Police State, Green, Knowledge, Cybernetic society. They change a complex of variables and can greatly change the way that you develop your society's infrastructure.

SimCity 2000 has comparable features that correspond to social policies including a complex taxation system for controlling what kinds of growth occur in your city. http://simcity.wikia.com/wiki/SimCity (Incidentally, http://www.donhopkins.com/home/micropolis/ is the open source version of the SimCity Classic engine.)

Democracy 3 implements social policies as groupings of variable relationships which can be effectively be positively or negatively impacted by adoption or abolition of the policies; the policies generally can be adopted as a sliderbar that represents a spectrum of possibly discrete states between either no implementation or negative implementation to complete implementation. They form feedback and control systems between dynamic interdependent or networked statistical models; the colony command facility and associated popup forms the first part of the feedback and control system. Example social policy: abolishing birth control.

For Outpost, I always liked the fact that you were not just rebuilding the culture of Earth on some far away colony, but you are building a future society that starts out with similar technology of the 1990s Earth then you rapidly diverge off into a very different society. A big part of that is deciding whether to go totalitarian to survive or instituting the glorious socialist revolution.
Title: Re: Population Model
Post by: leeor_net on July 21, 2016, 09:59:53 PM
Okay, so, I'm building a prototyping program now to simulate the numbers with given inputs. With it numbers can be tested with a constant morale, given university, medical facility and resource values. Different starting population configurations can be provided and different environmental factors, etc.

But I'm finding it difficult to come up with a formula to take into account all of these things and then modify population values accordingly.

We know the following facts and assumptions:

Populations tend to be fairly evenly split in terms of binary genders. I'm unconcerned with current social issues regarding gender identity, sexual identity, sexual orientation and gender fluidity. While these are important issues, they are irrelevant, I think, to this sort of game. Ultimately if humanity was thrust into such a situation the end result would be those who can bear children will be expected to do so else have humanity go extinct.

So a 50/50 split is assumed.

Population is split into the following categories:


These come from the original game and ultimately makes sense in terms of a population.

The following assumptions can be made about the population:


These numbers are very much up for debate -- I can also see children being ages 0 - 15, students being 15 - 25, workers being 16 - 50 and scientists being 25 - 50. Outpost 1 did the student-->Scientist automatically but I like Outpost 2's idea of explicitly training scientists out of the Workers group. Scientist training would run 5 - 10 years (60 - 120 turns).

This is what I've got at the moment... this is turning out to be a lot harder than I anticipated. It would be very easy to do this using a series of objects representing people considering the myriad complexities involved in this but as Hooman and others have stated, doing so raises the amount of memory required to do this and with very large populations can be very slow. This is where my weakness in math starts to take its toll.

On the other hand, I'll need to start doing some work on paper because I think this can be done using numerical models.
Title: Re: Population Model
Post by: Hooman on July 25, 2016, 01:59:00 PM
Quote
I think this can be done using numerical models
:)

*thumbs up*
Title: Re: Population Model
Post by: leeor_net on July 26, 2016, 10:40:37 PM
So it can be done using numerical models but I'm finding it exceedingly difficult to make it work. Perhaps I'm stuck in OOP mode but it would seem a lot easier to think about these as individual objects each considering age, gender, health and role.

When I did some basic math, since only a few values are stored, roughly 10,000 'person' objects with three int's and one bool will only really take up a few hundred KiB of memory (140 for the raw info itself) with a bit more for vtables and whatnot. E.g., a 'person' object costs a bit more memory than just the sum of its parts.

Anyway, point being I tested it with up to 30,000 'person' objects and found that the program only takes about 1.5Mib memory (not sure why so much) but ultimately in the grand scheme of things it's a negligible amount of memory for handling this. Also, it runs through the objects very fast, withing a few nanoseconds to update each individual person object in  group of 30,000. I suspect late games to have somewhere in the realm of 4 - 5K populations, I don't really know why the would get any larger than that, if that.

Okay, so, here's the real problem. Savegames.

If I went minimalistic with the population saving information, it would look something like this in XML:

Code: [Select]
<person age="400" health="100" gender="0" role="2" />

With 30,000 population we're looking at a savegame size of 1.6MiB not accounting for other information including structures, etc.

Not sure if I should just go the route of writing out that information as human readable XML (could take awhile to save and load due to DOM processing) or if I should just write it out as a binary stream and save that between <population></population> tags (reduces 30,000 population to a little under 500KiB).

I know this one is really super 100% technical but it's kind of a reasonable thing to consider earlier on. I may simply go with human readable XML for now, can always add binary output later... it's not like storage space is at a premium anymore.  :-\
Title: Re: Population Model
Post by: UtopiaPlanetia on July 26, 2016, 11:54:47 PM
Is modeling individual health an important feature? I've seen population models using systems of differential equations (e.g. https://en.wikipedia.org/wiki/Lotka%E2%80%93Volterra_equations). The models don't care about the individual. Then, you only have to save a few variables including the time, current population count, and some parameters instead of thousands of objects.
Title: Re: Population Model
Post by: leeor_net on July 27, 2016, 01:14:35 AM
Therein lies my difficulty. Sure, by using a formula like this I could reduce all of this down into just a handful of variables. Which is cool and all, but I'm not entirely convinced I'd be able to properly track things like children to adults (workers), workers to scientists (training is on an as needed basis) and adults to retirees.

The individual health is gradually reduced and as it gets closer to 0 chance of death is much higher. It's less a matter of state of health vs. a chance modifier which can be adjusted based on whether or not the person is starving, receiving adequate medical care, general stress levels (though this would be generalized based on crowding conditions and overall morale) and a few other factors.

I'm also still considering adapting it to work more like it does in some of the Sim and Tycoon games where you can actually track individual people. I haven't completely decided on this so for now this allows me the option to do that in the future.

Lastly, I'm having a hard time really admitting my failure to understand abstract mathematical models. I suppose my mind just isn't built for that, I look at things in more real-world ways as objects and their relationships to each other. I see the advantage in a somewhat more complex model of the population. As Hooman has pointed out earlier when you start getting larger groups it almost doesn't matter... so that's why I'm posing it here as a discussion because I see the potential in going for the less efficient (but much easier to understand) model or the more abstract and more efficient methods.

Really has me scratching my head again.
Title: Re: Population Model
Post by: UtopiaPlanetia on July 27, 2016, 02:47:55 AM
If you are going for the group models, would this be plausible?

childPopGrowthRate        = birthRate - childDeathRate - toStudentRate
studentPopGrowthRate   = toStudentRate - studentDeathRate - ( toWorkerRate + toScientistRate )
workerPopGrowthRate    = toWorkerRate - workerDeathRate - workerToRetiredRate
scientistPopGrowthRate  = toScientistRate - scientistDeathRate - scientistToRetiredRate
retiredPopGrowthRate     = workerToRetiredRate + scientistsToRetiredRate - retiredDeathRate

toStudentRate is the rate that children become students.
toWorkerRate is the rate that students become workers.
toScientistRate is the rate that students become scientists.
workerToRetiredRate is the rate that workers retire.
scientistToRetiredRate is the rate that scientists retire.
The other rates should be obvious. Everything right of the equal sign will probably not be a constant values, will change depending on number of resources, number of buildings, random disasters, etc. Everything left of the equal sign will be used to calculate the population count. Pop1 is the current population, Pop2 is the new population after the turn.

childPop2        = childPopGrowthRate + childPop1
studentPop2   = studentPopGrowthRate + studentPop1
workerPop2    = workerPopGrowthRate + workerPop1
scientistPop2  = scientistPopGrowthRate  + scientistPop1
retiredPop2    = retiredPopGrowthRate  + retiredPop1

currentPop = childPop1  + studentPop1 + workerPop1 + scientistPop1 + retiredPop1
newPop = childPop2 + studentPop2 + workerPop2 + scientistPop2 + retiredPop2
Title: Re: Population Model
Post by: Hooman on July 28, 2016, 07:39:08 PM
Quote
... workers to scientists (training is on an as needed basis)
That's the easy one. The user controls the training. There is no growth model there.  ;)

Sounds like you're afflicted by the mental laziness bug. There's something you don't yet understand, and you want to be lazy and avoid doing it, and thus avoid learning something new and unfamiliar. Quite a serious illness really, affecting millions of people. I'm afraid it's terminal.

Keep in mind the actual model doesn't really matter that much. It doesn't need to be realistic. It just needs to be fun. If people enjoy something, they'll invent their own reasons why it's the way it is. Worry more about the effect you're going for, rather than trying to reason about what should happen.

I have some thoughts on building a population model, including the math, and techniques to tweak the numbers. It's taking a while to formalize and really nail down the core concepts though. I try to post the details in a day or two.
Title: Re: Population Model
Post by: leeor_net on July 28, 2016, 09:33:26 PM
Quote
Sounds like you're afflicted by the mental laziness bug.

Yes and no. First and foremost, my abstract math skills are weak. This is something I can fix by simply doing the math and really understanding it and just practicing.

No because normally I would, but I simply don't have the time to do it. Work has me slammed all the time and mentally drained all the time so when it comes to really putting the time to understanding something difficult like that, ya no, I take the easy way out.

Plus, as stated when I think about certain other games like SimTower, SimCity (new SimCity), Roller Coaster Tycoon and others they do actually keep track of individuals as collections of objects. I guess ultimately when it comes down to when I play the games I don't always go inspecting each of the potentially thousands of individuals but I can see a lot of potentially cool things that can be done by doing it this way.

Quote
Keep in mind the actual model doesn't really matter that much. It doesn't need to be realistic. It just needs to be fun.

Yes. After talking to a few non-programmer friends, I opted to skip the complex mathematical model and go for the object based model as 1) I have a much firmer grasp of it and 2) it'll ultimately produce the results that I want.

So on that note, I've started building a prototyping program that allows me to see how numbers work together. I haven't yet added in mortality rates, difficulty settings or various other variables that would influence birth and death rates so people continue to age indefinitely until the great mediator Food runs out. In the screenshot once food runs low you get mass die off's... and as you can see it usually leaves only a few kids to fend for themselves.  :o

This is with the aforementioned design of looking at the population as collections of individuals. I have a few values in there I call 'jitter' values that are applied to birth mechanics. This basically randomizes how many kids are born and when by randomizing a bit the rate of conception in female's. This is where things like morale, birth rates and such start to kick in but the way I'm doing it now is that female's have a minimum and maximum birthing age (geez this sounds more and more like I'm some masochistic asshole seeing women only as baby makers... but I suppose in this particular case that's kind of an important function that they kind of sort of need to do this).

Anyway, minimum age is 20, max is 45 so that gives women a 25 year window into which to produce children. The base spacing between conceptions is 18 months (generally speaking it's very bad for health to pop one child out after the next immediately after a pregnancy and modern doctors recommend children no sooner than 18 months after a pregnancy... I've reduced this to no sooner than 9 months as this is kind of a dire situation). Anyway, the jitter value can increase this up to 4 years which would lead to roughly 6 kids per female per peak reproduction years on the minimum and up to 16 kids for someone really getting busy. I'll want to play with these values some.

Bleh, anyway, once I add in the death and mortality rates (things that kill colonists besides starving) I expect to see very different values (e.g., at turn 1215 I'm probably not going to have 50000 colonists with 1600 or so 80+ years olds).

Of note:

As I put this together in the prototyping program, I broke logic down into a number of functions and realized that all of these could easily belong to a Population class... which means that the implementation of the Population itself can be switched out for whatever system works the best with no changes to the rest of the game. Which I like... modularity... this is what OOP was designed for.
Title: Re: Population Model
Post by: Hooman on July 31, 2016, 05:09:00 PM
Ok, so here are some thoughts for developing a numerical model, such as for population growth.

Start from a simple idea. Numbers grow over time. They should not grow too slow, nor blow up too quickly. For population, you'll probably want a bit of an accelerating growth as the game goes on. Think of a gently upward curving graph, with time along the x-axis, and population along the y-axis. There are many formulas that will produce such an upward (concave up) curve. Two types of equations that immediately come to mind are quadratics (such as x^2), and exponentials (such as e^x). Exponentials are often used to model population growth, so they make for an obvious choice here. We have yet to specify a property that requires exponentials though, and much of this discussion will be generic to other numerical models beyond just population. For the sake of the initial discussion it really doesn't matter, the only requirement so far is a gently upward curving graph, so we'll consider both the quadratics and exponentials. We'll even expand on this a little and consider higher order polynomials, and non-integer powers of x.

Some examples would help at this point. Try looking at a few formulas in an online graphing calculator (https://mathway.com/graph). We can start by looking at some base formulas. Try entering the following (you can graph them all on the same graph):
e^x  (exponential)
x^2  (quadratic = polynomial of order 2)
x^2 +x+1  (quadratic = polynomial of order 2)
x^3  (cubic = polynomial of order 3) (this one has an inflection point = a change in concavity)
x^3 -x^2 = x^2 (x-1) (cubic = polynomial of order 3)  (this one has a dip, which would be a bit weird for population growth)
x^1.1  (any fixed exponent strictly greater than 1 will produce an upward curving graph)
x^0.5  (square root function, concave down, just for fun)
x^10000  (very sharp bend, concave up, resembling the bottom and right sides of a box)
x^0.0001  (very sharp bend, concave down, resembling the left and top sides of a box)

Aside concerning x^n:
If n was 1, there would be no curvature. You'd have a diagonal line. It n was stricly geater than 1, including non-integer values, the curve will be concave up. If n was between 0 and 1 it would be concave down. Such a concave down curve will still always be increasing, just at ever slower rates as x gets large. Higher exponents produce more dramatic changes in the steepness of curves. As the exponent increases to approach infinity, the bend approaches a sharp corner, looking like the bottom and right edges of a box. As the exponent decreases towards 0, the bend again approaches a sharp corner, looking like the left and top edges of a box. Note that 0^n = 0 for any n, and 1^n = 1 for any n. All the simple powers of x will pass through the points (0, 0), and (1, 1). The curve will start out slow near 0, and start getting quite steep by 1.

You'll notice all these graphs get very steep very quickly. Remember, we want gradual controlled population growth, not babies exploding out of airlocks. Zoom in on the graphs where they are still gently curving up. What we'll want to do is transform this small zoomed in area and expand it to match the time frame and expected population levels of the game.

For simple fixed powers of x, the area between 0.0 and 1.0 will be of most interest. Already by the time x = 1, the curve will be quite steep. Perhaps uncomfortably so for a population curve, making it difficult to manage. For x^2, the part up to about 0.5, or perhaps even as low as 0.3 looks much better.

For the exponential equation, the area where x is negative will be of most interest. The point when x = 0 looks to be about the point where managing a growing population starts to be difficult and will soon be vexing and tiresome. For e^x, we can take the graph from about -3 to 0.

Next we need to define some sort of target area for time and population. Some thought needs to be given to the unit of time. In Outpost 2 for example, there are game ticks, game marks (100 ticks), and the time period during which population adjustments run (every 256 ticks, or 2.56 marks). You might also use a real time measure, such as seconds, minutes, or hours. Perhaps the most natural unit of time is how often the population algorithm runs, or 2.56 marks. Let's say an average game should last 2560 marks, then there are 2560/2.56 = 1000 population increase intervals during an average game. (Not all of them will produce new people). Our desired time scale for the population graph is then 1000 time units (calls to the population algorithm). To win a game, you need at least 200 colonists. There may have been some setbacks though, and the player doesn't always launch the spaceship right away, so to account for this, let's say population = 220 at that point. We'll then want to transform the equation for the graph to match up the origins, scale the x range (time) so it ends at 1000, and scale the y range so it ends at 220.

For a turn based game like Outpost 1, the natural unit of time would be 1 turn, which is also how often you should call the population growth code.


This is getting a bit long, so this is probably a good place to cut it. Join us next time for graph transformations. We'll discuss the math behind matching up the origins, scaling in both the x and y, and identifying a starting population level.

The topic after that, will be some Calculus. We'll talk about the pesky time aspect of the equations, a bit about derivatives, numerical integration, and build a case for using an exponential function.
Title: Re: Population Model
Post by: leeor_net on August 02, 2016, 06:03:19 PM
And about half way through and my eyes glazed over. I genuinely don't understand this even after having read it 4 times.

Odd how I can design and architect an entire complex system but what ought to be simple math is just beyond my understanding.
Title: Re: Population Model
Post by: Hooman on August 02, 2016, 06:32:56 PM
Did you try out the online graphing calculator?

Any terms you'd like me to elaborate on?
Title: Re: Population Model
Post by: leeor_net on August 02, 2016, 06:45:52 PM
It's not terminology that I'm not understanding, it's putting it all to practical use. I guess for me the hard part about working with numerical models is that they are abstract in a lot of ways. On the other hand, I think in purely relational ways, e.g., objects and how they relate to each other. On occasion I use mathematical models because I have to and most of the solutions I come up with are clearly just me plodding through and coming up with something that's 'good enough' and leaving it at that.

It's very likely the reason I can't for the life of me come up with fragment and vertex shaders. 3D geometry is whatever, I can deal with that. Scenegraphs and world trees and all of that is simple enough.

Come up with actual equations and formulas that deal entirely with numbers and nothing else? Now you've lost me. As I've stated in the past and probably will long into the future, I'm very, very weak with applied mathematics so when I see these kinds of formulas I leave it up to those who understand the math and take their word for it.

FFS, I can't even figure out basic matrix math. I think it's lead me to some seriously bad formulas and in some cases horribly inefficient code. Look at my mouse picking code for OutpostHD, for example. You know how I do it? Using a lookup table. It WORKS, but it's by no means elegant. An elegant approach would simply use a mathematical approach but I literally have no idea how to do it. I've looked at the mouse picking code for OpenXCom and ... it literally makes no sense (it's also somewhat inaccurate but generally does the job). And yet, I just KNOW that there's a way to mathematically and elegantly do isometric mouse picking without resorting to a brute force approach.