CISC326ix The Conceptual Architecture of Doom 3

October 23, 2015

Timothy Crowley 10101513 12tc40@queensu.ca Jerry Mak 10086828 12jm91@queensu.ca

Cody Weeden 10107325 13caw@queensu.ca Christopher Thomas 10066835 12cmt@queensu.ca Raymond Chung 10095831 12rc51@queensu.ca Jashandeep Sudan 10103816 13jss@queensu.ca

1

CISC 326 Conceptual Architecture Report

Table of Contents Subsystems Descriptions …………………………………………………………………...2

Core Systems………………………………………………………………………....2 Low level and Renderer……………………………………………………………....3 Collision and Physics………………………………………………………………....5 Skeletal Animation…………………………………………………………………....5 Gameplay Foundations………………………………………………………………..6 Game Specific Foundations…………………………………………………………...6 Resource Asset Manager……………………………………………………………...7 HID……………………………………………………………………………………8 User interface………………………………………………………………………….8 Visual Systems………………………………………………………………………...9 Audio System………………………………………………………………………….9 Scene Graph………………………………………………………………………….10 Network………………………………………………………………………………11

Derivation…………………………………………………………………………………...11 Conceptual Architecture Picture…………………………………………………………..12 Interacting Subsystems and Dependencies………………………………………………..12 Concurrencies……………………………………………………………………………….12 Evolution of the system………………………………………………………………….….13 Use Case Diagram…………………………………………………………………………..13 Lessons learned……………………………………………………………………………...14 Sequence Diagram…………………………………………………………………………..15 References…………………………………………………………………………………...17

2

Core Systems

The core system is a fundamental component in Doom 3’s architecture which is essential for inter­module communication between different components in the architecture. The core system contains a range of sub­modules that form together to create the game engine. Its main task is to support other modules with processes ranging from memory allocation to accessing essential libraries stored within the core system.

Assertion statements is an essential sub­module of core system during the development and testing process, these statements consist of a variety of error checking code. Assertion statements are primarily focused on catching logical mistakes that may occur during game play. Violations to the programmer’s original assumptions were also addressed by the error­checking code which notify the programmer. Metrics testing is heavily used to ensure that each module is called when it is required to ensure that the entire system worked together as one unit. Assertions are removed from the product for the final product.

Doom 3 is a game that requires a significant amount of mathematical computations for each aspect of the game. To ensure optimal game performance, id Software, has created a custom math library for the game. This math library performs efficiently on frequently used mathematically operations, such as vector and matrix, by coding custom equations that are relevant to the system, avoiding unnecessary computations. The math library embedded within the core system handles all the mathematical operations throughout the entire system

Memory management is significant sub­module that exist within the core system and its effectiveness is a critical component on the overall gameplay. Since memory management is such an essential component, id Software decided it would be in the game’s best interest to create a custom memory management system, resulting the the creation of Zone Memory. This custom memory management system was designed to ensure rapid memory allocation and deallocation while limiting the negative effects memory fragmentation. Zone Memory accomplishes these requirements by performing a regular malloc on a large block of RAM at the beginning of each execution. Zone Memory introduced “Z_malloc” and “Z_free” which were critical functions that performed similarly to the regular malloc in C. Having the large block of ram already malloced into the program, there were less calls into the low­level memory management. Zone Memory functioned on the principle where blocks of memory were stored as a list and adjacent free blocks were merged for the purpose of shortening the length of the list. Shorter the list implied a reduced time required to find free blocks of memory. Zone Memory also solved the issue with external fragmentation, blocks of memory too small to do anything, which was essential at the time due to the high cost of memory.

Doom 3 consist of a custom data structure created by id Software to maximize the efficiency of the system. A custom data structure is essential in the optimal performance of the game play. Doom 3 introduced an innovative variant on list by creating intrusive lists.

3

Intrusive list differ from the conventional non­intrusive list by having pointers point to adjacent cells of the list. This reduced calls to the memory manager since a list of nodes within the object is already allocated in memory. This technique stored all similar events and objects closely together, improving on the time it took to find similar objects. The custom data structure produced by id Software has proven to be revolutionary in handling game data and improving overall performance.

Low level Renderer

The purpose of the low level renderer is to prepare a scene or frame before it is actually output to the screen. It creates prepares the low level elements required and works in conjunction with many different subsystems to pass its data on to the visual effects processor for display. There are significant advantages to this in a multi threaded system, as one thread can handle the processing or low level rendering and the other can handle output. Thus increasing frame rate and user experience.

