Your population takes 3 values (number of workers, kids, and scientists).
Population growth takes 3 values (growth progress of workers, kids, and scientists).
Population death takes 3 values (death progress of workers, kids, and scientists).
Now I understand. I thought primarily from a coding standpoint: individuals in a matrix vs individuals in objects, which is why I didn't get it.
While this does reduce realism and immersion, and potentially introduces odd abstractions in population management, this does reduce the amount of data processed to practically nil.
Furthermore, this is a lot simpler to implement. At the start of a turn:
1) Calculate the changes in the population pool.
2) Loop through the jobs at the start of a turn (based on job priority, I guess), keep 'filling' them until we run out of people.
However, from a coding standpoint, I do have a question: how complicated and abstract will the formulas get (assuming the Outpost 2 method isn't copied to the letter)?
If population death works based on a number, and every turn this number increases: numDeath = numDeath + 0.01 * numPop. Then we add general medical research, which leads to numDeath = numDeath + 0.001 * numPop. An negative event happens, so numDeath instantly increases by 0.05 * numPop. numDeath > 1 means killing floor(numDeath) individual(s), and numDeath = numDeath - floor(numDeath). I'm not sure I understand the effects of morale; does a high morale increase progression towards a death-event? That does not feel proper. It's been a long time since I played Outpost 2, so I might not get it.
Morale itself, however, can become very complex very quickly, since there are a lot of factors that can be taken into account. Furthermore, if the formulas incorporate a lot of other factors, they will potentially reach a level of abstraction that makes bug-hunting difficult. I remember a game with a similar approach for a worker pool, that would roll over zero at some point, leading to an infinite worker pool and a crash. Also, due to the formulas being abstract, it would be quite difficult to get them to approach something believable (although this might be less of an issue here).
On the other hand, this does feel quite similar to what Outpost originally did. Also, the other method (population as object-individuals) does have some drawbacks. On the computational side, it is slower. Of course, the amount of operations per individual should be relatively low (a small 'does it change?' operation should take care of most of it), and steps can be taken to reduce this (infants and children in a pool as a single number would be a VERY good idea, possibly ignore retirees as well), but it'll always require more computing power than the population-as-a-number-approach. Second, all supporting functions would be inherited from the 'person' class, and should be very easy to understand, but would still take up a bit of time to code. Bug-hunting should be easy, though, since the level of abstraction is a lot lower.
Some stuff can certainly be improved from the original, and I do like immersion and storytelling, but it does deviate from the original. I think I'll mount the fence for this issue.
