A year of working on my game engine

I wanted to write my own game engine so this time last year I started doing just that.

Screenshot of game
The engine has come a long way in a year

I had been using Phaser to make JavaScript games for a few years. I then started using Electron because I wanted to make a 'proper' PC game. But then I wanted to release games for consoles as well and Electron didn't support that.

That's when I decided to make the switch to writing my own engine with the help of MonoGame.

Why not Unity I hear you ask? While it is true that there is a lot of support for Unity I felt that writing my own woulbe beneficial for a number of reasons.

Firstly, I wanted to learn stuff. I wanted to learn more about how stuff works under the hood of a game engine. I wanted to learn more about C# and the .net ecosystem.

The other main reason I liked the idea of making my own engine is that I would then own and control it. I wouldn't have to worry about ever changing fee structures or unnecessary API changes or bloat.

So, in April last year I started.

All that that initial 'engine' could do was render animated sprites and handle basic input but it was a start. And, as they say, "A year from now you'll wish you started today."

The structure of the engine has changed drastically over the year.

Just got my Aseprite MonoGame Pipeline Extension working. It's not 100% finished yet but it works for what I need atm. Massive thanks to @NoelFB for the help.

gist.github.com/nathanhoad/bf9dda...

The band

-- Nathan Hoad* (@nathanhoad) July 27, 2018

I read everything I could find and would frequently stumble across other ways of doing things. I learned what did and what didn't work.

In twelve months I rewrote the whole thing twice.

The initial structure was naive and needlessly complicated. There was duplicated responsibilities everywhere.

The first big rewrite was changing how everything fit together to be more like a standard ECS. Previously, there had been logic in a bunch of different places and it was getting hard to reason about the flow of things.

I also rewrote how I was handling sprites and animation which drastically simplified the turnaround time of testing out changes.

Another change came when I moved from macOS to Windows as my main game dev environment. Visual Studio for Mac lacks a lot of the memory profiling that its Windows counterpart has and when I first ran it I quickly discovered a memory leak in some texture handling code.

The last rewrite was taking everything I had learnt and simplifying it.

I did a full audit of the code and refactored what I could and removed anything that wasn't needed. That resulted in halving the amount of code in the engine but it also meant that I could more easily reason about where things were found.

A lot of work has gone into the engine and I am glad I started when I did.

I am one year further than I'd be if I started today.