Designing Day and Night Cycles

Few things in a game carry as much feeling for as little code as the setting of the sun. A light rotates a few degrees, its colour warms toward amber, the shadows stretch across the ground like fingers reaching for the walls, and something in the player tightens without being told. The sky is the oldest clock humans have, and long before they had words for it, people knew that the hours after dusk belonged to other things.

A day and night cycle borrows that inheritance. Technically it is a modest system: a timer, a rotating light, a handful of curves that change colour and intensity, and adjustments to the sky, the ambient light and the fog. Its effect on play can be enormous, because it divides time into phases with different meanings, and the transition between those phases becomes a deadline the player can see approaching across the whole horizon.

The following sections treat both halves of the subject: the rendering mechanics in Unity that make a convincing cycle, and the design decisions that give it consequence. The two cannot really be separated. A beautifully lit dusk that changes nothing feels like a screensaver, while a dangerous night rendered without care feels like an arbitrary switch thrown by the designer.

The sun as a rotating light

The heart of nearly every cycle is a single directional light standing in for the sun. A directional light has no position that matters, only orientation: its rays are parallel and illuminate the whole scene from one direction. To move the sun across the sky, one rotates that light around a horizontal axis. A common formulation sets its rotation each frame to Quaternion.Euler, with the x angle derived from the time of day and the y angle fixed to choose the compass direction of sunrise.

The time of day is best kept as a normalised value from zero to one, where zero might be midnight, one quarter dawn, one half noon and three quarters dusk. Mapping that value to an angle is then a matter of multiplying by 360 and subtracting 90, so that at dawn the light points horizontally and at noon it points straight down. Everything else in the system reads the same normalised value, which keeps the components in step with each other.

The rotation alone is not enough, because a sun below the horizon still lights the scene from beneath, glowing up through the terrain in a way that betrays the trick immediately. Intensity must therefore fall to zero, or close to it, as the angle approaches the horizon, and shadows should be faded or disabled when the light is too low to matter. In the built in pipeline, setting RenderSettings.sun to this light also lets the procedural skybox draw its sun disc in the right place.

A moving sun has a cost that a static one avoids. Baked lightmaps assume fixed lights, so a cycle generally relies on realtime lighting and realtime shadows, which are among the more expensive features in a frame. Shadow distance and the number of cascades become important tuning parameters, and dense scenes may need to bake only indirect lighting from static light probes while letting the direct sunlight move freely.

Colour, intensity and the curves of a day

Real daylight does not merely brighten and dim; it changes hue. Near the horizon sunlight passes through more atmosphere, which scatters away blue and leaves the warm oranges and reds of dawn and dusk, while at noon the light is close to white. Unity's Gradient class captures this naturally: a gradient from deep blue through orange to white and back again, evaluated with Gradient.Evaluate at the current time of day, yields the light's colour for that moment.

Intensity is better described by an AnimationCurve, which can be edited visually in the Inspector and evaluated with AnimationCurve.Evaluate. A curve that rises steeply after dawn, plateaus through the middle of the day and drops sharply at dusk gives more convincing results than a plain sine wave, because twilight in reality is brief and the change in brightness around it is abrupt. Designers can shape the curve by eye, with keyframes and tangents, without touching code.

Many teams gather these curves and gradients into a ScriptableObject describing a lighting profile: sun colour, sun intensity, ambient colours, fog colour and density, all keyed by time of day. Different biomes, seasons or weather states can then use different profiles, and the cycle controller simply evaluates whichever profile is active. Blending between two profiles during a transition, by interpolating their evaluated values, allows a storm to roll in without a visible pop.

Night deserves its own treatment, rather than being merely the absence of day. Complete darkness is unplayable, so most games tint the night a cool blue and keep it dimly visible, often with a second directional light for the moon or by reusing the sun light with a different colour after it sets. Two shadow casting directional lights at once doubles a substantial cost, so a common approach swaps between them rather than running both.

Sky, ambient light and fog

The directional light handles direct illumination, but much of what makes an outdoor scene read as morning or evening comes from indirect light: the sky's diffuse glow on surfaces facing away from the sun. Unity exposes this through RenderSettings.ambientMode and related properties. In trilight mode, RenderSettings.ambientSkyColor, ambientEquatorColor and ambientGroundColor can each be driven from gradients, letting shaded walls turn blue at night and warm at sunset.

