Aarkun | Devlog #92 | Indie MMORPG | March Update (Part 3)

Another small update, in early April we also created the primary site for Aarkun! About | Aarkun

Welcome to Part 3 of the March update. After the crafting demo and starter island tour in Part 2, this one goes deeper — both literally, into the starter island dungeon, and technically, into the template systems that make Aarkun scalable to build. If you’re curious about how we add new monsters, items, and races without rebuilding things from scratch, this is the post for you.

Inside the Dungeon — Lighting, Lore & Advanced Crafting

The starter island dungeon is large enough that even I get lost in it on camera. As you move deeper inside, the lights gradually thin out — fewer candles, fewer wall sconces — until you’re effectively forced to bring your own light source.

This ties directly into the mage progression path. Mages aren’t just damage dealers in Aarkun; the class is designed to be dynamic and utility-driven. Putting points into mage abilities unlocks light spells that change how you navigate the world, not just how you fight. Players who don’t go that route will need to rely on torches and consumables instead.

The Advanced Smithing Station

Tucked inside one of the dungeon rooms is a second crafting station — and this one is more advanced than the village station you saw in Part 2. The temperature mini-game from the village setup has a soft cap on how hot it can run. To craft higher-tier items, you need stations that can reach those temperatures, which means:

Village station — basic recipes, lower temperature ceiling
Dungeon station — mid-tier recipes
Volcano station — top-tier crafts requiring the highest temperatures

That progression is woven into the lore of the world, not just the mechanics. Going to the volcano isn’t a grindy unlock; it’s part of the journey for any serious crafter.

Bandits, Dragons & Future Trap Systems

The dungeon is currently infested with bandits searching for treasures connected to dragons. There’ll be multiple dragons scattered across the world, and one of them is on the starter island — there’s some interesting dragon lore coming that I’ll save for a dedicated post.

Future dungeon features in the pipeline include:

Spike traps in narrow corridors
Flame traps in choke points
More environmental darkness to push players toward light spells and torches

The goal is to make dungeons feel like genuine expeditions where preparation matters.

Template Systems — How We Keep Aarkun Scalable

This is the part of the dev log that probably matters most to anyone interested in the engineering side. Aarkun’s content scales because we’ve built template systems that separate generic logic from per-entity configuration. Let’s walk through them.

Monster Definition Template

Adding a new NPC starts with a monster base class that gives every NPC the abilities it needs. From there, each monster just specifies:

Mesh asset — what the monster looks like
Animation instance — which animation blueprint drives its skill animations
Stats and abilities — defined on the Java side

Take the brown bear as an example. Its stat block is:

15 Strength / 15 Dexterity / 15 Intelligence
High Stamina for extra health
Move speed: 500 (slower than the player default — you can outrun it)

Then comes the skill configuration. The bear has access to:

Maim — slows the target. Won’t be cast if the target is already maimed or can’t move. 40% chance per decision tick.
Rupture — applies bleed.
Instant Heal — 70% chance to cast when the bear drops below 40% HP, with a 5-minute cooldown override.

The “decision interval” is part of the state machine — every 1 second, the bear evaluates whether to use one of its available skills based on the configured probabilities and conditions. We can also override default skill cooldowns per monster, which is how the bear’s instant heal becomes a once-every-five-minutes panic button rather than a spammable ability.

Scaling Up — The Giant Crab Boss

The same template that defines the bear also defines the giant crab boss, just with much heavier numbers:

Stat	Brown Bear	Giant Crab
Health	100	~1,000
Strength	15	130
Movement Speed	500	Faster
Skill Decision Chance	40%	60%
Heal Cooldown	5 minutes	7 seconds

The giant crab also gets:

Extended mesh range — you don’t need to be at its center point to be hit
+200 attack range on top of the mesh range, giving it a huge melee threat zone
A stomp ability that activates when at least two actors are within a 900-radius — designed for group fights
Lower cooldowns across the board because it’s a boss

There are more skills planned to push boss combat further. For example, when a boss is surrounded by multiple players, future skills might grant bonus HP, regeneration, or physical/magical damage amplification — making coordinated group fights genuinely tactical rather than just DPS races.

