Location-Based Games

Project Summaries

submitted by student groups in

CS 440 - Introduction to

Software Engineering

at the

University of Illinois, Chicago

Fall 2016

John T. Bell, Instructor

Tanima Chatterjee, TA

Instructor's Notes

During the Fall 2016 semester the students enrolled in CS 440, Introduction to Software Engineering, at

the University of Illinois Chicago were asked to work together in groups on two different software

engineering projects, representing roughly the first and second halves of a complete project. The goal

was to give the students experience working in groups on a ( relatively ) large software engineering

project, for which they alone were responsible for the specification, design, implementation, and

validation of the project. Splitting the complete software engineering experience into two half-projects

allowed students to begin the implementation phase of the coding project early in the semester, thereby

allowing time for thorough testing and inspection of significant amounts of real code. As an added

benefit, students were faced with the realistic challenge of specifying and designing their new original

systems in sufficient detail that future students that they had never met would be able to implement their

visions, while simultaneously working to implement the vision created by former students.

For the coding project, their overall task was to implement and thoroughly test ( at least a working

prototype of ) an object-oriented software design that had been previously developed by former students.

This work represented the final two stages of a complete software engineering project, ( implementation

and testing ), and gave the students the perspective of completing a project that had been conceived and

initially planned by other software engineers. For this work, the students utilized agile development

methods, conducting two sprints of development to yield two versions of a working prototype, and one

sprint of code testing and inspections.

For the development project, their task was to conceive an original software product, and to develop it

through the requirements, system design, and object design phases, using a more traditional waterfall

approach, for eventual implementation by other students in future semesters of CS 440. This work

represented the initial stages of a complete software engineering project, and gave the students the

perspective of developing a complete software specification and design to be eventually implemented by

other software engineers.

For Fall 2016, the development project was to develop location-based games, in which a player’s

location in the real physical world would somehow have an impact on their play of the game, and in

which player’s would be encouraged to move around in the real world in order to play the game. Well-

known examples of such games are Pokemon Go and geocaching.

In developing the initial project descriptions, detailed system requirements, system and object designs

and acceptance test plans for these software products, students were asked to not limit themselves to

what a small group could accomplish in a few months, but rather to go ahead and plan a project as large

as it needed to be to get the job done. Major reports were due every few weeks, and at the end of the

semester, students submitted a final overall report of their project results.

Overall the students completed both their projects admirably, producing some very good working

prototypes for their coding projects and some very thorough software requirements, designs, and test

plans for their development projects. This document includes the two-page summaries of the

development projects submitted by each of the groups. Anyone interested in learning more about the

systems described here may either contact the course instructor or the students involved directly. In the

meantime, I only hope that the learning experience turns out to be at least as valuable as the finished

software designs.

John T. Bell

December 2016

“Go Geo”

Group 1 – Zainab Al Qurashi, Deven Patel, Dhrumil Patel, Venkata Ramkiran

Summary

“Go Geo” is a location based game where the actor travels to various places in the world and accomplishes

certain targets. This game is especially designed to educate the people of the climate changes and its

impacts. It also tries to empower the users on how to overcome these challenges along with fun and

excitement. In this document, we are providing both functional and non-functional requirements along

with the test plan summary of the game as below.

Some of the functional and non-functional requirements are

The application should provide a unique id to the new user who signs up for the game and should

retrieve the information of status of the game based on the unique id for the existing users.

The application should provide a demo training for the new users to understand the game before

jumping to the actual game. The application should have a help option for the player to reach out

for assistance whenever required.

The application should have various locations in the different countries as the levels of the game.

The worst hit locations due to climate changes should be selected as the levels of the game.

The application should display the default location for the new user to play the game and rest of

the levels should be locked. For the existing users, the system should also display the unlocked

levels.

The application should unlock next level only upon completion of the current level.

The application should allow the user to team up with other active player and play as multiplayer

game.

The application should provide information of the location before the start of the gameplay of every

level.

The application should display the tasks to be accomplished to complete the level and move on to

the next level.

Non-functional Requirements

Usability: The game ‘Go Geo’ is for all age groups but is specifically targeted to the school students. So,

the game should be very user friendly and should be easily understood and played by even novice user. The

help option should aid the user whenever needed.

Reliability: The database server that connects the game to the various device should be up 99% of the time

and any maintenance should be done without the affecting the original game. The user must not be lost in

case of any server crash.

Performance: The application should take maximum of 20 secs to load any new level or move to any menu

and shouldn’t produce any lag or jitter or other defects.

Security and Supportability: Only developers must provide updates to the game. The game must support

the earlier versions in all devices without any errors. The user should try to update the game before the

previous version becomes obsolete.

Test Plan

The testing for the Go Geo game will consist of unit, system/integration and acceptance level tests. The

unit testing will be done by the development team as well as the dedicated test team of the application. The

system and integration tests are done together and are done by the test team. The acceptance test will be

done by the end users under the supervision of both the development and test teams.

Class Diagram:

The entire game can be summarized using the class diagram as below. All the classes and

corresponding methods were included in the diagram.

Finally, Go Geo is a mobile application game that can be downloaded from the istore or the play

store as well as play on the desktop using google maps. We could derive the idea from the game

and make it played on consoles like play station and make it more enthralling. Multiple versions

of the game can be released, each for its own type of engine.

Quiz Quest Description Summary

Group 2: Tsz Lam, Tan Le, Anthony Nedumgottil, Weiheng Ruan Introduction:

Quiz Quest is a location-based mobile game that enable the user to have fun while learning. The purpose of this game is motivate users to travel to variety of places to learn more about the history and interesting new facts about those places. This game is generally targeted toward all ages. Anyone that have a passion for trivia quizzes would find themselves indulge in Quiz Quest. The objective of this game is to answer quiz questions at famous landmarks. By doing so, the users will learn new things about the world around them.

Requirements:

Quiz Quest will have many different requirements that must be met before, during, and after the time of launch. There are 8 main use cases at the current time of development, Register New User, Login Existing User, View the Leaderboard, View Quiz Locations, Take Quiz, View Quiz History, and View User Shop. We have detailed uses case diagrams for all of these examples in our design document. Since Quiz Quest is a simple, yet fun and interactive game there are only five functional requirements. The system must really allow users to find and take quizzes as well as store information about the user such as account authorization information and their overall score they have accumulated while playing Quiz Quest. The game map is a core feature of Quiz Quest and the game would not be playable without it, luckily the map data is being outsourced to Google Maps as we will be using their API for the backend of our game world.

There will be 2 databases that Quiz Quest will host and manage, the User and Question databases. The will be secured and monitored by Quiz Quest. The location is provided to us from the user’s GPS on their mobile devices and the Map data is managed and owned by the Google Maps team.

The performance of Quiz Quest will be highly monitored and altered in the case where it doesn’t meet our standards. Since we want users to quickly open the game when they’re at a location, answer a quiz, and then continue on with their day we will have a lot of speed and latency requirements. The Splash screen should load

immediately once the game is launched. The Login process should not take more than

300 milliseconds. New screens and windows must be loaded with in 2 seconds and will timeout if the response is longer than 5 seconds. Not only is speed one of our performance requirements but we also want Quiz Quest to be highly precise and accurate. All mobile devices using this game must have GPS 2.0. • The system should try it’s best to accurately measure and display the user’s positon relative to the map, however there will be limitations due to how accurate the GPS is and other external factors. We also want a large concurrent user base playing Quiz Quest so, the server(s) must handle at least 1,000 concurrent users at once.

We would also like to keep our company, Quiz Quest LLC, in a good light with the public so we are also strict with our dependability requirements. We take extra

precautions so that User information such as their account, shall not be lost in the case of a system failure. We make sure that maintenance must be done periodically to the system. Safety while playing Quiz Quest is also an issue so we encourage that the user should not put themselves in any harm or engage in describe behavior while traveling to other Quiz Locations.

Test Plan:

