Crimson: Massive Multiplayer Mixed Reality Game Group 2pmody/Crimson Report.pdf · Mixed reality games are part of a growing genre of games that involve real world locations, artifacts,

Crimson Document - Group 2Anthony Perritano, Aditya Balasubramanian, Andrew Long, Nasim Mobasheri

Crimson: Massive Multiplayer Mixed Reality GameGroup 2

Anthony Perritano, Aditya Balasubramanian, Andrew Long, Nasim Mobasheri

1


Contents:

1. Introduction2. The Client, the Customer, and Other Stakeholders3. Users of the Product4. Mandated Constraints5. Naming Conventions and Definitions6. Relevant Facts and Assumptions7. Functional Requirements8. Look and Feel Requirements9. Usability and Humanity Requirements

Configurability allows different users to have different functional variations of the product;;in terms of in-game notifications and settings. For example a user may turn offnotification settings for an impending skirmish or add notifications which indicate ifresources are low.

10. Performance Requirements11. Operational and Environmental Requirements12. Maintainability and Support Requirements13. Security Requirements14. Legal Requirements

The crimson game will adhere with all the legal requirements and abides by the laws inall aspects.The crimson game will comply with the product standards set by the corporation (Thecompany’s standards)

15. Use Case Diagrams16. Sequence Diagrams17. User Interface18. Development Schedule19.System Design19.1 Design Goals19.2 System Architecture

Critical Design Decisions: XMPP vs HTTP ProtocolHardware, Software and User Interface

19.3 Subsystem Description20. Object Design20.1 Subsystems Description in Detail

AuthenticationAccount & User Management

2

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.735hfkgegwpt

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.fzjpjbmb9edo

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.d608z5dl16ro

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.jx47t5vw4hf8

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.pn94tab9etqe

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.ekyh65yrw292

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.b9969gzi9acz

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.l04bdso9ledm

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.xhoxxbgz3d0

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.bhawyth9efpe




https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.ttj4lox43r98

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.clzqdrt4yyta

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.fxfzn7wyaxwc

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.77ou8gfciqv1

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.5ruc6gchdcl2

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.a5ptn8jb24mu

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.a5ptn8jb24mu

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.m401irrgeamq

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.m401irrgeamq

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.y9kfg4dxzeq5

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.cmeblgjlhh2d

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.nvyhiwr1yp51

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.wwuu59959uue

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.jibjh53fjeov

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.q52adicvn5ru


Content SystemBattlingConstraintsPlayersLocationsLevels (3D aspect)ArtifactsMapsResources

21. TestObjectiveRoles and ResponsibilitiesTest ProcessTesting ItemsTesting SurveyAcceptance Tests

22. Team Send Off23. Conclusion and Development Process Review

3

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.ce96fp4wep6d

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.lwwecg224xqz

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.wve4rn3xqkac

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.ogn7chj4xya8

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.acr8f56c3ii6

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.nqlr0mc7g5a5

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.5aptdxjmzen4

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.ixn996ctwvq3

https://docs.google.com/document/d/sYqV-B6c3ObJr06UfZfpH_w/headless/print#heading=h.qyl0p3hdlvx


1. Introduction

The purpose of this document is to gather requirements for Crimson game.This document is for game development team and client to specify what will be implemented inCrimson game.

1a. Project Background

Mixed Reality Games

Mixed-reality games are part of a growing genre of games that involve real world locations,artifacts, resources etc. In real-time coupled with virtual overlays and computing devices as theplayer is playing. Moving from one game plot to another requires physical movement in the realworld. These factors attract not only hard-core gamers but also casual gamers who enjoy pickup and go games. Games of this type can be played in small portions and still deliver asatisfactory experience.

The Concept of ‘Foraging’ in Nature

