Make games not engines: why I'll be using Godot engine

One of the reasons I learned how to program was to make games. Games are a unique form of creative medium, combining art, interactive storytelling, and vibrant worlds. But as a software engineer, it’s easy to lose sight of my goals and get trapped by the technical details. It’s common for software engineers in game dev to roll their own engine, which I believe reduces productivity and is ultimately a distraction to making a game.

Note that I’m not just referring to making reusable or generic game engines; for this article, I consider using low-level technology like OpenGL, SFML, or SDL to make games to include the act of rolling your own game engine, even if the focus is specific. It’s more manageable, but you still end up reinventing the wheel and having to solve many of the same problems.

There are plenty of other articles about whether or not to make your own game engine. This article is personal to me; it’s an exploration of my journey in game dev, a discussion of what motivates me, and a promise for the future.

My Journey #

Learning to Program #

One of the first programming languages I learned was Scratch. I created a lot of small games, the most impressive of which was Spirit Walker, an adaption of my favourite book series at the time.

Not long afterwards, I was given a book called “Game Programming for Teens”, which taught me how to make games using the Blitz3D game engine. I created a series of competitive games, mostly with split-screen multiplayer, called Pro Series.

Neither of these tools were perfect: they were pretty limited, and the code I wrote sucked almost as much as the art I made. But those tools allowed seeing results immediately and that is very important for motivation. I was able to create a lot of impressive things (for my age) in a fairly short time.

Rolling My Own Engine #

It wasn’t long before I was running up against the limitations of Scratch and Blitz3D. I briefly tried Unity, but I wasn’t a fan of how it worked.

I googled “programming languages for game dev” and found C++. Perhaps not the best advice for a beginner. From there, I found Irrlicht, a 3d rendering library on top of which you can make your own engines. Whilst Irrlicht is largely obsolete and dead these days, at the time it had a thriving community and wasn’t too outdated. I discovered Minetest on the Irrlicht forums; I’ve been contributing to Minetest since this time, eventually making core developer in 2015.

I made a few simple game prototypes with Irrlicht, including a zombie survival game. I also made NodeBoxEditor, a voxel 3d modelling program for Minetest.

Whilst these projects served as great learning exercises, I wasn’t able to finish many projects as much of the focus was on the tech rather than on the games. One exception during this time was my HTML5 projects, I was able to complete quite a few small projects including Physics Simulation Kit.

The Final Straw: RVWP #

Ruben’s Virtual World Project (RVWP) was a hybrid top-down shooter and base builder, where you manage a group of rebels hiding from a dystopian government. In “base builder” mode, the player would build a base and manage a group of characters similar to RimWorld. Then they would switch to “Hero” mode, and go on missions in a top-down shooter.

RVWP was written using C++ and SFML; I started the project to learn low-level multiplayer networking but transitioned to making a game after a while. I spent five years (on and off) working on it. In the end, I implemented very basic top-down gameplay, a build mode, and some NPC AI. The amount of time I spent on gameplay was massively dwarfed by the amount of time working on the engine; I implemented multiplayer networking, voxel lighting, entities, behaviour trees, and Lua scripting. By the time I got to this point, I had mostly lost interest in the game idea.

Thoughts #

What did I learn? #

When I first started making games, most of my time was spent implementing gameplay. As I became a better programmer, solutions became increasingly more programming-focused, with less time being spent on gameplay.

It all comes down to priorities. Creating my own game engines taught me a lot about programming and game development. I implemented scene graphs, entity systems, sounds, multiplayer networking, physics, tools, and more. I became better at C++ and programming overall. But I’m no longer interested in programming as a learning exercise, I want to actually make games.

Time spent rolling my own tech is time I could be working on gameplay; how good a game is depends a lot on the number of iterations and feedback cycles it goes through. Modern game engines make it much easier to prototype and get a game to a playable state quickly. I’m not planning on starting an indie dev company, but if I were - time is money and using a game engine is a competitive advantage.

I’m not saying that no one should write game engines. Someone needs to, and they are amazing learning experiences. But if you want to make a game, make a game, don’t make an engine as well. And if you seriously want to make a game engine, make sure you have a team and a limited scope (ideally a game in mind).

Why did I write my own engine? #

So why did I ever decide to write my own engines? Part of it is the learning exercise excuse, RVWP was started so I could learn about multiplayer networking at a low level.

Another part is being able to know and own all my code. Before I started using C++ and Irrlicht, I tried making games with Unity. I ran into several bugs in the engine - given that Unity is closed-source, I was frustrated at not being able to fix the bugs or have any visibility into why they were happening. This is not as much of a problem with Godot, as it has zero bugs is open-source.

Another part of it is dogma - I felt like existing engines were impure, buggy, and bloated. As a software engineer, it was much more fun to write my own tech, especially to begin with when the project is new. It was also easy to justify - this is just a learning exercise! The most important thing when making a game is to make the game. Players don’t care if the game is a few extra megabytes - games are regularly in the gigabytes these days! Nowadays, I care more about the outcome than always aiming for ‘perfect’ tech. This quote comes to mind:

Obviously, the above is taken to the extreme. I’m not planning to become a Pastafarian, but I am now willing to take a more pragmatic approach to creating technology. My goal for the future is to focus less on the perfect tech and more on the thing I’m creating. I will use established game engines and not be afraid to write imperfect code.

A New Hope: Godot #

I tried out Godot quite a while ago, but it was still quite immature. Godot is a very capable engine now, especially Godot 4. I’ve started using it for new game projects. I really didn’t like Phaser.JS, so ended up converting my Tin Mining game jam entry from that to Godot as well.

Godot isn’t perfect. When I first used it, I wasn’t a fan of how it used inheritance rather than something more component-based. But this is an example of ‘purity’ again, there are plenty of ways to do composition in Godot and avoid all the issues with OOP-based designs.

Premade game engines can have a bit of a learning curve, but it’s worth it in the long run. Godot’s documentation is very good and there are a lot of third-party tutorials and support available.

Conclusion #

I’m a software engineer. It’s easy to fall into the trap of writing code for the fun of it, rather than to actually make something. But this is a distraction, I like making things and want to actually finish a game.

I’ve been learning Godot and enjoy using it. One day, hopefully soon, I’d like to finish a game and publish it to Steam. I’m not expecting to make the next bestseller, just something that I’m proud of enough to publish even if niche.

Further reading #

• Should I Write a Game Engine or use an Existing One? - this article contains a lot of pros and cons of making your own engine.
• Write Games, Not Engines - the author defines ‘engine’ as strictly reusable code, which is a more narrow definition (but potentially more accurate) than what I use. This is a good article to read if you do want to make engines, though, as it describes the best approach - make your engine with a game in mind.
• Should I Develop a Game or an Engine?
• The truth is that many games are held together by duct tape - Polygon