As everyone already knows: Auto-evo kinda sucks. There is always this optimal design, hardly any niche specialisation and often weird designs that doesn’t seem like it came from trial and error; which at the end of the day is what evolution is just over large timescales. I’ve read other suggested algorithms for auto-evo and they are probably better than what we already have.
I decided to take a different approach
Instead of doing what auto-evo does and try to simulate the process of evolution. Evolution is the simulation.
As a proof of concept, I implemented one in C. At the time of writing this it is still missing a couple features but it is already producing interesting behaviour without a player or scripted events. The simulation advances in timesteps with each timestep comprising of these distinct phases:
Environment regeneration
Environment diffusion
Migration
Predation
metabolism
Population growth/decline
Mutations
Rather than scoring species or trying to estimate fitness, every population simply attempts to survive under the current environmental conditions. If a mutation genuinely provides an advantage, it spreads because it reproduces more successfully. If it doesn’t, it dies out naturally. The “selection algorithm” is just the simulation itself.
Welcome to the Thrive Community Forums, @N4no57! This sounds very good. Funnily enough, I have implemented similar features like “having to survive under current conditions” in my Intermediates FG by literally playing every organism I random generate. Do you have any estimation as to whether the new Evolution Algorithm would be more, or less, resource intensive than the current Auto-Evo?
The current idea of the algorithm works like this: The simulation works on populations as a whole and makes a bunch of estimations with arbitrary numbers. The internal state of the simulator can generate a quite cumbersome number of populations and species but at the end there is this little “compression” stage. The idea is you don’t have to make every mutation a new species so instead it tries to compress populations and species by lineages with the defining factor currently just being innovations like new proteins, new organelles or the evolution of a nucleus. This limits how many species and populations it needs to work on every pass. As for the resource intensity… I can’t say for certainty as the number of populations and species is quite variant. The world is hardcoded at start time and even that can have surprisingly different outcomes due to randomness. I could run some benchmarks on how fast it runs on average.
Does world size have any substantial effect on results? Since in Thrive, world size dictates the number of biomes a world can have, and thus, the total number of max organisms that can occur in a world.
It depends. The world I have hard coded has only 1 patch where resources are regenerated from which is the hydrothermal vent patch. Depending on how resources are regenerated and diffused across a whole world the carrying capacity of a world can vary greatly.
You definitely need to expand the number of patches. In Thrive, small world sizes can have maybe 12-18 patches. Medium sized world can have around 25-35 patches. Large worlds can have 45-61 patches. These are estimates based on what I have seen finding World Seeds.
That is the current intended plan. I kept it the 3 patches to reduce the amount of data and make my life debugging easier. One of the features I plan to add is to be able to use worlds exported from Thrive so that I can also vary the worlds without giving myself headaches.
I think so. Depends exactly on what the event changes about the environment. The evolutionary pressure mainly depends on the environment and how the populations change the environment. So if the environment changes then so will they. The event with the meteor icon I know reduces max light at noon. If photosynthesisers exist then they will be impacted and the rest will be either doing just fine or not depending on what their primary food source is.
4 Likes
aah31415
(The maker of SitF, Radiostrocity, The Lifenote and TGBing; The Second Ascended...; And just maybe a security warning come alive...?)
12
Welcome to the forum @N4no57 !
(Been a strangely active week for user joinings…)
I am kind of afraid at this stage of development large scale changes to autoevo wouldn’t be viable for the amount of time we have at hand for purposes other than pushing on the roadmap
Fair enough. I understand that auto-evo is a big thing and that currently the focus this year is to power through the multicellular stage. I would do something but I’m not ready to touch C# yet nor am I done working on the proof of concept to a point where I am happy.
4 Likes
aah31415
(The maker of SitF, Radiostrocity, The Lifenote and TGBing; The Second Ascended...; And just maybe a security warning come alive...?)
14
The space to make major changes to the algorithms may free up in maybe 2 years given the rough plans the developers have developed. By the way, how many things you know are in Thrive are you missing from your own take? Like events or other sorts of intricancies an evo algorithm would have to deal with?
We’re always happy for anyone to try and make improvements to the performance and/or auto-evo! Though I would normally recommend working on a fork of repository so that you can actually see the context things have to work in.
Not sure I really understand from your description what and where the differences are.
5 Likes
aah31415
(The maker of SitF, Radiostrocity, The Lifenote and TGBing; The Second Ascended...; And just maybe a security warning come alive...?)
16
They probably mean the organisms are more intriguing than what we got going on in Thrive
I was never the one to be great at explaining my code. I’m more for letting it speak for itself. Buuuuuuut, if I properly understood how auto-evo works I could give a better explanation. My current understanding from playing in the game is everything has an attached fitness which the algorithm tries to maximise. My understanding of it is it’s kind of an optimiser. Also I was trying to avoid C# before I truly had something a little more tangible than just an idea.
5 Likes
aah31415
(The maker of SitF, Radiostrocity, The Lifenote and TGBing; The Second Ascended...; And just maybe a security warning come alive...?)
18
I think next you should move on to adding the stuff in Thrive itself so we can see how much of an improvement there is really and if there are any drawbacks to adding such a new algorithm like increased autoevo times for example
I think that’s a reasonably accurate description. There’s a tree of score calculations that are dependent on environmental conditions, with associated mutations for each node of the tree. The algorithm maximises scores, and then distributes population from each energy source based on proportion of the total score.
This is where I think a lot of the issues people run in to with auto-evo stem from. The whole idea is it’s supposed to be like evolution and reasonably plausible. either try to mess around with the tree of calculations which probably is gonna be time consuming, difficult and idk if that would work, see the other auto-evo algorithms work and try an implementation of that or take the same route I did with auto-evo literally being evolution through simulating living organisms over a set number of time steps. I’d be happy to fork and try to implement it in Thrive. A few pointers on where to start would be nice.