DAIKON Development Update: Skills, World Actions, and Reward Tables

Note: Diagrams in this post are AI Generated, I'm not graphically inclined to do them myself, Updated at 21st of June, 2026 at 11:30AM; reason: typos fixed.

It has been a while since I wrote a proper DAIKON development update focused on the actual gameplay.

The last larger updates were mostly about the bigger technical direction: the C++ client, the renderer, the backend services, and why the project needed a cleaner foundation before the gameplay layer could really start moving again.

This update is more about that gameplay layer starting to come back to the surface and getting some more focus.

Not in the sense that DAIKON suddenly has everything it needs for a full player loop. It does not.

But the project has moved past just talking about skills, objects, progression and server-side actions as design ideas. Some of those systems now exist in early form, and that changes the conversation a bit.

This update covers the skill system changes, why the older branch-based model is gone, the first real Woodcraft/logging action, world object replacement, the new attribute and varbit foundation, the task system, pulse system, cleanup work, and why I am starting to move some services toward always-online testing.

There are also some notes on hardware, because that has become part of the project setup too.

The Skill System Has Changed Quite A Lot

One of the bigger changes recently is that the skill system has been simplified based on feedback online from colleagues, friends & family feedback.

Earlier design work used to be branch-based model.

The idea was that some skills could have internal branches. For example, ranged progression was previously treated as a broader discipline with seperate combat and production parts. That meant a player could be good at ranged combat without also being equally skilled at making bows or ammunition.

That was the rough thinking. On paper, it had some advantages. It gave room for specialisation, it made it possible to seperate combat use from production use. It also let the game represent broader discipline without forcing every part of that discipline to contribute towards combat.

The problem is that once the design moved closer to implementation, the cost became clearer:

The skils tab became harder to explain
XP Storage became more awkward.
Combat level calculation needed more exceptions.
Every action has to answer the same question: Does this award parent XP, branch XP, derived XP or a special case?

That is too much complexity before the game has even proved or shown the basic RPG loop, so the visible branch model is gone. Skills are now top-level progression tracks:

Player trains a skill
The server stores XP against that skill.
The UI displays that skill
The combat system reads from that skill

Activity names can still exist, but they are not seperate visible XP tracks by default:

Logging can exist as an activity under Woodcraft.
Essence siphoning can exist as an activity under Charge Magic.
Lockpicking can exist as an activity under Roguery.
Forging can exist as an activity under Metallurgy.
But those are actions, labels, recipe groups, or content categories.
They are not separate branch skills.

That is a much cleaner foundation.

It also makes the system easier to explain publicly. Instead of showing players a hierarchy of parent skills, branch levels, derived levels, and combat eceptions, the game can just show the skill list and let the content give each skill it's own identity.

The Current Skill Direction

The current skill list is more direct, Combat stays readable:

Attack - Melee accuracy, and melee weapon requirements.
Strength - Melee damage and strength-gated behaviour.
Defence - Armour, mitigation & reduced chance of being hit.
Hitpoints - Health and Endurance.
Ranged - Ranged combat, and ranged equipment gate.
Magic - Spellcasting & Magical equipment - Gate
Faith - Is the prayer-equivalent support skill (buffs whilst active).

That part is deliberately familar and are meant to be immediately understandable. I do not think every part of DAIKON needs to renamed or reworked to look difference. if a readable old-school structure works, it is better to keep it readable.

The non-combat skills is where DAIKON starts to define more of it's own identity:

Charge Magic - Replaces the old rune-crafting-style pressure with a skill focused on essence gathering, staff charging, staff siphoning, catalysts and all things magic up-keep.
Mining - Self explainitory, click rock!
Fishing - Self explainitory, click fishing spot!
Foraging - covers herbs, mushrooms, crops, fibres, seeds, oils, toxins, and natural reagents.
Woodcraft - covers logging, bows, shafts, timber, planks, firecraft-style outputs, resins, oils, and future wood-side construction ideas.
Hunting - covers tracking, contracts, trapping, beasts, hides, pelts, bones, trophies, and creature resources.
Metallurgy - covers smelting, forging, alloys, armour, tools, weapons, gem cutting, and jewellery bases.
Cooking - remains separate from Fishing because gathering fish and preparing food are different loops.
Crafting - Still exists, but it is narrower. It is not a giant catch-all bucket. It is for finishing, assembly, repair, ornamenting, and mixed-material outputs where that hybrid identity actually makes sense.
Roguery - covers access utility: lockpicking, pickpocketing, shortcuts, stealth, sabotage, and similar systems.

