The complete srs documentation of our developed game

1. INTRODUCTION:

1.1 PURPOSE:

This Software Requirements Specification (SRS) document is intended to give a complete overview of Android game project Amazing Boxy (working title), including the game mechanics, user interface and story therein. The SRS document details all features upon which Amazing boxy have currently decided with reference to the manner and importance of their implementation.

1.2 DOCUMENT CONVENTIONS:

As the development team is responsible for the SRS document, no ambiguity arises from its usage. There is a clear distinction, however, between the use of the words “player” and “character.” The “player” is the human being interacting with the game in the real world, while the “character” is the in-game player avatar being manipulated. This document is too printed on A4paper in Times New Roman font. Normal text is size 12 black, while section headings are size 24 bolded white against green backgrounds. Subheadings are bolded size 14 black upon green backgrounds, and third subheadings are bolded size 13 black indented with green hooks.

1.3 INTENDED AUDIENCE AND READING SUGGESTIONS:

The SRS document also gives testers and project managers a way to ensure the game’s adherence to original vision. Although the document may be read from front to back for a complete understanding of the project, it was written in sections and hence can be read as such. For an overview of the document and the project itself, see Overall Description (Section 2). For a detailed description of the game play elements and their interaction with the character, see System Features (Section 3). Readers interested in the game-play interface and navigation between different front-end menus should see External Interface Requirements (Section 4). Technical standards to which the team will hold the project are laid out in Other Nonfunctional Requirements (Section 5). The development schedule, meanwhile, will be maintained in the Key Milestones (Section 6).

1 | P a g e

1.4 PROJECT GOAL:

Amazing Boxy is a simple Android Phone game that calls upon you to bounce a brick up through a maze of portals while avoiding obstacles that are placed along the way.Amazing Boxy also requires a little patience and timing; otherwise the game could drive you crazy. Available for low-memory devices, Amazing Boxy is a fun game to have in your library for those occasions you need a little help passing the time.Amazing Boxy's main menu is minimal by design with two gaming modes available and an option to rate the game in the Google Play Store. The two gaming modes are Easy and hard. The key difference in these two modes is the size of the portal you have to bounce your brick through.Controlling your brick (which looks more like a black diamond) is done by tapping the left or right side of the screen. Tapping the left side bounces the brick upwards to the left and tapping the right will send the brick upwards to the right. Taping these taps just right and your brick will move upwards in a somewhat straight direction.The maze you navigate through will have open portals in the solid lines/walls that you must pass your brick through. You will also have blocks placed in between the walls that you must avoid. Contact with any of the obstacles of walls will end the game.

2. OVERALL DESCRIPTION:

2.1 PRODUCT PERSPECTIVE:

While the game itself is not a continuation of any predecessor, its implementation is made possible through the game development tool Box2d and its ability to compile and build projects for use on the Android mobile device. As part of its inclusion in the Android framework it is guaranteed security against access from other applications. Since smartphones these days are full of tons of games therefore, one of our goal while designing the game is to be able to let the user understand the gameplay at the first look no matter how often and how least he opens the game, we are achieving this by showing the control guide screen every time at the beginning of the game, hence engaging the user every time with the game.We have tried to avoid creating the story primarily because the users (especially when it comes to small smartphone games) find it really annoying instead our game model focuses on gaining the score by achieving the difficulty level. The game would allow the users to pause the game by stopping the frames being executed, so it wouldn’t create aggressive feedback like recently hyped game flappy bird did.

2 | P a g e

2.2 PRODUCT FEATURES:

The following is a summary of the major features implemented in the game. They are separated into categories based on those that are necessary for the game to function.

2.2.1 FUNCTIONAL FEATURES:

GRAVITY ROTATION:

The central mechanic of our game, allowing the player to change their perspective and orientation through the use of a touch scroll bar.

JUMPING:

Also a necessary movement mechanic, allowing sudden movements upward from solid ground.

DEATH ZONES:

Areas that trigger the restart of the level, be they encompassing stage boundaries or spike-like traps.

TITLE SCREEN:

The first viewable screen upon starting up the application, containing buttons for play game, options.

PAUSE MENU:

