It mostly looks like a variant of what’s currently there. I prefer the current system as I think it is a bit more realistic to simulate the resulting populations instead of evaluating how good a species is.
If I had energy, I’d make a proper diagram of the current system, but it goes roughly like this:
- (player is swimming around, and auto-evo starts in the background in order to allow the simulation to take quite a lot of time)
- For each species, generate 5 random mutations
- Simulate the resulting populations for each of those mutations, and for each species select the best one (or no mutation)
- Simulate a couple random patch migrations for each species, and pick the best one (if it is better than no migration)
- Override the results for the player species so that auto-evo doesn’t affect it. This is done because the player currently has no way to know what their editor changes would do. And also the basic algorithm currently in the game doesn’t match well enough what the player needs to survive swimming around. So those two things need to be resolved before the player species can have auto-evo affect it.
- After the player enters the editor, apply the external effects (for example if a cell dies on screen it gets a population decrease), migrations, and random mutations
- Remove extinct species (if population ends up less than 25 it is rounded down to 0)
- Add a copy of the player species to the world. This step is temporary until we nail down the species split logic, but I’d prefer a logic where if a species has enough population and there are multiple best mutations (for example due to the species being in many different patches), the species splits into two so that both halves have a different mutation.
I’m pretty happy with this algorithm, as once we get better and better population simulations, that can just be plugged into the overall framework
In fact once Nick’s or someone else’s new algorithm is ready, it can be plugged in as the population simulation step and everything else will work the same.