People ask fairly often what it is actually like to build something this size in Godot, usually with a slight edge of “…are you sure?”. So this one is about the engine.
Luminids is a voxel colony sim with a first-person mode, a simulated creature population, weather, and a save system that has to keep all of it consistent. That is not the kind of project Godot gets recommended for. Here is how it has gone.
Why Godot, honestly
Not ideology. Three practical reasons.
I can read the whole engine. When something behaves strangely at the boundary between my code and the engine’s, I can go and look. On a closed engine that boundary is where debugging stops and guessing starts. I have used that ability maybe a dozen times, and each one saved a day.
Iteration speed. The edit-run loop is fast enough that I test ideas instead of arguing myself out of them. For a solo developer that compounds more than any individual feature.
Nothing is negotiating with me about my own game. No seat costs, no revenue thresholds, no licence conversation waiting at the end of the project.
The honest cost is that fewer people have solved your specific problem before you. There is no Stack Overflow answer for “voxel colony sim, quarter-metre foliage overlay, two hundred agents”. You read source and you work it out.
What is actually running
A lot of Luminids now exists in playable form rather than as a plan.
The world. Seeded voxel generation with biome-driven environments, water, a day and night cycle, and weather. The terrain is not raw noise: it runs through a layered process I wrote up separately in Dev Log 6, because “procedural” on its own reliably produces landscape that looks correct and feels like nowhere.
The creatures. Luminids run a shared behaviour model, and there is a wildlife layer alongside them so the world is not populated exclusively by the things you are managing.
The player. First-person controller, building and placement, crafting and progression, a quest and story structure, and save/load that keeps world continuity across sessions.
That last one deserves more credit than it gets. A colony sim save is not a snapshot of a scene: it is voxel edits, placed structures, every creature’s internal state, world time, weather, and quest progress, all of which have to come back consistent with each other. Getting that boring is a milestone.
What Godot made easy
Composition. Building behaviour out of small nodes that each do one thing suits a simulation game unusually well. A creature is not one enormous class; it is a set of parts that can be swapped, disabled, and tested on their own.
Shaders. The shader workflow is pleasant enough that I actually experiment rather than settling for the first thing that compiles. Most of the atmosphere work in Luminids exists because trying a variation is cheap.
Tooling in-engine. Being able to write editor tools in the same language as the game means the debugging instruments live next to the thing they measure, and they get written instead of being permanently on the wish list.
What has been hard
This is the part I would have wanted to read before starting.
Voxels are your problem, not the engine’s. Godot does not hand you a voxel world. Chunking, meshing, level of detail, streaming, and rebuild scheduling are all yours to design, and they are most of the performance story. Running two terrain layers at different resolutions (one-metre for the ground, quarter-metre for the foliage overlay described in Dev Log 3) was worth it, but nothing about it was free.
Node lookups will quietly destroy you. The scene tree is easy to search, which means it is easy to search from somewhere that runs every frame for every agent. This has cost me real time more than once.
Scale reveals itself late. Everything is fine at twenty creatures. The interesting failures start in the low hundreds, and you cannot find them without leaving a real colony running for a long time and reading the logs afterwards.
The creatures, briefly
Each Luminid runs the same core behaviour model, built around three axes: Work Drive, Boldness, and Sociability. Those values shift over time through repeated actions, environment, and social context.
The goal is behaviour that reads as consistent rather than random. When a Luminid changes how it acts, it should feel like something happened to it, not like a die was rolled. There is a much fuller breakdown in Dev Log 8.
Would I recommend it?
For this project, yes, with one caveat: pick Godot because you want to own the whole stack, not because you expect it to have already solved your problem. For a voxel simulation game, it mostly has not. What it gives you instead is a fast loop, readable source, and nothing standing between you and the thing you are trying to make.
There is still a long way to go. But the core world, creature, building, progression and atmosphere systems all exist and run together now, which is the point where a project stops being a set of demos and starts being a game.
Nick