In game option to halt game-play. This also allows access to the fields displayed on the title screen.

2.3 USER CLASSES AND CHARACTERISTICS:

Our control scheme is designed to be intuitive and our game-play innovative and unfamiliar. Therefore, experience with games will not be a major factor in determining who is able to play: players of any age or skill level should be able to pick it up. However, as with any game with a large enough fan base, there will be a natural divide between casual and hardcore players. These two classes will naturally differentiate themselves through the use of the game-play mechanics and the structure of the levels. The abilities and characteristics distinguishing hardcore players will include:

● Drifting: The ability to spin the rapidly accelerating gravity vector with proper timing in order to reach certain points without landing on intermediary walls.

3 | P a g e

● Foresight: The ability to plan out the paths of multiple falling objects to get each of them to their optimal positions.

● Speed: The ability to complete levels quickly.

● Intuition: The ability to make successful guesses about the existence of off-screen objects.

3. PROJECT CONTEXT:

This includes Mile-stones, Development Strategy, Risk Analysis and Tools, and Version Control Procedures.

3.1 MILESTONES:

MILESTONE START FINISHPre study 10 0ct, 2014 15 Oct, 2014Design 17 Oct, 2014 27 Oct, 2014Implementation 28 Oct, 2014 3 Nov, 2014Content and demonstration preparation

5 Nov, 2014 7 Nov, 2014

Demonstration 8 Nov, 2014 10 Nov, 2014Evaluation 11 Nov, 2014 17 Nov, 2014Platform design 18 Nov, 2014 21 Nov, 2014Finalization 23 Nov, 2014 10 Dec, 2014

3.1.1 PRESTUDY:

This phase consists of gaining an insight into the different subjects that concern this project. This preliminary study will also include creating the research part of the written report.

3.1.2 DESIGN:

This phase consists of gathering requirements and creating a software architecture for the game. The phase will be revisited several times during the implementation phase.

3.1.3 IMPLEMENTATION:

This phase consists of the iterative process of creating the game. The overall architecture should be implemented, and then the actual code should be written, along with tests and a thorough documentation. The implementation phase is divided into three sprints.

4 | P a g e

MILESTONE START FINISHSprint 1 10 Oct, 2014 20 Oct, 2014Sprint 2 22 Oct, 2014 5 Nov, 2014Sprint 3 7 Nov, 2014 10 Dec, 2014

3.1.4 CONTENT AND DEMONSTRATION PREPARATION:

This phase consists of preparing for the demonstration on 6th of December. The content of the game must also be prepared. This includes the creation and finalizing of tasks.

3.1.5 DEMONSTRATION:

This is a one day test consisting of letting several groups compete against each other. The experiences and results from this demonstration will form the basis for the evaluation.

3.1.6 EVALUATION:

This phase consists of evaluating the experiences and results from the demonstration, and will form part of the basis for the platform design.

3.1.7 PLATFORM DESIGN:

This phase consists of designing the platform, based on the evaluation of the results and experiences from our game, as well as any conclusions made on the background of our research questions.

3.1.8 FINALIZATION:

This phase consists of finalizing the thesis document.

3.2 DEVELOPMENT STRATEGY:

In order to implement the prototype, we are going to use a combination of the waterfall and the iterative software development strategy. We will make an overall design of the application using a waterfall approach, which means we will have a good idea about what the system should look like; and what we are going to implement. The implementation will be based on an iterative software development strategy. This means that the implementation process will be divided into smaller segments of design, implementation, and testing; thus allowing for a better planning of the time used on implementation.

5 | P a g e

3.3 RISK ANALYSIS:

This section is about the risks in this project. They are separated into two parts, general risks and demonstration specific risks.

3.3.1 GENERAL RISKS:

INTERNAL CONFLICTS:

Conflicts between team members can occur, and is even more likely since we will be working closely together over a long period of time. It is therefore important to communicate openly, and handle issues internally before they become too much to handle. Should this be insufficient one could always seek help from the supervisors, or in the worst case scenario - dissolve the group.

ANDROID DIFFICULTY:

Development with Android is something none of us are familiar with. If we spend too much time getting an understanding of the framework, development will take more time than expected and other parts of the project will suffer. We can avoid this by planning accordingly and allocate sufficient time to understand Android, as well as start development early.

