Day/Nigh and Weather System

Dynamic day and night cycles is something that almost every survival game implements in one way or the other. During my work on Outpost: Glacier I developed a day/night system that quickly turned into a larger weather manager that housed most of the logic to drive the weather visuals and behaviors.
If you are looking to develop your own system, here are some of my findings.

From both a design and technical perspective.

Demands and requirements

Outpost: Glacier had it's own set of demands and challenges. This system was supposed to drive both the world and overall weather and it's behavior. This system was the base manager class for all client side behavior of the weather and lighting.

Keeping the weather in synchronized was a priority to make sure all players had a coherent experience, while still providing all the necessary features for a player to be on their own individual adventure.

Requirements

Architecture

Game State

Server Authority

Manage the global time and weather events.


Weather Manager

Local Simulation

Interpret the global weather state and update visuals for the locally controlled player.


Additive Systems

Subscribers and Override systems for the weather manager.

Day and Night cycle

At face value the day and night cycle gives the player the impression of the passing of time. Oftentimes a lot of behavior in the game world is based on this representation such as Weather, AI spawning and behaviors as well as player Statuses and effects. Before we talk about day and night we should first define what time is.

Time

Time is central to not just the Weather Manager but other systems that are to give the illusion of the passing of day and night in a living game world.

Time as ticks

My preferred way to define time is in a system specific tick. not to be confused with the regular game update ticks. 

For the sake of simplicity, a world tick could happen once every second, where the server updates the current tick evaluates the current time to see if it should trigger any events, and then broadcast these events to listening systems. One day in the game could be the equivalent of one hour of real world time, that would make 3600 ticks.

The Server then broadcasts any events or changes and the weather manager proceeds to fetch the latest weather, wind and time states.

The Weather Manager then handles local interpolation of these values to avoid jagged stepping in positions, lighting and post processing.

Having a centralized time of day timestamp can make life easier when synchronizing behavior between other manager classes that have behavior dependent on the time of day.

 

For Outpost: Glacier, this tickrate was chosen because it gave plenty of room for the clients to fetch data with varying connectivity without creating taxing data requests. And still maintaining and fixing discrepancies for a coherent experience so players could react to the same weather state without any noticeable visual deviations. This also allowed us not to worry too much about players joining in progress as weather would at worst adjust within a few seconds after initializing the weather manager.


Why not make a completely event based system?

Events are great, they are great as long as you can ensure that all players receive vital events, like precipitation changes or the sky changing color.  Sometimes data packages are lost, players join late, the host computer has a hiccup or anything else happens that causes the world state to de-sync. Having to ensure every event is replicated to all connecting machines is usually one of the bigger bottlenecks you encounter when building multiplayer systems. Having the Weather Manager re-fetch the world state at a steady interval can make that maintenance easier while avoiding any major de-sync or taxing data transactions.  This can be used in tandem with events that handle single actions players should react to at the same time. 

For example: A thunderstorm should probably be a mixture of weather parameters making the sky appear dark and stormy. While a single lightning strike would be handled as an event that players can localize and react to together.

Day Length

Deciding day length is not trivial*. A good starting point is between 1/3rd to 1/6th of your total day length. A 60 minute day cycle could have anywhere between 10-20 minutes of night time. This should be decided on based on how much time should be spent performing tasks at night and the implications of night time gameplay.

The day and night cycle is broken down into several Curves and Floats that can be interpreted by other systems.

Alpha values:

Curves:

A. Designer notes: Why day length is important.

Darkness and nighttime is often used in survival games to make the world feel more alive and dynamic, as well as provide players with an incentive to craft tools and buildings to survive the night. Some times the night is used to further increase the challenge of the world, where dangerous or rare creatures and loot can spawn to make the game more exciting. Most of the time however, night is when every task becomes slightly more difficult and your world becomes a lot less colorful.

You might feel inclined to introduce a freezing de-buff, to force players to craft better clothes when temperature drops at night. Or reducing the sanity of the player because they have a fear of the dark. Maybe introduce enemies that lurk in the shadows to make exploration more dangerous?

When designing night gameplay, it's important to consider that EVERYTHING becomes more difficult. Even the simple the lack of light might already be doing these things for you. Draining their resources to maintain a steady supply of torches, while reducing their stamina or otherwise taxing their gameplay. You run the risk to make night gameplay not only tedious, but hopelessly hard, especially for new players who might decide to turn off the game instead of exploring further.

Consider this:

Reducing the total time of night. Players will just have to focus on surviving the few minutes of night gameplay before continuing exploring the game.

or

If you want the night to still be challenging and long enough for players to do substantial exploration. Give them the tools to manipulate the passing of time. A simple bed with the ability to skip to the next day can give players the agency to choose when they are ready to encounter the night gameplay. Without limiting potential design elements available to make the night feel interesting.

B. Designer notes: Why day length is important.

Darkness and nighttime is often used in survival games to make the world feel more alive and dynamic, as well as provide players with an incentive to craft tools and buildings to survive the night. Some times the night is used to further increase the challenge of the world, where dangerous or rare creatures and loot can spawn to make the game more exciting. Most of the time however, night is when every task becomes slightly more difficult and your world becomes a lot less colorful.

You might feel inclined to introduce a freezing de-buff, to force players to craft better clothes when temperature drops at night. Or reducing the sanity of the player because they have a fear of the dark. Maybe introduce enemies that lurk in the shadows to make exploration more dangerous?

When designing night gameplay, it's important to consider that EVERYTHING becomes more difficult. Even the simple the lack of light might already be doing these things for you. Draining their resources to maintain a steady supply of torches, while reducing their stamina or otherwise taxing their gameplay. You run the risk to make night gameplay not only tedious, but hopelessly hard, especially for new players who might decide to turn off the game instead of exploring further.

Consider this:

Precipitation

Just like every survival game features day and night, almost all of them feature at the very least snow or rain.  This can be purely aesthetic or tie into other game systems. Water collection, cold debuffs, or the inability to start fires due to wetness. While precipitation means the the product of water vapor in the atmosphere. The system can be used to spawn any type of lingering environmental effect. Snowfall, Rain, Hail, or Dust and Fireflies.

Game State

Delegate OnNewWeatherEvent();