Another responsibility for low­level rendering is pre­processing levels, to allow for the game to run smoothly. In Doom 3 the levels are designed in 2D therefore there cannot be multi­floored levels. In order to create this the developers partitioned floors as separate levels. This way as the player moves through the environment their needs to be multiple different levels loaded and unloaded as the player progresses through the environment. The developers created a data structure to allow the game to make an educated decision as to what room to process. The developers used a binary space­partitioning tool. This tool takes a full map and partitions it into a series of rooms. It then generates a dependency tree with the root being the room that the player is in currently. The first level of the tree is then all the rooms that connect to the current room. The second level of the tree is all the rooms that connect to the individual rooms in the first level. Using this system the game moves the root of the tree as the player moves through the game. It also only has to pre­process the first level of the tree. By using this abstract data type the developers have come up with an extremely efficient way to choose in which states of the game which individual spaces need to be rendered. The concept of using a binary space partition tool allows for increased performance across a wide variety of systems. See below for an actual Doom 3 map and how it is partitioned

4

When drawing maps, the levels are represented as a series of borders, representing rooms. The low level renderer lays them out so that when they have textures applied to them they will already know the bounds of the current space that they are in. While preprocessing of the map is taking place, the wire frame of the map is first created using the skeletal animation system in the rendering object. This is used to make sure that the bounds of the map are created before the textures are created. This speeds up processing in multi threaded systems present in doom 3 BFG, because one core can render a map, and then another can apply textures. See below for a wireframe of a player and objects in the room

5

Collisions and Physics

The collisions and physics module is an essential component in the architecture of Doom 3. Like all other libraries and modules within the Doom 3 system, id Software has created a custom version of its own collisions and physics module. Tech id 4, more commonly known as the Doom Engine, is directly responsible for making objects interact with the virtual world in a reasonable way. This module covers aspects such as gravity and projectile movement to ensure realistic results. The kinematics of Doom 3 enable human like movements and motions that are expected in a realistic or semi realistic virtual world. Collisions and physics are often tied together since whenever a collision occurs, the physics module is instantly called to deal with the result of the collision. The use of ragdoll physics in Doom 3 allowed for more realistic deaths instead of having an pre­set animation of a death. Rag doll physics uses procedural animations that use strict body components, held by joints and allowed for realistic death scenes. Doom 3 is recognised for its realistic fire physics and many weapon effects that are accurate to real world physics calculations, all this would not be possible if not for the custom collision and physics module.

Skeletal Animation

Skeletal Animation comes in two parts, the skeleton used to animate the character and

the skin or mesh used to draw the character. The skeletal mesh surrounds the invisible skeletal body. Each vertex is bound to the hierarchical structure of joints in the skeleton. for example when trying to move the elbow of an arm it must first take the movement of the shoulder into consideration. The Skeletal Animation engine is connected to the renderer. In order to send the animation to the renderer the skeletal mesh, joint names, parent child relationships, base pose of the skeleton and animation clips of the skeleton (to show how it moves) are needed. When animating a situation each bone in the skeleton has a pose, every pose is sent to the rendering engine in order to create the final blended vertex position and animation. In Doom 3 the mesh and the skeleton are exported to the renderer in one monolithic file. Animation is very memory intensive because each joint in the skeleton has individual animation samples, for this reason they are often stored in a highly compressed

6

format. In doom the Skeletal Animation relates to the drawing and animation of characters. Conceptually from our view Skeletal Animation is connected to everything in the rendering engine.

Gameplay Foundations

The gameplay foundations in Doom 3 contain all the objects, textures, weapons, and gameplay objects that are specific to the game. These are all the objects that are not present in the game specific subsystems. Another application that the gameplay foundations handle is any rule or ability that is enabled at a certain point in the game, such as weapon damage, or experience point systems. Within the gameplay foundations the weapon damage is coded to allow different weapons to affect monsters a different amount, as well as the health of different creatures. This is a key feature of the gameplay foundations. It is essential to recognize that the gameplay foundation is a very high level system, and could incorporate some scripting engine to smooth over how the game actually interprets each foundation.

Overall the Gameplay foundation's work in conjunction with the Game specific

subsystems to create the game components block in our architecture. This dependency is important as both of them create the fundamentals of gameplay.

Game­Specific Subsystems (GSS)

The game­specific subsystems layer sits directly “above” the gameplay foundations

