Concrete Architecture Report

Transcription

1 Concrete Architecture Report CISC 235, winter 2015 For Ahmed E. Hassan Due 13 November 2015 By GROUP OMG Joshua Lee Nelson Yi Andy Chu Percy Teng Hassan Haq Simon Zhang (primary contact)

2 TABLE OF CONTENTS ABSTRACT INTRODUCTION CONCEPTUAL ARCHITECTURE Modifications Made CONCRETE ARCHITECTURE Reflexion Analysis Initializer Libraries User Input Networking Scripting Subsystem Analysis: Scripting Entities Physics Subsystem Analysis: Physics Sounds Renderer ABOUT CONCRETE ARCHITECTURE Design Patterns Derivation Process Architectural Style Limitations of Reported Findings Concurrency SEQUENCE DIAGRAM DEVELOPMENT TEAM ISSUES LESSONS LEARNED CONCLUSION CONTAINMENT FILES GLOSSARY REFERENCES

3 ABSTRACT For this report, we have presented the concrete architectural structure of Doom 3. We used the Understand software that helped to visualize the dependencies/connections between each source file of the game. We changed our conceptual architecture by grouping together main components that we later deemed to be similar after using Understand. The dependency graphs in Understand proved to be very useful, as all the dependencies in our Concrete architecture were found using this program. Many of the determined concrete connections were expected, as they were logically sound when we determined our conceptual architecture. But there were also many dependencies that logically, we did not expect. We had to have extensive group discussion in order to figure out why these unexpected dependencies existed. We grouped the Input Engine and Command System components under the new User Input component, and Rendering System and UI under the new Renderer component. The name Game Data was changed to Entities, Event Handler to Initializer, and AI to Scripting. Furthermore, we added a whole new component called Libraries, which handled many of the miscellaneous files that the other components needed to complete their respective outputs. We determined that every single high level component in our Concrete Architecture had a dependency with Initializer and Libraries. We specifically deeply analyzed the Scripting subsystem and found many interesting and perplex connections between its sub components. In conclusion, we determined that Doom 3 is a highly complex and dynamic game, and that it takes significant amounts of analyzing and critiquing as a group to come up with a concrete architecture for it. INTRODUCTION The name of our group is OMG. The purpose of this group is to give ourselves an appreciation of software architecture in the context of a large software system. We are studying the 2004 science fiction survival horror first person shooter Doom 3 video game. This game was developed by the American video game company id Software, which is available on the Microsoft Windows, Linux, Mac OS X, and Xbox. A more recent version, titled Doom 3 BFG Edition, was released in 2012 and featured enhanced graphics, better sound with more horror effects, a checkpoint save system, and support for 3D displays and HMDs. Support was also added for the new PlayStation 3 and Xbox 360 platforms. However, we will focus primarily on the original Doom 3 and create a detailed architecture report by the end of the course. However, this report will only cover the Doom 3 source code version of the game, as it is the most consistent with all of our research and findings.

4 The report is organized in such a way that you can progressively see how the development team reached a concrete architecture from the conceptual and insight after the concrete architecture was finalized. Each title that is capitalized and underlined contain a broader identification of what we will be talking about. The titles in green indicate the subtopics that go under each of the main parts of the report. There are diagrams, figures, and small portions of source code extracted in order to help visualize and explain details that are otherwise harder to verbally visualize. In the process of the project, there were many complications that were met, which is evident by the size of the explanations. One of the problems was exactly this matter, causing our report to be greater than fifteen pages by a marginal amount. CONCEPTUAL ARCHITECTURE Modifications Made There were several flaws with our original architecture that made us remove, combine, or introduce new high level components. Each change, we categorized as a hard change/generalization, complete removals, soft changes, or additions. These changes were made based on looking solely on the files shown in the Understand Doom 3 project file before any dependencies were made. These changes were made due to the fact that they were either non existent, the components were too similar or indistinguishable to be kept as two separate components, or the file was too broad to be kept as one component. An interesting case would be with the Hardware, User Input, and Renderer components of the new updated conceptual architecture which involved all the hard changes. The hardware component was too abstract to be involved in things related to the game engine, thus we had to remove it completely. User Input was a combination of the Input Engine and the Command System. The Input Engine dealt with the registry of user key commands while the Command System dealt with the processing of said input commands. As given by the defining characteristics of each, there is too little distinction to keep them as two components, thus they were combined to become User Input. The Renderer contained the initial Renderer component and the User Interface component. This seems rather counterintuitive but this was due to the fact that we focused strictly on functionality. If the User Input dealt with the registry of keys, the Renderer would deal with the visuals of the game. Though rendering essentially meant creating a 2D screen from a 3D world we essentially had all visual components within rendering anyway. We kept Renderer named Renderer because the cause of the majority of dependencies were from rendering.

