Espionage Game Design Document

Espionage Game Design Document

Agents Provocateurs Liam Davidson, Bethany Dunfield, Alex Eady, Justin Loranger­Ahluwalia Last Updated: 14­11­07

1

Table Of Contents

1. Game Design 1.1 Summary 1.2 Gameplay 1.3 Mindset 2. Technical 2.1 Setting 2.2 Interface 2.3 Controls 3. Level Design 3.1 Agent­Specific Missions 3.2 Location­Specific Missions 3.3 Game Flow 3.4 Neutralising Agents 3.5 Exposure 4. Development 4.1 Technology 4.2 Portfolio/System Data 5. Assets 5.1 Style Attributes 5.2 Graphics Needed 5.3 Sounds Needed Appendices A. Marketing Plan A.1 Market Analysis A.2 Sponsorship A.3 Promotional Event A.4 Promotional Media A.5 Social Media A.5 Session Starter Package B. Testing Plan B.1 Development Testing Procedure B.2 Promotional Event Test C. Project Plan C1. Deliverables C2. Schedule 2.1 Work Breakdown Structure 2.2 Schedule C3. Resources 3.1 Team Structure 3.2 Hardware 3.3 Software C4. Risk Analysis 2

4.1 Risk Factors 4.2 Preventive Actions 4.3 Corrective Actions C5. Policies 5.1 Change Control Policy 5.2 Communication Policy 5.3 Quality Control Policy

3

1. Game Design 1.1 Summary Espionage is a multiplayer spy game that takes place in the real world. Players use their mobile devices to complete missions, gather intelligence, and outsmart their competition. The goal is to be the last player standing in free­for­all gameplay periods called operations.

1.2 Gameplay Gameplay sessions take the form of operations. The goal in each operation is to be the last agent standing, or the living player with the highest score at the conclusion of the operation.

This is accomplished by gathering intelligence on the competing agents and neutralising them. In the course of play, agents must avoid being exposed by their actions or through the actions of others.

1.2.1 Operations Gameplay sessions are called operations. Their duration and the geographical area of play can vary based on constraints set by the developers or the promoters of a given operation.

For example, a general operation may cover the downtown core of Ottawa and last one month, where a team­building operation sponsored by Carleton University may only last a weekend and be constrained to the boundaries of the campus.

Operations end early if only one agent remains un­neutralised, and the last remaining agent is the victor of the operation. However, if the operation time expires without there only being one remaining agent. the victor is the active agent with the most extensive intelligence dossier.

1.2.2 Intelligence Gathering Before players can neutralise competing agents they must identify their enemies. This is accomplished by performing intel gathering missions that provide information on competing agents and is stored in an intelligence dossier. Information on enemy agents takes the form of a 4 tiered system.

Tier 1 The name of the enemy agent is registered in the intelligence dossier.

Tier 2 The enemy agent’s profile now shows biographical information and statistics on how many missions this agent has performed and how many targets this agent has neutralised.

4

Tier 3 The enemy agent’s profile now shows the locations of missions and an the agent’s area of operation (estimated using their check­in locations) on a mini­map.

Tier 4 The enemy agent’s profile now includes a picture of that agent. The neutralise action is significantly more likely to succeed.

1.2.3 Neutralisation Players are eliminated from the game when they are neutralised by a competing player. When only one active player remains the operation ends. Players may attempt to neutralise anyone they know to be an agent; success is determined by proximity and the level of intelligence gathered on that player.

1.3 Mindset Gameplay requires daily usage to participate in an operation. Players must, at a minimum, check in using their mobile device at specified times in order to be considered active in the game. This is to encourage a mindset of ongoing play; each player should think of themselves as an agent and be aware of those around them as potential competitors. Although the game is structured in such a way that free­for­all competition is encouraged, it is possible for players to align and collaborate against each other, in this way players are not limited to one play­style, but can devise new strategies that suit them best.

5

2. Technical 2.1 Setting 2.1.1 Augmented Reality Espionage is set in the real world and, aside from the phone interface, takes place in physical space. Players will be able to alter the world around them by, for example, performing missions to booby­trap or bug certain areas or by travelling to destinations to complete specific tasks. While players will not literally be placing traps or bugs in locations, the integration of phone GPS ensures that physically travelling to locations and interacting with the real world is a core component of the gameplay

2.1.2 Phone, GPS, and bluetooth Players will make use of their mobile phones to play the game. The GPS functionality of the mobile device will be used to track player positions. This, in tandem with bluetooth communication between devices, will allow players to interact with each other in the context of the game.

2.2 Interface 2.2.1 Structure All game actions will be executed through the game’s menu interface. Because there is minimal digital interaction for core gameplay, menus will be largely static, and not require dynamic representation. Because the interface is menu­based, text and icons will be the primary modes of interaction and information display.

