UE5 MMO Devlog 86 – Refactoring character to C++

Hey everyone — it’s been about a month since the last update, and quite a lot has changed behind the scenes.

This post focuses on one of the biggest technical improvements: a full refactor of the character system, why it took so long, and what it unlocks going forward.

---

What We Had Before

Previously, the character system was built entirely in Blueprints, using a layered hierarchy:

• Base actor (shared by players & monsters)
• Multiple intermediate Blueprint classes (some acting like interfaces)
• A PlayerBase layer containing all player-specific components:
  • Parties
  • Talents
  • Appearance resolvers
  • Notifications, etc.
• Final character instances (e.g. humanoids) defining:
  • Skeletal meshes
  • Appearance setup

It worked — but it wasn’t ideal:

• Harder to scale
• More overhead when adding new content
• Logic spread across multiple layers

---

What Changed

We refactored the system into C++ with config-driven design, exposing only two main Blueprints:

• Player Character
• Creature Character

Everything else is now driven through structured data.

---

Why Move to C++?

Short answer:

• More scalable
• More dynamic
• Better performance
• Cleaner architecture

Blueprints can handle this — but as complexity grows (especially in an MMO), it becomes harder to maintain and extend efficiently.

---

Config-Driven Characters

Instead of creating new Blueprint classes for every variation, we now define things through templates/configs.

1. Player Race Template

Defines valid combinations like:

• Human (Male/Female)
• Death Knight (Male/Female)

Adding a new race (e.g. Orc, Dwarf) is now just:
→ Add a new config entry

It also allows flexibility:

• Not all races need both genders (e.g. robots)

---

2. Player Appearance Template

This is the core of character setup.

Each entry defines:

• All skeletal mesh components (e.g. chest, legs, etc.)
• Default meshes & materials
• Optional/empty components where needed
• Tags for dynamic lookup (used for equipping items)

This enables:

• Dynamic equipment swapping
• Clean mapping between inventory and character visuals
• No hardcoded mesh logic

---

Animation System Refactor

Animations are now also config-driven.

Instead of hard references:

• We use a map of animation keys → animation assets

Examples:

• Channeling
• Dead
• Attack
• HitReaction

Other systems (skills, items, etc.) simply call:

“Play animation with key X”

They don’t need to know:

• Which animation
• Which character type

This decouples:

• Gameplay systems ↔ Character implementation

---

In-Game Improvements

Functionally, things work as before — but with improvements:

• ✅ Strafing, forward/backward movement improved
• ✅ Casting system refined (start → complete → effect)
• ✅ Hit reactions added (still being polished)
• ✅ New map in progress (separate update coming)

---

Why It Took So Long

This wasn’t a small change.

The character system is core to everything, so refactoring meant:

• Updating all systems referencing characters:
  • Skills
  • Items
  • Combat
• Rewiring dependencies across the project
• Changing underlying architecture

That’s why it took ~1–1.5 months.

---

What This Unlocks

Now that this is done:

• Adding new races = config only
• Adding new gear = plug into system
• Animations are fully modular
• Systems are more decoupled
• Faster iteration going forward

This is one of those changes that slows you down short-term, but massively speeds things up long-term.