What Is Avalore?
Avalore is a private hobby project: a from-scratch remake of the classic early-2000s MMORPG I grew up with, written in Unreal Engine 5 C++ one system at a time. It’s more than a prototype. It runs as a real client and dedicated server, with account login, character creation, and saved progress behind it, and it keeps the original’s look and feel. It’s also far from finished: plenty of systems and most of the content are still missing.
The original game was the first game I ever played. It was my childhood. It’s the game that made me want to make games. I have an enormous amount of respect for the people who built that era of games with the technology they had.
I work on Avalore in my free time outside of work, almost daily. I started it because I love the source material, and kept going because it turned out to be the best classroom I’ve ever had for systems programming and game design.
Why This Project Matters
Avalore is half engineering project, half design study. I study classic MMOs as a behavioral reference to understand why their systems worked, where the friction came from, how older client/server designs were structured, and what made that era of MMORPGs feel so distinct.
Then I build those ideas with my own architecture, my own code, and more modern engineering practices. I want to keep what made those games feel the way they did, fix the parts that were frustrating, and build it all in a way that’s cleaner, safer, and easier to extend.
What I’ve Built
Everything below runs in the game today. The videos show part of it; the rest is listed further down.
Entity & Core Framework
A custom entity framework for players, NPCs, monsters, and world encounter objects, with shared systems for attributes, resources, stats, combat, abilities, status effects, death handling, respawn flow, and UI-driven interaction. Everything is designed to be extended without rewriting what’s already there.
Combat
Combat is server-authoritative and designed around MMO constraints rather than single-player shortcuts. The full loop covers click-to-move, click-to-attack, hold-input combat, melee and ranged attack handling, combo flow, critical strikes, mitigation, hit reactions, knockback, floating combat text, and reward distribution. It feels responsive to the player, but the server always decides what actually happened.
Ability System
On top of combat sits a data-driven ability system that supports direct skills, projectile skills, area and directional abilities, cooldowns, charges, cast timing, interruption rules, crowd control, and shared damage resolution. Each ability is defined through data rather than hardcoded logic, so adding a new one mostly means filling in data, not writing new code.
Status Effects
A full status-effect system for buffs, debuffs, over-time effects, and public crowd-control indicators. Effects stack, expire, interact with each other, and propagate visually so the player always knows what’s happening to them and to others.
Progression
The RPG progression layer includes leveling, spendable attribute points, ability points, reputation, and custom presentation for character growth. Stats propagate properly between character level, equipped gear, and temporary effects, so the numbers always make sense.
Items & Equipment
There is a full item pipeline covering world drops, loot, pickup rights, inventory, equipment, consumables, NPC shops, currency handling, enhancement, tooltip building, and visual equipment updates. Items carry both static definition data and per-instance runtime data, which makes room for enhancement progression, randomized rolled properties, and meaningful loot generation.
Enhancement System
Enhancement is a full gameplay system with validation, material requirements, success and failure handling, preview UI, and visual feedback. It also shows on the character: runtime weapon visuals, modular character appearance updates, and enhancement VFX and material treatment on visible gear. You can see the investment a player has made just by looking at them.
Monster AI & World Encounters
I built custom monster AI with aggro logic, chase and leash behavior, roam behavior, group coordination, and world spawners. World encounter objects are actors too, with threshold-based wave spawning and cleanup rules.
UI & HUD
Avalore has its own gameplay HUD layer with custom widgets for action bars, inventory, equipment, character windows, ability windows, target frames, chat, NPC interaction, shops, enhancement flow, respawn, nameplates, minimap, and full world map. The map is built from zone data rather than a camera capture, so it stays clean and readable.
Also Working
- Mounts, including mounted combat, mounted abilities, and flight, unlocked in tiers.
- Combat pets that level up, assist their owner in fights, and stay on a leash.
- Player-to-player trading with item locks, range checks, and a confirmation countdown.
- Private player shops: stands placed from an item, with pricing, browsing, automatic payouts, and expiry.
- Storage at the storekeeper, including items returned from expired shops.
- Chat with proximity and global channels, speech bubbles, and slash commands.
- Five playable classes, with character creation, a 3D selection screen, and up to five characters per account.
Networking & Backend
Everything is server-authoritative: the client sends requests, and the server validates them and decides what happens. Avalore builds as a separate client and dedicated server, and joining a server takes a signed, short-lived token, so nobody gets in without going through login.
Accounts, characters, and player shops live in a Nakama backend on PostgreSQL. The server loads a character when a player joins, and saves their level, stats, inventory, equipment, storage, currency, mounts, and position every few minutes and on logout.
I’ve also spent a lot of time on the networking costs an MMO runs into: relevancy distances per type of actor, tuned update rates, dormancy for objects that rarely change, owner-only replication for private data like inventory, and a spawn queue and registries so the server never has to scan the whole world.
Tools & Pipeline
None of the original game’s formats work in Unreal out of the box, so I built the tooling to bring them in. A separate converter I wrote handles the original files: it wraps an existing exporter for characters and animations, converts trees and effects, and exports map, object, and NPC data. Inside the editor, my Python tools then place buildings, trees, effects, and NPCs from that data, build animation montages in bulk, and finish off imported assets. That pipeline is what lets one person bring a whole town into the engine and keep it looking like the original.
What’s Next
This project is far from over. I’ve been working on it since 2023, and a lot of what makes an MMORPG an MMORPG is still missing: parties, guilds, quests, dungeons, PvP rules, and travel between zones. Only one town is playable so far, and the content in it is thin, with a handful of monsters, abilities, and items.
On the technical side, I want to add automated tests, get a shipping build working, and lock down the debug tools I use while developing. Beyond that, the list is endless. But I’m happy with where it is right now and how far it’s come.
Why I Do This
Avalore is purely a passion project, and it stays private. The original game’s IP isn’t mine, so I don’t distribute Avalore, I don’t monetize it, and I have no plans to release it on my own. I do it because I love that game and want to see how far I can take a remake of it by myself.
People usually discourage others from taking on something this big. That didn’t stop me, and I’m glad it didn’t.
If you’re wondering how I find the time for all of this on top of a full-time job: I’ll be honest, I spend most of my day behind a computer. Easily 14 hours. It’s probably not the healthiest lifestyle, but I enjoy what I do so much that I wouldn’t have it any other way.
What I’ve Learned
This project has taught me more than any course, tutorial, or single job. Building these kinds of systems from scratch taught me how game systems actually lean on each other: combat affects progression, progression affects items, items affect UI, UI affects interaction clarity, and all of it lives inside networking constraints that punish sloppy architecture.
But it goes way beyond systems design. Through Avalore I’ve gotten deep into materials, textures, scripting, test cases, coding practices, documentation, UI implementation, LODs, landscapes, heightmaps, animations, locomotion, playtesting workflows, and asking the right questions about why something works or why it doesn’t. It gave me a real understanding of the full scope of game development, not just the slice I happen to be working on at any given time.
That’s what makes me flexible as a game designer. I know what’s influencing what, because I’ve built it all myself. When I’m designing a system at work, I’m not guessing about the technical implications. I’ve lived through them.