A Brief Tour of Game Engines

23/01/2026

A while ago I gave a talk on game engines at my universty's game development society, and I figure it would probably make a good post too so here we are. I'm by no means an expert on game engines or anything this was just a casual talk so apologies if there are any errors.

What are Game Engines?

You probably associate game engines with “that” UI, like you’d see in Unity or Godot.

The reality is that game engines have a far broader definition, and are really just any shared code and features between games.

Wikipedia: A software framework primarily designed for video game development, including specialized software libraries, and tools such as level editors.

Game engines are in my opinion some of the coolest pieces of tech we have, as they encompass such a wide variety of different programming problems. And this shows, as they’re probably up there as some of the most complicated pieces of software on the planet, with AAA engines easily hitting millions of lines of code, filled with interesting low level tricks.

Unity, Godot, Unreal and GameMaker (the “big four”) encompass a very small subset of what they are.

Two Categories of Game Engine

Game engines can be generally split into two categories,

Commercial Game Engines

The terminology actually kinda sucks because it implies that the product has to be sold / licensed out for money.

In reality, a commercial engine is any engine that can be used to make a commercial game. Which also means that proprietary engines are also commercial engines but typically this term also implies that it’s an engine made by a company as the main product.

Godot for instance counts as a “commercial” game engine despite being completely MIT free licensed.

Commercial game engines must support (almost) all possible kinds of game, on (almost) all possible kinds of platforms, which is literally a herculean task with no clean solution.

As a result, they become super bloated, super fast. Even so-called “lightweight” game engines like Godot are massive, and far more complex than the games built on them nowadays.

AAA Game Engines

AAA studios have an advantage as they don’t need their engine to support all kinds of game, only what the company needs.

Some studios even have the advantage of knowing exactly what platform specs they’ll be solely publishing on, such as console-exclusives (Naughty Dog, Guerilla Games, …).

This makes comparison between proprietary engines and commercial engines stupid (in my opinion!) because of course AAA engines are going to be ahead in their tech compared to commercial engines because they’re focusing on a subset of the features commercial engines have to support.

However, AAA engines tend to be more fragmented (and as a result have a very different workflow), as a result of their development history.

They typically have seperate tooling for building levels, editing entities, managing the asset database, etc… (think the Hammer level editor for Source Engine).

For the programmers, the engine is literally just a massive, bloated, spaghettifies C++ library.

This is in stark difference compared to Godot, where everything is neatly integrated under one application that “magically” links everything together… somehow???

Marketability

Your average gamer looks pretty much like this,

Nobody actually knows what a “game engine” is, and AAA companies know this, so they brand their engine as a “secret sauce” that elevates their games above the competition, making gamers think that your game is somehow a more “bespoke” product.

The extra marketability is great because game engines are incredibly difficult to maintain and develop, and saying that you use a custom engine makes gamers think that it’s somehow a more “bespoke” product and thus higher quality.

Gamers like to blame arbitrary “game engines” for terrible games, without taking into consideration what I said before:

Naughty Dog doesn’t have to make a game engine that supports every game possible under the sun, but Epic Games does. You simply can’t have your cake and eat it too.

Unreal Engine being more versatile comes with performance costs because Epic ultimately doesn’t know what game it’s going to be used for.

Is it going to be a platformer? How about top down? Side scroller? Maybe open world? Will there be terrain (what kind?)? Will it be dynamically generated on the fly? Will you be doing live asset streaming or just load everything up-front? How complex is the enemy AI? What’s the graphics style and art direction? Will you be using more advanced volumetric effects or just billboarded particles?

All of these have a massive effect on the way the game plays and feels, in addition to performance.

Engines do matter

I know this is a hypocritical statement considering what I said before, but the statement that “engines don’t matter - design does” is really only true to an extent.

Engines heavily inform the design decisions behind games.

For instance, Minecraft could have probably been made in Unity if they tried hard enough, but it realistically wouldn’t. The development would be going against Unity’s architecture (think, custom physics, rendering pipeline overhaul, revamped networking, …). And as a result, downstream effects such as the modding scene would look completely different, potentially even non-existent.

Minecraft gets a lot of criticism for being written in Java, yet ironically Java is probably the reason it became so massive in the first place. It gave the community so much more control than the developers could have imagined.

That being said, I still stand by saying that “Unreal is ruining games” is more like a half-truth.

Indie Engines

The core piece of advice here is KISS - Keep It Simple Stupid!

Never, ever, ever for the love of god over abstract.

I’d recommend making a game alongisde your game, because it’s easy to make a game engine that “works” on paper, but sucks in practice. There’s no better way of finding bugs in your code and testing usability, and this will naturally shape the engine into your ideal tool.

