There is an old saying in the gamedev community that goes something like this:
"Give a man a game engine and he'll make a game. Teach a man to make a game engine and he'll never stop improving his engine."
That's quite a heavy claim! And let me go ahead and tell you that, from my experience, this sentence carries a lot of truth with it. There is a long list of half-finished game engines and game development frameworks that were created in the past, and no actual game was ever built with them. Ever.
"But Gustavo! How can you say that? Don’t you teach people how to make game engines?"
Well, yes. But we want to be absolutely sober about this decision. In many cases, using an out-of-the-box commercial engine is the right call for your project. Deciding between using an existing engine and writing one from scratch means we need to be super aware of our goals and understand the limitations that come with our decision.
When should I use an existing commercial game engine?
If your end goal is to build and release your game as fast as possible, with reasonable performance, and target multiple platforms and devices, then you should probably just go ahead and use one of the out-of-the-box commercial engines we all know and love.
If you are reading this article, you know the big names in this category:
The engines listed above are amazing pieces of software. They have been used for years by professional developers to publish many titles. One of the main reasons they are so popular is that they abstract some of the hard tasks that are required to develop simple games, allowing you to focus on the high-level aspects of gameplay and asset creation. They provide power, reasonable performance, a great editor, and user-friendly tools.
Most third-party engines provide an IDE-like feel to them. They bring the power of a great programming API, scripting, assets management and runtime debugging, and combine all ends of the game development flow. You can design, edit, script, debug, and deploy your project using a single product, building your game from start to finish without ever leaving the engine.
How hard is it to create a game?
Don't ever underestimate how hard it is to create, design, sell, and successfully distribute a game in the current market. If you are an indie developer trying your best to be ahead of the curve, a powerful engine might be the help you need to get your game out of the door as soon as possible.
When you are a beginner, it's hard to fully grasp why some tasks take so long to be implemented. Character animation, collision checking, synchronization between animation and audio, improving performance as multiple enemies appear on the screen. These can either be super trivial or end up taking weeks to implement.
Back in the 90s, what we called a "game engine" was basically a bunch of .c files that targeted only one platform. We would basically carry around floppy disks with some of the files we used in previous projects, tweak the source code to implement the new requirements, and build the binary that the end-user would run on their machine.
Games were a lot smaller back then. If we were developing an MS-DOS game, many variables were not variables at all; the screen resolution was constant, the aspect ratio was always the same, the developers would know the color palette and poke the display driver memory directly, there was no OpenGL, no DirectX, no Vulkan, and GPUs were still not a thing. We would also have a pretty good idea of the hardware specs and how fast the processor was. So much so that some of these games' FPS were tied to the processor clock and video synch rate.
If we had to target a different machine (let’s say the Amiga), then we would probably have to translate the core engine code to 68000 assembly, take advantage of some custom Commodore chips (Blitter, AGA, Copper), change the color palette, add some other fixes here and there, and voilà!
Okay, I might be downplaying a bit how hard of a task that was, but it was definitely doable. One experienced programmer was usually enough to complete the port.
Now let's fast forward to modern gamedev times. The huge amount variables that play a part in shipping the simplest of games in the current market is nothing short of overwhelming. Games became miracles only possible through a heavy collaboration of talents. We are talking about a large warehouse full of artists, illustrators, animators, developers (level designers, tool programmers, engine programmers, physics programmers), gameplay designers, network specialists, project managers, and many other fancy titles that look great on LinkedIn. Also, gamers and developers expect games to run on multiple platforms, consoles, operating systems, communicate with different accessories, interface with third-party hardware parts, and deploy to different stores.
It is no surprise that several game developers end up encouraging others to simply use a boxed commercial game engine, and that is a completely rational suggestion. If you are in the business of selling games, it's all about bypassing obstacles. With so many variables and ever-increasing complexity, having an engine taking care of some of these hard tasks can help you focus on what really matters: shipping your game.
Alright! After all this preaching, it looks like this could be a very short article. It's clear that using an existing engine has a lot of benefits, so why would anyone bother to create a custom game engine? Well, not so fast! There's a lot more to this topic than meets the eye. There are special situations where I do encourage students and other programmers to write their own game engines. If we go down that road, it is imperative that we understand the obstacles we'll face and adjust our expectations.
When should you write a custom game engine?
In my opinion, there are at least two important scenarios where you should consider writing a game engine. You should seriously consider a custom game engine if you find yourself in the extremes of the gamedev career spectrum:
- you are a beginner gamedev who wants to grow as a programmer
- you are an experienced programmer already working for a big development studio
Beginners should learn how the game sausage is made!
If you are a beginner gamedev, and you are serious about the programming aspect of games, I would encourage you to write a simple game engine from the ground up. If anyone tells you otherwise, they are either being naïve or elitist.
I noticed that most students that enroll in my Create a C++ Game Engine course are not looking to ship a game. Building a game engine from first principles is a great learning opportunity. You'll need to open black boxes and reflect on some of the fundamental design decisions that are required by any game.
For example:
- How do we organize game objects in memory?
- How do we create a robust and smooth game loop?
- How do we structure our data to optimize cache-hits?
- How do we separate rendering from gameplay logic?
- How do we design and structure your code for maintainability and growth?
These are not just game engine questions; they are important computer science questions dressed as a game development project.
From the perspective of an educator, a project that invites students to create a small game engine is usually an easy win. It gets students excited and willing to push beyond what is asked in the brief. If someone comes along and tells my university students that coding a game engine is not worth their time, in my opinion, that is a clear act of gatekeeping and a celebration of mediocrity in higher education.
What game engines do professional studios use?
On the other end of the spectrum, if you are an experienced programmer already working in a large AAA studio, you’ll likely need to understand and maintain the code of some existing internal game engine.
Some of the large gamedev studios develop and grow their own internal engines. These engines are not boxed products; they are a collection of custom tools tailored to meet the requirements of individual games.
Having one tailored engine per game allows the code to be adjusted as needed to fit individual requirements that only make sense for that game. For example, some games have multiple objects colliding several times per frame, while other games rarely have objects colliding at all. Depending on the nature of the game, the engine code can be modified to release resources to other subsystems. It's all about using the engine to squeeze all the performance possible. This is why we see complex AAA games running smoothly, while simpler games might struggle to reach acceptable framerate values.
Building a game engine is hard!
"But Gustavo! Building a game engine is super hard! I see so many successful developers publishing their games with Unity."
I agree! Let me say this one more time: if all you really want is to develop a game as fast as possible and get something working on multiple platforms, please just use an out-of-the-box commercial game engine. It’s as simple as that.
Is it hard to write a game engine? Absolutely! It's a task that requires a lot of time and dedication. It can take years for you to create something that you're proud of, but it's also an incredibly satisfying experience. Seeing the result of your work and put the theory into context can help you grow immensely as a developer.
Reading about how difficult it is to build a game engine can demotivate many students. There are no two ways about it; experience and scars are required for anyone to truly learn and master any subject. Building a game engine is hard, but if you set your expectations and the scope correctly, writing a very simple game engine is something that any programmer can do.
"Making games was just an excuse for us to keep building game engines."
- Ron Gilbert, LucasArts programmer, Monkey Island games.
Ron Gilbert's quote might sound weird at first, but once we realize that successfully writing a game engine is very similar to playing a game with varying levels of difficulty, then it's easy to see why this topic becomes a lifelong passion for many developers. Virtually every senior programmer that I’ve worked with tried to write their own small engine at least once in their lives. For better or for worse, this is the type of thing we like to talk about during lunch with our peers. We don’t need to understand how game engines work; we just can’t help it.
Please, don’t get me wrong! This does not mean that writing a game engine from scratch "is what real programmers do." I am not claiming you need to have a certain background or fit a certain personality type to succeed in the games industry. Game development is a vast field where many people from different backgrounds and motivations both succeed and fail.
That being said, objectively looking at what my previous students that are now working in the game industry did, all I can say is that having a large number of programming projects under your portfolio can open many doors. A small game engine can be a great example of a project that you can show employers during a technical interview for an entry-level position. Also, being able to explain how you designed and architectured your engine is a quick way of showing you know your stuff. If that helps you land that dream job, then it's a clear win!
Resources for those writing their a game engine
Alright! So now that you have your expectations correctly adjusted, you understand that you probably won’t be developing "another Unity", and you still feel excited about the idea of writing a game engine from the ground up, let’s look at some good resources that can help you get started.
1. Game Programming Patterns (by Bob Nystrom)
Game Programming Patterns is a great read and a great example of how to write a book that explains difficult topics in a beginner-friendly way. The book gives a high-level overview of many design patterns that are largely used by game engines and game development teams. The book does not give you a guided recipe on how to write a game engine, but it shows snippets of code for patterns that can be used to make game code cleaner, easier to understand, and faster.
2. Game Engine Architecture (by Jason Gregory)
Game Engine Architecture is another great read that covers both theory and practice of large-scale C++ game engine projects. It covers some important mathematics of game development, tools, subsystems, rendering, collision, physics, animation, multi-threading, and other aspects of how to implement real-time game engines. If you are a professional game developer, this book will make you reflect on some important architectural decisions of large game engine projects.
3. Game Engine Black Book Wolfenstein 3D & Doom (by Fabien Sanglard)
If you enjoy reading about classic game engines like id Tech 1 and Build, then you will enjoy reading Fabien Sanglard's books. This series is called Game Engine Black Book, and covers the implementation of id Software's Wolfenstein 3D and DOOM games.
4. Create a 2D Game Engine with C++, SDL, and Lua Scripting (by Gustavo Pezzi)
I might be biased, but I do believe this is a great starting point for anyone interested in learning more about how game engines are implemented. These lectures cover the complete roadmap of how to code a small 2D game engine using C++, SDL, and Lua.
You'll code a minimal Entity-Component-System (ECS) from scratch, rendering using SDL, movement, animation, collision, events, add ImGui widgets, and learn how to embed the Lua programming language to allow scripting in your game engine.
If you want to get your hands dirty by programming your own small 2D game engine, this is probably the place to start.
5. Handmade Hero (by Casey Muratori)
If you are already an experienced programmer and have lots of time to dedicate to one project, then Handmade Hero might be a good option for you to follow. Available on Youtube, Handmade Hero is a long series of videos covering Casey Muratori's journey in developing of a Windows game from scratch.
Casey is a game industry veteran. He's known for being, let's say, opinionated when it comes to game programming practices, but in my experience his arguments are usually reasonable and a direct reflection of his knowledge of the craft. The length of the series might be a bit overwhelming (we are talking 600+ episodes of 1+ hour each), but at the end of the day the content that Casey teaches is incredibly detailed and valuable. I have learned a lot from him in the past.
How to avoid losing control when writing a game engine?
One of the great issues faced by many programmers when starting a game engine is not defining a clear scope. It is easy to always find new functionalities and shiny options to keep adding to our engine. Soon enough we realize we have a never-ending project and a list of technical debt items that keeps growing.
This happens to many developers, and usually is a combination of poor scope definition with no actual defined goal when the project started.
Even though it's easier said than done, here are some of my recommendations to prevent losing control when building your own game engine:
- Have an actual game in mind. This is a recommendation I always give to my students. I found that having some idea of the game you want to create helps define the scope of the engine you're building and set some important boundaries.
- Start small and use an iterative approach. Define a very small deliverable for the first iteration of your game engine. It is not always possible to implement a full-feature IDE-like engine. It's easy to reason when working with small steps.
- You don't need to write everything from scratch! Unless you're doing it as a full learning exercise, consider using third-party libraries to help you. There are free and open-source modules that can help you with math, ECS, UI, logs, etc. These libraries are usually more reliable than anything you'll write yourself; you can use them and still create a great game engine by gluing pieces together. Popular examples are libraries like GLM, Dear ImGui, EnTT, and Flecs.
- Decide if your game engine will be 2D or 3D before you start. Pick one style and stick to it. I always recommend beginners to start with a simple 2D engine, as it removes some degrees of freedom and the overall complexity that comes with any 3D project. Either way, it is always better to define what type of engine you will implement before you start coding.
- Always plan and define clear boundaries before you start coding. It is super easy to get tempted to add shiny new features as we go. Stick to the plan and you'll increase the chances of not ending up with an unfinished game engine project.
Remember to have fun!
After all is said and done, just remember to have fun! If you are approaching the development of a game engine as a learning opportunity, focus on the basics and enjoy the process. Everything else is ego!
You don't need to create something huge to succeed. Get something small working, fully understand how things connect to each other, and improve the project with time.
It doesn't matter how small your engine is; the important part is that you own that knowledge!
“...maybe the real treasure was all the engines we made along the way!”
- Bob Nystrom