Game Engines

When I started learning C++ To make good performing games in Unreal Engine I started to wonder how Game Engines were programmed.

It seems like the programs I've always used had some magic to how they worked and I couldn't comprehend how one would go about making software like a Game Engine.


A friendly warning: knowing how these engines are made does take away some of the magic when developing games but it's replaced with knowledge that you won't otherwise acquire elsewhere and at the end of the day you will be a better game designer... more aware of performance shortcuts and also much more aware of what Game Engines offer you as a Game Designer and how you can take full advantage of them.

The Building Blocks

So You probably play games, we all know 2D and 3D games but did you know that the only difference 2D games have is one less axis to worry about, so instead of doing magic game maths with x, y and z we only use x and y.

z Is still there but instead of it having an impact on how large the object gets rendered  it's purely used to see in what order objects get rendered. We call it the z-order of an object, an object with a smaller z-order gets rendered  first witch means the highest z-order will not be overlapped by any other elements. (its no longer perceived as a coordinate, altho it's slightly similar by some standards)


So what exactly is the base of a game engine… this is easy to answer, we have a Renderer ( code that displays moving images on our screen) there isn't much more to it, all the other parts of a game engine are there to help this system move the pixel colors around on the screen or add and subtract colors. 


It might make it sound easy but believe me, this system is the bare-bones basics that you can build upon but without the rest of the systems, you won't have a game engine. The Rendering system is critical to understand before understanding the rest of the systems.

The Coding Language

It might help to mention that if you aren't coding your game engine in C++ You might just as well not go any further with it. The main purpose you would want to write your own game engine is for some extra performance, and C++ would definitely be your best bet. I'm Very well aware that Minecraft Java edition was coded in Java, but this is exactly why you can have 96 Chunks loaded on Minecraft Bedrock edition but only about 32 Chunks on Java edition on the same PC, and that 30 chucks will definitely Cause extremely low FPS on any good PC.


So long story short if you are really serious about Game Engines or game programming you will learn C++

Render Engine

So after you've learned the basics of C++ and you are ready to learn to display some beautiful graphics on your screen we can begin!


The next step is to get some graphics rendering and we do so with something we call a graphics API. If you have ever played a Decent game on a windows computer I'm sure you have heard about Direct3D ( DirectX ), this is a library of code containing functions that can be used to send commands to our graphics card to render Graphics on the screen, the collection of all the function calls in our Program that are Direct3D functions is our Direct3D Render Engine.


The problem we face with Graphics APIs like Direct3D is that they can only be run by the Windows OS. So this means if we make a game Using the Direct3D API we won't be able to run the code on any other platform. Unless you play games on Linux using an “emulator” like “Wine”.

Apple also has its own Graphics API called Metal.


Does this mean we can’t make cross-platform games using Graphics APIs, well no, luckily we have other options!


Just like Direct3D, we have other Graphic APIs but they are cross-platform. Vulkan and OpenGL

Vulkan is more difficult to learn but if done right you can get better performance than you can by using OpenGL.


Vulkan : https://www.vulkan.org/

OpenGL : https://www.opengl.org/

Direct3D : https://docs.microsoft.com/en-us/windows/win32/getting-started-with-direct3d

Metal : https://developer.apple.com/metal/


I'm not going into specifics on how to use these APIs but following these links will definitely get you started with some great learning resources.

The Subsystems

Great! We have graphics rendering to our screen … but it's boring because there are no systems that help us make a game. Although most of these subsystems will rely on our Render engine to display things to us the experience of the person using the game engine or even the person playing the game is reliant on all the subsystems like :

And probably a bunch more, but let's look into a few of them to get you started.

Physics Engine

So now that you have your 3D or 2D graphics rendering on the screen it's time to add some functionality to them. And we achieve this by building a Physics Engine with once again another library. The library I would use is called PhysX and it is developed by NVIDIA as a cross-platform Physics solution for games and game engines.


This library helps with basic physics but also with advanced physics simulations like cloth simulations.


PhysX : https://www.nvidia.com/en-us/drivers/physx/physx-9-19-0218-driver/

Game Engine GUI

We have a window with graphics rendering and physics but we can't affect our objects in real-time, there are 2 ways we can do this using UI Libraries, the first way would be to make some menus we can use to change details about an object and a menu we can use to add models like a content browser.


You can easily do this by using a library called imGUI, which stands for immediate mode GUI, immediate mode GUI is GUI that updates every frame, unlike the GUI you normally see in basic computer programs like NotePad. This graphics mode is known as Retained mode GUI and is only re-rendered when the computer receives input from the user.


Then the second GUI library we will need to affect our objects would be the 3D UI to move, rotate and scale our 3D models and we can use “ImGuizmo” or “tinygizmo” to achieve this, once again another library. Note that ImGuizmo requires you to be using ImGUI so if you are not, you should rather use tinygizmo.


ImGUI : https://github.com/ocornut/imgui

ImGuizmo : https://github.com/CedricGuillemet/ImGuizmo

tinygizmo : https://github.com/meshula/tinygizmo

Some Extra Info

This is by no means a full tutorial on making a game engine from start to finish, the reason I'm not planning on doing that is that it has already been done, I just want to be able to spread some helpful links your way so you know where to go if you get lost.


If you want to learn C++ from start to finish and more about Using Graphic APIs visit The Cherno’s Youtube channel, the guy is awesome and knows what he is talking about. He is both knowledgeable and knows how to explain a concept.


The one book I would recommend is 

Game Engine Architecture by Jason Gregory 

This book is an amazing overview of basically all the systems that make up modern Game Engines so if you are at all even the smallest bit serious about learning game engine concepts this book is a must-read.


If you have some Feedback feel free to leave some here, or even if you have some helpful links that I haven't shared please let me know.