The important change is not just the list of names, the important change is ownership. Each skill now owns its XP directly, that should make future gameplay systems much easier to build.

Crafting is Not a Dumping Ground

One design rule I still care about is that Crafting should not become a dumping ground for everything handmade.

A lot of older RPG systems have one enormous Crafting skills that quietly owns jewellery, leather, glass, pottery, textiles, staves, gems, random decorative items, and anything else that does not fit somewhere obvious.

I do not think DAIKON needs to do that. If an output has a clear material source or gameplay purpose, it should belong there.

Jewellery bases and gem work belong under Metallurgy.
Enchantments and charged effects belong under Magic.
Bows, shafts, timber parts, and wooden components belong under Woodcraft.
Hides, pelts, bones, trophies, and creature materials belong under Hunting.
Herbs, oils, toxins, mushrooms, fibres, and natural reagents belong under Foraging.

Crafting can still exist, but as a more specific finishing and assembly skill, that is a better role for it! It can handle things like studding armour, reparing robes, ornamenting jewellery, reinforcing gear, decorative assembly, and hybrid outputs that genuinely require multiple material sources.

That gives Crafting an identity without making it responsibile for everything.

This should also help the economy later. A player should be able to understand why an item belongs to a skill:

If something is metal and gem based, it should probably involve Metallurgy.
If something is magical, it should probably involve Magic or Charge Magic.
If something comes from a beast, Hunting should probably matter.
If something comes from timber, Woodcraft should probably matter.

That is easier to reason about than one huge Crafting skill and recipe list.

Magic and Staff Charge

Magic is another area where DAIKON is still trying to keep old-school pressure without copying old inventory friction directly:

Magic remains the spellcasting skill.
Charge Magic supports it.

That distinction matters.

Magic handles spell access, spellcasting, teleports, utility spells, enchantments, and magical combat identity.
Charge Magic handles essence gathering, staff charging, staff siphoning, catalysts, and magical upkeep.

The idea is that spells consume charge from the equipped staff, and the staff becomes the magical weapon and resource container.

A staff can have an archetype.

Fire.
Earth.
Frost.
Blood.
Storm.
Light.
Neutral.
Future types can exist later if they make sense.

Matching spells are cheaper, off-archetype spells are allowed, but inefficient. Neutral staves are more flexible, but less specialised.

So a Fire staff should feel like a Fire staff. An Earth staff should feel better for control and stability. A Blood staff can lean into sustain, leeching, sacrifice, or risk/reward magic. A Neutral staff can work as a flexible option without being the best at everything. That keeps magical upkeep, preparation, and economy pressure without filling the normal inventory with rune stacks.

The player still maintains something.
The market still has a resource loop.
Gathering still matters.
Boss drops can still support magical upkeep.

But the pressure lives on the staff and in the essence economy instead of becoming normal inventory clutter.

Charge Magic and Essence Siphoning

Charge Magic is where the staff upkeep loop becomes its own progression path.

The basic idea is that players can gather essence as a normal resource. If they have a compatible staff equipped, part of the gathering action can also siphon bonus charge into the staff.

For example, a player gathering Earth Essence might receive the normal essence output into inventory, pouch, storage, or whatever the final system uses. At the same time, if they have a compatible Earth-style staff equipped, the staff can receive a smaller amount of bonus charge.

That means essence gathering produces two things:

The normal tradeable or storeable resource.
A direct upkeep benefit for the equipped staff.

That is a useful loop.

It lets gatherers supply the economy.
It lets Magic users prepare through trade, gathering, boss drops, or bank presets.
It also gives staff choice and archetype matching more purpose.

The goal is not to recreate RuneCrafting with a different name, the goal is to have a magical upkeep economy that fits DAIKON better.

Combat Level is Cleaner Now

The combat level model is also cleaner now that the branch system is gone. Previously, combat level needed to read from branch-specific combat paths and that made sense inside the old design, but it is not necessary anymore.

Now the combat skills are direct.

Melee offence comes from Attack and Strength.
Ranged offence comes from Ranged.
Magic offence comes from Magic.
The primary offence is whichever of those styles is strongest.
Defensive core comes from Defence and Hitpoints.
Faith contributes as a support skill, but does not dominate the formula.
The important rule is that production skills do not inflate combat level.
Woodcraft making bows should not raise Ranged combat level.
Charge Magic supporting magical upkeep should not raise Magic combat level by itself.
Metallurgy making weapons or armour should not directly raise combat level.
Crafting gear should not raise combat level.