BAD PROTOTYPE DESIGN:

The survey and evaluation tells us that the concept for the prototype is bad. This is a risk that can make us unable to design a satisfactory platform, which would have a huge impact on the project. One way to reduce the probability of this occurring is to interview teachers to verify the learning aspect of the concept. The impact can be reduced by making a survey that will give us useful information even if the design of the prototype is bad.

3.3.2 DEMONSTRATION SPECIFIC RISKS:

BATTERY:

The low battery time for smartphones is a well-known issue, especially when GPS is enabled or the touch screen is used extensively. This can disrupt the demonstration of our prototype, should any of the phones run out of battery. We need to program with battery usage in mind, i.e. use GPS as little as possible.

UNCLEAR TASKS:

6 | P a g e

When creating task descriptions, one runs the risk of making tasks that are unclear. This can lead to frustration from participant and they may get stuck. This can be avoided by scrutinizing tasks and making sure that they are clear and have no ambiguity. Should that not work, the participants could always contact a demonstration supervisor and receive clarification.

PARTICIPANTS UNFAMILIAR WITH ANDROID:

Demonstration participants may be unfamiliar with using an Android device. This can lead to frustration and problems during the demonstration. The problem can be avoided by giving them a brief introduction before the demonstration starts, and prepare the phones ahead of time for ease of use.

3.4 TOOLS:

Programming language: processing Programming IDE: processing development environment (PDE) Diagram editor: Microsoft Visio 2010 Report writing: open office

3.5 VERSION CONTROL PROCEDURES:The following guidelines should be followed when using Git:

1. Perform updates before committing any changes.2. Only commit working code.3. Several people should not work in the same file at once.

4. SYSTEM FEATURES:

4.1 GRAVITY ROTATION:

4.1.1 DESCRIPTION AND PRIORITY:

This mechanic gives the player full control over the orientation of the level in relationship to the character. Gravity rotation replaces primary movement controls (left and right) by allowing the player to incline surfaces for sliding and “falling” at different speeds and directions.

4.1.2 STIMULUS/ RESPONSE SEQUENCES:

7 | P a g e

Step 1: The player slides their finger up/down the scroll bar on the right or left side of the screen.Step 2: The level rotates counter clock wise/clockwise around the character in real time at a speed proportional to the physical distance scrolled by the player.

4.1.3 FUNCTIONAL REQUIREMENTS:

REQ-1: The scroll bar must constantly update the current position of the player’s finger to allow for real-time gravity repositioning.REQ-2: The scroll bar’s effect on rotation must be scaled so that the player will be able to manipulate the level with precision.REQ-3: Different surface inclinations must affect the player’s velocity vector.REQ-4: Levels should be designed to take advantage of the implications of this game mechanic.

4.2 JUMPING:

4.2.1: DESCRIPTION AND PRIORITY:

Being the secondary method of player input, jumping maintains the second-highest game-play priority. This mechanic allows the player to navigate gaps without having to be adroit at gravity rotation.

4.2.2: STIMULUS/ RESPONSE SEQUENCES:

Step 1: The player presses the jump button located on the side of the screen opposite the gravity scroll bar. Step 2: The character jumps with a constant force.

4.2.3: FUNCTIONAL REQUIREMENTS:

REQ-1: Because the touch-screen is not pressure-sensitive, the jump force must be standardized.REQ-2: Levels should be adapted to this standard jump.REQ-3: Jumping should take into account the current vertical and horizontal velocities as well as the surface inclination.REQ-4: Jump force should be large enough that the mechanic is not made useless but not so large that gravity rotation can easily replace the effect.

4.3 DEATH ZONES:

8 | P a g e

4.3.1 DESCRIPTIONS AND PRIORITY:

Death zones are the opposite of level completion zones in that when touched, they send the character back to the starting point of the level. Some death zones take on the form of environmental obstacles; others are black shapes which represents holes in the protagonist’s memory. Death zones are a necessary replacement for bottomless pits, which prove impossible to implement given the changeling nature of gravity. These zones increase the game’s difficulty and incentivize good performance via negative reinforcement. They should be prioritized in level design, as they bring the game-play from “playable” to “enjoyable.”


