Day and Night

Making this thread to discuss draft PR 3072, the implementation of a Day / Night Cycle.

So far nothing concrete in terms of actual gameplay has come up however, regardless of that Day and Night cycles work in a similar fashion in most games, it’s little more than some States and Transitions that cycle in a loop and feed data to the environment lighting system of the game world.

Here’s all my thoughts so far, I put them in the skeleton class me and Game Dungeon will try to fill out:

3 Likes

Wouldn’t it be better to have a smooth time of day? I think we’ll want to have the sun position smoothly change in later stages, so I think designing the microbe system with that in mind would be good.

3 Likes

Sure, you could do that. You’d still need a state machine unless you want things to become a mess of if / else but, yes that’s perfectly possible. None of this is real code, it’s just a big comment.

I had imagined a more continuous changing of light levels rather than discrete states, but this probably works better actually. Provided there’s a nice animation between them, it should make things clearer for the player.

The obvious question is how long these states should last. A pretty thorny problem and deeply tied to how long it takes to reproduce. I’m imagining a minute or two, but that’s really a very vague guess.

There should be a visual indication of the current time, expressed through lighting of the environment. I experimented with this a while back and found the world light in the Godot scene didn’t seem to affect anything, at least to an easily visible degree. To get the background and cloud planes to change brightness in particular, this PR will require quite a bit of restructuring for various scenes.

One other quick thing to figure out is how this affects Auto-Evo. We don’t want to ignore it, as then we’d have a world full of photosynthesising organisms that keep dying at night. If the intent is to nerf photosynthesis and buff storage, then Auto-Evo needs to take storage into account.

The big and perhaps controversial concept I have in mind is that low light levels should limit the player’s vision. I can see why this might not work, but here’s my proposal:

As light level dims, the player’s vision should restrict to a shrinking circle around them. So cells, chunks, clouds and the background should fade to black (or at least a much darker colour) outside this circle. Chemoreceptors would still work. For consistency, the maximum range for the AI’s detection of other cells could shrink too.

To counteract this shrinking of view, cells can evolve bioluminescence. There would be bioluminescent proteins and a bioluminescent vacuole. With either equipped, the player can press a hotkey to switch on all their lights, which would greatly expand their range of view at the cost of ATP while turned on.

Other cells with bioluminescence would be visible even outside the player’s view circle, for obvious reasons.

Now, would this all make for a fun experience in the game? I don’t know. I’d like to see it in action to find out though.

But one immediate consequence of this is we’d have to think about how this works in patches that are permanently dark. Do cells have restricted vision there too? How would playing with permanently restricted vision affect gameplay? I would guess rather a lot.

EDIT: I should note that not all of this has to be implemented at once. It would be perfectly possible to add everything except the vision restriction and bioluminescence part, then return for those additions later.

1 Like

the states don’t have to be set up in this fashion, you can also use Dictionaries and have it so it’s really just Day and Night, and Dawn and Dusk just define when light levels are going up or down.

I’m not sure whether it’s worth writing a novel on here about different types of state machines and applications of State Design Pattern.

I’m not entirely convinced it needs to be a state machine. I think instead we should specify the properties that depend on the time of day and make those available to gameplay code to use. Then the time handling can decide how it updates those values internally (whether it is a state machine where each state lasts some time and interpolates to new values or the entire thing is a smooth linear interpolation defined between the various values set for each time of day).

The smooth interpolation you keep referencing, that would still benefit from a state machine / state design pattern, or be a state machine outright. For example, no matter what we do, there will be many scripts that benefit from instantly knowing if is Day (as the state machine is constantly trackng this) instead of itself having to look at some float value, do some instructions to figure out whether this value is during Day, and then probably do a bunch of behaviour you could have possibly encapsulated in a Day state.

See the following for a gentleman using a very simple State Machine to depict Night / Day:

I find that would be taking too literally the fact that input is provided to the player through sight. Cells do not see; they rather ‘smell’. Unless another mechanism that I don’t know is involved, there is no reason for cells to be penalized by obscurity (except of course for phenomenons like photosynthesis). I’m not even sure cells could ‘know’ that there is no light around them!

Now of course, that’s for the generic case. Some cells do react to light, if any retinal cells from our eyes. In more ‘ecological’ environments, some photosynthesizers actively move towards light - a phenomenon known as phototaxis. This allows them to exploit the most ‘nutritive’ places for photosynthesis. At the same time, high light intensity levels are harmful, and so these species may also undergo negative phototaxis in which they run away from light.

And I think this provides, on the other hand, very interesting gameplay perspectives; we have:

  • photosynthesis;
  • ‘compound’ search;
  • motility.

Which could definitely flesh out a bit plant gameplay, although that means non-uniform light levels, which could be related to day/night cycle (e.g. cloud patterns?).

