Tommi's Scribbles
Let's Make a Game Engine, part 1
- Published on 2021-12-25
Some time ago, I decided to write my own game engine. With great options, such as Amazon Lumberyard, popular options, such as Unity3D, Godot, and Unreal Engine, and a plethora of less popular engines available, you probably wonder: "Why on Earth would you do that?"
My reasoning was rather simple. As a programming hobbyist, the pace at which external game engines move and implement features (and bugs, though these days I think they are also called features) defeats the benefits of not coding everything myself.
Three Reasons Why I Chose To Make My Own Engine
Before starting the development of my own engine, I had been using Unity3D on and off since version 3.X. I also had tinkered around with Unreal Engine since UDK, with Northlight from my time at Remedy Entertainment, fighting with SCONS to get Godot to cooperate with JetBrains CLion, and also from creating my own "engine" back when Android was in version 2 to self-publish a game on Google Play Store.
Apart from using Northlight at Remedy, guess which option was my favorite.
Reason 1: No Bloat
"The engine" I made my game with for Android 2 can hardly be called an engine. It was a simple basic Java implementation of an OpenGL renderer and the basic game systems to make a simple arcade accelerometer game. Every line of code was fully used by the game, and the APK size was around one megabyte.
However, I later ported the game over to Unity 3.3. No assets were changed, gameplay logic code was just ported from Java to C#, and that was it. Yet, the APK size grew almost 800 percent, to over 8 megabytes. For a simple arcade game before cheap, fast, readily-available mobile internet, that was a killer.
With the growing feature sets of the popular game engines, you get a ton of versatility. But for small projects, the benefit of only rolling with features you might need vs. wrangling a massive feature set actually makes more sense.
To me at least.
Reason 2: Full Control
Since I am not programming full-time, my projects obviously move at a way lower pace than the engines get new versions. Now, you could argue that I could still rock Unity 5 and be happy. However, I beg to differ.
First, the main attraction for me with Unity3D was the Asset Store. More specifically, the art assets of the Asset Store. However, due to all the included fluff in the packages, something as simple as a model, and a texture and a material for the model, might have a minimum version requirement of 2019.2. And you're working on 2017.4 LTS.
This meant I couldn't necessarily get the assets I wanted. So there goes that advantage.
In addition, the way Unity3D development went seemed like you get a new version, with new features - and with bugs. Usually bugs you can't fix yourself without full access to source.
Then, there's eventually some new version, which finally fixes the bug affecting you. But oh wait, the new version introduced a different bug. This, combined to the reimport of all assets between versions, made me sometimes feel that, off the sparse times I program, instead of developing I just waited for a progress bar to, well, progress.
Reason 3: Apple Support
As everyone knows, Apple is not exactly considered the top gaming platform apart from the mobile free-to-play toys flooding the iOS AppStore. However, my home is filled with Apple devices, so to make something for my nephew to play on his visits, targeting Apple is a natural choice.
But for some reason, it often feels that Apple support outside of iOS seems often an afterthought - something that is slapped on to be able to call the engine multiplatform. Some engines don't even support development on a Mac.
A custom native solution thus makes perfect sense. Thus, after this rant, I give you:
The Engine
Like so many other game engine projects that have gloriously started only to vanish in flames to oblivion, I present to you the humble beginning: a grid of boxes rendered with a simple Metal shader with a front-back-left-right movable camera.
Insights So Far
So far into the project, I have to say that my first foray to Swift-land has been a glorious one; I love writing code in Swift!
Sure, there were growing pains to figure out how things work the Apple way. However, there are quite a few good free online resources to get you started, though I highly suggest mixing and matching sources as I think there wasn't a single "perfect" example.
What I yet don't know is how performant the Swift code will be down the line. Coming from a 1997 C++/Assembler background, it will be interesting how many things will come bite me in my posterior later on. Since I am currently working on adding 3D physics, I reckon I will find out sooner than later.
P.S: When ditching Unity, I uploaded all the source code I could on my GitHub. The gameplay code should be okay enough quality to maybe be off use, so take a look around if you're a Unity developer. DISCLAIMER: Code was last compiled on I think 2018.4 LTS, so YMMV.
P.P.S If you wonder why my GitHub is so empty, I actually use AWS CodeCommit for my private stuff. I will likely do some CD/CI write-up of the great AWS code tools later.