When the ambient light comes from the skybox itself, changes to the sky material are not automatically reflected in the environment lighting. Calling DynamicGI.UpdateEnvironment after modifying the skybox recomputes it, though doing this every frame is wasteful, and updating every few seconds of game time is usually enough. Swapping RenderSettings.skybox between day and night materials, or adjusting exposure and tint on one material, gives the sky itself the right mood.

Fog is the most underused tool in the set. RenderSettings.fog, fogColor and fogDensity can all be changed at runtime, and matching the fog colour to the horizon colour at each hour makes distant terrain dissolve gracefully into the sky. Increasing density at dusk does something more than look atmospheric: it literally shortens the distance the player can see, and in a game where danger approaches from the darkness, that loss of sight is felt as vulnerability.

In the Universal and High Definition render pipelines the specifics differ, with volumes, sky components and physically based sky models taking over some of these roles, but the principles remain the same. Direct light, indirect light, sky and atmosphere all have to change together, driven by one clock, or the illusion fractures: a bright blue ambient under an orange sunset reads immediately as wrong, even to a player who could not say why.

Choosing a time scale

The time scale of a cycle, the question of how long a day should last, has no right answer, only consequences. Minecraft famously gives a full cycle twenty real minutes, and that figure is a reasonable reference point for games where the player is meant to do several meaningful things each day. If the day is set at twenty minutes, one game hour lasts 50 real seconds and the sun rotates 0.3 degrees per second; the movement is slow enough to be ignored moment to moment yet visible across a task.

Shorter cycles intensify the rhythm, so that the player is constantly preparing for the next night, which suits survival games built around pressure. Longer cycles make each phase a place to inhabit, which suits exploration and simulation. Some games compress night relative to day, spending perhaps a third of the cycle in darkness, because nights are tense and tiring and a player who spends half of every session in fear may simply stop playing.

Implementation matters here too. The cycle should keep its own clock, advanced each frame by Time.deltaTime multiplied by its rate, rather than co-opting Time.timeScale, which also slows physics, animation and everything else. A separate clock lets a strategy game offer pause and fast forward, lets a sleeping mechanic skip the night, and lets the save system restore the exact time of day as a single number.

Day as safety, night as threat

The most powerful use of the cycle is to assign the halves different rules. In many survival and strategy games the day is for gathering, building and planning, and the night is for defending what was built. This gives the player a natural rhythm of preparation and test, and makes the evening a period of anxious final tasks: one more load of wood, one more stretch of wall, the villagers called back inside before the light is gone.

The approach is effective because it makes the clock itself a source of tension. A player who sees the sun low over the trees must decide whether to finish a construction or retreat, and the decision has stakes without any enemy yet being visible. Crown & Ashes is built on exactly this alternation: the settlement builds by day and survives the Hunger, its walking dead, by night, so the sunset, far from decoration, is the most important event in every cycle.

For such a structure to feel fair, the transition must be readable. Players should be able to tell how much day remains, through the sun's position, the colour of the light or a discreet interface element, and the onset of danger should follow that cue reliably. Torchlight becomes a gameplay tool as much as a visual one, with point lights marking the safe interior of a settlement against the blue dark beyond it, and light radius quietly defining the territory a player can hold.

Mood, rhythm and restraint

The cycle's emotional effect depends heavily on contrast. If the day is drab and the night only slightly darker, nothing is felt. If dawn after a hard night floods the scene with warm light, birdsong and the slow lifting of fog, it becomes a reward, a release of held breath that no achievement notification could match. Audio deserves the same curves as lighting, with ambient tracks and environmental sounds crossfaded by time of day.

Restraint is also part of the craft. Not every system needs to change with the hour, and a cycle that alters too much, enemy types and shop prices and quest availability all at once, can feel more like bureaucracy than nature. The strongest designs choose one or two meaningful differences between day and night and let the lighting carry the rest, trusting the player to feel what the sky is saying.

When it works, the player stops seeing the cycle as a system at all. They glance at the sky the way people once glanced at it from the fields, judging the hours by the length of shadows, and they begin to move faster as the light reddens. A rotating light and a few curves will have done the work of teaching them, without a single line of tutorial text, that the dark is coming and that it is not empty.