Accounts, Characters, Display Names, Billing and What Comes Next

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

Part 1 covered the C++ client, the 3D renderer direction, and why LibGDX is now shelved. Part 2 covered the backend services, worlds, broadcasts, character flow and scripting direction. This final part covers accounts, characters, display names, billing, future membership and what comes next.

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

---

In the first two parts, I talked about the C++ client and the backend services.

The first part was mostly about why the active client work moved away from LibGDX, why the native C++ client makes more sense for the 3D direction, and how it now connects to the existing Java backend.

The second part was more about the backend itself: services, worlds, character flow, chat, broadcasts, billing, scripting and the structure needed for DAIKON to behave more like an actual online game.

This final part is more about the player-facing systems that sit on top of that.

Accounts, characters, display names, character slots, billing, future membership and how those pieces fit into the kind of online RPG DAIKON is meant to become.

These systems are not as exciting to show as a 3D client or a shader test, but they matter a lot.

If these foundations are wrong, they become painful later.

---

Account Does Not Mean Character

One of the bigger changes in DAIKON is that an account and a character are not the same thing.

The account is the player’s platform identity.

The character is the playable identity inside the game.

That sounds obvious, but it is easy to get wrong early on.

Older projects often treat the username as the character. That works for a very simple setup, but it becomes painful once you want multiple characters, character slots, display name changes, character-specific status, account-level punishments, billing entitlements or proper character selection.

DAIKON is being built around the cleaner model.

An account can own multiple characters.

Each character has its own internal identity, slot, display name, progress, status and playtime.

The display name is what players see.

The internal character identity is what the server trusts.

That separation matters because it means a character can change name later without breaking ownership, history, billing, moderation or anything else tied to that character.

Character Slots

The current direction is that accounts have a base number of character slots, with optional extra slots available later.

This is not meant to be a power purchase.

An extra character slot does not make a character stronger. It does not give gear, stats, pets, cosmetics, boosts or progression.

It just gives the account more room for alternate characters.

That is the kind of monetisation I am much more comfortable with.

I do not want DAIKON to sell weapons, armour, pets, animations or cosmetic skins.

If someone is wearing something cool, using a rare item or showing off a pet, I want that to come from the game.

They should have earned it, found it, crafted it, traded for it or unlocked it.

Not bought it from a shop.

Character slots feel like a cleaner way to support the project without damaging that principle.

Character Deletion and Archiving

Characters are intended to be persistent.

That does not mean a newly created mistake has to be permanent forever, but deletion needs rules.

A very new character should probably be deletable or resettable during an early grace period, as long as it has not meaningfully touched the wider game.

Once a character has traded, used paid services, been involved in moderation, joined persistent systems, or left a real footprint in the world, deleting it becomes much more dangerous.

At that point, archiving or hiding the character is safer.

It keeps logs, billing history, moderation history, name history and account integrity intact.

That is less convenient than a simple delete button, but DAIKON is meant to be a persistent online RPG.

Persistence needs to mean something.

Display Names and Name Changes

Display names are another system I want to handle carefully.

Names matter in online RPGs.

They are social identity. They carry reputation. They are how players recognise each other.

At the same time, the visible name should not be the true identity of the character internally.

That is why DAIKON separates the stable character identity from the display name.

A character can change display name later, but the underlying character record remains the same.

That means name changes can exist without breaking ownership, history, moderation or account data.

The name system needs to handle uniqueness, reserved names, inappropriate names, impersonation, cooldowns, previous-name history and moderation tools.

I am also considering display-name changes as a paid service later.

Not because I want names to become a cash grab, but because name changes should be deliberate.

If players can rename constantly, reputation becomes weaker and moderation becomes messier.

If name changes are controlled, logged and limited, they are much safer.

Account-Level and Character-Level Moderation

Another reason for separating accounts and characters is moderation.

DAIKON can handle discipline at more than one level.

Some issues may only need to affect a specific character.

