Co-op Campaign in

DOOM 3Unnamed Space Marines

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

Overview

1. Introduction of New Feature2. 2 Ways to Implement Feature3. SAAM Analysis and Tradeoffs4. Chosen Implementation5. Impact on Architecture and Testing6. Sequence Diagram7. Team Issues8. Effects of Concurrency9. Lessons Learned

10. Limitations of Findings11. Closing

Introduction

Co-op CampaignDoom3 has a singleplayer mode and Player vs Player multiplayer

We will implement Co-op multiplayer gameplay to allow two users to play through the

story mode together

Implementation 1

Local co-op (splitscreen)

Implementation 2

Online co-op (dedicated servers)

Comparison of 1 and 2NFR Implementation 1 - Local Co-op Implementation 2 - Online Co-op

PerformanceThe game must run consistently at 60fps on modern hardware.

HIGH - two views of the game must be rendered at the same time on the same machine which

will require twice as much GPU power

LOW - each player’s machine is only responsible for rendering one view of the game; very little difference in

rendering requirements

AccuracyGame state on the local machine at most 0.5s behind during co-op so that the person connecting can play the game without lag.

LOW - not dependent on anything other than the instance of the game running on the local

host machine

HIGH- highly dependent on client connection and packet loss. If one player has a poor connection to the server, then this will cause player position and game state on the local machine to be slightly out of sync with the server. Weapon fire hit accuracy may suffer

as a result.

PortabilityCo-op must not use any API specific to a certain console to allow for portability to Xbox, PS3, Windows etc

LOW - Local co-op does not depend on any external APIs to function properly, since the only

changes that need to be made are within the gameplay foundation subsystem.

MEDIUM - If the network API chosen to implement online co-op is not well abstracted and platform

dependent, this might make moving to new consoles more challenging.

Comparison of 1 and 2NFR Implementation 1 - Local Co-op Implementation 2 - Online Co-op

MaintainabilityCode for implementing co-op should be reasonably focused and modular in order to be reused. Coupling between components should be minimized through good use of design patterns.

LOW - System simply needs to keep track of two players’ queued events and render two

instances of the game; no need to send events or states back and forth and can synchronize

into one state.Modularity can be preserved in AI behaviour as

well, since this requires only detecting the number of players (for scaling) and targeting.

MEDIUM - More components will be affected than in local co-op, so this may complicate the dependencies and force coupling.

Saving, sending, and receiving events may need to be more complex in code and less focused in order to handle the

sequence of many events and synchronize them properly; two states are updated at one time.

InteroperabilityLocal co-op should use common file formats and protocols so that information exchanged between clients is simplified.

LOW- little to no extra exchanges on local system, not dependant on any external systems

besides what is required to run the game

MEDIUM - online services such as Xbox Live and PSN should use standardized protocols which extend to all their systems but

PC hardware and software may differ and cause issues for content and bug patching

ReusabilityCo-op must be able to be exported as a mod or library to interface with as many systems and hardware as possible and abstracted well, with flexible code and adaptability

LOW - Local co-op code is only dependent the gameplay foundations subsystem. These subsystems are well abstracted and not

dependent on specific system APIs.

MEDIUM - Online co-op can be implemented using a client server architecture. Thus, it would be easy to reuse the code on different platforms assuming that network communication is well

abstracted on different platforms. This may not be the case depending on the API, however.

Comparison of 1 and 2NFR Implementation 1 - Local Co-op Implementation 2 - Online Co-op

CapacitySystem must handle co-op between two players while maintaining performance objectives.

LOW- As each co-op instance is run on a local computer, there is no impact on server capacity

MEDIUM - The servers should be able to support up to thousands of players creating and running co-op games at one

time while maintaining performance objectives

ManageabilityOnline: The dedicated server should be online and functional all but 2 hours per week, which are set aside for weekly server maintenance. Automated tests should exist for all affected components.

LOW - Local co-op only runs on the local machine, so server testing and downtime is not a factor.

MEDIUM - must be able to collect data and player statistics relating to peak usage times and average number of users

online at any given time to be able to schedule downtime for the server and to know what server capacity is needed

Logging bugs reported by players should also be possible.

Stakeholders

Managerial

- CEO- Project managers- Sponsors/Investors

Development

- Software developers- QA team- Artists- Voice actors

Users

- Players

Pros and Cons

LocalPros

• No internet connection required!

Cons• performance takes significant hit rendering two views of game on same machine at once• requires another person to be present in the same room to play and a second I/O device

OnlinePros

• Ability to engage in remote gameplay with distant users• You don’t need a specific individual to play with you - random matches can be made

Cons• capacity of server limits the amount of users able to play at once

Chosen Implementation

Online Co-op Campaign : Dedicated Server

- Performance will be too severely reduced if we implement a local co-op (running two views of the game will be very taxing on one machine)

- Capacity will be restricted, but the ability to scale-up or scale-out the dedicated servers will allow any number of users to be accommodated

- Players may connect with remote users (benefit to players)

- Dedicated servers instead of P2P because they are less dependent on player upload speed

Impact on ArchitectureClient-Server Architecture Affected Components:

● Gameplay Foundations:○ enemies need to target not one but

two players now (AI behaviour should change)

○ difficulty / strength of enemies may need to be scaled up

● Network:○ must have dedicated servers

available for matchmaking players into co-op missions

○ must been able to support thousands of players

Testing

• Potential automated testing methods• In order to test the integration of co-op mode fully, it is necessary for two people to play the game

using online co-op• This eliminates the possibility of using automated integration tests, since this has to be

carried out manually• Certain tests can still be automated

• unit tests that verify that the client machine can connect to the dedicated server• unit tests that verify that the server is receiving campaign game state properly• unit tests that verify that the server is sending campaign game state to client machine

properly

• Potential manual testing methods• QA team testing• code inspections• code walkthroughs

Firing a bullet and killing an enemy in a multiplayer setting

Team Issues

- Team needs to add more software QA testers

- Existing functionality may not be tested as fully during feature development

- More server capacity is required (must scale-up or scale-out)

- More technical support staff will be required upon initial release of game

- Hard to verify the connection quality in all geographical locations

Effects of Concurrency

• Our feature does not require the use of multithreading due to the fact that it uses a client-server architecture

• Major performance bottleneck is network connection, not local machine hardware

Limitations

- We have limited knowledge of specific Doom3 gameplay details (none of us have played it)

- Unclear distinctions and overlap between NFRs in SAAM analysis (e.g. Manageability vs Maintainability, Portability and Maintainability)

- Inability to actually implement proposed feature due to lack of resources

Lessons Learned

- Hard to speculate about the performance (and other NFRs) of a system without actually implementing the feature

- Difficult to think of quality NFRs with limited game development experience

- Hard to stay motivated in the last weeks of class!

Closing

Co-op campaign : Online using Dedicated Server