So here’s a very rough outline of what the patch system should do, from there we can work on how.
Patches are locations in space, which will eventually be geographic regions of a generated planet. The current play area will be one of those patches, and the rest of the planet will contain many more patches. As mentioned many times before, the area outside the current play area will be simulated, but in less detail than what the player sees.
Each patch has a an environment, for now that can be a predefined biome (deep sea, shallow sea, freshwater, ocean vent, etc.), but this will eventually be determined in part by climate.
Patches contain a number of species, a subset of all the species on a planet - some species will not be able to survive in all patches due to environment, others will not be present in a patch because of geographical isolation (think marsupials not existing outside Australia). Species within a patch have a population (from population dynamics), and may evolve in a different direction to the same species in other patches, leading to speciation (vicariance).
The patch system has two responsibilities:
- replicating the compound, population and auto-evo systems across multiple independant patches. I.e.: the CPA system running in each patch does not need to worry about the state of other patches.
- distributing compounds, species and populations amongst patches.
This can broadly be seen as a reaction diffusion model, where the dynamics within a patch are calcuated in one step, and the dynamics between patches in a seperate step.
Implementing the above is mostly a case of moving a lot of global systems to local, replicated systems. Where we currently have one CPA system, operating on the singular playable area, we need a seperate CPA system for each patch. More specifically, we need to replicate the data CPA operates on, and tweak the system implementation to iterate over that data - we don’t need multiple systems, just multipel data instances.
The only really complex part of this is balancing compounds, populations and mutations. We need to ensure that compounds and population aren’t lost or gained magically as they’re shuffled between patches, which is relatively simple.
We also need to decide what happens when populations of the same species in neighbouring patches evolve in different directions. Do the mutations merge, does one dominate the other, does speciation occur? Not massively complicated, but requires more thought than I’m going to put into this post.
Finally, we need to think about how the player interacts with the patch system. At least in the early stages, there’s no way an individual creature can move from one patch to another within its lifespan, and that won’t change until we have relatively large (probably flying) creatures. That means that migration happens on a multi-generational timescale, and is best handled during a reproductive step, i.e.: before or after the player goes into the editor. At this point we may give the player the option to encourage their species to colonise a new patch, to move population between patches, or to choose to play in a different patch when they exit the editor. We may or may not want the player to control the evolution of their species in other patches.