Dev Blog #4 - How Is a Small Team Going to Build an MMORPG?

Hey everyone,

Let's address the elephant in the room. Whenever a small team says "we're making an MMORPG," experienced gamers hear "we're going to burn out in eighteen months and ship nothing." That skepticism is earned — MMOs are the graveyard of indie game development. Massive worlds, massive server infrastructure, massive content demands, and traditionally, massive teams.

First, let's define "small team," because we're not being cute about it. Eternal Realms Online is three people: one developer building every system in the game, a map designer / level artist building the world, and a character artist handling characters, enemies, and gear. That's the whole studio.

So how do three people plan to pull this off? Not with optimism. With architecture.

Systems First, Content Second

Here's the core insight our whole approach is built on: in an MMO, systems are expensive and content is cheap — if you build the systems right.

We build the game as independent, modular systems: combat, gathering, crafting, equipment, banking, NPCs, day/night, loot. Each one gets built completely — server logic, visuals, sound, the works — tested until it's solid, and then we move to the next. We don't have twenty half-finished systems in flight. We have a growing stack of finished ones.

And every system is built data-driven from day one. The clearest example is the skills themselves.

Underneath, every gathering skill in the game is the same machine: a node in the world — a rock, a tree, a fishing spot, a patch of herbs — that requires a tool, takes a certain amount of time to work, and gives an output. That's Mining. It's also Woodcutting, Fishing, and Herbalism — just different nodes, different tools, different timings, different outputs. Processing skills are the same idea one step further: a station — a furnace, an anvil, a cooking range, an alchemy table — that offers you recipe options, requires inputs, and gives outputs. Smelting a bronze bar and brewing a potion are the same machine wearing different hats.

That's exactly why Mining and Smithing came first. Building them wasn't really building "mining and smithing" — it was building the core gathering system and the core processing system that the entire skill roster runs on. Now Woodcutting, Fishing, Herbalism, Cooking, Alchemy, and the rest don't need their own systems built from scratch — they plug straight into machinery that already exists and is already battle-tested. Each new skill is mostly new data and new art: nodes, tools, timings, recipes. Not months of new code. And the same philosophy runs through everything else — a new enemy, a new weapon, a new loot table, a new ability is a new entry in the game's data, not a programming project.

The payoff is huge: once a system exists, filling the world with content built on it takes hours, not weeks. The three combat styles, the enemies, the crafting stations, the potions — the expensive part was building each system once. Everything after that is us at maximum speed.

The Server Tech Nobody Had Ten Years Ago

Now the part that used to actually kill indie MMOs: the server.

Traditionally, an MMO needs a small ocean of custom infrastructure — game servers, databases, sync layers between them, and netcode gluing it all together, each layer a place where things break at 3 AM. Big studios throw teams of specialists at this. Small teams drown in it.

We're building on SpacetimeDB, a new kind of server technology where the database and the game server are the same thing. All of our game logic — combat math, loot rolls, the economy, XP, every rule of the world — is written as our own custom systems in Rust that run inside the database itself, right next to the data. There's no separate server fleet to babysit and no hand-written sync layer, because the world's state and the world's rules live in one place.

What that buys us, concretely:

• Worlds that just run. Like the old-school greats, the game runs multiple worlds — and you hop between them whenever you want. Your character, your bank, your progress: all of it follows you to any world, because your account is one single source of truth no matter where you're standing. You're never locked to a server.
• Cheat-proof by design. The server decides every hit, drop, craft, and trade. Your client is basically a very pretty window — there's nothing on your machine worth hacking.
• A tiny team can actually operate it. The hardest part of running an MMO has mostly been engineered away, which frees us to spend our time on the part you actually play.

This is also why the jump from our 2D prototype to full 3D didn't reset the project: the entire server — the skills, the items, the economy logic, the world state — carried straight over. The game got a new body; the brain kept every memory.

Buy the Bricks, Build the House

One more honest advantage: the modern game-dev ecosystem. We build on Unreal Engine 5 and we're not shy about using premium art, animation, and environment packs as raw material instead of hand-crafting every rock and run cycle. Our time goes where it actually differentiates the game — the combat feel, the systems, the economy, the world design. Nobody ever quit an MMO because the developers didn't personally sculpt the boulders.

And the Receipts

This isn't theory — you can already see the approach working. In the last few weeks alone: a complete action combat overhaul across all three styles, the full defense system, archery with real ammo, the mine-smelt-forge-equip loop, mounts, banking, NPCs with dialog, a shared day/night cycle, weather, and the game's entire sound layer. Every one of those is a finished module we never have to build again — and every automated test we write (there are hundreds now, running on every change) keeps it that way while we build the next one.

Three people. Modular systems. Data-driven content. Server tech that removes the classic killer. That's the plan — and so far, it's working.

More soon.

- The ERO Team