The Case for Research in Game Engine Architecture

Eike Falk Anderson∗ Steffen Engel† Leigh McLoughlin‡ Peter Comninos§

Interactive Worlds ARG The National Centre for Computer Animation
Coventry University, UK Bournemouth University, UK

Abstract for writing an engine, but provides little assistance for

designing one when the requirements are different from the
This paper is a call for research in the field of game engine
solution described.
architecture and design, a more comprehensive and thorough
understanding of which we consider to be essential for its
development. We present a number of key aspects that may We believe that there are a number of points that
help to define the problem space and provide a catalogue of should be investigated, with regard to the game engine
questions that we believe identify areas of interest for future development process. In this paper, we are not trying to
investigation. answer the questions that need answers, but we would like
to invite the academic community as well as the game
1 Introduction industry to participate in the discovery of these answers.
The aim of this position paper is therefore to present these
Starting with Spacewar in 1961 [Fleming 2007], computer questions in order to provide a starting point for debate,
games have been around for just over four and a half and to encourage discussion of game engine development
decades. Until about two decades ago, most games were and architecture.
developed by a small team of programmers, if not by
individuals, usually written from scratch with very few
reusable components. In a young industry that is very
much project-based, this does not come as a great surprise; 2 Research Questions
however, as the industry has grown, so has the size of
individual projects. This change has necessitated a number In this section we present a number of questions, focussed on
of advancements in production techniques, and Garlan a range of potential research topics within game and game
and Shaw [Garlan and Shaw 1994] recognised that “one engine development. The questions that we pose can roughly
characterization of progress in programming languages and be categorised into questions of terminology and questions
tools has been regular increases in abstraction level – or of game engine architecture and design. This is in no way
the conceptual size of software designers building blocks”. intended to provide an exhaustive list, or even to examine
A similar increase in abstraction level occurred within the points in all their detail. Instead it is our hope that
computer game development towards the end of the 1980s, we can spark discussions on these and similar topics, and to
when the first systems with reusable components appeared. trigger a more rigorous examination of their effects.
These components are what we would now call game engines. 2.1 Terminology: The lack of a ‘game development’
language.
There appears to be general agreement that game
engines are not only useful, but due to the complexity of The games industry is relatively young, and as such it is
modern computer games, are actually required for game still lacking a common terminology. This is true within
development. Given this, there exists a surprisingly small the games industry itself, and between the industry and
body of literature on game engine design. The available the emerging games-related academia. However, in order
research has mainly focussed on game engine subsystems, to facilitate the rigorous study of any subject, from both a
such as rendering, AI (artificial intelligence) or networking. purely academic and a practical point of view, the ability
However, issues regarding the overall architecture of engines, to communicate effectively is of the utmost importance.
which connects these subsystems, have merely been brushed
over. The absence of a formal terminology results in communi-
cation at cross purposes, as lamented by Stephens [Stephens
This lack of literature and research regarding game 2001], who points out the confusion between ‘game engines’
engine architectures is perplexing. Books on the subject, and ‘rendering engines’, clearly demonstrating the need to
such as that by Eberly [Eberly 2000], tend to only briefly establish a game development language.
describe the high-level architecture before plunging straight
down to the lowest level and describing how the individual We believe that such a language should encompass a defi-
components of the engine are implemented. Often authors nition of game engines and those engines’ components as well
present their own architecture as a de facto solution to as other aspects relating to game development, such as game
their specific problem set, without necessarily justifying genre, a now outdated classification of which was presented
the decision-making processes that led to their designs, by Sawyer [Sawyer 1996]. Regarding the technical aspects
and merely indicating the authors’ personal preferences. of game engine architecture, Folmer’s attempt to establish
Such literature offers an excellent source of information a reference architecture [Folmer 2007] can be viewed as a
step in the right direction. However, these two topics repre-
∗ e-mail: [email protected] sent only a small subset of the subject area and, in addition
† e-mail: [email protected] to further investigation of these areas, additional research is
‡ e-mail: [email protected] required to define the scope of the game development lan-
§ e-mail: [email protected] guage.
2.2 What is a Game Engine: Where is the monality we should start to gain a perspective and a clearer
boundary between game and game engine? definition of what a game engine is, and what components
it should be comprised of.
As mentioned above, there is disagreement about exactly
what a game engine is, with sometimes fundamental
We believe that a formal study of engine design with re-
differences between definitions. Simpson [Simpson 2002]
spect to genre could lead to the definition of a game engine
reports on the confusion between game engines and games
that is independent of genre.
themselves, as well as the erroneous description of game
engines as the game’s component for displaying graphics. 2.3.1 Überengine: Is it possible to define a game engine
independently of genre?
Game engine definitions that are not limited to individual
Currently, game engines are mostly written for specific
engine components are often very broad and vague, such as
game genres. Certain optimisations are required for each,
“a framework comprised of a collection of different tools,
and overheads are introduced when trying to come up with
utilities, and interfaces that hide the low-level details of the
a more generic solution. The ability to use a single game
various tasks that make up a video game” [Sherrod 2007].
engine for any genre of game instead of using a number of
The main issue appears to be the question of where the
genre-specific engines, however, could potentially offer large
boundary lies between the game engine and the game itself.
benefits for the development of games. Apart from financial
savings due to the use of only a single system that would
There are signs that a common consensus may be have to be maintained, such an ‘überengine’ would facil-
emerging for the definition of a game engine, however. More itate the transfer of programmers and artists across projects.
concrete descriptions have been offered, such as that by
Lewis and Jacobson [Lewis and Jacobson 2002] that game
There is as yet no taxonomy of game engines that could
engines are the “collection of modules of simulation code
provide an insight into the commonalities between differ-
that do not directly specify the game’s behaviour (game
ent engines. While superficially many engines appear to
logic) or game’s environment (level data)”. While this
have similar functionality, the question that needs asking
undoubtedly brings us closer to an understanding of the
is if there is something that could be called a game engine
boundary between game engine and game logic, this divide
that caters for games of any genre. In other words, if pre-
is still not clearly defined and many overlaps remain.
sented with two completely different games from different
genres, would a developer recognise the ‘engine’ in each, es-
As a precursor to an investigation of game engines and
pecially considering the wide range of games that include the
their components, research in this area will have to examine
so-called ‘serious games’ which are often simulations of real-
computer games to identify the software components which
world scenarios? We are convinced that it may be possible
are common and unique among different types of games.
to solve this problem, eventually.
This should then lead to the discovery of a clear distinc-
tion between game engine code and game code, helping to 2.4 Design Dependencies: How do low-level issues
establish this boundary. affect top-level design?
2.2.1 Toolsets: Is the toolset part of the game engine? Reference architectures, such as those by Doherty [Doherty
An issue which is becoming increasingly relevant is that of 2003] or Folmer [Folmer 2007] provide descriptions of
the toolset that must accompany a modern engine. Cur- top-level design, but rarely investigate the effect of low-level
rently, artists employed to generate game content use mostly issues on the system architecture as such. It is our belief
off-the-shelf 3D modelling and animation packages, such as that the manner in which low-level issues influence architec-
Maya or 3D Studio Max. These content creation packages tural design is intrinsically linked to the fact that technology
were not, for the most part, designed for the task of creat- changes at a very fast rate. Such technological changes
ing game assets [Blow 2004], and must be augmented by ex- take place at the low-level, in terms of hardware or soft-
porters, world-editors and script-editors that are tailor-made ware interfaces and capabilities, and can directly affect the
for the game engine. Such tools fill the gap between the as- evolution of individual or multiple game engine components.
set generation software and the game engine, and often pro-
vide an interface between artist and programmer. Without For example, a few years ago rendering was achieved
these tools there would be no game. However, an important using a fixed-function pipeline, whereas today we use
question that needs to be answered is if such tools should programmable shaders. Initially, one might assume that
therefore be considered within the scope of the definition of such changes would be limited to within a single game
a game engine? engine module or component. In the case of shaders, this
would obviously be rendering related. However, it is also
2.3 Game Genre: How do different genres affect the possible that functionality can be relocated from one part
design of a game engine? of an engine to another, for example part of an engine’s
The design and definition of a game engine is, currently, physics calculations could be performed by using shaders.
intrinsically linked to that of the game that uses the
engine. The broad subject of computer games can generally Another example is the introduction of multiple pro-
be subdivided into a number of game genres, such as cessors, providing resources which a modern game engine
real-time-strategy (RTS) games or first-person-shooters should take advantage of. The restrictions and requirements
(FPS). Commercially available game engines tend to be of these would result in fundamental changes to a game
more specialised towards the demands faced by games of a engine’s architecture (at some level or other) to transform
particular genre. This allows them to provide genre-specific it into a multi-threaded engine architecture [Tulip et al.
optimisations, but usually at the expense of flexibility. 2006].
While such distinctions across genres often highlight the
differences between approaches, by focusing on the com- It is clear that technology changes affect high-level archi-
tecture, but it has not yet been established to what extent. • The investigation of the effects of low-level issues on
Furthermore, the question must be asked if there are any top-level game engine architecture;
engine design methods that could be employed to minimise
the impact of the future introduction of new developments • The identification of a ‘best practice’ for the develop-
in computer game technology. ment of game engines.