The overall menu structure is outlined below. This is a simplified architecture with core components for each screen included. Each screen is listed in further detail below.

6

2.2.2 Login Screen The Login Screen is a simple security measure and data protocol to ensure that the information presented in the menus is appropriate to the player. This is a minimal interface for which the user must input their username and password to access the main interface, which consists of a UI hub from which all of the main interface screens may be accessed.

7

2.2.3 Map Screen The Map Screen is the primary source of location­based information in the game. The screen uses Google Maps integration to represent the play area, including the player’s location and all applicable mission locations. Selecting missions on screen allows the player to view the details of the mission.

2.2.4 Activity Feed The Activity Feed is a list containing a feed of updates pertaining to the game, including new missions, neutralisation alerts, and administrative messages. Some feed items such as missions may be opened to view additional information. This allows overview and detailed review to be executed in the same screen.

8

2.2.5 Mission Screen The Mission Screen exists for each mission the player has available. Information pertaining to the mission’s location and the actions required are provided in detail on this screen.

2.2.6 Profile Directory The Profile Directory is a hub page from which the player may access all of their collected information on themselves and other players. These are organised into separate “portfolios” for each player, which may be opened and viewed in greater detail.

9

2.2.7 My Profile This screen contains the player’s own profile, which is distinct from the other profile screens in that it permits the player to make (limited) changes to the information provided, such as the personal details that other players might uncover by performing missions. All details about a player are revealed to them, regardless of its state of visibility to other players.

2.2.8 Profile Screen The Profile Screen follows the same template as the player’s profile screen, but the information listed for each player is dependent on the viewing player’s level of mission completion. By default, information about all other players is extremely limited, though as the player completes more missions further information is revealed (the player’s identification image being the highest­tier piece of information). This information may not be altered by anyone other than the player to whom the profile belongs.

2.2.9 Actions Screen The Actions Screen screen is the primary location for all active interactions with the game system. Actions that change player status, such as neutralising another player or gathering data. The interface is limited to a few highly visible buttons.

These buttons are contextual to the player’s situation (primarily their proximity to other players or mission locations), and respond accordingly. More details about these interactions are listed in the Controls section below.

10

2.3 Controls Controls will be touch­based and executed via the phone’s interface. This is primarily accomplished through the Actions Menu. Location and agent specific actions form the broad categories of agent activity in­game, with specific actions covered in section 3.

2.3.1 Location­Specific Actions Location specific actions require that a player travel to a predetermined destination to perform an action. Player location is determined by GPS and acceptable positioning will form a radius around the desired location.

Action locations will be determined using several different methods: using geographic points of interest drawn from google maps, using locations determined by the creators of specific events and operations, and using location determined by paid sponsors.

2.3.2 Agent­Specific Actions These are actions that the player can perform at any time. The number of times the action may be performed is limited per player per operation. This includes actions such as laying a trap or bug.

The location of the performed action will be logged on the server using GPS. Agent specific actions may have temporary or lasting effects on locations and the players that are in range of those locations.

2.3.3 Neutralise Agent This action can be performed at any time but is only effective under specific circumstances.

The performing agent must have other agents within his/her immediate vicinity as determined

by GPS coordinates. Upon triggering this action, GPS data and bluetooth connection are used to determine sufficient proximity to attempt neutralisation. Successful neutralisation is more likely if the distance between agents is minimal and if the performing agent has a fully unlocked intelligence profile on the target.

2.3.4 Review Intelligence This action can be performed at any time by the agent. The agent may review the data gathered on competing agents and attempt to deduce their locations. This way they may identify opponents they wish to engage or seek potential allies. They may also determine if they have sufficient intel on a given agent to attempt to neutralise them.

11

3. Level Design With regards to level design, Espionage is not a traditional video game. Rather than use defined levels, the real world is used as its setting. In light of this, the following section will deal with types of missions a player might undertake during a game session.

3.1 Agent­Specific Missions These are missions that involve two or more players interacting with each other, either for mutual benefit or as competitors. These have a limited number of uses per operation.

Bug This sets a bug to ‘listen’ in an area for other passing agents. One tier of intelligence will be unlocked on each agent that passes near the bug per day. Additionally, the bug also has a chance to gather information from the intelligence portfolio of those agents, providing details about other agents. A bug has a 10m effective radius and may be used 3 times per operation.

Check In This is required on a regular basis or the agent’s location will be revealed. Failure to check in will result in the agent becoming exposed. Repeated failure to check in will result in the player’s neutralisation. This is to ensure that players remain active while playing the game.

Check in frequency is determined at operation creation, with shorter operations having more frequent check in times.