Source :

Euglena gracilis exists as a photosynthesising autotrophe but at low light intensity it can survive as a heterotrophe ingesting plant material. Neither strictly plant nor animal, it occupies a third kingdom as a protist. Chlamydomonas rheinhartii might more strictly be defined as a green algae in the plant kingdom. Phototaxis is essential for both organisms; moving towards light upon which they depend for energy and nutrition, yet also undergoing negative phototaxis to protect themselves against too intense a source of illumination. The eyespot is not the photoreceptor itself but rather a mass of carotenoid pigment shading the photoreceptor from light from one direction. This demonstrates the essential components of any visual system; any photosensitive organism needs a photoreceptor that detects the light. But that alone would not allow the organism to determine the direction of the light source. A pigment spot reduces the illumination from one direction, or changes the wavelength of the incident light falling on the photoreceptor, thus allowing the organism to move in the direction of the light or away for it. So third, a mechanism to promote movement is essential. To detect the light is one thing but to move towards or away from it requires a motor system; the flagellae in Chlamydomonas and Euglena. But also a mechanism is required by which detection of light can be translated into achange in flagellar movement, generally an ion flux of one kind or another.

[Light and the evolution of vision - PMC]

In any case, I’d argue that in most cases, there is no point in displaying day/night to the player, for the sake of both realism and simplicity (less information to process). Of course, some specialized builds could make use of it, such as plants, but also their predators. I thus argue that day/night display should be restricted to species possessing some specific organelle: either the ones that are already light dependent (thylakoids) or a brand new one dedicated to light perception (which would be helpful for predators). As a further note, I’d argue that it also definitely makes the case for a non homogeneous level of light across a sea zone, in a fashion similar to compound clouds.

Of course this is just to set global guidelines, as it would arguably add complexity to the proposed feature. But I think it is worth keeping in mind.


It is also interesting that the linked paper mentions the species Euglana gracilis, whose behavior should be allowed by whatever implementation we choose, as it may spice up photosynthesizer gameplay.

Euglena gracilis exists as a photosynthesising autotrophe but at low light intensity it can survive as a heterotrophe ingesting plant material. Neither strictly plant nor animal, it occupies a third kingdom as a protist.

2 Likes

I think the interface from the time system to the rest of the game should be properties like float LightLevel, bool IsDay stuff like that so that the time system can do whatever internally it wants, but it is connected with simple values and flags to the rest of the code so that the rest of the code base doesn’t need to know any of the complexity about checking like 3 state values to know if something should happen or not.

1 Like

This is one of those things where I can justify deviating a bit from reality for the purposes of gameplay and intuitive design. Although you are definitely right in saying that unicellular organisms have no need for any sort of visual assistance (bioluminescence in cells is only used for things like quorum sensing and communication it seems) the fact of the matter is that we are humans playing a cell simulation. While theoretically the brightness of say an abyss shouldn’t differ at all from the brightness of the surface in the perspective of a cell, I can see it being rather uncanny and confusing to players if we demonstrate this in Thrive. As imperfect and unrealistic it it might be, it could be pretty jarring if the player knows they are in a very dark place or knows it is nighttime but doesn’t see a change in brightness. Plus, it could be confusing for the player if they notice motile organisms with chloroplasts being much less motile for no apparent reason during certain times because they can’t see the day changing into night like cells with chloroplasts can. So I think we should relay that information to the player.

I do agree necessitating bioluminescence near the surface because it is so dark might be a bit too far, I’d be willing to see bioluminescence have an effect in the abyss. Though I can be talked off of this edge; bioluminescence would eventually make it in anyways when Thrive becomes macroscopic

1 Like

I think the central question about the day/night cycle is how fast it should be.

The answer to this question depends on two factors:

  • how fast will passive ammonium/phosphate absorbtion and therefore reproduction be?

  • will the player have the option to speed up time when they play a sessile organism?

The first factor of these two is in turn dependent on the second factor.
I feel like the day/night cycle should ideally be longer than two minutes. Such fast cycles would feel somewhat silly imo.

Both the day/night cycle and a sensible implementation of passive absorption hinge on the implementation of a timelapse feature for sessile organisms. I therefore suggest we start discussing the viability of a timelapse button as seen in Kerbal Space Program, Kenshi and other games.

How hard would it be to implement? Would it be possible at all? Or do you disagree with my premise of its usefulness?
I‘m curious to hear your thoughts.

Well, I beg to differ here.

Later stages will or should include senses, and their progressive acquisition. Arguably, it would be weird to drop from a cell that perceives anything to an animal that can’t see because they lack sight! For a better picture, you may have a look at the prototype from an old PU.

As for your precise concerns:

