Building a custom game engine

Most game developers will undoubtedly advise against building a custom game engine. With so many existing versatile game engines available, both free and paid, that’s not surprising. Why would you spend months or even longer working on a custom engine while you can also immediately start making your first prototypes? Sure, it’s nice and satisfying to be in control of it all and it’s a great way to learn as well if you’re interested in software development. However, is it a waste of precious time to reinvent the wheel that you could otherwise have used to create your game? That’s a valid question but the answer is not so straightforward.

Why would you even consider a custom game engine?

I eventually decided to develop a custom engine to create 2D games. But why? I did so after trying two existing game engines first.

Unity

I first explored Unity to find out if that was a better option. The workflow within Unity certainly is very nice. Moreover, I can program in my preferred language: C#. But with so many additional options and settings, I found the learning curve to be quite steep. Don’t get me wrong, with some basic knowledge you can have a working prototype within a day. I completed several video tutorials and had something that looked like a game in no time. Creating a polished game that is production-ready, however, is a different story. Loads of switches that you can use to tweak your game are great if you wish to create a complex 3D game. However, I often felt like they were overkill for the purpose of my games. When one day, for whatever reason, I suddenly couldn’t open scripts from within Unity anymore, it meant that Unity and I had to part our ways anyway.

Godot

I then tried Godot, which seemed perfect for developing my 2D games. It supports C# as well and the learning curve is not that steep. But I quickly ran into an obstacle: z-ordering. Although my games have an orthographic projection, they do have a simulated z-axis, which means that objects can be positioned on top of and under other objects. That requires dynamic z-ordering when the objects are drawn. I spent a lot of time trying to get that to work in Godot. I even tried to fully override the draw method and implement the z-ordering by myself, but apparently that’s not allowed. Perhaps the problem lies with me and I should have figured out more about the engine, but I feared that many other custom gameplay elements would pop up and cause trouble. So, I also had to let go of Godot.

Choose what suits you best

In short, a game engine should suit the game developer. The interface, the learning curve, the supported programming languages and the ease with which you can implement your custom gameplay elements quickly and hasslefree. Obviously, that’s different for every developer and that’s why everyone has a preferred engine, whether it is an existing engine or custom-built.

If I now try to answer the question from the introduction, I would say that building a custom game engine is not necessarily a waste of precious time. You can choose to spend a lot of time to learn the ins and outs of an engine with a steep learning curve, and risk facing edge cases that require more time to implement in a particular engine. Or you can choose to invest your time building a custom game engine, knowing the ins and outs of it while avoiding a learning curve, and being able to implement all current and future ideas without much trouble. In the end, you choose the option that makes you feel comfortable and, most importantly, productive.

A custom game engine on top of a framework

One of the requirements for my games is that they must be cross-platform. Although I’m an experienced software developer, low-level programming with APIs for graphics, audio, etc. for different platforms is not my area of expertise. That’s why I decided to use Monogame (formerly known as XNA). It’s a C# cross-platform framework for game development. Developing for desktop (Windows, Mac, Linux), mobile (Android, iOS) and even consoles is possible. The framework itself also seems to have various built-in engine components. You’re free to use those or develop your game from scratch. I chose the latter and took it one step further by developing a reusable engine. In my case, Monogame is solely responsible for low-level platform abstraction and running the main loop. Everything else is handled by my custom game engine, which all of my future games can use.

Minimum requirements for the custom game engine

First of all, the engine should at least handle main tasks such as:

• Input management
• Scene management
• Object management
• Physics
• Collision detection and response
• Rendering management

These terms are, of course, quite broad and need to be worked out in detail. For example, an object manager is responsible for creating and deleting objects, but can also be responsible for the spatial partitioning of the objects. Furthermore, having an event manager of some kind is not required, but a game engine without one is unimaginable in my opinion. As said earlier, the games will simulate the z-axis, which means physics, as well as collision detection and response, need to act in three dimensions. Finally, the rendering manager is responsible for displaying the objects in the correct order. These are the bare minimum requirements for the custom game engine. I will discuss each of those in more detail at a later stage, so check back in soon.

Photo by Hello Lightbulb