5 The Initializer is a special change where the functionalities of the original and the new conceptual were two different things in themselves. The event handler dealt with processing the right action to be made, sourcing from the user input and the current state of the game. However, though there was no such component existing in the source code give, there were components that created threads, started and stopped functions. Thus we renamed our event handler as the Initializer. This was kept as a soft change because rather than directing the right course of action from the given data (event handler), the initializer starts or stops actions to be made. Scripting, Entities and Libraries were all part of the original conceptual component, Game Data. Game Data in our original architecture dealt with all of the libraries, all of the storage of information, and all of the game states. This was too much to be kept into one component. However, we also couldn t break these apart into several additional components as the complexity of our concrete architecture dependencies would get too complicated. Instead, we changed other components to account for the specialization. A very abstract component of Game Data was the Libraries section which held all the miscellaneous data such as random Strings, math libraries, hash tables, and basically all other commonly used tools. Entities is what remained of Game Data s original identity as it stored all the data that dealt with all the existing objects within Doom 3, such as doors, walls, levels, worlds, weapons, players, monsters, and so forth. The Scripting component was highly coupled with the Physics and Entities component, but was still very distinguishable because of it s functionality. While the Entities dealt with the possible nouns in the game, the Scripting component dealt with the verbs of those nouns. Basically, all the actions that an entity can make was stored in Scripting. The difference between Scripting and Physics was that Physics was the adverb of scripting, which described how an object can move and not what actions the object can make Figure: Conceptual Architecture vs. Updated Conceptual Architecture

6 Due to the hierarchical nature of the conceptual architecture, we looked at the abstraction of the conceptual architecture and numbered them accordingly. We reorganized the components and linked each dependency based upon the dependencies we thought were logical. CONCRETE ARCHITECTURE Figure: Our concrete architecture Note that the missing dependency arrow of libraries is actually to the networking component, as networking has zero dependencies on libraries. Figure: Our concrete architecture as seen in Understand

7 Link to the fullsize image: Reflexion Analysis The Reflexion Analysis is a process used to compare the conceptual architecture to the concrete architecture and develop an understanding of what is missing from either architecture. This is followed by investigating why certain dependencies are missing and then adding/redeveloping the architectures. Instead of outlining it here the break down for the reflexion analysis is done in parts in each section of our Concrete section, where each sub system explains how we discovered dependencies, how we connected our architectures components/subsystems as well as outlining the gaps we found and how we worked to fill them. The reasoning for each decision upon the main components can be found in the Modifications Made and the Derivation Process section as it outlines which components we removed or kept depending on our collective consensus. Initializer The initializer is our name for the component containing sys, gamesys, and the game/script files. This component is a modification of the previous Event Handler component in our old conceptual architecture. The initializer comprises of low level abstract code foundational code that has no idea of the game built on top of it (2). For example, sys contains all operating system level calls, including locking/unlocking memory, loading dynamic link libraries, and starting processes. Game/gamesys, in turn, contains important idclass code, event handling code, and game saving code; and game/script contains script compilers, interpreters and threading. Due to the nature of the initializer, every subsystem relied on the initializer, with a relatively large number of dependencies on the initializer rather than from. One exception is the edge with the user input, where the number of dependencies far outweigh the number of dependents. This is reasonable, as user input is a top level subsystem, where data is received from for the game/gamesys code, which can determine what to do with the data. Libraries Libraries is essentially where generic, often used code is stored (eg. hash tables, math libraries, compilers, memory management) (2). It consists of idlib, tools, MayaImport, and TypeInfo. These were grouped together in libraries because we found that they all were similar in nature in that they were all code that could