Step 1: The character comes into contact with a death zone.Step 2: The character is immediately returned to the beginning of the level.


REQ-1: No death zone should be placed so as to make its respective level impossible to complete.

4.4 TITLE SCREEN:


The title screen is the screen the player will see every time upon playing the game. Through this interface, the player can choose to start a new game, play from saved data, or adjust the options. Since the title screen is the “hub” for all activities in the project, it must be included.


Step 1: The player launches the game from their portable device.Step 2: The start screen loads and appears, prompting the player with three buttons: “Play Game”, “Options”, and “Exit”.Step 3: The player presses one of the buttons, triggering its respective function.


9 | P a g e

REQ-1: The title screen must load and appear every time the game is launched.REQ-2: If the player quits the game during any stage of a level, they must be returned to the title screen.REQ-3: If the player presses the exit button, the game will end and return the player to the phone’s regular interface.REQ-4: If the player completes the game, the game will end and return the player to the title screen.

4.5 PAUSE MENU:


The player should be able to pause anytime during game-play, and this screen fulfills that requirement. The pause menu also allows the player to navigate between game-play and the level selection and title screens. The portable nature of the console renders player convenience paramount, so this feature must be included.


Step 1: The player presses the pause button on the game-play interface.Step 2: The level pauses, drawing up the pause menu which prompts the player with three options: “Resume Game” and “Exit Game.”Step 3: The player presses one of the buttons, triggering its respective function.


REQ-1: The “Exit Game” option must return the player to the main screen of the game or phone.REQ-2: The “Resume Game” option must continue the game without any change to the character’s vector or the state of the level from the moment of the pause action.

5. EXTERNAL INTERFACE REQUIREMENTS:

5.1 HARWARE INTERFACES:

Amazing Boxy is a mobile gaming application designed specifically for the Android platform and is functional on both mobile smart phones and tablets. Gaming application data is stored locally on the Android device using a SQLite relational database.Amazing Boxy has been developed for Android Version 2.2 and all subsequent releases. The Android platform is graphically adaptable with a 2 dimensional

10 | P a g e

graphics library and a 3 dimensional graphics library based on OpenGL ES 2.0 specifications as well as hardware orientation, scaling, pixel format conversion and accelerated 3D graphics.

5.2 SOFTWARE INTERFACES:

Amazing Boxy is to be developed under the Android operating system using a series of game development tools.

Android Software Development Kit (Android SDK):Software development kit for applications on the Android platform.

Box2D: Primary game development library using Java Used in conjunction with the Android SDK and Processing Box2D Processing: A helper class that communicates with jBox2D and

Processing. PDE: Processing Development Environment

6. OTHER NON-FUNCTIONAL REQUIREMENTS:

6.1 PERFORMANCE REQUIREMENTS:

Based on the capabilities of current phones and the Android system, performance should not be an issue. However, phones with weaker hardware may incur some difficulties and potentially run slower. The game design will be tailored in order to give an enjoyable experience on all Android phones, regardless of hardware. The functionality of the game will be simplistic enough, but not trivial, and the graphics will not be overly detailed so the system does not become slowed down.

6.2 SAFETY REQUIREMENTS:

Amazing Boxy will not affect or damage any of the other applications installed on the player’s phone. The game will also not cause any overheating of the player’s phone; therefore, the phone's internal components will not be damaged. Amazing Boxy should not be played when the player’s attention is divided among multiple tasks to prevent potential harm to the player.

6.3 SECURITY REQUIREMENTS:

Amazing Boxy will not ask for any personal information from the player and will thus be unable to compromise such information. There is no player authentication required to play Amazing Boxy. The player simply has to download the application in order to start playing Amazing Boxy. That being said, anyone who has access to the player’s phone will have the ability to play Amazing Boxy. If any unauthorized player acquires the original player’s phone, that unauthorized player will be able to play Amazing Boxy. It is the responsibility of the Player to make sure that no unauthorized player/ person will have access to his or her phone.

11 | P a g e

6.4 SOFTWARE QUALITY ATTRIBUTES:

