1

Architecture Enhancement Report CISC 326, fall 2015

For Ahmed E. Hassan

Due 4 December 2015

By GROUP OMG ­ http://cisc326groupomg.wordpress.com/

Joshua Lee 10112488 13jl45@queensu.ca

Nelson Yi 10105387 13ny@queensu.ca

Andy Chu 10099889 12sc133@queensu.ca

Percy Teng 10122592 13spt1@queensu.ca

Hassan Haq 10061306 12huh@queensu.ca

Simon Zhang (primary contact) 10111843 13skhz@queensu.ca

2

TABLE OF CONTENTS TABLE OF CONTENTS 2

ABSTRACT 3

INTRODUCTION 3

OUR FEATURE: COOPERATIVE PLAY 4

Implementation A: Local Co­op 4

Implementation B: Online Co­op 5

SAAM/ATAM Analysis 6

IMPLEMENTATION CHOSEN 8

Sequence Diagram 8

Potential Risks and Limitations 10

Impacted Subsystems 10

Concurrency 12

TESTING/IMPACT ANALYSIS 12

TEAM ISSUES 13

LESSONS LEARNED 14

CONCLUSION 15

GLOSSARY 15

REFERENCES 16

ABSTRACT

Adding additional game play modes like a cooperative campaign boosts the appeal of the game and allows it to reach a larger audience. As such, we looked at popular existing ways to implement a feature like this, local split­screen and online connection. In order to analyze which implementation would best suit doom 3, we conducted a SAAM analysis to weigh the pros and cons of each in relation to the nonfunctional requirements for the game. Though both had their merits, we ultimately concluded that using the online capabilities of the game in order implement this game mode would be optimal for both the developers and the users. We then looked at various use case diagrams and existing architecture in order to understand how the feature would affect and interact with the existing features and components. We considered the risks and costs of implementing this feature and concluded that with experienced developers, such a feature would likely not be a large problem to implement. The Doom 3 architecture is based around an object

3

oriented/ layered design, which will not need to be changed to accommodate the addition of this feature.Due to this architectural style, updating the system will be easy, especially since it is possible to change the way we implement the system without affecting clients due to the nature of the object oriented architecture.

INTRODUCTION

Doom 3 is a revolutionary game that stole the gaming market late 2004; the game successfully implemented features that were not yet seen before its time, which allowed the series to continue further into future productions. Doom 3 was a large AAA game project that required the whole id Software because of the fact that it pushed to utilize all the latest technologies and methods for creating a game. However, due to the nature of this ideation, it was evident that most current systems at that time were unable to run the Doom 3 engine in the first place. In essence, the id Software team had to take additional time into downgrading several components to account for most user demographic computer systems. One of the major changes that id Software were forced to make was converting from a game revolving around a multi­threaded system into a single­thread system. In the later Doom 3 BFG version, not only were the downgrade changes reverted, they were able to release the system into multiple game console platforms.

For the A3 Doom 3 report, we will answer the question as to how easy the changes really were. In order to get a good understanding of the matter, we will suggest a new feature that is not already existent in the Doom 3 engine and speculate the effect that it will have in other subsystems of the game architecture. We will be covering the SAAM and ATAM analysis for the decision process upon choosing which implementation for the new feature is most advantageous. After evaluating each of the pros and cons of the different implementations, we will discuss, in depth, the changes that occur in the architecture of Doom 3. This will be done by looking through the source code and seeing which of the files and codes are affected by the new feature, which will evidently lead us into seeing the following subsystems that are affected by the addition of the new feature. By this method, we can identify the difficulties in deciding upon features, the complexity of modifying existing code to account for the new feature, and the different effects the new feature as upon running the game.

The report is organized in fashion where when a text is capitalized, bolded, and underlined, it emphasizes the category of information in which we will be discussing. The green texts indicate the topic of which the report will be covering. Whenever there is a diagram or picture of reference, there is a “Figure:” text and an explanation as to what the visuals signify.

4

OUR FEATURE: COOPERATIVE PLAY

The new feature that we implemented is a feature to allow players to play cooperatively as in Coop mode. This would allow players to play with friends through the campaign. Cooperative play exists in many games and is a very prevalent feature. It’s draws include being able to experience the game with friends against some virtual enemies, which is a very different experience than playing alone. Since this is a brand new game mode, people will have their great time figuring out the new strategies and teamwork for this mode. It will also potentially attract some certain crowds who are just looking for some fresh features. They could be new customers or customers who return just for this new mode. It provides tremendous replay value.

Implementation A: Local Co­op

