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 A4
paper 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).

|P a g e 1
 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.

|P a g e 2
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.

|P a g e 3
 ● 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 FINISH

Pre study 10 0ct, 2014 15 Oct, 2014
Design 17 Oct, 2014 27 Oct, 2014
Implementation 28 Oct, 2014 3 Nov, 2014
Content and demonstration 5 Nov, 2014 7 Nov, 2014
preparation
Demonstration 8 Nov, 2014 10 Nov, 2014
Evaluation 11 Nov, 2014 17 Nov, 2014
Platform design 18 Nov, 2014 21 Nov, 2014
Finalization 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.

|P a g e 4
 MILESTONE START FINISH
Sprint 1 10 Oct, 2014 20 Oct, 2014
Sprint 2 22 Oct, 2014 5 Nov, 2014
Sprint 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.

|P a g e 5
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.

|P a g e 6
  UNCLEAR TASKS:
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.

|P a g e 7
 4.1.2 STIMULUS/ RESPONSE SEQUENCES:

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.

|P a g e 8
4.3 DEATH ZONES:

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.”

4.3.2 STIMULUS/ RESPONSE SEQUENCES:

Step 1: The character comes into contact with a death zone.

Step 2: The character is immediately returned to the beginning of the
level.

4.3.3 FUNCTIONAL REQUIREMENTS:

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

impossible to complete.

4.4 TITLE SCREEN:

4.4.1 DESCRIPTIONS AND PRIORITY:

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.

4.4.2 STIMULUS/ RESPONSE SEQUENCES:

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.

|P a g e 9
 4.4.3 FUNCTIONAL REQUIREMENTS:
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:

4.5.1 DESCRIPTIONS AND PRIORITY:

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.

4.5.2 STIMULUS/ RESPONSE SEQUENCES:

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.

4.5.3 FUNCTIONAL REQUIREMENTS:

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.

| P a g e 10
 Amazing Boxy has been developed for Android Version 2.2 and all subsequent
releases. The Android platform is graphically adaptable with a 2 dimensional
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 informatio n. 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

| P a g e 11
 make sure that no unauthorized player/ person will have access to his or her
phone.

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

| P a g e 12
 in implementation on an architecture that does not really yield any
substantial benefits at this stage in the project.

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 PRIORITY
AB – 01 The current route shall be retrieved from the High
database upon game start.

AB – 02 The current task shall be retrieved from the High

database upon game start.

AB – 03 The game state shall be updated in the database High

during game play.

AB – 04 The application shall display a welcome screen on Low

startup.

AB - 05 The welcome screen shall contain a button for Low

starting the next task.

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.

| P a g e 13
 8.2.2 TASK FLOW:

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

| P a g e 14
 welcome screen is very simple and contains a LinearLayout, TextView
and a Button.

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
TaskActivity
to 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.

| P a g e 15
APPENDIX A: USE CASE MODELLING

| P a g e 16
PLAY GAME

PAUSE GAME

RESUME
GAME

SAVE GAME

EXIT GAME

SELECT
MODE

EASY

DIFFICULT

CHANGE BACK
GROUND COLOR

WHITE

BLACK

CHANGE CHARA-
CTER SHAPE

SQUARE

CIRCLE

DIAMOND

CHECK SCORE

| P a g e 17
APPENDIX B: FUNCTIONAL REQUIREMENTS

| P a g e 18
USE CASE: Play Game
ID: UC 1
ACTOR:
Gamer/Player
Pre-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 Game

ID: UC 2
ACTOR:
Gamer/Player
Pre-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

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The gameplay and drawing should be paused, FPS should
be decreased to 1 or 0.

| P a g e 19
USE CASE: Resume Game
ID: UC 3
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The gameplay and drawing should be resumed, FPS should
be set back to the 60fps.

USE CASE: Save Game

ID: UC 4
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The information at that particular frame should be saved in
the database.

| P a g e 20
USE CASE: Exit Game
ID: UC 5
ACTOR:
Gamer/Player
Pre-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 gameplay
3) The application closes.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The game process is killed.

USE CASE: Select Mode

ID: UC 6
ACTOR:
Gamer/Player
Pre-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 area
3) The different modes should be populated.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The user gets into the mode selection area

| P a g e 21
USE CASE: Easy
ID: UC 7
ACTOR:
Gamer/Player
Pre-condition:
The mode selection event should have triggered

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

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The gameplay becomes easy

USE CASE: Difficult

ID: UC 8
ACTOR:
Gamer/Player
Pre-condition:
The mode selection event should have triggered

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

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The gameplay becomes difficult.

| P a g e 22
USE CASE: Change Background Color
ID: UC 9
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The background color has been changed during the
gameplay

USE CASE: Black

ID: UC 10
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The background color has been changed to the black during
the gameplay

| P a g e 23
USE CASE: White
ID: UC 11
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The background color has been changed to the white
during the gameplay

USE CASE: Change Character Shape

ID: UC 12
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The user ends up in the shape selection menu

| P a g e 24
USE CASE: Circle
ID: UC 13
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The shape of the character is now a circle.

USE CASE: Square

ID: UC 14
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The shape of the character is now a square.

| P a g e 25
USE CASE: Diamond
ID: UC 15
ACTOR:
Gamer/Player
Pre-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.

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The shape of the character is now a diamond shaped.

USE CASE: Check Score

ID: UC 16
ACTOR:
Gamer/Player
Pre-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

Secondary Scenario:
 User exits the application by pressing the back or home
button of the Android device.
Post-condition:
 The user saw the score list

| P a g e 26
APPENDIX C: DATA FLOW MODEL DIAGRAMS

| P a g e 27