Moving the Client Forward: C++, 3D, and the renderer direction.

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

Part 1 covers the C++ client, the 3D renderer direction, and why LibGDX is now shelved. Part 2 covers the backend services, worlds 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

---

It has been a while since I posted a proper DAIKON development update.

The last major update focused mostly on the experimental 3D renderer: why I started testing it, why the old 2D direction had become harder to justify from a production point of view, and why a stylised 3D presentation might make more sense for the kind of online RPG I am trying to build.

Since then, the project has moved quite a bit further.

DAIKON now has a native C++ client prototype.

That is probably the biggest technical shift since the 3D renderer experiment began, so I want to explain where that decision came from, what currently works, and what it means for the older LibGDX client.

 

Why the Client Moved to C++

DAIKON originally used a Java/LibGDX client because that made the most sense at the time.

The server-side work was already Java-based, the project had grown out of earlier HELIOS work, which was my internal 2D game engine/project base, and LibGDX gave me enough control to build a custom lightweight client without jumping straight into a large commercial engine.

For the original 2D renderer, that was a good fit.

Even for the first 3D renderer tests, it was useful. It let me prove early ideas around tile-based world rendering, character placement, camera movement, basic asset loading, and one of the biggest things: the client and server architecture.

But the further I went with the 3D direction, the more I wanted the client to sit on a cleaner native foundation.

The goal was not to rewrite the entire game in C++.

The Java backend is still the authority. The existing services, protocol work, and world server structure are still the same foundation I have spent the last few months working on.

The C++ work is focused on the client.

That means rendering, input, assets, shaders, platform control, and eventually the full game interface.

The important part is that the client can change language without the whole backend having to be rewritten. That is one of the reasons I have been trying to keep the protocol and service boundaries clean.

What the C++ Client Can Already Do

 

The native client is still early, but it is no longer just a blank OpenGL window running smoke tests against the backend, or a standalone rendering test.

It can already go through the early online-game flow: log in, fetch characters, select a character, fetch the world list, connect to a world/game server, receive the server handshake response, and decode world snapshot data.

That matters because it proves the C++ client is not separate from the real game.

It is talking to the existing Java backend. It is using the current service flow. It is receiving server-owned world state rather than inventing everything locally.

That is the difference between a renderer demo and the beginning of an actual game client.

The client is not finished, obviously, but this is a very important milestone. DAIKON is server-backed, so the renderer only matters if players can participate in the real login, character, and world flow.

LibGDX Is Shelved, Not Deleted

This does not mean the old LibGDX client has been thrown away.

For now, it is shelved. That is the best way to describe it.

I am not actively pushing the LibGDX client forward while the C++ client catches up, but the work that happened there was not wasted. A lot of renderer tests, UI ideas, world structure, asset experiments, and data-driven systems came from that stage of DAIKON.

The LibGDX client helped prove the first iteration of DAIKON’s direction.

The C++ client is where I want to take that direction next.

This is also why I want DAIKON’s data to stay as language-neutral as possible. The more the client loads from shared definitions and files, the less everything depends on one specific client implementation.

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

It may matter even more later if DAIKON gains better tools, editors, or alternative clients.

The Game Is Still Tile-Based at Heart

 

Moving to a 3D renderer does not mean DAIKON is becoming a free-form action MMO.

That part is important.

The game is still meant to be readable, structured, and tile-based at its core. Movement, combat, interaction, world state, and progression should still be server-authoritative.

The renderer can be 3D without changing the kind of game DAIKON is trying to be.

I am still interested in the same foundation: click-to-move interaction, clear world objects, obvious paths, readable character positions, and a slower old-school online RPG feel.

The presentation is changing, but the design intent is not.

The goal is not realism.

The goal is a stylised 3D world that keeps the clarity of a tile-based RPG while giving me a more practical way to build characters, equipment, animations, objects, and environments over time.

Models, Animations, and Blender Work

The 3D direction has also pushed me deeper into the asset pipeline.

That has been one of the more useful parts of the experiment, even when it has been frustrating.

I have been testing Blender models, GLB exports, FBX animations, idle animations, player models, and the general process of getting something from Blender into the client and moving in-game.

Some of it works.

Some of it looks terrible.

Sometimes the model imports fine, but the material does not. Sometimes the animation data loads, but the skeleton is awkward. Sometimes the character looks fine in Blender and wrong in the client. Sometimes body parts clip or sit strangely because the model was not prepared cleanly enough.

That sounds negative, but it is exactly the kind of problem I would rather find now.

DAIKON is still early enough that these experiments are useful. They show what the pipeline needs to handle before the game becomes dependent on it.

The long-term goal is not simply to load one player model.

The goal is to support a proper character and equipment pipeline where humanoid characters can eventually share compatible skeletons, reusable animations, modular equipment, and data-driven asset references.

That would make it much easier to expand DAIKON’s character visuals over time without every new animation or equipment piece becoming a huge one-off art job.

Shaders, Water, and Atmosphere

Another reason the native client has become more appealing is shader work.

The C++ OpenGL path gives me a cleaner place to build proper shader support for models, water, weather, and world atmosphere.

I have already been experimenting with water rendering, including the idea of a continuous animated water surface rather than treating water purely as individual tile graphics.

The goal is not realistic simulation.

It is stylised readability.

I want water, rain, lighting, and atmospheric effects to make the world feel more alive without making the game visually noisy or heavy.

That same idea applies to the rain effect. The old version made more sense in the earlier renderer, but the 3D client gives me a chance to rebuild it in a way that feels more grounded in the scene.

DAIKON should still be lightweight, but lightweight does not have to mean flat or lifeless.

It just means the effects need to serve the game instead of overwhelming it.

Where This Leaves the Client

The C++ client is now the active client for DAIKON.

LibGDX helped prove the early shape of the project, but the native client is where I want to continue from here. It already connects to the backend, goes through the account and character flow, loads into the world, receives server-owned state, and handles enough of the renderer work to make the direction feel real rather than theoretical.

The next step is not replacing LibGDX anymore.

It is making the native client feel less like a technical prototype and more like a proper game client.

That means tightening up the systems that are already in place: login, character selection, world selection, map loading, model rendering, animation playback, shaders, camera controls, click-to-move, right-click interaction, chat UI, and the data-driven interface work.

Once those pieces feel consistent and reliable, I can start moving back into the actual RPG loop properly.

That is where DAIKON needs to go next: combat, NPCs, loot, banking, gathering, production, progression, and the basic reasons to log in and keep playing.

In the next part, I will go more into the backend work that makes this possible: the services, worlds, character flow, scripting direction, and how DAIKON is being structured more like an actual online game platform rather than just a renderer experiment.