Patch Dynamic Environment

Gameplay
21

I think we should exclude direct population changes from the events as then we’ll need protections for the player as it is going to really suck to lose the game due to a random event…

I think we should avoid these kind of trigger conditions for now as I foresee quite extreme difficulty in balancing the triggering conditions to make sense.

Well we don’t really have currents in the game and even if they were flipped it wouldn’t actually really impact anything whatsoever, just the direction the currents would push objects. So I don’t see it worth the effort at all to add this.

Patch type changes is also something not really supported by the game architecture.

Also very difficult from programming side.

Here’s my adapted concept with anything that is hard to program stripped away:

  • Surface volcano eruption that increases co2 on surface patches and some other compounds more locally
  • Meteor Impact - Decreases sunlight over a certain area, and causes temporary dramatic shake up of compound availability. Population impact depending on proximity. 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.
  • Glaciation / snowball Earth / Cooling: reduces temperature and sunlight in surface patches.
  • Warming: increases temperature in surface patches and makes ice shelf patches have more sunlight
  • Irradiation: I guess we can technically have this as this isn’t too difficult to program but doesn’t really add new gameplay potential as temporary radiation won’t help much, but does add some extra environmental hazards. Radiation chunk spawning increase. Occurs rarely in shallow oceans or the ocean floor.

So that’s my adjusted list of 6 events we could add and, I think then be perfectly happy with the patch events system.

22

Understand the rest, but I will say that I think the community would be disappointed by having a snowball Earth event without any actual presence of ice beyond a dip of sunlight and temperature.

Maybe the entire patch changing isn’t necessary, but perhaps having a cooler light be applied and the spawning of ice chunks akin to those in the frozen seas during those turns I think would be easier while still demonstrating the frozen nature of a surface patch during glaciation.

2 Likes
23

Well I won’t know for sure without actually implementing both options, but I think that even that is almost as difficult as implementing support for patches changing type (and then changing back).

24

I agree with Deus that patches not changing type when major changes happen would be quiet the bummer. It kind of clashes with the axiom that if something should scientifically happen under certain circumstances, then Thrives world should reflect that. If photosynthesizers produce a lot of oxygen and temperatures drop below 0, then the oceans should freeze over. How exactly would we handle that? Will we just not allow the simulation to drop temperatures of patches below 0 degrees which were above it at the start of the game? Or would we just let patches drop below 0 without freezing them over? Both options seem to equally contradict Thrives core design philosophy…
Some ideas to circumvent this:

  • Does the architecture support adding patches and taking them away (again)? In that case ice shelf patches might spawn “on top of” epipelagic patches instead of replacing them? If an epipelagic patches temperature drops below 0 degrees a ice shelf patch would spawn over it and its sunlight would suddenly reduce drastically. Then, when temperatures thaw again, the ice patch could just disappear. All the species which lived in it would then be instantaneously migrated to the epipelagic patch below.
  • Alternatively, is there a way to keep a patch as a epipelagic patch internally (in the hidden internal architecture so to speak) and superficially present it as a ice shelf to the player? Then a script which temporarily “camouflages” an epipelagic patch as an ice shelf might suffice.
    If none of this is doable, then we might have to stick with his proposed “dynamic environment light”. But if it’s somehow possible I feel like the switch between frozen-over and non-frozen-over surface patches would be the one instance which would be worth the additional effort of a special solution. It’s really a big change which happened often and is really impactful. The Great Oxygenation event could really be an exiting milestone of each earth like playthrough and it would be a shame if it couldn’t be executed at least somewhat spectacularly.
1 Like
25

Sadly no, and this seems even more hard to fit into the code architecture than patches just changing type.

There’s no difference between the two: the patch type is shown in the GUI and used in the “backend” code so to speak. So again an architecture change would be needed to separate things.

I mean this is the only thing that can be currently fit in due to the existing architecture: the available max sunlight can be recalculated by patch events and later reset to the original value after the event is over.

1 Like
26

What about this? Is this possible with the current setup or not? If this might be possible I‘ll suggest a workaround involving this which aims to simulate the „surface patch freezing over“.

