Rendering in C++ and Vulkan because I outgrew Unity

18 August 2023

Over the summer I decided it was time to let go of Unity due to a variety of reasons, so I picked up the famous Game Engine Architecture book, the Vulkan specification and got to work.

This is my first venture into writing code in C++, as opposed to C#, which went as good as you might expect. I abandoned this project after a certain point, because the abstractions I built didn’t make that much sense and I didn’t really know how to progress further.

Note from 2026-01-25 #

At the time, I wrote a simple design document for the requirements of what I wanted to build. This document was naturally quite over-ambitious, because I did not yet realize just how much time goes into writing this type of software. It does show my realization that Unity was no longer sufficient for the type of software I wanted to build.

What’s especially funny about my whole venture into writing a game engine is that I didn’t know you could write software without a game-engine like architecture. I never wanted to make a game engine. I always wanted to make a 3D design application. I got confused and thought you’d first have to build the “framework” i.e. game engine yourself, and afterwards could build the application on top of it.

Right now I know that you can build an application, and write supporting – potentially reusable – libraries that might have overlap with the libraries present in a game engine, but deviate quite quickly when going higher in abstraction. Building a generic ECS for example doesn’t make any sense for a design application. The lower level libraries such as a platform wrapper, renderer, graphics API wrapper and UI can be the same. Certain acceleration data structures such as VDBs, BVHs can also be similar.

Design document #

Sphere is an experimental 3D game engine for creating and authoring AR / VR experiences.

Its main innovation goal is in enabling full live editing on the target device (probably at reduced visual quality).

Iterative approach #

Building a game engine is hard, so we employ the software development model of:

Design goals #

Business model #

Because a game engine itself doesn’t initially make for a sustainable income stream we employ the following business model:

This model allows for true dogfooding, which is desirable in determining which features are important and essential.

Why build a custom game engine #

  1. For fun and educational purposes.
  2. Performance. The ability to fully control every single line of code that is being run. On performance constrained devices such as the Quest, you can only go so far with an existing game engine. There’s always overhead. Now the only limiting factor for something not running smoothly is you.
  3. Stability. More stable and well-documented APIs. The lower you go in the technology stack, the more things become an engineering discipline, which should result in better APIs and less breaking changes.
  4. Screw Unity [1]

Structure #

Follows the Pitchfork specification

[1]: I have grown incredibly discontent with Unity and all of its stupid engineering decisions;