The premise of the game is based on concepts that exist in nature in which animals andhumans perform on a daily basis. It’s called foraging. In their survival, animals forage for food tostay alive. They do this individually and collectively. They forage at rich abundant patches andpatches with poor resources. This is all a matter of decision making (“Decision Ecology:Foraging and the Ecology of Animal Decision Making.", Stephens, 2008). This is survival of thefittest and natures evolved mechanism to promote the most adaptive agile animals to the top.There are a number of factors that go into foraging:

Crowding/Depletion - Too many animals at a patch can deplete its resources, in manycases down to nil where they could be unusable by others. Many times this begins bycrowding, which is the case when a rich resource patch over run by many animals.

Predation - Patches can contain lurking predators. Such as the hawk in nature.Predation can occur at low or high yielding patches. High yielding patches have a greaterchance of predation than lower ones.

These concepts of foraging are basis for the fundamental mechanics of the game. Instead ofpatches, players will check-in into spots and acquire gold (the main resource for survival) basedon the amount they spend there. Like in nature it’s a matter of a decision, the longer they stay inthe spot the greater risk they are putting themselves in danger of an attack. While not at a spot,players use their slowly depleting gold resource to stay alive until they die, unless they check-into more spots to gain more gold.

4


3D Game Playing

To add some depth and strategy to the forage/ambush concept, at every location there arevarious positions with various altitudes that a player can put themselves. Each position will give astrategic advantage or disadvantage depending on what your personal objective is. Loweraltitudes have high resource yields, but no increase in attack power or defense. Higher altitudeshave low resource yields, but come with great strength and defense. This extends the strategicgame of foraging or ambushing, allowing the player to do a little bit of both if they so choose.

Scenario: You are a student at UIC. Before you head into class you decide to check into theCrimson application so you can harvest resources while you attend lecture. You open up theapplication and check-in to the UIC area. The application gives you a set of possible locationswhere you can position yourself in the gameworld (given in the table below). Since your objectiveis to harvest you decide to choose a location with a lower height, resulting in a lower resourcepenalty. After class you check back in to the application and see that Crimson has alerted youthat you have been attacked and lost the battle, losing your hard earned resources!

Unbeknownst to you, a fellow clansman had checked into the UIC area not long ago. Due tohaving a character that is more built for battle they positioned themselves at a higher altitude toward off invading clans. At this higher altitude they are granted a higher attack power and betterdefense against attacks but at the costs of a high resource penalty. Crimson notified the playerthat an intruder had checked into the area and attacked a fellow clansman. The player decides tospring into action and attack. Being positioned at a greater altitude results in an easy victory forthe champion leaving a battered enemy and a heap of newly acquired resources. Being thenoble knight they are the clansman decides to return some of the acquired resources that youhad lost during your battle.

Location Height Effect (DEFENSE/ATTACK /RESOURCES)

Lecture Center B 2 (+10%/+20%/-10%)

Douglas Hall 3 (+30%/+10%/-40%)

University Hall 10 (+80%/+70%/-95%)

1b. Goals of the Project

Create a massive multi-player geo-location based mixed-reality game using a major city (e.g.Chicago) as its playing field. This involves traversing real locales, battling other players andarmies, acquiring virtual resources to stay alive to become the richest and most powerful ruler inthe land.

5


2. The Client, the Customer, and Other Stakeholders

2a. The Client

Mobile gaming companies like Zynga Corporation, a well known provider of social gameservices. It’s obvious that this company is interested in geo-location based mobile games withconcepts of battling and traversing.

2b. The Customer

Smartphone/tablet users with interest in gaming. Any player who buys our product in market canbe considered client as well as an end user.

2c. Other Stakeholders

Stakeholder Description

ProductUser/Gamers

This type of stakeholder use the product for entertainment. The majorinterests for this group is amusement and fun.

Development team They are responsible for success or failure of the Product. They arealso responsible for debugging.

BeneficiaryCompanies

Since the game is based on geo-locational concepts and user need togo to real places to check in, we assume some companies speciallychain stores and restaurants like StarBucks, McDonald,... areinterested in investing in game to attract more customers. In return wecan add more resources to their place or put some artifacts there topersuade gamers to check in there.

6


3. Users of the Product

3a. The Hands-On Users of the Product

User Description

Gamers Main users of the game that simply play this game, they should beowners of smartphones and tablets from various level of education,gaming experience, male or female. We assume that the gameattracts people with interest in fantasy genres, RPG game, mainlyyoung from 13 to 35 but it can appeal many middle aged gamers aswell. It will also attracts users with interest in outdoors activity andsociable as the game play requires to going to different locations suchas Cafes, Restaurants, etc .

3b. Priorities Assigned to Users

User Priority

Gamers Key User

3c. User Participation

User Participation

Gamers An average of one login per day would guarantee an active gameenvironment which would increase the entertainment value for otherplayers as well, in comparison to a server with a high amount ofinactive users.

3d. Maintenance Users and Service Technicians

User Role

System Administrator User responsible for supporting and maintaining server. This user isalso responsible for system outages and other problems. This usermust have degree in IT, Computer Science or Computer Engineeringand sufficient experience in maintaining systems and databases.

7


4. Mandated Constraints

4a. Solution Constraints

All steps of product development should be properly documented for ease of use.

Rationale: We are assuming that the game will be used for other major cities.

Fit Criterion: All steps are documented for other developers.

4b. Implementation Environment of the Current System

Implementation Environment of the current system

This game will be installed only on Wi-fi/3G enable mobile devices and tablets with cameras.It’s supported by iOS 6.0+ or Android operating system 4.0+.

The Game will be available on application stores like Apple iTunes and Google play.

The product comes with all options necessary to play the game. There’s no need to use otherdevices/applications.

The product can be used in places that are stored as PLACES in our database.For firstrelease of the game it will be available only in Chicago city and nearby suburbs.

The hardware required for the backend will consist of a dedicated linux server with MySQL permajor location, or realm. The server will generate new “stock” of resources for each check-inlocation at set intervals (hours, days, etc.), which will be stored in the database. The serverwill also be responsible for handling player interactions. The database will also store all playerinformation.

5. Naming Conventions and Definitions

5a. Definitions of All Terms, Including Acronyms, Used in the Project

Term Definition

Skirmish A battle between two Players or a Player and AI character.

8


Forage Action of collecting resources like gold, lumber, etc in a check in spot.

GPS Global Positioning System : Provides position data for player

Level Available altitudes in each spot. They can be considered as differentfloors of a building. By changing level Player’s abilities in foraging andbattling change.

Attribute Attributes refer to a player’s attack, defense and resources.

9


6. Relevant Facts and Assumptions

6a. Facts

With the rise in popularity and accessibility of smartphone and tablet based computing coupledwith the availability of high speed cellular networks;; mobile games are becoming increasinglypopular. A recent research report (NPD Group, Mar. 2012) indicates that mobile gamers nowrepresent the largest gaming segment over consoles and pc games.There was a time when the average smartphone user was a businessperson, now the averageuser ranges from their teens to their fifties. With this change to more casual users, the marketfor smartphone ‘Apps’ has skyrocketed. Especially through direct sales to the user via mobileApp stores such as Apple’s iTunes App Store and Google Play. With this explosion mobilegames have become cheaper as they require fewer developer costs to produce than traditionaldesktop and console games, which also allows for more risk.

The Fantasy GenreToday, the term fantasy is used to classify a genre of fictional narratives that contain magic,supernatural phenomena, myths, sagas, medieval and ancient folklore. Games in this genre(especially Role Playing Games (RPGs)) are filled with magic, wizards, knights, elves, witches,sorcerers etc. The fantasy genre gives game developers and players no limits to their creationsand imaginations.

6b. Assumptions

Mobile smartphones and tablets commonly cost a dollar or less, so people who aren’t gamerscan still enjoy a quick game during a break from work or when they’re sitting waiting for the trainto arrive.

10


7. Functional Requirements

Functional requirements are the fundamental or essential subject matter of the product. Theydescribe what the product has to do or what processing actions it is to take.

Accounts, Joining and Creating games Requirements

1-The Player should be able to create an account and setup a user profile.

2-The Player should be able to see a list of available games to join as a participant.

3-The Player should be able to join a game in progress if there is a free slot.

4-If the Player drops out of a game the system should inform the group.

5-If a Player enters the game the system should inform the group.

6-Each game can have from one to fifty Players.

7-A Player and a group of Players should be-able to create their own game.

11


8. Look and Feel Requirements

8a. Appearance Requirements

Appearance Requirements

1-The product shall be appealing to all the users of various ages. This would ensure usersatisfaction while interacting with the game system. In short, the appearance of Crimson’suser interface would please the player and make him/her feel comfortable with repeated andprolonged usage.

2-The colors used in the Crimson application are certain to please all users, maintaining aconsistent black and white classical appearance.

8b. Style Requirements

Style Requirements

1-The system would be approachable, meaning that the user won’t hesitate to use it and becomfortable with the interface.

2-A player would not feel intimidated by the product as it is designed to be very user friendlyand people with less/no experience in using mobile apps would also feel at home.

3-The game would have a medieval feel, where players have to battle and gather resources atthe same time.

4-The game would give the player a feeling of being a part of a virtual fantasy world whichmakes the player feel like part of the world.

5-The crimson game exudes a conservative appearance while maintaining consistency ofdesign.

12


9. Usability and Humanity Requirements

9a. Ease of Use Requirements

Ease of Use Requirements

1-Upon purchasing of the Crimson application, the player can easily create an account fromwithin the application and start playing the game.

2-The product does not require the user to remember any aspects of using the game as thegameplay style is extremely user friendly and does not expect too much from the user in orderto perform game actions.

3-The Player should be able to download the application easily from a cloud based applicationstore. e.g. Apple iTunes, Google Play.

4-The Crimson game ensures overall satisfaction with its ease of use and ability to performcommands given by the user with utmost precision by providing proper and adequatefeedback to each action performed;; so that the user feels confident while using the product.

5-The product should require little to no training by implementing a user interface that reliesheavily on pictures and symbols rather than text.

9b. Personalization and Internationalization Requirements

Personalization and Internationalization Requirements

1-Personal Configuration options take into account the user’s personal preferences. Forexample, when player ‘Vinu’ checks in to a location, the system would respond withcustomized responses like “What are you planning to do now Vinu ?”, and display the availableactions that Vinu can perform.

2-Configurability allows different users to have different functional variations of the product;; interms of in-game notifications and settings. For example a user may turn off notificationsettings for an impending skirmish or add notifications which indicate if resources are low.

9c. Learning Requirements

Learning Requirements

13


1-The Crimson game will be extremely easy for all players of different ages to learn and adapt,due to the simplicity of design.

2-No training/prior experience is required in order to experience an enjoyable style ofgameplay.

3-Any queries which the user might have during gameplay or on how to use the product, wouldbe answered by the user-friendly help system in the game.

9d. Understandability and Politeness Requirements

Understandability and Politeness Requirements

1-The product shall use common english which the user feels familiar with and is comfortableto use on a regular basis.

2-The product will not consist of any symbols or phrases which the player is not familiar with.

3-The product will not reveal any details of its internal construction or mechanisms or anysuch aspects which are not relevant to the user;; so as to make it more understandable andeasy to use.

4-All notifications in the game as well as the help guide would be of extreme politeness andcourteousness. For example, in case the user enters the wrong password during login, thesystem would reply with a message saying “Please check the password you have enteredand try again”.

9e. Accessibility Requirements

Accessibility Requirements

1-The product will adhere to the disabilities act which is set in the geographical area of play.

2-The product shall be usable by those who are partially colorblind, owing to simple yetconsistent designs.

10. Performance Requirements

10a. Speed and Latency Requirements

14


Speed and Latency Requirements

1-Any interface between a user and the game system shall have a maximum response time of5 seconds (less than 2 seconds provided a decent internet connection)

2-The product will provide with fast and accurate GPS coordinates in order to facilitate propergameplay and help the user make decisions without any lags or delays.

3-The product will update itself to any new patches within 10 minutes of introduction of achange.

4-The application should be able to perform normally under weak wifi or cellular dataconnection.

10b. Safety-Critical Requirements

Safety-Critical Requirements

1-The product will be tested upon and certified by professional engineers in the domain.

2-The product will not harm the user, in any way.

10c. Precision or Accuracy Requirements

Precision or Accuracy Requirements

1-All details provided by the game would be accurate, inside the game.

2-The product will give accurate location descriptions via GPS satellites at all times.

3-The product will contain an ingame clock which will provide the player with the precise time.

10d. Reliability and Availability Requirements

Reliability and Availability Requirements

1-The product will be available at all times, throughout the year so that players can enjoy acontinuous gameplay experience.

2-The product will have an uptime running of 95 %, owing to any upgradations or patches.

3-The game will provide with reliable and consistent performance at all times.

4-The product will be monitored at all times by a team of professional software engineers andwill comply with the players expectations.

15


10e. Robustness or Fault-Tolerance Requirements

Robustness or Fault-tolerance Requirements

1-The product will perform under low connection speed circumstances (Response time mightincrease)

2-The product will restore back to original or factory settings in case of a fault occurrence, inorder to prevent total system failure.

10f. Capacity Requirements

Capacity Requirements

1-The product will be capable of handling nearly 10,000 players at a given time.

2-The product will perform at best efficiency under all circumstances of number of playersplaying the game

10g. Scalability or Extensibility Requirements

Scalability or Extensibility Requirements

1-The product will be able to handle any number of increase in number of players using thegame at a given time, without any faults or lags.

2-The game will ensure proper communication with the player at all times, irrelevant ofnumber of users.

10h. Longevity Requirements

Longevity Requirements

1-The product shall be expected to operate with proper maintenance, and within the presetbudget for a minimum of 2 years.

2-Proper maintenance and consistent upgradation to the game system would ensureincreased lifetime of the Crimson game.

11. Operational and Environmental Requirements

16


11a. Expected Physical Environment

Physical Requirements

1-The product is a mobile/tablet app, hence is extremely portable

2-The game can be played anyplace where wifi/packet data transfer(3G/4G) is permissible.

3-The product can be used in all climatic conditions, owing to the accessibility of the user.

11b. Requirements for Interfacing with Adjacent Systems

Interfacing Requirements

1-The product will be capable of operation on both android and Apple iOS operating systems.

2-The product will operate not only on mobile phones but on tablets as well, supporting both3G and WiFi data transfer.

3-The product will interface with applications that run alongside with weather stations in orderto provide accurate climatic details.

11c. Productization Requirements

Productization Requirements

1-The product is purchased as an application to the mobile phone/tablet via any cloud basedstore such as Apple iTunes or Google Play store

2-The product shall be able to be installed by an untrained user without the need to refer toseparately printed instructions

11d. Release Requirements

Release Requirements

1-Any updates or patches to the game would be downloaded automatically on a bi-weeklybasis.

2-The maintenance releases will be offered to end users once every 6 months.

3-Each release shall not cause previous features to fail thus ensuring backwardscompatibility.

17


4-All upgradations and maintenances would be within the budget prescribed.

12. Maintainability and Support Requirements

12a. Maintenance Requirements

Maintenance Requirements

1-The Crimson game will be maintained by a team of system administrators familiar with theproduct.

2-Any patches/upgrades to the product will be automatically downloaded and installed on theuser’s system without any hassles.

12b. Supportability Requirements

Supportability Requirements

1-The crimson game will run on mobile phones/tablets and hence be highly portable.

2-Support is provided at all times to the customer at Crimson’s online portal.

3-A help section elaborately describes any aspect of the game which the user might havetrouble with.

4-Faults occurring in the gameplay, if any, are immediately dealt with with proper feedbackfrom the player.

5-The application would not be available in an offline mode, due to a dependency on accessingthe internet.

12c. Adaptability Requirements

Adaptability Requirements

1-The product is expected to run in both Apple iOS as well as Android systems, in both mobilephones and tablets.

2-The product might eventually be expanded to other major cities in the United States.

3-The product is designed to run in all environments and all geographical locations within theprescribed boundaries.

18


13. Security Requirements

13a. Access Requirements

Access Requirements

1-All player data is confidential and can be accessed only by the top tier of management andthe players themselves.

2-Players can only access their own data and not others, even if they belong to same groups.

3-Players can access game content only upon successful login.

13b. Integrity Requirements

Integrity Requirements

1-The product will validate all data entered during registration.

2-The product will not be susceptible to external attacks.

3-The product will make backups of data at regular time intervals in order to protect itself fromany unforeseen consequences.

4-Any loss of information (such as player forgetting password) would be dealt with utmostprivacy, by the support staff and would only be revealed with proper identification of the player(via secret questions during profile setup).

13c. Privacy Requirements

Privacy Requirements

1-The product shall inform all users of all of the privacy policies before collecting data fromthem, which will be presented via a End User License Agreement.

2-Any notifications made to the information policy will be brought to the users attention on thenext launch of the application.

3-The product will not divulge any private information of the user and conform to theorganization’s policy.

14. Legal Requirements

19


14a. Compliance Requirements

Compliance Requirements

1-The crimson game will adhere with all the legal requirements and abides by the laws in allaspects.

2-Personal information would be stored in the system database once the user agrees to thedata compliance norm of the product.

14b. Standards Requirements

Standards Requirements

1-The crimson game will comply with the product standards set by the corporation (Thecompany’s standards)

2-The product will adhere to all the Apple iOS and Mobile android standards.

20


15. Use Case Diagrams

15a. Actors

Name Description

Player Player is the user who plays the game.

System Administrator The system administrator does maintenance on the system.

System ApplicationManager

This user is responsible for pushing new updates out to the system.

AI Character Artificial Intelligence character who battles player in different stages.

21


15b. Use Case Diagram

22


15c. Accounts and Account Administration Use Cases

Use Case Name: CreateAccount

Actors: Player

Entry Conditions: The Player has a working email address.

Flow of Events: 1. The Player selects new account option in the main menu.2. The System displays a form for the Player to enter in:

Username Password Email Address Address Date of Birth (DOB)

3. The Player submits the form.4. The System validates the form.5. The System Indicates the form has been submitted successfully

and adds the account’s information to database.

Exit Condition: The System sends the Player an email confirming the accountcreation.

Requirements: The System must be able to validate the submitted form.

Use Case Name: EditAccount

Actors: Player

Entry Conditions: The Player has an account

Flow of Events: 1. The Player selects edit account option2. The System displays information which can be edited ofaccount for the player to choose from:

Password Email Address Address Date of Birth (DOB)

3. The Player edits the form and submit it.4. The System validates the submitted form.5. The System Indicates the form has been submitted and

23


updates database.

Exit Condition: The System sends the Player an email notifying him/her ofchange(s). If Player edit the Email Address, System sends email tonew one.

Requirements: The System must be able to validate the submitted form.

Use Case Name: DeleteAccount

Actors: Player

Entry Conditions: The Player has an account.

Flow of Events: 1. The Player selects delete account option.2. The System displays a message notifying Player and asks for permission for deleting the account.3. The Player chooses OK.4. The System deletes account.5. The System removes Player’s username and statistics from existing games and updates database.

Exit Condition: The System displays a thank you for playing message and exits theapplication on the user’s mobile/tablet.

Requirements: The System must successfully remove Player’s information fromexisting game and database.

Use Case Name: SetupProfile

Actors: Player

Entry Conditions: The Player has already registered.

Flow of Events: 1. The Player selects setup Profile option.2. The System displays a profile screen which contains :

Profile picture/Avatar Current Game Race Attack Power Defense Power Overall Score

3. The Player can change profile picture/Avatar and view other

24


information. 4. The System stores the profile picture/Avatar that Player uploaded.

Exit Condition: The System sends appropriate message to Player.

Requirements: The size and type of the image that Player is uploading must be validin defined constraints.

15d. Gameplay Use Cases

Gameplay

The Player should be able to check in to a location using the application in conjunction with theGlobal Positioning System (GPS) on their mobile.

The Player should be presented with a list of available actions that can be performed.

The Player should be able to execute an action from the list of available actions.

The application should inform the player of any actions the System has take in regards to theplayers actions at a given context (GPS Check-in)

Use Case Name: Join Game

Actors: Player

Entry Conditions: The Player has an account and is logged in.

Flow of Events: 1. The Player selects join game. 2. The System displays a new screen showing available games. 3. The Player chooses one of the games to join. 4. The System add Players name to game and informs other Players of that game.

Exit Condition: The Player is in new game and can view other Players and statisticsof the game.

Requirements: The System shows only available games with free slot to join.

25


Use Case Name: Leave Game

Actors: Player

Entry Conditions: The Player had joined a game.

Flow of Events: 1. The Player selects leave current game option. 2. The System sends a message to the Player for permission to remove him/her from game. 3. The Player confirms leaving game. 4. The System remove Player’s name from the game

Exit Condition: The System updates the existing game.

Requirements: The player should currently be part of a game, once logged in.

Use Case Name: GPS Check In

Actors: Player

Entry Conditions: The Player has joined a game.

Flow of Events: 1. The Player selects Check In option from the main menu. 2. The System stores the GPS data (time and location). 3. The System displays new screen, showing available resources and altitudes.4. The System also provides a list of present Players at the spot.5. The System provides new options: Forage, Change altitude and Plan Ambush.

Alternate Flows: No Network Coverage: Prevents Player from checking in.

Exit Condition: The Player will see new screen of available resources and differentlevels of the spot and new options, Forage, Change altitude and PlanAmbush.

Requirements: The Player must choose a valid spot for checking in.

Use Case Name: Change Altitude

26


Actors: Player

Entry Conditions: The Player has checked into a spot.

Flow of Events: 1. The Player chooses Change Altitude option from Menu. 2. The System displays available levels of the spot. 3. The Player chooses an available level. 4. The System displays new screen showing the changes in Player’s power in foraging, attack and defence. 5. The System adds a new option to Player’s menu: Search for Artifacts.

Alternate Flow: The spot doesn’t have any available altitude levels for selection

Exit Condition: The Player is in new altitude and can search for artifacts or see thepresent players in levels below him/her.

Requirements: The Player should choose available levels in spot.

Use Case Name: Forage

Actors: Player

Entry Conditions: The Player Checked in to a spot.

Flow of Events: 1. The Player selects Forage option after checking in and determining the level. 2. The System checks number of present players in the spot and prepare resources ratios. 3. The Player gains resources with predefined ratios.

Alternate Flows: Depletion: Too many players foraging in a spot can deplete resources.The System will notify Player of depletion.

Skirmish: Another Player or AI character attack user.

Exit Condition: Successful forage: The Player successfully gained resources or the spot is depleted of resources. Player leaves the spot.

Skirmish: The Player gets attacked by another player or AI player.

Requirements: The player must be within the game.

27


Use Case Name: Skirmish

Actors: Player, AI Player

Entry Conditions: The Player Checked in to a spot and starts foraging.The Player checked in and change the altitude and starts to obtainartifacts or forage.

Flow of Events: 1. The System sends a message to Player and notify him/her of an attack. 2. The System sends another message describing the information of the invader. 3. The Player can leave the spot quickly or accept the battle and start to fight with the invader.

Exit Condition: Win: The Player wins the battle and obtains enemy’s resources.

Loss: The Player loses the battle and plenty amount of resources.

Death: The Player loses the battle and all resources.

Requirements: The player must be active within the game and not in a safe zonesuch as a resurrection or healing spot.

Use Case Name: Plan Ambush

Actors: Player

Entry Conditions: The Player has checked in.

Flow of Events: 1. The Player selects Plan Ambush option after successful check in. 2. The System stores hide Player’s from present players. 3. The System prevents the Player from gaining resources but keeps the list of present players available.

Alternate Flows: Not Attacking: Player decides not to attack anyone.

Battle: Player attacks another player and start a fight.

Exit Condition: No Action: Player leaves the spot with no action.

Death: Player starts a battle and die in it, he/she also loses all resources.

28


Win: Player starts a battle and wins it and gains enemy’s resources.

Injury: Player starts a battle but gets defeated and loses plenty amount of resources.

Requirements: The player must be active within the game and not in a safe zonesuch as a resurrection or healing spot.

Use Case Name: Display Players

Actors: Player

Entry Conditions: The Player has checked into a spot and determined desired level toplay on.

Flow of Events: 1.The Player selects Show present players option.2. The System displays new screen, showing present player’s name and race and amount of primary resources.

Alternate Flows: The system is unable to display players due to a connectivity issue.

Exit Condition: The Player chooses exit option on the screen and the System displays previous page again.

Requirements: Option is enabled only when other players are present in the spot.List does not show ambushed Players.

Use Case Name: Search Artifacts

Actors: Player

Entry Conditions: The Player has checked into a spot and determined an altitude otherthan ground.

Flow of Events: 1. The Player selects Search Artifacts option.2. The System displays new screen, showing hidden artifacts and their description and power in present level and all levels below it.3. The Player can obtain one of the artifacts in each check in.

Alternate Flows: No Artifacts: Level is drained. All the Artifacts were obtained.

Full Inventory: The Player obtained another artifact and his inventory is full. There’s no place for new items.

29


Exit Condition: The Player stores the artifact. The System will update attackpower/defense power based on the item he/she collected.

Requirements: The Player must be on levels other than ground.

Use Case Name: Check Statistics

Actors: Player

Entry Conditions: The Player has an account.

Flow of Events: 1. Player selects Character button in main page.2. System provides general statistics based on user experience

and attributes.3. Player selects Resources button in main page.

System provides resources statistics include user specificstatistics on each resource.

Exit Condition: Player view statistics.

Requirements: None

Use Case Name: Administrator Mode

Actors: System Administrator

Entry Conditions: System Admin has online access to The System.

Flow of Events: 1. System Administrator connects to the administrator mode.2. The System permits Administrator to access the mode which allows him to manage accounts and groups.3. System Administrator can set up , maintain accounts and lock/unlock users.4. System Administrator can maintain and lock/unlock groups.

Exit Condition: System Administrator logs off.

Requirements: System Administrator shall be allowed to access Administrator modeanytime.

15e. Scenarios

30


Scenario Name: CreateAccount

Participating actor instances: Mary: player

Flow of Events :

1. Mary installs the application on her smartphone/tablet.2. Mary opens the application and chooses the create account option.3. The System displays a form for Mary to fill in4. Upon proper validation, Mary’s data is fed into the system database.5. The System updates Mary profile and sends a notification to other players notifying them ofnew player.

Scenario Name: EditAccount


Flow of Events :

1. Mary opens the Crimson application and logs in.2. Mary selects the Edit account option from the menu3. The System displays those attributes which Mary can alter4. The system validates the entries.5. The system displays a message for successful change in data and updates the database.

Scenario Name: DeleteAccount


Flow of Events :

31


1. Mary opens the Crimson application and logs in.2. Mary selects the Delete account option from the menu3. The System asks for a confirmation from the player.4. Upon confirmation, the system proceeds to delete all player data from the databases5. The system finally displays a farewell message.

Scenario Name: JoinGame


Flow of Events :

1. Mary opens the game application and selects join game option.2. The System will display all available games which have free slots.3. Mary chooses one of the game and joins it.4. The System updates Mary profile and sends a notification to other players notifying them ofnew player.

Scenario Name: LeaveGame


Flow of Events :

1. Mary opens the game application and The system displays her homepage screen.2. Mary decides to leave the current game and chooses leave game option.3. The System sends a notification to Mary and asks for her permission to remove her from thegame.4. Mary gives a confirmation.5. The System removes Mary from the game and updates her profile and sends a notification toother players notifying them of this event.

Scenario Name: CheckinPlaces


32


Flow of Events :

1. Mary opens the game app and after signing in , check in to the local café with her mobile/tablet device .2. The System will update her GPS data (time, location) and show her as an active player on thespot. After successful check in , system shows a new screen, displaying the amount of availableresources and the available levels in the spot. And give her three options : Forage, Plan Ambushand Change Altitude.

Scenario Name: ChangeAltitude


Flow of Events :

1. Mary opens the game app and after signing in , check in to local cafe with her mobile/tabletdevice .2. The System will update her GPS data (time, location) and show her as an active player on thespot. After successful check in , system shows a new screen, displaying the amount of availableresources and the available levels in the spot. And give her three options : Forage, Plan Ambushand Change Altitude.3. Mary chooses the Change Altitude option and selects one of the available levels of the spot.4. The System updates Mary Altitude and display new screen which shows the changes thatoccurred in Mary’s ability to gather resources, attack power, and defense power.5. The System also shows amount of resources in new level and adds a new option to Mary’smenu which is search for artifacts.6. The System updates present players list and shows all the players who are present in Mary’slevel and other levels below her.

33


Scenario Name: DisplayPlayers


Flow of Events :

1. Mary is in the local café and after a successful check in she chooses her altitude and selectsthe display players.2. The System will display new screen showing a list of all present players at the spot whichlocated in Mary’s level or levels below her. This list contains some information such as theirattack/defense power about present players.

Scenario Name SuccessfulForaging

Participating actor instances Mary: player

Flow of Events:

1. Mary is in the local café and after a successful check in she chooses her altitude and selectsthe foraging option.2. The System checks the spot for other players then calculates the ratio of resources bydividing resources on number of present players at the spot.3. The System displays Mary’s resources as small icons on screen and updates them as theychange.So Mary can see amount of her resources everytime she checks her screen.4. Mary keeps gaining resources till she leaves the location.

Scenario Name DepletionwhileForaging


Flow of Events:

34


1. Mary is in the local café and after a successful check-in she chooses her altitude selects theforaging option.2. System checks the spot for other players then calculates the ratio of resources by dividingresources on number of present players at the spot.3. The System displays Mary’s resources as small icons on screen and updates them as theychange.So Mary can see amount of her resources everytime she checks her screen.4. Because there are too many players feeding in the spot, resources deplete.5. From the depletion time till Mary leaves the spot, she gains no resources.

Scenario Name AttackandEscape


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses her altitude and selectsthe foraging option.2. System checks the spot for other players then calculates the ratio of resources by dividingresources on number of present players at the spot.3. The System displays Mary’s resources as small icons on screen and updates them as theychange.So Mary can see amount of her resources everytime she checks her screen.4. Another player or AI Player attacks Mary, The System sends an attack alert to her and givesher name and information like attack power of the invader.5. Mary decides to leave the spot and evade the battle.

Scenario Name BattleandVictory


Flow of Events:

35


1. Mary is in the local café and after a successful check-in she chooses her altitude and selectsthe foraging option.2. The System checks the spot for other players then calculates the ratio of resources bydividing resources on number of present players at the spot.3. Another Player or AI Player attacks Mary, the system sends an attack alert to her and givesher the name and information like attack power of the invader.4. Mary decides to fight back.5. Mary wins the battle and gains a portion of the enemy’s resources.

Scenario Name BattleandDeath


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses her altitude and selectsthe foraging option.2. System checks the spot for other players then calculates the ratio of resources by dividingresources on number of present players at the spot.3. Another Player or AI Player attacks Mary, the system sends an attack alert to her and givesher the name and information like attack power of the invader.4. Mary decides to fight back.5. Mary loses the battle and her enemy drains a portion her resources and her profiledeactivates.

Scenario Name BattleandInjury


Flow of Events:

36


1. Mary is in the local café and after a successful check-in she chooses her altitude and selectsthe foraging option.2. System checks the spot for other players then calculates the ratio of resources by dividingresources on number of present players at the spot.3. Another Player or AI Player attacks Mary, the system sends an attack alert to her and givesher the name and information like attack power of the invader.4. Mary decides to fight back.5. Mary loses the battle and plenty amount of resources.

Scenario Name Ambush/No Action


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses her altitude and selectsplan ambush option2. The System hides Mary from other players and also prevents her from gaining resources.3. While Mary is invisible to others, she can see other players and their information but shedecides not to attack anyone.4. Mary leaves the spot without any attack or any change in her resources.

Scenario Name Ambush/Attack-Victory


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses her altitude and selectsplan ambush option2. The System hides Mary from other players and also prevents her from gaining resources.

37


3. While Mary is invisible to others, she can see other players and their information, Shedecides to attack one of the player.4. Mary wins the battle and drains her enemy and leaves the spot or waits for another player toattack.

Scenario Name Ambush/Attack-Injury


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses her altitude and selectsplan ambush option2. The System hides Mary from other players and also prevents her from gaining resources.3. While Mary is invisible to others, she can see other players and their information, Shedecides to attack one of the player..4. Mary loses the battle and plenty amount of resources and becomes very weak. She leaves thespot to evade all possible attacks.

Scenario Name Ambush/Attack-Death


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses her altitude and selectsplan ambush option2. The System hides Mary from other players and also prevents her from gaining resources.3. While Mary is invisible to others, she can see other players and their information, She decides

38


to attack one of the player..4. Mary loses the battle and a portion of her resources and her profile deactivates.

Scenario Name SearchArtifact/Successful


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses a level above groundand selects search the artifacts option.2. The System displays hidden artifacts in Mary’s level and all levels below her, and alsoprovides Mary with description of the artifacts.3. Mary selects one of the artifacts to obtain. It’s the first artifact she’s choosing since her checkin.4. The System checks Mary’s recent inventory and allows her to pick up the item.5. The System updates Mary’s attack/defense power based on the artifact she chose.

Scenario Name SearchArtifact/FullInventory


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses a level above groundand selects search the artifacts option.2. The System displays hidden artifacts in Mary’s level and all levels below her, and alsoprovides Mary with description of the artifacts.

39


3. Mary selects one of the artifacts to obtain. It’s the second time that she wants to obtain anartifact after checking in.4. The System checks Mary’s recent inventory and sends her an error message, notifying herthat her inventory is full.5. Mary is not able to obtain the artifact.

Scenario Name SearchArtifact/NoArtifact


Flow of Events:

1. Mary is in the local café and after a successful check-in she chooses a level above groundand selects search the artifacts option.2. The System fails to find any artifacts in Mary’s level or lower levels.3. The System sends a notification to Mary informing her that there’s no available artifacts.

40


16. Sequence Diagrams

16a. Create Account

41


16b. Edit Account

42


16c. Delete Account

43


16d. Set Up Profile

44


16e. Join Game

45


16f. Leave Game

46


16g. GPS Check-In

47


16h. Change Altitude

48


16i. Display Players

49


16j. Forage

50


16k. Skirmish

51


16l. Search Artifacts

52


16m. Check Game Statistics

53


17. User Interface

Check-in Screen After a successful check-in the user ispresented with available resources (and

options) at the location.

The game statistics screen displaysgeneral statistics on the users

experienced and their character attributes.

The resource statistics screen displaysgeneral resource statistics and userspecific statistics for each resource.

54


18. Development Schedule

18a. Three Month CycleMany small software teams work on three month release cycles. An initial three monthdevelopment cycle would include functionality for the requirements list below. Requirements andfunctionality related to the specific game detail and content design will come at later cycles. Thisincludes character and level design also.

Milestone Use Cases Delivery Date

Location Based Check in. Forage, Change Altitude, PlanAmbush

March 15th, 2013

User Profile Creation Creating Accounts, ProfileCreation, Editing

April 15th, 2013

Battling System Attack, Defend, ResourceGathering

June 15th, 2013

55


18b. Gantt Chart

56


19.System Design

19.1 Design Goals

The following are important design goals that are addressed by our system architecture.

Performance Criteria

The performance of any online game would mainly focus on the speed and response timesof the player’s interactions with the system. This would then ensure an enjoyableexperience free of noticeable lag. The client server architecture employs eXtensibleMessaging and Presence (XMPP) Protocol messaging for intersystem communicationfacilitates fast and accurate transfer of information which results in this desirable responsetime.

Design criterion Definition

Response time The System should be able to handle userinterface requests and responsesimmediately. Reading and storing userlocation data should not take more than afew seconds. The number of players onlineand concurrent games should not affect theresponse time.

Speed & Accuracy The product will provide fast and accurateGPS coordinates in order to facilitateproper gameplay and help the user makedecisions without any noticeable lag ordelay.

Capacity The product will be capable of handlingnearly 10,000 players at a given time. Theproduct will perform at best efficiencyunder all circumstances of number ofplayers playing the game

Dependability Criteria

57


Any game should make the player feel comfortable and this can be achieved byemphasizing on the fault tolerance of the game, its security aspects and its availability at alltimes. The Crimson game consists of separate databases for user information and gamecontents. This allows for good fault tolerance of the system. The user’s private informationis stored securely, and login requires proper authentication so as to prevent hacking of anykind. The game would be made available at all times so that the user’s gameplayexperience is not affected and this is done by professionally sound maintenance persons.Furthermore, Crimson is easy to use even for those who are new to such a genre ofgames, as the architecture only displays the relevant information to the user hiding theintricate details.


Fault Tolerance The System should be able to handle usererrors and network failure errors. In case ofuser errors the system notify player of errorwith a mock up. in case of network failure,System should store all data and preventdata corruption.

Security The System won’t be vulnerable to anyoutside attacks. Individual playerinformation and data is only accessible tosystem administrators and the player.

Reliability The Crimson game ensures overallsatisfaction with its ease of use and abilityto perform commands given by the userwith utmost precision by providing properand adequate feedback to each actionperformed;; so that the user feels confidentwhile using the product.

Availability The product will be available at all times,throughout the year so that players canenjoy a continuous gameplay experience.

Cost Criteria

58


Any product should adhere to the set budget. The crimson game uses a client/serverarchitecture which is ideal for such a scenario. It complies with all the preset costconditions set by the organization.


Development Cost The development cost for the game will bewell within the budget limit set.

Deployment Cost The deployment cost for Crimson will notexceed the preset amount.

End User Criteria

The end users (i.e players) are the most important aspect of the game. Player interactionswith each other and the environment are what drive the game. The user interface on theplayer’s device emphasizes ease of use through intuitive design and the system built insuch a manner as to allow for smooth, interruption-free gameplay. Help options are easilyavailable and response times are given highest priority via proper inter-communicationbetween the game’s subsystems.


Usability The user Interface should be attractive andeasy to learn. It should minimize requestsfor gameplay and help.

Ease of use The product does not require the user toremember any aspects of using the gameas the gameplay style is extremely userfriendly and does not expect too much fromthe user in order to perform game actions.

Maintenance Criteria

System maintenance is essential for any product. The Crimson will be maintained by ateam of experienced professionals which ensure there is no downtime. This againemphasizes the importance of end users namely the players. The architecture allows for

59


easy maintenance and troubleshooting. There is no data loss owing to secure databasesand any updates are easily installed without disturbing the player or the gameplayexperience.


Updates The product will update itself to any newpatches within 10 minutes of introduction ofa change. Any patches/upgrades to theproduct will be automatically downloadedand installed on the user’s system withoutany hassles.

Game Maintenance The Crimson game will be maintained by ateam of system administrators familiar withthe product.

Access & Security All player credentials would be stored in asecure database, with properauthentication techniques so as to preventhacking of any kind;; thus ensuring systemsecurity.

19.2 System Architecture

19.2.1 Critical Design Decisions: XMPP vs HTTP Protocol.

HTTP (HyperText Transfer Protocol) and the eXtensible Messaging and Presence XMPPprotocols are some of the two most popular protocols used in client-server communicationon the internet. XMPP was chosen as the protocol because of its real-time messagingproperties.

The XMPP Protocol is an XML based synchronous message oriented protocol for networkcommunications. Its use has been made popular with Instant Messaging (IM) systems suchas Google Talk. Part of the protocol is the idea of presence and awareness. Allowing

60


clients to determine whether users are online or not. XMPP client libraries have beenwritten in most mobile platforms and programming languages. This makes it an idealcandidate to support a number of different of types of clients. One of the main advantagesof XMPP is that an XMPP client such as iOS or Android based mobile do not need to pullat regular intervals to receive updates. The libraries use a continuous bidirectional streamlistening for messages. Once a message is received the client is able to act on it and senda reply with an open connection. The XMPP server is coordinating these messages tovarious clients in real-time. E.g. Mobile A is logged in with user John and Mobile B islogged in with Sally. The XMPP server is able to address messages to [email protected] [email protected] individually. So the server is able to update Sally with only itsstatus, making communication more efficient.

HTTP is the foundation of the world-wide-web and based on a request-responseclient-server architecture. The client requests a page and the server sends back that pagewith a status. The architecture is more suited for html pages, one time client requests,periodic client updates, than real-time clients messaging. Also one important fact is that ifthe Crimson client was build with HTTP it would constantly have to poll the server forupdates vs XMPP which can send an update directly to the client. Polling the serverconstantly for updates is expensive network and system resource wise.

61


19.2.2 Hardware, Software and User Interfaces

Crimson has a real-time system framework, which means there are some time constraintson actions and time errors must be evaded. This framework makes Crimson an interactivesystem, which results in interactive interfaces. System administrator and players are theonly external agents in our system.The system also uses XMPP for intercommunication between the subsystems which allowsa good response time in interactions.The architecture of Crimson is broken into many subsystems with peer to peerconnections. The layering and partitioning consists of three main layers as Client/Server

62


architecture, which defines the interactions between these subsystems.

System Overall Architecture

63


Hardware Architecture

19.3 Subsystem Descriptions

The various subsystems of the architecture are shown in the main architecture diagram.Below is a brief description of each subsystem and its main function.

19.3.1 The client side

User interface - This is what the user will interact with to play the game on theirtablet or smartphone.

Storage - Internal storage for storing the current state of the application and theplayers session with the game. This is a local proxy to the players server side stateused for efficiently. So the client doesn’t have to phone home all the time for thecurrent status.

64


XMPP Communication - This module coordinates message flows within the clientapplication. Listens for updates from the XMPP server and sends client updates toserver to be processed.

19.3.2 Server side (XMPP Server):

Authentication - Authentication refers to the proper login of the player whenstarting the game. The user credentials are verified with the data present in the Userdatabase. Security is given utmost importance to prevent any hacking.Authentication is done using encryption algorithms.

Communication - This subsystem sends, receives, and processes XMPPmessages while acting on them accordingly in the Game Engine. See sectionbelow for different types of xmpp messages.

Account management - Account management involves all activities related tomanaging the player’s account and his/her personal settings like user profile picture,password, etc. The account management interacts mainly with the user databasefor this purpose.

Content System - The content system holds all the vital information regarding thegame such as battling, maps, player attributes and so on. The content system couldbe considered as the heart of the game as it houses all the in-game information andit interacts with the game database.

Game Engine - The game engine is responsible for running the game in real-time.Basically its function involves setting up the game world, its rules and constraints,and allowing the players to interact with it. While we call the content system as theheart, the game engine can be looked upon as the brains of the entire system,coordinating activities and managing all gameplay related activities. The gameengine interacts with essentially all components or subsystems in the architecture.

65


19.3.3 Databases

Game database - The game database holds information related to the game suchas maps, artifacts, levels and so on. Based on the levels, attributes such as hitrating and evasion vary.

User database - The user database mainly houses the user information, as thename suggests. This consists of user settings, in game preferences, playerinformation such as name, display pictures and statistics. This information is verysecure and cannot be accessed by unauthorized persons.

19.3.4 XMPP Messages

XMPP message is an XML based message. Within that XML message subtypes can bedefined to allow the message processor to work more efficiently in routing the message tothe proper subsystem. Types of messages:

1. Game Play - General game play updates.2. Authentication - For logging the user into the system.3. User Account/Profile - These update the user accounts and profiles.4. Check In/GPS - These messages update the player's current location.

66


Server Side Packages

67


20.Object Design

20.1Subsystem Description in DetailUser Interface

This is nothing but the GUI with which the user interacts while playing the game.

Classes in the user interface subsystem:

Account GUI : The account class is used to manage the user accounts. It allows accessto the user database.

Methods Description

viewAccount viewAccount shows the current accountdetails of the player.

modifyAccount modifyAccount allows the user to makechanges in his/her account.

deleteAccount deleteAccount allows the user to deletehis/her Crimson account.

Constraints

context AccountGUI::viewAccount() pre:

accounts->exists(a:Account | accounts.equals(a))

context AccountGUI::modifyAccount() pre:


context AccountGUI::deleteAccount() pre:


context AccountGUI::deleteAccount() post:

!accounts->exists(a:Account | accounts.equals(a))

Profile GUI: This class deals with the profile of the player within the game. It is dividedinto 2 subclasses namely User Profile and Enemy Profile

68


User Profile: This class displays the user’s current profile within the game.

Methods Description

displayUser Profile displayUserProfile displays the user profileon the screen.

Constraints

context UserProfile::displayUserProfile() pre:

profiles->exists(p:Profile | profiles.equals(p))

Enemy Profile: This class displays the enemy user’s current profile within thegame(during a skirmish)

Methods Description

displayEnemyUserProfile displayEnemyUserProfile displays the enemyprofile on the screen.

Constraints

context EnemyProfile::displayEnemyUserProfile(p:Player) pre:


Statistics GUI: This class is used to display the user’s statistics within the game. It isdivided into two subclasses namely the Game Statistics (GameStats subclass) andResource Statistics (ResourceStats subclass)

Game Stats: This class deals with all the game statistics such as number of wins, itemswon, players defeated, player hit points, attack power, etc.

69


Methods Description

displayGameStats displayGameStats display all the gamestatistics on the screen

Constraints

context GameStats::displayGameStats() pre:


Resource Stats: This is used to view the details of the resources that the player holdscurrently in terms of gold, lumber and stone.

Methods Description

displayRecStats displayRecStats display all the resourcestatistics on the screen

Constraints

context ResourceStats::displayRecStats() pre:

players->exists(p:Player | players.equals(p))

Game GUI: This class deals with the Game interface. A player has to initially check-in toaccess features available in the game. This class composed of three classes namelyCheckIn, Present Players and Successful CheckIn.

CheckIn: This subclass is used for the player to check in at a particular location.

Methods Description

displayLocations displays list of available locations to checkin.

70


checkGPSdata pinpoint the location of the player.

Constraints

context CheckIn::checkGPSData() inv:

device.hasGPSServices = true

context CheckIn::checkGPSData() pre:

device.hasGPSServicesEnabled = true

Present Players: This displays all the players who are present in the same location asthe user.

Methods Description

listPlayers displays list of present players in the samelocation.

Constraints

context PresentPlayers::listPlayers() pre:

locations->exists(l:Location | locations.equals(l))

Successful Check in: Upon Successful check in at a location, this class is invokedwhich basically gives the options that a player can choose from. This class consists oftwo classes: Select Action and Skirmish.

Select Action: This class displays the options which are present to the player. It includesthose activities such as forage, change level.

Methods Description

actionInitiate Initiate the action that was selected.

71


Constraints

context SelectAction::actionInitiate() pre:

actions->exists(a:Action | actions.equals(a))

Skirmish: This class is used to engage the player in a skirmish with another player/AI inthe game.

Methods Description

engageSkirmish initiates the battle between the players.

fleeSkirmish Flee is used to run from a skirmish at thecost of little resources.

Constraints

context Skirmish::fleeSkirmish() pre:

skirmishes->exists(s:Skirmish | skirmishes.equals(s))

72


Storage

This subsystem is an internal storage for storing the current state of the application and theplayers session with the game.It stores all the data for User Interface subsystem. This is alocal proxy to the players server side state used for efficiently. So the client doesn’t have tophone home all the time for the current status.

73


Classes in Storage subsystem:

Game Play: The main class of this subsystem that stores all the data related to a game.This major class composed of six classes: Resources, Profile, Game Action,UserAccount, Locations, Statistics.

Resources: This class is a superclass that stores resources data like gold, lumber andstone. This class consists of two subclasses: User Resources, Place Resources.

User Resources: This subclass obtains and stores user resources like gold, lumberand stone.

Methods Description

getUserResValue This method gets resources value andstores them. This values were obtainedfrom User DB.

Constraints

context UserResources::getResourceValue() pre:


Place Resources: This subclass obtains and stores current place resources like gold,lumber and stone.

Methods Description

getPlaceDes This method obtains current place.

getPlaceResValue Gets resource’s value in the current placeand stores them. These values wereobtained from Game DB.

74


Constraints

context PlaceResources::getPlaceDes() pre:

places->exists(p:Place | places.equals(p))

context PlaceResources::getPlaceResValue() pre:

places->exists(r:Resource | places.resources.equals(r))

Profiles: This class is a superclass that contains players profile information. This classconsists of two subclasses: User Profile, Enemy Profile.

User Profile: This subclass contains user’s profile information.

Methods Description

getUserProfile This method gets user profile informationand stores them. This value is obtainedfrom the User database.

Constraints

context UserProfile::getUserProfile() pre:


Enemy Profile: This subclass obtains and stores enemy’s profile while skirmish.

Methods Description

checkSkirmishStatus This method checks if a skirmish initiated.

getEnemyProfile This method gets enemy profile informationand stores them. This values wereobtained from User DB.

75


Constraints

context EnemyProfile::checkSkirmishStatus() pre:


context EnemyProfile::getEnemyProfile() pre:


Game Action: This superclass obtains and stores all the actions during a game. It hastwo subclasses: CheckIn and Action.

Check In: This subclass obtains and stores gps data of location that user is checking in.

Methods Description

getGPSData This method gets gps data of the currentlocation.

Constraints

context CheckIn::getGPSData() inv:


context CheckIn::getGPSData() pre:


Action: This subclass is responsible for actions in the game. It composed of fourclasses: Skirmish, Artifacts,Forage and Ambush.

Artifacts: This class gets a list of artifacts available in location. It also stores artifacts thatuser has collected.

76


Methods Description

getArtifactsList This method gets list of artifacts in currentlocation

addArtifact This method stores the artifact that userhas collected.

Constraints

context Artifacts::getArtifactsList() pre:


context Artifacts::addArtifact() pre:

locations->exists(a:Artifact | locations.artifacts(a))

context Artifacts::addArtifact() post:

!locations->exists(a:Artifact | locations.artifacts(a))

context Artifacts::addArtifact() post:

user.inventory.exists(a:Artifact | user.inventory.equals(a))

Skirmish: This subclass is responsible for battle and skirmish. It contains threemethods: initiateSkirmish , sendSkirmishAlert, endSkirmishandUpdate.

Methods Description

initiateSkirmish This method starts a battle between twoplayers.

sendSkirmishAlert This method notify a player when askirmish is about to begin.

endSkirmishandUpdate This method ends the skirmish and storesall the new values.

Constraints

77


context Skirmish::endSkirmishAlert() pre:

skirmishes->exists(s:Skirmish | skirmishes.equals(s))

Forage: This class gets resources ratios and stores them.

Methods Description

getRecRatio This method gets resources ratios incurrent location

addRecRatio This method stores the amount ofresources that player is obtaining in time.

Constraints

context Forage::getRecRatio() pre:

location.inventory.resource != 0

context Forage::addRecRatio() pre:

location.inventory.resource > 0

context Forage::addRecRatio() post:

location.inventory.resource < [email protected]

context Forage::addRecRatio() post:

user.inventory.resource > [email protected]

Ambush: This class is responsible for ambush action.

Methods Description

initiateAmbush This method starts an ambush.

Location: This class stores the parameters of the current location like gps data andaltitude as well as providing list of present players in that location.

78


Methods Description

getlocAltitudes This method gets location altitudes.

getlocGPSdata This method gets location gps data.

getPresentPlayer This method gets the list of present playerin the location.

Constraints

context Location::getlocAltitudes() inv:


context Location::getlocAltitudes() pre:


context Location::getlocGPSdata() inv:


context Location::getlocGPSdata() pre:


User Account: This class stores user account information.

Methods Description

deleteUserAccount This method deletes all the accountinformation.

updateUserAccount This method saves new changes to useraccount

addUserAccount This method saves new user information.

Constraints

context UserAccount::deleteUserAccount() pre:


context UserAccount::deleteUserAccount() post:


79


context UserAccount::updateUserAccount() pre:


context UserAccount::addUserAccount() pre:


context UserAccount::addUserAccount() post:


Statistics: This superclass stores all the statistics. it has two subclasses game statisticsand resources statistics.

Game Statistics: This class stores game statistics such as user information and userresources, therefore it consists of two classes: user profile and user resources.

Resources Statistics: This class stores the general resource statistics and userspecific statistics for each resource.

Methods Description

getGeneralRec This method gets general resources.

80


XMPP Communication

This subsystem coordinates message flows within the client application. Listens forupdates from the XMPP server and sends client updates to server to be processed.This subsystem has a facade design pattern which simplify the interfaces with othersubsystems and classes. It also reduces the dependencies in client side.

XMPP Service Facade: it gets or sends the XMPP message and provides with properactions .

81


Account Management: This subclass handle the data flow between client side andAccount management subsystem in server side .

Methods Description

createAccount This method is for creating a new account.

updateAccount This method is for updating an existingaccount.

Game Parameter: This subclass handles the data flow between client side and GameEngine subsystem in server side .

Methods Description

updateGame This method handles all the changes thattake place during a game.

updateGameDatabase This method is for updating GameDatabase.

Authentication: This subclass handle the data flow between client side andAuthentication subsystem in server side .

Methods Description

sendUserdata When a user tries to log in to the system.

verifyUserdata This method notify user of valid/invalid login.

Connectivity: This subclass handle the data flow between client side and Connectionsubsystem in server side .

82


Methods Description

sendMessage This method is for sending a message.

receiveMessage This method is for receiving a message.

Authentication

The authentication takes place when a player logs into the Crimson game via his/her app.The system checks for proper credentials. This subsystem is responsible for reliability andsecurity of the application.

83


Classes in the Authentication subsystem:

Authenticate class: Used to match the user’s input to the data stored in the user database.The method involved, Authenticate, would consist of the authentication process whichprovides the service of checking the login credentials.The method would also be responsible for displaying appropriate messages forvalid/invalid logins.

Class Authenticate: This class is used for authentication purposes during login

Methods Description

authUser Checks the user input with data indatabase to ensure proper login anddisplay appropriate login

Constraints

context ClassAuthenticate::authUser() pre:

84



context ClassAuthenticate::authUser(c:Credentials) post:

accounts.credentials = c

Communication

Communication is achieved among subsystems via XMPP messaging which has beendiscussed in detail. Communication by itself is a subsystem which facilitates interactionamongst the various components. The main class in this subsystem is the XMPPconnection class. This subsystem also checks for internet connectivity as well.

Class Connectivity: This class is used for checking connectivity which is essential

Methods Description

connUser Checks for proper connectivity or signal aswell as availability of gps services

Constraints

context ClassConnectivity::connUser() pre:

device.hasGPSService = true

context ClassConnectivity::connUser() pre:

device.hasGPSSerivceEnabled = true

Class XMPPconnection: Used for communication among subsystems

Methods Description

authenticationConnection Involves communication with theAuthentication subsystem for authenticationpurposes

accountManagementConnection Involves communication with the AccountManagement subsystem for managing allaccount details

85


gameEngineConnection Involves communication with the GameEngine subsytem to facilitate prperfunctioning of game activities

checkInConnection Involves communication with the Userinterface subsystem during check in

Constraints

context ClassXMPPConnection::authenticationConnection() pre:


Account & User Management

The server keeps track of all user information in a database. Any change in userinformation results an immediate update in user database. The databases are secure anddo not allow any breaches.

86


Classes in the Account & User management subsystem:

1. The Account class is responsible for manipulating account details. This includesupdating as well as deletion. This account management class is linked with the class inAccount GUI under the User interface subsystem.

Methods Description

viewAccount viewAccount shows the current accountdetails of the player.

modifyAccount modifyAccount allows the user to makechanges in his/her account.

deleteAccount deleteAccount allows the user to deletehis/her Crimson account.

Constraints

context Account::viewAccount() pre:


context Account::modifyAccount() pre:


context Account::deleteAccount() pre:


context Account::deleteAccount() post:


2. The user class is responsible for handling all user related data. The methods involved inuser class are as follows

Methods Description

viewUser viewUser shows the User statistics in thegame

manageUser manageUser is used for keeping track ofnumber of users in a given location

Constraints

87


context User::viewUser() pre:

users->exists(u:User | users.equals(a))

context User::manageUser() pre:

users->exists(u:User | users.equals(a))

Game Engine

The game engine is responsible for running the game in real-time. Basically its functioninvolves setting up the game world, its rules and constraints, and allowing the players tointeract with it. The game engine orchestrates the functioning of the Crimson gameThe class associated with Game Engine is the Game Mechanics class which coordinateswith all other subsystems via XMPP

Class Game Mechanics: This class deals with orchestrating Crimson

Methods Description

manageContent Deals with managing all the game content,keeping track of all changes which may occurdue to any reason

manageData Makes itself aware of changes and updatesthe databases accordingly

managePlayer Keeps track of all player information bycoordinating with databases and othersubsystems

Constraints

context GameMechanics::manageContent() pre:

games->exists(g:Game | games.equals(g))

context GameMechanics::manageData() pre:

games->exists(g:Game | games.equals(g))

context GameMechanics::managePlayer(p:Player) pre:

games.players->exists(games.players.equals(p))

88


Content System

Battling

Battles occur between two players

1. Hit points2. Mana / magic points3. Gold (Can be won or lost based on outcome of the skirmish)4. Battle attributes namely hit rating, dodge rating and attack power (based on the

levels)

Class Battle: This class deals with the battling scenario of Crimson

Methods Description

manageBattle This method tracks all the events occuring inthe battle namely changes in the playerattributes/resources

reportBattle This method reports the final outcome andstatistics of the battle to the database

Constraints

context Battle::manageBattle() pre:

games->exists(b:Battle | games.battles.equals(b))

context Battle::manageBattle() pre:


context Battle::reportBattle() pre:


context Battle::reportBattle() pre:

games.battles.isOver = true;;

Constraints

89


For a battle to begin there needs to be a minimum of two players. The player’s need to bein the same battle zone and of different factions.Players

Players form the crux of the game.Attribute of players include:

1. Name2. Clan / Guild (if any)3. Race4. Hit points5. Mana / magic points6. Resources7. Gold8. Inventory / items held9. General attack power (i.e damage dealt)10. General hit rating11. General dodge rating

Battling in a particular level : Player gets a modified hit rating (accuracy) and dodge rating(evasion) based on the level at which the player is battling

Class Player: This class deals with all aspects related to the player

Methods Description

viewPlayer viewUser shows the Player statistics in thegame

managePlayer This tracks all changes in the Player’sattributes such as when player enters a levelor acquires an item which leads to a changein previous attribute.

trackPlayer This is used to determine the current locationof the player

invePlayer Lists the players inventory

90


Constraints

context Player::viewPlayer() pre:

users->exists(p:Player | users.equals(p))

context Player::managePlayer() pre:


context Player::trackPlayer() pre:


context Player::invePlayer() pre:


Locations

The various locations based on the altered map of Chicago

1. Location belongs to which race (Suburb/magic quarter/downtown etc)2. Important places situated in that location (places to heal/ major battlegrounds)3. Items available in the location (Eg the mystic staff can be found only in ravenswood)

Class Locations: This class deals with the various locations in the game.

Methods Description

viewLocations viewLocations shows the various locations inthe map along with the places of interest.

viewLocItems This method displays the items which can beobtained in the location

Constraints

context Locations::viewLocItems() pre:

locations.users->exists(p:Player | users.equals(p))

Levels (3D aspect)

91


The various levels available in a certain place alter the battle conditions

1. The levels available in a building / structure2. Hit rating in a level3. Dodge rating in a level4. Items obtainable at a certain level5. AI present in the level (if any)6. Amount of resources in a level

Class Levels: This class is all about the 3D aspect involved with battling players

Methods Description

viewLevels Shows the levels present in the currentlocation of the player, as well as presence ofany players/AI/items

goLevel Allows the user to jump/drop to the mentionedlevel

detailLevel Gives details of how the user’s attributeswould vary in the mentioned level

Constraints

context Levels::goLevel(l:Level) pre:

locations.exists(l:Level | locations.level.equals(l))

context Levels::goLevel(l:Level) pre:


context Levels::detailLevel(l:Level) pre:

locations.exists(l:Level | locations.level.equals(l))

context Levels::detailLevel(l:Level) pre:


92


Artifacts

Artifacts contribute to a player’s statistics and may prove to be the edge in a battle

1. Artifact name2. Artifact attributes (like increase in hit rating/dodge rating/attack power or a trade-off

amongst them)3. Artifact location (i.e where it is found)4. Artifact rarity (i.e how commonly it is found)

Class Artifacts: This class is all about the artifacts in the game

Methods Description

viewArtifact Displays information about the artifact, itslocation and attributes

useArtifact Primarily used in battle, changes theattributes of the player accordingly

dropArtifact Throw away the item from your inventory

Constraints

context Artifact::viewArtifact() pre:

locations.artifacts.exists(a:Artifact |

locations.artifacts.equals(a))

context Artifact::dropArtifact pre:

player.inventory.artifacts.exists(a:Artifact |

player.inventory.artifacts.equals(a))

context Artifact::dropArtifact post:

!player.inventory.artifacts.exists(a:Artifact |

player.inventory.artifacts.equals(a))

93


Maps

Maps are used to identify the players position as well as for players to navigate in crimson

1. Main map: The main map of Chicago which is divided into regions based on therace inhabiting them

2. Sub-map: The ‘mini-map’ of the region which the players wants to view. Gives amore detailed view of the buildings in the region. This can also give a generallocation of an item

3. Level map: These are used when battling to view the different levels which the playercan occupy. This map can also show a brief view of the attributes change atdifferent levels (like in certain altitudes the hit rating or dodge rating will vary)

Class Maps: This class is all about the maps in Crimson

Methods Description

viewMap Displays the entire map of Chicago dividedinto regions.

viewLevelMap Shows the map of various levels available inthe present location (inherits from classLevel)

Constraints

context Map::viewLevelMap() pre:


94


Resources

Resources are key for a player as it emphasizes the concept of foraging

1. Gold2. Lumber3. Stone

These are the items that the user can acquire through foraging. It contributes to playerstatistics. These can be gained or lost based on the outcome of the player’s skirmish withanother player/AI

Class Resource: This class displays information about the user’s resources and tracksany changes in them.

Methods Description

viewResource Displays the current resources held by theplayer

trackResource This method keeps note of changes in theplayers resources(which may take place dueto foraging, battling, etc) and updatesdatabase accordingly

Constraints

context Resource::viewResource() pre:

inventory.exists(r:Resource | inventory.resources.equals(r))

95


96


21.Testing

21.1 ObjectiveThis document describe the acceptance test and test cases for Crimson project

21.2 Roles and ResponsibilitiesThe test team responsible for performing tests consists of:

Test team leader Client Representative Testers Data Analyzer

2.3 Testing ProcessThe goal of acceptance test is to make sure that the system complies with all requirements.Crimson testing process consists of two parts: (1) The first part concentrates on functionalrequirements and usability, performance, reliability requirements with group of testers. (2) Thesecond part covers most non functional requirements by survey data collection.

The first part of the test consists of user walkthrough scenarios to make sure that the game willbehave as expected. It also covers some non functional requirements to ensure that usability,performance, security and other aspects of project are meet as well.

The second part consists of two survey data collections:1. Sample members are selected among potential users. This survey focuses on

appearance, usability, and learning requirements.2. Sample members are selected from developers. This survey gathers the information

about speed, reliability, fault tolerance and other requirements about system functions inlong term period.

When all the unit, integration, and system testing has been passed then the acceptance testscan be performed.

To start the acceptance tests some conditions must be met:

1. Appropriate testing environment as described in System Design for simulating theapplication environment. Access to this environment is restricted to test team members.

2. A sample application for testing which is installed on testing environment3. Multiple testers4. sample members for survey are identified

Each of our test cases should be perform by at least one device (mobile phone or tablet). Inmany test cases we need more than two devices to participate in the test. It’s strongly

97


recommended that these tests perform with different type of devices. ( e.g. for Join existinggame test we need at least three devices it’s reasonable to use a tablet , Android phone and aniPhone.)

21.4 Testing ItemsTesting items in this process are:

1. Authorization: Validating the user when connecting to application.2. Access Level: Specific service permissions for a valid user.3. Correctness: Meeting client requirements in functionality.4. Ease of use: Ease of use and user friendly environment.5. Performance: Speed of connecting, processing and responding to user requests.6. Portability: Ensuring the application runs on different platforms.

Test Case: Account Creation

Corresponds To: Functional requirement 1.7.1 and Nonfunctional requirement 1.13.C.1

Precondition: Test application is installed on testing environment.

Flow of Events: Bring up the application. Select Create an Account option. Create a new account with “Test User” as user id, a valid

email, password, Address and valid date of birth. Select ‘I agree’ when prompted with the EULA. Push submit button and create the account. In the new menu select setup Profile option. Upload a photo with maximum size of 300M. Exit Profile option and select it again. Confirm that photo and other information displayed is equal to

what you entered and uploaded. Confirm that Account information is equal to what you entered. Delete the “Test User” account and close the application.

Test Case: Game Creation

Corresponds To: Functional requirement 1.7.8

Precondition: Test Application is installed on all devices. Three testers are requiredfor this test.

98


Flow of Events: Testers start the application. Each tester must create an account by “TU #” id. “Test User 1” should select the account button and push

CREATE A NEW GAME option. In game page type “TEST GAME 1” as the name of the game. “TU1” should select INVITE OTHER PLAYERS and add “TU2”

and “TU3” to “TEST GAME 1”. “TU 2” and “TU3” must receive notification of invitation to a new

game : “TU 1 invites you to join TEST GAME 1, Do youconfirm?”

Test Case: Browse Games and Join

Corresponds To: Functional requirements 1.7.2 and 1.7.3

Precondition: Test Application is installed on all devices. At least four testers arerequired for this test.

Flow of Events: Testers start the application. Each tester must create an account by “TU#” id. “TU1” , “TU2” and “TU3” must each create a new game with

“TEST GAME #” title. “TU4” should select AVAILABLE GAMES option from account

menu. In the new screen there should be three available games each

titled as above. “TU4” should select one of the games and push JOIN GAME

button. New screen must display the game and available players. “TU4” can view his/her profile info to ensure the changes are

saved.

Test Case: New Player Notifications


Precondition: Test Application is installed on all devices. At least two testers arerequired for this test. Test user “TU1” must create a new game titled“TEST GAME” based on test case “Game Creation”.

99


Flow of Events: “TU2” sign in to application. “TU2” selects AVAILABLE GAMES option from account menu. A list of available games displays which contains “TEST

GAME”. “TU2” choose “TEST GAME 1” to join. As “TU2” joins the game, “TU1” receives a message “TU2 has

joined the game”.

Test Case: Dropped Player Notifications


Precondition: Test Application is installed on all devices. At least two testers arerequired for this test. Test user “TU1” must create a new game titled“TEST GAME” based on test case “Game Creation” and “TU2” mustjoin the game as described in test case “Browse Games and Join”.

Flow of Events: “TU2” chooses the LEAVE GAME option from game options. As “TU2” leaves the game, all remaining players in “TEST

GAME” will receive the message “TU2 has left the game”. The profile for “TU2” is updated.

Test Case: Player Limit


Precondition: Test Application is installed on all devices. At least 51 testers arerequired for this test. Test user “TU Host” must create a new gametitled “TEST GAME” based on test case “Game Creation” and “TU2”through “TU50” must join the game as described in test case “BrowseGames and Join”.

Flow of Events: “TU51” selects the AVAILABLE GAMES option from accountmenu.

A list of available games display all games in progress whichcontains “TEST GAME”.

“TU51” selects “TEST GAME” to join. The application prompts a message stating that the game

“TEST GAME” is at maximum capacity.

100


Test Case: Personal Configuration

Corresponds To: Non-functional requirement 1.9.B.1

Precondition: Test Application is installed on all devices. At least two testers arerequired for this test. Tester with “TU1” must create a new game titled“TEST GAME” based on test case “Game Creation” and “TU2” mustjoin the game as described in test case “Browse Games and Join”.

Flow of Events: “TU2” selects CHECK IN option, and checks in to a validlocation.

“TU2” receives a message “What are you planning to do TU2 ?”

The application displays new options on the screen. “TU2” can choose CHANGE ALTITUDE, FORAGE, DISPLAY

PLAYERS, or PLAN AMBUSH.

Test Case: Notification Management

Corresponds To: Non-functional requirement 1.9.B.2

Precondition: Test Application is installed on all devices. At least two testers arerequired for this test. Tester with “TU1” must create a new game titled“TEST GAME” based on test case “Game Creation” and “TU2” mustjoin the game as described in test case “Browse Games and Join”.They both check in to one location.

Flow of Events: “TU2” turn off notification in the setting menu. “TU1” selects DISPLAY PLAYERS option in the game menu. “TU1” selects “TU2” and chooses the SKIRMISH option Application does not send any notification to “TU2”.

Test Case: Game Updates

Corresponds To: Non-functional Requirement 1.12.A.2

Precondition: Test Application is installed on device and is not currently up-to-date.

Flow of Events: The user launches the application.

101


A prompt notifies the user that a game update is available andis required to login.

The user updates the application to the most recent versionthrough their devices application store.

After the update has been applied, the application returns tonormal functionality.

Test Case: EULA Updates

Corresponds To: Non-functional Requirement 1.13.C.2

Precondition: Test Application is installed on device and the user has not agreed tothe newest EULA.

Flow of Events: The user launches the application. A prompt notifies the user that the EULA has been modified. The user clicks ‘I agree’. The application returns to normal functionality.

Test Case: Authentication

Corresponds To: Non-functional requirements 1.13.A.1, 1.13.A.2, and 1.13.A.3

Precondition: Test Application is installed on all devices. A minimum of two testerswith ‘Player’ roles and one tester with a ‘System Administrator’ role arerequired for this test. Tester with “TU1” must create a new game titled“TEST GAME” based on test case “Game Creation” and “TU2” mustjoin the game as described in test case “Browse Games and Join”.

Flow of Events: “TU1” choose account menu and can view his/her account infoand profile.

“TU1” selects “TU2” from the “TEST GAME” menu and viewhis/her basic information. Only user name,race ,attack/defense power. Further information about “TU2” remainshidden to “TU1”.

“System Administrator” can view both players information onhis/her screen.

21.5 Testing Survey

102


A survey was conducted among a group of possible users of the Crimson app between ages 15to 30. The survey included critical aspects of Crimson’s non-functional requirements and theparticipants were asked to give their response based on a scale of 1 to 5 (1 being poor and 5being excellent). The survey questions are focussed to analyze the game from the player’sperspective and to check if the requirements have been met.A requirement passes the test if more than 80% of participants score it good or excellent (4 or5).

1. Appearance and Style

Were you satisfied with the appearance of Crimson?

Did the classical style interface appeal to you?

Were you comfortable in interacting with the Crimson interface?

Did you feel there was a consistency in Crimson’s design?

Would you say that the looks of Crimson played a big role in your gaming experience?

2. Ease of Use

Was the Crimson app user friendly and accessible?

Did you feel at any point during the game that you required assistance regarding gameplay?

Was the Crimson game easy to access & download from the source?

Was the app fast and faithful in responding to commands?

3. Learning and Understandability

Was the Crimson game easy to understand?

Did the in-built help function answer any queries you had regarding gameplay (if any)?

Did you feel that all aspects of the game interaction were understandable and polite?

Did you find any part of the game design as annoying or unpleasant to view?

21.6 Acceptance Tests

The following surveys were conducted as part of the internal report. These were addressed to a

103


team of testers who rigorously participated in perfecting the game.

1. Speed, Reliability and Fault Tolerance

Was there a minimal response time (from game system to user) during gameplay?

Did the game perform well under weak signal strength?

Were all details such as GPS coordinates provided in the game accurate?

Did the game provide good uptime with consistent performance under all conditions?

2. Operation and Environment

Was the game playable anyplace where wifi/packet data transfer (3G/4G) is permissible?

Did the game run perfectly on both Android and Apple operating systems?

Did the auto-update feature of the game perform as expected?

Did the game run in all environments and all geographical locations within the prescribedboundaries?

Did the game performance vary if there was an increase in the number of current onlineplayers?

3. Integrity, Compliance and Standards

Was all data validated during registration?

Did the backup system function as expected?

Did the game adhere to all the standards set by the company?

Was all user information securely stored in database without giving allowance to any sort ofhacking?

104


105


22.Team Send Off

Students can reasonably be expected to finish this application in two sprints of 4 weeks durationeach with game play working

Release 1 - Week 1 to Week 4

Release 1 - Week 1 Checklist

Is there a server in place?

Can the server register and store user information?

Can the client create an account from the application?

Does the application work on both Android and iOS devices?


Does the application allow the user to edit their own account information?

Can the server register check-ins?

Can the client check-in to a location?

Can the server retain game environment information on a check-in location?

Can the client see game environment information at a check-in location?


Can the server regulate location resources?

Can the server regulate skirmishes?

Can the client perform actions such as Forage and Skirmish at a location?

106



Can the server host multiple simultaneous game sessions?

Can users join and drop from game sessions?

Can the server regulate game ending conditions?


Does the application have a user interface with a theme similar to the game?

Does the user interface represent itself accurately across multiple screen sizes/devices?


Is the game world represented within the server?

Has user surveying begun in regards to the user interface?


Has a dedicated testing team begun playtesting?

Can the application handle game updates?


Has a playable version been play tested by users not involved with development?

Have all high and medium priority bugs been resolved?

23. Conclusions and Development Process Review

Crimson development process emphasized on human roles and relationships betweendevelopers. The roles and responsibilities played an important part in the project, different taskswere assigned to different people with close communication and constant cooperation. Thismethod allowed development teams to concentrate on the important functions first hand,delivering them as fast as possible, gathering feedback from client, and adjusting and improving

107


the product based on collected information.We divided our development process into smallreleases with short cycles, all steps were well documented and adaptive. The developmentprocess was changed multiple times from the original sketch to final production. In all being astrong team that was commited to get the job done well and being able to think through manyparts of the system that tripped us up.

The initial phaseComing up with an idea which necessitated a 3D perspective was a challenge. Not only is itdifficult to implement in this genre of games but in general implementing a 3D aspect in a gamewhich is unique, unlike normal first person shooters or mazes, was a challenge.Also coordinating all aspects of the game and linking each function to another so that the entiregame is well orchestrated required a lot of brainstorming as well.

Implementing an age old concept such as a fantasy genre game in a radical thinking geolocationbased environment was also a challenge, in the sense, the game should not be mundane tousers and they should not be thinking that Crimson is just yet another fantasy game. Theconcept of geolocation truly involves the player and immerses him/her inside the virtual world.

RequirementsAny game which consists of players should have certain attributes such as hit point, attack,defense and so on. Coming up with these game specific terms as well as manipulating the mapof Chicago into something of a medieval type was tedious, but fun. The various requirementsthat this game would satisfy, keeping in mind the player’s perspectives was good practice.Thinking about the system as a whole was difficult and a lot of brainstorming went into it.

System designIn terms of the system design, the concept of AI character was challenging. The AI is part of thegame and is capable of upsetting players. This needed a lot of thinking. The system architectureas a whole took a lot of time to come up with. The game required an architecture whichfacilitated communication amongst various elements which together would hold the entire gamein its place. For this purpose we came up with the Client-server architecture which uses theXMPP protocol for communication between various subsystems in the architecture and wouldserve as a bridge between the client side and server side. This system was reviewed by usthoroughly and found to be the most appropriate. Identifying the various subsystems, by itself,was a challenge as the game is huge and has various concepts interlinked. Hence connectingtogether all the pieces was quite the task.

TestingThe Crimson game was designed entirely keeping in mind the player and his perspectives.During testing, all of the requirements and goals set were fulfilled so that the game would comeinto fruition entirely and the user would have an unparallelled gaming experience. All aspectsright from the functional requirements derived from use cases and scenarios, to thenon-functional requirements were introspected and tested upon. The testing also included a

108


survey in which the game was handed over to a set of possible users and their responses weredocumented.

What worked wellBeing a strong team that was commited to get the job done well and being able to think throughmany parts of the system that tripped us up, was one of our strengths. Being perfectionists isnot a downside when the goal is to make the customer happy with the product. Thebrainstorming sessions really helped in developing a quality product. No stone was left unturnedas we made use of each member’s strengths and ideas.

109

Documents

Crimson: Massive Multiplayer Mixed Reality Game Group 2pmody/Crimson Report.pdf · Mixed reality games are part of a growing genre of games that involve real world locations, artifacts,