Stakeout This reveals other agents in the immediate vicinity to the agent performing the stake­out. Two tiers of intelligence will be unlocked on any agent in range of the stakeout. This action can be automatically cancelled if a nearby agent performs a sweep or if the player moves more than 10m from their stakeout location. The stakeout action may be performed 3 times per operation.

Sweep This reveals and nullifies bugs and cancels nearby stakeouts. Any bugs caught by the sweep unlocks one tier of intelligence on the agent that placed them. Agents caught in the sweep will have two tiers of intelligence unlocked in the intelligence dossier. If the agent caught is performing a stake­out an additional level of intelligence will be unlocked. This action may be performed 3 times per operation.

12

3.2 Location­Specific Missions These are missions that focus on single­player interactions with the environment, usually to collect more information on their adversaries or to grant them other advantages in player vs. player interactions. The agent must perform the action within range of a pre­determined location which will be displayed on the game map.

Dead-Drop Leaves an information package to be shared with other agents. The information left is a copy of the agent’s intelligence dossier at the time the action is performed. The dead­drop disappears once another agent has performed a dead­drop pickup. This can be used as a tactical move (to bait other agents) or a cooperative action.

Dead-Drop Pickup This mission involves gathering a dropped information package to add it to the agent’s intelligence portfolio. Picking up the dead­drop consumes it, preventing other agents from claiming it.

Hacking This adds information on random agents to the intelligence dossier with a chance to learn of bug placements throughout the play area.

Rendezvous This adds information on random agents to the intelligence dossier and allows the player to perform additional sweep and stakeout missions.

Supply Drop By visiting this location, the agent gains access to additional bugs, which they may use to perform bugging missions.

Safehouse These locations will hide an exposed agent and satisfy that agent’s check­in criteria.

3.3 Game Flow The following demonstrates the general flow of gameplay from start to end of a single session: 1. All players start without any information regarding their competition. By performing agent and location specific missions they build up intelligence on their competition 2. Missions allow agents to learn about each other, but at the risk of exposing their own identities to the competition 3. Once a player has sufficient information on a competing player, they can attempt to locate and neutralise that player 4. Once the session time runs out or only one active agent is remaining, the game ends

13

3.4 Neutralising Agents Neutralisation of other players is a core component of Espionage’s gameplay. Neutralisations must be performed in close proximity to an enemy agent. A minimum range must be maintained for any chance of success, and the probability of a successful neutralisation is increased the closer the player is to the enemy agent. Additionally, the amount of gathered intelligence about the target influences the chance of success. However, if the target agent is currently exposed then gathered intelligence is not necessary.

Upon a successful neutralisation, the victor is granted the target’s intelligence portfolio. If the attempted neutralisation fails then the agent that attempted the neutralisation becomes exposed.

3.5 Exposure Agents can become exposed through various means, either through their actions or the actions of competing agents. When exposed, an agent’s location is visible to all other agents on the game map. As well the exposed agent can be neutralised by any player within range regardless of the intelligence they possess pertaining to the exposed agent. Additionally, exposed agents cannot neutralise other agents or perform missions, aside from the Safehouse mission.

Exposure duration is a factor of the operation duration, with shorter exposures for shorter operations. Exposure may also be voided when the agent successfully completes the Safehouse mission.

14

4. Development 4.1 Technology 4.1.1 Native The application will run as a native Android application. This will allow access to the device’s GPS data and bluetooth connectivity, which are integral to the performance of missions.

4.1.2 Back­End / Database The application will interface with a database containing information on all users and currently active missions. The database itself will make use of SQL tables, which will communicate to the application through server­side PHP scripts.

4.1.3 GPS and Bluetooth Positioning GPS positioning will be the primary means of determining players’ locations relative to each other and mission locals. Soft­positioning, in the form of a radius of effective locations, will compensate for imprecise GPS positioning. In player neutralisation, a bluetooth connection will be used as a secondary check to determine sufficient proximity.

4.2 Portfolio/System Data The following is information that a player might find within their dossier about specific agents, or information seen by the player as a part of the game experience, for example, mission details.

4.2.1 System­Generated Information This is game data generated by the game system itself, or by non­player users such as sponsors. and pertains to the core functionality of the game. This information may or may not be visible to players based on the current game state.

1. List of Players: A database table composed of all the players participating in a single game instance 2. Player Status: Whether or not players are alive or dead within the game, in addition to whether or not their location is currently broadcasting 3. List of Missions: A database table consisting of all missions, descriptions, objectives, and dates / times where the mission is active 4. Player Locations: Stored as a latitude / longitude pair

15

4.2.2 User­Generated Information This is data that is provided by the players at registration to make up their personal portfolio.

Players that are found to be dishonest in their profile will be immediately disqualified from the game.

1. Agent Name ( First and Last ) 2. Photo: An image of the agent 3. Gender 4. Age 5. Email / Password: Used as the player’s account credentials upon registration