8 theoretically be used anywhere in the system. This is supported by the fact that all other subsystems have a large number of dependences on the libraries subsystem User Input This component is about how we retrieve data from the user, through inputs from the keyboard, mouse or gaming console controller. It depends on libraries where it gets most of the miscellaneous files needed to complete the input instructions. The Renderer processes the user input and gives an output onto the UI. The Physics component needs to know what the external inputs are, in order to produce the correct physics aspect of output. This high level component has many important sub files like Common.cpp, CmdSystem.cpp, and FileSystem.cpp. All three of these files are either dependencies or dependent of other high level components in our concrete architecture. For Common.cpp, there are many functions that have dependencies with Libraries. For example, Common.cpp/ LocalizeMap function gives the localized information as an integer. It calls the Libraries/ HashTable.h function s public constant function Get to get more information for its computations. Secondly, CmdSystem.cpp/ Icmp is called by the Libraries/ Str.h function to help with modifying character strings ( return idstr :: Icmp ( (* a ) > name, (* b ) > name ); ). Lastly, FileSystem.cpp s idfilesystemlocal class contains a function called ReadFile that reads a file, and it calls Libraries/ Mem_ClearedAlloc ( buf = ( byte *) Mem_ClearedAlloc ( len + 1 ); ) to help in instances when memory needs to be cleared and allocated. As the User Input component acts like a gateway to how every single process of the game will be carried out, its files have many logical connections with some files in the other high level components. It was clear that User Input depended heavily on Libraries where it get most of the miscellaneous files needed to to correctly complete each user input instruction. But there were also some unexpectancies. Firstly, User Input depends on Sound. Later it was found that some user input processes results in a acknowledgement sound that comes from ingame (Like a OK button press). Networking This component focuses on handling and processes data transfers between the client and server during online play. Networking takes the received data and transfers the information to the high level components that need them. We did not expect many of the determined dependencies of Networking on other components, but after further analysis we determined that these were necessary as the Networking also needs to take information processed on the client s computer to the

9 server. Networking depends on Renderer to determine how to visualize the client s game world and processes it so that others on the servers side can correctly see the client s world in their own perspectives. Furthermore, Renderer depends heavily on both the User Inputs component and Entities component. For example, when a user wishes to type a message to other people during a online game of Doom 3, Networking depends on the User s Input in order to transfer the correct data through the server. Lastly, Networking depends on the Entities. This is because Entities produces the physical and interactive behaviours of all entities ingame (Character, monsters, pickup able weapons etc.). Scripting We defined the scripts in our system as actions. If the entities were the things, the scripts would hold the info on what those things can do and how they can do them. This included player scripts, weapon scripts and monster scripts. In our old architecture, this was held in the game data component. However, once we broke that component down we realized that the monster scripts were already very similar in practice to the monster AI, so we thought it would be appropriate to combine the two subsections together. In our conceptual architecture, we believed that the scripts were only dependent on the User input, which was clearly not the case as we saw with our conceptual architecture. Entities: The scripts available for each entity depend on what that entity is. For example, a monster that just has claws to attack shouldn t be able to use the shoot scripts. User Input: The scripts translate the user s input into actions in the game for the renderer to show. These scripts include shooting, running, jumping, picking up items and others. Physics: When the AI tries to tell entities to follow a certain path, the paths that they can take are limited by physics. They are bound by the gravity files, and the collision model files. The AI needs to work around things like walls due to this. Networking: The scripts receive data from the servers about the actions of the other player s input and the scripts execute them. This functions mostly in the same way that the dependency between the user s input and the scripts do. Rendering: Like with the player, monsters are subject to stun animations, or other animations that inhibit further actions until the animations are complete. Even if the AI wants to tell a monster to start shooting because the player is in the monsters area of awareness, that monster wouldn t be able to if he has been shoot down and still needs to get up.