Our first potential implementation is local split­screen. This would allow multiplayer using one system and one copy of the game, with no networking required. This would happen by separating the screen in half, with each half being a player’s perspective. The additional player would interact with the game using either an additional controller or an additional keyboard/mouse combination.

Figure: A mock­up of what split­screen co­op would potentially look like.

Being local and requiring no networking, an advantage of implementing co­op using split­screen would make it easier to implement for the Developers. Since everything is local, security is less of an issue as man­in­the­middle network attacks, encryption, eavesdropping, tampering, or any potentially malicious activity all do not

5

need to be worried about. Being in the same room with your buddy that you’re playing with is a more emotional, intimate, and fun experience playing with your friend.

However, it can be a clear downside having to be in the same room. If you don’t live close to the friend you want to play with, you’re out of luck—split­screen play do anything for you. An additional controller or an additional keyboard/mouse combination would also be needed. Splitting the screen would make both players see a smaller portion of the screen, reducing usability. This is something I’m sure anyone who has played split­screen is familiar with. Performance would also take a hit with split­screen play. Rendering multiple perspectives would strain hardware and take more resources—resources that were limited at the time in 2004.

Implementation B: Online Co­op

Our second possible implementation is online multiplayer cooperative play. This would allow any two people with copies of Doom 3 to play co­op with each other over the Internet, from anywhere in the world. Of course, this is theoretical, as the latency between players increases the farther the players are from each other. This can make playing with friends far from yourself impractical, but online play is still much more practical than co­op, where they must be in the same room.

Figure: A mock­up of what online multplayer cooperative play would potentially look like.

While network code has already been written for the multiplayer mode already in Doom 3, additional servers would need to be implemented. This introduces several limiting factors, mainly maintainability, cost, and security. Back in April 2014, it was announced that the GameSpy servers that hundreds of games that relied on for their multiplayer play would be shut down (2). This is an example that servers must be maintained in order to continue permitting players to play the multiplayer portion of the game. Costs would also be involved in maintaining the servers, and

6

any potential hacking efforts would need to be avoided through encryption and any other man­in­the­middle attacks, tampering, or malicious activity would need to be avoided. Online play would rely almost completed on the internet connection of the Player, as well. Stability, reliability, and robustness would all rely on the internet connection of the player.

SAAM/ATAM Analysis

For the process of deriving our SAAM and ATAM analysis, we listed potential stakeholders, and listed potential NFRs relevant to the system. Since NFRs can have several different meanings depending on the context, we defined the NFRs for each stakeholder and categorized them under the stakeholder according to how significant it is to the stakeholder than to other relevant stakeholders.

Players Developers Testers

Reliability Modifiability Testability Performance Reusability Maintainability Usability Interoperability Capacity

The biggest concern with this is that we cannot compare NFRs with actual high quality measures due to the fact that the implementations are not official. This prevents us from making actual comparisons based on actual performances and coding architectures with the implementations. For this reason, we make speculations upon the quality of the NFR in context of the implementations A (Local co­op) and B (Online co­op) and give a relative quality accordingly. We then compare the pros and cons of each NFR given each implementation choice and display whichever pro or con outweighs the other. For each NFR upon each implementation, we generalized the quality of the NFR into categories of either Good, Bad, or Tolerable. If the NFR is essentially Good for the implementation, the advantage of the implementation will have to clearly reflect the pro of looking at the NFR and the same idea applies for a Bad NFR quality. If the NFR quality is classified as Tolerable, there are aspects of the implementation that are relatively bad, but is balanced by another reason. For the sake of highlighting the most important NFRs that apply to the system relative to both implementations, we compared several of the identified NFRs that had the most impact to making a decision between the implementations. The chosen NFRs revolve around the player’s end because the end user is the more likely than not, the player.

7

Stakeholder + NFR Description A: Local co­op B: Online co­op

Players/Users Performance

How well does the system respond to player input?

Good The response time is always as good as the player’s system

Bad The response time is as good as the bandwidth of each player (uncontrollable factor)

Players/Users Usability

How easy is it to use the new feature?

Bad Since this is not BFG, we cannot simply pick up another controller

Good The player only needs a computer to utilize this feature

Developers Interoperability

How well does the system work with other systems without extra user effort?

Bad To account for another player, the developer has to consider another set of controllers and utilize the single processor

Good Two players utilize the network in order to concurrently process two computer inputs

Testers Maintainability

Can the new feature be maintained and errors can be fixed easily?

Bad Once the game is released, people with no internet access can no longer have bugs fixed

Good Minor to fatal errors in the code can be fixed through patches and updates

