Is there a plan of making sort of dev builds.
Making dev-builds is kinda pointless because in my current plan any sort of UI is literally the second to last step. The last step is “see if you can turn it into an actual mod instead of a separate program”.
So unless you have basic coding knowledge and access to the source code the only thing you’d be able to do is run the same scenario over and over again.
In other news I tried to get the ‘collect compound clouds to reproduce’ thing working today, but I’m having a hard time balancing it.
I’m also being plagued by an annoying bug where the order in which you enter organelles into the species has an effect on the compounds they can produce.
If you first give it an organelle that costs ATP (e.g. nitrogenase) and then one that produces ATP (e.g. mitochondria) the species correctly realises it can use the mitochondria to make ATP for the nitrogenase.
But if you order them the other way round it just goes
8 Likes
Time for an overdue update:
Today I overhauled the way reproduction worked.
Previously I was doing reproduction exactly the same way Nick was: Every microbe has an arbitrary reproduction factor. For every full timestep spent reproducing they create a number of new microbes equal to the reproduction factor (set to one in the previous updates). This has two unrealistic consequences I’d like to fix:
- Reproduction takes equally long for every species. This means that giant eukaryotes are taking just as much time to reproduce as tiny P. Thrivium (who breed like rabbits in the real game).
- Food supply is the only limit to how many microbes can exist. This means that autotrophs could keep exponentially growing their population forever, filling the entire patch several times over.
In the simulation, I made microbes gather and compete for clouds of ammonia and phosphate just as they do for food. The amount they need to collect to create one new microbe is based on the composition of their organelles, taken from the source code of the real game. There, I noticed to my HORROR that metabolosomes and thylakoids both cost LESS than cytoplasm. I resisted the urge to correct this because it doesn’t make sense, and will adjust my speedrun strategy in the future.
Anyway, this fixes both issues:
- Now reproduction takes longer depending on the cost of your organelles, and how fast you are at gathering compounds. P. Thrivium has an edge over giant eukaryotes in both departments.
- Because there is only so much ammonia and phosphate in a patch, there can only exist so many microbes at once. Once all the compounds in the patch are used up, that’s it. Naturally, if a microbe dies, he deposits his compounds back into the patch. Otherwise patches would run a net loss and die out over time.
Here are some example scenarios:
A cyanobacterium (1 thylakoid, cell wall membrane) is alone in a patch, what will happen now that he has to work with limited resources like this?
It still grows (almost) exponentially at first, but the graph levels off once ammonia and phosphate run out.
For our next experiment let’s see what happens when we make P. Thrivium compete against Ammoniae Aedifex (one metabolosome and one nitrogen fixing plastid). A. Aedifex will be able to make ammonia out of thin air, but constantly spend ATP doing so:
Unfortunately A. Aedifex was not able to keep up with the ATP costs and quickly starved to death. A look into the internal variables reveals that they were not able to collect glucose fast enough to keep up with their ATP demand once it got below a certain density. Once they go extinct P. Thrivium briefly peaks due to its new lack of competition, and then falls into its equilibrium population.
For the final experiment I want to test how much better metabolosomes really are than cytoplasm. So I pit P. Thrivium against P. Metabolosomus (one metabolosome):
ngl I was completely taken aback by this. P. Thrivium actually held his own! This is the first time in all my testing that a species was able to survive in the face of superior competition. Not only that, but he never actually reaches a stable equilibrium, instead bouncing back and forth between two populations. I suspect that this is a fluke of how various numbers are discretised (like the number of clouds, number of microbes, etc.) and that the population would simply reach 72 in a continuous model. But who knows, irl sometimes shit like this happens too.
I am beginning to suspect that the patch I’ve created might be a bit too harsh, if even super-optimised species like P. Thrivium and P. Metabolosomus are barely clinging on with less population than they started with. That’s why I’ll see you next update when I’ll be recreating some of the patches that are actually in the game.
Until then hmu if there’s some scenario you’d be interested in seeing.
10 Likes
what about glucose decrease? Will you add it to tbe simulation?
Glucose decrease doesn’t need to be added to the simulation. Microbes already eat clouds of glucose, causing them to permanently disappear from the environment.
Currently I am adding an arbitrary amount of glucose to the patch each timestep to ensure that the glucose never completely runs out. This is because predation isn’t a thing yet, so heterotrophs would just die when the glucose runs out.
I’ll address how the simulation handles environmental compounds in a future update.
3 Likes
THE ANT ARMY HAS ARRIVED
1 Like
A few days ago I added enviromental variables to the simulation: Enviromental gases like oxygen and CO2 can now change the rate at which microbes can run their processes, affecting how much food they need, and whether they’re able to survive at all (with any amount of food).
Vice versa, microbes are able to affect their enviroment: Photosynthesisers produce oxygen and consume CO2, Aerobic microbes consume oxygen and produce CO2, etc.
This seems to have caused, to put it lightly: ‘Complete Fucking Chaos’.
Populations wildly swing all over the place, no equilibrium ever appears, and I have yet to find a scenario that doesn’t end with everyone dying at some point. I could keep trying to balance this forever, but I believe that’s pointless: This isn’t some wild outlier, it’s an inherent symptom of the way my (and Nick’s) algorithm is built.
We go through the whole scenario month by month, and just sort of hope that after a certain amount of months an equilibrium population will just show up. Every month we also change the amount of compounds and enviromental variables of the patch based on the kind of creatures present, and the amount of creatures changes based on the enviroment present, and it’s a loop. Do you see how quickly this could spiral out of control?
That’s why I’ve decided to do two things:
-
Change my algorithm with a rather weird assumption: Microbes do not directly affect their patch while the population algorithm is still running. Patches are large and ancient, and they do not undergo dramatic changes on a month-by-month basis. For example: If a microbe eats a cloud of glucose, the next month that cloud will simply respawn, no permanent change having happened. If a microbe produces oxygen, that will be ignored by the population algorithm. Changes to the patch can still happen, but they happen over the course of entire editor cycles, not months.
This has some advantages. It makes point 2 (see below) easier to implement. It vastly reduces the amount of chaos in the system. And it makes for a much more player-friendly experience. When players sees in the editor that ‘Glucose: 4%’, they can be confident that that number will stay for at least this editor cycle. They do not have to take into account that glucose could suddenly drop to 0% halfway through running the auto-evo algorithm when they are making their microbes. -
I will (at some point, probably once the discrete version is done) convert the population algorithm into a continuous function, that can be solved directly for the equilibrium population, where Births = Deaths.
Previously I considered this an optimisation, to be done in case the current approach took to long to calculate. Even if we ignore that: yes, it will almost certainly take too long to calculate, I now see that this is not an optimisation but a neccesity. Finding an equilibrium population by calculating the population every month from some starting condition is ridiculous to begin with. If I want to find the equilibrium population, then I must calculate the equilibrium population. Not some incidental stuff that may or may not end up being the equilibrium population.
I might be busy impementing point 1. for a while, but after that I’ll see you in the next update. There, we’ll run the new and shiny population algorithm for a couple of patches that are actually in the game, and see how different species do in different patches.
EDIT: I should add that 1. will not revert the fact that microbes have a limited amount of phosphate and ammonia to work with, because in my model microbes are simply seen as little bags of compounds within the patch (just like compound clouds). A microbe could be built by taking 2 ammonia and 2 phosphate out of a cloud, then die depositing 2 ammonia and 2 phosphate back into a cloud. That’s not considered a ‘net change’ to the patch anymore than taking some ammonia from one cloud and moving it to another is a ‘net change’.
8 Likes
Time for another update:
Today I implemented point 1. from the above post. No compounds (enviromental or not) can be permanently added or removed from the patch anymore. No more burning all the glucose. No more dumping CO2 in the atmosphere. No more blindsiding the player with Great Oxygenation Events. Party’s over.
I also converted all the biomes from the real game into my simulation. This means that we’ll now be able to run scenario’s in different biomes, like the coast or the vents.
Here are some results, in this case we put P. Metabolosomus (1 hex of metabolosome) and a cyanobacterium (cell wall, 1 hex of thylakoids) into the pangonian coast patch:
As you can see a couple things changed:
- We have succesfully prevented most of the chaos resulting from stuff like food shortages and oxygenation events. Both graphs seem to have a fairly logical progression from the starting population to an equilibrium.
- The equilibrium takes much longer to reach. In fact technically it is never reached, as the species populations are now asymptotic (it’s just that we round the population to a whole number). In this case it took about 40 months to reach equilibrium, where before it took only 12. It took about 2.5 seconds to simulate all of that for just 2 species. This is not as much of a performance liability as it seems: In the continuous algorithm it won’t matter much how many months we have to simulate, because we don’t need to loop over every month anymore, only the final month. Also see point 3:
- Long before equilibrium is reached we are already approaching it. This means we can ‘cheat’ by only simulating a fraction of the months needed, than just extending the graph a bit in the direction it was already going. This approximates the population we’d reach if we left the algorithm running for an infinite amount of time.
I’ll see you in the next update where we’ll be looking at a more exciting topic: the food web!
5 Likes
D: Some of us want to ruin planets in the microbe stage, sentiant.
1 Like
You can! It’ll just take multiple editor cycles.
every1 gangsta still someone finds a glitch to circumvent this
The amount of ants in this fourm is just Amazing
4 Likes
welcome
(To our community)
Welcome another ant!
Hello fellow ant.
Our brotherhood expands further
1 Like
Can mods still change people username and profile pics? it be cool to have an ant apocalypse like the goat apocalypse.
1 Like
The REVOLUTION is coming.
2 Likes
Perhaps this is because primordial Earth’s biosphere had more types of biochemical processes, which could have led to an equilibrium, whereas the current game doesn’t have that many types of processes, which could eventually be fixed (if only we had more programmers :-]).
Wouldn’t the cyanobacterium have lower population at the end since the heterotrophs would eat them for glucose? Unless that is part of the food update.
Just a sidenote: in your graph, we can see the numbers but it would be ideal if you named the axes and specified their unit if needed. Also the title should be a little more accurate than “Pangonian Coast”. I would have suggested to name it “Population variation based on environmental input (Pangonian Coast)”. This methodology would be useful since it makes the reading a lot easier.
When is the next update?