In the past, when having discussions with friends or relatives over dinner about what games they play, a certain keyword often pops up. Especially so, if one socializes in IT circles. A Game Engine. Most people are familiar with the term and often carelessly throw it around. However, it seems there is a bit of a misnomer going on, as it appears that people are not always aware of what a game engine actually is and what is it’s purpose.
Introduction
So, what is a game engine and when should you use one? I will try to answer you below.
Disclaimer: I will deliberately avoid using any reference material, like Wikipedia or game engines’ own marketing material when describing terms and keywords. This article is my own take on what I know and understand of the concepts. Hopefully, this gives you a fresh, different perspective into the world of game engines. I firmly believe these different angles give readers a broader view of the complex topics (whatever they might be) and allow them to grasp the concepts easier. And I am absolutely sure that anyone reading this is more than capable of finding the “proper” definitions on their own anyway. I’m also very skeptical of this “reference culture” that seems to be deeply rooted in technical papers and scientific field, but let’s leave this discussion for another time.
[Unreal Engine 5 Tech Demo]
What is a Game Engine?
A Game Engine in its essence is a set of functionality (or in some cases even a whole development environment) that allows users to rapidly access and create solutions to common scenarios. These scenarios are related to an interactive media that would be using the said engine – games, virtual / augmented reality applications, architectural demonstrations, etc.
Ok, let’s unpack this.
So, game engine is a framework. Most, if not all of them are libraries that ease the way developers deal with 2D/3D graphics by hiding the nitty-gritty innards. It builds on top of lower level APIs like DirectX, OpenGL, Vulkan which are VERY complex and laborious to work with. Engines also often add additional bonuses like running physics simulations for you, dealing with spatial audio, managing content and assets, etc.
Some of them, like for example Unreal Engine and Unity Engine are so huge and mature, that they are pretty much their own development environments. You could create a whole functioning game without writing a single code line (and I am not exaggerating here). These engines provide you with tools and workflows, where you create mechanics and rules via state machines and event-based relations; all visually, inside their specially crafted powerful game creation suites.
Apart from many commercially available game engines, there is nothing to stop a developer creating his own custom engine. With a bit of elbow grease and a lot of patience, one can craft something that is tailored to the particular needs of the idea or a quirky working process.
[Unreal Editor, 1st Example]
When would you use a game engine?
Many people start out with a vision of a game. That vision is often a visual idea of what the game would look and play like. If you start from a scratch (what in fact many aspiring developers do, because they want to “forge their own destiny”), there is a really long road ahead, before you see anything even remotely resembling the vivid picture in your head. Heck, it will be ages until you manage to display a single colored square on the screen if you are new in this. Also, you will have to comply to certain patterns and data blocks, figure out effective workflows and procedures to be able to create and manipulate entities within your virtual world with relative ease. After all this foundational work is done the initial vision might be blurred or even lost entirely. And, sadly, the creative spark could have already died out.
A game engine aims to be the solution exactly for this case – you can start implementing your idea really easily. You don’t need specific knowledge about graphics architecture. You don’t need to know about the data structures, pipelines and game loops. You don’t even need to know how to code. And the best part – you immediately get something displayed on your screen, which you can start shaping into the approximation of the vision of YOUR game. This is the area where the game engine excels at – it enables users to rapidly create a visual content that shows exactly what the final result will be. This allows you to quickly create demos (or a proof of concept), start player testing early and iterate through the project changes with ease. Some engines even go as far as allowing you to change code as the game is running in the background.
[Unity Editor]
What are the strengths and weaknesses of a game engine?
So, what a game engine is and what it isn’t?
Advantages
What a game engine does really well is allowing users to quickly import content and assets. These are 3D models, meshes, animations, effects, sounds, music, etc. Moreover, it gets them rendered – displayed (or played through speakers) in just a matter of a few quick mouse clicks. Additionally, it often supports most of the popular export formats of 3rd party tools either it is something as simple as Audacity for sound effects, or monstrosities like 3ds Max and PhotoShop for some art assets.
Another great feature that often fascinates game developers is the ability to target multiple platforms with the same project code base. Most of the famous names in the game engine world support all the main platforms (PC, Xbox, PlayStation, Switch, even iOS and Android) out of the box. This saves creators a great deal of headache and allows them to change the target platform on the fly if needed. And, not to shy away – covers a much broader userbase with minimal changes to the project.
So, if you want to start quick, and you have no previous software development experience, the most popular engines in the field have whole free (!) development suites. With them you can create game logic and build it almost as if you were building it with Lego bricks – all visual. Moreover, you could probably even create it all using only the mouse (though learning a few keyboard shortcuts on the way definitely wouldn’t hurt).
[Unreal Editor, 2nd example]
Another awesome thing is that since working with game engines is relatively easy, there is a heap of tutorials and resources online. The more popular the engine is, the more info you can find on each specific little detail and quirk you encounter.
However, there’s one important thing to mention: if you are serious about this, you’d probably still write quite a bit of code. Engines sometimes are even language agnostic, or, sometimes, they let you pick from a certain set of supported languages (most popular being C# and C++ or their close derivatives). This heavily depends on the engine itself, as they might even have their own proprietary language, which you will need to learn. Although to me this doesn’t sound like a lot of fun, because you’d be learning a skill that can only be applied in a very narrow field.
To sum up, this brings us to the next topic: what you should not expect of a game engine?
Disadvantages
One of the main drawbacks is the flexibility of the engine. Game engine inevitably puts you into certain constraints – well as all frameworks do. They have their own specific workflow and data protocols that you must follow. Keep in mind that those are mostly industry standards and best practices. But, if your game is really implementation specific or if you already have a particular way of going about, it might not work for you. Even more, further further down the road it may become a huge hindrance in that case. Of course, you can always recode the engine or wrap it in certain abstraction layers, but then you will be creating your own engine on the top of another engine. And all that just doesn’t sound right, does it?
Following this train of thought, some bigger companies, in their need of game defining features, start rewriting and rewiring the game engine itself. Not just building on top of it but rewriting the internals. While this is totally reasonable, sometimes it gets so out of hand, the final engine is pretty much a new entity in on itself. As a result, we raise a natural question – wasn’t it easier to build your own engine instead?
Another thing is that you’d never create a lean game if you use a 3rd party engine. Those easy asset importers? Those cool out of the box functions and multi-platform capabilities? They don’t come free and they don’t come cheap. A game built on an engine will always have a bigger footprint than a game built from the ground up on the specific API. Sure, engines try and optimize a whole lot during their final builds, but still, there are things that just have to be in the right place for it to function. So, don’t be too surprised when even a simple inception of a game starts off within hundreds of MBs in size.
The last, but not least thing to mention, is that a game engine often brings with it a certain visual feel. This is especially true for 3D rendered games and is even more noticeable, if you, as a developer, do not have a particularly good sense of art direction and do not dig deeper into the render procedures and shaders. In other words, the games built on the same engine might feel a bit the same(-ish).
Game engine Examples
We have quite a selection when it comes to game engines.
There are free options like Unity, Unreal Engine, Cry Engine, Lumberyard, etc. Anyone can use them, or at least – start using for free and later on there are tiered licenses after you start monetizing your game. Out of these I would highlight Unity and Unreal Engine as a really good starting spots for the new game creators.
You can also choose from the paid options like GameMaker, Serious Engine or RPG maker.
Eventually, there are engines that are only available if you work with certain publishers or are their subsidiaries, such as Frostbite or id-Tech.
And then, of course there are the mysterious, shadow covered, strictly in-house engines like the Fox Engine or the Decima.
[Horizon Zero Dawn – Guerilla Games, Decima Engine]
Another way (or the original way)
There is the alternative to using a 3rd party engine – you can always write your own.
On every platform you can find the underlying graphics APIs. You have your DirectX, OpenGL, Mantle, Vulkan, Metal, Gnm. Then there are higher level frameworks which I would not consider as engines, such as XNA and MonoGame. They only provide the APIs and are not that comprehensive in terms of prefabricated functionality – you still have to build that yourself.
[Owlboy – D-Pad Studio, XNA]
SNEAK-PEEK INTO THE PART 2:
In the second part you will find out:
- What are the advantages of writing a custom game engine?
- Why sometimes it’s inefficiend or too complicated choice?
- Advice for beginners.
- What mistakes should you avoid?