Services, Worlds, Scripting and the Backend

This is Part 2 of a three-part DAIKON development update.

Part 1 covered the C++ client, the 3D renderer direction, and why LibGDX is now shelved. This part covers the backend services, worlds, broadcasts, character flow and scripting direction. Part 3 covers accounts, characters, display names, billing and future player-facing systems.

Series: Part 1 — C++ Client | Part 2 — Services, Worlds and Scripts | Part 3 — Accounts, Characters, Display Names and Billing

---

In the first part, I talked mostly about the C++ client.

Why I moved the active client work away from LibGDX, why the native client makes more sense for the 3D direction, and how it now connects to the existing Java backend rather than being a separate renderer experiment.

This part is more about the backend itself. It is not as easy to show in screenshots, because a lot of it is services, protocols, world registration, account flow, character data, billing logic, chat, broadcasts and server-side structure.

But this is the work that lets DAIKON function more like an actual online game rather than just a local prototype.

 

 

From Engine Prototype to Online Game

DAIKON grew out of HELIOS, which was more of an internal 2D game engine/project base, that gave me a lot to build from, but an online RPG needs a different structure.

The client cannot be the source of truth, that is probably one of the biggest mindset shifts in the project. The client should render the world, take input, play animations, draw the UI, and make the game feel good to play. But the server needs to decide what actually exists, where a character is, what account owns what, which world is online, and what the player is allowed to do.

That is why so much of DAIKON has moved toward a service-based backend.

The C++ client can exist because the backend is not tied to LibGDX.

It is just another client talking to the same services and game server.

That is the point.

The Service Layer

DAIKON now has several backend services and shared modules around the actual game server.

I will not go into internal URLs, keys, ports, or anything like that, because that is not really useful for a public update.

But at a high level, the current service stack includes auth-service, registry-service, world-list-service, character-service, chat-service, broadcast-service, billing-service, service-common and service-protocol.

The auth-service handles login and account session flow.

The registry-service tracks running game worlds.

The world-list-service gives the client a clean way to see which worlds are available.

The character-service handles account characters, character slots, character state, and character selection data.

The chat-service handles chat communication and server messages.

The broadcast-service is for wider system messages, announcements, and update-style broadcasts.

The billing-service is intended to handle purchases, account entitlements, refunds, chargebacks and fulfilment properly.

Then service-common and service-protocol exist so every service is not duplicating the same shared code and contracts.

That probably sounds dry, but it matters.

The client should not have hard-coded world addresses.

The game server should not directly care how the website shop works.

The chat system should not be tangled into login.

Billing should not be a random check buried inside gameplay code.

Each piece needs a clear job.

It has taken longer to build it this way, but I think it is the right direction for DAIKON.

Worlds, Not Realms

One smaller change in how I think about the project is that I talk about worlds now, not realms.

In older MMO ideas I had, realms made more sense.

Those projects were closer to a traditional MMO setup, where a realm represented a separate version of the world with its own population.

DAIKON is a bit different.

A world is basically a running game server.

It registers itself with the backend, stays visible while it is online, and appears in the world list that the client can fetch.

The client does not need to know all of that in advance.

It asks the backend what worlds are available, then connects to the selected world.

That flow is already working in the C++ client.

It can log in, fetch characters, select a character, fetch the world list, and connect to the selected game world.

That is important because it proves the backend is not just theory anymore.

It is actively supporting the native client.

The Game Connection

The service layer handles the surrounding platform flow.

Login, characters, world lists, chat support, broadcasts and account-level systems all live around the actual game connection.

The world connection itself is still its own thing.

The C++ client connects to the Java game server, sends the handshake, receives the server response, and starts decoding world snapshot data.

That was one of the more important milestones for the native client.

It means the client is not just drawing test objects locally.

It is receiving server-owned state.

The game server still owns the world. The client displays it and interacts with it.

That is how I want DAIKON to work long-term.

Movement, entities, combat, NPCs, loot, progression and world rules should come from the server.

The client should not become the authority just because it is easier in the short term.

Character Flow

The character flow is also now part of the login path.

This is one of the areas where DAIKON has moved away from the older idea of an account simply being the character.

The account logs in first.

Then the client fetches the characters attached to that account.

Then the player selects a character.

Then that selected character enters a world.

That structure matters because DAIKON is being built around account identity and character identity being separate things.

The account is the platform identity.

The character is the playable identity.