10 Library and Initializer: The scripts need to needs to make function calls to these components. Subsystem Analysis: Scripting Figure: The concrete architecture for Scripting subsystem Inside scripts, we have three major subcomponents, AI, trigger, and spawn. The AI subcomponent contains info about how nonplayer entities act, as well as scripts for any object that the player can interact with, such as weapons and doors. It includes the area awareness system, potential vision set, as well as pathing. It primarily relies on the renderer, user input, physics, and entities. It also has some minor dependencies on spawning and sound. The script relies on the user input in order to know when the player interacts with an object. When the player presses the button for shoot, the script needs to retrieve the files for firing. But in addition to needing to know when to fire, the script needs to know what to fire. Because of this the script depends on the entity component to get the ID for the weapon that the player is currently holding. The AI also needs to depend on the entities to know which monsters are on the map. Since different monsters have different AI s, the scripting component needs to retrieve the monster s ID. The actions possible for those monsters are limited by the physics of the game, particularly, the collision models. The AI may tell the monster to take the shortest path to the player, but if there are collision models in the way, the monster can t take that path. So, the AI needs to recalculate a different path. The AI of the monsters is also limited by the renderer, since it holds details about the models that would be in the monster s way. Though we expected all of this info to come straight from the

11 physics component, it s possible that more dependencies were added to expedite the process. The Trigger sub system for Physics is much like a cue for when things should happen. For instance, if a player walks past a certain door, the Trigger sub system will essential trigger another event to occur. The reason why Trigger relies on Entities is due to the fact that when something occurs, it must rely on what objects are being tampered with and what objects or entities will be affected by the trigger. The Physics component comes into play because in order to deal with when an event occurs, the Trigger component must know the interactions between the entities, essentially, what had happened. When putting this together in an example, if the player goes to the boss room, the player entity is pulled, the door entity for that boss room is pulled, the Physics component determines if the collision models have made contact, and the information is relayed back to Trigger. The spawning subcomponent deals with spawning new monsters. It needs to decide where to spawn them and how many should be spawned. This is also used for respawning new players in the multiplayer matches. It depends mainly on the entities. The dependencies on the entities are very clear because the game needs to know which monsters to spawn. The spawning subcomponent would get the model ID from the entity component and decide how many of that monster should spawn depending on what kind of monster it is. Smaller monsters may spawn more than larger ones to even out the difficulty of the game. Entities The Entities component handles the physical behaviours of all entities in the game, like monsters, weapons, items, particles, and interactive objects in the game like door panels. It contains an important file called Session that is in charge of handling the game s transition from level to level. This component is a significant component, as it has dependencies between almost all of the high level components in our concrete architecture. For example, Entities/ Actor sub architectural component contains a file called Actor.h. On line 193 of this file, it calls the public virtual constant function GetAASLocation from the high level Script component and uses the abstract class idaas. Another example is the Item.cpp file under Entities. This file has a dependency with the SetBouncyness function of the Physics_RigidBody.cpp file in the high level Physics component. Item.cpp calls the SetBouncyness function at line 962 to help set up the characteristics of the in game item. As entities define mostly all the interactive and active objects in game, it has significant dependencies on the Scripting, Networking and Physics components. For Scripting, the AI sub component provides Entities with the complex and interactive

12 behaviours of live objects in the game, specifically monsters. Networking provides Entities with information about items that other users in server are using and interacting with. As some entities are live, the game needs to determine their physics aspect of movement, thus Entities depends on Physics. Physics The Physics component contains the Collision Model sub component, which handles collision detection of entities in the game world. The Physics component deals with determining how to move these collision models through the world according to the laws of the physics or other rules; it basically does the math. Physics has a dependency on Renderer, which was unexpected. Further analysis showed that Physics implements a Trace System that depends on information from the Renderer. We expected Physics to depend on User Input as it was logical; since physics can only process the correct computation when it gets input instructions from the user. Lastly, Physics depends on Entities, which was unexpected. But with further analysis, we determined that certain aspects of entities cannot be build without input from Physics. Subsystem Analysis: Physics Figure: The concrete architecture for the Physics subsystem Our physics system deals with the forces exerted on the entities to simulate the physics in the real world. As such, we organized the files into three subcomponents, Physics, Collision Models, and Forces. The physics subcomponent defines how the physics affect the different entities. As such, there are files for specific entities, like actors, monsters, and players. It decides how things move and which direction things move. It relies heavily