Since Quiz Quest wants to offer the highest quality of educational quiz game experience we take our quality assurance tests very seriously. We take our testing very seriously but since Quiz Quest is a very simple game we only have twelve test cases, since the number of test cases are so low we make sure we accurately execute them. We test that a new user can register, a returning user can login, testing various UI interactions, how responsive is the map and GPS, testing the game status for Users, testing whether or not the correct quiz questions are being populated at that specific Quiz Location, if the purchases the user made are being stored correctly, if there are delays in the system, if the fatigue system for users is working correctly, if the map renders properly, and if the difficulty system for questions is working. We will try to test our speed requirements as well but there are some factors that are out of the control of Quiz Quest LLC, like the user’s internet connect or mobile device processing power, that we cannot control and will not take in account for when we perform our tests.

Design and Subsystems: There will be several interfaces. Some of them include:

User – Player, Location_Owner, Q_Q_Admin

Quiz Location – Name, Owner, Quiz, Facts

Support – Local Support, Legal Support, Maintenance There can be three types of Users. Players, are users who are players of the game. Location_Owner, are the business users who own Quiz Locations. Q_Q_Admin, are game administrators who work for Quiz Quest LLC, these users can have full access to the system. The Quiz Location will have a lot of details about them. The Name is the name of the location. The Owner is the owner of the location. The Quiz is the quiz you take at that location. The Facts are some fun fact(s) about that location. There will be three main support teams. Local support is your typical customer service team to help Players and Location_Owners with their issues. Legal Support is to cover any legal issues that Quiz Quest LLC might face. Maintenance is our Dev team + System Architecture team.

Summary: Reign Reality Group 3: Sriram Rajaram, Talab Omar, Jacob Abraham, Lakulish Gandhi

Over the course of the semester, we developed a location based game called Reign Reality. The goal for this game is to have each player build up their village/kingdom and expand the boundaries. This could be done by going into the real world and picking up resources based on the location provided, or they could start wars with other villages and take over these new lands, or they could make alliances and combine all of the villages in their alliance in an effort to gain total domination. Once the idea was in place, we had to find stakeholders who would help us pay for all parts of the game, think of all the requirements that needed to be in place to develop the game, design the game, and make test plans. That way, once the project starts, there will be no issues. All the information needed to make this game will already been in place. Everything would be in the documentation provided.

The client who we thought was a great fit for this game was Visual Freedom. The

company, has designed quite a few fantasy and science fiction games. That experience would help our game in a big way. Having a support system that has developed a game like this would definitely speed up the process. In addition, they will be the main group that funds our game. Paying for a secure database and good software is not cheap. Having them contribute will help us make the game how we see fit. Money will not be a pressing issue but we will still keep tabs of the how much money is being spent and make sure we don’t spend excessively. Having somebody with deeper pockets goes a long way. Once, the stakeholders were all in place, as said earlier, we created many requirements. These requirements would contain the basics of what was needed in the game. For example, how the game was supposed to be played, how we will maintain the game, and most importantly, the performance and security measures needed to make the game completely functional. Security is always our greatest concern. Our clients and users should be safe at all times. To do so, we will stand by the privacy policy provided. We will try to make sure that our systems are never breached and everything is always secure. Performance wise, the users must always be happy. That way more will play the game thus making the game more profitable. To make the users happy we provided various performance requirements. Our standards for Reign Reality are very high. There should be little to no delay to each feature the user wishes to complete. Everything must be quick and responsive.

Once all of the requirements were taken care of, we now had to make sure that the project design was completed to perfection. Yes, overtime things make change. The project will be extremely agile. However, to make a project agile, the basics must first be designed and implemented. That was our main goal when creating the project design. Because of that, we didn’t go through the absolute specifics in the report provided. Those would depend the whims and fancies of the development team. Having some sort of leeway and letting them be creative,

as long as what they are doing is approved, would make our project as a whole much better. The main things we designed were the system, the supposed software architecture, the user interface and many more. All these designs could definitely change in the future. However, providing a basic layout of what the game would look like will help steer the development team in the right direction. Having them provide us something from scratch would not be very productive. By us giving the development team something to work with, we can speed up the development time of the product and get it to the production stage and the open market much faster.

Before getting it to that point, we will need to run rigorous tests on this application. To account for that, in the documents provided, we have given a test plan. This test plan tells the development team what to look out for, and how often the are required to complete testing. We felt that it would be much faster for the team to do their testing as they complete each step in the development stage. That way, it would be much easier to make changes and catch bugs. If the development team only tests at the end, it would take substantially longer to complete all of the testing and fixing all bugs. Once testing is complete, we will receive a report from them saying what completely works and what needed fixing and so on. From that, we as the owners of the company will be able adjust our timeline, and get a rough estimate of when exactly we will be able to put this game on the open market.

Overall, we are quite excited to be building such a game. Our goal was to make a game, that fuses many ideas together. When Pokemon Go came out, we were really surprised to see how many people were actually playing it. Because of that we decided to break into the location based gaming marking. In addition, having a game that is is of the science fiction and fantasy genre, in a way helped us kill two birds with one stone. That market is also still booming. Games like Clash of the Clans and Mobile Strike are still being played and downloaded at an excessive rate. Having our game be a part of both markets, will hopefully be as successful as the games listed above, if not much better. One way we could be better is by drawing different age groups to our game. We know that usually the younger generation are the one who will be playing our game, but it would be in our best interests if the older folks started playing our game as well. Having this game reach out to all various ages is one of our main goals. If that is attainable, we believe that our game will be extremely successful. We look forward to starting the development process of Reign Reality. It may take quite a while for it to be completed and hit the market, but we believe we can get it there. We have no intention of rushing things and providing the users with some “random” game that’s out on the market. We want to be the main attraction. However, that takes time. Going through all the various requirements and rigorously testing the project will not be trivial. All the code written will be checked repeatedly until it satisfies all the requirements provided and there are absolutely no bugs within the system. Our main goal this semester was to complete all of the necessary documentation needed to move this project into

development phase. We are extremely interested in developing Reign Reality in the near future and hope it will turn out to be a major success.

Guerre Géo Group 4: Henvy Patel, Janki Patel, Ishta Bhagat, and Aiwan Hazari

Description Guerre Géo is an educational and adventurous multi-player game where the player solves interesting puzzles and trivia questions based on their location. This game is available world-wide. Guerre Géo is a mobile-based application, supported on iOS and Android devices. Guerre Géo defines a new way of challenging one’s geographic knowledge and puzzle-solving skills. Guerre Géo is an approach to make users more motivated to be physically active. Each player in the game belongs to a team: Bandits or Warriors. The player is required to visit coinspots and hotspots around their neighborhood to solve défi (puzzles and trivia questions). Upon successfully solving defi, the player would receive coins at coinspot and gems at a hotspot, which can be used to switch their team. Furthermore, the player can request a duel challenge to any players from the opposing team who is nearby. Guerre Géo is an approach to make people active by requiring them to visit coinspots as well as educate them about their surroundings. Requirements Functional Requirements The system must provide a means for the players to sign up for the game. The system must provide an option to choose teams. The system must provide all users with an option to spot their location and other players near them. The system must provide the players an option to view the amount of coins collected. The system must provide an option to request duel challenge to another player. The system must provide an option to switch teams. The system must provide a means for the player to solve défi. The system must provide an option to view défi hints. Random coinspots and hotspots should be added to allow users to visit them to solve défi. The system must allow the DBA to generate défi based on the location. The system must allow the user to edit their profile. Non-Functional Requirements Performance: It is very important that Guerre Géo is quickly able to adapt to changes. Therefore, measuring the speed and latency of the game is very important. The game should generate défi in less than two seconds and update player’s location in less than five. Accuracy: For a better user experience, the Guerre Géo should be precise and accurate for all players. The défi must be accurate based on the player's location. Furthermore, the system should provide the same défi to both players, when a duel challenge is requested. The system should accurately verify the players’ solutions to the défi. The system should also accurately keep track of the player's coins and provide hints accordingly.

