System Architectures Game Engine Architecture: Basics and History - - PowerPoint PPT Presentation

System Architectures Game Engine Architecture: Basics and History

Jonathan Thaler

Department of Computer Science

1 / 59

Introduction

Remember the Driving Forces of Architectural Design ...

• 4. Driving Force

Particular efficiency requirements may lead to suitable software architectures: For example: Performance. Ease of modelling effort (process-oriented modelling versus event-oriented, visual modelling, ...)

2 / 59

Introduction Unreal Engine 5

https://www.youtube.com/watch?v=Oa2drgVThbs

3 / 59

Game Engine Architecture

Definition Game Engine Architectures are an architectural style which allow to implement soft real-time interactive agent-based computer simulations. The main architectural driving force of Game Engine Architectures is conveying experience of how to build software with very strict performance require- ments.

4 / 59

Game Engine Architecture

The focus of a Game Engine Architecture is on performance as games in general perform a massive amount of numerical computations to achieve high visual fidelity. The essence of game engines is built around a main loop, which executes as fast as possible, with the aim of not dropping below 30 iterations per second. In general, this is not a hard constraint, cannot be guaranteed and depends on the hardware and computational complexity of the game, therefore we refer to games as soft real-time. In the main loop various subsystems are executed, implementing various features required by every game.

5 / 59

Game Engine Architecture

Game Engine Subsystems: Rendering Audio and sound Physics AI Animations Input Data Streaming Networking Scripting Game Object Management

6 / 59

Game Engine Architecture

Rendering Subsystem Responsible for displaying the graphics on the screen in either 2D or 3D. It is generally the most computationally heavy subsystem, therefore getting dedicated support from rendering hardware such as GPUs. There exists various graphics APIs such as Direct3D, OpenGL and Vulkan which provide a standardised interface for accessing rendering hardware, allowing to implement platform-independent rendering subsystems.

7 / 59

Game Engine Architecture

Audio and Sound Subsystem Plays in-game background music and sounds, triggered by certain events and influenced by the physics of the environment e.g. a cave or the doppler effect by moving sound sources. There exists also deditcated hardware for this, which can be also programmed through open and standardised interfaces such as OpenAL and FMOD.

8 / 59

Game Engine Architecture

Physics Subsystem Performs collision detection and computes realistic movement of rigid bodies, cloths, ropes and other elastic materials. This subsystem can be also quite computationally heavy and has traditionally been computed on the CPU. In the mid 2000s dedicated physics hardware emerged, which then eventually got integrated into the more general GPGPUs, therefore in modern game engines GPUs also perform physics calculations along- side the CPU. When physical accuracy is paramount, such as in racing games, the physics sim- ulation is executed in a separate thread with for example 100Hz or above, to achieve a higher update rate and not be limited by rendering performance.

9 / 59

Game Engine Architecture

AI Subsystem Responsible for implementing various low- and high-level AI functionality such as path finding and environment scanning (low-level) or tactical behaviour (high-level). The computations of this subsystem are generally executed on the CPU.

10 / 59

Game Engine Architecture

Animations Subsystem Required by every game, whether it is 2D or 3D. 2D animations are achieved by sprites, which are simply a number of images displayed over time. 3D animations are much more computationally heavy and complex as they are generally implemented using sekeletal animation, requiring the interaction of many transformation matrices and interpolation of many values over time. 3D animation is therefore executed to a great extent on the GPU.

11 / 59

Game Engine Architecture

Input Subsystem Capture input from the user from various devices such as mouse, keyboard, joystick or more advanced system such as Wii controllers. To achieve high performance buffered input is used where instead of waiting blocking for the input, the OS or the input library buffers input between frames which can then be queried in the next frame without delay.

12 / 59

Game Engine Architecture

Data Streaming Subsystem Deals with the streaming of data from the harddisk / optical disc into the game. As modern games have content that goes far beyond what fits into the main memory of standard hardware, it is necessary to stream data in the background and load/unload parts of a level seamleassly.

13 / 59

Game Engine Architecture

Networking Subsystem Is an important subsystem to implement multiplayer functionality. There exist a number of different approaches how to program multiplayer games, and which to choose depends very much on the genre of the game.

14 / 59

Game Engine Architecture

Scripting Subsystem Allows to implement game functionality such as triggering events upon some player action using a high level scripting language such as Lua, Python or even JavaScript. This allows for quick prototyping and faster development as there is no need to customise existing classes and recompile the whole engine.

15 / 59

Game Engine Architecture

Game Object Management Subsystem Responsible for providing certain classes of game objects, such as vehicle, NPC,

• door. Manages their relationships and interactions.

This is basically the domain layer of traditional monolithic layered architectures, however in game engine middlewares they have to be quite general to support a broad range of games (for the specific genre).

16 / 59

Game Engine Architecture

Game engines are built in layers

Figure: Runtime game engine architecture

17 / 59

Game Engine Architecture

