CISC326ix Raymond Chung (10095831) Tim Crowley (10101513) Jerry Mak (10086828) Jashan Sudan (10103816) Chris Thomas (10066835) Cody Weeden (10107325) Fall 2015 Project Phase 1 An explanation of Doom 3’s repository-style architecture

Collisions and Physics Low Level Rendering Network Interface GSS Visual Effects Scene Graph Audio Skeletal animation Gameplay foundation User Interface Collisions and Physics Low Level Rendering Network Interface Human interface device Resource Game Assets Core System Libraries Sub System Depends on

Core System Assertions Math Libraries Lines of code used for error checking Used to catch logical mistakes and violations of the programmer’s original plans Assertions are taken out of the final product Math Libraries ID Software creates its own libraries to replace standard template libraries Provides facilities for math functionally including vector and matrix math, geometric operations.

Core System: Memory Management Most games tend to create their own custom memory management Custom memory management : ensures high speed allocations and deallocations Limits the negative effects of memory fragmentation Doom 3 uses “Zone Memory”, a system developed by ID Software

Core System: Custom Data Structures ID Software avoids using standard template libraries and creates custom libraries, to minimize or eliminate dynamic memory allocation ID Tech (Doom Engine) introduces intrusive list as opposed to conventional non-intrusive list. Benefits of Intrusive List: Less memory management: since nodes are already within the object, allocation is already done together rather than looking for various nodes in different segments of memory

Collision and Physics Required in games to make objects interact with the virtual world in a reasonable way Physics systems are responsible for realistic/semi realistic dynamic systems Concerned with the motion (kinematics) of rigid bodies of the forces and dynamics that cause motions to occur Doom 3 uses ID Tech (Doom Engine) for handling collisions and physics

Low Level Rendering in general gaming LLR is one of the largest and most complex components of any game engine Extremely important when applied to 3D Graphics Low level rendering encompasses all of the raw rendering facilities of the engine. Handles many of the pre processing tasks that are present in the game.

Low Level Rendering in Doom 3 Responsible for underlying data structures responsible for game operations, and preprocessing level design. Levels are designed 2D, therefore there can be no multi-floored levels. The game partitions floors, as 2 separate levels.

Binary Space Partitioning Doom uses a Binary Space Partitioning tool, to generate a binary tree of different areas in the level Clever way of rendering the correct areas, as a player moves through the level When the level is changed the BSP data is updated if there’s a structural change

Gameplay Foundations Any action that takes place in the game Rules, abilities, and mechanics Implemented in the native language of the engine or a high level scripting language. Most engines have a separate layer for gameplay foundations. Tied to a software object model: pervades the entire engine. The term software object model refers to the set of language features and policies to implement OO software.

Game-Specific Subsystems Layered above gameplay foundations; close to the “top” Implements unique game features eg. AI for NPCs, in-game camera angles, weapon and vehicle systems Represents the “line” between the game engine and the game itself Line between generic game engine and implementation of specific Doom 3 features Coupled heavily with gameplay foundations objects

Game-Specific Subsystems Doom 3 is typically in a first-person view, so player mechanics, camera objects, HID component, and the rendering engine are highly interdependent Appearance of other features (such as monsters or powerups) is handled by the low-level renderer, and communicate with the player object as necessary Multiple possible camera views; each is its own object (eg. death cutscenes, chase view, etc.) Components interact in an object-oriented way

Resource Asset Manager Doom 3 uses a resource manager called DeePsea Contains packages supporting 3D object modeling, object collision resolution, etc. Packages of game information/data is stored in special files called WADs Either IWAD (Internal WAD) or PWAD (Patch WAD) WADs containing related data are assembled into lumps Example: IWAD lump called “BLOCKMAP” stores information indicating whether any two objects in a map are touching Tied very closely to Core Systems Contains slightly more static data than Core Systems, as opposed to applied functionality (such as math libraries, etc.)

HID 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. This system is how the user interacts with the game. The user moves the character and interacts with objects usually through  keyboard and mouse or controller actions. The HID usually doesn't use raw inputs from devices, it massage the user inputs to create smooth actions in the game.

HID in Doom 3 Doom was originally developed for windows in 2004 so the player controlled the game through a mouse and keyboard. 5 months later it was ported to mac and Xbox. This incorporated a Xbox controller into the Doom’s HID engine.

Skeletal animation When doing skeletal animation two parts are taken into consideration, the skeleton used animate the character and the skin or mesh used to surround the skeleton. Each vertex of the skeleton contains a list of indices showing what joint in the skeleton it is bound to and its location. When trying to move the elbow of an arm it must first take the movement of the shoulder into consideration. To render the skeletal mesh you need the mesh, joint names, parent child relationships, the base pose of the skeleton and animation clips of the skeleton to show how it moves.

Skeletal animation Animation is very memory intensive because each joint in a skeleton(often more than 100) has individual animation samples.  for this reason they are often stored in a highly compressed format. Skeletal animation in doom 3 relates to the drawing and animation of characters, monsters and objects.

Network Game model changes from layered/object oriented to a layered/object oriented/client server Most calculations, instead of being done locally would go to a dedicated server Core system would factor in ping for everything i.e. Collisions and physics, audio, animation etc. Network keeps a snapshot of the game state and resolves all issues involving latency

Collisions and Physics Low Level Rendering Network Interface GSS Visual Effects Scene Graph Audio Skeletal animation Gameplay foundation User Interface Collisions and Physics Low Level Rendering Network Interface Human interface device Resource Game Assets Core System Libraries Sub System Depends on

User Interface What is it? -Heads-Up Display -In-game GUI -Full-Motion Video -In-game Cinematics -In-game GUI -In-Game Menus

Visual Effects What is it? -Light Mapping -HDR Lighting -PRT lighting -Particle and Decal Systems -Post Effects -Environment Mapping

Audio System Contains at least one sound world Handles the complexity of audio Tracks what state they are, where the listener is and location of all of the emitters Interacts with sound files (.wav) to play the sound

Scene Graph Contains all the render models and textures in the scene/area Interacts with the front end components ensure everything needed by the backend is uploaded to GPU ram Handles culling and dispatches commands to the back end

Collisions and Physics Low Level Rendering Network Interface GSS Visual Effects Scene Graph Audio Skeletal animation Gameplay foundation User Interface Collisions and Physics Low Level Rendering Network Interface Human interface device Resource Game Assets Core System Libraries Sub System Depends on

Derivation Process for Architecture Used process of elimination Started with Pros and Cons of every architecture Considered Implicit Invocation Came to conclusion that a hybrid architecture would be needed Decided on object oriented and layered -Discuss alternatives

Derivation for Interacting Parts Each person was assigned 2 subsystems to study Came together and discussed each of our subsystems Worked together to draw a starting conceptual architecture Edited, reviewed and went over cases to come up with a final draft

What we learned! Subsystems have a lot of overlap Focusing too much on specifics, rather than structure of overall architecture Looking at Doom 3 regular game play, not BFG Architectures have a lot of leeway and can change for different scenarios We spent a lot of time doing repetitive research, when a lot of the stuff we studied had a lot of overlap, and group research would have been better