Building an open-world fishing MMO solo in Unreal Engine 5

Anchor Point is an open-world, multiplayer fishing simulation set on the cold edge of Alaska — live weather, a real seafloor, a shared market — and it is being built by one person in Unreal Engine 5. People ask how that's even possible for a solo developer. The honest answer is that it isn't, unless you change what "possible" means: you trade a big team for ruthless scope, real-world data, and systems that do the work of content.

This is the first entry in the Anchor Point Journal — a running, honest devlog about making a genuinely ambitious game alone. No hype, no "one weird trick." Just the decisions that actually let a single developer ship something that reads like it came from a studio. If you're an indie working in Unreal Engine 5, or thinking about it, this is what I'd have wanted to read before I started.

Why Unreal Engine 5 for a solo developer

The first real decision is the engine, and for an ambitious solo project UE5 is hard to argue with. Not because of any single feature, but because of leverage. Nanite and Lumen mean I can light and detail a coastline without a rendering team. World Partition streams a 64×64 km map so I'm not hand-managing level loading. And the split between Blueprints and C++ lets me prototype a mechanic in an afternoon, then move the parts that matter — the economy, the validation, the netcode boundary — into typed, testable C++.

Just as important is the ecosystem around the engine. A solo dev's most scarce resource is time, and the Unreal marketplace and community turn money into time. Anchor Point's sky, for example, starts from a proven off-the-shelf sky asset, which I then wrap in my own server-driven weather engine. I didn't need to write a volumetric cloud system from scratch; I needed to write the rules that make weather matter. Knowing the difference is most of the job.

The engine is not the game. The engine is the thing that stops you from having to build the engine — so you can spend your one life building the game.

Scope is the whole game

Every solo developer eventually learns that scope isn't a phase of the project; it is the project. The skill that separates a shipped game from a beautiful, abandoned prototype is deciding what not to build — and being at peace with it.

Here's a concrete example from Anchor Point. The ocean has real, weather-driven swell that runs from a glassy 0.3 m calm to a 4 m storm, and your boat rides it on four-point buoyancy — the hull bobs, pitches and rolls, and a loaded crabber wallows where a light skiff snaps to every crest. It looks and feels like a physically simulated sea. But under the hood, I made a deliberate call: the waves are cosmetic. The server never computes wave height. There is no capsizing, no wave-riding speed bonus.

Why cut it? Because true wave-gameplay — waves that push your hull, swamp your deck, change your route — means server-side wave simulation and physics replication for every player on a shared map. That is a AAA-team feature. The 5% of players who would notice its absence are not worth the 40% of my year it would eat. So the sea looks alive, the boat feels alive, and the gameplay stakes live in systems I can run authoritatively: weather, prices, catch, storm loss. Players feel a rich ocean; I shipped a scope I can finish.

Cutting well is not about doing less. It's about spending every hour where a player will feel it.

Borrow the world, don't invent it

A believable open world is expensive, and "believable" is the operative word — hand-sculpted terrain tends to read as generic because a human is guessing at how geography works. So I didn't invent an ocean. I borrowed a real one.

Anchor Point's land comes from a real-world heightmap of Southeast Alaska, and its seafloor is cut from GEBCO — the same global bathymetry dataset actual hydrographers use. From that height data, a build tool derives everything else automatically: a 128×128 navigation grid, depth at every cell, distance-from-shore, channel detection, and finally the ten fishing grounds that run from a sheltered estuary out to the ice edge. Nothing is a painted rectangle. Shelves, channels and drop-offs sit where the survey says they sit.

The payoff is that local knowledge becomes real knowledge. The channel that funnels current also funnels weather; the shelf break where the depth lines crowd together is exactly where the halibut money lives. I got a world with genuine texture without a level-design team — because the texture came from the planet. If your game touches the real world at all — terrain, cities, tides, traffic — there is almost certainly an open dataset that will make it feel authentic for free. More on the world & ecology →

Systems beat content

A team can afford to hand-author content. A solo dev has to build systems that generate the feeling of content. The highest-leverage decision in Anchor Point was making one weather engine the spine of the whole game.

The server owns a single authoritative forecast — fourteen weather states across five severity bands, the same sky for every captain at the same moment. But weather isn't cosmetic mood-setting. Each state feeds four separate channels at once:

• Prices — a storm thins the fleet, supply tightens, and the fish already in your hold is worth up to 15% more.
• Speed — hull speed and fuel efficiency degrade as the sea builds.
• Catch — every species has a weather mood; herring vanish in a gale while others feed hard under rain.
• Loss — a violent storm puts your gear and part of your cargo genuinely at risk.

That's the multiplier. One system I can actually maintain, times fourteen states, times four consequences, produces emergent situations I never had to script. "Read the sky" stops being flavour text and becomes the core skill of the game. More on the weather engine →

Server authority without a netcode team

Anchor Point is a persistent, shared-world game: dozens of captains, one market, one weather system. That normally implies a backend team. Instead I lean on managed infrastructure so the decisions that matter — what you caught, what it's worth, what the weather's doing — resolve server-side, never on the player's machine.

The point for a solo dev is that you don't need to build a netcode stack to get a fair, consistent world — you need to be disciplined about where authority lives. Keep the decisions that matter on the server, and the game stays consistent for everyone. The sea is the same sea for every captain, and nobody can lag their way out of a gale.

Balance with math, not manpower

Here's the problem that keeps solo economy-game devs up at night: with 26 species, 97 biological variants, six quality grades, weather, freshness, ports and boat tiers all multiplying together, how do you know the game is fair? A studio throws a balance team and a thousand playtesters at it. I don't have either.

So I let the computer play the game. A Monte Carlo harness runs thousands of simulated careers — smart players and random players, across every zone, boat and weather seed — and reports back: which strategies dominate, which species are dead weight, where a player goes bankrupt. When the numbers say a fish is unprofitable or one loadout is a runaway winner, I retune the data and run it again. It's how I can promise all 26 species stay viable and no single strategy collapses the economy into a spreadsheet — with a balance team of one and a lot of CPU time.

Build in the open

The last lesson is less technical and more human: as a solo dev, transparency is an asset, not a risk. Anchor Point is greybox in a lot of places today, and I say so. The tech logs show the seams. This journal will keep showing them. Players are remarkably generous with a developer who tells the truth about where a game actually is — and remarkably unforgiving of one who oversells.

That honesty also keeps me aligned. If I can't explain a system plainly in a devlog, it usually means the system isn't done. Writing these has caught more design holes than any review.

What I'd tell another solo Unreal dev

If you're staring down an ambitious game with a team of one, this is the short version:

• Pick leverage, not features. Choose the engine, assets and services that delete work you were never going to enjoy anyway.
• Decide what to fake. Find the systems that can be convincing without being real — and be ruthless about the line.
• Steal from reality. Real datasets give you authenticity a solo dev can't hand-author.
• Build multipliers. One deep system that touches everything beats ten shallow ones.
• Let the machine balance. Simulation replaces the playtest army you don't have.
• Ship in daylight. Honesty compounds; hype doesn't.

None of this makes solo development easy. It makes it finite — and finite is the whole game.