I’m Building a Game Engine - Part 1

My wife and I have been toying with the idea of working together to make our own video game. She has a lot of art skills, and I have the software background to handle the technical stuff. While making video games is certainly not foreign to me, over the years I’ve tried many engines and never really felt like I clicked with any of them. Let me explain.

Background

Between high school and college when I was trying to figure out what exactly I wanted to do (even though I was quite certain I would major in Computer Science), I learned Unity and made some fun little projects. Unfortunately I think that all of these projects are lost as I wasn’t using Github at the time and I wasn’t documenting any of my progress (this lack of documenting is a continuing theme for me and one of the purposes of this blog). During college I tinkered with game development here and there and took electives in game-adjacent courses like computer graphics and artificial intelligence, but I didn’t put too much extra time into it. After college I finally got back into making games when I discovered Godot.

Godot

Godot is great. It’s open source, the documentation is fantastic, it has a huge community that’s grown around it, and it doesn’t suffer from the license and usage restrictions that closed source engines like Unity and Unreal suffer from. However, I never really got it to vibe with me. I think this is partly due to the restrictions that it necessarily places on the developer.

The major issue I have with Godot is GDScript. Don’t get me wrong, I think there is a time and a place for using dynamically typed languages, but I don’t think game development is really one of those times. For larger projects that go beyond a simple script to automate a small task, I always reach for C# which leads me to my second problem.

Godot supports C#, but you can’t export for web unless you’re using Godot 3.x (currently the latest is 4.x). This was a huge bummer for me because exporting for web is a fantastic way to quickly get a build out for play testing and you can host it on Itch.

There’s a number of other things that I just couldn’t stand with Godot, but those are the major issues that made me want to find something else.

My own engine

Noel Berry, co-creator and programmer on Celeste, posted a blog entry last year discussing his method of making video games without an engine. I got a lot of inspiration from reading it and his stack is oriented around using C# as the primary programming language. I felt like he outlined a path forward specifically for me and my preferences.

I began putting together my own engine by following some of his guidance. I wrote some wrappers around SDL3 functionality, integrated ImGui for debugging UI, and did some extra little side-quests (more on that in future updates). Importantly, I did all this while taking inspiration from other engines and while making small game projects. It’s really easy to get caught up in writing the engine, without writing any fun games at the same time. I think in order to structure something you know is going to work well for you when you finally use it for your game, you need to start on that game while working on the engine.

Where it’s at right now

While I don’t want to get into the nitty gritty technical details of the engine as it currently stands (this stuff will come out in the future), I do want to give a brief overview of where it’s at. To be honest, it’s in its infancy still. Functionality is quite limited, but it is capable of doing some simple, single screen 2D games. My goal is not to create something that is capable of handling super high-performance scenarios or complex 3D scenes, my goal is simple 2D games that my wife and I can make together.

Right now I basically have a scene-tree architecture set up much like how Godot handles scenes. You can create scenes and instantiate entities within the scene. You can load textures. There’s some basic mouse input handling, you can write some basic procedural animations. Lastly, there’s an audio project that includes a way of doing some simple procedural audio generation via basic additive and subtractive synthesis.

It’s not much, but already I can create some fun things with it. The first game I created was a match-three style game. I built it for web and I’m hosting it over here. I found that it can behave a little weirdly on some browsers and I think that the web functionality of the engine needs some work, but the point is that I can do it. Unfortunately it doesn’t have audio, but I did include some procedurally generated sound-effects that play when tiles stop falling, but that only works on desktop builds which I’m not distributing at this time.

Wrapping up

While typical advice for aspiring game developers is to build a game, not an engine, I’m currently finding that building an engine is forcing me to get creative and build some games. It’s forcing me to make them small and frequent as I iterate on features of the engine. They will get more and more complex and I believe my game development skills will grow with my engine development skills. Having limited engine functionality definitely helps with maintaining achievable scopes for the small games I’m creating.

So I hope I’ve piqued some interest and that you will return for future updates. I’m still working out some details with the blog and I haven’t been able to put in any extra features like RSS feeds and better post organization so I will just have to ask you to check back in a while to see my updates.