The Java ↔ Unreal Bridge

Once a skill is defined Java-side and triggered in combat, here’s what happens:

Java sends a message: “this actor used this skill”
The actor is mapped to its Unreal blueprint
The skill ID is looked up in the monster’s animation blueprint
The matching animation plays from the animation hit list

The framework underneath this lives on the C++ side, but the Java configuration and the Unreal animation lookup are both clean and generic. That means adding new monsters and skills is a configuration job, not a coding job — which is exactly what makes content scaling viable for a small team.

Item Data Template — One System, Every Item Type

The item system used to live in Blueprints. We’ve moved it over to C++ with a template-driven approach, so every item type follows the same loading pattern but gets type-specific behaviour.

Take a footman’s helmet as an example:

The template loads HelmetBase (C++) — which contains helmet-specific logic (e.g. removing hair and facial hair when equipped)
The template specifies per-race slot mappings — for human_male, the helm slot points to a specific skeletal mesh and material
Other items load their own base class — PotionBase for potions, etc.

The slot-to-component mapping is where this system really pays off. The same skeletal mesh can be reused with different materials for bronze, iron, and steel variants of the same helmet. We’re not fully utilising this yet, but the infrastructure is in place — when crafting variants ship, we won’t be authoring three separate helmets, just three materials.

Why This Matters

Adding a new item now means:

Drop in the skeletal mesh and 2D icon
Pick the correct item class (e.g. PotionBase, HelmetBase)
Map the slot components for each supported race

That’s it. The Java side handles gameplay effects (potion stat boosts, weapon damage), and Unreal handles visuals and animations (drinking VFX, equip animations). It’s configuration-driven, which is exactly the property you want when your content roadmap keeps growing.

Player Appearance Template — Modular Characters

Currently we support four playable templates:

Human Male
Human Female
Death Knight Male (zombified / undying)
Death Knight Female (zombified / undying)

The death knights were originally added for testing purposes while orcs and dwarves were still being configured — they may or may not be playable in the initial release. Orcs and dwarves are coming soon.

Each appearance entry specifies an animation class that drives several animation lists:

Channeling animations
Death animations
One-hit list — connected to skills
Drink animations — triggered when potions are used

When you drink a potion, the system requests your character class to play its specific drink animation — so the same potion ID will look right whether you’re a human, a death knight, or eventually a dwarf.

Modular Character Composition

We’re using Enhanced Studios assets, which break characters down into many independent components. To make those work cleanly with our backend, we built a template that composes the components together and exposes a clean entry point on the C++ side.

Adding a new race now means:

One new entry in the player appearance template
Slot updates in the item data template — e.g. adding a dwarf_male entry alongside human_male for every gear slot, with the appropriate skeletal meshes and materials

It’s a one-off setup per race. Once it’s done, every existing item works for the new race automatically. That’s the kind of leverage you need when planning multiple playable races on a small-team budget.

Mining Nodes & The Cave System

To wrap up, a quick look at mining nodes inside the cave. They’re scattered through the dungeon and tied to the dynamic backend spawning, so positions and density will be tuned as we test.

The cave layout is being designed around a few core principles:

Narrow choke points that will host trap systems in future updates
Heavy darkness in deeper sections — pushing players toward light spells or torches
Mining node distribution that rewards exploration without making it feel grindy

There’s going to be a lot of play on lighting throughout dungeons and at night across the open world. The combination of darkness, traps, and bandit ambushes is what we want dungeons to feel like — places where preparation and class choice matter.

Wrapping Up

Part 3 was a denser one — more about the systems behind Aarkun than the visible content. But these template systems are what make the content roadmap realistic. Every monster, item, and race we’ve shown so far is built on infrastructure designed to scale, which is what gives a small studio like ours a real shot at the open-world MMO scope we’re aiming for.

If you’ve got questions about any of this — the template architecture, the Java/Unreal bridge, the modular character system — drop them in the YouTube comments or jump into the Discord. I read everything.

Thanks for sticking with the dev log series. Next time, we’ll either dive into the dragon lore or the mount system that’s currently in progress — both are getting close to showable.