(this article is reposted from my Medium blog)
So you’re thinking about making your own game engine. Great! There’s lots of reasons to want to make one yourself instead of using a commercial one like Unity or Unreal. In this post I will go over why you might want to, what systems are needed in a game engine, and how you should approach development of it. I won’t be going into any deep technical details here, this is about why and how to develop a game engine, not a tutorial for how to write the code.
Why?
Lets start with the absolute first question you should be asking yourself if you want to make your own game engine: Why?
Here’s a few good reasons why you might want to:
Novel Tech: You want to make a game that uses a piece of novel tech that no other engines out there currently support, or can’t be easily made to support in their current state. This can mean some kind of massive-scale simulation that requires some to-the-metal coding to make performant (Factorio) or some custom thing that doesn’t fit into any existing molds (Noita, Miegakure), or wishing to target an odd piece of hardware that current engines don’t support (Playdate), or any number of other things really. It’s a good reason to make your own engine, cause there isn’t any other option in cases like this.
Specialization: You want to optimize your workflow for the kind of games you make. You don’t need all the features included in a commercial game engine, and you can make your asset pipeline / level editor / whatever way smoother to use when considering your specific use cases instead of needing it to be general purpose. Specialization is almost a requirement of making your own engine, if you aren’t specializing it and catering it towards your exact use case, you should rethink why you’re making an engine in the first place.
Independence: You don’t want to be dependent on someone else’s technology in the long term. The incentives and values of a company like Unity or Epic are not always going to align with your own, and you want control over your own tech, the ability to fix bugs yourself instead of “waiting and hoping”, and comfort knowing that an update won’t completely break your current project. You are willing to eat the cost of developing your own tech, because in the long run its good to not have to constantly change stuff depending on the whims of giant companies.
Curiosity/Learning: You’re just curious about how it works and why other engines have made certain decisions they did. This is a great reason, one of the best reasons actually, to make your own game engine.
Also while I’m making lists, here’s a couple of bad reasons for why you would want to make your own game engine. If any of these are your (only) motivation, you should back up and reconsider:
I can do it better: You think you can just make something better than Unity or Unreal (or Godot or GameMaker) in general. You can’t. It’s possible to make something that is better than these for specific use cases (see: Specialization above), but you, as an individual or a tiny team, are not going to compete with these for general purpose stuff. Especially if you have never made your own game engine before.
It’s the what real programmers do: There is no “right way” to make a game, you don’t win programmer points for making your own engine. If your game is a good fit for an existing engine (and I’d argue like, 99% of games are), there’s no shame in using one. After all, a game engine is simply a tool for which to make a game, its not and should never be the goal by itself. The games you make with it are all that matters.
Saving Money/Time: You most likely won’t. Making an engine takes time, and time=money. Unity’s cost is negligible compared to the time it takes to make your own tech. Unreal’s rev share is negligible unless you’re selling 10 million copies of a AAA game. Using your own engine won’t make you sell more copies of your game automatically. And while you *can* save time in the long run, this usually means having your engine be good enough to carry you across multiple projects, while also providing you with significant workflow improvements compared to commercial engines. It’s not easy to get this right, and you definitely won’t if its your first try at it (and extremely unlikely if you’re doing 3D instead of 2D).
Also, you should absolutely consider your own experience and goals when weighing all of this. If you don’t have a lot of experience making games, you will have a much harder time making an engine (and you should definitely go get some game making experience before trying to make an engine anyway). If you want to do 3D, you will have a much harder time than just doing 2D.
For me, the motivations to making my own engine are mostly about novel tech and specialization. I come from a flash game background, having made quite a lot of them in the mid/late 00s, and its a workflow I am really comfortable with and enjoy. None of the existing engines out there supported importing flash animations, so my only option was to do it myself. It’s extremely nice to just be able to plop .swf files into my resources folder and instantly have the animations available for use in my game code, without needing any middle steps to export them to sprite sheets or whatever.
These aren’t the only reasons why you’d want to make your own game engine. There’s a ton of advantages (and disadvantages) to it, and whether or not the pros outweigh the cons depends a whole lot on how much experience you have with both game dev in general and lower level coding. Like, it’s nice to just have your own tech, and its nice to not have to constantly google for tutorials that might be outdated for how to do something in your engine. It’s nice to be able to actually debug the internals of your game if something goes wrong. But it can also suck if you made a couple of bad design choices and everything falls apart entirely, and there’s no resources online to help you. You have full control and full responsibility, and all the pros and cons that come with that.
What?
Before we get into how to make your own game engine, lets take a step back and define what a game engine actually is, and the types of problems a game engine is supposed to solve.
A game engine is the framework upon which you make a game. It provides you a foundation on which to build on top of, and all the building blocks and lego pieces you need to assemble a game out of. It provides a boundary between “game logic” and “boring technical stuff” so that your game logic code (the stuff that actually describes what your game is, how it controls, the interactions between objects, and the rules), doesn’t need to actually care about stuff like how to send a triangle to the graphics card.
There’s actually a lot of variance in how much game engines actually do for you. Some of them are barely more than just a framework for displaying graphics, doing very little for you beyond that (Flash, Pico-8). Some of them are basically an entire game by themselves, or at least hyper-specialized for a specific genre, putting a ton of common game logic in the engine itself (RPGMaker, Ren’Py). And everything in-between.
Game engines themselves also tend to be built on top of even lower level frameworks like SDL and OpenGL, and include many special purpose libraries for things like audio, physics, math, and whatever else is out there that you find useful. Making a custom game engine does not mean writing every little piece of it yourself, especially something as standard and useful as SDL. Assembling the right set of existing libraries for your use case is part of making an engine as well, and there do exist libraries out there for nearly all of the systems you could want in your engine.
Anyway with that in mind, lets talk a bit about what I consider the most basic feature set you need for your game engine. The bare essentials. The minimum that you need before you can start making a game.
System Initialization: opening a window, obtaining an OpenGL/DirectX/Vulkan context, initializing audio. SDL will handle all of this for you, so just use SDL. Like really, SDL is industry standard at this point for custom engines, there’s no reason to do this part yourself.
Frame Timing Control: You want your game to run 60fps, so you need some kind of timer and loop that controls when updates and renders happen.
Input: You need to be able to respond to button presses. There’s a lot of different ways to respond to button presses, maybe you just want to be able to query the current state of a button, or maybe you want to register events, it doesn’t really matter. SDL will report button inputs to you, if you’re already using that for system initialization you should be using it here as well. You can build a really powerful and flexible input system on top of this, but its not necessary to do anything more than the basics at first.
Rendering: Most, probably at least like 75% of games, use graphics in some way, and this is absolutely something that should be your engine’s responsibility. If you’re doing a 2D game, the bare minimum renderer just needs to be able to display simple textured quads on the screen. Shaders, vertex buffers, render targets, meshes, materials, and whatnot are all great, but they can come later as you need them. If you want to get your hands dirty with OpenGL or Vulkan or whatever you can absolutely go ham with your custom renderer, but again there’s no shame in using an existing library like Ogre3D to cover rendering. Entirely depends on your goals and your needs and what problems you actually find interesting to solve.
Math & Misc. Utilities: I don’t really consider “vectors and matrix math” a full on “System” but it is something you should probably have as a utility library that engine and game code both have access to. Plus any other random useful functions and formulas you find as you dev.