16

5. Assets 5.1 Style Attributes In accordance with the theme of the game, an old fashioned spy aesthetic will be used for the interface. This will consist primarily of art deco, minimalistic, and brutalist influences to evoke a mixture of film noir and cold war spy era style. Colours will generally be limited to black and white, with greys, desaturated browns, and beige as texturing and background colours. Some stronger colours such as solid blue, green, or red may be used for highlighting , but only to a limited degree. The use of textures will be focused on traditional physical text and architectural materials and style, such as paper, leather, folders, manilla envelopes, plaster, and concrete. Other texturing elements may include smoothed colour gradients and film grain, though only in limited quantities to retain readability. Text will generally follow typewriter­esque or art deco fonts, and representations will use period­appropriate physical representations where applicable (such as polaroid framing for images).

Audio will follow a similar aesthetic to the visual design, and be centered around old­fashioned sound effects. These will be limited, and the sole sources of audio in the game will be interface feedback and alerts. Ambient audio will be nonexistent or minimal in nature, so as not to detract from the theme of discretion of the game.

5.1.1 References Historical Secret Intelligence Documents

Source

Source

17

Art Deco

Source

Source

Brulatist

Source

Source

18

Minimalist

Source

Source

19

5.1.2 Screen Mockup

20

5.2 Graphics Needed 1. Logo a. Social Media logo treatment

b. Espionage title graphic

2. Menu Graphics a. Buttons b. Folder backgrounds

c. Player photo framing (polaroid frame)

3. Map Graphics a. Player icon b. Agent icon c. Mission icons (one per mission type)

21

5.3 Sounds Needed

1. Effects a. Notification noise b. Success notification noise c. Neutralisation notification noise 2. Music a. Background music

22

Appendices

23

A. Marketing Plan A.1 Market Analysis The popularity of games in the espionage/spy genre, such as the water­gun assassination game Streetwars, suggest that there is a market for this game. There exist also a genre of mobile games that are played in the real world like Google’s popular Ingress that takes the form of a global game of capture the flag and pits two teams against each other.

The game will be marketed towards both community and technology focused individuals. The games mentioned above attract a wide range of players, so a similar level of interest could be expected for Espionage. A possible specific target market would be university or college students. With daily trips to and from work or classes, users will have numerous daily opportunities to complete missions and neutralisations.

Community event planners will be a large secondary market for the game. By having location specific events adopt the game as an activity their attendees can participate in the reach of the game is greatly increased.

A.2 Sponsorship Locations play a very important role on gameplay, while simultaneously being a real­world factor that may be familiar to potential players. This makes them a prime means to maximise exposure and open a venue for potential monetisation. This would involve promoting the game directly to companies or organisations that have any of the following: 1. brand or location/landmark recognition, 2. an interest in sponsoring events, 3. a large customer/member/attendee base. This marketing strategy would involve promoting directly to such organisations, putting an emphasis on the potential for profits or awareness it might bring.

Promoting to companies or organisations, especially ones with easily identifiable locations (such as coffee shops or organisations with recognisable landmarks such as government or university institutions), gives a distinct benefit to the game, the players, and the organisation itself. By linking certain missions to sponsor locations, the players are given clear points of reference with which to play, which in turn raises attendance to these locations (this can potentially boost awareness or sales, depending on the type of location in question). This effectively prompts players to go to a location without overtly imposing advertisement upon them (it should be noted that at no point would the player be obligated to take these missions to progress in the game, and purchases at store locations would not be mandatory to complete missions).

24

Further research would be necessary to confirm that players being presented such locations as mission points would prompt greater attendance and purchases/awareness, but the potential for increased attendance at locations offers greater exposure from a market that organisations may not have had access to previously.

In addition to the location factor, Espionage sessions also have a value as a group activity to be held by organisations for their members or employees. Because of its design, the game is built well to foster interconnectivity and community, which are important to many organisations.

The exact nature of sponsorship deals will vary for each organisation, as not all groups would be for profit. Small scale promotions for single game sessions and larger partnerships to promote branded locations present across many areas are equally viable. The needs of each potential sponsor are unique, and for this reason some specific catering may be necessary in targeted campaigns, but the principles of increased exposure and group promotion would remain important elements of any directed promotion to sponsors.

A.3 Promotional Event On December 8, a promotional game session will be launched at Carleton University. Players will be recruited at the University Center Atrium on December 8th. After the recruitment session, the game session will be launched, and will run until the December 19th deadline for the project.

A.4 Promotional Media The simplest promotional media to be used is posters. This will consist of variously sized graphics made for print and distribution. This will consist of general promotional posters to raise awareness of the game as well as template posters that can be modified to provide information about specific sessions. This may be used for promotional events or as a tool for players creating game sessions to raise awareness for their particular game. Posters are planned to be designed and some examples printed for late November. In addition to posters, other physical media such as pins or shirts may be created, but these are stretch goals and as such are not planned to be included in the schedule unless supplementary time and resources are found to be available.