layer and other lower­level game engine modules. It implements game features and systems that are unique to Doom 3; these are discussed in more detail below, but two major examples are the AI behaviour of NPCs and the class­level implementation of various weaponry present in the game. (In fact, many of these classes are abstracted in the gameplay foundations layer; hence the hierarchical relationship between the two.)

Game­specific subsystems are very unique in both their contents and implementation

from game to game. A common way to think of the GSS layer is as the “dividing line”

7

between the generic structure of the game’s engine (found in the core systems, which is reliant on various low­level data libraries and their associated functionality) and the actual implementation of specific/unique Doom 3 features (such as those described below). It is worth noting that this “line” is by no means absolute; it is inevitable that some coupling exists between higher­level implementations of game features and lower­level engine components.

As previously mentioned, many elements of GSS are implemented as their own

objects within the game’s core structure. For example, camera views in Doom 3 are objects that receive information from the core systems and other objects within GSS (for example, weapons classes and power­ups found in the level – see the diagram above) and help inform the renderer which part of a level currently needs to be loaded and displayed. Each player character has a camera “attached” to it for use in the standard first­person view. However, other camera views exist within Doom 3 (for example, a third­person cut scene when the player character dies), and these are also implemented as objects within GSS.

Game Resources Asset Manager

Every game engine has a resource manager present within it in some form. It is an interface (or set of interfaces) responsible for accessing a large variety of game assets, current game state information, and various engine input data. There are two approaches to accomplishing this: either centralize these access processes and make them consistent across the entire game engine’s implementation, or leave it up to the developers to directly access the files and resources they need. Doom 3 decidedly leans towards the latter approach.

Doom 3 uses a resource manager called DeePsea. It organizes game resources into

special files called WADs, with the individual WADs themselves organized into “lumps” of related data. For example, in Doom 3, each map is comprised of numerous lumps of data required to render and interact with the map. A lump may contain information such as a list of all object vertices in a map, or collision­detection information indicating whether any two objects in a map are touching. This information is accessed and used by many front­end components to display the current game state.

8

Human Interface Devices I/O component

Games are interactive simulations so the player has to have a way of interacting with

the game.The player does this by using the HID engine. Traditionally the user moves the character, interacts with objects and controls the game through a keyboard and mouse or controller actions. More modern games have incorporated virtual reality devices like the Oculus rift or motion sensing devices like the Xbox kinect or Playstation camera into their HID engine. The HID usually doesn't use raw inputs from devices, it manipulates the user inputs to create smooth actions in the game. HID engines are also responsible for dealing with chords (a pattern of buttons or keys that result on an action) or double tapping a button, for this reason the engine needs to save recent button presses by the player. Conceptually from our view the HID engine is connected to the core systems component. When a user inputs data through the HID engine the input is sent to the core systems to pass off its information to any systems that are affected by that input. It is also connected to the Network Interface component, the network Interface receives user input from the HID and puts it on the server.

User Interface

The User Interface is made up of all visual items that the user sees and interacts with. The User Interface is responsible for working together with other systems, such as the renderer to display graphics and collaborate with the back end. The User Interface is made up of the Heads­Up Display, Full­Motion Video, in­game Cinematics, In­game GUI, and In­Game Menus. The Heads­Up Display is a visual report of the current player status, this includes things like health and gun ammo. Full Motion Video is the use of pre­recorded video files to display action in the game, this saves time on rendering. In­game Cinematics are videos, which the player does not interact with. Another system in the In­Game Menus, this is all the menu options present in the game, examples being login and pause menus. The User Interface, works together with many systems, the GPU and the graphics engine (which depends on what platform you are playing on) to put together, high quality graphics and immersive gameplay.

9

Visual Systems

Visual Effects are the detailed animations and lighting of floors/levels. Visual effects

of the game includes light Mapping, HDR lighting, PRT lighting, Particle and decal systems, post effects and environment mapping. Light mapping is the effect that judges how bright a surface in the game should be. HDR Lighting also known as high dynamic range rendering, this is the rendering of computer graphics scenes by using lighting calculations, from other lighting systems. PRT lighting also known as precomputed radiance transfer is a technique used to render scenes using precomputed calculations to save time, this means that important calculations which are reused often, would be stored in the Visual effects. Particle system is the use of very small 3d models to simulate a fuzzy phenomenon/image, a doom specific example would be the fire animations. Post effects is the application of filters to an image, before actually displaying it, this would be one of the final effects on an imagery. Environment mapping is the technique of approximating the appearance of a reflective surface by using a precomputed texture image. So you use the image of the environment and then put that as the texture of an object. These all come together with the User Interface to help display imagery.

