If I Were Dumb Enough to Build an MMO

I've been sick for the last few days. Brain rotting. Because of that I've got myself thinking again about developing a game.

Yeah just like that. Simple phrase. Game development has always been an area that interested me. What steers me away from it is my inability for sprite work or 3D work — I simply can't do graphics.

The abilities I do have that I may be able to translate some knowledge to use here are: Backend Development, Frontend Development, Mobile Development, Architecture, DevOps, whatever is in my resume and also years of reading about how these things are made. I've projected my career towards web development, but I have that spark I want to fulfill someday: make one of my dream games.

The spark

I've always wrote TTRPG rules. I have 15ish years of excerpts for quest lines, characters and all sorts of things I've never shared with anyone sitting in my OneDrive. Game systems that never saw the light of day.

As I go through old notes. As I watch Chain Chronicles — The Light of Haecceitas. As I play Spacestation 13/14 and Diablo 2 Resurrected. The spark has been re-igniting.

I can't do graphics — but I know systems, architecture, and game logic. So naturally, instead of starting small and learning the craft, my brain went straight to: what if I designed my dream MMO?

I'm not actually going to build this. I'm not that far gone. Making an MMO as your first game is the software equivalent of learning to juggle by starting with chainsaws. Someday, maybe AI gets good enough that the execution gap closes and something like this becomes a one-person project. We're not there yet — and I have a job. But thinking through how it would be built? That I can do.

meme: random IT guy at 3am hitting AIs with a whip

Making peace with AI

I've been able to slowly grow up to like AI. I used to miss the dopamine of hitting compile or run and seeing things work as I designed. But the advent of AI made me spend more time planning and less time executing — and I'm starting to actually prefer that. It gives me time for what matters. While also allowing me to parallelize work.

It may be easy for me to think on game systems. How to apply certain mathematics (to some degree!), design patterns and techniques to create them. But it is not as easy to prototype and specially to test a game.

The Factorio principle

Factorio's approach to automated testing in game development

If someone were to make this right using AI, the first thing they'd need is a proper testing loop — something you can orchestrate work around.

At some point I became an addict at Factorio. They have it right. They got something very hard in the game dev industry: tests that actually work and a delightful gameplay loop.

A solid testing foundation would let whoever is mad enough to build this focus on systems, story, and gameplay instead of firefighting. The platform has to come first — stable, secure, testable. Everything else follows from that.

The thought experiment

So this is a thought experiment. What would I build if I could? What would the systems look like? What would I spec out if I had infinite time, a team, and some poor artist willing to suffer alongside me?

I don't want to focus on graphics — I never could. I want to think through the systems. The quest design. The class interactions. The architecture of a game that would actually be fun to play and interesting to build. That's the part that lights my brain up at midnight.

If you want to take this and build it — in whatever language, whatever stack — go ahead. This is just the design living in my head. If you actually ship it, I want to play it.

The vision

Let's do exactly what a newbie should never do first: an MMO! This is purely theoretical... right?

Okay! now that we got that out of the way: I've always had a thing for Dark Fantasy. I don't like High Fantasy that much nor Low Fantasy, lets meet in the middle.

Engine: Bevy. Written in Rust, open source, and built around an ECS architecture that fits how I already think about software. I get to write actual code instead of wiring nodes in an editor — and Rust's type system and borrow checker mean entire categories of bugs just don't compile. Plus, the performance ceiling is absurd.

Why Bevy? Because I want to use it.

Perspective: Top-down isometric. Think Ragnarok Online meets more dynamic, fluid movement systems like you'd find in Grand Line Adventures or Tibia-like RPGs. Characters should feel responsive and snappy — no click-to-move, no tile-locking. Smooth directional movement with weight.

Tone: Dark fantasy. Not the grimdark "everything is mud and misery" kind — but not high fantasy elves-singing-in-forests either. Mid-fantasy. A world with real stakes, morally grey characters, some beauty, and a lot of danger.