Digital advertisements will be included for internet promotion in conjunction with physical promotion. This will consist of banner advertisements and a promotional video. These will be included on the website, though hypothetically, banner ads would also be used for promotion on other websites, while the video would be used for video advertising (such as television and Youtube). Banners are aimed to be complete by late November, and the video is projected to be complete by mid­December.

25

A.5 Social Media Social media will be a significant component of promoting the game, as it relates well to the social nature of the game. Accounts for the game will be created on Twitter and Facebook, and will periodically post messages regarding sponsored events and game updates, as well as providing a venue for players to interact. All social media accounts are planned to be up and running as of mid­November.

In addition to standard social media venues, a website will be created to be used as a hub for information and media relating to the game. This will include a summary of the game, all promotional material created for the game, links to social media accounts, update messages about the game, and a location to register to the game as a player. The website is planned to be complete by late November.

A player­side mode of advertising that will be included is the ability to post accomplishments in the game to social media, in the form of messages such as “I just neutralised player X in Espionage!”. These messages will have links for interested parties to navigate that will provide additional information about the game, and will serve to promote further exposure.

A.5 Session Starter Package Because of the social dynamic of the game, it is beneficial for each session to have a player group that is both large and diverse. Espionage is best played when players do not all know each other. For this reason, marketing is especially important during session recruitment, prior to a new session being launched.

In order to satisfy this need, a component of Espionage’s marketing will consist of a “Session Starter” package, which consists of media and guides for session hosts to use as a means of promoting their session to potential players in the area. This package is available to session starters through the game’s website.

In addition to instructions on how to effectively prepare for a session, the package will include a special campaign mission. This mission will include brief instructions and a code, which are to be printed and placed at visible locations around the game session area (a brief guide regarding where these may/should be placed is also included in the package). These codes may be accessed by anyone through their phone, and will begin a small guided quest for the potential player similar to a standard game mission. This will introduce the player to the fundamental concept of the game and its core mechanics. Completion of the tutorial will give the player an offer to sign up for the game (which they may do at any time upon entering the code). Completion of the tutorial, like a usual mission, will grant the new player one random piece of information about another player, to be unlocked when the operation begins.

The purpose of the tutorial is to raise awareness for the game, intrigue potential players, and give them a small demonstration of how the game works. Because the tutorial is designed to 26

be accessible to anybody (provided the session creator places the promotional materials in public spaces), it allows for a more diverse and anonymous player base for operations, which helps to improve the overall experience of the session.

27

B. Testing Plan B.1 Development Testing Procedure During development, testing will be carried out in two forms. Formal user testing will be used to determine the strengths and weaknesses of game concepts and UI designs. Developer bug testing will be used to locate and fix technical problems within the software both before and after release.

B.1.1 Bug Testing Bug testing will be an ongoing process throughout development. Any change to the codebase will be precipitated by minor bug testing by the developer. Major changes will be tested by multiple team members. Before the beta release and promotional event, a final, comprehensive software test will be completed by all team members.

B.1.2 User Testing User testing will occur in discrete stages throughout development. Users will be recruited from any available source, and will include classmates, friends, coworkers, and community members from Carleton University.

The first stage of user testing, occurring early November, will consist of a paper­prototype test to determine weaknesses in concept and UI design flaws. Based on the results of this test, changes will be implemented into the game and UI designs. A second paper prototype test will take place to determine the effectiveness of the changes. During the early alpha stage of development, user playtesting will be used to determine logistics issues, especially with regards to GPS/bluetooth positioning. As with the paper­prototype test, playtesting will occur more than once in order to determine whether development changes are effective.

B.2 Promotional Event Test As outlined in the marketing plan, after the beta version of the game is complete an open public test instance of the game will be held at Carleton University. Players will be recruited at a promotional event on December 8th, where the development team will present the game to the community at the University Center Atrium. Afterwards, a session of the game will be held which will complete before the December 19th final project deadline. During this game session, users will have the ability to report problems with the game directly to the developers.

These problems will be resolved if possible and implemented during the game session.

28

C. Project Plan

Agents Provocateurs Liam Davidson, Bethany Dunfield, Alex Eady, Justin Loranger­Ahluwalia Last Updated: 14­11­07

29

C1. Deliverables The following items will have been provided by the end of the project. These will be provided as over the course of development and completion. This includes deliverables that will be provided as part of the Design Studio 4 deliverable requirements. These deliverables are based on the information provided in the 2014­2015 Course Outline (and updated as needed).