Typical* Engine Structure

Engines are typically organized into “tiers” or “layers”:

I recommend watching / listening to this talk by Jason Gregory that talks about how Naughty Dog develops their games.

Their project architecture is organized into,

Common code is then constantly abstracted to “promote” it to Shared code. Common code and Shared code both live in the same directory, but Shared code is compiled as a seperate library while common code is compiled as part of the game executable.

A History Lesson

1990’s: Pre-Engine Era

Around this time, game engines weren’t really a thing, and every game was built from the ground up.

This era was pretty much dominated by id Software’s pioneering work,

id Software later licensed out a variant of the Quake engine, “GoldSrc”, to Valve, which they used to make Half-Life.

2000’s: Standardization

Game engines start to become more standardized: level editors, asset pipelines, software libraries, etc…, all become commonplace. Multiplatform game engines become more prevalant due to the increased profits that they can bring.

2010’s: Commercial Engines take off

So now commercial and proprietary engines alike have established their toolchains. Commercial engines become very popular due to the indie boom where pretty much everyone and their mother is making a video game. Amidst all of this Unity becomes the de-facto standard indie engine.

Games - and by proxy the engines - focus on open world spectacle. As a result game engines start to become more generalized due to the increased demands in game scope, moving away from their specialized designs. A kind of “great filter” occurs where lots of engines are dropped around this time because their codebase simply can’t keep up.

Pipeline Modernization

Initially, tools such as the asset manager and level editor were seperate programs due to necessity. Lower hardware specs meant that level designers couldn’t handle having the game, assets, level editor, and whatever else open at all times.

However, this was a pain. Multiple different programs created lots of friction slowing down development time and causing lots of bugs. As hardware specs improved across the board, this wasn’t the case anymore. Modern level editors, such as Hammer 2 (Source 2) are literally built in the engine itself.

This allows level designers to hot-modify the game as it simulates and renders and get real-time feedback, and artists to see what their work looks like directly in-game instantly.

Tools Pipelines

Many AAA companies have established pipelines dating back to the 2000’s when engines were first standardized, because artists, level designers, programmers, etc… all have to work together… somehow(?).

Changing the established pipeline is incredibly difficult even if the current one sucks. If even a single feature is missing then people will just go back to using the old system.

This video by Guerilla Games talks about a lot of their difficulties updating their tools pipeline for the Horizon games.

As a result, most AAA companies are still stuck with at least parts of their pipeline fragmented between different tools. Oh, and don’t even think about rebuilding the engine itself. Engines don’t get “rebuilt”. Ever. I saw an image of a roman empire building that just kept getting built over and I feel that this demonstrates it the best:

2020’s: Modern Era

So now the focus becomes on photorealism and performance. Thanks to at least partially integrated tooling, workflows are far more streamlined.

We also start seeing more “convergence”:

We’ve come so far

It’s important to recognise just how far we’ve come in the literally only 30 years games have been developed.

A case for your own engine

In my opinion, indies actually have a leg up. Remember, your engine doesn’t need to do everything, only what your game needs. And that is actually very manageable.

You reap performance benefits, and it allows you to do fancy rendering tricks that might be out of reach in commercial generic engines. It also gives you complete authority over the physics engine, entities, input processing, etc…

Celeste and Teardown were both built in engines becasue the developers felt that the extra control was necessary.

Finally, you do get those fabled bragging rights and marketability, and if you really need me to tell you, it’s a great thing to put on your CV.

Game Frameworks

If you still want control of the custom engine but want to cut down on the work you can turn to a game framework. It’ll handle the low level platform and graphics code for you typically, so you can think of them as handling the OS and PIGS layers I mentioned before.

MonoGame/FNA, Love2D, libGDX are some of the most well known game frameworks and I personally love them.

That being said, they’re not engines! These frameworks don’t have notions of “entities” nor how they interact. Therefore they have no notion of physics or maps or game objects or tiles or colliders or particles or events or ANYTHING!

Some of these frameworks come with extra “packages” you can opt into (I know libGDX has a lot of these, MonoGame as well) which provide modular functionality, such as a Box2D integration (physics) or particle systems.

All of your tools have to be built in house still, such as the map editor, entity editor, developer console, etc… Which all sounds like a lot of work. It is. Buuutttt it’s not AS much as you think. And ultimately it gives you super valuable experience.

Or, just pull a Terraria and literally hardcode absolutely everything into the game code :p (looking at you, 10k line long if-else item handling function).

Resources you should look into (if interested)