Talking About Game Engines and Production Tools

This blog post is based on the research paper “A Taxonomy of Game Engines and the Tools that Drive the Industry” by Marcus Toftedahl and Henrik Engström, game production researchers at the division of Game Development, University of Skövde, Sweden.

To create a game, you need a game engine - right? In everyday game development language game engines are the software that is used to create a game, but in reality there are so much more involved than just a single piece of software. During the last few years, the University of Skövde has focused on doing industry close research in the game development field, focusing on challenges when creating games. As a part of this work, we have encountered a number of stories where the term “game engine” is problematic, both for developers and consumers. Let’s take some examples of this.

In an article published by Kotaku, it is reported about the backlash from fans regarding Fallout ’76 from Bethesda. Upon release, the game was receiving negative feedback from the player community regarding bugs and performance issues, and questions were raised about the “game engine” used in the game. Fans complained that the engine used in the game would not be on par with game engines used in other games released at the time. Kotaku describes how a spokesperson from Bethesda is explaining that they will continue to use their tools even in forthcoming games and they are happy with the tech used. The Bethesda spokesperson continue stating that their tools are allowing the developers to create content quickly and that they have implemented a new renderer as a part of the tool set used. Even though the term “game engine” was not mentioned by the spokesperson in the statement, there was a community backlash stating that their “game engine” was outdated. Kotaku points out that the critics (or “fans”) did not grasp the complexity of a game production with its multitude of tools and competences. The Kotaku article concludes that “An engine isn’t a single program or piece of technology—it’s a collection of software and tools that are changing constantly”.

This example is a case where the need of a uniform “game language” in a wide context apparent. While it is understandably difficult for players (or at least non-developers) to grasp the game development processes and the professional language connected to game development, we have found examples derived from developer settings as well.

Eurogamer reports about the problems that Starbreeze encountered while developing Overkill’s The Walking Dead. The Eurogamer article states that the management of Starbreeze focused a lot of resources to buy and subsequently further develop an in-house engine, Valhalla, with the intention to use it in all forthcoming Starbreeze games. Developers interviewed in the Eurogamer article state that the Valhalla game engine was essentially only a graphics renderer with no tools attached to it: “It was just not good. Like most engines, it had good potential, but it wasn't in a good place for people to properly develop a game. That was the problem. It was just way too far behind in the pipeline” a developer stated. On a later stage, Starbreeze management decided that the Valhalla engine should be replaced with another game engine -  Unreal. But, since the decision came late in the development process a lot of work had to be redone due to the switch of main production tools.

Just to switch the game engine to improve on the quality of the game might seem like a viable solution, just as you might consider switching any other software for another. Maya is not working for you? Try 3DS Max instead. In reality, seen from a production perspective such a change of “game engine” technology impacts a lot more.

Our final example is taken from our own practice as educators of game developers. We have observed that students and inexperienced developers expects game engines, such as Unity and Unreal, to encapsulate all components needed to develop games. The need to develop additional tools is something that is frequently ignored. This limits the creativity and productivity of those teams. Maslow's hammer applies also in this context: if all you have is a hammer, everything looks like a nail. More experienced developers shift focus from the engine to the production pipeline and invest time to develop integration between tools and also to develop custom tools to give specific support of the creative process for the game they develop. For example, by developing custom level editors. This will turn the hammer into something more appropriate. 

GAME PRODUCTION TOOLS AND GAME ENGINES

We would argue that the phrase game engine has been used for a very wide range of concepts (and tools) related to game development. It has been used to represents all tools used to produce games. It has even been used to describe the core runtime of a compiled game in some cases. This confusion in terminology has been proven to be problematic, and the articles quoted above are some examples of this. To avoid confusion in the future, we propose a more nuanced taxonomy for tools in game production that focus on the characteristic functions in the multitude of tools used. We do not propose that the term “game engine” should not be used – it is widely used and thus nigh on impossible to replace. We argue that the term should be more carefully pinpointed and position towards related concepts such as game production tools and the production pipeline.

The game production pipeline is the core of the production of a game where professionals from various disciplines create content that is assembled and combined into a game that can be executed on a target platform. A “game engine” is  a part of this pipeline, but there are many additional components needed for an efficient game production. The production pipeline can be thought of as a factory assembly line, where many components are assembled by people with different roles and work task with tools relevant to their specific work task.

In the first step of introducing our taxonomy we want to make a distinction between tools. Tools that are part of the production pipeline (pipeline tools) and those that are not (non-pipeline tools). The non-pipeline tools are used for other processes involved in game production such as project planning, testing, marketing etc. For the pipeline tools we propose a distinction between three different tool types:

Using the above taxonomy, we propose that different types of game engines are classified according to the following:

Note that with these definitions, a core engine is a game engine without any user facing tools, except a programmers API for expanding and connecting the core engine to other parts of the pipeline. This was the first type of engines, e.g. the first iterations of id Tech, which were provided as programming libraries. With our taxonomy, we can also include all current common game engines, something that is of great importance due to the common use of the game engine term. 

THE PRODUCTION PIPELINE

With these definitions of tools and game engines, we can now move on to defining the production pipeline. We argue that the focus need to be shifted from game engines to the production pipeline. The production pipeline of a game development project contains a game engine and an arbitrary number of additional pipeline tools.

An archetypal characteristic of a game production pipeline is its plasticity – tools can be altered or added depending on the type of game being produced. This can, for example, be to create a design tool that enables modeling of the game levels of a particular game. Some of the tools used have this plasticity included in their native design. In other cases new tools are created. As an example, Unity has inherent functionality to create custom inspectors and panels for the various game components created. It also has support for different types of plugin extensions from third party software through its asset store. Note that in the figure above the game engine is drawn with a dashed line indicating this plasticity. The border between the game engine and other tools in the production pipeline is not of any major importance. As long as the integration of the different tools is handled, they can be located inside the engine or outside.

For complexity reasons, a game engine is not likely to include the whole production pipeline. Only games developed in small teams in special purpose engines can handle the whole pipeline in a single application (for instance GameMaker). Even Unity that includes a lot of user facing tools, e.g. for animation and audio processing, depends on external tools such as Visual Studio for script editing. 
It should be noted that this taxonomy is an abstraction and that a real production can include more complex interconnections. The same modules can for example be shared between tools. Tools outside the production pipeline can depend on objects in the production pipeline, e.g. analytics tools have components in game binaries; planning tools relate to production entities, etc. It is also possible that the same tool, e.g. Photoshop, is used in both the production pipeline (to create textures) and in the non-production pipeline (to create promotion material).

Our approach to nuance the use of the “game engine” term and put it into a broader perspective will hopefully help to avoid, or at least minimize the risk of, confusion in the future – at least in a production setting. 

This blog post is based on the research paper “A Taxonomy of Game Engines and the Tools that Drive the Industry” by Marcus Toftedahl and Henrik Engström, game production researchers at the division of Game Development at the University of Skövde - a part of Sweden Game Arena. Illustrations by Rebecka Thor, University of Skövde. The paper was presented at Digital Game Research Association (DiGRA) Conference 2019 in Kyoto, Japan as a part of the Gamehub Scandinavia research project.