Proposal A brief summary of the game concept and core components of the development plan Due: October 3rd Design Document A comprehensive design document laying out the core design of the game, including a marketing plan, early prototypes, and a preliminary website Due: November 7th, November 28th (Updated) UI Wireframes Wireframes outlining the general structure and visual appearance of the game’s interface Due: November 7th Hierarchical Task Analysis A breakdown of the tasks necessary for the completion of the project, including information estimated durations and dependencies Due: October 3rd User-Testable (Beta) Prototype An advanced prototype with core functionality and preliminary visual design complete Due: November 28th Final Presentation A presentation demonstrating and explaining the game and project in its final state.

Due: December 8th Release Version A completed game with all functionality and design complete and polished Due: December 19th Source and Marketing Packages A comprehensive package of all documentation, development materials, and promotional materials (including a demo video and complete website) created for the game Due: December 19th

30

C2. Schedule 2.1 Work Breakdown Structure All task duration estimates are denoted with practical work periods (accounting for breaks and pauses, not only time spent working on task) and rounded to day units for simplicity and clarity.

2.1.1 Art and Design UI Architecture Plan Conceptualise the structure and flow of the user interface Dependencies: None Duration: 2 Days UI Layout Plan Conceptualise the visual layout of interface elements for each menu state Dependencies: UI Architecture Plan Duration: 3 Days UI Asset Plan Conceptualise list of graphical and audio assets that will be required for the game interface Dependencies: UI Layout Plan Duration: 2 Days UI Graphical Assets Create preliminary visual assets to be used for the game interface Dependencies: UI Asset Plan Duration: 3 Days UI Graphical Asset Cleanup Polish preliminary assets as needed for use in the final game Dependencies: UI Graphical Assets Duration: 2 Days UI Animations Create transitional effects and animations to be used for the game interface Dependencies: UI Asset Plan Duration: 2 Days UI Audio Asset Recording Create or acquire preliminary audio assets to be used for the game interface 31

Dependencies: UI Asset Plan Duration: 2 Days UI Audio Asset Mastering Polish preliminary assets as needed for use in the final game Dependencies: UI Audio Asset Recording Duration: 1 Day

2.1.2 Development API Research Research APIs to determine which is the most suitable for the project Dependencies: None Duration: 2 Days Hardware and Device Research Research devices and hardware tools (Phones, RFID, Bluetooth) to verify their capabilities and ensure that the best tools are chosen to complete the project Dependencies: None Duration: 3 Days Data Storage Research Research a system to use for the purpose of data storage and management Dependencies: None Duration: 2 Days Development Environment Setup Setup the development environment for the project, including a testing device and installing the required software and tools on all relevant systems Dependencies: API Research, Hardware and Device Research Duration: 2 Days Network Environment Setup Setup the server and networking systems for collection and management of the game and website, including acquiring the required software and tools on all relevant systems Dependencies: API Research, Data Storage Research Duration: 1 Day File Repository Setup Setup the file repository system for versioning and collective access of the development code and game asset files for the game Dependencies: None Duration: 1 Day Location Broadcasting Implement the functionality for a player to broadcast their current location to the system 32

Dependencies: Development Environment Setup Duration: 3 Days Data Storage Implement the structure for data relating to player profiles, location, and other relevant information to be stored on the database Dependencies: Network Environment Setup Duration: 2 Days Proximity Detection Implement the functionality to detect relative positions of players to determine proximity for interactions such as neutralisations and data transfers Dependencies: Network Environment Setup Duration: 3 Days Gameplay Triggers Implement the functionality to have triggers work in conjunction with location and player proximity to execute changes to the game data (ex. triggering the neutralise button in proximity to a player to remove them from the game) Dependencies: Location Broadcasting, Proximity Detection Duration: 3 Days UI Architecture Implementation Implement the planned interface structure and navigation Dependencies: UI Architecture Plan, Development Environment Setup Duration: 2 Days UI Layout Implementation Implement the planned interface layout and positioning Dependencies: UI Architecture Implementation, UI Layout Plan Duration: 3 Days Asset Implementation Integrate graphical and audio assets into the game Dependencies: UI Graphical Asset Cleanup, UI Animations, UI Audio Asset Mastering, UI Layout Implementation Duration: 2 Days Game Completion Integrate Design and functionality of game into finished game Dependencies: Asset Implementation, Gameplay Triggers Duration: 2 Days

33