13 on scripting, entities, user input, as well as to the collision models subcomponent. In order to decide how an action will affect an entity, the physics subcomponent must first know what the action was. This would come straight from the scripts component. It also depends heavily on the entities component. This component, particularly the Entity.cpp file, contains a lot of details about the entity that affects how the physics will apply to it, as seen by the use of ActivePhysics, the GetPhysics, and the SetPhysics methods. It should also include details about the entities weight and how the entity handles impacts. We didn t expect the physics subcomponent the have any relation with the user input component. However, upon closer inspection of the files that are being called, we realized that a specific file in the User input, UsercmdGen.cpp handled certain aspects that we wanted to encapsulate in the scripts component. This file contains most of the dependencies seen and contains info about how the player entity moves. However, this file also contained information about how a user inputs data to the system, so we ultimately decided to leave it where it was, despite the extra intercomponental dependencies it creates. The other dependency it has is with collision models. When physics are affecting entities, the entity is moving, but the movement that they can take is still bound by things that they can collide with. That movement decided by the physics subcomponent needs to stop at walls or floors, or ceilings or anything else that has a collision box associated with it. The force subcomponent is the component that calculates the math of the forces. It decides how fast things move when pushed and where they will land. It depends on the physics subcomponent and the entities. The physics subcomponent gets the info from scripts about what happens to the entities and decides how to handle those events. The physics component would then call the force subcomponent to decide the math behind how the actions occur. But, in order to calculate the math, it needs to get data about the entities that are being affected. Each entity can be affected differently from similar events depending on its characteristics detailed in the entities component. Most notably, different entities will have different weights. A small monster which weighs very little will go flying from hits, whereas a large monster when hit by the same force will not move much at all. These factors are needed by the forces subcomponent in order to decide how events are carried out. The collision model contains the hit box of the entities, as well as tell the script when things are solid and can t be moved through. This will depend on the user input, the entities, and the renderer. The entities contain the model IDs for the collision model to refer to. This is how the collision model knows where to get the data about the boxes in the entity that has to be solid. The actual information about the solid hit boxes are found in the renderer component. Though this data was intended to be put in the entity component, the model images and model boxes overlapped too much to separate them without creating even more dependencies.

14 As such, the collision model needs to rely on both the entities and the renderer to get this info. The collision model also depends on the user input due to the leftover framework files that are found in the user input component. Sounds The sound component handles all sound aspects of the game. It mainly includes sound effects, background music, any dialog, and the sound shader. It was largely unchanged from the sound engine component in our conceptual architecture. Originally, it only really depended on our game data component, but after it was split up, it s now depends mainly on the components that made up our game data component. Render: When certain animations and cutscenes play, sounds need to be played to accompany it. As such, the sound engine depends on the renderer to know which pieces of the sound track to play at those times. User Input: The sound engine plays sounds according to the user s input, particularly in the UI. Entities: The sound shader depends on the entities to know where the entities are in relation with the player. It also needs to know which entities are what so that they can make the sounds which correspond with that entity s ID. Scripting: When players do certain actions, for example, shooting, the sound engine needs to play the corresponding sound. In this case, it s the pew pew sound that comes from the gun. Library and Initializer: Like every other component, the sound engine needs to make function calls to these components. Its illogical dependencies are to: Networking: As stated before, we found this dependency to be to expedite the code. Most of the dependencies Understand listed to us logically could have gone through other components. Renderer We needed a component that would deal with the graphics of the game. It would need to hold the model images, the animations, the visual effects, the lighting, and anything else that would be seen by the user. We decided to put all of those files into a component we called the renderer. We also had the User interface that needed to be placed in our architecture. While we had debates about its logic place, we ultimately decided to place it within the rendering subsystem since the main purpose of the UI is to visually give the user information about the game state.