That separation matters because combat level should describe combat readiness, not every supporting economy skill around combat.

The First Real Skilling Action

The biggest practical gameplay update is that skilling is no longer just design documentation, the first real server-side skilling action is now in place: Woodcraft logging.

It is still basic, but the shape is important:

A player clicks a tree object.
The server resolves the tree data from the object ID.
The server checks the player’s Woodcraft level.
A logging action is scheduled.
Every few ticks, the action rolls for success.
On success, Woodcraft XP is awarded.
The tree is replaced with a stump.
The tree respawns later.

That is the first proper version of the loop, not a final skilling system. But the foundation is now real!

This matters because it proves several systems at once:

World objects can represent resources
Player interactions can start server-side actions
Actions can run over time
Skills can receive XP.
The world can change in response.
Objects can respawn later.

That is one of the first points where DAIKON starts to feel less like a renderer, service stacks or design document, and more like a beginning of a Game.

Skill Actions as a Foundation

The logging action sits on top of a broader action structure, there is now a shared skill action base that knows which skill owns the action That sounds small, but it matters:

Mining should not be a totally different one-off structure from Woodcraft.
Fishing should not be a completely separate hack.
Foraging, Hunting, Charge Magic, Cooking, Metallurgy, Crafting, and Roguery should all be able to use common ideas where possible.

A skill action can know:

Which player owns it.
Which skill it belongs to.
How often it ticks.
Whether walking should cancel it.
What validation it performs.
What happens when it completes.
What happens when it is cancelled.

That gives DAIKON a cleaner way to build repeated gathering actions, timed production actions, and future contextual skill actions, the first version is simple, but that is fine. simple and consistent is better than clever and fragile.

Temporary World Object Replacement.

The Woodcraft logging implementation also introduced a more general world object system.

The server can now temporarily replace one world object with another.

For logging, that means:

Tree becomes stump.
Then later, stump becomes tree again.

That is the obvious use case, but the system matters beyond trees:

It can support depleted rocks.
Opened doors.
Temporary barriers.
Broken or repaired objects.
Event objects.
Quest objects.
Tutorial changes.
Resource nodes.

Instanced or phased objects later.

The important part is that the server is changing the world object, updating collision where needed, marking the static world snapshot dirty, and scheduling the object to return, Objects are not just scenery:

They are interaction points.
They affect collision.
They affect pathing.
They affect what the client should display.
They affect what the player can do.

So this is not just a visual change, it's the first step of making the Game World feel alive.

Player Attributes, Varbits and Object Overrides

Another major foundation is the new attribute system. This is one of those systems that sounds boring from outside but becomes important very quickly in an online RPG:

A Character needs state.
Some of that state is persistent
Some of it is session-only

What's the difference between persistent and session?

Persistent survives logout.
Session state only last while the player objecti s alive (logged in).

The new attribute map gives the Server a cleaner place to store those kinds of information. Right now the important pieces are player varbits and player object overrides.

Varbits are useful for persistent character state:

Quest stages
Tutorial progress
Unlocked routes
Dialogue state.
Single-time reard claims
World event progress.
Character flags.
Account or progression markers.

Object overrides are different:

They let one player see a different version of an object from another player. This is seperate from global object replacement, if a tree is cut down, everyone should see the stump. That is a global state.

But if one player has repaired a bridge during a quest, and another has not, those players may need to see a different object state. That is per-player state.

The seperation matters.

Global object replacement is for shared world-change.
Player object overrides are for personal world state.
Varbits are saved Character progress.

If those systems are kept seperate now, future content such as:

Quests
Tutorials
Unlocks
Phased world content

Should be much erasier to build later. A future script should be able to say in effect:

This player has completed this step
Set this Varbit
Show this object differently for this player
Unlock this shortcut
Do not make everyother player see the same change.

That is the kind of RPG infrastructure DAIKON needs before larger content makes sense.

Player Tasks, Pulsing and Logout Cleanup

Another important piece of important work is the task and Player lifecycle structure. This isn't flashy, it isn't something that makes a good screenshot.

But it does matter, there is now a clearer player pulse task with hooks for things like buffs, debuffs, cooldowns and temporary state ffects.

Those hookes are not fully implemented systems yet, but having a place for them matters. Online RPGs need timers everywhere:

Temporary boost
Debuffs.
Cooldowns.
Faith effects.
Combat states.
Skilling states.
Poison
Damage-over-time effects
Temporary restrictions
Runtime flags

If every one of those systems get bolted directly into the world loop later, the code becomes unpleasant very quickly. A Player pulse layer gives those systems somewhere to live.