As imperfect and unrealistic it it might be, it could be pretty jarring if the player knows they are in a very dark place or knows it is nighttime but doesn’t see a change in brightness.

Well given that it has no gameplay effect, we may keep the current backgrounds. For night time, how would they know without it? You suggest behaviour…

it could be confusing for the player if they notice motile organisms with chloroplasts being much less motile for no apparent reason during certain times because they can’t see the day changing into night like cells with chloroplasts can.

… well I precisely find it fairly fitting : you got a prey who seemingly has some weird behaviour, but you can’t grasp it… because you lack some info! Wouldn’t that be an interesting mechanics? I think it would!


If you are still unconvinced, we could tell the player they lacks photosensitivity by apply a greyish filter/sort of global fog. And the tooltips could tell that a given organelle “Grants the ability to detect light!

I orginially refrained from commenting on this proposal since I wasn’t sure how you meant it. I thought you were talking about some possible UI element which would indicate the time of day to the player if they played a photosynthesizer which would be disabled otherwise.
Now that you made clearer what you mean, I tend to agree with Deus. We already show the player lots of visual information which their cell wouldn’t be able to see. It would be strange to selectively hide the environmental indications of nighttime from them if they lacked eyespots when we show them everything else.
To drive my point home: Most real-life algae, unicellular and multicellular alike, lack eyespots. It would be very strange if the day/night cycle directly affected the player but wouldn’t be communicated visually to them.
And as most real-life photosynthesizers don’t have eyespots, we shouldn’t force them on the player should they choose to play as a photosynthesizer.

I will argue that the only times the day / night cycle affects the player is when they can photosynthesize (and therefore be able to detect day and night) So before then it doesn’t even matter, though it will clear up confusion, and after they can detects it.

The real question is, how will the backgrounds change? Theoretically and how should it work in code? I do agree that it’s best to be linear with “isday” as an option.

To be clear, nothing prevents:

  1. displaying day/night to photosynthesizers but not local variations; granted it may seem a bit confusing if you have a non consistent output of light, but anyways non homogeneity of light spots is a somewhat distinct case which we’ll have time to discuss
  2. assuming that photosynthesis organelles provide light detection, removing the need for a dissociated eyespot; this simplified model works anyways for pure day/night, given that you know from your processes if there is light or not; you simply can’t gradient ascent light, i.e. hunt for optimal light spots;
  3. indeed have an icon displaying day phase for simplicity; it could also help explain the mechanics, with a big red ‘?’ question mark for species without photosensitivity.

Onto your specific concerns:

We already show the player lots of visual information which their cell wouldn’t be able to see. It would be strange to selectively hide the environmental indications of nighttime from them if they lacked eyespots when we show them everything else.

We display 3 kinds of things to the player: clouds, chunks and cells. All 3 can be ‘smelled’ at a distance by a single system of chemoreception. We simply choose to display cell knowledge to the player using sight (because smell in videogames is… not there yet). We also provide the player with an organelle extending the range of chemoreception. Note this uses another system of representation (lines) because of limitations of the visual modality of the player (screen size).

In short, not showing light would not be without reasons, because, it is detected by the cell through an entirely different mechanism than the rest.

And writing that I wonder if there is not a deep misunderstanding of what what is displayed stands for: these are informations detected by the cell by its senses (smell) and brought to the player using their own senses (sight). But the cell’s senses and the player senses are not necessarily overlapping! In particular, sight is a privileged sense for video games, which is why we represent things through sight. But it should be clarified that what the player sees is not what the cell sees! And this will be very important for later stages, e.g. https://www.youtube.com/watch?v=VK_ClyrLO98.

Which is why I think day/night cycle is a great opportunity to address this issue.

You see the thing is, the second you say having something like ‘isDay’ as an option, you’re justifying there being a state machine because that bool is an exposure of the state. A state machine can be ‘linear’, the states don’t have to set static values, just flags of when is what.

The backgrounds changing is easy, just subtract from albedo according to the time. Just need methods to send the values to a uniform in the shader.

I don’t see the point in debating this. The day of time system can be internally structured however it is wanted (though, I guess you said you do want to co-author this with @Gamedungeon …) as long as:

  • The interface to the rest of the code is simple enough and doesn’t expose too many internal details
  • Optimally the time system is designed now so that the same system works for the later stages (probably with a different kind of time speed configuration file)
2 Likes

Alright, I can work with that

1 Like

Ok, I can definitely agree that making things mechanically different for most cells depending on the time of day may be a step too far. Ignore everything I said about vision restriction for the time being.

But I 100% think there should be some visual indication of time of day in the environment. It would be highly confusing for players to see a fully lit background at the dead of night. It could be as simple as dimming the background as Nunz seems to be looking into. Not doing this is in my opinion going way too far into realism at the expense of gameplay clarity.

1 Like