Dependability and Maintainability: The game should be available 24 hours all year around. In case of any system break, there should not be any data loss and no security protocols skipped. Also, there will be continual game improvements are users play. The users will be responsible for their own actions or injuries caused while playing the game. Usability: The usability of the application for the user should be easy to use and should challenge the players to help them gain general knowledge about the place they live in. The tutorial, when the user first opens the application, will have easy instructions on how to play the game. The users should be able to use the product easily and will need to bring their general knowledge to quickly recall facts. The user should also have a high satisfaction rate. Security: All of the user data should be encrypted and stored into the database. The servers and database should be protected. The encryption for generating the défi should also be advanced enough so that the user cannot hack the game and be the ultimate player. Look and Feel: The game should be appealing to the users with an attractive GUI. The users should feel inclined to solve the clues and be challenged, and be happy during and after the game. Cultural, Legal and Political: Content of this game should not offend any group of race, religion, or nationality. There will be no political affiliation. Furthermore, the game’s rules should comply with the laws of each nation. Test Plans Testing is important in developing this game to insure the best user experience. We must test that the spotting tool shows nearby users, coinspots, and hotspots. Furthermore, we should test that the défi is generated related to the location and when the user solves it, the answer is checked accurately and the result is stored into the database. The test should not only check for the correctness of the tools, but should also test its performance in terms of time. Design In order for this game to be optimal and maintain popularity in the market, there are design goals that would significantly improve the game. The system should be fast at the cost of some accurate calculations. The game should show the user’s location as quickly as possible, and it is considered still accurate if the user’s location is on the other side of the block rather than the exact location. Conclusion Overall, Guerre Géo is a world-wide mobile game that allows users to explore their neighborhood, educate themselves about it, and become active. Furthermore, there is a business aspect that is appealing because partnering with businesses in the area to help advertise on the app, can make the company more profitable. But the main goal of developing this game is to let people use it to gain more general knowledge. Guerre Géo allows them to play individually or with other players, which is why this game provides a fun and new way of learning about general knowledge on things and places around them.

Magia - Final Summary

Group 5: Shagiya Mansuri, Christian Valladares, Chris Hong, Fayaz Khan Project Description

Magia is a highly social and interactive fantasy game that promotes exploration, competition, cooperation, and interaction with the community. It will use geolocation services to facilitate interaction amongst the involved parties, and will open new venues for marketing for private firms. This project will also encourage users to interact with their communities, and provide an alternative form of entertainment. Magia creates an environment that encourages users to interact with not only the virtual world of the game, but also the community in which they reside. Magia will strengthen the bonds between local residents/gamers with the local businesses and organizations. Purpose The purpose of this application is that of encouraging interaction, especially in the current context of social media and socializing remotely. We want users to challenge these models of interaction, and to broaden the space in which they operate, to promote healthier individuals and healthier communities. The user will be playing the game but the player will also have to interact with business that have signed an agreement with our cooperation on a subscription bases. Business Model The user’s character will have attributes that will be depleted as the game is being played. The player can revive this by interacting with business. The business can provide attributes to players based on the subscription they have subscribed to with our corporation. There will be several levels of subscription: for example a business can be subscribed to a bronze level subscription. Further, the business will be present in the game but may not generate as much traffic as platinum level. The bronze level will provide various attributes such as health revitalizations. When a business subscribes to a platinum level subscription they will be provided rare items such as a booster potions, spells, and other unique items. Platinum subscription will differentiate between other business and thus generate more user generated traffic to desired locations.

When a business subscribes to platinum subscription, they will be provided with a rare attribute. After several users attending location to attain rare attribute thus rare attribute is no longer rare. After reaching peak how to retain subscription from business and also continue new users to visit location Functional Requirements

The system shall display the latest and relevant news about the player’s environment. The system shall display the Overworld screen once the user has successfully logged in. The system shall update the overworld as the user moves in real time. The system shall update the overworld in real time to only display items that are in the

user’s vicinity.

The system shall notify the user when they have collected the targeted items. The system must show a description of the items in the user’s inventory. The system shall transfer users to an augmented reality when the user interacts with a

rune. The system shall activate the user’s camera once the user enters into augmented reality. The system shall notify the user of the success or failure of a purchase.

Design Performance - the system should be responsive, and the game should avoid any sort of lag or stuttering whenever displaying the Overworld or the Arena gameplay. The game should not get overwhelmed by the amount of players connected to the game.

Dependability - the system should allow for countermeasures on erroneous or abnormal states in the program. The system should ensure that the transactions are valid, both monetary transactions and gameplay transactions.

Maintenance - The system must expect frequent changes, and must allow for modularity: it should allow for the adding of features (new items, new gameplay, new battles), and the system must also allow for the removal of gameplay features when deemed unnecessary or against the purpose of the system as it evolves.

Usability - The system must be accessible to all audiences, and must avoid a complicated design so as to deter the loss of players due to an unaccessible, complicated design. Test Plans A test will be considered a pass if and only if the actual results of the test match the expected results specified in the associated test case. Some features to be tested include: Register Login Overworld Resource Gathering Engaging NPCs

Battle Lobby Battle Arena Shop Avatar Customization Changing Active Movelist

Manage Inventory Logout Help Menu Settings

Target Audience The targeted user business are the player base which includes individuals with health goals in mind, with a desire to explore the community. In addition it targets players looking for a rewarding and competitive gaming venue. Finally, it targets businesses that seeking to expand their marketing range.

User Participation

Users are necessary to provide Magia with a community and the funding to provide the application regular updates, new features, and customer support. Magia is meant to be a game for regular and dedicated players that will create a community. Their opinions will help shape and grow the application during its lifetime. Constant feedback will help to find bugs quickly and improve broken mechanics.

Geo Scavenger Hunt Group 6: Harsh Patel, Jay Patel, Jaydeep Patel, Krupa Patel

Introduction:

Scavenger Hunt has been one of the most popular games played by everyone. We have tried creating something new and different from the traditional scavenger hunt. With this modern scavenger hunt, a player is able to play the game on a mobile device. With this new approach, there is no risk of losing clues. By creating digital version of the game, we are adding features like tracking user data with new technologies. Users can also use this product as a means of networking. We are making this game more modernized by adding business approach to this game. The game allows small business to promote their business in a gamely manner. The user will be a range of individuals such as students, organization leaders, and basically anyone who loves to solve complex puzzles and earn prize. We will also have small business owners as our targeted audience for this game. All in all, our game is scalable and can be used by many people at the same time. Key Features:

Geo Scavenger Hunt has key features that differentiate it from other similar softwares out in the market. The key features of the game are listed below:

The game displays a dashboard that helps user keep track of their past performances.

The game keeps track of user data, such as the amount of distance a user has walked and

at the pace they have walked.

The game gives a dashboard view to the user that displays metrics, such as the amounts

of hunts they have completed and their success ratio.

The game will utilize Google Maps api to put down puzzles on the map, so user gets a

good view of where to go.

The game allows its consumer to raise awareness of their affiliates, create puzzles by

using localizing approach.

The game will utilize native push notifications within the mobile device to deliver

updates to the users.

The game allows its consumer to concentrate and target a specific type of audience by

utilizing data gathered by the game.

The game will provide instant messaging service using #Slack api

The game allows the integration of a real time database, which will help developers make

changes quickly and efficiently.

The game allows integration of multiple platforms like Facebook, Google, Twitter,

Outlook, Hotmail, Yahoo and give everyone the ability to sign-up with any log-in.

Test Plans:

Geo Scavenger Hunt will be tested thoroughly before deployment. All requirements will

be mapped to a corresponding test case. The test planning will begin as soon as the requirement

selection of the product begins. Unit testing will be done by the developing team followed by

system integration testing and client acceptance testing by a dedicated testing team and client

respectively. Even if a single test fails, the feature as a whole is considered a failure. The app

will be tested on both iOS and Android platforms. Whenever new features are added, additional

testing should take place when they are implemented.

Requirements:

The product uses functional and nonfunctional requirements implemented by the

development team. This game will require remote access to database in order to store all the user

credentials, user information, and payment information. We are focusing on the requirements of

three main users in our game: paid creators, non-paid creators, and players. All three users have

some basic requirements to begin: they need to have a valid email address to register or login

into the app; they must also choose their role when they register into the app for the first time. By

choosing a role, the user is able to use the functionality that are associated with it. The platform’s

response time between the user and the system should be two seconds or less. Our app shall have

an uptime of 99.9% in our servers. The only time server will be offline is when we are