A key thing to note is that Usability and Interoperability are very close as to what they evaluate for each implementation. This is because this is one of the biggest concern that Doom 3 has in making the implementation a reality. If we summarize both these NFRs they cover the fact that the player using local co­op cannot essentially use local co­op without modifications to their existing PC setup. Local co­op may require either a split­screen, dual screens, and most importantly, two set of control inputs. This means that we may require either two sets of keyboards and mouses, or another means of controlling the other player. This confusion is also something that the developers will have a concern with as well. It is unclear as to how local co­op will occur without making significant changes to the existing subsystems.

IMPLEMENTATION CHOSEN

After evaluating the SAAM and ATAM analysis, we have concluded that the online co­op implementation is the best implementation for co­op. As stated earlier, the biggest problem for the local co­op is actually making it happen. Since the Doom 3 original version only has a single­thread system, it would essentially require making it multi­threaded to account for the second player. Online gaming is also the

8

current trend in gaming as seen in many current games. It would be more accessible for users since they wouldn’t need to be near each other in order to play together and they wouldn’t need additional hardware in the form of more controllers. However, since these features aren’t mutually exclusive, it’s possible to add both versions of coop and ideally we would in order to make the feature accessible to as many players as possible.

Sequence Diagram

The figure below illustrates the general situation where two players are playing through Doom 3’s campaign in Online Co­op. The client player is located in Canada, while the server­side player is located in Germany. This sequence diagram focuses on illustrating the scenario where the Canadian player launches a rocket launcher, the projectile must be also rendered on the German player’s screen. The majority of the components belong to and are processed on the Canadian player’s screen. This is because the client side’s renderer has a function that sends a copy of the client’s rendered world through the network so that it can be rendered through the server side user’s renderer. This process saves significant amounts of time and resources. A description of the steps through the sequence diagram is listed below: When the Canadian user clicks on the left button of his mouse, the user input component recognizes this input as a left click from a PC mouse. It sends the nature of this input to the Scripts component through the handleMouseEvent() function. The Scripts component takes this input and compares it with the current situation in the game. Since the player is holding a rocket launcher and the key input if a left mouse click, Scripts determines that a projectile will need to be rendered. It then initiates idTrigger::idTrigger() to further process the outcome of using the weapon. The next step is to go into the Entities component to determine the pre­rendering behavior and characteristics of the projectile (Shape, resulting particles properties). Furthermore, The method IdVec3 idProjectile::GetVelocity(const idDict*projectile) in the entities components gives the velocity of the projectile. The next step is to go into the Physics component to use the determined velocity to assist with the animation of the projectile during rendering. After animateBullet(angle, velocity) is called, the process goes into the Renderer component, which takes all the data processed in the previous components and renders (visualizes) the game world for the Canadian user. Up to this point, all the processes have been completed on the client side’s components. The Renderer then sends the data of the just­composed game world through the Network component. The German player’s renderer then takes the data and renders the projectile on his screen.

9

Figure: A sequence diagram for shooting a rocket.

Potential Risks and Limitations

Since we chose to implement the online implementation, the feature is limited by the same limitations that the multiplayer mode has. Most notably, the player experience is still dictated by the network connection. Though doom 3 has a client predictive model that seeks to limit the impact of a poor connection on player experience, in practice a poor connection still greatly affects the overall experience. This feature will be subject to the warping issues due to miscommunication between the client and the server due to this. Also, players may be vulnerable to ddos attacks, like with any other online feature. The effect of a poor internet connection may make this feature inaccessible to some. Adding players to the single player campaign would increase the number of things happening, which means that the system would need to process more things and performance would decrease in order to accommodate this. The biggest limitation on our feature would be the need for extensive knowledge on C++ in order to code in the addition files needed. Many new files are needed to be added for features like the communication system and friendly fire. Since these features don’t exist currently, they would need to be coded from scratch. In addition, the developers would need to understand the doom 3 architecture and files very well. Both the communication system and the friendly fire features would need to call various other functions from other files. Also, they would

10

need to understand the multiplayer files in order to reuse the code effectively and edit values in the entities files to reflect the varying difficulty.

ARCHITECTURE

Impacted Subsystems

Figure: Our conceptual architecture for Doom 3

Many of the components in our architecture will be affected in order to implement a coop campaign feature. In order to implement a coop feature, we would need to affect the entities and the scripting engines. If we were to implement the local split screen version, then the renderer and the user input components would need to change as well. Using the online version, the networking component would be utilized as well as either the sound or the renderer components. Despite all of the affected components, our overall architecture will remain the same. Many existing dependencies are strengthened by the inclusion of our new feature, but since our architecture is already highly coupled, no new dependencies are needed.

