GWeatherSystem

gWeatherSystem
Description of the weather system that is present throughout the game.

Description

The weather lies as a constant part of the environment through the game.

How the weather system changes is chance-based, and the specific weather chance is also dependent on the specific biome the player is in.

Dimensions Functionality: The chance (in %) for the initial weather for heat 0-0.2: can be seen in the table to the right. After the weather type has been set, the weather state needs to be determined. There are 3 states for each weather type: Since the random rolls can determine any weather type and state, disregarding what is currently present, a transition time is necessary to get to some altering states (fx going from sunny to thunder) Sound:
 * Is present on the entire timeline.
 * There are three parts to the weather system: Weather type, weather state, and weather transition.
 * At the start, and whenever a new weather state is set, a random roll is done to determine how long the weather state should last for.
 * The formula for this is as follows:
 * Random(40, 180). The number that comes out of this is the time, in seconds, it takes before the weather changes.
 * A timer is therefore also started when the weather is present, and when that reaches the output of the random roll, a new weather type and state should be set.
 * After it is determined that the weather needs to change, it then rolls another dice-roll to see what the weather should change to.
 * There are 5 weather types: Sunny, Cloudy, Rain, Thunder, and Snow.
 * The chances for each weather type is dependent on the biome the player is currently in and on the heat variable (See BHeat ).GWeather1.png
 * GWeather2.png
 * Whenever heat increases with 0.2 the chances change. The change is shown in the table to the right.
 * The chances in this table are added to the original table for each time the heat variable has increased with 0.2.
 * GWeather3.png
 * This is determined by another dice-roll, each option has ⅓ chance of being picked as the active state.
 * After the weather type and state has been set, the transition will begin.
 * GWeather4.png
 * The transition is based on the hierarchy to the right:
 * As seen, the transitions has to travel through the different weather states in order to get to a different weather type.
 * Each individual transition from one state to the next should maximum take 1 second.
 * A transition to weather in a non-direct connection is possible, but transition takes n times longer (n being number of connections), because it needs to transition through each type to get to the goal.
 * For example, if it needs to travel from Sunny L to Cloudy H, it will do 5 transitions, therefore taking 5 seconds in total.
 * For animation purposes, each transition should be considered as its own transition, and not as one long n second transition. (See Animation)
 * The arrows from Rain to Snow are direct as well, so here it can just travel directly, back and forth, and does not need to go back to Cloudy.
 * Once the transition is complete, the initial weather time roll will be done, to determine how long this weather state will last for.
 * The sound depends on the weather type and state.
 * Each weather state has a sound.
 * Sun: Environmental, atmospheric sounds. Light and open.
 * Cloudy: Environmental, atmospheric sounds. Heavier and more dampened.
 * Snow: Environmental, atmospheric sounds. Heavy and slow.
 * Rain: rain sounds of the rain hitting the ground.
 * Rain L: Light rain, drizzly.
 * Rain N: Normal rain.
 * Rain H: Heavy rain.
 * Thunder L: Heavy rain, Rare thunder cracks.
 * Thunder N: Monsoon storm, occasional thunder cracks
 * Thunder H: Heavy Monsoon storm rain, frequent thunder cracks.


 * Nice to have:
 * Sounds depending on surfaces in the biomes. For example, heavy rain in city sounding different than heavy rain in jungle.

Aesthetics
 * Reference images for the different weather types and states:
 * Sunny L
 * Sunny N
 * Sunny H
 * Cloudy L
 * Cloudy N
 * Cloudy H
 * Rain L
 * Rain N
 * Rain H
 * Thunder L
 * Thunder N
 * Thunder H
 * Snow L
 * Snow N
 * Snow H

Animation
 * The Rain, snow, and thunder rain can go in front of the player.
 * Each transition has an animation. (See the hierarchy and table for the states and transitions):
 * Sun L -> Sun N: Single clouds form.
 * Sun N -> Sun H: The clouds grow a little in size.
 * Sun H -> Cloudy L: The clouds start merging, leaving some spots.
 * Cloudy L -> Cloudy N: The clouds merge completely.
 * Cloudy N -> Cloudy H: The clouds grow darker.
 * Cloudy H -> Rain L: Rain starts lightly.
 * Rain L -> Rain N: Rain intensifies a little, more consistent.
 * Rain N -> Rain H: Rain goes more intense, raining heavily.
 * Rain H -> Thunder L: Rain stays the same, thunder stats cracking.
 * Thunder L -> Thunder N: Rain intensifies even more, thunder goes more frequent.
 * Thunder N -> Thunder H: Rain intensifies even more, thunder goes very frequent.
 * Cloudy H -> Snow L: Snow starts lightly.
 * Snow L -> Snow N: Snow intensifies a little, more consistent.
 * Snow N -> Snow H: Snow goes more intense, snowing heavily.
 * In each of the rain -> snow (and vice versa), the intensity of the weather stays the same, but it changes from rain to snow (or vice versa).

