Game Engines: Part 1 - What are they?
Vroom Vroom Mother-tucker
How does engine, game make?
The term ‘engine’ is a slightly misleading one.
Talking about how X game runs Y engine tends to lead people to believe that their device (console / computer) is launching the engine, and the game is running on top of the engine.
This is where we get a lot of misinformed opinions like “this game runs bad because of X engine” or “this game would be better if they didn’t use Y engine”.
It’s not quite that simple and far more nuanced.
When we talk about an ‘engine’ what we are really talking about is a suite of tools and systems that helped develop, test, run, expand, and monitor the final product.
Then the final part of the development process is taking what the engine made and packaging it up to work on Playstation, Switch, PC etc. The consoles themselves are for the most part unaware / indifferent to what engine made the game, as the consoles have their own way of running a game and the engine creates a version to run on that console.
The best analogy I can give is a restaurant. For the most part the entire establishment is the engine, however, it’s more accurate to say the kitchen and all of its staff, tools, and ingredients is the engine. You don’t say that the pasta that arrived at your table is running on the kitchens ‘engine’.
The kitchen made it, and then you get a final product that no longer needs the engine / kitchen for you to eat it.
This is a very simplified metaphor for engines, however much of the criticism about engines is ill informed and it’s because they don’t understand this basic principle.
X game doesn’t run bad on the Playstation because the engine is bad, nor would the game be 100% better if it ran on another engine.
The game running poorly can be for a variety of reasons not related at all to the engine, and when the engine is to blame, it's normally due to other complicating factors.
Your pasta isn’t bad because the kitchen isn’t good enough to make pasta, but is most likely due to complicating factors like human error, the kitchen was far too busy, or something went wrong. Same applies to a ‘bad’ game.
I’m going to write a couple of articles on engines, mainly because I find them fascinating, and the next one, part two will delve deep into all the times it went wrong and what happened.
In this article we are going to cover the basics of what options are available to studios when they need an engine.
Engines can be categorised into three buckets; In-house, Commercial, and Open Source.
In-house Engine’s
In terms of an in-house engine, these are often created within a company for the sole purpose of making their style of games. As they are considered proprietary technology, and involve a lot of time and money to develop, companies tend to rarely share these engines with other companies. Their are a few exceptions like Decima, but for the most part they are locked away only for internal use.
There are two key benefits for a studio to fabricate their own engine, profit sharing, and focus.
Profit Sharing
With a commercial engine you have to share a portion of your profits. This will scale with the popularity of your game and so for big studios, investing hundreds of millions into their games, the math of profit sharing is something that isn’t appealing to them.
For example, Ubisoft invested about $500 million dollars into developing Assasins’s Creed Odyssey, the marketing costs are often a few million if not tens of million on top of that and so its quite a steep incline for a game to make its money back when its being sold at under a hundred dollars a title, then goes on sale later on.
Unreal Engine won’t charge their 5% royalty fee until your game passes its first million. So let’s say for example Ubisoft, who do use their own engine instead released Odyssey on Unreal. They would need to add 5% on top of that ~$500m+ investment to get to break even.
They also need to pay that 5% on every sale, every quarter for the life of the game. This interferes with a studios desire to not only make their money back, but to also get enough profit to pay their shareholders and invest in another game.
Effectively a game needs to be making 2-3x its initial investment back for it to be successful. Not to mention games development does incur other ongoing costs, such as license for software and music, server costs, support and call centre costs. The more money they game costs, the more you have to pay for its ongoing support, and the more money you need back.
For big AAA studios who are set to release a constant stream of big budget games it works out better for them to invest in their own engine and tools to bring down the ongoing costs that would impact their revenue.
Focus
Third party engines do tend try to accommodate a wide variety of gaming needs and so if your studio specialises in a specific kind of game you may find that a good chunk of a third parties engines functionality isn’t of any use to you.
For example, EA created the Frostbite engine to be specifically catered to first person shooters, primarily to support their Battlefield series. So they don’t need all the extra features that they won’t use. Big AAA studios may also find that they need more functionality than what an out the box engine offers, opting to choose to use other tools for animation, rigging, dialogue and progression.
You may also find that commercial engines don’t run well for your type of game. Normally game engines focus on the processing power of the GPU as the majority of games are streaming in lots of visual assets pushing the GPU to it’s limits, this is why there are so many newer visual technologies being developed like DLSS to help ease that burden.
Strategy games, or games that are simulation heavy are more likely to stress the CPU rather than the GPU and so you often find that strategy games like Civilisation (Firaxis LORE Engine) and Age of Empires (Essence Engine) will make their own engine so they can develop something that focuses on CPU performance.
Commercial Engines
On the flip side you can choose to develop your game using a commercial engine like Unity or Unreal.
The benefits of choosing a commercial engine tend to be the inverse of why you would choose an In-house engine. If you can’t afford or don’t need to invest your own time and money into creating your own engine then you’re more likely to opt for a Commercial engine. They also offer heaps of benefits when it comes to making development easy.
Plug-ins and Compatibility
Both Unreal and Unity come with their own stores filled with assets, scripts, and other vital items that you can easily purchase and plug straight into your game. This vastly speeds up certain aspects of development or prototyping.
Complex systems like dialog management, save states, and asset management are the sorts of things that In-house engines need to fabricate themselves, meanwhile a commercial engine can handle these for you, either natively or via standard extensible protocols that allow you to insert another piece of software.
As time has gone on, these commercial engines have had time to learn and iterate at pace, meaning their tools and services have improved greatly. Unreal Engine’s Blueprint system is an example of a development system that has been tried and tested so many times that Unreal has been able to simplify and standardise it.
Blueprints offers a way of doing system scripting quickly and effectively using a visual node based system and i’ve spoken to a lot of developers who swear by it.
Basically a commercial engine allows you to avoid re-inventing many of the core systems needed to develop and game and with the ability to easily plug-and-play other pre-made assets and systems this can greatly speed up development.
Platform Porting
Another benefit to commercial engines is that they have incorporated the porting protocols into their platform. From Unity you can export to Windows, Playstation, iOS, or Switch, with a click of a button.
They can offer this because they have incorporated, and paid the cost of licensing, the SDK’s of these various platforms into their own tool.
If you are running an in-house or open source engine, you have to do this porting yourself, which involves finishing the product in your engine, then using the target platforms SDK to port over your game. This can be very time consuming and difficult as all sorts of bugs and incompatibilities will arise.
Say you make a multi platform game. A commercial engine affords you the ability to create one game in your engine and the engine will do nearly all the heavy lifting to get an iOS or Xbox version out of it, you may still need to tweak and change things to make it work perfectly but the overhead is lower than doing it manually. On the other hand if you go a different route you will effectively end up making multiple different versions of your game, one for each target system and this can be costly.
For example, Destiny 2 which runs on its own bespoke engine, used to be developed for console by Bungie, but the PC version required an entirely seperate porting team which was done by Vicarious Visions. This was part of their Activision deal. When they separated from Activision Bungie had to bring that porting work inside bungie which was costly in terms of time and resource but took a while to get all the bugs ironed out.
Industry Standard
If a hundred games are made in a year with a commercial system like Unreal, then you have hundreds if not thousands of game development professionals who are familiar with the tool. If you are making a game in Unreal and you need to hire staff, your talent pool is big and enables you to quickly onboard someone.
However, if you have a bespoke in-house engine, unless a potential employee has worked on it before, they come into your studio needing to learn the engine from scratch.
This is becoming a big problem in the industry at the moment as studios with in-house engines struggle to attract talent. One of the reasons Halo developer, 343 Industries, has made the decision to switch to Unreal Engine, was because they struggled to attract talent. In an industry as complex as game development, you want to be attracting individuals who can hit the ground running and offer expertise on alternate ways of doing things. If every new hire has to learn your unique engine they are slower to onboard, and some of their awesome experience may not be applicable because their ideas don’t work in your engine.
Open Source Engines
An open source engine is technically your third option if you don’t want to build an engine yourself or use a commercial engine. However, it’s not really a viable third options for many big budget game companies.
As the name suggests, these engines are open-source, free to use, and that often means they are developed by volunteers or people working for donations.
There are a myriad of open-source engines out there, catering to different needs, niches, and functionalities.
Godot is a popular open-source engine, and my engine of choice, however despite it’s popularity it’s prominently used on personal development projects and smaller indie titles.
This isn’t to say that you can’t make a great game without using Unity / Unreal / or a major in-house engine, but there are many factors that complicate the path to release.
For example, Godot and other engines like it, are missing vital functionality that impede publishing a game. Often, these open source engines, can only distribute to PC platforms. To make a game using Godot and to port it to Switch, Playstation, or even iOS requires additional complicated steps that are very hard to do by yourself and at that point it becomes a lot more attractive to instead just develop your game in Unity or Unreal.
Well that caps off part 1 of this series, stay tuned for the next part where I dive into the nightmare stories of the engine world! Feel free to share with your channels.