In order to add any kind of coop at all, we will need to edit the scripting and the entities components. In our architecture, the scripting component handles all scripts, triggers and AI files, the main ones that concern us regarding coop are the scripting files. These files hold the possible actions for each entity. In this component, we will need to add files that detail any new interactions that the players will have. Also friendly fire is something that is sometimes disabled in coop shooters. Friendly fire would allow players from hitting each other to prevent stray bullets from accidentally killing each other. If we were to disable friendly fire in Doom 3, we would

11

need to add tags to the projectile.cpp file that specifies whether a monster or a player shot it. Then, when the collision model in the physics component notices that a projectile has hit a hurt box, the trigger.cpp file in the scripting component will trigger a damage event. This would be where the health function in the Player.cpp file would decrease, but instead, we would have it check the newly added tag in the projectile that hit it first. If the tag was from an allied player, then damage would be set to 0, otherwise it would proceed as usual.

The entities component would need to be able to handle multiple player characters, but more importantly, it would need to change the difficulty of the game. When we add more players to the game, each player has their own ammo, health, and contributes to the damage to the enemies. So, we need to change the difficulty of the game to handle this. Since having two players would effectively double the amount of damage done to the enemies, the game would be far too easy if it wasn’t adjusted. As such, we would need to go into the entities.cpp file in the entities component, which holds monster data, and adjust the health and damage so it’s proportional to the number of players. In addition, we would also need to adjust the spawn rates of the items, specifically the health packs and the ammo, to accommodate the multiple players.

Should we choose the use the local play implementation idea, we would need to edit the user input component to track which player input which input. To do this, we would tag the commands in the usercmdgen.cpp file to hold the player controller number. The entities would then only receive the commands that are tagged with their respective controller numbers. We also need to adjust the renderer component to only show half of the screen so that we can show both players screen. We could do this either by compressing the existing vision set or by halving what the player can see as found in the vision functions in the actor.cpp file in entities. Either way, we would then need to add a function in rendering to split the screen in half to show both the viewpoints on the screen at once.

If we chose to implement the other implementation, online coop, then the major component involved is the networking component. For this implementation, we will be able to reuse a lot of the existing code in the NetworkSystem.cpp file. Since online coop would have many similarities the existing online multiplayer mode, we can use those files to connect to the client server network and send and get the game states to function. Though not necessary for the feature to work, nearly all games that feature online coop also have some way for the players to communicate with each other. For doom 3, we would implement this with new files in either the renderer or the sound components. Both of these would be called by the user input component either by adding microphone support and letting the players communicate with each other with speech, or having a chat box on the screen that could be typed into using a virtual keypad on a console or a keyboard on a pc.

12

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. Even with our new implementation, it does not add more concurrency.

TESTING/IMPACT ANALYSIS

Our Chosen enhancement, Online Co­op play is in large parts similar to the already implement Doom 3 Vs. Mode. In the Online Vs. mode multiple people are gathered into the same room and set up with different game modes with the final goal being to eliminate the other players. Our Co­op feature would be only 2 players. Using the existing network they would work together to play through the campaign with some extra bonuses. Before we can implement something that affects the game on such a large scale we would need to test the feature and ensure that no game breaking bugs are carried onto the final version.

As we were brainstorming how to test the feature to cover all of its effects on the architecture we realized that the feature is greatly similar to the online Vs. mode. In terms of the network connection, It’s effect on the rendering and scripting subsystems. The largest change would come from the implementation of the Team Communication system which has its roots in the Sound subsystem.

To test the new feature we would run various high level tests such play testing or BETA testing. This usually involves choosing a few select individuals from amongst the target consumer base and allowing them early access to the new feature. While they play in game bugs that may have been missed during initial testing can become apparent and it provides us a chance to fix them and prevents the launch of a faulty feature. With a game mode like Co­op BETA testing is key and many of the bugs from the implementation are easy to catch as players go through the various stages of the game. Player­Player, Player­Environment, Player­Monster and Player­Entity interactions are really clear to see. Also, since the the doom campaign is reasonably sized and in various different environments it provides testers a chance to see exactly how, when and where bugs can occur and fix multiple areas of the source implementation at once.

A really useful outcome of implementing a network based co­op system is that we already have a large base of tests that we can run to make sure the technical

13

