Building a dynamic weather system that changes how you play

Most games treat weather as decoration — a rain shader, a fog card, a skybox that cycles while nothing underneath it cares. In Anchor Point, the weather is the game. It sets the price of your catch, the speed of your boat, which fish are feeding and whether you make it home with your gear. This is how one developer built a dynamic weather system in Unreal Engine 5 that drives real gameplay across a shared, multiplayer world — and why that was the highest-leverage system I've shipped.

This is the second entry in the Anchor Point Journal. The first post was the wide view — how a solo developer builds an ambitious game in UE5 at all. This one goes deep on a single system, because if you take one idea from this whole devlog, make it this: a solo dev should build a few systems that touch everything, not many that touch one thing. Weather is my proof.

Weather as a system, not a skybox

The temptation with weather in Unreal Engine 5 is to stop at the visuals. Between Lumen, volumetric clouds and any of the excellent marketplace sky assets, you can have a gorgeous, rolling sky in an afternoon — and it will mean absolutely nothing. A beautiful storm the player can ignore is worse than no storm, because it teaches them that the sky is set dressing.

So I flipped the question. Instead of "what should the weather look like?", I asked "what should the weather decide?" The answer became the design rule for the entire system: every weather state has to change a choice the player is making. If a new state doesn't move a number the player cares about, it doesn't ship. That single constraint turned a cosmetic feature into the spine of the game.

One authoritative forecast: the server owns the sky

Anchor Point is a persistent, shared world — dozens of captains fishing the same coast at the same time. For weather to matter, everyone has to be living under the same sky. If my storm is your sunshine, there is no shared reality to talk about, trade around, or race home from. So the forecast is server authoritative: the backend owns a single timeline of weather, and every client just renders the state it's told to.

This matters more than it sounds for a solo developer. The moment weather is server-owned, a whole category of cheating and desync problems simply can't happen: nobody can force calm seas to dodge a storm penalty, because their client doesn't get a vote. I didn't need a netcode team to make it fair — I needed to be disciplined about where the decision lives. Keep the authority on the server and the shared world stays honest for free. See the sky & sea systems in motion →

Make the weather touch everything

Here is where a weather system earns its keep. A single authoritative forecast is only powerful if it reaches into the systems the player actually plays. In Anchor Point, each weather state feeds four channels at once:

• Prices — a storm thins the fleet and tightens supply, so the fish already in your hold can be worth up to 15% more. Weather becomes a market signal, not just a mood.
• Speed — hull speed and fuel efficiency degrade as the sea builds, so a gale changes not just whether you fish but how far you dare to range.
• Catch — every species has a weather mood. Herring vanish in a blow; others feed hard under rain. "Read the sky" becomes a literal fishing skill.
• Loss — a violent storm puts your gear and part of your cargo genuinely at risk. Risk is what makes the reward mean something.

That's the multiplier that makes solo development possible. One system I can actually maintain, times fourteen states, times four consequences, produces thousands of distinct situations I never had to hand-author. A studio would fill that space with content and a content team. I filled it with one rule engine and a lot of interaction.

A shallow feature is one you can describe in a sentence and finish in a week. A deep system is one you can describe in a sentence and never stop discovering. Weather is the second kind.

Severity bands make the chaos readable

Fourteen states could easily become noise. The fix is structure: every state sits in one of five severity bands, from flat calm to full storm. Bands are what let the player build intuition — they learn to read "this is a band-three afternoon, I can push the outer grounds but I should watch the horizon" without memorising fourteen individual weathers.

Bands also keep the design honest on my end. When I add a new state, I'm not balancing it against thirteen others in a vacuum; I'm slotting it into a band with known price, speed, catch and loss envelopes. It's the same trick as the rest of the project: impose a small amount of structure up front so the system stays understandable as it grows. For a solo dev, understandable is maintainable.

Build it solo: buy the sky, write the rules

The single most useful decision was drawing a hard line between the look of the weather and the logic of it. Anchor Point's sky starts from a proven, off-the-shelf UE5 sky asset — I am never going to out-engineer a dedicated volumetric-cloud team, and I shouldn't try. What I own instead is the layer that matters to gameplay: the server-side forecast, the severity bands, and the rules that turn a weather state into prices, speed, catch and loss.

That's the leverage play for any solo developer. Buy or borrow the parts that are craft — rendering, clouds, ocean shading — and spend your scarce hours writing the parts that are your game. The sky is a commodity. What the sky does is the product.

Test the weather without a QA team

A system this interconnected raises an obvious fear: how do I know a rare band-five storm doesn't quietly bankrupt everyone, or that one weather seed doesn't hand out a runaway payday? A studio answers that with a QA team and a thousand playtesters. I don't have either — so I let the computer play instead.

The same Monte Carlo harness I use to balance the economy runs thousands of automated fishing careers across every zone, boat and weather seed, and reports where the numbers break. If a storm band is too punishing or a calm stretch is too rich, the simulation catches it long before a player would. Weather isn't tuned by vibes; it's tuned by a few thousand simulated seasons and a lot of CPU time.

What I'd tell another solo dev building weather

If you're adding weather — or any ambient system — to a game in Unreal Engine 5, here's the short version:

• Make it decide, not decorate. If a weather state doesn't change a player choice, it's a screensaver.
• Put authority on the server. In a shared world, one owned forecast kills a whole class of cheating and desync — no netcode team required.
• Wire it into everything. One system times many consequences beats many systems times one. That multiplier is how a solo dev competes with a content team.
• Impose structure early. Severity bands keep both the player's intuition and your own design legible as the system grows.
• Buy the look, own the logic. Off-the-shelf sky, hand-written rules. Spend your hours where the game actually lives.
• Let the machine test it. Simulation is the playtest army a solo dev doesn't have.

Weather turned out to be the clearest example of the whole Anchor Point thesis: you don't beat a studio on volume, you beat the odds by building fewer things that matter more. One sky, owned end to end, doing the work of a dozen shallower features. That's not a shortcut — it's the whole strategy.