The kins

Three playable kins to start — each with their own cultural identity and starting zones:

Humans — adaptable, widespread, politically fractured
Elves — long-lived, proud, in slow decline
Dwarves — industrious, stubborn, builders of things that last — and diggers of things that should have stayed buried

More can come later. The system should make it trivial to add new kins without touching core mechanics.

The class system

This is where it gets fun. I don't want a flat class system where you pick "Warrior" at character creation and that's your life. I want layers — a composable progression system that rewards exploration and commitment.

The tiers

Every character starts with a profession — what you were before you went out into the world. A miner, a woodcutter, a blacksmith. This is your mundane class. You were someone before you picked up a sword.

Then the adventure begins:

scroll to zoom · drag to pan · double-click to reset

Class progression: each tier runs its own parallel level track

The key detail: each class has its own independent level progression. When you unlock an Advanced class, it starts at level 1. Your Novice class keeps leveling. You're running multiple tracks in parallel — and each one unlocks different skills through its own talent tree.

How you discover classes

Not all classes are handed to you on a silver platter.

Novice classes — you simply select one. Warrior, Magician, Rogue, Acolyte.
Advanced classes — easy to find. NPCs out in the world who practice these classes can teach you, if you gain their trust through a few quests. Do a job quest, prove yourself, unlock the class.
Expert classes — rare. Some are straightforward like advanced classes, but the interesting ones? Hidden quest chains. You'll have to explore, pay attention, and follow threads that aren't marked on any map.
Master classes — the hard ones. Long quest chains tied to iconic NPCs. You might need to become an apprentice to a legendary figure or join an order. Weeks of progression per level. Reaching level 25 in a master class is a feat that takes months.
Legendary classes — event-only or story-driven. Temporary roles or handcrafted for players who accomplish heroic feats. These are the stuff of server history.

The time investment

This isn't a rush-to-max-level kind of game. The grind is part of the story.

time-investment.md

Profession (cap 150)  → always ticking in the background while you gather/craft
                       early levels: minutes — later levels: hours each
                       this is your side grind, your comfort loop

Novice (cap 100)      → lv.1-10: tutorial pacing, ~minutes each
                       lv.10-25: a few hours each (Advanced unlocks at 25)
                       lv.25-50: the long road, hours per level
                       lv.50-100: prestige grind, days per level

Advanced (cap 75)     → lv.1-10: feels fresh again, ~hours each
                       lv.10-50: the real commitment, several hours per level
                       lv.50: Expert unlock — a milestone that takes weeks to reach
                       lv.50-75: endgame territory, days per level

Expert (cap 50)       → lv.1-5: quest chains gate entry, days just to get started
                       lv.5-25: the slow burn, days per level (Master unlocks at 25)
                       lv.25-50: a multi-month journey for the dedicated

Master (cap 25)       → every level is a project — weeks each
                       reaching cap is a server-notable achievement (~6+ months)

Legendary (cap 10)    → event/story pacing — not grindable
                       you don't farm these, they happen to you

The class roster

Here's what I have so far — organized by tier. This isn't final, but it gives shape to the system:

Novice (pick one): Acolyte · Magician · Rogue · Warrior

Advanced (discover through NPCs): Wizard · Sorcerer · Cleric · Paladin · Shaman · Guardian · Crusader · Occultist · Witch/Warlock · Elementalist · Thief · Assassin · Scout · Berserker · Fighter · Ranger · Swashbuckler · Knight · Juggernaut · Druid · Spellslinger · Merchant · Skald

Expert (hidden quests and exploration):

Magic: Abjurer · Pyromancer · Aeromancer · Arcanist · Astromancer · Conjurer · Cryomancer · Diviner · Enchanter · Geomancer · Hydromancer · Illusionist · Invoker · Necromancer · Psyker · Runesmith · Spellsinger · Spellsniper · Thaumaturge · Transmuter · Demonologist · Alchemist