Audio

The sounds from Doom 3 are astonishing and intense. With a built­in support for 5.1 surround sound, it makes playing Doom 3 a terrifying experience. That terrifying experience while playing can be enhanced with modifications to the sound files using an editor. The sound system of Doom 3 consist within its system at least one sound world, which handle the complexity of the audio. The sound world interacts with the audio directory containing all of the sounds, and play the file that the program requested. The audio file is a .wav file. The sound world keeps track the location of all of the emitters, where the listener is and what state they are in. It can be thought similarly as the render system for sound.

When the game was released, it introduced a new addition to the audio component, which are the sound shaders. The sound shaders allow for more control over sounds in the id engines, and allow designers to drop sounds in levels without setting some parameters every time.

How sound shaders work in game is the sound closest to you will be the loudest. So, imagine yourself in a scene, you and your allies are walking up the battlefield to victory. You decided to give your loudest battle cry to motivate your troops. Your cry will be the loudest around you, but the further the noise echo, the volume of the cry will get lower and lower until it goes silent.

10

As mentioned in the first paragraph, you can modify Doom 3 sound files using the built­in editor by typing “editSounds” in the console. The editor was designed for a non­level designer to play around with sounds during levels in order to create a scary unreal experience.

Scene Graph

What a scene graph does is contain any texture and render model in the scene/area. It

interacts with the frontend components to ensure everything that is needed by the backend is uploaded to the GPU ram. This works by finding every light/entity combination affecting the view. The scene graph also handles culling and dispatches commands to the back end.

This is what a top view scene graph looks like, it contains everything in the scene, which are the texture and render model, the non­playable characters in red and the player itself in blue. In actual view without non­playable characters, it would look like this in a first­person view: It contains all of the render and texture models such as the lights, the floor, the doors etc.

11

Network

The network interface is a very crucial part to the architecture and gameplay of Doom 3. The reason for its importance is that the architecture style changes from an object oriented/layered style, because of an addition of a client server. This client server enables the user to play on an online multiplayer mode with other players. The reason for the addition of a client server is so that the server can host a snapshot of the game state online, that way every player is seeing the same action/reaction. All calculations are also then done on the server, that way when the rendered information is sent back to the players, it is consistent throughout. The Network Interface communicates with the User Interface and Human Interface Devices, to display visual content to each player, along with taking each player’s system input. This all comes together to make sure all players are seeing the same animations and graphics at the same time, making gameplay fair.

Conceptual Architecture Derivation Process

We derived our overall conceptual architecture for Doom 3 as a team, because its

design and components affected all the work we did individually. The structure of the architecture we came up with defined how each of the individual components we researched tied back together to form the whole system.

We began by examining the different architecture styles presented to us in class. We

evaluated their pros and cons, as well as their feasibility for implementing a large­scale video game such as Doom 3. Ultimately, by process of elimination, we decided on an object­oriented architecture, with some layered components. We made this decision based on the advantages offered by object­oriented and layered styles, and how these advantages can be applied to video games such as Doom 3. For instance, one of the advantages of a layered system is that it promotes efficient interaction between components and subsystems – since fast and reliable performance is a key part of the Doom 3 experience, this is very important. Further, at a high level, many different components of a video game need to communicate and interact directly with one another. This is easily facilitated by taking an object­oriented approach to implementing game features, such as those outlined in the game­specific subsystems section of this report. Also, an object­oriented approach offers advantages such as guaranteed order of execution for concurrent processes, and easier information hiding over a network.

12

1. The renderer is dependent on game asset libraries for information on the current game state needing to be displayed, as well as things such as 3D Modeling Resources and the game’s map.

2. User interface deals with all visual related effects, it depends on the rendering engine, core system, Network Interface and Resource Game Assets to render images and display an up to date graphic to the user.

3. Audio depends on the user interface, in order to tell the sound system on which sounds to play in unison with the visual effects and model.

4. The renderer depends on information from game components (such as camera views or weapons) to tell it what front­end components need to be loaded and how they should be displayed.

5. The HID is connected to the network interface component, as the network interface receives user input from the HID and communicates it to the server.

6. The core system contains the libraries within the system and the game’s engine; hence, all other modules depend on it.

Concurrencies

