1 . 2. Introduction to Game Engines

1. 1.2.Introduction to Game Engines Introduction to game engines and an overview of architecture

2. Introduction to Game Engines Definition and features of a game engine

3. 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

4. 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.

5. 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.

6. 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), ScaleformGFx (UI), SpeedTree (trees/vegetation), Bink (video), Granny 3D (content/animation), etc.

7. 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 mid-1990s 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).

8. Example game engines Unreal Engine (Epic Games) Source Engine (Valve Corporation) Gamebryo Engine (Emergent Game Technologies) id Tech 5 (id Software) CryEngine (Crytek)

9. Video not available in on-line slides

10. Game Engine Architecture Overview of Typical Game Engine Architecture

11. 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.

12. Rendering engine

13. 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.

14. 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.

15. Platform Independence 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:

16. Core Systems In order to function game engines typically depend upon underlying utility and support classes. Depending upon the game engine, this might include:

17. 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.

18. Rendering Engine Rendering engine The rendering engine within a game engine tends to be a large and complex component which is often decomposed into separate layers

19. 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.

20. 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.

21. 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.).

22. 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)

23. Collisions 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 non-physics related component.

24. 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).

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. Video not available in on-line slides

32. Tools and The Asset Pipeline Game Engine Tools and the Asset Pipeline

33. Video not available in on-line slides

34. 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:

35. 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)

36. 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.

37. Video not available in on-line slides

38. Directed reading Directed Reading Directed reading on game engine architecture

39. 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 Directed reading

40. 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 To do: • Read the recommended directed reading • Identify aspects of the game engine which you find particularly interesting