15 The renderer component was kept from our original conceptual architecture, though it integrated the UI component into it. After changing around the components, the dependencies we were left with were to scripts, entities, physics, and libraries. The only thing render would depend on would be initializer. In hindsight, we missed many dependencies that the renderer would have. When running through the understand program, the renderer component had coupling with every other component. Looking through the source code, it s easy to see why the renderer would depend on so many of these other components Entities: The renderer needs to interact with the entities primarily to get the model IDs for each entity. Every entity in the game needs to be rendered as that the user can tell what they are trying to interact with. Scripts: Every model then needs to be animated at every action. As such, the renderer depends on the scripting component to know what actions the entities are performing, and when entities trigger events. Physics: While some animations come straight from scripting, other animations are subject to the physics engine first. Events that have to do with knockback, falling, or collisions need to have the effects calculated before being animated. User input: When the user interacts with the UI through the user input component, scripts aren t needed. The inputs interact with the UI directly to edit options, pause, or click through dialog boxes. The renderer shows the results of these interactions depending on the user s input. Library: The renderer would need to make several low level function calls. To do this, it would depend on libraries. Initializer: Similarly to libraries, the renderer needs to call the low level abstract code in the initializer in order to run. Though most of the dependencies were logical, some didn t quite make sense to us. These dependencies are the ones we believe are illogical. Networking: While it s clear that the multiplayer option would need to interact with the renderer, it seemed more logical to us that any info from networking would go through entities, scripts or physics before going to renderer. If that were true, then there wouldn t be any direct dependency between renderer and networking, but the Understand project said otherwise. However, the small number of dependencies leads us to believe that the dependencies exist for expedite the code as a shortcut, rather any significant reasons for coupling Sound: Like with networking, there is a very low level of coupling between sound and rendering. Though we knew sound depended on rendering, we couldn t come up with a logical reason why rendering would depend on

16 sound. When we looked at the files involved, the files didn t seem to have any relation to each other. As such, we believe this dependency to be illogical. ABOUT CONCRETE ARCHITECTURE Design Patterns It was relatively hard to find design patterns in the Doom 3 source code since it was not in the same formatting as familiar programming languages. However, if we were to apply our understanding of Java into the C++ files shown, design patterns can be summarized by abstract classes in Java. However, the reuse of a function call not only can be summarized by parent and child classes, but also the reuse of common function calls or even whole classes. In this sense, we can see design patterns in much of idlib in general. As described by the modding community for Doom 3, idlib is where often used generic code is stored (2). Thus, when looking at the dependencies with idlib, much of the code reuse can be seen among all the different files within the Doom 3 source code. This is a general example of design patterns regarding code reuse. Another good example of how active components such as Entities and Scripting use design patterns for common actions. For example, in Doom 3, there are guided missiles, which need to be directed by an algorithm. In order to do this, the projectile is kept in a file as it s own entity. In order to guide the missile, the projectile goes through the Physics component to see the restrictions of how the projectile can move, and then through the Scripting component to see how the projectile should move. This is just a specific case for how an entity interacts with the environment. In a more general case, the entity is identified (identity), the entity is processed through the scripting how an object can move (Think()), how the object is to move concerning restrictions, such as collision models (runphysics()), and then the actual event that occurs (Present()). This format is evident in pretty much all of the entities in Doom 3. Derivation Process Once the updated conceptual architecture was complete it wasn t hard to derive a concrete conceptual architecture. The biggest part of the derivation process from the conceptual architecture to the concrete architecture was from the process of