performing daily maintenance or server upgrades. All the game process should be saved

regularly to assure that the no user loses their progress. Overall all the game process should be

saved regularly to assure that the no user loses their progress. Thus, with important features, the

concentration on our design and experience with our game, it will make the application stand out

application among the competitors in the market.

Time of the Ages

Group 7 - Adolfo Moreno, John Toledo, Jose Hernandez, Pranjal Desai

Game Description and Overview Time of the Ages is geo location based game that is available on all major mobile operations systems.

The objective of this game while playing is to solve and complete story quests, some of which will require the

help of other real world users to complete in order to level up your character ranking. This game utilizes a 3D

graphics engine for rendering, although an option to downshift to 2D graphics is also available for lower end

hardware on mobile platforms.

The main layout during gameplay is similar to PokemonGo, in the sense that a 3D map is displayed, a

long with your character at the center of it. Character movement is based on current GPS location. To move

your character to a specific location on the map you must walk towards that direction (n,s,w,e) until you’ve

reached your destination physically, as well as in game. While playing on your instance of the game, you may

potentially see other real in-game players, and have the option to message each other inside the app.

During gameplay players will encounter story quests which are optional missions that are placed in

various locations ranging from historic locations, all the way to ordinary houses or parks. These quests are

divided into non-fiction and fiction categories which are awarded variable number of token rewards, and

character wearable items(ie. hats, capes, attire, pets etc.) upon completion which can utilized for purchasing in

game-content. Fictional story quests will be depicted around historically accurate events that once occurred,

with the exception of essentially reliving that scenario with you as the main character. This allows users to

potentially learn about history without the boring traditional classroom setting.

The purpose of a quest is to make you as the player become the role for the main character as the story

quests plot and objectives begin unraveling. Multiple quests may also be started simultaneously. During quests

you may be asked to talk to NPC’s for clues, travel to relatively close locations in search for quest related items,

as well as riddles, and input from the user to advance in the story. These are the fundamentals for quests in the

game.

The game will contain an in-game store that will get updated at least once a month, with content such as

new in-game character attire, as well as additional quest stories some with substantially more rewards created

by a special team of story developers. A portion of the monthly released content for the store will be available

for purchase, and the remaining will be free to download.

Features

Key Functional Requirements

Game UI should allow for the player to view stats, customize character appearance, adjust settings, and

access content store for purchases.

Game UI should allow for users to choose options in the menu such as-start a new game, resume, change

settings, and logout.

Game character should simulate walking, and update character location, as your geolocation changes.

Game should allow for interaction through the user clicks at a particular location on the screen, which

would engage an activity if there is any significance at a clicked location.

Game character should be able to interact with other players, and in-game NPC’s as well as start quests,

that are within a certain radius(represented by an occasional light ring)

Additional actions and options will be displayed if player clicks on the screen a significant area of

interest (IE. read sign, enter building, attempt to search bush, cancel)

Key Non-functional Requirements

Data- Will be supported by Amazon Cloud Services to provide a strong foundation for rapid scalability

using elasticity during load peak times for client and server interactions.

Usability-Should be easily understood by audiences 8+ with minor learning curve.

Dependability – The game should not fail to be available more than once every 6 months for as most 30

mins of downtime, with the exception of crucial patch updates.

Performance –Less than 1000ms client/server responses to ensure good user experience.

Design Goals

Efficiency: This game application is only allowed to run in full screen window to ensure sufficient

system resources are available for performing graphics rendering during gameplay.

Reliability: Time of the ages has been extensively tested using unit and integration tests that reinforce

core game functionality, to ensure a stable build for release of the game.

Availability: This game has an uptime availability of 99.9%, 24/7. This is supported by a SAAS

infrastructure on the server side that allow for rapid elasticity of resources during peak loads to

accommodate rapid flux of user load and capacity.

Portability: Cross platform availability on Android and IOS phones, and tablets.

Efficiency: The game application design should maintain fast performance by offering an option for

graphics that allow for graphics rendering modification that can be adjusted automatically or manually

to optimize your systems hardware capabilities.

Security: During gameplay, any connections and communication to the server are encrypted using SSL

3.0 certificates to avoid eavesdropping, and man in the middle attacks.

Extensibility: The core game system is influenced by an object-oriented architecture as well as defined

interfaces along with documentation to support future development. This allows for rapid modifications

to the core system without causing the system to fail.

Testing Plans

Testing will be done by creating unit and integrations tests with a testing framework such as JUnit, or NUnit. We will also

be issuing invitations for a beta run of our game. The public beta will begin 6 months prior to projected launch date. This

Beta period will contain most core functionality, and will last approx. 3 months. This gives us 3 months to fix any serious

bugs found during the beta phase, to increase a more successful stable launch on the first public release of the game.

Major features we will test for:

1) Ensure that the game on the client side is always transmitting data to the server using SSL.

2) Interaction with other real in-game players and NPC’s (non-playable characters)

3) Ability to correctly recognize returning players state information

4) Whenever user input is required, validate and check for valid characters.

Test Cases:

1) During any gameplay attempt to eavesdrop using a proxy to observe network traffic – sensitive data should not

be in readable format if secure transmission is in place.

2) Perform client side API calls to server- Assert expected result with actual result

3) Save state information in an external log prior to logging out. When logging back in, compare the current state

information with the external log for any state differences(should be the same)

4) XSS(cross site scripting) and SQLI(SQL Injection) malicious strings in any user input prompt.

RPG GO - Final Project Summary Group 8 - Richard Kim, Denis Radinski, Oscar Salinas

A Brief Description:

RPG GO is a massive online multiplayer mobile game that lets players walk around their environment and gather resources placed in the terrain around them. The game generates resources periodically, and places them in different locations; so as the user travels around their physical world they are presented with new interactions. The player will be able to spend their resources to expand their base which in turn will unlock more aspects of the gameplay. Some examples include player trading and the ability to hire workers. By fully embracing the environment around them, the game distinguishes itself from competing location based games, providing a dynamic experience to the user. Since player cooperation is an essential part of the game, a chat room is featured, allowing users to connect with their friends.

Requirements: Functional Requirements:

The application must provide users with a chat system in order to communicate with other players.

The application must provide a means of showing individual users their progress. The app should present sufficient encryption to protect the personal data of the user. The app should provide the user with a variety of themes for in use purposes. Performance: The user should be directed to the game’s main screen within 2 seconds of

log in, and the login process should take no more than 7 seconds. User progress should be saved automatically, additionally the user should be receive a prompt asking them to confirm exiting the game before they do so. Logout should follow security protocols and will not take more than 3 seconds.

Non-functional Requirements: Accuracy: The user will be presented with their profile and saved progress each time they log in to a new game session. Dependability: If the application unexpectedly stops, any saved progress will be presented to the user along with a prompt allowing the user to discard that progress. Gameplay: The user should receive hints on how to interact with the in-game environment. Maintainability and Supportability: Development documentation shall be compiled and presented by the development team in order to provide later developers with the ability to provide support, patches, and improvements to the original platform. Performance: Mobile devices are limited by many factors; for this game it is important to hardware and bandwidth. For example, the game should perform well under various operating

conditions including low CPU availability or slow network speeds(2G). Additionally, the game should interact with the device’s sensors such as GPS or accelerometer in a satisfactory way. Usability: Game interaction should not take more than 2 mouse taps in order to facilitate gameplay. Buttons should be large enough and occupy an adequate amount of area for the user to operate the game with any finger. Text should be large enough to be clearly legible, a size 18pt font is recommended. The game will lock the screen at the landscape orientation and allow the user to change their preferred orientation. Testing Plans and Schedule:

Testing of the platform at all stages of development will ensure any issues are resolved promptly, and that the customer ultimately receives a quality product. Test should demonstrate that functional requirements are met and work as specified. Testing will include extensive regression tests to ensure existing functionality is not affected when new functionality or changes to the game’s platform are introduced. Additionally, tests should be conducted across a variety of devices and mobile operating systems. This will ensure the game works and responds correctly to different types of input from multiple devices. Ultimately, it is the goal of these test to ensure the game will work as expected on intended environments, showing satisfactory performance.

Design:

The RPG Go platform should support the latest four releases of android and iOS. The core software architecture will be based on the ACTOR system, which will provide a robust, parallel, and concurrent object oriented system that is asynchronous and fault tolerant. The Actor system that serves to implement the game logic will be deployed on a private cloud. The benefits of this are that on the user’s device, the app can maintain a lightweight process, and it will allow our system to scale in an elastic fashion to efficiently accommodate growing demand. Conclusion: The goal of this project is to develop a lucrative game that can compete with similar games in today’s market. The design was based on an analysis of competing games, which allowed the development team to address design flaws and propose ways to capitalize on them. Usability of the product is a primary concern, as the success of the application is reliant on creating a seamless and pleasurable user experience. A careful review of functional and nonfunctional requirements such as performance, security, privacy, usability, and availability is crucial to the success of the game. Adherence to a high standards will ensure a profitable and high quality game is produced.

Daniel Doyle, Kevin Tang, Jacky Duong, Mike McClory

CS 440 | Development Project | Group 9

12/3/2016

Dungeons & Dank

Final Summary

Product Overview

The game we’ve developed is called Dungeons & Dank. It is a location based,

fantasy adventure game where the adventurer has the ability to decide where and how

the story progresses. The adventurer will be able to choose from multiple classes for

exciting gameplay as well as exclusive quest for how they choose to lead in their story.

The motivation behind the development of this game is to create a new level of

immersive storytelling and game play to bring life the, often times stale, Role-Playing

Game (RPG) genre. By incorporating cooperative, multiplayer elements with real life

interaction, Dungeons & Dank aims to build a mesmerizing, more rewarding game

experience.

Requirements

Requirements are essential to designing and product. When it comes to

Dungeons & Dank, the most important functional requirement(what the system must do)

is give the user a way to create a character. Without that you can’t play the game. Other

important functional requirements include providing a way to enter a dungeon and

encountering an enemy. There are also non-functional requirements which aren’t

essential for the system to work, but they help define the product. They include

performance, maintainability and security requirements. For Dungeons & Dank, those

requirements include protecting the user’s information(not distributing it), providing the

users with a tutorial world(for easy learning of the game), and making sure that the

game doesn’t side with andy political or religious groups.

Design

Dungeons & Dank utilizes a Three Tier Software Architecture. The three tiers

are: the Presentation Tier, Game Logic Tier, and the Data Access Tier. These tiers

interact with three databases, the Account DB, Game Content DB, and Character DB, to

store all data related to the game. The Presentation Tier populates the GUI and handles

all in-game animations, the Game Logic Tier handles all the data creation for the game

and stores the data in objects for the Presentation Tier to use. Lastly, the Data Access

Tier handles all execution of all of queries passed to it from the Game Logic Tier.

Daniel Doyle, Kevin Tang, Jacky Duong, Mike McClory

CS 440 | Development Project | Group 9

12/3/2016

Dungeons & Dank

Final Summary

All game computation is done server side. The user’s phone application houses

the GUI, which sends and requests information to the Dungeons & Dank servers. This

ensures that all game progress is saved in the event of the phone dying, internet

disconnection, or some other service interruption for the user.

Testing

Creating an MMORPG, especially one utilizing location based gameplay,

requires an enormous cadre of tests. Some tests include: ensuring GUI responsiveness,

checking for latency issues between the player and the game servers, stress testing the

server for game performance, etc. Another facet of testing is the gameplay. Ensuring

that all content is created and seamlessly integrated with the player’s game.

In terms of database testing, because player progression is extremely important

to both the gameplay and financial longevity of the game, making sure that all of the

required databases abide by ACID properties is paramount. Extensive testing on SQL

transactions are needed to ensure that there are no phantom reads or partial changes

made to the game, such as a player receiving an item, yet not having it appear in their

inventory.

Issues

Because Dungeons and Dank is a game that heavily relies on GPS in order to

function the game must correctly read the location of the user. If for any reason the way

the GPS information is grabbed is changed and it causes conflict with the game it would

make it unplayable. There should not be any problems with the users since we made

sure that Dungeons and Dank doesn’t side with any religious group or have any political

affiliations. We also made sure that the user can easily find any information they need

as to playing the game or about the game, including a tutorial world that they can stay in

until they’re ready to begin their journey. An important issue with Dungeons and Dank

would be worried about is having an overload of players. Whether it is at the launch or

for some reason there is a huge increase in player base, if too many people are playing

and the server overloads we would not be ready to fix it fast enough to satisfy most

people.

Silent Assassin Final Summary

Group 10 - Lukasz Przybos, Neil Rao, Samer Dar-Ayyad

Introduction

Silent Assassin is a GPS based game of tag played through your mobile smartphone via Android

or iOS. The purpose of this game is to create a safe environment, but provide for real time

gameplay that has recently become popular in the mainstream. Games like Pokemon GO fulfill

this type of real time gameplay, but fall short on some fundamental safety precautions that Silent

Assassin meets. One of these being the particular danger of unwanted social interaction from

strangers. Silent Assassin resolves this problem, while maintaining fun game elements that

Pokemon GO has.

Functionality and Gameplay

Silent Assassin is played based on concentrated locations, where players are assigned one of two

types of roles: Assassins, or Explorers. Assassins are assigned a bounty, also known as their

objective, which requires them to locate a person, known as the victim, and assassinate (tag), that

victim. The game requires that the assassin can tag this person without close up physical contact.

In order to do this, the Assassin is required to have a radius around themselves when they play.

When they find their bounty, they do not need to be too close to the victim, they just need to be

within the target’s radius. This helps maintain the safety aspect of the game, where unwanted

physical contact is not desired. In addition, the victim is anonymous to the Assassin, and the

victim does not know he is being targeted. This provides additional safety against the assassin.

Another feature to the safety will be explained in detail later. When the Assassin has completed

his bounty, he himself will become an Explorer, and the victim will be immediately changed into

an Assassin. More details on this is explained later.

The Explorer is given a mission instead of a bounty. The missions is for the player to do a bit of

urban exploration. They are asked to visit popular points of interests, such as coffee shops,

theaters, etc. When they complete their mission, they are given a new one. As there is no

required interaction with other players for the Explorer, and there may or may not be any

Assassin targeting this Explorer, the Explorer is safe from unwanted contact, since no one knows

of their intentions. If the player is targeted by the Assassin, this Explorer will become an

Assassin. The original Assassin is turned into an Explorer and given their own mission, while the

Explorer is turned into an Assassin, and has his mission turned into a bounty. When they

complete their bounty, the same result takes effect as the previous Assassin.

Every day, or 24 hour cycle, the servers will stop all gameplay at midnight, and calculate scores

and certain information. Afterwards, the server will assign new Assassins and start a new game

cycle.

If the game encounters player count issues, the server will simulate some of the player base, and

give the real players the illusion that there are more players in the game. This results in not only

continuous good gameplay, but promotes further safety by giving occasional false victims to

Assassins. Assassins will not be able to determine and locate victims, by placing certain victims

in safe spaces, like crowded area, or homes.

Target Audience

The audience for this game is people from ages 16 to 65. These are the reasonable ages because

of reasonable maturity as well as having accessibility to transportation such as buses in cities.

This age group will also most likely have access to a mobile smartphone that has versions no

later than Android 4.4 and iOS 5.

Maintainability

The system will need to be maintained by maintenance staff that can respond to server side and

game app issues when they arise. Emergency maintenance should take no more than an hour,

while scheduled ones can take any extended amount of time, so long as players are notified no

earlier than three days.

Maps with Friends Group 11 - Jim Bendoraitis, Yordan Machin, Haskell Meninnga, Nikhil Shankar

Project Description:

Maps with Friends is a location based game which allows players to have head to head competitions with other players around the world or, of course, their friends. Maps with Friends integrates the Google Maps API to achieve the functionality of allowing players to determine where they and their opponents are on the map and allows players the ability to place pins on an actual map to guess their locations.

Matches start out with each player being dropped into a random location within the Maps with Friends’ smart location database. Once in their randomly chosen location each player must look around their surroundings use the Google Maps API’s Streetview and looking for clues in their environment as to where they are. Players are allowed three guesses to their location and the game checks the locations against a specified distance to determine which player has the correct or closest guess. Games can be played with staggered turns, one player can make a guess right now and then wait for the next player to make their guess much later on; The game does not need to be played one guess immediately after another.