Player removal has become more deliberate. Logging out of an online world is not just deleting a Player object. The server needs to clear pending actions, queued movement, save character state, release character locks, clear session sate, cancel task, and only then can it remove the Player from the world, this is why some MMORPG's are cautious about handing out punishments whilst your online, only affecting you them you log back in.

That matters because DAIKON now has Account and Character seperation, character locks, async saves, service-backed character flow and long-term persistence:

The removal flow needs to be safe
It also leaves room for future blockers:
- Combat logout delay
- Death animation
- Trade cleanup
- Activity restrictions
- Minigame state
- Pending save work

Those are not all wired yet, but the shape is now there. That is the kind of system Players should never notice when it works.

But if it is wrong, everything else becomes unreliable.

Gathering and Production Are Different Loops

The first Woodcraft action also reinforces one of the older design principles that still holds: Gathering and production should not feel the same.

Gathering is a World Interaction
- The Player clicks a resource node, gathers over time, validates tools, levels and space, receives output and XP, eventually the node depletes or changes.
Production is different
- The player chooses a recipe, chooses a quantity, the server calculates what is possible, and a timed action processes the materials in batches.
- Make-All should actually mean Make-All
  - If a player has enough materials to make a large stack of arrows, meals, bars, potions or components, tjhe server should not create one million seperate events. It should represent the job as one production action with batch ticks. That keeps the action server-controlled and interruptible without turning production into pointless menu repetition.

The Naitive Client Still Matters Here.

The C++ client remains the active client direction. That matters for this update these server-side gameplay systems eventually need to be visible and usable through the Client:

It needs to show object changes.
It needs to handle interfaction feedback
It needs to show world snapshots, and static snapshot updates.
It needs to support:
- object clicks
- right click menus
- chat messages
- XP feedback
- Inventory changes
- Animations

The server can already begin doing more of the real game logic, the Client now needs to keep catching up to that and start feeling like an actual Game Client.

(Tab orders, Attack style, Skills, Quests, Inventory, Equipment, Faith, Magic, Social, Guild & Settings)

Hardware and Portable Development

There has also been practical hardware investment around the project, I recently picked up a 2019 16-inch Intel Macbook Pro, with a Core I9 (2.4Ghz), 64GB RAM, and a 1TB SSD, it's not replacing my main development PC, the Macbook is more of a portable workhorse, alongside an iPhone 13.

Longer term, I still think a Steam Deck, and an Apple Silicon Mac makes sense as future test devices, as we still want to target those platforms too, but I am happy to announce that iPhone development, and MacOS Development could be possibilities (I currently use an Android phone daily, so I always had access to an Android device to test potential mobile builds on).

Anyway, this isn't about buying hardware for the sake of it, it's about building practical testing, and animation setup around DAIKON.

Always-Online Service Testing

The other practical shift is moving some services toward being always online, Local development is useful. But local-only testing hides problems:

Networking is too clean
The startup order is too familiar
The enviroment is too controlled
The developer know what is running, because the Developer started it all manually.

A real online game does not work like that, it works like this:

Services need to be reachable.
They need to survive restarts
Client need to handle latency
Authentications need to stay reliable
The world list needs to reflect real running worlds.
Character locks need to renew and release correctly
Chat and Broadcast systems need to behave as seperate systems

The Game Server needs to exist as a part of a wider platform, not just a local process. Putting some services onlien earlier should help expose issues sooner. It should also reduce demand on local hardware. The development device does not need to run every service, database, test client, development tool, and world server everytime I want to test a basic Client session, so a small always-online test setup can give the project a more realistic baseline.

Reward Tables Are Part Of the Foundation Too

Another system I want to talk about briefly is rewards. Not just monster drops, rewards in gneeral.

DAIKON needs a system that can handle combat loot, skilling rewards, chests, crates, object looting, event rewards, quest rewards, boss rewards, raid rewards, rare drops, collection style-tracking, and future activity rewards without every system inventing it's own one-off reward logic.

That is why I have been building a reward-table system, I do not want rewards to be hardcoded list buried inside of NPC's code, that may work as a tiny prototype. But it doesn't scale well one the game has bosses, skilling, chests, special events, minigames, rare broadcasts, partiicpation rules and different ways to award items.

A reward source can ask the reward system to roll a table (with nested tables), the source could be:

An NPC
A Boss
A Chest
A Reward Crate
A Quest
A future Event

The table system should not care much where the reward request comes from, It should care about the Reward context:

