Concrete Architecture of

DOOM 3Unnamed Space Marines

Laura W., Dan L., Matt R., Kristian L., Karen C.

Overview

1. Review of Conceptual Architecture2. Introduction of Concrete Architecture3. Derivation Process4. Discrepancies Encountered5. Renderer Subsystem6. Considered Alternatives7. Limitations8. Lessons Learned9. Sequence Diagram

10. Concurrency11. Team Issues12. Closing

Conceptual Architecture

Layered and Object OrientedArchitecture

Concrete Architecture

Concrete ArchitectureStarting point:

Concrete ArchitectureEnding point:

Concrete ArchitectureEnding point (with Libraries hidden):

Conceptual vs. Concrete

Conceptual Concrete

Derivation Process1. Map files into 8 subsystems

Approach: try to keep whole directories together when mapping

Rationale: if they were saved together in a directory in the source code by the development team, they must be cohesive and should probably stay together

- When individual files had seemingly different functions, we mapped them on a case by case basis to different subsystems

2. Check reference architecture from Jason Gregory’s textbook to verify mappings

3. Examine Internal Dependencies graphical view of subsystem connections

- If dependencies have a small amount of links, explore those connections and, if illogical, remap files or directories

4. Repeat

Considered Alternatives● 3rd Party SDK: minimal 3rd party resources used, so Maya

Import moved into Libraries component

● Game Specific Subsystems: ○ game entities’ initialization and behaviour described

together in files, more fitting in Gameplay Foundations

○ some subcomponents more specific to other subsystems (rendering/animation, user interface)

● Tools: contains both foundations and developer tools, so subcomponents divided between Libraries (ex: debuggers and materials editor) and Gameplay Foundations (ex: scripting)

LibrariesExpected Dependencies:

• Depended on by:• All components

Observed dependencies:

• Two way dependency:• All components

Logical dependencies:

• Libraries depends on network• idCommonLocal: Shut down

network before closing game• Libraries depends on sound

• idCommonLocal: Shut off sound before closing game

Illogical dependencies:

• Libraries depends on UI• Libraries depends on Animation• Libraries depends on Renderer• Libraries depends on Physics• Libraries depends on Gameplay

Foundations

User InterfaceExpected Dependencies:

Depended on by: Physics

Depends on: Renderer, Libraries

Two way dependency: Sound, Network

Observed Dependencies:

Depended on by: Network, Physics (not required)

Depends on: Animation, Sound

Two way dependency: Gameplay Foundations, Libraries, Renderer

Dependencies Missed:

• Depends on Animation (illogical)• Two way dependency - Renderer• Two way dependency - Gameplay

Foundations (illogical)• Two way dependency - Libraries

SoundExpected Dependencies:

Depends on: Gameplay Foundations, Network, Libraries

Two way dependency: User Interface

Observed Dependencies:

Depended on by: User Interface, Network

Two way dependency: Animation, Gameplay Foundations, Libraries, Renderer

Dependencies Missed:

• Depended on by Network• Two-way dependency - Animation

(illogical)• Two-way dependency - Libraries • Two-way dependency - Renderer

(illogical)

Animation

Expected Dependencies

Depends on: Physics, Renderer, Libraries

Unexpected Dependencies

Depends on: Gameplay Foundations, Sound

Renderer

Expected Dependencies

Depends on: User Interface, Animation

Unexpected Dependencies

Depends on: Sound, Gameplay Foundations, Network

Gameplay Foundations

Expected Dependencies

• Depends on User Interface• Depends on Physics• Depends on Network•

Unexpected Dependencies:

• Depends on Sound• Depends on Renderer• Depends on Animation

Physics

Expected Dependencies:

• Depends on Gameplay Foundations

• Depends on User Interface

Unexpected Dependencies:

• Depends on Renderer• Depends on Animation

Dependencies Expected but Not Present:

• Expected Physics to depend on User Interface

NetworkExpected Dependencies:

• Depended on by: Sound• Depends on: Libraries• Two way dependency: User

Interface, Gameplay Foundations

Observed Dependencies:

Depends on: Sound, User Interface

Two way dependency: Renderer, Gameplay Foundations, Libraries

Unexpected Dependencies:

Network -> Sound

Network <-> UI

Network <-> Renderer

Rendering Subsystem

Rendering Subsystem

Limitations● Files were mapped to subsystems based mostly on the names and documentation of classes,

rather than the actual behaviour of each class○ Result of time constraints

■ Too easy to rathole based on the number of interactions between objects in a large codebase

■ Very time-consuming to discern what functions did what when called and to trace them back to where they were declared

○ A more thorough analysis of each file and class would yield a more accurate result

● Examining deeper levels of a subsystem in Understand was too complicated○ Difficult to discern which components were interacting based on the sheer number of

components○ Low signal to noise ratio

● In general, static analysis tools like Understand have a high learning curve○ Having to learn the tool delayed our progress

Lessons Learned● Very easy to get lost in small details of class implementation

○ Have to keep the high level picture in mind at all times when creating the concrete architecture

● Knowing how to use your tools correctly is important○ Understand was difficult to learn and challenging to use at times

■ Project files created on Windows did not work on one group member’s Linux machine, for example

● If you drop the course, let your group members know! (courtesy)

Firing a bullet and killing an enemy in a single player setting

Concurrency

Doom 3 was developed for single core systems and thus does not take advantage of concurrency

Multithreading is not supported

Development Team Issues- Modern technology advancing while game is still being developed

- Game was developed over 4 years

- Longer than expected development time (scheduling problems)- Doom creator John Carmack said that development took “longer than expected”

Closing

Our conceptual architecture matched up reasonable well with the actual observed concrete architecture that we created with the Understand tool. We explored the logical and illogical dependencies in an attempt to better comprehend the architecture of the Doom 3 game.

References

Sanglard, F. (2012). Doom3 Source Code Review. http://fabiensanglard.net/doom3/

Gregory, J. (2009). Game engine architecture. Wellesley, Mass.: A K Peters.

Petrillo, F et al (February, 2009). What went wrong? A survey of problems in game development. ACM Computers in Entertainment, Vol. 7, No. 1, Article 1