As previously mentioned the game will select locations from its own database rather than choose random locations straight from Google Maps. This is done to prevent cases wherein the game might drop a player in a desert or other remote location without much hope of making a correct guess. These smart locations will be manually chosen by an Administrator whose job it will be to determine whether locations are intuitive enough to be guessed by the average player given enough poking around the Streetview for clues.

Maps with Friends, as the name suggests, is meant to be played with friends and as such will be programmed to have seamless integration with Facebook. This will allow first time players to quickly register and all players to easily access and communicate with their friends while in game. Requirements:

The user must be able to use their Facebook account to create their account and validate their login.

The game must be able to use Google Maps’ API to check the player’s guesses.

The administrator must be able to add locations for players to be dropped in.

Pins must fall within a 50 mile real world radius of the player’s guess is to be deemed a correct guess.

Players shall not be able to play a game if Google Maps API servers are down or experiencing issues

75% of users over the age of 60 must be able to play the game effectively after their first game.

Test Plans:

Testing on this application will be done by testing each individual class, and then eventually moving onto higher levels where they begin to interact with each other. This will be achieved via the use of JUnit tests to be done on individual functions throughout our code. Each unit test for JUnit is be default Pass/Fail, thus all tests will indicate passing for success and Failure for something going wrong or unexpected output. The unit testing will be counted as a failure if any on the the many tests are unsuccessful. Design:

GEO Treasure Hunter: Final Development Overview Group 12

Jose George, Jordan Tsvetanov, Valentin Kormanov, David Halverson Project Description

Geo Treasure hunter is developed with GPS (Global Position System) location based reality game that is similar to the popular game called “Pokemon GO” . The game will be implemented on multiple types of mobile devices such as Android smart phones and tablets as well as IOX devices. The main requirement is the device would need to have an integrated geographical position system. The other key features are that the device would need to have a camera and be able to be connected via Wi-Fi or 4G LTE to a network. The player can find treasure boxes at certain locations on google map, and will have to be at the exact geographical location in order to collect the “treasure”. When the treasure box is located, the player will have to point their camera at the computer generated object(treasure box) and there will be a popping up menu which the player can interact with. In order to collect the treasure box, the player will need certain tools, such as hammer, ax etc . The player of this game will be able to find treasure boxes, open them, obtain tools, upgrade tools, even team play can be done with other connected players in the game.

Requirements

Functional requirements:

The system must provide form for the user to enter personal data in order to create account.

The system must provide form for the user to enter personal data in order to login into their account.

The system must provide form of selection between single or multiple player mode. The system must provide location of treasure box and user on the map The system must provide user ability to execute camera that can point to treasure box

in order to display interface for opening treasure box. The system must provide user ability to choose specific tools to open treasure box. The system must provide form for user to obtain object from treasure box after open

the treasure box The system must provide user ability to chat with other players in multiplayer mode. The system must provide alarm if user tends to go dangerous area on the map The system must save persistent data of user after user exits the game. The system must provide user ability to report any problems occurred in the game.

Non-Functional requirements:

MySQL will be used for database storage.

The game must be available at least 20 hours of the day.

Persistent data from user should never be lost in the event in a shutdown of the Game.

Operations using the database should take a maximum of 10s.

The game interface should be easy to understand without any experiences of GEO

Treasure Hunter

Any problem reported from user should be fixed as soon as possible.

Design

Efficiency: The game application sdesign should consume few resources such as memory,

battery, etc while maintaining fast performance.

Understandability: In-game controls and game UI should be simple so that it is easy for the

users to understand and get started with game in less than 5 minutes.

Portability: The game should be cross platform compatible and playable on varous mobile

devices such as Android/IOS phones, tablets.

Maintainability/Extensibility: The game should have traceable requirements and

well-defined interfaces. It should fail safely. The game should also have an object-oriented

architecture that enables cutomizations for the subsequent level retricted versions of the game.

Security: The game should provide protect for user’ information and follow various secruity

guidelines and protocols to make users feel safe while playing the game.

Availability: Geo Treasure Hunter should be available for its players almost anytime. It

should be made availble on the app stores.

Reliability: Geo Treasure Hunter should be designed so that it has minimum bugs and errors

during gameplay. Hence, frequent testing should be done to ensure that a solid first version of

the game is released.

Test Plans

In order to test every requirements listed above, we have to test all the user actions in the game while playing. The game will be tested by game-tester who is testing the game and find

any faults in the game. Game-tester will test all the actions they can make in the game and detects fault if game is not working as intended. Whenever new features of the game are added, additional testing shall take place when they are implemented. GEO Treasure Hunter will be tested on Android and IOS platform.

GEODestiny – Project Description Summary

Group 13: David Cho, Eilbron Davood, Opin Patel, Glenn Turner Jr.

Project Description

GEODestiny is a MMORPG that allow players to experience different activities and

challenges in different locations around the world. With the use of geocaching, players are able

to travel through an accurate depiction of different areas of countries around the world to

complete different missions and goals. Each environment will be unique by their real life

characteristics (i.e. weather, land properties).

GEODestiny will allow users to create their own unique character using a list of creation

tools or select from preformatted characters. There are four character types to choose from:

Human, Robot, Monster, or Alien. Each character type will contain special attributes that will

distinguish it from other character types. Special attributes such as magic powers for aliens,

super strength for monsters, enhanced creativity and logical thinking for humans, and advanced

technical adaptation for robots will provide users different types of advantages over their

opponents. Using a checks and balance system, each character type will have some general

advantage over another character but will also be “checked” by other character types to ensure

equality of characters. The attributes that users will be able to enhance on their characters will

be the determining factor on how dominant his or her character will be in the game.

Along with creating a character, users will be able to select their character’s primary

location. This part is important as adapting to all environments is not guaranteed in

GEODestiny. By choosing a primary location, that will be your strength environment where you

will be at your optimal comfort and familiarity more so than other characters from other areas.

As geocaching is the backbone to this game, each location will accurately portray its proper

environmental details. For example, if your primary location is in a country regarded as a desert

region, your character will be more adaptable to desert environments vs colder climates or

wetlands. Since the game will include about twenty countries to interact in (with more being

available through downloadable content in the future), players should be able to get a unique

experience from each environment.

Requirements

Our functional requirements include local and remote data storage capabilities such as an

accessible memory drive (Hard Drive, memory card, servers, etc.), server consistency through

report generators, and data collection for unique user experiences. As GEODestiny will be a

demanding game, there will be a system check that will pull local and remote data reports from

the functional elements which will describe device storage and health compatibility, server

connection latency, as well as daily server maintenance data pings which will be able to

automatically detect server issues as well as connection issues such as DNS errors or malicious

attempts on the system.

Along with functional requirements there are several nonfunctional requirements that will

be implemented in this project. First, for data requirements we will utilize a remote database for

data storage. Our goal is to minimize downtime while maximizing uptime. We will have regular

data checks and maintenance once a week along with hotfixes for urgent scenarios. For

performance requirements, our main focus is consistency. We want to ensure that there is

consistency between the user and the server. Data that gets generated by the user will be stored

fast and get to its proper destination. Other requirements that will be implemented are

dependability, maintainability, and supportability. Error checking will be established for the

latency of the servers, but also in game bugs. System maintenance must be ready to resolve

issues related to server disconnect and data. In addition to error checking and maintenance,

technical support will be made available within adequate times throughout the week for players

experiencing prolonged gaming issues. Support includes manually syncing data to and from the

servers along with recording all complaints related to the usability of the game.

Testing

We plan to test every requirement listed above. An assumption to be made is production

like data will be made available in the system prior to the testing period. The test will execute

and verify test scripts and identify defects. Expectations are that more than 90% of the test cases

will pass. If at any point less than 90% tests pass, the testing phase will pause until new updates

to our application are made. At the end of each testing phase, a test closure report will be

generated and reviewed by the project manager. The test closure report will evaluate the test

cases and analyze defects.

Design

