Why I’m building my own game engine

Why I haven’t chosen Unity or Unreal

I could have started with Unity or Unreal Engine. They are powerful tools and make sense for many projects. My main reason for building my own engine is complete control over my technology: being able to understand and change even the smallest detail of the engine, the tools and how they connect.

That freedom lets me adapt the technology to what each game needs. If a city requires a different kind of plot, clothing needs to fit a body or animation calls for a new control, I want to change the component that handles it and decide how it works with the others.

That control is the biggest advantage, and it also means an enormous amount of work. Every system needs building, testing and maintaining, even when a commercial engine already provides it. It is a long-term investment: taking on that work to build a foundation of my own that I can specialise, connect and reuse across different games.

Underneath: C++, Vulkan and Jolt

The core is written in native C++. It lets me decide how data is organised, how scenes load and where each frame spends its time. Much of this work is not especially visible, but it matters when everything has to run together.

I started building the graphics side on OpenGL. That was the wrong choice for the kind of engine I wanted to develop. As I added virtualized geometry and loading data in pages, I needed more control over how GPU work is organised, what occupies memory and when each resource is ready. That is why I decided to move to Vulkan.

I’m now moving that foundation to Vulkan 1.4. The backend already exists and integration is ongoing. Systems need migrating, their rendering needs checking and improvements need measuring. It is a decision I would have made earlier if I were starting again, and one of the lessons of building the engine as I go.

For physics I use Jolt, with custom work in the integration. For example, I have adapted the motorcycle controller to calculate lean from speed and steering, and adjust how the bike regains its balance. Jolt still handles contacts and collisions; the additional control lets me work toward the riding behaviour I want.

I’m also connecting physics with animation. In a fall, for example, the physical body starts from the animated character’s pose and Jolt continues the motion, with masses and joint limits tuned for the character. The handover between animation and physics has plenty of details worth showing. I may explore it in another article, with more examples.

Virtualized geometry: what changed in performance

Virtualized geometry is particularly interesting for large scenes. In simple terms, it breaks models into small groups and selects the detail a camera needs. Finer data can arrive in pages while a simpler representation remains available.

This is a custom, narrower implementation of ideas popularised by Nanite. It already includes detail selection, GPU visibility work and geometry and texture streaming. I wanted to see what it contributed inside a project scene, beyond simply rendering correctly.

In a saved comparison of the baseline against a candidate with virtualized geometry and its streaming, the frame-time summary fell from 29.0 to 17.1 milliseconds. GPU work fell from 22.7 to 12.1 ms. Those are reductions of roughly 41% and 47% on that route. That is an encouraging result.

Connected tools, with AI as a bridge

Around the engine I’m building specialised tools: some design terrain and cities; others create buildings, vegetation, clothing or animation. Human Master handles characters’ bodies and faces. Each solves part of the work, but what interests me is how they can share results and build the same world together.

For example, imagine I want a neighbourhood with narrow streets and houses on a hillside. The planning tool lays out streets, divides the land into plots and records the terrain height. The architecture tool receives that information and builds the houses, fitting their size and foundations to each plot. The engine brings the pieces together so the neighbourhood can be explored. That is the workflow I’m aiming for.

I connect them through structured data contracts: agreements about what information each tool delivers, what the next one receives and which rules both must follow. In that neighbourhood, the data might specify a street’s width, a plot’s boundary, the permitted number of storeys or the terrain slope. These are concrete parameters, with units and limits, that can be read, changed and checked.

This is where AI becomes a bridge between an idea and the tools. A developer can adjust those parameters directly; AI can interpret a request and propose changes to the same data. The tools check that their rules are respected, and the result can be reviewed in the engine.

Studio is the name I use for the set of creation tools that accompanies the engine. It keeps the editable files and the instructions for generating each component. The engine receives a specific version to use in the game. That lets me keep improving a house or character without losing the version that was working, and reuse that work in other projects.

Some connections already work; others are still being built. I want improvements to each tool to carry through to the others, using data that both a person and AI can understand and adjust.

The next step is making good games with it

Once the engine’s foundations are in place, I want to bring one or more games to life using these tools. What I learn from creating cities, characters and animation can become the basis for experiences with an identity of their own.

My goal is to create living worlds where sandbox freedom, action, decisions and role-playing define the experience. Places to explore, improvise, take risks and find different ways to approach a situation. Where the player’s choices and the world’s response open up new possibilities and give rise to unique stories in each playthrough.

I’ll share that journey in this diary, from engine experiments to the first playable experiences.