Who is receiving the reward?
What source created it?
Was there valid participation?
Are there modifiers?
Is the reward guaranteed?
Is it weighted?
Is it rare?
Does it need to Broadcast?
Doesi t need to be tracked in the Collection Log?
Does it go to the Inventory, Ground, Bank, Coffer, or somewhere else?

That is the kind of Structure I want DAIKON to have, The current idea is rewards should be seperate into a few clear stages:

Reward source
- The reward source is the thing asking for a reward.
Reward context
- The reward context describes the situation.
Roll result
- The reward table defines possible outcomes.
- The roll result is what the table produced.
Award destination
- The award destination decides where the reward goes.
Post-roll hooks
- The post-roll hooks can handle things like collection tracking, messages, broadcasts, achievements, or future account/character unlocks.

That seperation is important, and it matters. Rolling a reward and awarding a reward are not the same thing.

A combat drop, a create, a quest chest might all use the same reward-table structure. But they may award the result differently.

Combat might place an item on the Ground.
A chest might put the item directly into the Inventory.
A boss coffer might store the result until claimed.
A future event might roll several tables and broadcast the rare result.

Those should not all be completely seperate reward systems, they should be different uses of the same system.

This also connects back into the wider DAIKON design.

Combat needs rewards.
Skilling needs occasional secondary rewards.
Bosses need participation-aware rewards.
Events need flexible reward tables.
Future reward containers need reusable behaviour.

The economy needs item sources that can be controlled and tuned.

If every system invents its own reward logic, balancing the economy later becomes much harder.

So even though the full combat loop is not finished yet, the reward-table work matters now.

It means loot and rewards are not being treated as an afterthought.

When NPC combat, bossing, skilling crates, chests, and future activities are ready for proper rewards, there will already be a system direction for handling them.

That is the important point.

DAIKON is not just getting “drops.”

It is getting a reusable reward foundation.

Where Is DAIKON Now?

DAIKON is still early.

There is still no complete playable RPG loop.

Combat still needs work.
NPCs need work.
Banking needs work.
Inventory integration needs work.
Production needs work.
The client needs more UI work.
Animations and models need more work.
But the foundation is no longer just abstract.
There is now a direct skill model.
There is a skill XP service.
There is a combat level calculation.
There is a skill action structure.
There is a first Woodcraft logging action.
There is temporary world object replacement.
There is player attribute state.
There are persistent varbits.
There are object overrides.
There are player pulse hooks.
There is a cleaner removal/logout task flow.
There is a reward-table system direction for combat loot, skilling rewards, chests, crates, events, and future reward sources.
There is a backend service stack that already supports the surrounding platform.
That is a very different place from simply saying, “eventually the game will have skills.

What Comes Next

The next step is to keep turning foundations into loops.
Woodcraft logging needs to become more complete.
Actual inventory rewards.
Axe and tool requirements.
Distance checks.
Animation hooks.
Better success formulas.
Object definition integration.
Client feedback.
XP drops or skill tab updates.
Then the same pattern can expand into Mining, Fishing, Foraging, Hunting, and Charge Magic.
Production needs its own loop too.
Choose recipe.
Choose quantity.
Validate materials.
Process timed batches.
Create output.
Award XP.
Stop cleanly.
Combat needs the same treatment.
NPCs.
Damage.
Accuracy.
Defence.
Hitpoints.
Adrenaline.
Magic staff charge.
Faith utility.
Equipment requirements.

The basic goal is still simple:

Log in.
Select a character.
Enter a world.
Move around.
Click something.
Do the action.
Get something.
Progress.
Bank or prepare.
Come back later.

That is the heart of the game. Everything else exists to support that loop.

Closing Thoughts

The older branch-based skill design was useful.

It helped explore how DAIKON could avoid copying older games directly.

But it was not the right foundation for this stage of development. The current direction is simpler where it needs to be simpler.

Top-level skills.
Direct XP ownership.
Readable combat.
Clearer skill identities.
Server-side skill actions.
World objects that can change.
Player state that can persist.
Tasks that can manage player timers and safe removal.
Services that can be tested like an online game.

That feels like a better foundation.

DAIKON is still not meant to be a giant MMO.

It is not meant to be a remake.
It is not meant to be a private server with renamed systems.
It is meant to be a small, readable, server-backed online RPG with old-school roots, modernised where it actually helps.
The next real test is turning all of this into visible gameplay.

That is the stage DAIKON needs to move into now.

Posted on June 20, 2026 by RadRadish

You must be logged in to leave a comment.