1.2. INTRODUCTIONTO GAME ENGINES
Introduction to game engines and an overview of architecture
Definition and features of a game engine
Definition of a game engine
A game engine is “a piece of software designed for the creation and
development of video games”. It offers a number of components and/or
tools which can be (re)used to economise game development.
Core functionality typically provided by a game engine includes:
•
•
•
•
•
•
•
•
•
•
•
•
rendering engine (2D/ 3D)
scene graph
collision detection (and response)
physics engine
scripting
animation
artificial intelligence
sound
networking
streaming
memory management
threading
Definition of a game engine
Game engines may also
provide development
tools and/or an
integrated development
environment to aid
developers.
Some game engines only provide real-time 3D
rendering capabilities (providing attachment
hooks for the other types of needed game
functionality). Such engines are generally referred
to as a graphics engine or rendering engine.
Platform and Hardware Abstraction
Many game engines provide platform abstraction (i.e. they can be run multiple
platforms – including PCs, consoles, handhelds, mobile devices, etc.).
Typically the rendering system in a game engine is built on top of a defined
graphics API (e.g. Direct3D or OpenGL) providing access to the GPU.
Other libraries such as DirectX, OpenAL, etc. may also be supported to provide
hardware-independent access to input devices, sound cards, network cards,
physics accelerators, etc.
Component-based Architectures
Extensibility within a game engine is important given the diverse and
progressive nature of game development. As such, many game engines
adopt a component-based architecture, permitting engine components to
be replaced or extended (either by the developer or using specialised
middleware components).
Common middleware components include: Havok (physics), FMOD (sound),
Scaleform GFx (UI), SpeedTree (trees/vegetation), Bink (video), Granny 3D
(content/animation), etc.
Development History
Early games were typically bespoke and
designed/developed from the ground up for a
particular game with little/no reuse between
games. This was often necessitated by the
need to maximise performance given limited
hardware capability.
The game engine largely emerged in the mid1990s from FPS games. The popularity of ID’s
Doom and Quake entailed that other
developers licensed core portions and added
their own game assets and content. Later
games, i.e. ID’s Quake III or Epic’s Unreal were
design with reuse in mind (i.e. engine and
content were cleanly separated).
Example game engines
•
Unreal Engine (Epic Games)
•
Source Engine (Valve Corporation)
•
Gamebryo Engine (Emergent Game Technologies)
•
id Tech 5 (id Software)
•
CryEngine (Crytek)
Video not available in on-line slides
Overview of Typical Game Engine Architecture
Game Engine Architecture
The is no archetypal game engine architecture design, although, many
games engines will offer certain forms of functionality, or define common
types of component.
Game Specific Subsystems
Gameplay Foundations
Rendering engine
Front-end
Animation
Human Interface
Devices
Visual Effects
Audio
Scene Graph / Culling
Collision and Physics
Networking
Renderer
Resource Management and Game Assets
Core Support and Utility Systems
Platform Independence Layer
SDKs / Drivers / OS
Hardware
Hardware
Hardware
The target hardware layer on which the game will run. A game engine may
be capable of running on top of a number of hardware layers.
SDKs/Drivers/OS
SDKs / Drivers / OS
Typically some means of communicating with the underlying hardware is
needed. This can be accomplished using either device drivers or through
APIs exposed by the OS.
In some cases, e.g. PCs, the OS strongly controls execution of the game
engine (which is one executing process amongst many).
Most game engines use 3rd party SDKs to provide access to:
•
Ready made data-structures and algorithms (e.g. STL or Boost in C++)
•
Graphics hardware (e.g. DirectX or OpenGL)
•
Collision detection and Physics (e.g. Havok, PhysX or ODE)
•
etc.
Platform Independence
Platform Independence Layer
Game engines which can run across multiple platforms often provide an
abstraction layer hiding platform specific differences from higher-level
layers.
The platform independence layer assures that standard data types,
libraries, fundamental APIs, etc. offer consistent behaviour across the
different supported platforms.
Supported abstractions can include:
Platform Independence Layer
Atomic
Data Types
Collections
and Iterators
File
System
Network
Transport Layer
Threading
Library
Graphics
Wrappers
Core Systems
Core Support and Utility Systems
In order to function game engines typically depend upon underlying utility
and support classes. Depending upon the game engine, this might include:
Core Support and Utility Systems
Memory
Allocation
Assertions
Math
Library
Debug Printing
and Logging
Localization
Services
Profiling / Stats
Gathering
Random
Number
Generator
Parsers
Movie
Player
Network
Transport Layer
RTTI /
Reflection &
Serialization
Asynchronous
File I/O
Game Assets
Resource Management and Game Assets
The resource manager provides a unified means of accessing the different
types of game asset and other engine input data, including but not
necessarily limited to model meshes, textures, fonts, skeletal animation
data, game/world maps, etc.
The rendering engine within a game engine
tends to be a large and complex component
which is often decomposed into separate
layers
Rendering engine
Rendering Engine
Front-end
Visual Effects
Renderer
Renderer
Renderer
This component encapsulates all the raw rendering facilities of the engine,
providing a means of rendering a collection of geometric primitives as
quickly as possible.
Supported geometric primitives may include triangle meshes, line lists,
point lists, particles, etc.
This component typically accesses
the graphics device interface
(possibly through a defined
platform independence layer) and
acts to configure the hardware
state and game shaders using some
defined material system and
dynamic lighting system.
Scene Graph / Culling
It is the job of the scene graph to
limit the number of geometric
primitives sent to the renderer
based on some form of visibility
determination.
Typically some form of world
spatial decomposition (bsp tree,
bounding volume hierarchy, etc.)
is employed to build a set of
potentially visible objects.
Scene Graph / Culling
Visual Effects
The rendering engine might provide support for
the following types of visual effect:
•
Particle effects
•
Decal system
•
Dynamic shadows
•
Light/environmental mapping
•
Full-screen post render effects
(e.g. HDR, FSAA, colour correction, etc.).
Visual Effects
Front End
A front end component provides a
means of rendering 2D graphics
(possibly overlaid on top of a 3D
scene), providing:
• Game front end and menus
• In game Head-up-display (HUD)
• In game graphical user interface
(e.g. for inventory screens, etc.)
• Debugging and other tools (e.g.
console)
Front-end
Collisions and Physics
Collision and Physics
Whilst collision detection and a real-time dynamics simulator can be
separate entities, they are often found together given the
interdependence of physics on collision detection. Given the complexity
of both areas, most engines rely upon a 3rd party SDK (e.g. Havok, etc.).
A collision detection system is often of use within a wide range of nonphysics related component.
Animation
Animation
Most current game engines support skeletal
animation, permitting a mesh to be posed
using a system of bones. Poses are typically
interpolated or combined to produce a
palette of matrices used to render the mesh
parts (a process known as skinning).
Animation
Animation
State Trees
Inverse
Kinematics
LERP and
additive
blending
Animation
Playback
Sub-skeletal
Animation
Animation
Decompression
Human Interface Devices
Human Interface
Devices
Games often support a number of different forms of player interface
device, including:
• Keyboard and Mouse
• Gamepad
• Specialised Controllers (e.g. Wii Fit
Board, dance pads, steering wheels).
It is often the role of this component to
abstract the mapping of physical controls
and logical game functions. The
component may also embed support for
detecting multiple simultaneous button
presses and/or input sequences, etc.
Audio
Audio
The sophistication of audio engines between different game engines
differs considerably. More advanced audio engines offer wide support for
different input sound formats, including streaming, and output speaker
arrangements.
Additionally, different forms of playback support, including audio effects,
may also be supported.
Networking
Game engines typically
provide support permitting
multiple computers/
consoles to be linked
together in some form of
mutli-player game. This is a
different environment to
massively multiplayer
online games (MMOGs)
where thousands of players
are typically managed using
a server farm.
Networking
Networking
Match-making
and Game
Magagement
Object
Authority
Policy
Game State
Replication
Gameplay Foundations
Gameplay Foundations
Gameplay refers to the actions which take place within the game.
Gameplay is either implemented using the same language as that used to
create the underlying game engine, or through a higher-level scripting
language, or some combination of both.
The gameplay foundations layer offers utilities of use to gameplay
formation and a means of readily accessing some of the lower-level engine
components.
Gameplay Foundations
High-level Game Flow System
Scripting System
Game World
Dynamic Game
Objects
Static World
Elements
Event/
Messaging
System
Gameplay Foundations
Gameplay Foundations
Game World
The gameplay foundations layer may define the game world structure in
terms of both static (e.g. background geometry) and dynamic objects (e.g.
NPCs, rigid bodies subject to physics).
Event / Messaging System
In order to permit game objects to communicate and interact an event
based messaging system is often employed.
Gameplay Foundations
Gameplay Foundations
Scripting System
A scripting system may be employed in order to provide more rapid,
accessible and convenient development of gameplay rules and content.
Typically using an interpreted scripting language avoids the need to
rebuild the code base given a gameplay change.
High-Level Game Flow System
High-level control mechanisms, such as finite-state machines, etc. may be
embedded within the gameplay foundations layer and made avaiable to
the game specific sub-systems.
Video not available in on-line slides
Game Engine Tools and the Asset Pipeline
Video not available in on-line slides
Tools and the Asset Pipeline
Game engines consume a lot of data in order to construct and play a
game, including game assets, configuration files, scripts, etc:
Sound
Bank
Textures
Animation
Tree
Skeletal
Hierarchy
Particle
System
Mesh
Asset
Conditioning
Pipeline
World Editor
Content Creation Tools
The graphical and aural assets used within a game are typically created
using various digital content creation tools. Some examples of common
tools include:
•
Autodesk Maya (models and animation)
•
3ds Max (models and animation)
•
Adobe Photoshop (textures)
•
SoundForge (audio)
Asset Conditioning Pipeline
Whilst content creation tools can export data in different formats, such
output often needs to be ‘conditioned’ before being usable within a game
engine. This is typically done if the content creation tool exports data that:
• Contains more information than is needed,
or structures the information in
inconvenient manner.
• Is stored in a file format that is either closed
proprietary or cannot be read sufficiently
quickly at run time.
A game engine which targets multiple
platforms may also wish to store assets in a
common game engine format suitable for
deployment across multiple platforms.
Video not available in on-line slides
Directed reading on game engine architecture
Directed reading
• More information on an overview of game engine
architecture can be found on pages 5-55 of Game
Engine Architecture.
• Information on basic software engineering for
games can be found on pages 91-135 of Game
Engine Architecture
• Highly recommended: Information on means of
representing and updating game objects (dynamic
and static) within a game engine can be found
pages 687-793 of Game Engine Architecture
Summary
Today we
explored:
 What is a
game engine
 The types of
core
components
found within a
game engine
 The tools and
asset pipeline
which feed
into a game
engine