2.5 Best Practice: Are there specific design In this paper we have identified several key aspects that
methods or architectural models that are used, may help to define the problem space of game engine archi-
or should be used, for the creation of a game tecture and design. We have posed a number of questions
that we believe may provide directions for future initiatives
engine? to address. A possible next step would be to set up an ex-
Common sense suggests that top-down design, and bottom- ploratory meeting of interested parties from industry and
up implementation would provide a solution suitable to academia. This could be followed by the setting up of a
the development of game engines. However, this is not committee or working group to coordinate research on this
necessarily how game engines come into being. Empirical topic, a possible end result being the definition of an open
observation suggests that many engines grow and evolve standard for use by all.
over time. The danger with organically grown projects
is that features can spiral out of control, a phenomenon References
known as ‘feature creep’, usually because the original goals Blow, J. 2004. Game development harder than you think.
were poorly defined at the beginning of a project. This ACM Queue 1, 10, 28–37.
has the unfortunate effect that when the implementation
finally meets the original requirements, the goals may have Doherty, M. 2003. A software architecture for games.
changed. The architecture, however, may not be capable University of the Pacific Department of Computer Science
of supporting these new requirements, and workarounds, Research and Project Journal 1, 1.
affectionately called ‘hacks’, must be added. As briefly
mentioned above, a large section of the available literature Eberly, D. H. 2000. 3D Game Engine Design. Morgan
appears to overlook this issue altogether by concentrat- Kaufmann.
ing solely on the implementation of individual engine
Fleming, J., 2007. Down the hyper-spatial tube: Spacewar
components, approaching the subject in terms of micro
and the birth of digital game culture. Available from:
architecture as opposed to macro architecture.
http://www.gamasutra.com.
The question that we ask is whether there is a ‘best prac- Folmer, E. 2007. Component based game development.
tice’ for the development of game engines that can help elim- In Component-Based Software Engineering, vol. 4608 of
inate, or at least reduce, these problems? LNCS, 66–73.
3 Summary of Research Questions Garlan, D., and Shaw, M. 1994. An introduction to
While it is usually simple to attack specific problems, a software architecture. Tech. Rep. CMU/SEI-94-TR-21,
scholarly approach would be to pull back to see the bigger ESC-TR-94-21, Carnegie Mellon University, Pittsburgh,
picture and to identify trends. This abstraction can then PA. CMU Software Engineering Institute.
be used to identify gaps in the knowledge of the field and
to explore ideas that others may have overlooked. Our Lewis, M., and Jacobson, J. 2002. Game engines in
task, as academics, should be to look at designs and find scientific research. Communications of the ACM 45, 1,
commonality, to allow us to try to piece together a ‘better 27–31.
design’. Sawyer, B. 1996. The Ultimate Game Developer’s Source-
book. Coriolis.
The aim of this call for research is to raise academic inter-
est in the field of game engine architecture and design. Our Sherrod, A. 2007. Ultimate 3D Game Engine Design &
research agenda could therefore be defined as: Architecture. Charles River Media.
• The establishment of a unified language of game devel- Simpson, J., 2002. Game engine anatomy 101. Available
opment; from: http://www.extremetech.com.

• The identification of software components that are com- Stephens, N., 2001. “game engine” versus “rendering en-
mon to all types of computer games; gine”. Letters to the Editor, http://www.gamasutra.com.

• The establishment of clear boundaries between game Tulip, J., Bekkema, J., and Nesbitt, K. 2006. Multi-
engine (code) and game code; threaded game engine design. In Proceedings of the 3rd
Australasian Conference on Interactive Entertainment, 9–
• The definition of the role of content creation tools in the 14.
game development process and as part of game engines;

• The identification of links between game genres and

game engine architecture;

• The identification of components that are common to

all types of game engine, allowing the definition of a
genre-independent reference architecture;