How a Game Engine works — From a simple perspective
This is a simple explanation how a Game Engine works with a little depth on each common subsystem
Games are almost everywhere today, since from gaming consoles, computers to smartphones. And Game Studios develop these products by using tools that helps to turn their ideas into reality. Where these tools can be specialized to create something specific or more generic.
These instruments can help to track human motions, scan areas and turn into a 3D environment, mix sounds into specific formats to support the selected architecture for the game development. And are generally (or can be) integrated into a software that helps to create video games, which are named generically Game Engine.
A Game Engine works like a "backstage" of a movie, where there are Subsystems (the directors) that specializes and commands certain "things" (the actors). Generically the Game Engine architecture consists of a: Memory Handler Subsystem, Render Subsystem, Input Subsystem, Physics Subsystem, A.I. Subsystem, Game Objects Subsystem, Animation Subsystem, Audio Subsystem.
1. The Memory Handler Subsystem
The Memory Handler Subsystem is the "core" of each Game Engine, because it handles the memory allocation and deallocation functions for each instance and structures on the game and tries to avoid memory fragmentations to speed up the game’s performance.
In the "common language" (for non-programmers or related), an example is how to handle the Game Scenes / Levels and how are they loaded in some way to get the maximum performance of the hardware at each instant / frame without making the famous "lags" and slowdowns.
2. The Render Subsystem
The Render Subsystem takes care of the graphics, where matrices calculations are happening into the hardware's GPU and are shown into the user's screen.
This part takes care since the loading of a Texture and combining it into Materials to drawing into 3D Virtual World or a Sprite to a 2D Virtual World, furthermore relates with Light Emitters to create Shadows or other effects and at last how are displayed into the User’s View Frustum (User’s Monitor / Vision).
If you don’t what is a Texture, Material, Sprite, Light Emitter or a Frustum… Don’t worry! I can explain to you!
Texture: It’s an image that will be applied into a 3D World.
Material: It’s an “object” where combines textures with lighting models (like specular, diffuse and ambient).
Sprite: It’s an image that will be applied into a 2D World.
Light Emitter: It can be an “object” that emmites lights like the Sun, a Light Bulb, a Flashlight…
View Frustum: It’s the “Field of View” (look at the quotation marks) for user.
3. The Input Subsystem
The Input Subsystem specializes in getting the information from the H.I.D (Human Interface Devices) by using the OS (Operating System) drivers, which can be a Joystick or even a Keyboard. And these informations can be transformed into some kind of event inside the Game, like if the some Stick has been moved, the player's character moves.
But… Wait… If you don’t know what is a driver… I will explain! A driver it’s more like a program that is running on the Operating System of your device that you are using to read this for “listening” taps, touches, key presses.
4. The Physics Subsystem
The Physics Subsystem specializes in mimetize the real world physics, like the image above where there is a person surfing on the sea wave, which was generated by the wind fetching the ocean water.
One simple example in a 2D context is how to detect a simple collision between two squares in one axis and with their pivot set on their center:
Where the inequation “says” if the absolute of the sum of positions in X are greater than the sum of the the Widths of each square divided by 2, they aren’t colliding, else they are.
5. A.I. Subsystem
The A.I. (Artificial Intelligence) Subsystem, where the Objects tries to act in the optimum way to a desired target state. Here we can works with Pathfinding algorithms to search the “best” possible route to a point in a graph (e.g. how to get out of a maze).
Mostly in games, theses Pathfinding algorithms can be used to find the best way to the enemies get close to the player in a RPG, to move the troops on a RTS system, or even for a 3D FPS game.
6. Game Objects Subsystem
This is a Subsystem that handle the components that are in the game itself, like the characters mechanics, static objects and “mob” spawners and so on... More specifically specifically speaking is how they will interact with the Game Scene and with their Entities, furthermore how they will interact at each game loop (which the loop will be shortly discussed here).
Generally these entities are written using High Level Scripting Language, like LUA, because this avoids the compiling part of a Game Engine, so a script is always read at runtime and makes easier to debug.
7. The Animation Subsystem
The Animation Subsystem handles the models rig animations for 3D or the sprites atlases animations for 2D. This is where the characters and the game scenarios mimetizes the life (or not… Depends which genre the game will be focused).
On the image / sprite atlas above, we have multiple positions of the movement of this “toucan” (seens to be like it… Or is it a Parrot? Or both?), where each one is an individual sprite, so for example in each frame, we render one image and then another, after that we can achieve a movement effect.
8. The Audio Subsystem
The Audio Subsystem takes care of the Audio itself (e.g. Music, Voices, Ambience and Objects Sounds) and the Audio Effects. This Subsystem loads since the audio files by using certain Codecs and how the sounds will interacts in the game, like if the certain audio will be used with a Spatial Algorithm for creating a 3D effect or if it will work as Stereo only.
And is there something more? The answer is “Yes”, but in that post we are focusing on the most common things that are in the popular Game Engines like GODOT, which is Open Source.
But… How these subsystems communicates between each other? This is by using a simple internal "loop" function where (depending on the architecture) from Physics to Render Subsystem (in that order) are called repeatedly while the game isn’t closed / stopped. But I can explain this a little bit more on some another time by demonstrating a simple 2D Game Engine made in Swift.
Did you like that post? Please push the clap button! But if you didn't like it… You can comment bellow with a constructive feedback for me! Did I miss something or made some mistake? You can correct me! If you want to message me, feel free! :)
Thanks for reading!
REFERENCES:
- GODOT Engine — https://godotengine.org/
- LUA Language — https://www.lua.org/
