A 3D game engine, built from scratch.
A Vulkan renderer, a dockable editor, a visual designer for in-game interfaces, a node graph that drives both logic and animation, physics, audio and an asset pipeline. Gameplay is C++, and it reloads while the editor keeps running.
Three choices the rest of the engine follows from
I build Vilanel on my own, for the games I want to make, and that shapes everything in it. These are the three choices the rest of the engine was built around.
Gameplay is C++, and it reloads
Game code is the same language as the engine, so there is one debugger and nothing in between the two to keep in sync. Rebuilding swaps it in with the editor still running. The cost is real: a crash in gameplay takes the editor down with it.
The interface system is built here
Menus, HUDs and inventory screens are laid out in a visual designer inside the editor and saved as files. Owning the widget model and the file format is what lets the designer keep pace with the engine instead of lagging a release behind it.
Depth over breadth
One model format, designed around rather than adapted to. Proven language features rather than experimental ones. Each choice is narrower than it could have been, so that the parts which exist are finished rather than eighty percent done.
Twenty-three milestones, all of them done
The plan was written before the first line of code and ran from a blank window to a working editor. All of it is in the repository. This is what it adds up to.
Renderer
Materials that respond to light the way real surfaces do, lighting picked up from the surroundings rather than from individual lamps, shadows, hundreds of lights at once, and film-style colour handling. Deciding what is visible, how detailed a version to draw and what pose each character is in all happens on the graphics card.
Reloadable gameplay
Rebuild your game code and the editor swaps it in with the level still open and your objects still holding their state. It was the third thing built, because reloading code while it runs constrains how everything after it is written.
Animation
Skeletal animation, characters that blend smoothly between states, movement carried from the animation into the world, and several clips mixed together based on how fast a character is going.
Assets
Source files are converted into a form the engine loads quickly, with textures compressed for the graphics card and models simplified for distance. Edit a texture and everything that used it rebuilds by itself.
Simulation
Objects that fall and collide, a character that walks around them properly, pathfinding worked out from the ground rather than from everything solid, and sound that gets quieter and moves across the speakers as you turn.
Editor and Hub
A window the editor draws itself, play mode with pause and single-step, undo across the whole level, an asset browser, a command search, and a Hub that manages projects and engine versions.
One editor for scripting and animation
Wiring up game logic and building an animation blend tree use the same canvas, the same file format and the same runtime. Only the available nodes differ.
Panning, zooming, the grid, box selection and dragging several nodes at once are the same job in both. Written twice they drift apart, and you end up with two editors that behave differently for no reason anyone chose. Undo, saving and the properties panel came free the same way.
How the graph works
Twelve connection types
Where the work went
Turning characters into shapes on screen, and working out how they sit next to each other in any given language, is decades of specialist work and the existing libraries are excellent. Layout, styling, input handling and file formats are the parts that have to fit the engine, so those are written here.
Measured from the start
Performance measurement was the third piece of work in the project, before there was much to measure. A profiler added later is one nobody has earlier numbers to compare against, so the first slowdown becomes an argument instead of a measurement.
Built to be replaced in two places
Two things the engine does by hand today will become part of the C++ language itself in a few years: working out what fields a type has, and splitting work across processor cores. Both are written behind a boundary now, so switching later is a small change rather than a rewrite.
Written down as it is built
A record of the decisions behind the engine, and why it works the way it does. Mostly the reasoning, because the reasoning is the part worth keeping.
Mixing animations by speed
A character that walks at one speed and runs at another needs something sensible in between. Doing that by hand stops being workable at the fifth clip.
02 Aug 2026Opening more than one file format
glTF is still the format the engine is built around, but it is no longer the only thing it will open.
19 Jul 2026Four tree views that disagreed with each other
The editor had four places showing a tree, and each had been drawn separately. They disagreed on indentation, icon size, text size and where you had to click to expand a row.
Vilanel is a personal project.
It is my engine, built for the games I want to make. There is nothing to download and no plan to distribute it, which is also what lets it stay this opinionated. This site is the record: what got built, and why it was built that way.