27

It’s again the same case: it needs extra code handling for it.

The reason why compound and chunk densities don’t need is that we have the biome template easily accessible for each patch.

So that’s why that’s the only thing that is easy to do, anything else requires extra logic to store information on what connections or patch types have been changed and will need to be reset back to what they were before.

28

I think that should be doable. I’ll try to tackle it this release to see what needs to been done and how much work it would require.

2 Likes
29

If it’s possible to enable and disable patch connections, then maybe every epipelagic patch could have a ice shelf patch above it and this ice patch would only be accessible if the temperature of the surface in this region is below 0. If it gets warmer, the patch connection could be disabled and all species living in the ice patch could be migrated to the epipelagic, simulating the disappearance of that ice patch. The ice patch which “no longer exists” could then be hidden in the patch map if that’s somehow possible.
I will stop now with hurling suggestions at this topic and leave it to the programming and design teams:)

30

I was trying to code the patch change for the oxyganation event. Would we allow manually setting Biome’s class properties (after doing a deep copy) like “Icon”, “Sunlight” etc. like that:

private Biome createSnowyPatchTemplate(Biome biomeTemplate)
    {
        // Biome biome = new Biome();
        biomeTemplate.Background = "iceshelf";
        biomeTemplate.Sunlight.Colour = new Color(1, 1, 1, 1);
        biomeTemplate.Icon = "res://assets/textures/gui/bevel/PatchIceShelf.svg";
        biomeTemplate.Panorama = "res://assets/textures/background/panoramas/PolarSea.png";
        biomeTemplate.untranslatedName = "ICESHELF";
        biomeTemplate.Resolve(null);
        return biomeTemplate;
    }

and saving the old ones in order to reset them later after few generations? I know it might be a little bit tricky but I got it working.
If that is allowed I would also change things like allowed chunk types etc.

31

There should be no need for this as this event should only affect compounds. And for compounds they can be easily reset to the biome template values, if needed.

Any change should need to be put into the patch snapshot system so that historical data viewing works. And II think rather than creating full new templates, it would be better to just have all templates hardcoded but allow patches to switch between templates if they so desire.

32

Since I’m currently working on the Global Glaciation event (aka snowball earth) I will present my approach:

The event would have a chance to be triggered after 70% of surface patches contain at least 7% oxygen and would last from 2 to 5 generations. So once these conditions are met there would be, let’s say, 50% chance every generation that the event would trigger. It can be triggered only once in one playthrough. Of course these numbers will be adjusted for the balancing purposes.

When the event is active, the following happens in the surface patches:

  • light level is reduced to 50%,
  • temperature is reduced to a value from range [-1, 4],
  • light’s color is slightly blue,
  • background is the same as for the ice shelf patch,
  • ice chunks can spawn but at a higher rate than in ice shelf patch
1 Like
33

Sorry if I missed it, but what’s the reason why snowball event requires oxygen to trigger? Other than that, that seems reasonable approach as long as the balancing is done properly.

34

Based on this quote. In the history of earth there was a massive glaciation triggered by the introduction of oxygen into the atmosphere which reduced methane levels and caused snowball earth

2 Likes
35

I will sum up the today’s discussion from discord and the progress I have already done regarding the meteor impact event.

The event would have 7% chance of being triggered every generation and would have 3 possible sizes:

  • small: 1 surface patch,
  • medium: all surface patches from 1 region,
  • large: all surface patches from 2 connected regions.

Types of meteors and their probabilties:

  • Plain: 25%,
  • Iron: 25%,
  • Phosphate: 20%,
  • Radioactive: 10%,
  • Sulfur: 10%,
  • Glucose: 10%.

All meteors will increase CO2 level and decrease light level. Iron, phosphate, radioactive and sulfur meteors will also add chunks to the patches that will disappear after the event finishes the next generation.
There was also a proposal for non-LAWK meteor that would introduce new species, but that is something that I would not be implementing for now as that seems much harder to do.
It was also mentioned that there should be meteors that would shake up the compounds more but I think that requires more discussion as to what it would exactly do.

2 Likes