This short post will cover my proposal on how game will handle dynamic patch environment in general. I will probably come up with some things during writing it so sorry if some thing don’t make sense
Species - Compound Balance
Instead of removing or adding compounds depending on species count difference, each lack of individual is worth compounds free in the environment.
Each hex will be worth x amount of compounds, so it total removed compounds from base patch concentrations can be presented as follows (for example - ammonia)
ammonia - (species * its count * hex count * per hex modifier)
That would calculate for each species of course.
Now, species have processes, these would also get its way into the code
ammonia - (species process input * modifier) + (species process output * modifier)
(brackets for readability)
Now that I covered basic compound handling time to get to more fun stuff but they might be more controversial so treat them less seriously.
Patch Events
I want to suggest here 2 types of events: “Shot” events and regular events. Shot events would happen outside of editor, while player plays its species, and would be registered to affect compounds once editor is entered. Examples could be volcano eruption, meteor strike and generally short in terms of timespan things and affect 1 patch at a time. Regular events are created upon entering editor and these would include glaciation, long term volcano eruptions etc. This way player can experience some events in-game and also take time to think strategically in editor.
Sorry if this post is out of shape or silly but it’s my 2nd thread on this forum and also I mentioned I could pick up dynamic environments once planet generation is done.
I think the desire behind dynamic patch conditions is to facilitate the great oxygenation event and make the game be able to start with 0 oxygen anywhere.
So I think rather than species members taking away compounds, it’d be better to calculate the overall all processes that all microbes do (and weight those by population) to then get a balance for environmental compounds. Then there should also be compound exchange between adjacent patches.
This has been attempted before but the work was not completed due to the difficulty it is to get the system to be stable and not oscillate a ton.
Though it could be a worthwhile idea to also model how much compounds the microbe’s cells take up and lock away from the environment. But that would be much more complex thing to get working also with auto-evo energy calculations impacting maximum possible populations. Also I feel like the gameplay effect for the player would be quite bad as I’d expect both ammonia and phosphates to be always close to zero, meaning that we end up in a situation where basically only passive reproduction is possible.
I soon want to turn attention towards creating a solidified concept streamlining a lot of previous thought strung all over the place into something a bit more cohesive. Before I do that, I want to discuss implementation details based on the thoughts raised by @Titan here:
I think Titan brought up a very nice way of organizing and presenting information on a pretty complex area of our simulation, where a lot of things can really go wrong and where we want to provide some level of standardized experience. It makes me think that if we wished, we can represent a lot of information like temperature and compound changes through these Patch Events/Traits. Things like representing warming with a temporary “Warming” trait, or dropping temperatures with “Cooling” instead of having a really complicated system in the background doing these potentially hard to balance events.
I think the assumption here has always been that there will be this really complex planetary simulation dealing with matters like this. I’m not necessarily against this at all, but I guess my question is: are we able to/should we simplify that down? Or would it be easier from a software design perspective to deal with things in that more dynamic way?
Simulation and communcating to the player are two seperate things. We can have the most fancy complicated code in the world for calculating temperture and light level, and decide if we want to call the patch a “ice shelf” “hot sprint” or “sea floor” with a couple if statements.
To me, the bigger question is: how much detail and complexity will the player be able to notice or react to in any meaningful way? I can totally see Thrive players wanting to watch percentage numbers go up and down generation to generation, but unless you’re looking for it I imagine most players won’t notice until an organelle stops working like it used to.
Yeah, that’s a good point about communication & complexity.
Relating to things like temperature, sunlight, and honestly the actual numbers themselves, I think that can be communicated in that sort of “patch trait” descriptor way on the patch selection screen. For example, putting “Glaciation” on a patch’s descriptor can communicate falling temperatures.
With organelles though, that’s a more complicated thing to communicate to the player. It’s hard to think “my current build works right now, but if CO2 decreases by 1.2%, boy will I be in some trouble!” If players have multiple metabolisms and cellular processes, it would be hard to present information that says something like “current build would have net positive ATP with atleast x% Oxygen, x%CO2, etc.” And of course theoretically, they can look to the graphs to see changes. But especially if the early world is more choatic, the whole hard-to-rationalize-percentages thing is still present.
When is the player supposed to notice the patch has changed? Should there be a notification screen like the “your planet blew up: game over” message we always joked about? Do we expect players to NOT skip past the auto-evo report each editor cycle in some coming version of the game like everyone does now?
In the editor info dump, I think the best way to do it is to indicate to the player that the patch is changing in X turns with a bit of information as to what is happening. For example, “the [patch name] is getting colder. Patch change in y turns.” That way, the player has some information as to what is going on.
That is, assuming they read. I’d assume we need a better way to let the player focus their attention; perhaps a filter allowing the player to see information related to the environment, events, specific species, etc.?
Gameplay wise though, I think flashing the edge of the screen a cool blue or a warm red very briefly upon spawn depending on the temperature change could be a good visual cue, making the player think “oh, something is happen in the world”. And ultimately, the depths will remain stable temperature wise atleast, always remaining as a shelter from the more volatile surface patches.
And I think world ending events like that should only be enabled by a button on the eventual world customization tab. And should occur the second you start the new world with a pop up saying the planet exploded, as a joke alluding to our conversations with the community requests for world ending events. It personifies our official response of “why would you want a chance of the world ending and all your progress being lost” in game.
That could work as part of the solution. Though we need to be careful to not overload the player, so only truly important icons should be present so that there isn’t too much unnecessary noise causing players to eventually just ignore all the icons.
Also we still need something to notify the players who skip over the patch map once they’ve found a patch they like (for example I’ve noticed one Youtuber who usually clicks the “cell” tab directly quite often and skips the patch map entirely).
That could work, but I feel like small environmental changes don’t warrant that kind of “you must absolutely check this tab” thing. Maybe the cell editor screen could say something about the changing effectiveness of the player species (in the current patch, if there is a difference or upcoming big change)?
Here is the master concept for most of what we have related to dynamic environments, available for some discussion before implementation approaches. If someone who is more knowledgeable on climate science would be willing to contribute, I’d very much appreciate that; my knowledge over the area is lacking.
THE DYNAMIC ENVIRONMENT MASTER CONCEPT
What should we expect from a dynamic environment mechanic in the Microbe Stage?
We want to represent the evolution of a planet’s biogeochemical processes as life proliferates and influences the atmosphere. The distribution of resources, gasses, and the resulting climate changes from these changes. This will provide scientific accuracy and storytelling.
We want to represent some level of shifting resource supplies and outputs depending on the characteristics of the organisms in a patch. This will emphasize strategy.
We want there to be some capacity for patches and the map to change overtime as geological eons pass. This will provide a level of dynamism through each playthrough, and create new situations for the player to deal with.
We want to represent environmental events that are significant to the evolution of life on Earth, such as glaciation, warming, oxygenation, and catastrophic events.
General Playthrough Experience
Flux - Players will spawn into a world with cloud resources that are volatile and unpredictable. Resources will dramatically and unpredictably swing on a young planet, especially near in the depths; surface patches will change as well, but generally have more identifiable “trends”. This will make players either play it safe, retaining a basal and tweakable organism, or risk specialization, becoming more complex and having a head start at the risk of their food source rapidly diminishing. This fluctuation will gradually taper down and settle on an average, seeding initial resource distribution dependent on the characteristics of your planet.
Oxygenation Crucible - Oxygenation begins slowly at the surface, slowly spreading deeper with every generation. Resource distribution is affected, as hydrogen sulfide diminishes and iron depletes in oxygen-rich environments. Along with the inherent toxicity of oxygen, organisms are challenged and forced to redistribute as available resources change in behavior. To top it off, rapid oxygenation dramatically increases the likelihood of a Snowball Earth event, presenting an even greater challenge to organisms. Players must manage environmental changes while marching forward and achieving the nucleus.
Stability - After the advent of oxygen and the initial crises, the climate settles into more predictable trends. Oxygen will generally increase, while iron and hydrogen sulfide are bound more to deeper waters and more exotic environments. Periods of glaciation and warming happen, though usually to a lesser extent than the swing seen in Snowball Earth. This stability paves the way for more complex life.
How Should the Compounds Generally Act?
Hydrogen Sulfide - Initially widely present, though will diminish with time as oxygen spreads, especially at the surface.
Iron - Similar to Hydrogen Sulfide, although slightly more sensitive to oxygen.
Oxygen - Initially non-existent, oxygen will appear as photosynthetic life becomes more prolific. Gradually increases.
Carbon Dioxide - Carbon Dioxide will start off very high, representing the volcanism of an early planet. As time progresses, it will gradually decrease as the ocean absorbs more carbon dioxide (note, does this mean that a patch can have increasing CO2 but still cool as the climate cools?). Carbon dioxide will influence the temperature of the planet, influence plant productivity, and impact calcium carbonate membranes.
Nitrogen - Nitrogen can remain pretty stable since it tends not to have a direct impact on the planet’s atmosphere and since a lot of our processes in game don’t really utilize it, though it should interact with nitrogen-fixating plastids.
Glucose - Glucose in the game acts as a proxy to the free organics available in an early bioproductive ocean. It will reduce as it does now.
Phosphate & Ammonia - Both will act somewhat similar and will also gradually reduce, though not to the same degree as glucose. Certain environmental events can also cause phosphate/ammonia spikes and dips.
Temperature - The planet should generally start off warmer than it is, and gradually cool down, allowing for the emergence of cold regions. Temperature will dramatically plummet in global glaciation events, but will return to stable temperatures gradually. Temperature can randomly warm or cool through glaciation and warming events. Higher temperature environments will slightly reduce the amount of oxygen present in a patch.
Light - Light will start off lower than usual, but will increase as the atmosphere gets less hazy. Light will generally be stable outside of environmental events, which will dramatically challenge photosynthetic life. It will have a slight influence on temperature.
Patch Dynamism
The map will change dynamically through two mechanisms:
Surface Patch Changes - Most changes to the environment occur on the surface - shifts between estuaries and regular surface water, frozen patches, etc. The depths will remain generally stable, allowing players a refuge.
Patch Connector Shifts - Some patch connections will appear and disappear, sometimes outright denying movement from a patch cluster.
Surface patches - Epipelagic, Shallow Seas, Estuaries, Frozen Seas, Tidepools - can change into each other.
Epipelagic can become either Shallow Seas or Frozen Seas
Shallow Seas can become any.
Frozen Seas can become any.
Tidepools can become Shallow Seas, Frozen Seas, or Estuaries.
Estuaries can become Shallow Seas, Frozen Seas, or Tidepools.
Environmental Events
Environmental events represent global trends and phenomena which can either randomly occur or occur as a result of compound changes. Here are some existing concepts:
Volcanic Eruption - Increases CO2 & decreases sunlight over a certain area depending on size. Can be small, affecting local patches, medium, effecting a patch cluster, or large, affecting multiple patch clusters.
Meteor Impact - Decreases sunlight over a certain area, and causes temporary dramatic shake up of compound availability. Increase in CO2, but not to same extent as volcanoes. Can be small, affecting local patches, medium, effecting a patch cluster, or large, affecting multiple patch clusters.
Cooling - Decrease of CO2, causing cooling weather. Frozen seas more common.
Warming - Increase of CO2, causing warming weather. Frozen seas less common.
Glaciation - On surface patches, indicates a change to or presence of Frozen Seas. In non-surface patches, indicates the formation of ice shards.
Snowball Earth - Rare event in which the entire planet dramatically cools, causing most, if not all surface patches, to freeze. Very likely to occur after initial introduction of oxygenation.
(Bonus) Earthquake - Legacy concept; all currents flip in the current patch.
Global Atmospheric Scores
Buckly proposed a way of dealing with dynamic atmospheric gasses. I linked the post above, in case it can be used as inspiration for the actual handling of dynamic compounds. I also think it’s our best existing concept, though Buckly had mentioned passingly on a potential improvement he is conceptualizing.
Planet Editor
The planet editor ties heavily into dynamic compounds/climate, but concepts for it aren’t very fleshed out currently. Would it be best to have a planet editor concept ironed out, or is it possible to tack on the planet editor afterwards?
Thanks for putting together this summary. In general I think this is very good, but I fear that some of the ideas regarding volatility of the early world might be way too difficult for a first time player without extreme tutorialization and warnings about certain attempted playstyles. So I’d like to see the other stuff before adding initial game instability as that’s the most critical time to retain a new player and get them introduced to Thrive.
Good to hear that this is useful. I do think the variability in the early game could be a good way of introducing some sort of uncertainty and variation for a portion of the game that can be pretty repetitive, but I definitely see your point in wanting to see how the basic simulation will work before screwing with it.
Another way we can approach if it sounds better to you is just by having environmental events, like volcanic eruptions and meteor impacts, be more prevalent and potent in the earlier game. There will be variation and uncertainty, but atleast the “norm” will be some form of stability for the patches to turn to after periods of instability, and the uncertainty is bound more to specific events as opposed to the map itself. And the variation will be more predictable - instead of literally anything being on the table, a volcano will make the player go “oh okay, CO2, sunlight, and warming”, a meteor will make the player go “okay that’ll be more unpredictable”, etc.
One thing I wanted to purposefully mention regarding oxygen that came to mind after playing with the experimental build. It should probably be made so that once a certain level of oxygen is reached in a patch, oxygen won’t dip below this level.
Let’s say we have a “checkpoint” at 5%, and another at 10%. If oxygen reaches 5%, then it can’t possibly go below 5% ever again. It can climb up to 9% and then dip back down, but only 5% at the lowest. This will help to ensure that progression is stable, and players won’t suddenly inherit an anoxygenic world when they are a eukaryote. Different patches can have different “checkpoints”. For example, surface patches can have checkpoints for up to 20%, while deeper patches might only have a checkpoint for 10%.
While this is a pretty arbitrary rule, I think it has direct importance for progression. If others are willing to implement a more natural method of ensuring an oxygenic baseline, then go ahead.
My thought is that it would be much nicer to get a natural equilibrium working (like there’s on Earth, currently). Though as I’m unsure how to get the numbers and algorithm to work like that, these minimum thresholds that cannot be fallen below again might be a “short term” (I know that in software development there’s nothing more permanent than a temporary solution) alternative.
So the first release of compound production has resulted in some very cool gameplay responses from our community. It is apparent that the atmosphere can result in some outright impossible or unrealistic environmental conditions, such as these two 100% oxygen-concentration environments on the community forums:
Which would result in what is essentially a fireball Earth in real life. There have also been instances of certain important compounds being completely absent in patches, such as 0% carbon dioxide, making photosynthesis impossible. We can get away with some intense ecosystems since a lot of the Microbe Stage takes place on a planet with incomplete biogeochemical processes, but all-in-all, we should introduce some control on compound frequency - for both balancing and realism purposes.
An idea GameDungeon brought up was having certain compounds have a constant amount added each generation - for example, +2% carbon dioxide every turn - to represent geological processes and other important systems occurring in the background. I think that sounds like a good way of adding some balancing, enforcing a soft “minimum” amount of carbon dioxide. I can also see these features being pretty easily interloped with planet customization, where having a more geologically active planet means a higher amount of carbon dioxide being added each generation.
Along those same lines, might it be useful to have compounds be subtracted against once compounds reach a certain threshold, to represent geological recycling and chemical processes that naturally balance out excesses? For example, if we decide that, say, 30% oxygen is too high for a patch, 1% of additional oxygen will get removed automatically each generation alongside any biological activity for as long as the oxygen amount is higher than 30%. This will allow us to enforce soft caps as well. This can also tie into planet customization as well, and if we wish, can tie into a bit more advanced of a compound simulation - if iron is higher than 5%, then the “cap” for oxygen is lower, and the automatic reduction happens much earlier (that could be complicated to track if we make iron get eaten up by oxygen as well).
I think approaching “mins” and ‘maxes” with compounds in this manner would be a nice way to create balance while not outright enforcing strict conformity. If the player inhabits a patch where biological activity forces carbon dioxide down even with a soft minimum, then we can accept that ecosystem as an immensely unique patch. We just don’t want to make such conditions overrepresented in frequency.
I think all of these cases have been with the experimental compound production enabled. So it is clear that the volcanism (as a base co2 generation) I added for the normal photosynthesis compounds production, is working relatively well.
And we seriously need a big warning text under the checkbox to tell players to not enable experimental features unless they are really sure. And if they enable it they must disclose that whenever they are reporting bugs or balance issues.
Exactly how it is in the default version.
At this point I think we have to discard all feedback about the experimental compound production, because it just is so unbalanced and non-working that it’s not worth it to try to figure out every single thing wrong with it.
On the roadmap there’s an item to stop representing the gases as percentages, which will help a lot. Though a relative soft cap might be necessary, but we don’t fully know before trying.
One idea I think I might try to do soon (as the above item isn’t fully about this, but more like displaying stuff as ppm format so that the players aren’t fooled into trying to sum up the things, which basically everyone does when given percentages as everyone is too familiar with those) is to switch up how the calculations are done.
Basically the idea is to calculate the volume for each patch, then multiply the volume by the percentages to get absolute values. Then the change calculations are done in absolute values before converting to percentages back. This ensures that the percentages can never go above 100.