GEODestiny was designed for a client-server model. Users will perform some actions,

and the server will respond based on those actions. The approach to our design is to offer

reliability, manageable, and to maximize performance. The code will be done using object oriented programming and documentations will readily made and available for developers. The

user interface design should not be cluttered and be easy to use.

Project Issues

There are several issues concerning GEODestiny. The main issues highlighted in the

Project Issues section of the report is that there may be a hardware bottleneck to having millions

of users logged in at once. Another issue is that since this game will initially be a console based

game, migrating to the mobile side will be difficult. Related issues are high costs for new

equipment, create a new architecture from scratch, and reusability of code.

Group 14 Constantino Rodriguez, Jon Tran, Talha Taj, Nathan Tisdale-Dollah Professor John Bell CS 440 3 December 2016

Final Project Summary - Era-set Boulevard

To reiterate, Era-Set Boulevard is a game program centered on providing the user another approach in learning history from locations around them, as well as exploring new locations from far about. Taking multiple aspects from the popular game release in the summer of 2016 - Pokemon Go, Era-Set Boulevard hopes to achieve a similar effect which is to allow the user to physically explore the outdoors and ultimately go to new places. Era-set Boulevard however, differs in gameplay from Pokemon Go by not doing the same repetitive task to achieve the same or similar results such as PokeStops and its items, but allow the user to keep track and document where they have explored and in a way - keep a collection of the historical landmarks they’ve been in. Ultimately the user will be able to see their world map filled with marks of the places they’ve been and get to show other users how many more places they’ve explored.

Era-set Boulevard will be a mobile handheld device game which will mainly focus on portability as well as agility, using the mobile carrier’s built-in GPS system to get the user’s location in order to relay only the necessary game information to the user. The program will initially be built on the Android devices and later ported to the Apple mobile devices.

With the phone’s GPS, the world map will be displayed to the user with additional points of interests in place in the map. In order to encourage the user to explore the world around them, historical landmarks will appear and be marked on the map around the user’s current location. When the distance between the user and landmark comes close enough, the user is able to tap on the landmark and view its information such as the name, pictures, description, history, and quizzes. Doing so will permanently mark that landmark on the user’s tally and provide experience. Additionally as mentioned formerly, there will be pictures and quizzes. Both of these functions will be crowdsourced, whereas other users may submit their own picture of the location or quiz about the location. These two functions however are prone to abuse, so thus a voting system and reporting system will be put in place in order to facilitate such abuse. When a sufficient threshold of positive votes are tallied, then the picture or quiz will be submitted to that particular landmark, and provide the submitting user with more experience. The user may also take notes or take personal pictures on the location without sharing it and is kept private to the user exclusively. So thus, experience, or EXP will be an incentive to get more abilities to access the area around them as well as showcasing the user’s playtime of the game.

The design of Era-set Boulevard is aimed at being as user friendly as possible while allowing simple functionality to create enjoyment for the user. Through the creation of quizzes at various landmarks around the world, and being tested by other user quizzes, the user has an extremely large depth of information available to them. Many of the requirements that we have set in place revolve around keeping the user experience as efficient and pain free as possible, allowing the back end to merge seamlessly with the user interface.

On top of this, the back end is developed in such a fashion that all documentation and

code is maintainable and sustainable, allowing for not just the users to enjoy a wonderful experience, but also to allow current developers, as well as future developers to seamlessly integrate into the community that Era-set Boulevard aims to establish and promote. With clearly defined documentation, instructions, and a well built team, Era-set Boulevard aims to change the world of VR mobile applications, helping establish an unprecedented learning environment.

As a reminder, this program will have the user walk out into the outside environment and

thus the user shall take great notice and care about their surroundings. The product shall not be responsible of any injuries the users may happen to them but however take great notice in the safety of the user. So thus the program will be quick and easy to use, which will involve as minimal user engagement as necessary. Also, a system of reporting will be available on historical landmarks which will have an option for users to report about the location of the landmark. Such as landmarks in the middle of the sea or in the middle of the highway may be moved or removed completely. Additionally a warning to users will always happen occasionally to make sure users will be aware of their surroundings.

All testing for the application will be rigorous, with each stage of development being

finished, up to two weeks of testing will be implemented in order to allow a smooth transition between the cycles of Era-set Boulevards development. This also means that should prior development need to be altered in any fashion, whether this be additions or portions to be removed, the experience is seamless and swift.

As project issues are discovered, conferences will be scheduled in order to address these issues while the development is going on. Should any dire issues arise that could possibly threaten the entire development process, all team members will be diverted towards solving the issue with utmost haste.

The total life cycle of the development should be roughly two years with a 5 million dollar budget to cover all costs. This project does have a fair share set of risks in terms of upbring and maintenance, but with the current state of the market, it should be a significant success and bring the joy of historical learning to the world once again.

Project Description Summary Group 15 – Josue Alvarez, Grieldo Lulaj, Tyrone Harris

Introduction

Extreme Clash is a massively multiplayer online (MMO) game that combines the base-building combat strategy genre found in games like Clash of Clans while allowing the player to interact with the real world through augmented reality features like those found in Pokemon Go. Players will gather resources by exploring the real world using geolocation features provided by the app, which they can then use to construct their virtual base, train their armies, and research upgrades. Items found while walking in the real world will include materials like wood, gun powder, and in game currency like gold and silver. Some items will be guarded by enemies while the rest is easily obtainable. Requirements As a player in the game the basic use case list necessary for a player are as follows:

Login

Attack base

Defend base

Obtain resources

Join clan

Clan wars These are a necessity, anything else can be expanded on after this has been implemented first. Other things that are suggested to be implemented to increase user experience include adding a forum for Extreme Clash users as well as a suggestion area where players can provide their feedback on the game. Testing

The follow are features that should be tested:

Login

Beginning Tutorial

Resource collection and allocation

Unit production

Building Placement

Clan Leader/Member Pass/Fail Criteria

User Interface: Must be very responsive and perform user action within 1 second of performing said action 95% of the time.

Update: Client should successfully save and update changes from ingame

actions within 1 second 99% of the time

Network: Game clients should be connected to a server and allow user to log in and play 99% of the time.

Design The game takes on the UI design of Pokemon Go but has all the elements of Clash of Clans. A player will have an avatar in the center and a map of the surrounding area. There will be spots on the map within a 40 meter radius all around the user with that represent goblin bases you can attack, other players nearby or a store one can visit to purchase new items. Although a player might be on the move he/she can still access their base remotely. Similar to Clash of Clans, clans can be formed and joined. Clan wars are fought remotely.

Pandemic Summary Group 16 - Alex Pieczynski, Trevor Evans, Ledio Sinjari

Since Pokemon Go’s release in July 2016, the Location-Based mobile game market has seen an explosion of similar products. However, these games are all the same, and the market is in need of a fresh subject. Pandemic aims to meet that demand by providing gamers with a new reason to get out of their house and enjoy themselves. Pandemic is a game about a war on bioterrorism between two opposing factions: The BioHydra - whose goal is to wipe out humanity with their viruses - and the VacSect - whose goal is to stop the spread of viruses with their vaccines. Every new player gets to choose which side they would like to fight for, at which point they are given a seed virus/vaccine. That’s when the war begins. Each player is now able to travel around in the real world to achieve their goal: to infect or vaccinate as many other players as possible. Players infect or vaccinate others by getting within range of them or through the use of items. Defending players can resist infection or vaccination by using items themselves, or winning the BattleShip-style mini game that begins between the defender and an AI as soon as an enemy is within range. The BattleShip-style mini game gives player a chance to defend themselves against infection by correctly selecting the viral tiles on the board. When a member of the opposing faction creates a primordial strain or decides to modify an existing one, they are essentially rearranging and adding additional tile combinations onto their board. The player is given a limited number of tries to correctly guess and destroy the tiles, which varies depending on both the level of the player and the strength of the virus. Upon a successful defense, the VacSect member acquires the viral antibodies that he/she can then use to create a vaccine and cure other carriers of this strain as well as quarantine viral hotspots. Members of the same faction have the option of bypassing the minigame and becoming willing receptors of a virus or vaccine. That way they instantly gain the ability to reproduce it by becoming “active hosts”. One of the most interesting things about Pandemic is that there are a multitude of ways in which players can strategize to spread their influence as far as possible. This includes targeting high traffic areas, clever usage of items like BioBombs and VacBombs (which players can drop in any location, at which point the bomb will begin infecting enemies who pass by for a limited amount of time), and designing their virus or vaccine to be as effective as possible. Players can even do things like placing BioBombs in bodies of water, which has the potential of spreading to other users near that body of water thanks to Pandemic ’s sophisticated algorithms. Ultimately, Pandemic ’s goal is to become a global frenzy, where a player in say, Alaska, can design the perfect strain, drop it in a fish supply, let it spread to the entire distribution network, restaurants, grocery chains, and eventually the entire world. Such an ambitious goal will take significant resources to accomplish. Pandemic will operate on a budget of 4.20 million dollars which will include both startup and operating costs several years into the lifespan of the project. Pandemic will require renting server space and developing an aggressive advertisement and rollout strategy.