2.1.3 Marketing Marketing Plan Establish a plan for major marketing initiatives and implementation Dependencies: None Duration: 3 Days Website Design Conceptualise the appearance and architecture of the promotional website Dependencies: None Duration: 2 Days Website Development Implement the architecture and navigation of the website Dependencies: Website Design, Network Environment Setup Duration: 3 Days Website Assets Create the graphical assets for the website Dependencies: Website Design Duration: 2 Days Website Asset Implementation Integrate the created assets into the website architecture Dependencies: Website Development, Website Assets Duration: 1 Day Video Conceptualisation Plan the structure of the promotional video Dependencies: Marketing Plan Duration: 2 Days Video Recording Record the content for the promotional video Dependencies: Video Conceptualisation, Game Completion (Possibly), Marketing Event (Possibly) Duration: 3 Days Video Mastering Edit and polish the content of the promotional video for release Dependencies: Video Recording Duration: 2 Days Posters/Promotional Graphics Conceptualise and create promotional graphics for use on posters and banners Dependencies: Marketing Plan 34

Duration: 3 Days Marketing Event Planning Conceptualise and organise the plan of action for marketing event(s) Dependencies: Marketing Plan Duration: 2 Days Marketing Event Implement and monitor planned marketing event(s) Dependencies: Marketing Event Planning, Game Completion Duration: 2 Days

2.1.4 Testing Testing Plan Establish a plan for major testing initiatives Dependencies: None Duration: 2 Days Reporting Documents Create relevant testing documents Dependencies: Testing Plan Duration: 3 Days User Testing Conduct testing and observe users with the devices to collect relevant data *May be repeated, but project assumes one major observational testing initiative (individual interview­based testing is covered under User Feedback Collection below) Dependencies: Reporting Documents, Marketing Event (Simultaneous) Duration: 3 Days User Feedback Collection Conduct interviews or collect user­filled forms pertaining to the usability of the game Dependencies: Reporting Documents, Asset Implementation Duration: 4 Days Testing Review Evaluate testing results and making alterations to the game’s design or development as needed Dependencies: User Testing, User Feedback Collection Duration: 2 Days

35

2.2 Schedule The project schedule is organised by half­month increment milestones. These are approximate, but function on the principle that the tasks listed will be completed by the given period (note that this only defines completion deadline; tasks may be started prior to that period).

Mid October ● ● ● ●

API Research Hardware and Device Research Data Storage Research File Repository Setup

Late October ● ● ● ● ● ● ● ●

UI Architecture Plan UI Layout Plan UI Asset Plan Development Environment Setup Network Environment Setup Marketing Plan Website Design Testing Plan

Mid November ● ● ● ● ● ● ● ● ● ● ● ● ● ●

UI Graphical Assets UI Audio Asset Recording UI Graphical Asset Cleanup UI Animations UI Audio Asset Mastering Location Broadcasting Data Storage Proximity Detection Gameplay Triggers Website Development Website Assets Marketing Event Planning Reporting Documents Video Conceptualisation

Late November ● ● ● ● ●

UI Architecture Implementation UI Layout Implementation Asset Implementation Game Completion Website Asset Implementation 36

● ● ● ● ● ●

Video Recording Posters/Promotional Graphics Marketing Event User Testing User Feedback Collection Testing Review

Mid December ● Video Mastering ● All document and asset packaging

37

C3. Resources 3.1 Team Structure As is demonstrated in the table below, each team member is assigned to two fields, and each field has a unique pair of workers. This is to ensure a sufficient degree of overlap exists for each task and team member for maximum efficiency and to alleviate problems such as or gating bottlenecks. In the event that one of the fields is gated or is bottlenecking other tasks, team resources may be shifted in order to minimise drag.

It should be noted that this does not mean each member works exclusively on these fields with no consideration for the others, and every member may theoretically work on tasks that belong to any field including those they are not assigned to. However, this serves as a guide for the primary focuses of each team member, and solidify the general dynamic with respect to those tasks.

Liam

Development Art and Design Marketing Testing

Bethany

Alex

Justin

X

X

X

X

X

X

X

X

3.2 Hardware Development will occur on both Carleton Lab computers, and developer’s personal computers. In order to test and run the application, bluetooth capable, gps­enabled Android devices will be required. The Carleton Ugrad server will also be required in order to run the back­end and host the application database.

3.3 Software Native Application development will be done using Android Studio v 0.8.6. This platform has been chosen due to its superior access to Google APIs, and ability to detect performance and version incompatibilities. The Google Maps API will be used in order to implement the map functionality of the game. Additionally, game prototypes will be developed in HTML5 using the Brackets IDE.

38

C4. Risk Analysis 4.1 Risk Factors Below is a list of risk factors involved in the game, sorted by their “exposure” values.

User Privacy Because of the nature of the game, user privacy is a significant concern for designing the game. Players are required to provide some information about themselves, and all of this information may become available to other players during the game.

Communication Between Devices A core element of the game is player interaction. As such, it is essential that player’s devices be able to communicate with each other. Technology may prove limiting in the implementation of these features, particularly under certain circumstances, such as if players are indoors or in locations where interference may occur.

