The Complexity Of Game Engines

The Complexity Of Game Engines‍‍

The recent pricing changes from Unity have brought to focus how crucial game engines are to the developer community (Unity). Immediately after the announcement, developers came out condemning the changes and boycotting the platform (mobilegamer). Unity eventually walked back some of the price increases, but the damage to developer trust was already done. The frustration around the change was largely uniform through the game developer community; however, the path forward for Unity remains heavily debated and contested. Many pointed developers to use alternatives such as Unreal or Godot, others suggested that creating their own engine was a better option (a path usually only trodden by large AAA studios), and many determined Unity was still the best option in the market. In this newsletter, we wanted to take this chance to break down what a game engine is, why the decision to switch engines is so complex, and if there is an opportunity for new entrants in the engine space.

What is a Game Engine?

The definition of game engines tends to be ambiguous, but it typically encapsulates all the tools required to get from game idea generation to game distribution. This view oversimplifies an engine and can make conversations around specific features and tools ambiguous and confusing. In The Taxonomy of Game Engines, a framework is provided to segment all of the tools focused on game production (exclusive of project planning, testing, marketing, etc.). An illustrative example of a game production toolset is shown below with the dotted lines intended to emphasize the degree of plasticity of the system:

• Product-facing tools: These are the tools that are composed of data structures and algorithms (rendering, physics and AI). Examples include Unreal Engines' newly released Nanite Virtualized Geometry and Luman Global Illumination, which radically change the way that games are rendered to allow for higher quality assets and more dynamic lighting (Logic Simplified).
• User-facing tools: These tools are user interfaces that developers use to create code or assets to put into the engine. Examples include Aesprite for 2D pixel art or Visual Studio Code for a more streamlined programming experience.
• Tool-facing tools: These tools create bridges between different tools in the production pipeline or add functionality. Examples include Oodle for data compression or Dolby digital for audio compression.

Game engines are a package of different tools and are often heavily supplemented by an array of other 1st and 3rd party tools. A game engine is not a singular software, rather an amalgamation of different software coming together in a fluid package.

Why Is The Decision To Switch So Complex?

A typical engine will include a set of core features like a window (to display your game), user input (allows the developer to interact), asset management (to manage images or models) and scripting (to quickly add functionality to these assets), among other things, but these features are highly modular depending on the specific requirements of the engine. Exactly which tools the game engine is composed of changes from engine to engine. Let’s look at an example of a user-facing tool and a product-facing tool and how they vary between the two most popular engines, Unreal and Unity.

• User-facing Tool: 2D Sprite Editor
• ~Unity: A very simple example of a user-facing tool is a 2D sprite editor, which is a program that takes static pictures and helps animate them to be used in your game. Unity has a sprite editor that is built directly into the game engine allowing users to easily animate their images right out of the box.
• ~Unreal: A similar solution for Unreal requires a 1st-party plugin. And if you think that their solution is too bare bones, you can also use a 3rd party plugin to extend its functionality. But it is not as simple as downloading any of the plugins. Each adjustment adds a layer of complexity. For example after you download the 1st-party plugin, settings must be adjusted to ensure the pictures are being pulled in using a 2D rendering technique as opposed to the 3D setting that Unreal defaults to. If a 3rd-party plugin is introduced, you run the risk of bugs or crashes that you do not know how to fix (Unreal Engine).‍

• Product-facing Tool: Rendering Pipeline
• ~Unity: An example of a product-facing tool would be a rendering pipeline, which is the framework that the computer uses to create visual images of objects. Unity’s rendering pipeline defaults to minimum render complexity to help the game scale down to less powerful GPUs. This is one of the reasons that Unity has such significant market share in mobile (Unity). However, any additional features that a game developer might require must be “built up” into the engine directly or indirectly.‍
• ~Unreal: Unreal defaults toward high end graphics, in contrast to Unity, Unreal requires users to navigate through settings and turn off a multitude of default options to reduce processing requirements for games. This requires extensive knowledge of the underlying programs and can come with tradeoffs.

Differences in core functionality can very quickly amplify the degree of complexity a project has to face. Compound this complex decision making by thousands of features, integrations, and tools, and the choice of which engine to use and when to switch becomes so specific to the company, game and target audience.

We believe this degree of complexity, and ultimately compromise, is why many AAA studios choose to make their own engine. They not only eliminate any fees associated with their engine, but gain the ability to craft each component, fine tune features and avoid excess baggage associated with tools that are not required.

What Are The Opportunities In The Space?

The complexity of game engines makes them sticky for many users, and new entrants have had a difficult time taking market share. Not only do new entrants have to bear the up-front cost of building an engine, but they are forced to overcome the network effects of incumbents. Incremental users to a game engine benefit the platform by contributing plugins, providing updated documentation or even answering questions on forums. To solve for this and rapidly drive adoption, a new engine would significantly benefit from public validation in the same way that Unreal Engine was marketed and fine tuned through Fortnite.

It will be  difficult for new entrants to break into the existing duopoly of engines. GameMaker is largely a hobbyist engine and Godot, while promising, is struggling to pull mature developers onto the platform (Gamalytic). However, one potential approach to entering this market would be to create a new engine that caters to a very unique style of experience. For example, Frostbite Engine was originally created alongside Battlefield, allowing for multiplayer battlegrounds and dynamic destructible environments in ways that had not been achieved on other engines (EA).

Takeaway: Because engines are complex amalgamations of specialized tech and the learning curve for developing on them is so high, it is difficult for new entrants to gain meaningful market share. We believe upstart engines that want mass appeal have a couple of narrow paths to success: 1) focusing on new distribution platforms or 2) building a flywheel on successful 1st party content. New distribution platforms (non PC, console, or mobile), such as virtual reality or cloud gaming, offer the chance for new entrants to leapfrog incumbents and offer a significantly better development suite and featureset for the target platform. The window for this innovation is likely small given that large tech companies will build new engines in house (i.e. Reality Kit for the Vision Pro) with Unity and Unreal providing alternate rendering engines for the masses over time. However, for a nimble, aggressive start-up, the emergence of new interactive experiences and new technology may provide a window for rapid innovation.