That means characters can have their own slots, status, display names, playtime and long-term progression without everything being welded directly to the account username.

I will go into this more properly in Part 3, because character slots, display names, name changes and billing all connect to it.

But it is worth mentioning here because the backend flow is already being shaped around that model.

Chat and Broadcasts

Chat and broadcasts are also separate from the core game server.

That is deliberate.

Chat is one of those systems that can become messy if it is buried directly into everything else too early.

The chat-service gives DAIKON a cleaner place for chat-related communication and server messages.

The broadcast-service is a separate piece for wider announcements, system messages, update notices and similar backend-driven messaging.

That might sound like overkill for an early project, but I think it is better than treating messages as random strings fired from wherever.

Eventually, this kind of structure should help with things like system updates, world notices, global announcements, and controlled messaging between services.

Billing Without Bolting It Onto the Game Server

Billing is another part I wanted to separate early.

DAIKON will use the website/shop side for purchases, but the game still needs to reconcile those purchases into account entitlements safely.

That should not be done by the client.

It should not be trusted just because a website page says something happened.

It should not be hacked directly into the game server either.

That is why billing-service exists.

The broad idea is that billing-service can look at completed purchases, refunds, chargebacks, account entitlements and fulfilment state, then decide what DAIKON should actually grant or revoke.

For something like extra character slots, that matters a lot.

If a player buys a slot, the game needs to know whether it was already delivered, whether the payment is still valid, and what should happen if the payment later becomes refunded or charged back.

That is not something I want to solve with random one-off checks.

It needs to be part of the backend properly.

GraalJS and Server Scripting

Another thing I have been looking at is scripting.

The idea is to use GraalJS/GraalVM on the Java server side so some gameplay content can live outside the hard-coded server core.

Not every object interaction, NPC interaction, dialogue, tutorial step or small content behaviour should require rebuilding the whole server.

That does not mean I want the entire game to become a pile of loose scripts.

The server still needs a strong core.

But content needs to be easier to work with than editing Java classes every time I want to test a basic interaction.

The important part is reload safety.

I do not want a script reload system that leaves the game half-updated if something fails.

The better version is to rebuild a full script bundle, validate it, and only swap it in if it works.

If it fails, the previous working scripts stay active.

That gives DAIKON a better path for future content work without making the server fragile.

It also fits the kind of game this is supposed to become.

An online RPG needs lots of small interactions, not just big engine systems.

Objects, NPCs, dialogue, shops, quests, tutorials, events and world content all need to be practical to build.

Scripting should help with that later.

Data-Driven Content

This also connects to the broader data-driven direction.

DAIKON already has a lot of systems moving toward shared definitions and files instead of hard-coding everything into one client.

That matters more now because the active client is C++, while the backend is still Java.

The more data-driven the project is, the less the game depends on one specific client implementation.

Items, NPCs, objects, map regions, placements, UI documents, models, animations and shaders should eventually be described in ways the client can load cleanly.

That also leaves room for future tools.

I still want DAIKON to eventually have its own editor or editor-mode workflow.

Something that can visually edit maps, tile heights, objects, collision, terrain, planes and eventually DAIKON’s own region format.

That is not the next immediate milestone, but I do not want the architecture to block it later.

Why This Backend Work Matters

The obvious missing part is still the actual RPG loop.

DAIKON still needs proper combat, NPCs, loot, banking, gathering, production, progression, trading and content.

That is the part that will make it feel like a game.

But I do not think this backend work is wasted time.

If account identity is wrong, everything built on top suffers.

If character ownership is wrong, slots and name changes become messy.

If billing is bolted on later, it becomes risky.

If the client owns too much state, cheating and desync become worse.

If worlds are hard-coded, the whole thing feels like a local prototype.

So yes, this work is boring compared to showing a new model or shader.

But it is also the work that makes the rest of the game safer to build.

Where This Leaves the Backend

The backend is not the flashy part of DAIKON, but it is becoming one of the most important parts.

The C++ client can exist because the backend is separate.

The game can have multiple worlds because worlds register through services.

Characters can become proper playable identities because they are not just account names.

Billing can be handled properly instead of being hacked into the game server.

Scripting can eventually make content iteration easier.

There is still a lot to do, but the shape of the project is much clearer now than it was when DAIKON was just a client and some early engine work.

In the next part, I will go more into the player-facing account systems: characters, slots, display names, name changes, billing, future membership, and how those pieces fit into the kind of online RPG DAIKON is meant to become.