Combat: Cavalier · Executioner · Gladiator · Harbinger · Martial Artist · Marauder · Myrmidon · Pit Fighter · Reaver · Sentinel · Weapon Master

Faith & Finesse: Bard · Corsair · Diplomat · Gunslinger · Justiciar · Sapper · Sharpshooter · Templar · Witch Hunter · Blackguard · Zealot

Legendary (event/story only): Chronomancer · Destroyer · Dragonslayer · Nightstalker

These are just examples of course.

Talent trees

For such a system to work, we need a composable class system — easy to define active and passive skills for any class. Think the old World of Warcraft talent trees: a branching grid where each point spent opens new paths.

The abilities themselves should not be just stat bumps — they need narrative weight, consequences, and trade-offs. A bard's Cacophony doesn't just "deal AoE damage" — it also disrupts your own allies. A Requiem can revive your party, but it might kill you in the process. Power should always come with a price.

Here's what a Bard master class tree looks like. Go ahead — spend some points:

Bard — Master Class

Points: 0/25 · 25 remaining

Click to inspect · Click again to add point · Right-click to remove

Interactive talent tree — click to inspect, click again to spend, right-click to remove

Simple paths. Each skill has one parent going straight down — until row 4 where branches converge. Dance of Knives skips row 2 entirely, connecting Riposte Verse (row 1) straight to row 3. Soothing Melody is a dead end: a powerful healing node that leads nowhere deeper — points spent there are points you can't spend reaching the capstone. Every build is a trade-off. Also remember that the talent tree above is just an example I put here to demonstrate.

Every ability has a cost or a catch. Cacophony disrupts your own allies. Requiem might kill you. Magnum Opus is a once-per-day zone-wide ultimate that every player in the zone hears. That's the kind of ability that becomes a server story.

Skills need to be easy to compose: triggers, effects, conditions for activation, cooldowns, resource costs. The system must be data-driven — define a skill in config, not in code. A designer (or a sleep-deprived me at 2am) should be able to create a new ability without touching the engine. More complex skills may require some more work. But as long as we keep those moving parts composable we will be able to more easily create new skills in the future.

Bevy's ECS makes this natural. A skill is just data — components describe what it does, systems execute the behavior:

skills.rs

/// A skill is an entity with components that describe its behavior
#[derive(Component)]
struct Skill {
  name: String,
  cooldown: Timer,
  resource_cost: u32,
}

#[derive(Component)]
struct DamageEffect { base: f32, scaling: f32 }

#[derive(Component)]
struct AreaOfEffect { radius: f32 }

#[derive(Component)]
struct StunEffect { duration_secs: f32 }

#[derive(Component)]
struct ProjectileTrigger { speed: f32, range: f32 }

// "Cleave" is just an entity with the right components:
// Skill + DamageEffect + AreaOfEffect
// "Charge" is: Skill + DamageEffect + StunEffect + ProjectileTrigger
// No class hierarchy. No giant match statement. Just data.

Quests and storytelling

The focus of this game is telling good stories that make sense to the world. Every quest must feel unique and introduce characters that belong — with objectives, flaws, and motivations. Some characters should be likable, others detestable. There should be villains. There should be some grey morality that makes some villains even understandable in reason.

Movement and feel

This is where a lot of isometric games fall flat. I want movement that feels alive:

No click-to-move. Keyboard directional movement — WASD or arrow keys. The character responds immediately.
No tile-locking. Smooth, free-form movement across the isometric plane. Tiles exist for the world grid, not for the player.
Weight and momentum. A character in heavy armor should feel different from a rogue in leather. Not sluggish — just grounded.
Dodge and dash. Responsive evasion mechanics. Roll, sidestep, blink — depending on your class and build.
Directional attacks. Swings, projectiles, and spells should respect facing and positioning. No tab-targeting.

Think Grand Line Adventures or the better Tibia-likes — that snappy, responsive feel where you're always in control.

