The Meaning of using Game Engines: Unreal Engine 5


I started learning about game development when I was 14, in 2004. At that time, professional game engines were not availabe.

Since the inception of real-time 3D in the mid-1990s, 3D game development dramatically evolved. My article analyzes the technical and economic evolution that led to the distinction between a game engine and a game, and evaluates why the adoption of general-purpose engines has become the industry standard for solo, indie, and some AAA teams.

Introduction

The never-ending debate between developing a custom game engine versus using a general-purpose engine, such as Unreal Engine or Unity, has yet a crystal-clear technical answer.

From a technical perspective, I argue that for solo developers and small-scale teams (up to 20 developers), and in some cases for AAA game studios as well, using an existing general-purpose game engine is the best strategic decision.
On the opposite side, I argue that building a custom engine very often create a massive technical overhead that doesn’t give increased product value, outside of very specific cases that I will highlight as well.

Creating a high-quality 3D game while meeting today’s quality standards is already an incredibly challenging task. Therefore, developing a custom game engine on top of that would only generate a gazillion of additional issues!

Moreover, the sheer amount of complexity of modern 3D game development, with ray-traced lightning, PBR textured assets, complex animations, and much more, make engine development a distinct discipline from game development. Thus, my article demonstrates how these are now two very separate professions.

The only cases I can think of where custom engines might make sense, as a solo dev or a small team, are the following:

AAA Custom Engines


This article will not focus on triple-A studios (i.e., video game development studios with high revenue and large teams). Some have enough financial power to spend millions of dollars per year, and hire the most talented developers. Thus, they can afford the luxury to create a proprietary technology, specifically tailored to their own needs.

For AAA studios, building a custom game engine from scratch might help them to achieve higher quality standards than those possible with universal game engines, because they can tweak performance to a higher level. I mostly think about Rockstar Games in that specific case, with RAGE, a custom engine used for multiple franchises, including Grand Theft Auto and Red Dead Redemption.

This can indeed give competitive advantage over other game development studios, and help to create a higher-quality product.

But even in that case, we saw a major shift from creating proprietary, tailor-made engines to either creating more generic engines, used in entire studios instead of just for single games, or to use existing universal game engines.

Focus on 3D Games


It’s also very important to highlight that my article is focused on developing real-time 3D games (what we called true 3D way back when) with high-quality graphics. I am avoiding any explanation about 2D game development, as I know absolutely nothing about it.

Besides, I do not talk about low-poly games or simple 3D games using retro game development workflows, as these are far simpler from a technical standpoint, and sometimes too niche.

Lastly, I will avoid 3D mobile games with very simple graphics and gameplay. I only have long-term projects in mind.

Choosing the Right Tools


There is nothing more dangerous than thinking there’s a one-size-fits-all solution for every project, or that every single game must be made with either a custom game engine or an existing one only!. In fact, one of the most important qualities of a good programmer working on a commercial project, if you ask me, is being open-minded (besides technical skills, of course 😂).

Moreover, there are a gazillion reasons why a great programmer should choose the best (and most relevant) technology for any given project, after carefully considering different tools while keeping the following key criteria in mind:

Most game development projects last for several years before being released, especially for console and PC games, and probably smartphone games in the future! Even when creating the next game, many (good) developers will reuse the same codebase (if it follows good practices with conventions, design patterns, software dev principles, etc.), unless the new project is drastically different!

This is exactly why evaluating a project before choosing a framework, engine, API/3D API is crucial. Thus, in most cases, making your own game engine when we already have incredible, well-established engines with a proven track record, such as Unity or Unreal Engine (and others 😉) is much harder to justify from a technical standpoint. Especially because Unreal Engine, for instance, is Source-Available (and not Open-Source, be careful!), and can be modified as you see fit.

Historically accurate


However, the very idea of making your own game engine isn’t something that came out of thin air! From a historical point of view, making your own game engine during the 1990s and early 2000s was very common, and probably a good idea.

