DAIKON Dev Blog: Experimenting With a 3D Renderer
DAIKON started life with a 2D renderer, and for a while that made the most sense.
The original direction was tile-based, readable, and heavily inspired by the kind of game interaction model I already understood well: click-to-move, clear world objects, simple positional logic, and a game world built around tiles rather than free-form movement.
That part has not really changed.
What has changed is that I have started experimenting with a 3D renderer for DAIKON.
This is not meant to be a big announcement or a final decision about the whole project. It is more of a look at what I have been working on recently, why I started testing it, and why the idea has become interesting enough to explore properly.
Why I Started Looking at 3D
The biggest reason is production reality.
I am not especially artistically inclined. Most of the sprites and assets shown in earlier development screenshots were either free assets, paid assets, or temporary placeholders. They were useful because they let me build and test systems without waiting on final artwork, but they were never meant to represent DAIKON’s final visual identity.
The original plan was always to replace those assets later with proper work from our own in-house artist.
That may still happen, but the more I worked with the 2D renderer, the more obvious the art requirement became. If DAIKON stayed fully 2D, I do not think 32x32 sprites would be enough for the level of character and equipment detail I wanted. The renderer would probably need to move closer to 96x96 sprites, with paper dolls and more detailed character layers.
That sounds good visually, but it also increases the workload very quickly.
More sprite detail means more animation frames, more equipment variations, more character parts, more NPC work, and more duplicated effort every time something changes.
That is where 3D started to become interesting to me.
Not because 3D is easier in every way, because it definitely is not, but because it gives me a different way to prototype. Instead of drawing every frame of every animation, I can create a rough model in Blender, rig it with bones, animate it, export it, and test it directly inside the client.
I have already been learning that process: creating player models, working with armatures, testing GLB exports, testing FBX animations, and trying to work towards a modular character setup where equipment, body parts, and animation data can eventually share the same humanoid structure.
For someone who is more comfortable building systems than producing finished art, that matters.
And who knows, maybe one day we will have the funds or resources to make the 2D renderer useful for something else, like a mobile-specific version running on the same servers. That is not the plan right now, but I like the idea that the work does not have to be wasted.
What I Have Been Testing
The current 3D renderer is still experimental.
Right now, the focus has been on getting the basics working and seeing how it feels inside the DAIKON client. That means loading models, testing animations, checking how characters sit in the world, and seeing whether a tile-based game can still feel readable when the presentation is 3D.
So far, I have been testing things like:
- loading 3D character models into the client;
- importing GLB models;
- testing FBX animation files;
- playing idle, walking, attack, and death animations;
- keeping characters tied to the existing tile/world structure;
- experimenting with modular character ideas;
- checking how readable low-poly models feel in-game.
One of the more important parts has been the animation workflow.
The idea I am interested in is having humanoid characters use a shared or compatible skeleton. That way, players, humanoid NPCs, and equipment-based characters could eventually share animation logic instead of every model needing a completely separate animation setup.
That would be useful for DAIKON because I want equipment and character visuals to be expandable without every new piece becoming a massive art job.
Learning the Blender Side
A lot of this has also been me learning Blender properly.
That has been a mix of progress and frustration.
Some things work. Some things look completely scuffed. Sometimes a model exports fine, but the materials do not appear correctly in-game. Sometimes the animation works, but the rig is not quite right. Sometimes arms, hands, clothing, or body parts clip in ways that make it obvious the model was not prepared properly.
I have already run into issues with GLB imports, FBX animations, missing materials, awkward armatures, bad deformation, and character parts not sitting together properly.
That sounds negative, but it has actually been useful.
These are the kinds of problems I would rather run into now, while the renderer is still experimental, instead of much later after building more of the project around assumptions that might not hold up.
The useful part is that I can now make something rough, get it into the client, animate it, and see it moving in the actual game environment. Even when it looks bad, it teaches me something.
Where 2D Still Fits
I still like the 2D direction.
A 2D version of DAIKON could look clean, readable, and distinct with the right art direction. It also fits naturally with a tile-based game.
The issue is not that I dislike 2D. The issue is that I am trying to be realistic about what I can prototype and maintain at this stage.
The 2D renderer made sense when the game was mostly testing movement, maps, UI, and early interaction. But once I started thinking more seriously about equipment, character identity, animation quality, NPC variation, and long-term content, the art pipeline started to feel like a much bigger wall.
3D has its own wall, but it is a different one.
With 3D, I can reuse rigs, reuse animations, make rough placeholders myself, and improve models over time. It gives me a way to keep moving while I am still figuring out the project’s final visual direction.
That is the main reason I am testing it.
The Style I Am Interested In
If the 3D renderer continues, I do not want DAIKON to aim for realism.
The style I am interested in is more stylised, readable, and low-poly. I still want the world to be clear at a glance. Characters, objects, paths, buildings, and interactable areas need to be easy to understand.
The game should still feel structured. It should still feel like DAIKON. The renderer should support the gameplay rather than turning the project into something completely different.
That is why I am not treating this as “make everything 3D and see what happens.”
I am more interested in whether a 3D renderer can keep the same tile-based foundation, but give me a better way to build characters, equipment, animation, and world objects.
Where Things Stand
Right now, the 3D renderer is still a prototype.
The 2D renderer is not being thrown away, and I am not treating the 3D renderer as final. This is just the stage where I need to test enough of it to understand whether it is actually worth continuing.
The current work has already helped me understand more about:
- how models need to be prepared
- how animations should be exported
- how awkward materials can be between Blender and the client
- how important a clean skeleton is
- how modular characters might work
- how much of the existing tile-based structure can still carry over.
That has made the experiment worthwhile already, even if the final direction is not locked in yet.
Closing Thoughts
DAIKON is still early enough that this is the right time to test something like this.
The 3D renderer is rough, but it has been useful. It has given me a better understanding of the asset pipeline, character models, animation workflow, and what a different version of DAIKON could feel like.
For now, I am going to keep building enough of the 3D renderer to see whether it can properly support the game.
If it works, DAIKON may end up with a tile-based, stylised 3D presentation that keeps the structure and readability I wanted from the original 2D version, while giving me a more practical way to prototype characters, equipment, animation, and long-term content.
That is where the experiment is at.
Some videos
Posted on May 28, 2026 by RadRadish