In Bevy's ECS, this translates beautifully. Movement is just components and systems:

movement.rs

#[derive(Component)]
struct Velocity(Vec2);

#[derive(Component)]
struct MovementWeight(f32); // heavy armor = higher value

#[derive(Component)]
struct DashCooldown(Timer);

fn movement_system(
  input: Res<InputState>,
  time: Res<Time>,
  mut query: Query<(&mut Transform, &Velocity, &MovementWeight)>,
) {
  for (mut transform, velocity, weight) in &mut query {
      let speed = velocity.0 * (1.0 / weight.0);
      transform.translation += (speed * time.delta_secs()).extend(0.0);
  }
}

fn dash_system(
  input: Res<InputState>,
  time: Res<Time>,
  mut query: Query<(&mut Transform, &mut DashCooldown, &Velocity)>,
) {
  for (mut transform, mut cooldown, velocity) in &mut query {
      cooldown.0.tick(time.delta());
      if input.dash_pressed && cooldown.0.finished() {
          let dash_dir = velocity.0.normalize_or_zero();
          transform.translation += (dash_dir * DASH_DISTANCE).extend(0.0);
          cooldown.0.reset();
      }
  }
}

No inheritance. No base class. A character in heavy plate just has a higher MovementWeight — the system handles the rest. Want to add a "slowed" debuff? Slap a component on the entity. Want a class that dashes further? Change the query to include a DashModifier component. Composition all the way down.

The spec

Everything above is the vision. Below is how I'd spec it out if this were real — what a v0.1 would look like, what systems matter first, and how the architecture would hold together under the weight of everything else.

Project overview

Field	Value
Name	TBD (working title needed)
Engine	Bevy (Rust)
Architecture	ECS (Entity Component System) — shared crate between client and server
Perspective	Top-down isometric (2D sprites in isometric space)
Genre	Dark fantasy MMO
Tone	Mid-fantasy — stakes are real, magic is dangerous, beauty coexists with danger
Target	PC first, extensible

Core systems

1. Authentication & Authorization

Account registration, login, session management
Role-based permissions abstracted into well-defined roles with explicit permission sets — player and admin to start. The system should make adding new roles trivial without touching core logic.
Character-to-account binding

2. Character creation

Select kin (Human, Elf, Dwarf)
Select profession (mundane class)
Select novice class
Appearance customization (sprite-agnostic — the system stores data, rendering is separate)

3. Class & progression system

Parallel level tracks per class tier (profession, novice, advanced, expert, master, legendary)
Level caps: profession 150, novice 100, advanced 75, expert 50, master 25, legendary 10
Class unlock conditions: novice (free pick), advanced (NPC reputation + job quest at novice lv.25), expert (hidden quest chains at advanced lv.50), master (long chains + NPC apprenticeship at expert lv.25), legendary (event/story only)
Talent trees per class tier — data-driven, composable
Skill definition system: triggers, effects, conditions, cooldowns, resource costs — all configurable

4. Movement system

Keyboard-driven (WASD), no click-to-move
Free-form movement on isometric plane (no tile-locking for characters)
Physics-based weight/momentum per equipment load
Dodge/dash mechanics (class-dependent)
Directional facing for attacks and abilities
Server-authoritative position with client-side prediction

5. Combat system

Real-time, action-based (not turn-based, not tab-target)
Directional attacks and abilities
Hitboxes and collision detection
Class skills from talent trees
Status effects, buffs, debuffs
PvE and PvP contexts. PvP is important and there should be systems designed to encourage it — but it is zoned and runs its own separate progression. It must never bleed into PvE content or pressure players who want to focus on the story. Instanced PvP content, ladders, rankings, and separate reward tracks. If you don't want to PvP, you should never have to.

6. Quest system

Data-driven quest definitions (objectives, prerequisites, rewards, branching dialogue)
NPC and/or Faction reputation system tied to class unlocks
Quest chains (linear sequences and branching paths)
Hidden/discoverable quests (triggered by exploration, items, NPC interactions)
Event-driven quest state (ties into class unlocks for advanced/expert/master classes)