aspects of the implementation are running smoothly such as the players connection to the other player. These tests can be derived from the existing test suites used for testing on Doom 3 Vs. modes. Tests for the network, scripting and Entities subsystems can in large part be re­used. For the network subsystems test suites can be reused from Online Vs. mode. This will cover a large part of player­player interaction and connection. Scripting test suites can be reused from the normal campaign mode since both players interactions to the monsters and environment will be similar. Tests will however need to be run to ensure that the game reacts properly to two players running similar actions such as monster hp decreasing accordingly. A similar event occurs for testing the effects on Entities from the co­op play. Test suites can be used from Online Vs. mode and from the original single player campaign. The largest change will probably occur in the Sound subsystem when we need to run tests for the Team Communication systems. This however can be easily testing in high level play testing.

TEAM ISSUES

Deciding on a Feature Everyone on the team had a different idea of what feature we should

implement. We brainstormed various ideas and their effects on the architecture and how we could implement each idea two ways. To shorten down the list we chose ideas that were easy to research and had a good amount on documentation. Ideas were also separated based on how easy it would be to implement and test the feature and the time it would take an actual development team to get the feature up and running. Since cost and time are big factors in real development.

Scheduling

As we approach exam periods a lot of deadlines for all courses begin to appear at once. So finding time to meet up with the team and iron out a proper plan for the presentation and report was difficult. However we managed to schedule short meetings where we would meet and talk about how we wanted to end to realize our feature.

Knowledge Since this is the first course in Queen’s where we’ve tackled the

problem of dealing with software architecture our knowledge and experience with the subject is still lacking. In A1 and A2 we had documentation and existing source code to read and learn from but for this project we had to actually create, “implement” and “test” a new feature. At first we were kind of lost with figuring out how features are added and fit into the lifecycle of game architectures but by doing

14

research and studying our architecture it started to become a little more clear how we were meant to work with out architecture.

SAAM/ATAM Analysis. We’ve never encountered this form of analysis but we were able to iron

it out by studying documentation we found online such as analysis of other similar systems.

LESSONS LEARNED

Carefully choosing a new feature We found that many of the ideas we suggested at face value had two

different implementations. Such as finishing moves (Manual/Automatic) or Dual Wielding(Large/Small Weapons). However, when we went to study the effects on the architecture their implementations were too similar to call them different features.

Documentation Online Our proposed feature (Online Co­op) is implemented in many games

on many different consoles and is greatly talked about in the gaming community. We had access to so much documentation that any problem we encountered was easy to research. We also found good documentation on how to implement the feature and how to most effectively test it.

Difficult to Split Work As we began work on this feature we found that it was required us to

meet very often so that when we worked on different parts of the report and presentation we were all working along the same lines. It required the whole team to wholly involved.

CONCLUSION

In conclusion, our proposed feature was the implementation of a Campaign Co­op Mode. The two implementations we had in mind were Split­Screen Co­op and Online Co­op. In the end we chose Online Co­op due to less severe effects on the overall architecture of the system. Online Co­op was also a more cost effective solution as many more people would have access to the feature and each player could play with a larger gamer base. Our SAAM Analysis was also quite clear on the positive and negative affects that adding a Co­op feature would cause to the game and how it would affect the various parties involved. A huge positive to implementing an Online Co­op feature was that we would not need to worry about the game mode affecting the overall architecture too much. Online Co­op is in essence a different version of Online Vs. and so it was a better choice to implement it over split­screen.

15

Another plus was that when testing our feature we could reuse many of the test suites already set up to test Online Vs. and the campaign mode of the game. We faced many challenges as the development team of the this new feature but using what we’ve learned from A1 and A2 we were able to overcome these obstacles and in the process learn a lot about the game architecture of Doom 3 and how implementing a feature is both a challenging and rewarding experience.

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. <http://cs.queensu.ca/~ahmed/home/teaching/CISC326/F15/files/icse99.pdf>.

2. Dyer, Mitch. “GameSpy Multiplayer Shutting Down, Hundreds of Games at Risk” IGN. Ziff Davis. 3 Apr 2014. Web. <http://ca.ign.com/articles/2014/04/03/gamespy­multiplayer­shutting­down­hundreds­of­games­at­risk>.

3. Id Software. "Making DOOM 3 Mods : The Code." Doom 3 Software Development Kit. Id Software, 2004. Web. <https://www.iddevnet.com/doom3/code.php>.

4. Sanglard, Fabien. "Doom3 Source Code Review: Introduction." Fabien Sanglard's Website. Fabien Sanglard, 8 June 2012. Web. <http://fabiensanglard.net/doom3/>.

5. Sanglard, Fabien. “doom3_notes.txt.” Fabien Sanglard’s Website. Fabien Sanglard, 2012. Web. <http://www.fabiensanglard.net/doom3/doom3_notes.txt>.

6. TTimo. "Doom 3 GPL Source Release." Github. Github, 7 Apr. 2012. Web. <https://github.com/TTimo/doom3.gpl>.