I will try to avoid writing an entire history of game development (I leave that for another day), however, I will offer some insights into why this idea was prevalent!


The Birth of 3D Game Engines


Before real-time 3D and during the fourth generation of consoles, game developers were creating most games on Super Nintendo (Super Famicom) or Sega Mega Drive (Genesis) using Assembly languages. Because of the nature of that family of languages, the idea of creating your own game engine was actually nonsensical.

Before: Assembly Languages (4th Gen)


Technically speaking, Assembly is actually a family of languages, and each one is tied to a specific processor (and machine). In other words, Super Nintendo’s assembly language (65816 Assembly, and SPC700 Assembly for music) were different from the Genesis’s Assembly language (68k).

Thus, developers who made games for Super Nintendo or Genesis would need to rewrite most of the code if they wanted to port the game to another platform! However, porting an existing codebase to another language, whether similar or not, is significantly easier than creating a new codebase (i.e., a new game) from scratch.

Although I’ve read some books mentioning “game engines” made for Super Nintendo, I found zero evidence suggesting that it was the case (as far as I know). Besides, the very concept of a game engine made zero sense at that time, as I said earlier. In fact, most libraries or code developed for a specific game could only be reused within the same hardware generation. Games which had multiple iterations probably reused the same functionalities, such as Mortal Kombat or Donkey Kong Country.

In most Assembly languages, including the Super Nintendo’s Assembly language (65816), we can reuse code by writing subroutines, which are similar to functions in C or C++. But having multiple subroutines and sharing them between games doesn’t equal making a game engine. Reusing code is a natural part of any software, and has nothing to do with my definition of a game engine.

I would also like to point out the possibility that some games may have been made in C on Super Nintendo. However, as far as I know, there is no official evidence to officially support this claim. So, I will leave it as a hypothesis, which is quite common in the gaming industry, as many development details remain secret (especially during the 1990s and 2000s 😅)!

After: C Language (5th Gen)


As the fifth generation of consoles started in late 1994, game developers shifted from using purely assembly languages (supposedly) to the C language, created by Dennis Ritchie between 1969 and 1973. However, assembly was still used for certain critical parts, with three different possible methods that I will expose later (based on the C language reference, not on actual interviews from developers).

I can give some hypothetical examples of games where the Assembly language was used to optimize critical parts. But, as I already said, some of this information is not backed-up with evidence of actual developers, outside of Andy Gavin.

Definition of Game Engine


During that era, as complexity grew exponentially with new game genres and real-time 3D, it started to make much more sense to establish a clear separation between two major aspects:

This separation is essentially the definition of a game engine, which could provide reusable tools instead of, as many people always say, reinventing the wheel 😉.

Besides, it seems like the word ‘game engine’ was actually invented by John Romero and John Carmack, who were inspired by car engines, as mentioned in Romero’s book, Doom Guy. Moreover,
Henry Lowood confirmed, by using Google Books Ngram Viewer, that the term ‘game engine’ started to appear frequently right after the release of DOOM. Before that, he explained that most instances of the term were unrelated to the gaming industry!

Ultimately, the idea of creating game engines was born by the need to avoid the same code (over and over again 😴) for generic functionalities, those not tied to any specific game but essential for most, if not all, games. However, as I’ll explain later, this approach came with major limitations, mostly related to game genres.

Pseudo 3D Game Engine


Although I avoid 2D games on my article (as it’s not my area of expertise), it’s worth highlighting some 2D engines such as the Gold Box Engine in 1988 (according to Schules, Peterson, and Picard) or the Adventure Game Interpreter (based on Greenberg).

Full 3D Game Engine & Genre Specialization


True 3D game engines, i.e., those capable of 360° camera rotation and full 3D rendering, were the XnGine, Descent Engine, Quake Engine, and Unreal Engine.

But a very interesting fact is that all of these game engines had something in common: they were specifically built for creating First-Person Shooter (FPS) games.

Bibliography