Other issues may need to affect the whole account.

For example, a character-specific punishment might make sense for something tied to that character’s behaviour or progression. But repeated or serious issues across multiple characters should be able to escalate to the account level.

That gives the system more flexibility than treating everything as either harmless or a full account ban immediately.

It also means moderation can be more proportionate.

The goal is not to make moderation complicated for the sake of it.

The goal is to avoid building a system where every punishment is forced through one identity layer, even when that does not fit the actual problem.

Billing and Entitlements

DAIKON is also getting a proper billing-service rather than letting the game server directly trust website or client-side claims.

The website/shop side can handle the purchase.

DAIKON still needs to reconcile that purchase into account entitlements safely.

That matters because payments are not just “paid” or “not paid.”

There can be completed purchases, refunds, chargebacks, expired entitlements, duplicate fulfilment attempts and changed payment states later.

If someone buys an extra character slot, the game needs to know whether that entitlement was already delivered, whether the purchase is still valid, and what should happen if the payment is later refunded or charged back.

That is why billing belongs in its own service.

The game server should not be guessing.

It should receive clean account entitlement state from the backend instead of trying to become the shop, payment processor and fulfilment system all at once.

Future Membership

The future membership model is still something I think is worth mentioning, because it affects how DAIKON should be built.

At launch, I do not want DAIKON to feel like a chopped-up free version of a paid game.

The launch version should be free-to-play and complete within its own scope.

That does not mean huge.

It does not mean endless.

It just means the available launch game should feel like the actual game, not a thin demo where the real content is locked away.

Membership, if and when it happens, should come later as an expansion layer.

New areas, deeper systems, larger encounters and longer-term content can make sense as member content later, especially if the game needs to fund itself.

But free-to-play should still receive meaningful updates too.

That is important to me.

DAIKON is meant to be lightweight and accessible. The monetisation should not fight against that.

That is also why I am not interested in a cosmetic shop full of weapons, armour, pets or animations.

I would rather monetisation be boring and honest than damage the value of items inside the game.

Why This Matters Before the Game Loop

The obvious missing part is still the RPG loop.

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

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

But the account and character model affects all of that.

Combat progress belongs to a character.

Inventory and bank data belong to a character or account depending on the system.

Membership belongs to the account.

Extra character slots belong to the account.

Display names belong to characters, but need account-level history and moderation visibility.

Billing belongs to the account, but may unlock character-related features.

All of those boundaries matter.

If they are wrong now, the proper gameplay systems become messier later.

So while this is not as exciting as building combat or adding a new area, it is still part of building the game properly.

What Comes Next

The next major step is still getting the native client and backend foundation solid enough to move back into gameplay properly.

The C++ client is already the active client, and the backend services are now far more structured than they were earlier in the project.

That means the focus can start moving back toward the actual RPG loop.

• Log in.
• Select a character.
• Enter a world.
• Move around.
• Fight something.
• Loot something.
• Bank something.
• Gather something.
• Make something.
• Progress.
• Come back later.

That is the heart of it.

Everything else exists to support that loop.

---

Closing Thoughts

DAIKON has changed a lot technically, but I think the project is clearer now.

It started as a 2D client.

Then the 3D renderer became interesting because of the production reality around sprites, equipment, animation and long-term content.

Now the C++ client is the active direction because it feels like a better foundation for the renderer and platform control I want.

At the same time, the backend has grown into a more serious service-based structure.

Accounts, worlds, characters, chat, broadcasts, billing, scripting and shared protocols are all starting to find their place.

That can make the project look like it is moving sideways sometimes.

Maybe it has been.

But I think the shape is better now.

DAIKON is 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, but modernised where it actually helps.

The next real test is turning all of this foundation back into visible gameplay.

That means continuing with the native client, keeping the backend clean, and building the actual RPG loop on top of it.

DAIKON still needs to become a game people can log into, play, progress in and care about.

That is the next stage.