To ensure reliability and correctness, Amazing Boxy will respond to the player’s commands in a timely manner. When the player makes the box jump the gravity and velocity components would response immediately, the player should see the effects of this command within milliseconds not 10 seconds after the effect. For adaptability and flexibility, Amazing Boxy will automatically save the player’s progress after every level completion. That way, in the event that the player’s phone runs out of battery during game-play, the player can resume game-play at a reasonable starting point.In terms of usability, the graphical user interface will be very intuitive for the player to use. The beginning levels of Amazing Boxy will also slowly introduce each of the unique commands available to the player as well as any other game mechanics the player may need to know to complete the level. In more complicated and elaborate levels, these introductions and hints will not be available because the player will have already been introduced to all the tools needed to complete the level. This method will ensure that the player gradually learns all the game mechanics and also enjoys a challenging game-play experience. Our game focuses on both ease of use and ease of learning while not leaning towards one or the other. Amazing Boxy should be a game that any player can pick up and play instantly without much down time in figuring out the controls. The controls will be easy and intuitive to use and the player will not be bombarded by having to use all the controls at once in the beginning levels. The game play will ease the player into learning and using each of the commands by gradually introducing each command as the player progresses through the game and completes each level. By the end of any given level, the player should be familiar with and fully able to use the command introduced in that level and all the commands introduced in previous levels.

7. SOFTWARE ARCHITECTURE:

7.1 ARCHITECTURE CHOICES:

7.1.1 SERVER SOLUTION:

Initially we considered client-server architecture for the prototype where content was located at the server and sent to clients on request. This idea was ultimately scrapped in favor of an architecture that does not include any server, meaning the whole system is on the user’s device. There are several reasons for this. Most important of these, the purpose of the prototype is to test the game concept. This needs to be done relatively fast so that we have the necessary time to evaluate the prototype and create a platform design based on the results. Implementing a server would unnecessarily complicate the design process and require more time spent in implementation on an architecture that does not really yield any substantial benefits at this stage in the project.

12 | P a g e

7.1.2 STORAGE SOLUTION:

We evaluated two possible solutions for storage of game data. The alternatives were using a file or using an integrated database. We decided on using a database, because the support for databases in Android is very good, with simple interfaces for retrieving and storing data. Android offers an easy way to create, edit and manage a SQLiteDatabase with the class SQLiteDatabase. Also, each database created and its content is visible only to its parent application. A database combined with frequent saving of game data will ensure that data will not be lost even if the application were to terminate unexpectedly.

8. IMPLEMENTATION PHASE:

8.1 REQUIREMENTS:

The requirements for this sprint are:

ID DESCRIPTION PRIORITYAB – 01 The current route shall be retrieved from the

database upon game start.High

AB – 02 The current task shall be retrieved from the database upon game start.

High

AB – 03 The game state shall be updated in the database during game play.

High

AB – 04 The application shall display a welcome screen on startup.

Low

AB - 05 The welcome screen shall contain a button for starting the next task.

Low

8.2 DESIGN:

8.2.1 GAME START:

When the game is installed, the database is created and the game content is filled in. Upon game start the game retrieves the current game state, which is the current task as well as the route. If there is no current game state, a new route is retrieved from the database, and the current task is set to the first task in the route.

8.2.2 TASK FLOW:

13 | P a g e

The first user interface screen the user encounter a welcome screen containing a welcome text and a button for getting to the next task. When the user pushes the next task button, the next task in the route is retrieved from the database. Upon completing the task, the application automatically retrieves the next task. If the user exits the game, the user will again encounter the welcome screen, and the route and task is retrieved from the database. If the user pushes the next task button, the application will load the task that the user was on when he or she killed the application.

8.2.3 COHESIVENESS:High cohesion leads to the reliability, robustness and reusability. Since it is a game project therefore each module, each class and each file in the entire project is somehow dependent upon one another and can’t be completed independently. In order to detect the collision of the main character with the boundaries or walls and any other obstacles we would have to access the location of both the actual character and any of the colliding objects.

Similarly if we have to take any food or coins we have to detect the collision and trigger the respective behavior in the game.

In almost every game the code is most of the time cohesive because each object in the game has to obtain the information or fields of the other objects in order to make the game physics work therefore the cohesion of this project is high in comparison to the usual software projects.

