I’ve been a fan of Casey Muratori's work for a long time. I watched ~150 out of 700 videos of him writing a game engine and had a thought “oh, I can do that!” like many other people. Accidentally, I stumbled upon an open sourced raddbg project after Epic Games bought the RAD Game Tools company. The project is awesome, but “reusability” is hardly in it’s principles. Surely you can fork it (I did that!), but it takes a while to figure out undocumented conventions of the codebase and throw away everything debugger related. So I asked myself: why not make a standalone collection of libraries which anybody can use without spending time on a fork? Another thing I tried to engineer into the project is approachability.

To explain what this means, let’s discuss a very common problem in programming: serialization. Casey’s approach is “write the serialization code yourself”. I don’t have 30+ years of experience writing C for a living, and I hate debugging serialization bugs with passion. So I asked myself “what would an 80% approach to serialization look like?” and tried my best to engineer it.

Complete set of values I picked from here to have a clear understanding of what the fork should be is:

  • Iteration speed (Velocity)
  • Approachability
  • Simplicity
  • Debuggability
  • Performance

In practice, this means “taking raddbg ideas and dressing them to make them approachable by the general population of developers”, or to put even more obvious: documenting the code & decisions, writing tests, making “guardrails” with compiler & linters, etc.

There’s little value in creating those libraries if I’m not going to use them myself. So naturally, I figured I’m going to make a game. After a year spent reading about rendering techniques and figuring out how animations work, I realized that although I like some parts of everything that constitutes game development, I like very specific parts. The indie game dev market is brutal and I’m not motivated enough to spend years of my life working on a single project. Game design is a unique activity in many ways and I would’ve spent even more years trying and failing enough times to create something decent.

Games I like playing myself are usually this very specific kind of incredible world building and visual spectacle — think Cyberpunk 2077 or Expedition 33 — and not something created by small motivated teams. So I realized that instead of making a game, the thing I actually want to do is to tell a story using computer graphics as a medium.

Another thing I’ve learned recently on my day job out of all places is “publish early and publish fast”. Since it’s hard to keep myself motivated working on a side project most of my free time, I figured that instead of making it a multi-year project with questionable milestones, I’m going to publish every 3-6 months something that gets me closer to the final goal of the project. My current plan has 6 such “3-6 month” steps, and the first two are:

  1. Native LLM UI app.
  2. Graphics demo using the engine’s capabilities.

The first one might seem a bit strange, but hear me out. Releasing software is known as a pretty hard thing to do in the industry. So obviously I decided to try to release something simple first. I’m naturally curious and I love asking LLMs the weirdest of questions and delegating the boring parts of the work, but existing companies try very hard to lock people into their “platforms”, so I figured that snappy native UI might be useful to some people. I decided to make it closed source for various reasons, including: I like getting paid for my work, and even if I sell 20 copies throughout the project’s lifetime, figuring out everything required to get those 400$ is an achievement on its own. And I get a better tool for myself in the end! Sounds like a win-win for me.