Programmed Weather System
This section will cover the implemented version of the weather system. It will cover what the weather system consists of, what these elements do, and a tutorial to set up of the system.

The weather system primarily consists of 5 scripts: _WeatherManager, LightmapsController, DownfallController, CloudsController, and ThunderController. In the future additional script may be required, e.g. for the future utilization of unity's light probe system. These light probes would be baked in the current unity version and thus a script may be required to switch between groups of light probes. Alternatively with less performance draw, a more neutral single set of light probes could be setup together with one primary light source.

_WeatherManager

The weather manager is what decides the weather, it is the decider, it is the boss. It is made as a singleton manager for ease of access from other scripts. The weather manager displays the current heat variable, and can be used for debugging to set the heat. But in the final setup it will be controlled by a property 'Heat' set by the script calculating the heat variable.

The weather manager too displays the roll it makes between 1 - 100 to determine the weather. This variable cannot be manipulated in the editor to any result.

Then the weather manager has a minimum and a maximum in seconds for when to change the weather to a new random weather.

There is a transition time (s) that determines the speed it should change between each weather. Currently set to 1 second a transition between light sun to heavy rain would take 2.66 seconds. If the transition time was set to 3 seconds the same transition would total in 8 seconds.

Current Weather displays the current weather (Wow), but is also used to set the initial weather for testing, this does not work during run time, but I'll get to that.

Intensity is used in the same way as a display and for setting the initial value. This variable is not currently setup to be manipulated during run time from any means.

And lastly the current biome which displays the current biome, is used for setting the initial value, and can be manipulated like a fox during run time.

Setting the Weather During run time (Debug)

to set the weather during run time, for debug purposes, the idea is the tweaking tool will include it eventually (and can do so by using the property for CurrentWeather). But currently this is not implemented yet, but do not fear.

You rightclick the Weather Manager title in the inspector and get a dropdown menu which will hold a context menu for setting the weather during run time from the inspector.

LightmapController

The lightmap controller has a list of functions being called from the weather manager, to fade the baked lighting between the wished weathers. The lightmap controller determines everything about the transition between lightmaps and keeps track of what to fade from and to.

It is basically simple animation used to get the lightmap transitions, it uses 5 static lightmaps, and 5 lists of lightmaps containing the animation frames, which it cycles through based on the transition time and number of frames given in total. The lightmap controller needs 1 lightmap at the time, and as far as documentation shows, 1 lightmap should be plenty per level.

The easiest way to get the lightmaps and animation I currently have found is to bake a lightmap for each weather (Sun, Clouds, Rain, Thunder, Snow) with the light levels, sources, etc., wished. Here everytime you bake a new lightmap make a copy into a new folder so it's not overwritten.

Then take these 5 lightmaps (.exr) and open them in Photoshop, then copy e,g, the clouds lightmap image into a layer in the sun lightmap (above). Then use the Opacity inside the "Animation (Timeline)" to fade this new layer from 0% to 100% over a wished number of frames. Then use File>Export>Render Video to export an image sequence as OpenEXR files (.exr) and use whatever name you see fit, but I would suggest using a format like:

levelname_transition_##.exr (e.g. firstlevel_SunToClouds_01.exr)

do that for all the 5 transitions: There is no need for the reverse transition as the script will cycle through the animation backwards when needed.
 * 1) sun to clouds
 * 2) clouds to rain
 * 3) rain to thunder
 * 4) rain to snow
 * 5) clouds to snow

DownfallController

The downfall controller takes the information from the weather manager and uses it to determine how a downfall particle system shoudl emit it's particles at the current time.

Through the inspector everything a designer should need to change to achieve the weather he wanted should be available. The emission of particles can be controlled for each intensity for both rain and snow. Furthermore here they can set the particle textures, the color and the opacity they want for those particles. Remember the rate should be fairly propertional to the phsyical size of the downfall emitter.

CloudsController

The clouds controller currently performs a simplified version of the cloud transitioning in and out, dependent on the weather and intensity. In the future it may be as complex as described in the design document.

The clouds controller needs a parent to a set of gameObjects each with SpriteRender (will become clouds) component for the clouds for 3 stages of clouds. These clouds will be added dependent on the intensity and weather, which will mean e.g. the weather "normal clouds" will display both the clouds in the "light clouds parent" and in the "normal clouds parent".

Then four colours can be set for the different intensities and weather. Lastly designers can place the sprites textures they want the clouds to adopt in the list "Cloud Sprites".

ThunderController

The thunder controller just needs the intervals of thunder to decide when to make a lightning strike and play the thunder. There are intervals for the 3 intensities of thunder.