Reducing the cohesiveness might lead the game to look like a fake physics and not a clean work, hence high cohesiveness in this project can be said as mandatory.

8.3 IMPLEMENTATION:

8.3.1 GAME START:

The game starts in the class Main. First off the database creation is forced by creating a new DbAdapter then using its methods open() and close(). The database is created only at first installation of the game. When the user starts the game, the game state is loaded by calling the the loadGameState() method. This method uses the DbAdapter methods getGameStateRoute() and getGameStateTaskId() to retrieve the current game state. If there is no current game state, which means that routeId and currentTaskId are 0, then a new game state is created. The new game state contains a new route and first task id of the route. If a new game state is created, the game state is stored in the database using DbAdapter.updateGameState(). Finally the welcome screen is created. The welcome screen is very simple and contains a LinearLayout, TextView and a Button.

14 | P a g e

8.3.2 TASK FLOW:

When the user pushes the button on the welcome screen, the next task is loaded through the Main.loadTask() method. The loadTask()method creates a new Intent with the class TaskActivity and currentTaskId parameters. It then starts the activity. When TaskActivity is loaded, TaskActivity first calls the the method fetchTask(). The fetchTask() method retrieves the currentTaskId from the Intent and then calls the method DbAdapter.getTask() to retrieve the task from the database. TaskActivity then uses fetchView() to retrieve the UI according to the task type of the current task. It then creates the view by calling TaskUI.createView().

8.4 TESTING:

8.4.1 TASK FLOW:

Testing of the task flow was done incrementally. The overall task flow was created and tested first. This includes Main.loadTask(), TaskActivity.fetchTask(), and TaskActivity.fetchView().In order to test these methods we added a dummy task and a view.Main.loadTask() called startActivityForResult() with TaskActivity as a parameter to start the activity. TaskActivity then used fetchTask() to create the dummy task. The method fetchView() was then called to load the view. When the user completed the dummy Task, finish() was called on TaskActivityto finish the activity. The application then returned to Main, and Main called loadTask() and the cycle was complete. We had no issues with testing the overall task flow.

8.5 EVALUATION:

We encountered a few problems during the implementation of this sprint, due to our inexperience with and our limited understanding of the Android framework. For instance, we struggled a while with passing objects between Activities, and in the end decided to implement a database to bypass the problem. Most of the other problems originated in the usage of a database, like correctly loading game state variables, objects, etc.

APPENDIX A: USE CASE MODELLING

15 | P a g e

16 | P a g e

PLAY GAME

PAUSE GAME

RESUME GAME

<<extends>>

APPENDIX B: FUNCTIONAL REQUIREMENTS

17 | P a g e

USE CASE: Play GameID: UC 1

18 | P a g e

ACTOR:Gamer/PlayerPre-condition:The application should have launched correctly

Flow Of Events:1) On the title screen the play game button populates on the

screen.2) Upon pressing the button the application should take the user

to the gameplay screen.3) The tutorial screen populates, which should disappear on a

single tap.

Secondary Scenario: User exits the application by pressing the back or home

button of the Android device.Post-condition:

The game starts.

USE CASE: Pause GameID: UC 2ACTOR:Gamer/PlayerPre-condition:The game should have started

Flow Of Events:1) When the game starts the pause button populates on the screen.2) Upon pressing the button the application should take pause the

drawing of the graphics.3) The screen fades and populates the exit game and resume game

buttons



The gameplay and drawing should be paused, FPS should be decreased to 1 or 0.

USE CASE: Resume GameID: UC 3

19 | P a g e

ACTOR:Gamer/PlayerPre-condition:The game should have been paused

Flow Of Events:1) When the paused button is pressed the resume button should

populate on the screen.2) Upon pressing the resume button the application should

resume and start drawing the graphics again.3) The screen fades into the normal gameplay.



The gameplay and drawing should be resumed, FPS should be set back to the 60fps.

USE CASE: Save GameID: UC 4ACTOR:Gamer/PlayerPre-condition:The game should have be played.

Flow Of Events:1) When the paused button is pressed the save button should