Many concurrencies have to occur in a game architecture to keep all systems running

as intended. Some examples of concurrencies in an architecture are the graphics, rendering, Network and Human Interface Devices. All rendering has to be done concurrently, to make sure that collisions and physics are kept consistent with the game state, this then has to be running concurrently with the graphics/User Interface. All graphics have to be running

13

concurrently, to make sure animations and player movements are responsive and reflective of the current game state. This especially is important in Online play, where the Network Interface has to be displaying an up to date snapshot of the game state to the core systems, so that the players are all seeing the same actions/reactions to make gameplay fair. Finally a big concurrency has to occur with the Human Interface devices and Core System, so that every action by the player is registered by the game state and appears

Evolution

Doom 3’s conceptual architecture facilitates easy code evolution and updating because its components are implemented in a layered and object­oriented style. It is also a big reason why the user/developer community is very engaged in the ad­hoc modding of Doom 3. When related components and game objects are layered into a hierarchy of abstraction, if one is updated, it affects at most two others. This is very convenient if, for example, a patch is released affecting only a minor subsystem of the overall game. Also, an object­oriented style means that individual game components are largely self­sufficient; if one is modified, its interaction with others will be mostly unaffected, and any changes can be implemented within the updated object itself.

Use Case

The following diagram is a simple use case diagram of Doom 3 game play. The diagram takes in actions that the user could complete and connects it to the appropriate back end modules to complete the task.

14

What We Learned

A lot of the subsystems we researched overlapped, when we presented our research during our meetings we discovered that there was a lot of repetition between our systems. Another thing we learned was we focused far too much on the specific subsystems and how they work and less on how they connect to the overall conceptual architecture. On initial research of doom three when looking at gameplay we focused mainly on the single player aspect. We realized BFG edition has major network interface aspects and we added it to this our conceptual architecture.

We chose Object Oriented and loosely Layered style but we can see other styles being relevant in this game engine. Implicit Invocation for user input or client server for multiplayer aspects. But we decided to keep it as simple and clean as possible with Object Oriented style.

15

This sequence diagram show the action of shooting a gun at an NPC. The player clicks the mouse to shoot at the NPC, this signal is sent to the core system. The core system processes the signal and send the necessary information to the User Interface. The user interface goes to the Game Components to get the weapon objects and then to the rendering component to render the model. From the Rendering component the modified model is sent back to the User Interface. The User Interface sends the updated model to the core system which in turn sends back the shoot NPC signal to the User Interface. And finally the User sees the NPC is shot.

16

In this sequence diagram, it shows the player walking forward during online gameplay. The player presses the forward key on their keyboard, which would modify the location of the player in the network interface. At the same time, it sends a signal to the user interface.. Then it loads the animation object and render the model. After the animation object is applied to the model and is updated to the core system, the location is updated on the network interface. Finally, the player walking is shown back to the user on the display screen.

17

References: Gregory, Jason. "Game Engine Architecture, Second Edition." Google Books. CRC Press, 01 Jan. 2015. Web. 22 Oct. 2015. Quassar. "Zone Memory." Doom Wiki. Doom Wiki, 12 Jan. 2005. Web. 22 Oct. 2015. Norem, Josh. "Maximum PC." Google Books. Maximum PC, 01 Oct. 2004. Web. 22 Oct. 2015. "Intrusive Lists in Doom 3." Intrusive Lists in Doom 3. N.p., 03 Feb. 2010. Web. 22 Oct. 2015. Sanglard, Fabien. "Fabien Sanglard's Website." Fabien Sanglard. Fabien Sanglard, 08 June 2012. Web. 22 Oct. 2015. Developers, ID. "Id.sdk [Sounds]." Id.sdk [Sounds]. ID Tech, 01 Jan. 2004. Web. 22 Oct. 2015. Public. "Back and Front Ends." Wikipedia. Wikimedia Foundation, n.d. Web. 22 Oct. 2015. Doom. "Camera." Doom Wiki. Doom Wiki, n.d. Web. 22 Oct. 2015.

"DeePsea." Doom Wiki. N.p., n.d. Web. 22 Oct. 2015.

<http://doom.wikia.com/wiki/DeePsea>.

"Id.sdk [The Code]." Id.sdk [The Code]. N.p., n.d. Web. 22 Oct. 2015.

<https://www.iddevnet.com/doom3/code.php>.

"Player." Doom Wiki. N.p., n.d. Web. 22 Oct. 2015.