Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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