17 modifying the conceptual architecture to an updated conceptual architecture, which is already explained in the Modifications Made section. Once the updated conceptual architecture was complete we began moving files by groups depending on their functions within the program. If we stumbled upon files that were not easily distinguishable, we left them as is. We believed this was the best course of action because we assumed there was a reason the file existed in a certain category. Thus, for respecting the choices made by the GitHub uploader, we also refrained for moving things whenever possible. To finalize our concrete architecture, we began running Understand to map our dependencies for each component and moving/creating files until we were satisfied with the result. For the most part, the new dependencies that appeared on top of our conceptual architecture were logical in context to the functioning of each file within a component. Architectural Style In our original conceptual architecture, we had the belief that this the architecture was simply in the style of an object oriented architecture. However, upon the derivation of the concrete architecture, it became clear to us that it followed the style of a layered object oriented architecture. This was clear to us due to the architecture keeping with an hierarchical structure for all the subcomponents.

18 Limitations of Reported Findings While mapping source files we discovered it was difficult to really understand how the main components interacted to the excess of files and the immense code base to work around this we categorized files in terms of their assume sub system and labeled the rest as MISC. files which would be left until everything else had a place in the architecture. As stated above due to the large code base we could only explore the system so deeply before the dependencies exceed a number which could be easily navigated. This meant that when we looked into specific sub systems we could only explore the dependencies within that sub system at a certain depth. The source code files we found with Understand were labeled by filename which is not the most optimal way to organize them. This meant that files belonging to a range of subsystems would be found grouped together. The only way to resolve this was go through all the folders and manually organized source files to their related sub system. The process of tracing functions back to their source was a time consuming process but in the end the class files were redirected to their intended subsystem Understand has a high learning curve. When in the hands of an experienced developer it can do amazing things. However, because we only began to use the tool a week before the presentation our level of experience and understanding of the tool was less than sufficient. At best we managed to find and sort source files and form useful dependency diagrams. Concurrency The original Doom 3 is predominantly single threaded as in it can only deal with one command at a time. It is neither able to manage multiple requests from one user nor commands from multiple users. Without being able to implement by time slicing, it is hard to recognize Doom 3 s concurrency. The lack of concurrency in Doom 3 was due to the limited technology at the time, when it was difficult to ensure that the typical computer system would be able to support multithreading. This is opposed to the BFG version of Doom 3, which was released in 2012 and supported multithreading and concurrent processing. SEQUENCE DIAGRAM

19 Figure : Sequence diagram for shooting a monster Here we have our updated sequence diagram for Shooting a Monster. It begins at Input Command where it accesses certain keyboard input files and contacts scripting. From scripting we have 3 main actions that take place. The Animation Action where Scripting contacts the Renderer and accesses Model and animation files. and outputs the bullet animation to the screen. The second action consists of contacting the sound subsystem, accessing the sound files and creating the necessary noises on the user's console. The third action is managing the calculations for the bullet interactions with the monster. This step involves contacting physics to retrieve bullet pathing information for the gun being used as well as calculating the monsters knockback/stagger at point of contact. Scripting also contacts entities to retrieve damage dealt to monster based on the monster model/hp files located in entities. This is all then amalgamated and output through the renderer to show the monsters reaction. To finish the players animation lock is removed so he can input another command. DEVELOPMENT TEAM ISSUES A big issue for the team was the advancement of technology. Due to the fact that it took over 4 years to develop Doom 3 when it was released modern technology was able to support much more than what Doom 3 had to offer. A good example of this is concurrency. Doom 3 (original) saw little to no multi threading this was due to