7. World & NPC system

Zone-based world with isometric tile maps
NPC schedules, dialogue trees, reputation tracking
Spawning, pathing, and AI behavior for enemies
Zone transitions and instancing

Architecture principles

scroll to zoom · drag to pan · double-click to reset

High-level architecture — server-authoritative, zone-sharded, NATS-bussed

Server-authoritative — the client renders and predicts, the server decides. Clients send intentions; the server validates and broadcasts results. No client can lie its way to an outcome.
Optimistic updates & client-side prediction — movement and common actions are predicted client-side and reconciled with authoritative server state. Keeps the experience snappy regardless of latency. Mispredictions are corrected, not punished visually.
Shared Rust crate — game logic (components, systems, types) lives in a shared crate used by both client and server. Same code, same types, no serialization drift.
Zone sharding — a zone is a logical concept, not a single server process. High-population zones split into shards automatically. Players are distributed across shards transparently — the world always feels alive, but servers aren't crushed under their own weight.
Instancing — dungeons, raids, and PvP content live in private server instances. When a group enters, they get a dedicated process separated from the open world. No interference with open-world players, no shared state to corrupt.
Phasing — players at different points in a quest chain see different states of the same zone. The city isn't burning for everyone. Reduces load concentration while making progression feel personal and consequential.
Interest management & network culling — the server only sends state about entities near you. Update frequency drops with distance. This prevents the N² traffic explosion as zone populations grow — you don't need to know what's happening on the other side of the map.
Spatial fan-out — how zone-wide events reach all players across shard boundaries. The World Manager is the spatial coordinator; shards are never aware of each other.
NATS — the message bus across services. Zone shards publish game logic events (level-up, quest completed, faction rep changed); Quest Engine and Class & Progression subscribe and react. In-process channels handle intra-service communication; NATS handles everything across service boundaries.
Data-driven systems — classes, skills, quests, NPCs defined in data files (RON, TOML, or YAML), not hardcoded
ECS everywhere — entities are IDs, components are data, systems are behavior. No god objects, no inheritance hell.
Graphics-agnostic core — the game logic doesn't know or care what the sprites look like. Swap the art, the systems keep working.
Test-first platform — automated tests for game systems before we write a single quest. The Factorio principle. Rust's #[test] and Bevy's headless mode (hopefully) make this straightforward.

What a v0.1 would NOT include

No world building / lore writing (that's a separate effort)
No asset creation / sprite work (use simple shapes and colors as placeholder)
No sound design
No networking optimization / load balancing (get it working first)
No economy system (future spec)
No crafting system beyond profession leveling (future spec)
No guild/party system (future spec)

Where I'd start, if I were starting

If someone — hypothetically, theoretically, definitely not me — were to actually build this:

Set up the Rust workspace: client, server, and shared crates
Get a basic Bevy isometric scene rendering with a placeholder sprite
Implement the movement system — it's the first thing you feel, and if it's bad nothing else matters
Build the class/progression data model in the shared crate — with tests
Prototype a single talent tree with skill composition
Build the quest system data model
Wire up a headless Bevy server with basic zone shard and character state sync

This is purely theoretical. A design exercise. Me staring at the ceiling at midnight thinking about talent trees and zone sharding instead of sleeping like a normal person.

But the systems are real. The architecture decisions are real. Hopefully not only real, but also correct. Remember I don't have experience designing games. This is only random bullshit I've collected in my mind after years reading about how games like these are made.

The ideas have been sitting in my head — and now in my OneDrive, and now here — for a long time.

Maybe AI gets good enough someday that a single determined person can actually pull something like this off. Maybe that person is me. Probably not. But the spec is here if anyone wants it.

Actually I may throw the link to this article to Claude and tell it to try and build this. Just for the funsies of it.

Kind regards,
Leonardo