Code center > Suggestions
Population Control and selection pressure without costs
EricL:
Even though it was my idea, I've long had an issue with auto-adjusted costs as the primary mechainsm for population control in evo sims. The thesis has been that as bots evolve, they compete for limited resources, adapt, become better competitors and thus we require steeper costs over time to keep the population in check. But this thesis only works if changes in costs are gradual - oh so gradual - so that selection can drive adaptations over time. Alas, given our limted cpu resources and small population numbers, auto-costs has to spike up the cost multiplier many orders of magnitude faster than evolution can possibly adapt in order to prevent sims from grinding to a halt when population flurries occur.
Evolution can't provide adapations to sudden, unpredictable, seemingly unexplained bursts of increased costs which exhibit no locality to the event that caused them. Our sims and popualtions are so small and fragile relative to something like the real world, that the explosive reproduction of a even single parent organism can spike the costs for the whole sim. That just ain't right.
I've been toying with a new approach, one where costs in a sim can be fixed or non-existant. Population is controled through prediation. The problem with prediation as a menas for population control in the past has been keeping the preditors in line. Generally, they either desimate the non-preditors and then die out or they overbreed and swamp the sim or get infected by a virus and stop doing what you wanted, etc.
We now have all the options we need to prevent unwanted mutation, breeding and virus infection of a species. But the preditors still don't have a way to know when to cull the herd and when to lay off.
So, I've added two new sysvars in 2.43b.
.totalbots (401) is read only and returns the total number of bots (including corpses, autotrophs, etc.) in the sim.
.totalmyspecies (402) also read only, returns the total number of bots in the bot's "species".
Now, evo sim folks can build a preditor that respects the total sim population and controls their own numbers. I've been playing in my own evo sim with a version of Animal_Minimalis that stops feeding when the total sim population drops below a certain number and stops breeding when it's own population rises above a certain percentage of the total. If they are configured as virus immune and prevented from mutating, they become an effect means of population control in an evo sim - part of the environment in essense - one other bots can potentially see, defend against and run from.
More sophisitcated strategies are possible. Preditors can choose to move faster, bite harder, etc. as populations grow and scale back their attacks all the way to doing nothing as they decline. They can even read the .totalmyspecies memloc of perspective victims and decide whether to prey on them or not.
The important point in all this is that unlike random cost spikes, evolution can adapt to preditors. Over time, I would expect to see preditor avoidance DNA selected for.
Comments?
googlyeyesultra:
Very interesting. I wonder what I can do with this for F1. . .
Also, thanks for picking memory locations no bots (at least that I've seen) use.
One thing I have to wonder: If totalbots includes corpses, then won't a predator continue killing, even if most of the remaining enemy bots are corpses? Essentially, how will it tell how many are dead and how many are alive? Does totalmyspecies work the same, and also return corpses of my species?
EricL:
Yes, it is possible for preditors to feed beyond the intended limit because corpses are counted in the total. But corpses decay away and I think you would have to pick an extremely slow corpse decay rate for this to be an issue. If people find this to be a problem going forward, I can add a .totalcorpses or something similar.
Corpses are NOT currently counted in .totalmyspecies. Corpse is essentially it's own special built-in species, similar to the way graphs work now.
We actually have a great deal of free memory space remaining - only 217 memory locations are currently reserved by the system. Bots can use the rest for their own purposes of course, but even so...
googlyeyesultra:
We might want to (perhaps when we add in the egrid and what-not), set up a large block (preferably at least 100 contiguous variables) that are reserved exclusively for free variables. Since we'd be breaking most old bots anyways, we could reorganize which sysvars are where.
Martian:
--- Quote from: EricL ---Comments?
--- End quote ---
I like it.
Navigation
[0] Message Index
[#] Next page
Go to full version