20 the fact that many computers at the time worked on a single CPU. Even though the doom engine could support multiple threads the team had to revise the game to run single threaded so it would function on all platforms it was intended for. This is why the bfg version was easily able to incorporate multi threading. The base was already set and simply had to be utilized. The team also ran into development issues throughout the span of game development and the game ended up taking longer to release than initially intended. I believe that the issues were most likely related to threading and dealing with the large code base. The large code base especially stands out because of the amount of dependency the subsystems have between one another. Also have to document and properly format would have been a real issue. LESSONS LEARNED Using Reflexion Analysis we were able to clearly define our concrete architecture and refine our existing conceptual architecture. Doing this we had to map various files to the subsystems we thought they belonged in. Explanations for the dependencies we derived during the stages of the Reflexion Analysis are stated under the Reflexion Analysis section Many Errors occurred throughout the process of deriving out concrete architecture. Initially we had a conceptual architecture that needed updating and as we began to add/remove and combine sub systems we realized that there was a lot of mapping to do before we could realize a potential concrete architecture. Other errors involved our Sequence Diagram being too general when we should have gone into a specific sub system to describe full the functionality the code and components of the system play in realizing a task. Even after several lengthy meetings, our Understand mapping was not very accurate to what we wanted as a result. Some files were not readily identifiable and thus thrown around or left unchanged, which have lead to very minor dependencies which may or may not have been. Having Understand to help us organize and manage the source code files of Doom 3 was extremely useful. Although no one in the group managed to fully utilize the program we were still able to use it to map files and discover dependencies we did not know previously existed. If we had tried to manually map and discover dependencies it would have taken a lot longer than it did. Having a tool to organize source files into dependency diagrams proved to be really useful Definitely hard to manage the report when there are six people actively working on it. Since we could not meet up during the week to work on finalizing our report, we worked separately on our own parts and ended up exceeding the page limit. For the next time, we should list the requirements and set a length limit rather

21 than assigning each group member various tasks to complete on their own without a plan. CONCLUSION We managed to re define our new updated conceptual architecture and define a concrete architecture by using Understand to manage source files to develop dependency diagrams that helped us to find what dependencies we expected and which were unexpected. Using a method called Reflexion Analysis we were able to consistently compare our conceptual and concrete architectures and update them based on what dependencies we found between both of them (expected dependencies) and the connections we only found in the concrete architecture (unexpected dependencies). After updating our conceptual architecture and studying our concrete we found that it followed a loosely layered and objected oriented architecture. We ve covered all of the major components, we ve also covered their sub systems and dependencies in detail with reference to our architecture. As we further studied the architecture we found that concurrency was not a large part of the game because of the technological limitations of the time and we identified design patterns as the use of certain abstract calls and patterns for calling functions from various parts of the system. Overall, Understand helped us to redefine our conceptual architecture and create a solid concrete architecture which helped us to develop a thorough understanding of Doom 3 s overall architecture. CONTAINMENT FILES Link to Understand project files: GLOSSARY Artificial Intelligence (AI) - The capability of software to mimic intelligent human behaviour Bit Message - Layer above the Message Channel heavily involved in compression/decompression and manipulation of data that is to be packaged. Client Server - One of many types of architecture styles, client server focuses on servicing many clients that seek information from a single server Common System - System that starts/shuts down all other system id Tech 4 - The game engine developed by id Software for Doom 3 Message Channel - Layer above the UDP that is involved in basic compression and converting messages to packets (Snapshots)

22 Packet Server - In Doom 3, a packet server is connected to one of the players in a game and eliminates the need for all players to have a low latency connection to all other players in the game Peer-to-peer Network - A form of network system that is used in multiplayer games Potentially Visible Set (PVS) - The current environment the player is experiencing including all active entities Snapshots - Data packets transferred over a network. Snapshots carry vital information about current game state and all active entities User DataGram Protocol (UDP) - A designated way to send messages from the server to client and vice versa. Not the most secure method but the delivered messages are never corrupt User Interface (UI) - Everything designed in an information device with which a human can interact with REFERENCES 1. Bowman, Ivan T., Richard C. Holt, and Neil V. Brewster. "Linux as a Case Study: Its Extracted Software Architecture." N.p., n.d. Web. < >. 2. Id Software. "Making DOOM 3 Mods : The Code." Doom 3 Software Development Kit. Id Software, Web. < >. 3. Sanglard, Fabien. "Doom3 Source Code Review: Introduction." Fabien Sanglard's Website. Fabien Sanglard, 8 June Web. < >. 4. Sanglard, Fabien. doom3_notes.txt. Fabien Sanglard s Website. Fabien Sanglard, Web. < >. 5. TTimo. "Doom 3 GPL Source Release." Github. Github, 7 Apr Web. < >.