18 / 59

Game Engine Architecture

19 / 59

Game Engine Architecture

20 / 59

Game Engine Architecture

Implementing Game Engines Practically all modern game engines are written in C++. C++ is a modern object-oriented programming language with a rich featur set, allowing low-level memory management, following a policy of zero run-time overhead for features. This makes it possible to write extremely performant code while still having the benefits of object-oriented programming. Having high performance is of fundamental importance in games for

• bvious reasons.

Object-oriented programming is clearly the programming paradigm best suited to game engines in particular and computer simulations in general.

21 / 59

Game Engine Architecture

Implementing Game Engines Game engine developers pick a standard which suits them and then stick to it for at least one generation of their engine. Also, game engine studios deliber- ately restrict themselves to a specific subset of C++ and avoid usage of more problematic features: Exceptions cause overhead. Certain variants of automatic memory management as games need to be in full control over memory. Extensive use of template metaprogramming as code tends to become non-portable and very difficult to understand. The use of the STL and containers due to memory management (STL has a lot of memory overhead).

22 / 59

Game Engine Architecture

Implementing Game Engines Ideally a game engine is platform independent, by following a component-based architecture, allowing for abstracting the subsystems into interfaces, providing different implementations for them and by programming a specific subsystem against standard APIs. How can we arrive at a maintainable software architecture with high cohesion and low coupline and achieve required performance? How much performance are we willing to sacrifice for a higher software quality such as high cohesion, low coupling, leading to better maintainability and higher productivity?

23 / 59

Game Engine Architecture

Implementing Game Engines A game engine should be customisable and extensible and applicable to a wide range of games but it is unlikely a that an engine will be applicable to all kind

• f genres.

aFor example the Unreal Engine is generally used in 1st and 3rd person 3D games such as

Fortnite, Unreal,... and it is rather unlikely that we will see its use in real-time strategy such as Star Craft or in MOBA such as Dota 2 (interstingly Dota 2 uses the Source Engine ;)).

24 / 59

Game Engine Architecture Game Engine Architecture

In this course we will ignore specific implementation details of various subsystems and primarily focus on the ”glue” which holds them together which is the game engine

• architecture. More specifically we are discussing how the main loop is implemented,

how subsystems interact, how game object management works.

25 / 59

Introduction A short and opinionated 1 History of Game Engines.

How did we end up with Unreal Engine 5?

1Let me know if you think I missed an important (your favourite) game. 26 / 59

Introduction CPU-only, until 1996

27 / 59

History of Game Engines

1993: Doom I

Figure: Doom is considered to be one of the most significant games in video game history and is frequently cited to be one of the greatest games of all time.

28 / 59

History of Game Engines

1994: Doom II

Figure: Doom pioneered impressive 3D graphics, multiplayer gaming and modding.

29 / 59

History of Game Engines

Doom facts: Programmed in C with some assembly for performance-critical sections. Target hardware was 486 Intel CPUs running at 33MHz with around 4-8 MByte

• f RAM.

The game was a 2.5 dimensional engine as it was not possible to look up or down, nor were there any multi-level structures or sloped areas. This would have required a perspective divide for each of the pixels rendered on

• screen. This would have been prohibitively expensive in those days as floating

point operations were very expensive on these early CPUs. Doom I was built on id Tech 1 which can be seen as the world first widely used middleware game engine and it was this game from which the term game engine

• arose. The game engine was released under open source 2

2https://github.com/id-Software/DOOM 30 / 59

History of Game Engines

1996: Duke Nukem 3D

Figure: Duke Nukem 3D originated the Build Engine, another engine with a lot of impact.

31 / 59

History of Game Engines Graphics cards emerge (from 1996)

32 / 59

History of Game Engines

1996: Quake I

Figure: Quake I was the first true 3D game.

33 / 59

History of Game Engines

1997: Quake II

Figure: Quake II had support for OpenGL.

34 / 59

History of Game Engines

Quake facts Quake I was the first true 3D game, using innovative rendering technology. Quake I ran on a software rasteriser, with a patch it was able to use dedicated graphics cards which started to emerge at that time. Quake introduced its own scripting language Quake C for more flexibility in development and content generation. Quake II had also out-of-the-box support for hardware-accelarted graphics using OpenGL. Quake I 3 and Quake II 4 were released under open source.

3https://github.com/id-Software/Quake 4https://github.com/id-Software/Quake-2 35 / 59

History of Game Engines

1998: Unreal I

Figure: Unreal 1 set new standards in regards of graphics quality.

36 / 59

History of Game Engines

Unreal facts It is the originator of the Unreal Engine family, which is one of the most important and influential game engine middleware of today. It was programmed in C++ and still had a software renderer but needed an SLI system of two 3dfx Voodoo2 graphics cards to run on maximum quality. Unreal came with a powerful scripting language UnrealScript, which allowed for quick and flexible modding of the game.

37 / 59

