Weather That Matters

Ashen Hearth’s weather design has two intended jobs: change how the world looks and sounds, then provide explicit conditions that survival rules can interpret.

That separation keeps weather from becoming a cosmetic toggle, but it also prevents rain particles or fog opacity from becoming hidden gameplay truth.

Five Layers, Five Responsibilities

The inspected Unity reference architecture divides the feature into several cooperating parts.

1. Game time publishes hour and elapsed-day changes.
2. Season state derives the active season from elapsed days and an authored cycle.
3. Weather policy decides whether conditions change and weights possible weather by season.
4. Weather state publishes the selected condition.
5. Presentation and survival consumers react independently to that state.

This is more deliberate than asking one WeatherManager to change particles, audio, temperature, UI and AI directly. A single manager still owns the selected condition, but subscribers decide what that condition means for their domain.

The weather states represented in that code are Clear, Rainy, Windy, Thunderstorm and Fog. Snow is not a separate weather state in the reference implementation, so the presence of a winter season value cannot be used as proof of a complete Ashen Hearth snow-weather mode.

Time Drives Opportunities, Not Guaranteed Changes

The weather manager listens to the game-time system’s hour changes. Each check uses an authored probability to decide whether to choose a new condition.

If a change is allowed, selection comes from season-specific weighted entries in a SurvivalProfile. This makes “what weather is likely now?” editable data instead of a switch statement embedded in presentation code.

The distinction between change chance and weather distribution matters:

• change chance answers whether the current condition should be reconsidered;
• distribution answers which condition should be selected for this season;
• the current weather remains unchanged when the roll does not trigger a change.

This avoids selecting a new weather type every hour merely because the clock advanced. It also gives tuning a clear surface: persistence, frequency and seasonal identity can be adjusted separately.

Seasons Are Authored, Not Assumed

The season manager resolves a season from total elapsed days, a configurable number of days per season and an ordered cycle. Spring, Summer, Autumn and Winter are available values, but the default cycle can omit a season until the authored world supports it.

That is a useful production safeguard. Adding Winter to an enum is easy; completing winter visuals, navigation readability, crops, shelter rules, audio and balance is not.

A season should only enter the active cycle when its dependent systems have meaningful behavior and player feedback. The data model permits it without forcing the public game description to overstate current scope.

Weather State Fans Out To Presentation

Weather effects implement a shared interface and register with the manager. When state changes, each effect receives the same weather value and decides how to respond.

The reference project includes separate behavior for rain, fog, wind and thunder presentation. Fog can adjust by season, and wind presentation can also use seasonal values. Because these are consumers rather than state owners, disabling one visual effect does not silently change the canonical weather.

This structure also makes layered feedback possible:

• particles and fog communicate visibility and motion;
• audio communicates intensity beyond the camera;
• lighting and color can alter the emotional read of a familiar place;
• HUD text can confirm the named condition;
• survival code can apply a gameplay modifier.

Survival Reads Data, Not Particles

The survival layer accesses weather through a provider contract. It combines the current condition with time, season and other environment data, while SurvivalProfile stores authored warmth modifiers for each weather type.

This means a thunderstorm can be harsher than clear conditions without the player-survival controller needing to know which particle prefab is active. It also makes the calculation testable: a test can supply a weather condition directly without rendering rain.

That boundary supports future consumers as well. AI may care about visibility, work desirability or shelter, but those rules should be explicit profile data or sensed world state—not guesses based on whether a particle system is emitting.

The GOAP article explains why state that affects decisions must be inspectable and updated at an appropriate frequency.

Avoiding Random Punishment

Dynamic weather can easily become noise if every change interrupts the player or invalidates a plan.

The intended pressure comes from readable combinations:

• bad weather makes a working hearth and shelter more valuable;
• darkness and fog make familiar routes feel less certain;
• seasonal distributions change the texture of longer play;
• survival modifiers make preparation matter without hiding the cause.

The UI should name the current condition, while the world supplies redundant cues through sound, light and effects. Consequences need the same clarity. If warmth is falling faster, the player should be able to connect that change to conditions rather than blame an invisible formula.

Transitions also need restraint. A weather change should not restart every effect at full intensity, stack duplicate audio loops or cause several expensive systems to update on the same frame. The architecture creates places to solve those problems, but visual and performance validation still has to happen in the running game.

Persistence And Reproducibility

Time and environment state affect too many systems to be reconstructed casually. A save should restore enough canonical state that the same world does not become a different survival situation merely because the scene reloaded.

The save-system architecture note describes ordered restoration and semantic validation. Weather restoration should update subscribers from the restored state without pretending a random hourly change just occurred.

For debugging, deterministic test inputs are just as important as runtime variation. The profile’s weighted-selection function can be supplied a known roll, allowing tests to verify which weather a distribution should choose without depending on uncontrolled randomness.

Current Boundary

This is not a meteorological simulator. The system does not claim wind fields, fluid simulation or a complete climate model. Its value is a clean chain:

time event → seasonal policy → weather state → presentation and survival response

That chain is small enough to inspect and broad enough to make the same authored homestead feel different across a clear morning, a windy afternoon, fog or a storm.

Explore Ashen Hearth or continue with Keeping the Hearth Alive to see how local warmth gives weather pressure a visible answer.