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
PlayerBaselayer 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:
ChannelingDeadAttackHitReaction
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.