In order to reach as many people as possible, Pandemic will be rolled out across both the IOS and Android operating systems. Most of the major processing will be done on the Pandemic servers, and the devices will simply host the front end. The game will be developed simultaneously across both platforms. Operating systems from the two latests versions of each device will be supported. Beyond that, Pandemic will not guarantee compatibility with older or fringe devices. All devices must have a GPS built-in as well as a constant connection to the internet as location data must be constantly transmitted. Throughout its lifespan, Pandemic will be developed in a sort of perpetual agile methodology with scrum. Stories, sprints, and tasks will be planned around major releases, of which there will be an unspecified amount until the budget runs out or Zynga performs a hostile takeover. The Pandemic team hopes to constantly evolve and adapt the game based on the feedback of the community. This can lead to instability over a traditional waterfall approach but we believe that the current enthusiasm for augmented reality favors quick, experimental builds in the hands of players. Once Pandemic is available across the major devices, we will ensure a welcoming environment and approachable learning curve, while at the same time offering an intense and rewarding experience to dedicated gamers. We expect the majority of players to be considered casual gamers thus no penalty will be dealt for player inactivity. Pandemic will employ a level-based progression system to avoid overwhelming new players with its plethora of features. Upon leveling up, the player will gain access to a new skill and be presented a tutorial with its uses. After a number of uses of said skill and others, the player will gain enough experience points to level up once more and continue the cycle. Extremely high level players will become local faction leaders and have their hard work repaid with advanced abilities. Only the highest level elite Pandemic players will be able to fully create, name, and design viruses and vaccines. Pandemic will also foster its social component the fundamental purpose of augmented reality games should be to get people moving and interacting with otherwise strangers. Pandemic’s faction system will allow lower level players to gain in-game rewards and experience by interacting with higher level players, visiting as many new locations as possible, and traveling across the globe. The game will also display leaderboards that show users with the highest scores, the name of their faction, and a heat map of how far their influence has spread. Testing Pandemic will be rigorous. Developers will harness Test-driven development methodologies to develop unit tests and code simultaneously. Beyond unit testing, the Pandemic team will use integration and regression testing on every new build. Once a stable enough platform has been developed, builds will be rolled out to the community for an open beta test. These conditions will allow the developers to coordinate large scale functional and stress testing without the need to hire additional QAs.

Living Among the Dead Group 17: Carlos Beltran, Ioannis Bolaris, Jonathan Galvan

Living Among the Dead will be a user-friendly game application that enables individuals to collect items and explore a variety of places wherever they go while facing a common threat. By using the phone’s GPS coordinate, users will be able to find hidden objects and face off against hordes of zombies. Project Description Living Among the Dead is a location-based augmented reality game for IOS and Android devices that will give users countless hours of gameplay and new content add- ons every month. This product is targeted to every age group that is willing to embark on various exciting adventures. Living Among the Dead will provide a login system for users with existing profile accounts. Profiles within Living Among the Dead will contain their name, biography, and a cool fact about them. Users will be able to interact with other existing players to take down hordes of zombies through the use of a party system. Each player will start off at level one and continue to level up their player through playing the game. In particular, collecting certain items and defeating zombie will grant them experience. In addition, every one a week there will be a special event in which a zombie boss will spawn in a certain area. To engage in battle with the boss, players will have to unite together and take down the beast. Requirements Notable Functional Requirements:

The system must provide the user the ability to create an account. The system must have location services permitted. Permission is requested

when the game first launches. The system must present the user a map of rendered markers that represent

points of interest. The system must display an inventory screen where the user can see all

collected items. The system must allow the user to interact with items. The system should be able to display the user’s Facebook friends that also have

the game installed. Design

The following design goals will be directed to Living Among the Dead: Living Among the Dead will contain dedicated servers for users. The servers will be able to handle erroneous conditions and notify users of the current problem. The game client will also be easy to understand and navigate for new and upcoming users. The code should be modifiable, easy to understand, and simple to migrate across platforms. Lastly, Living Among the Dead will contain three subsystems: Account Management, Store Management, and Gameplay Management. Test Plans The testing will be automated so that it can be conducted frequently without using valuable human resources. For Android the testing cases should run on devices with small, medium and large screen sizes. The devices that will be tested shall cover the range of supported Android versions. The testing should also cover all iPhone models that can run the supported iOS versions.During the development phase the manager will plan the next sprint taking into account the testing results. The errors that affect all the tested devices should be a priority. Once these errors are solved the development team can focus on solving device specific errors which affect certain OS versions and screen sizes.The development team will develop an automated testing software for ensuring that all the functional requirements as described in the document are met. Project Issues An open issue associated with the product is the issue of determining appropriate software tools to secure and protect the project from malicious attacks such as a DDOS attack. Project Planning The project will shall ideally be divided into four phases of development:

In the first phase, the UI will not contain functionalities that enable it to communicate with the back end server. Only the existence of the UI components need to appear such as buttons. There should be only one instance of a UI structure for each unique page.

The second phase will consist of the development of the server side. This will involve constructing all the tables that will correspond to data types present in the product.

The third phase will consist of implementing the functionalities that were not constructed within the first phase of the development process. The functionalities will enable the client to perform operations that will communicate with the server and the Microsoft SQL database.

The finalized Microsoft SQL database, in which the product will have access to, will be prepared to be used in the final phase of the development process.

Private Eye Adventure Mystery Game Emphasizing Geo Tracking

Group 18: Matthew McCormack, Quan Zheng, James Lave

Private Eye is an adventure mystery game based on “mission” like objective event sequences that will lead the player to various physical geographical regions in order to complete mission objectives. The premise of game is that you are a private eye seeking to expose corruption and you accept missions which lead you on a sequence of events that take you to real world places where you gain clues and can gather evidence to help solve the mystery (specifically; taking photographs as evidence utilizing augmented reality capabilities). This first summary describes the general sequence of events encapsulated by a mission event, which is the aforementioned core of a game instance. At the outset of the game you will be prompted with a mission selection screen. This is where you can first choose between various missions to accept. The menu will allow you to select a mission from a list to view a more detailed mission dossier on the selected mission. From here you can either accept the mission or return to the previous menu to view and select other missions. Once you have accepted a mission the true game play begins. A mission, conceptually, consists of real world locations where in­game objectives will be set. A mission begins with one destination, once the user arrives at that location the game will prompt them for some sort of interaction in order to complete the objective at that real world location. These objectives can consist of many things, a few that we know will be included are;

Deciphering a text document or riddle to determine the location of the next mission objective

Solving a more mechanical type of puzzle in order to reveal the destination of the next mission objective

Taking “evidence photos” with an augmented reality feature that will allow the user to take photos of real world locations with in­game elements superimposed onto them

Once a player has completed all the mission objectives by visiting each location and completing each task they will be able to submit their report and complete the mission. From here the game will return to the main menu where they can select another mission to embark on. The mission structure will account for the entirety of actual “game play” and the format is very conducive to regular content updates where new missions could be added to the game on a regular basis, giving users more incentive to continue playing the game. This, combined with the use of two very popular and under­developed game play features; geo­tracking and augmented reality, will make for an interesting, unique, and engaging mobile gaming experience that we believe people will want to explore.