State of the engine

And drawing lines in the sand

I have been working on the same side project for three years now (although bits and pieces date back later than that) and I feel like it’s a good time to reflect on how far I have come and what the next steps are.

Here’s some rough metrics 1 for the current codebase:

Full disclosure: I am coding my game engine from scratch using SDL2 and C++ as the foundation. I opted not to use a commercially available engine like Unity or Unreal for my game. 4

This could still be a more time consuming approach but honestly I find it more productive. However, the age old question of “are you making a game or an engine?” still comes to mind. As a programmer first, it’s easy to get wrapped up in coding neat little technical details and systems. I am definitely guilty of this.

Now though, I need to realistically focus on the game itself.


I think while I have a lot of the systems in place or at least rough versions of them, a pragmatic line in the sand would be the difference between production ready technical aspects and actual gameplay. Production ready things would include handling integrated versus dedicated GPUs, UTF-8 support, a full featured settings screen, remapping controls, high DPI support, achievements and testing different CPU architectures.

My core focus now will be to get something playable and fun. Then I think I will extend that prototype to the first vertical slice and polishing that as much as possible. This is an exercise that the developers of Hollow Knight, Team Cherry did. It helps set the standard for what the rest of the game should look like plus it also makes a good cut-off point for a demo (which I think is becoming more and more important with Steam Next Fest being a key marketing opportunity for indies).

After that I will begin roughing out the rest of the world and making the story playable from beginning to end. Then probably some rounds of polish, playtesting and finally all those production ready criteria mentioned above (as well as any optimizations that are needed).


As of today this is quick overview of some of the main systems in my engine:

So not a bad base overall, it could be better, there’s lots of gaps as my spare time has been dedicated to this very sporadically. Work and life gets in the way and sometimes my attention shifts around. But I think it’s enough to whip up a prototype so that’s my turning point from initial engine to more actual gameplay. On rainy days when I need a break from my current task list I might pick something engine related to improve or maybe work on some dev tools (like an in-game console, hot reloading or a debug view). They might speed up development in some situations and be worth the additional effort.


So why write this post? It’s mostly for myself. I’m taking a snapshot at this point in the development of this game to come back to years later for perspective. I’m sure that I’ll change my mind on some of these thoughts over time but let’s see.

I am really curious to see by the end of this project, years from now, what the metrics will look like. I find posts like this one great for providing some similar stats.

To put things into perspective: Dyad has 193k lines of code, all C++. Doom 3 has 601k, Quake III has 229k and Quake II has 136k. That puts Dyad somewhere in between Quake II and Quake III. These are large projects.

Dwarf Fortress is supposedly 700K LOC. 5

These are by no means an objective level of quality or perfection but they are fun to indulge in from time to time.


In the next post, I want to continue this chain of thought and talk about actually building out a game idea.


  1. Metrics were generated with sloc && wc -l *.json 

  2. This also excludes all open source dependencies 

  3. The game is fairly data driven although a good chunk of this is a massive map file that features a 2D grid (that’ll get optimized over time) 

  4. Many jobs ago I worked with Unity and had to deal with a few major version upgrades that had breaking changes. Writing my own engine may require more time up front but it’s a trade-off so I do not have to invest time continuously whenever new engine updates arrive. Nevermind the ripple effect it has on plugins that you might use that don’t get updated as fast too. I also opted not to use Unreal Engine because I am not thrilled with their revenue share model. After Steam’s 30% cut, your business taxes and your own personal taxes, adding another fee on top of all that was not particularly appealing. 

  5. Although Tarn Adams did the metric by searching for ; characters and not using a tool like sloc. However, he coded Dwarf Fortress, we know it’s a large codebase. What’s an extra 10K lines of code here and there?