Failure to Secure Sponsored Locations Though not game breaking, the lack of sponsored locations would significantly hinder the viability of the game, particularly for non­private operations. Because sponsored locations provide a benefit both to game awareness and gameplay by way of mission locations, this is a challenge both with regards to marketing and the game’s design itself. Compared to other risks, this is also potentially very likely.

Insufficient Adoption It is entirely possible that operations will not succeed or be lacking in engagement because of a lack of players. Though the game can hypothetically be played with just a small amount of players, there is a clear advantage to having larger scale operations.

Bottlenecking and Blocking Over the course of development, bottlenecking and blocking of tasks, particularly from one field to another, is a major concern, as it would impede the already restrictive time period for projected completion of the project.

4.2 Preventive Actions The following is a list of preventative measures that will be used to minimise the potential exposure value of the risks outlined in the previous section.

39

Require User Consent In order to limit concerns over privacy, a very clear warning of the potential risk will be presented to players early on, prior to registration. This will make players fully aware that any information put in the game’s database is potentially discoverable by other players, and that the game will hold no liability for any breach in privacy this might incur. Players will be asked to only put information they are comfortable with sharing on their account, and requested information will be limited to general items necessary for the game, such as the player’s name and picture.

Extensive Device Testing A priority over all other game development tasks will be the testing and implementation of all core device functions to ensure that they are functional and reliable. Both development and testing will have the core functionalities of the game at top priority to ensure that the proper venue of development for the game’s functionalities is assured. The team structure will be taken advantage of to ensure that non­critical features are still completed in addition to the core functions.

Directed Marketing to Sponsors As is noted in the marketing plan for this project, sponsorship is a core factor of the marketing of the project. This includes heavily directed marketing towards potential sponsors, and will be aimed at effectively presenting the benefits sponsoring the game can provide and emphasising that their support with regards to promoting and hosting parts of the game would require only minimal effort on their part.

Lines of communication would be provided to such organisations so that they might easily access the development team for further inquiries, to maximise the possibility of having the game supported by such organisations. Over time, this risk would also be dampened in direct relation to the success of the game, as prior sponsorship examples and clear demonstrations of the value it presents can then be provided as reference.

Modularised Team Structure As was mentioned previously, the team is split into four fields, each with a different pairing of team members. This will help with any bottlenecking or blocking issues through the flexibility of the team’s resource allocation.

If any one field becomes a project bottleneck due to an unexpectedly difficult or long task, the second field member will assist, with the remaining team members covering lower priority tasks within the field. Conversely, if a task is blocking one field of the project, team members working in blocked fields may simply shift their focus to their other assigned field. This ensures that team members will always be able to contribute to the project, despite blockers.

40

4.3 Corrective Actions The following is a list of actions that would be undertaken in the event that a risk comes to pass, so as to limit the impact it would have on the game’s success.

Backup GPS Support In the event that bluetooth is not viable, GPS functionality will make up the entirety of the location based features. While this would impact the accuracy of the location based features, GPS would be reliable enough that the game could still be played.

Alternative Technologies Several devices and tools were considered during the research phase of development, and though these were considered less optimal, they remain viable alternatives, should the current technology selection prove too unreliable. The most likely candidates in this event would be to resort to RFID tags or bluetooth beacon bracelets.

Landmark Locations Though they would normally be used in addition to sponsored locations, in the event that a sponsorship is not attained these may serve as the sole mission locations. Landmarks may include recognisable locations as well as simple locations such as intersections or other public spaces. Though this is slightly less optimal as it presents fewer viable locations for missions, there should be sufficient landmarks to keep a given operation interesting for players.

Delay Operation Launch In the event that an unsatisfactory number of players join for a game, an operation may be delayed by way of a grace period to allow for further promotion. During this time, small individual missions may be provided in a manner similar to the tutorial outlined in the marketing plan as a means to occupy players as they wait for the operation to begin.

41

C5. Policies 5.1 Change Control Policy Git, hosted on BitBucket, will be used as the version control system for the project.

Developers are encouraged to write detailed commit logs. Major changes or feature implementations will undergo code review with at least one other team member.

Documentation for the project is completed over Google Drive. Team members contribute to their individual sections, which are then reviewed as a team before submission.

5.2 Communication Policy Team members meet twice weekly, on Wednesdays and Fridays. The bulk of communication and task delegation takes place during these meetings. Online communication takes place through several avenues, including Facebook, email, and Google Drive. Files or documents needing to be shared that are not a part of the code base will be shared through Google Drive.

5.3 Quality Control Policy As mentioned above in section 6.1, peer code review will be implemented for major features or changes. Additionally, all team members will assist in testing the application and reporting bugs or problems. As mentioned in the testing and marketing sections, a live beta test will be conducted early in December which will feature bug reports directly from users.

42