populate on the screen.2) Upon pressing the save button the application should save the

progress in the database.3) The application takes the user back to the main/title screen.



The information at that particular frame should be saved in the database.

USE CASE: Exit GameID: UC 5

20 | P a g e

ACTOR:Gamer/PlayerPre-condition:The application should be at the title screen or the game should have been paused.

Flow Of Events:1) When the pause button is pressed the exit button appears, or

when user launches the application.2) Upon pressing the exit button the application should kill all the

objects and the bodies and it should end the gameplay3) The application closes.



The game process is killed.

USE CASE: Select ModeID: UC 6ACTOR:Gamer/PlayerPre-condition:The application should have launched

Flow Of Events:1) The button is populated on the main screen of the application.2) Upon pressing the select mode button the application should

take the user to the mode selection area3) The different modes should be populated.



The user gets into the mode selection area

USE CASE: EasyID: UC 7

21 | P a g e

ACTOR:Gamer/PlayerPre-condition:The mode selection event should have triggered

Flow Of Events:1) The game mechanics and physics becomes easy2) The user is brought back to the main screen



The gameplay becomes easy

USE CASE: DifficultID: UC 8ACTOR:Gamer/PlayerPre-condition:The mode selection event should have triggered

Flow Of Events:1) The game mechanics and physics becomes difficult2) The user is brought back to the main screen



The gameplay becomes difficult.

USE CASE: Change Background ColorID: UC 9

22 | P a g e

ACTOR:Gamer/PlayerPre-condition:The application should have launched

Flow Of Events:1) The button is populated on the main screen of the application.2) Upon pressing the change background color mode button the

background color of the gameplay would change.



The background color has been changed during the gameplay

USE CASE: BlackID: UC 10ACTOR:Gamer/PlayerPre-condition:The application should be in the change background color mode

Flow Of Events:1) The button should be populated on the screen brought by

change background color use case.2) Upon pressing the black color mode button the background

color of the gameplay would change to the black.



The background color has been changed to the black during the gameplay

USE CASE: White

23 | P a g e

ID: UC 11ACTOR:Gamer/PlayerPre-condition:The application should be in the change background color mode

Flow Of Events:1) The button should be populated on the screen brought by

change background color use case.2) Upon pressing the black color mode button the background

color of the gameplay would change to the white.



The background color has been changed to the white during the gameplay

USE CASE: Change Character ShapeID: UC 12ACTOR:Gamer/PlayerPre-condition:The application should be in the main screen.

Flow Of Events:1) The button should be populated on the start of the application.2) Upon pressing the change character shape button, the user is

brought to the screen where he can choose different shapes of the game character.



The user ends up in the shape selection menu

24 | P a g e

USE CASE: CircleID: UC 13ACTOR:Gamer/PlayerPre-condition:The application should be in the Change Character Shape mode.

Flow Of Events:1) The button representing the circle shape is populated in the

change background shape color menu.2) Upon pressing the circle shape button, the game character’s

shape is changed to the circle in the gameplay.



The shape of the character is now a circle.

USE CASE: SquareID: UC 14ACTOR:Gamer/PlayerPre-condition:The application should be in the Change Character Shape mode.

Flow Of Events:1) The button representing the square shape is populated in the

change background shape color menu.2) Upon pressing the square shape button, the game character’s

shape is changed to the square in the gameplay.



The shape of the character is now a square.

25 | P a g e

USE CASE: DiamondID: UC 15ACTOR:Gamer/PlayerPre-condition:The application should be in the Change Character Shape mode.

Flow Of Events:1) The button representing the diamond shape is populated in the

change background shape color menu.2) Upon pressing the diamond shape button, the game character’s

shape is changed to the diamond shaped in the gameplay.



The shape of the character is now a diamond shaped.

USE CASE: Check ScoreID: UC 16ACTOR:Gamer/PlayerPre-condition:The application should be in the main screen.

Flow Of Events:1) Upon pressing, the check score buttons leads to the list of the

highest scores or hall of fame.2) Upon pressing back or swiping, the user is brought back to the

main screen



The user saw the score list

26 | P a g e

APPENDIX C: DATA FLOW MODEL DIAGRAMS

27 | P a g e