History of Game Engines

Towards GPUs (from 1999)

Games from 1999 onwards marked the departure from software rendering, towards consequential use of graphics cards which started to evolve towards GPUs. The difference between a graphics card and GPU is rather blurry and the term was first coined by NVidia in 1999 with the advent of the GeForce 256. The main innovation was that geomtery transform and lighting operations could be done now on the graphics card, capable of rendering 10 million ploygons per second 5. Also the GeForce 256 came with hardware accelerated texture combiners, allowing for unseen effects.

5Modern GPUs of 2020 are capable of rendering 20 million polygons per frame. Assuming 60 FPS,

the difference amounts to a mind-boggling increase of geometric complexity of a factor of up to 1,200!!!

38 / 59

History of Game Engines

1999: Quake III Arena

Figure: Quake III Arena uses the id Tech 3 engine, implemented in C.

39 / 59

History of Game Engines

1999: Unreal Tournament

Figure: Unreal Tournament uses the Unreal Engine 1

40 / 59

History of Game Engines

Figure: The family tree of Quake engines.

41 / 59

History of Game Engines

Fast Inverse Square Root Quake III Quake III Arena was released under open source a. Special attention got the function for computing the fast inverse quare root, required to calculate a nor- malised vector, fundamentally important in the renderers lighting computations.

float Q_rsqrt( float number ) { long i; float x2, y; const float threehalfs = 1.5F; x2 = number * 0.5F; y = number; i = * ( long * ) &y; // evil floating point bit level hacking i = 0x5f3759df - ( i >> 1 ); // what the fuck? y = * ( float * ) &i; y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration // y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed return y; } ahttps://github.com/id-Software/Quake-III-Arena 42 / 59

History of Game Engines

2004: Half Life 2

Figure: Half Life 2 uses the Source Engine.

43 / 59

History of Game Engines

2004: Doom 3

Figure: Doom 3 uses the id Tech 4 engine and was released under open source 6 7

6https://github.com/id-Software/DOOM-3 7https://github.com/id-Software/DOOM-3-BFG 44 / 59

History of Game Engines Towards General Purpose GPUs (from 2007)

45 / 59

History of Game Engines

2007: Crysis

Figure: Crysis with the CryEngine, one of the first game to run fully on DirectX 10, still looks stunning even by todays standards.

46 / 59

History of Game Engines

2007: Unreal 3

Figure: Unreal 3 runs on Unreal Engine 3

47 / 59

History of Game Engines

2011: Rage

Figure: id Softwares Rage runs on id Tech 5.

48 / 59

History of Game Engines Towards Multicore (around 2013)

49 / 59

History of Game Engines

2015: Unreal Engine 4 Elemental Demo

Figure: Unreal Engine 4 came with an improved particle system.

50 / 59

History of Game Engines

2016: Doom (2016 reboot)

Figure: The 2016 Doom reboot runs on the id Tech 6 engine.

51 / 59

History of Game Engines

2017: Desiny 1+2

Figure: Destiny’s engine was built by Bungie from the ground up to use multicore architectures.

52 / 59

History of Game Engines Towards Photorealism (today)

The trend in the last 1-2 years has been towards photorealism by moving towards extreme geometric detail and incorporating hardware supported global illumination techniques from physically based rendering such as raytracing. This became possible through the ever-increasing computational power of modern GPUs and hardware ray tracing.

53 / 59

History of Game Engines

2019: Quake II RTX

Figure: The Quake II renderer was rewritten to make use of real-time ray tracing, something not imaginable a few years ago.

54 / 59

History of Game Engines

2020: Minecraft Raytracing

Figure: Minecraft ported its renderer to use raytracing.

55 / 59

History of Game Engines

2020: Doom Eternal

Figure: Doom Eternal runs on the id Tech 7 engine.

56 / 59

History of Game Engines

2020: Unreal Engine 5 Tech Demo

Figure: It is still unclear how Epic achieved this breathtaking graphic fidelity. It is assumed to be a completely custom built rendering pipeline on the GPU, bypassing most fixed functionality, and extremely efficient data streaming allowed by the PS5 architecture.

57 / 59

History of Game Engines

The Future? The drive towards photo-realism using physically based rendering with raytracing can be expected to continue. Streaming of games is likely to become important such as Google Stadia, which would allow the simulation of huge, shared gaming worlds, going way beyond what is possible now with shared world shooters such as Destiny and MMORPGs such as WoW. More and more important will be also faster prototyping and shorter iteration cycles of artists to compensate for the ever increasing effort required to create assets for modern games which due to the quality need much more detail. The question is whether we will see new and exciting game designs and concepts emerge or just old wine in new bottles...

58 / 59

Game Engine Architecture Game Engine Architecture

Jason Gregory (Naughty Dog)

1240 Pages ISBN-13: 978-1138035454

For additional details of Game Engine Architecture and detailed introduction to various game subsystems.

59 / 59