Design & Risk table

texturegainfulMobile - Wireless

Dec 10, 2013 (3 years and 4 months ago)

57 views




CS430

Elliott Iannello, Daniel Gilmore, Jacob
Wolen, Anthony Glitzner

3/10/13

CS430

Searching

~A Game about a Robot~

Design

Document

Table of Contents

Introduction

................................
................................
................................
................................
..................

4

Goals and Objectives

................................
................................
................................
................................
.

4

Statement of Scope

................................
................................
................................
................................
...

4

Software C
ontext

................................
................................
................................
................................
......

4

Major Constraints
................................
................................
................................
................................
......

5

Key Terms

................................
................................
................................
................................
..................

5

Data Design

................................
................................
................................
................................
...................

6

Internal Software Data Structure

................................
................................
................................
..............

6

Global Data Structure

................................
................................
................................
................................

6

Save File and Level File

................................
................................
................................
..............................

7

Architectural Design

................................
................................
................................
................................
......

8

Architecture Description

................................
................................
................................
...........................

8

Overall Class diagram

................................
................................
................................
................................

9

Component Level Design

................................
................................
................................
............................

10

Descri
ption of Components

................................
................................
................................
....................

10

Processing of Narrative for Game Functions

................................
................................
..........................

11

Processing Narrative for GameDirector Functions

................................
................................
..............

11

Processing
Narrative for Player Functions

................................
................................
..........................

13

Processing Narrative for Background Functions

................................
................................
.................

15

Processing Narrative for Tile Functions

................................
................................
...............................

15

Proces
sing Narrative for Item Functions

................................
................................
.............................

16

User Interface Design

................................
................................
................................
................................
..

18

Gameplay Design

................................
................................
................................
................................
........

19

Aesthetics

................................
................................
................................
................................
................

19

Mechanics

................................
................................
................................
................................
...............

19

Story

................................
................................
................................
................................
........................

19

Concept Art

................................
................................
................................
................................
.............

20

Schedule

................................
................................
................................
................................
......................

22

Milestones

................................
................................
................................
................................
...............

22

Detailed Design Plan

................................
................................
................................
...............................

22

Limitations and Restrictions

................................
................................
................................
........................

23

Risk Table

................................
................................
................................
................................
.................

24

Citations

................................
................................
................................
................................
......................

27






Notes:


Introduction

This document is constructed to relate the requirements for building the game
Searching
, a mobile
platforming

game built for Android. The core of the experience is to provide entertainment while also
imparting a philosophical message to users. The game’s mainstay is random level generation, which will
ensure no two play
-
troughs are exactly the same.

The game’s a
esthetic style (while technically simple)
and thoughtful use of mechanics will be used to convey the overall theme of the game
-

that is, finding
one’s purpose in the world takes trial, error, and most of all the courage to “jump”. This application will
be

developed for the most widely used version of the Android OS (Gingerbread) and for mobile cellular
devices
-

this means the game may not be compatible with tablet devices. Distribution will be done via
the Google Play Marketplace and the Team Website wher
e the game will be available for download as an
applet.




*Note: Game Design relies heavily on the creative process, which is an ever changing and flowing
endeavor when it is at its best. With that
stated

it holds that nothing in this document is final
and is
subject to change.

Goals and Objectives

The main goal of this application is to provi
de a
fun

and meaningful experience

to users on the go.

The
game’s touch based control scheme should feel fluid, responsive, and accurate.

Players should be able t
o
sit down with the game for 10
-
15 minutes and have a fruitful experience; hence levels/zones should be
relatively short but present a challenge at the same time. Save and quit functionality is needed to keep
track of progress as it is important to make su
re players reach the finale of the game without the
frustration of always starting over.

Statement of Scope

The scope of the application will be limited to the capabilities of the Android 3.0 OS, Java, and the
average hardware specifications of modern day
cellular devices.

Interactions with the application will be
simple tactile touch based control as player input (i.e. jump, left, and right) and the images and sounds the
game will display in response via the phone will be the only form of direct output.

A save file will need
to be stored internally on the phone.

Software Context

This application is intended to be distributed as a commercial product on the Google Play marketplace.

It
will be available in two flavors: a free version with advertisements and
a 0.99 cent version without
advertisements.


It must fulfill the wants and needs of the average mobile gamer.

The game’s style and
gameplay are geared towards attracting as wide an audience as possible, as is the message it is trying to
convey.





Major
Constraints

Conforming to the limitations of the Android OS 3.0 will be the greatest constraint.

There are some
functions native to Java that do not port into the Android environment. Other considerations to be taken
include the screen size and resolution

of the broad base of phones that run this version of
Android.


Feedback should be limited to visual since any auditory feedback may be drowned out by
crowd noise or the phone may be muted while the user uses it in a public space. Users will probably
pres
sed for time or in transit when wanting to engage in playing the game, hence this places a limitation
on the level design since they must be kept brief but remain fun and challenging.

Key Terms

Term

Definition for the Context of Game

Zone

A Zone is a
series of levels that maintain a co
n-
sistent theme. The game will have 3 distinct zones.

Level

One part of zone. The player will have to keep
navigating and completing them to receive enough
Tokens to move on.

Platforming

A genre of game where the prima
ry mechanic is
dodging/jumping obstacles. Heavy focus on nav
i-
gation and exploration.

Wall
-
Grab

A move where the player controls the character to
grab the side of a tile for moment in time; wall
grabs can’t be held forever…only a brief moment
and then the

player will be forced to jump again.

Token

An item/collectible that once the player has enough
of a new Zone will be loaded. Tokens will play an
importance to the theme of the game.




Data Design

Internal Software Data Structure

These are software
elements that contain information for the game to integrate smoothly for all of the
following elements. Each of these elements will need to be updated sequentially in the game loop.


Sprite
-
This data Structure contains a substantial amount of data to keep
track and to update on the current
game loop. Players will have an integer health value for interaction with the enemies. The sprite class will
contain information such as thrusting; thrusting will consume fuel, which must be kept track of inside the
sprit
e class. Then Animations need to be kept track of such as each image when the player does a special
event, to simulate this move; for example jumping, crouching, climbing, and walking.


Enemy
-
Enemies structure will contain an integer collision value for da
maging the sprite. This Class will
contain the movement animation for simulation of movement. The enemy will need to contain collision
detection to make sure the enemy stays in an area to make sure the player must interact with the enemy.


Level
-

Each leve
l created will exist in a Level File containing all levels needed. When a level is needed it
will be chosen from a list of levels. Each level will contain information such as collectables, thrust
quantity and the level itself. Each level will be designed t
o operate on a specific dimension. Once a player
transverses that level a new level will be chosen from a level collection to simulate random level
generation.


Level and Sound Animations
-

Each level will contain a certain level animation. After it is dete
rmined that
the level animation needs to updated for the story progression a new level animation will be loaded with
the correct terrain and background. Sound will also be assigned to certain story progressions zones, to
ensure proper story interaction.


C
ollision
-

A Collision class will need to be created to allow for certain design constraints, and proper
player operation over the game. Collision for the player will be when the player hits walls and floors to
allow the game to make the player stop fallin
g, or walking forward. When a player falls through a pitfall
the game will need to make sure the player is dealt with accordingly. Collision also must include player
interaction with enemies.


Global Data Structure

Constants Interface
-

This Class will be
an interface to keep track of gameconstants.

These will contain the
following:

o

Scroll Speed
-

speed the background moves with the player.

o

Movement Speed
-

Speed player moves.

o

Jump height
-

Height the player jumps.

o

Block width
-

width of a level block.

o

Block H
eight
-

height of a level block

o

Level Height
-

total height of a level.

o

Level Length
-

Total

Length of a Level.

o

Zone Number
-

Story progression
animation.

o

Item Collected
-

total number of items collected.

o

Background Directory
-

Background location for each

Zone number.

o

Tile Texture
-

Texture image of the level block.

o

Save File Location
-

Location of the players save file.


Save File and Level File

Save File
-

A save file will be created upon user prompt to save the current state of the game, or upon exit
of
the game. The save file will contain information on the progress of the current game, amount of items
collected in the game, current difficulty level, and player information.


Level File
-

This will contain a level using a normal text file. Each terrain pie
ce will be represented by a
number corresponding to its terrain image. These will be loaded into a two dimensional array and
interpreted to display the proper terrain. Collectable items will also be represented by a number for proper
assignment to the leve
l. The Levels will also contain an integer value of the total amount of thrust allotted
to the player.



Architectural Design

Architecture Description

Our class architecture do
es

not fully adhere but are based off a commonly used model in game
development


that is the MVC model (Model, View, Control).


This image can be found at the following URL:
http://www.google.com/imgres?imgurl=http://www.codeproject.com/KB/tips/ModelViewController/Figure4.gif&imgrefurl=
http://www.codepr
oject.com/Articles/25057/Simple
-
Example
-
of
-
MVC
-
Model
-
View
-
Controller
-
Design&h=400&w=600&sz=15&tbnid=3piW8bQpxfE4sM:&tbnh=73&tbnw=109&zoom=1&usg=__lXApjNgI2Eev6LNqAs4Kd5CGHLU=&docid=LVC
0XfByoR7JYM&hl=en&sa=X&ei=lFI9UffCGuy40QHs0IG4Bg&sqi=2&
ved=0CEYQ9QEwBA

The GameDirector Class combines the responsibilities of the View and Controller components of the
above model, but the other classes act as observers that deliver responses to the GameDirector class based
on input received.

This is a flexi
ble design to use since adding features to the game is encapsulated
mostly in our Model. Very few changes are needed to be made to the view and controller; they just
simply give responses and take input. Combining the View and Controller portions of the
MVC design
model into a single class was choice made for two reasons: it lets us perform balancing (when we start to
get feedback) more quickly and the majority of the resources we used to learn how to make this game
offloaded these responsibilities into a

single class.



Overall Class diagram

This class diagram is tentative. If new features are added (ex. Enemies) it will be updated.


+
update
()
+
moveRight
()
+
moveLeft
()
+
stop
()
+
jump
()
+
stickRight
()
+
stickLeft
()
-
Fuel
:
Integer
-
Position
-
x
:
Integer
-
Position
-
y
:
Integer
-
Sprite
-
MovementSpeed
-
x
:
Integer
-
MovementSpeed
-
y
:
Integer
-
TokensCollected
:
Integer
Player
+
forUpdate
()
-
Position
-
x
:
Integer
-
Position
-
y
:
Integer
-
TextureNumber
:
Integer
-
Images
Backgrounds
+
update
()
-
Image
Tile
+
animate
()
-
DelaySpeed
-
ImageArrayList
Animator
+
checkCollisionVertical
()
+
checkCollisionHorizontal
()
«interface»
Collidable
-
Image
-
Taken
-
Position
-
x
-
Position
-
y
Item
+
loadMap
()
+
update
()
+
paint
()
+
saveGame
()
+
loadGame
()
+
randLevelSelect
()
-
Player
-
Background
-
LeveTilelArrayList
-
ItemArrayList
-
GameState
:
Boolean
GameDirector
Levels Folder
BackgroundD
irectory
Sprite Folder
Interface
1


Component Level Design

Description of Components

This game can be simply described in terms
of the various states that it will assume, as defined in the state
diagram

(see below)
. Each state is independent of one another, but the transitions between the different
states will be discretely defined.


For State 0, the player will start at the main
menu, where they will be able to start a new game, load to a
previous game level, view their current states, and can quit. Each of these options can be selected with a
button. Once a game is being played a player can continue playing until desired, if the
y wish to quit or
save their

current progress then simply pausing to
go to the game menu

will write current progress to the
save file
.
A player can safely exit the game by pausing and choosing to quit via the menu; any other
termination of the game will re
sult in a loss of progress.
This menu will be reached by selecting the menu
key on the
player’s

phone.



Once the player has chosen to play a game (State 1), they can either load a previous game or start a new
one, in which case a new level will be selecte
d from the game level directory, and the player can start
moving around the level. If at any point the player runs out of resources to continue the level (such as
fuel), they will be placed back at the starting point. As the player is moving throughout the

level, they will
be collecting items which will remove the individual item that the player passes through and it will be
recorded that the player has picked up the item. Finally if the player reaches the finishing point of the
level, the player will be sh
own their statistics for that level, and their overall statistics, then they will be
shown a cut
-
scene and a new random level will be selected.


As the player is moving throughout the level (State 2), they will be return to an idle state after moving.
Thou
gh from the idle state, they can move either left, right, jump, fall, or continue to be in an idle state.
These movements will be dictated with pressing the left/right hand side of the screen, or swiping (and
holding) for jumping.


If the player presses th
e menu key, they will be taken to State 3, the game menu state. In this state, only
buttons can be selected. If the main menu is selected from this state, a prompt for saving will be posed,
and then the player will be returned to the main menu. This is the

same case, for quitting from this menu.



State Diagram


Behavioral Model of
Game State
Game
Game
Generate Level
Cut Scene
Run out of
resources
Movement
Collect Item
Finish Point
Start Point
Statistics
“New Game” or “Load
Game” Button
Restart level
,
record
“You’ve Collected another item”
“Ohh noo”
“You’ve Completed another
Level”
“Resume” Button
“Time to start another phase
in your life”
“Time to start another phase
in your life”

Processing of Narrative for Game Functions

Processing Narrative for GameDirector Functions

1.1 Processing Narrative for loadMap():

Description:

Loads a random level generated by the RandomLevelGenerator class from a two
dimensional matrix.

Processing Narrative:

Once called, loadMap() parses the given matrix and traverses it line by
line to build a corresponding ArrayList of tiles and items in the

order that they appear in the m
a-
trix.


Inputs:

Fixed size two dimensional character matrix


Outputs:

ArrayList of tiles(Tile object) and items(Item object) corresponding to matrix.

Performance Issues:
Due to the hardware limitations of mobile devices, C
PU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.


1.2 Processing Narrative for update():

Description:

Main game loop that calls severa
l methods in order to update all of its components.

Processing Narrative:

Once called, update() enters an infinite loop that calls several methods
that update its data objects and gather user input.


The Player class, Tile class, Item class, and
Backgrou
nd class are all updated with each iteration of the loop.

User input is also listened for in
this loop via touch

events and handled appropriately. Finally, animate() is called, which is d
e-
scribed below.


Inputs:

None

Outputs:

Updated character(Player ob
ject) position and display model, updated tiles(Tile o
b-
ject), updated items(Item object), updated background(Background object)

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

D
esign Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.


1.3 Processing Narrative for paint():


Description:

Draws the game’s assets to the screen.

Processing Narrative:

Once called, paint() draws

each of the recently update data objects to the
screen.

The background(Background class) is drawn first, then the tiles (Tile class), items(Item
class) and finally the character(Player class).


Inputs:

None


Outputs:

Updated sprites on display

Performa
nce Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.



1.4

Processing Narrative for saveGame():


Description:

Saves the current session’s progress.

Processing Narrative:

Once called, saveGame() writes elements of the game that can be used to
determine progress (such as phase in the game, number of deaths, and

items collected) to a text
file.


Inputs:

None


Outputs:


Updated text file that contains information on the progress of the player.

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored clos
ely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.



1.5

Processing Narrative for loadGame():


Description:

Loads the previously saved session.

Processing Narrative:

Once called,
loadGame() reads the given text file and creates a game
state that is similar to the previous session.


Inputs:

Text file that contains information on the player’s progress


Outputs:

Appropriately generated levels and items

Performance Issues:
Due to the

hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.






1.6

Processing Narrative for randLevelS
elect():

Description:

Loads a randomly selected predefined level for the user to play on.

Processing Narrative:

Once called, randLevelSelect() will go into the level directory and

select a level and a texture (based on the progress of the player)

Inputs:

The directory of levels that is to be selected from

Outputs:

Returns a level with a texture scheme that will be used by load() that can be converted
into tiles

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will

have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.


Processing Narrative for Player Functions

2.1 Processing Narrative for update():


Description:

Changes chara
cter’s position (x and y values of Player instance).

Processing Narrative:


Once called from the main game loop, update() changes the x and y c
o-
ordinates of the object.

The amount of change is a direct result of user input.


Inputs:

Horizontal move speed
, vertical move speed


Outputs:

Updated x and y coordinates

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform

well on a variety of
hardware configurations.


2.2 Processing Narrative for moveRight():


Description:

Moves the character to the right.

Processing Narrative:

Once called from the main game loop as a result of user input,
moveRight() sets the horizontal

move speed to a positive value indicating movement to the right.


Inputs:

User’s touch

event


Outputs:

Updated attributes

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Desi
gn Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.


2.3 Processing Narrative for moveLeft():


Description:

Moves the character to the left.

Processing Narrative:

Once called from the main game l
oop as a result of user input, mov
e-
Left() sets the horizontal move speed to a negative value indicating movement to the left.


Inputs:

User’s touch

event


Outputs:

Updated attributes

Performance Issues:
Due to the hardware limitations of mobile devices,
CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.


2.4 Processing Narrative for stop():


Description:

Stops the movement of the charac
ter.

Processing Narrative:

Once called from the main game loop as a result of user input, stop() sets
the horizontal move speed to 0 indicating no movement.


Inputs:

User’s touch

event


Outputs:

Updated attributes

Performance Issues:
Due to the hardware

limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.


2.5 Processing Narrative for jump():


Description:

Moves the character upwards

Processing Narrative:

Once called from the main game loop as a result of user input, jump()
sets the vertical move speed to negative value indicating an upward motion.

Note: Java’s coord
i-
nate system has a reversed y axis.


Inp
uts:

User’s touch

event


Outputs:

Updated attributes

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well
on a variety of
hardware configurations.


2.6 Processing Narrative for stickRight():


Description:

Allows the character to stick and slide down the right side of a wall.

Processing Narrative:

Once called from the main game loop as a result of user input,

stic
k-
Right() alters the attributes of vertical motion (slowing the apparent descent of the character) and
the jumping procedure.


Inputs:
User’s touch event


Outputs:
Updated attributes

Performance Issues:
Due to the hardware limitations of mobile
devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.

2.7 Processing Narrative for stickLeft():


Description:

Allows the characte
r to stick and slide down the left side of a wall.

Processing Narrative:

Once called from the main game loop as a result of user input, stickLeft()
alters the attributes of vertical motion (slowing the apparent descent of the character) and the
jumping pr
ocedure.


Inputs:
User’s touch event


Outputs:

Updated attributes

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and
perform well on a variety of
hardware configurations.




Processing Narrative for Background Functions

3.1 Processing Narrative for

update():

Description:

Updates the position of the background. This provides a scrolling effect that gives
the appearance o
f moving character.

Processing Narrative:

Once called from the main game loop, update() changes the horizontal
position of the background image.

This movement is relative to the character’s(Player class) ho
r-
izontal and vertical movement speed.



Inputs:


Movement speed of Player class


Outputs:

Updated attributes

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perfo
rm well on a variety of
hardware configurations.

Processing Narrative for Tile Functions

4.1 Processing Narrative for update():

Description:

Updates the tile’s position. This makes it appear that the character(Player class) is
moving when the tiles are
actually moving around the character.

Processing Narrative:

Once called from the main game loop, update() changes the horizontal
and vertical position of the tile(s).

This change is relative to the character’s(Player class) horizo
n-
tal and vertical moveme
nt speed.

Once the position is updated, this method calls checkColl
i-
sionHorizontal() and checkCollisionVertical() to make any adjustments to the character’s pos
i-
tion.


Inputs:
Movement speed of Player class


Outputs:

Updated attributes

Performance Issues
:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.


4.2 Processing Narrative for

ch
eckCollisionHorizontal():

Description:

Checks for horizontal collisions between the character(Player class) and the
tiles.

If detected, the character’s position is adjusted so that the images do not intersect.

This
gives the appearance of a physical bou
ndary within the environment.

Processing Narrative:

Once called from update(), checkCollisionHorizontal() determines if
there is an intersection between the character’s(Player class) collision box and the tile’s collision
box. If an intersection is detect
ed the character’s horizontal position is changed accordingly.


Inputs:

Player class collision rectangle and tile collision rectangle


Outputs:

Updated attributes

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage

will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.








4.3 Processing Narrative for

checkCollisionVertical():

Description:

Checks for vertical collision
s between the character(Player class) and the tiles.

If
detected, the character’s position is adjusted so that the images do not intersect.

This gives the
appearance of a physical boundary within the environment.

Processing Narrative:

Once called from
update(), checkCollisionHorizontal() determines if
there is an intersection between the character’s(Player class) collision box and the tile’s collision
box. If an intersection is detected the character’s vertical position is changed accordingly.


Inputs:

Player class collision rectangle and tile collision rectangle


Outputs:

Updated attributes

Performance Issues:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compati
ble with Android 3.0 and perform well on a variety of
hardware configurations.


Processing Narrative for Item Functions

5.1 Processing Narrative for update():

Description:

Updates the item’s position. This method is almost identical to the update method
found in the Tile class.

The distinction between the two is how the collision is handled.

Processing Narrative:

Once called from the main game loop, update() changes the horizontal
and vertical position of the item(s).

This change is relative to the cha
racter’s(Player class) hor
i-
zontal and vertical movement speed.

Once the position is updated, this method calls checkColl
i-
sionHorizontal() and checkCollisionVertical().


Inputs:

Movement speed of Player class


Outputs:

Updated attributes

Performance Issu
es:
Due to the hardware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.


5.2 Processing Narrative for
checkCollisionHorizontal
():

Description:

Checks for horizontal collisions between the character(Player class) and the
items.

If detected, the item is no longer drawn and the character has obtained the item.

The co
l-
lection of items is logged in the GameD
irector.

Processing Narrative:

Once called from update(), checkCollisionHorizontal() determines if
there is an intersection between the character’s(Player class) collision box and the item’s collision
box. If an intersection is detected, the item’s sprite

is no longer drawn and the GameDirector u
p-
dates its collectable item list.


Inputs:

Player class collision rectangle and item collision rectangle


Outputs:

Updated attributes(collectable items list and objects to paint)

Performance Issues:
Due to the ha
rdware limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.







5.3 Processing Narrative for checkCollisi
onVertical():

Description:

Checks for vertical collisions between the character(Player class) and the items.

If
detected, the item is no longer drawn and the character has obtained the item.

The collection of
items is logged in the GameDirector.

Process
ing Narrative:

Once called from update(), checkCollisionVerticall() determines if there
is an intersection between the character’s(Player class) collision box and the item’s collision box.
If an intersection is detected, the item’s sprite is no longer dra
wn and the GameDirector updates
its collectable item list.


Inputs:

Player class collision rectangle and item collision rectangle


Outputs:

Updated attributes(collectable items list and objects to paint)

Performance Issues:
Due to the hardware
limitations of mobile devices, CPU and memory usage
will have to be monitored closely.

Design Constraints:

Must be compatible with Android 3.0 and perform well on a variety of
hardware configurations.





User Interface Design


Below is a crude mock up of

Searching’s
interface. The arrows on the left and right actually will not be
visible during game play (hence the transparency). They are there to signify where the player will touch
the screen to move left, right, and jump. There will be control instru
ctions in the “Help” section of the
menu and under “Options” a feature will be available to turn on transparent control guides in the final
version of the game. The red arrows and buttons represent a place where the player can hold their finger
to move in

that direction. The yellow up arrows indicate “Jump” commands. Swiping up on the screen
will perform a jump. Swiping up and holding the finger after the swipe will cause a wall
-
grab; doing that
gesture on a specific side of the screen will cause the play
er to grab respective side of a wall in
-
game.


Android OS’s development tools provides and API with a stock menu, this is what will be displayed when
the game is paused. To pause the game, press the Home button on your Android phone. The back button
on t
he Android device will act as an exit command, but this exit will not trigger the game to save.


It was important to keep the interface as minimal as possible so the player is focused with the
environment. Indicating such things as fuel and number of to
kens collected will be done by changing the
imagery used to depict the robot on screen. For instance, as a player uses up fuel the robot will begin to
frown and look tired.
For collecting tokens, a gauge on his chest will go up for each item collected.

On
ce again, important for immersion that we eliminated a HUD (Heads Up Display).



Phone Screen
(
Horizontal
)



Gameplay Design

This section is purposed toward divulging some of the more artistic decisions and development that
occurs when constructing a
game and will walk through the inception and progression of the story,
mechanics, and aesthetic of the game.

This section is more of a reflection for creative purposes than it is
for technical use.

Ultimately all of our technical decisions are made on th
e basis of a creative one


a.k.a. a decision made
while designing the actual game. The whole aim of the project is pending on delivering a fun and
meaningful experience. If the game isn’t fun, the rest of the design (no matter how meticulous) is for not
.

Aesthetics

The overall mood we wanted to invoke was a meditative one. This isn’t supposed to be a sad game, just a
contemplative one. The color palette will reflect this nature by using a combination of metallic hues and
dingy grays. Each zone will be

distinct in its texturing but the overall feel has to remain the same:
meditative. Zones will change to match the themes of love, intellect, and spirituality. Natural and earth
-
like colors will be used sparingly at first and grow more prevalent as the pl
ayer progresses through each
zone. This is reflective of T01313 gaining essence of being…basically becoming more human.

Mechanics

It was important that the mechanics actually made sense with the theme. For instance just the simple
action of jumping over pits


the pillar stone of platformers


had to provide some addition to the theme.
This action is contextualized in that the pits

are like the “pitfalls of life” that we can fall into. Failure will
happen, but how well we react and learn from failure will dictate our end. That is why we decided that a
player’s adeptness at playing the game would be reflected in the closing of the
game…but up until that
point there is no penalty for death. Wall grabbing and the fuel resource system are simply there to make
sure that we had other mechanics to play off of to make traversal a little more interesting. It’s important
to the art form to

use gameplay metaphorically, but far more important to make sure that the game
remains fun and interesting.

We opted for handcrafted levels that will be selected randomly from a pool over entirely randomly
generated levels so we could ensure that each l
evel provides some sort of unique challenge; using the
three mechanics of collection, fuel, and wall grabbing we hope to be able to craft about 40 unique levels
each with their own unique gimmick.

Story

It was important to us from the beginning to have som
e sort of narrative behind the game. Narrative does
two things: it contextualizes your actions within the game and deepens immersion. When we were
coming up with our in game items (tokens) for example, it was important for us to make sure we had an
answe
r for the player if they asked: “Why am I doing this?”

The games narrative will place players in the role of T01313, a robot who has been beaten up by his hard
labor in a factory. T01313 one

day gets decommissioned by the factory he works in, but rather

then
except his junkyard fate, he goes out into the world and tries to fix himself
. Pursuit of him is forlorn since
he is an old banged up robot that is easily replaced. T01313 goes on a journey of illumination,
searching
for the things that
he thinks w
ill fix him, but turn out to be symbolic of
the essence of being: love,
intellect, and spirituality.
He mistakes flowers for gears, and begins collecting them. Once he has
enough, he gives them to a girl who is crying to cheer her up. Next, he mistakes
books for batteries.
Eventually, he hands this collection over to a man in need of inspiration. Finally, candlewicks are
mistaken for wire and given to a candle maker in a church.
Depending on how much T01313 focuses on
finding one these three particula
r things will affect his ultimate fate. Will he be balanced? Will he be
romantic? Intelligent? That is up to the player and how well they perform in each zone.

Concept Art

The following pictures are some of the initial pieces of conceptualization we have
performed to figure out
how the game will look and feel. The focus so far has been the main character, the robot T01313.




The above images were just initial sketches done by a graphic designer helping us named Meghan Long.
All are of T01313.



The above conceptualization was done in our first meeting and by Elliott V. Iannello. Key thing to note is
the concept drawing of how a level might work.


More artwork is in development as of the publication of this document. It is being done by Meghan
Long
,
Jesse Lewis,

and Kristen Manzo.

Schedule

Milestones

Date

Goal

3/2/13

First Alpha Build


Begin Alpha Testing

3/8/13

Design Plan Due

3/19/13

First Class Demo

3/20/13
-

3/27/13

Have all art Assets and focus on Graphical Fidelity

4/9/13

Second
Class Demo

4/10/13
-

4/30/13

Beta Test and Polish

5/1/13

Final Class Demo/ Hand game in for Evaluation

6/1/13

Have game published on Google Marketplace


Detailed Design Plan



Week of Mar. 2:

Compile Development Plan, and Proofread. Construct a
concrete Data Hierarchy of Classes, R
e-
fine Requirements Specifications


Week of Mar. 8:


Turn in Development Plan Draft, Work on Refining Requirements Specifications, Finalize Data
Hierarchy, and work through a gaming tutorial Kilobolt (Cho), Create Presen
tation


Week of Mar. 12:

Present Presentation, work on refining randomization (add rules to randomization), and controls


Week of Mar. 19
-
27:

Continue working on refining randomization and controls. Add Main Menu, make second prese
n-
tation for second iterat
ion
. Alpha version should be close to complete to begin Integration Tes
t-
ing.


Week of Apr. 9:

Present Second Iteration, continue working on randomization and controls, add the cut scenes,
and debug Main Menu
. Beta Test.


Week of Apr. 30:

Final up levels,
and create and present third and final iteration

for class
.


Month of May:

Consider feedback given from Beta and make changes accordingly.


June 1
st
:

Hopefully submit to Google Play for certification and distribution.



Limitations and Restrictions

Accessibility
: The only way
for users to acquire

this game is through the Google Play marketplace
provided by
third party

(a service provider and Google)
.



Hardware Diversity:
Android is run on a variety of different devices ranging in complexity and pow
er.
Making sure the play experience across these devices is smooth will be a constraint, since limiting
graphical complexity will be crucial for maintaining performance.


Developing for Gingerbread:

Gingerbread is the most widely used Android OS, so it i
s the primary
focus; this limits though the market for exposing the game to those still using past versions of the OS.
There is not too much worry in running the game on future OS’s since Android remains fairly backwards
compatible.


The Creative Process:

This is a constraint in the sense that we are trying to ensure that it happens, and by
doing so risk dealing with abrupt change (and just more change in general). It is important to let
creativity have “its way” throughout the development process because

it will ultimately make for the best
game possible. It will be imperative to know where to draw the line in terms of when changes and new
ideas can no longer be brought to the table.


Developing for Immersion:
This is a self
-
inflicted constraint. Even t
hough this is a small game in scope,
it is still a goal of this team to minimize the amount of UI the player will see and communicate everything
through the play experience. We want to maximize immersion buy eliminating on screen buttons
indication where
fingers should touch or even showing a score…everything should be communicated via
the environment and character on screen and how these things change in response to player action.



Risk Table


Key

Term

Meaning

Low

Impact



Little affect on project success. Negligible

Medium

Impact



Mediocre affect on project success.

Noticeable

High

Impact



Substantial affect on project success.
Considerable

V. High

Impact



Disastrous affect on project success. Ca
t-
astrophic

Gree
n

Probability



Unlikely to occur. Rare.

Yellow

Probability



Likely to occur. Probable.

Red

Probability



Will Occur. Imminent.


Table

Risk Number

Issue

Risk Area

Response

Impact

Probability

R
-
01

Failing to Meet a
Deadline

Project and
Technical

Delegate tasks
better; Break
work down into
smaller pieces
and make more
frequent
deadlines;
monitor progress
more closely.
Adjust feature
list for game
accordingly

High

Yellow

R
-
02

Design/Feature
Change

Project and
Technical

Readjust
prioritization of
features and aim
to finish what
we think will
serve to be the
most robust
feature suite.
Continue to be
agile to cope
with the
demands of
working on a
creative
endeavor.

Medium

Red

R
-
03

Feature Added to
Design

Project and
Technical

Staying flexible.
Making sure that
any feature
added adds to
High

Yellow

enjoyment and
re
-
playability
but detracts from
overall
complexity.

Staying
tenacious and
being aware that
a creative
endeavor will
always present
this fluid
challenge.

R
-
04

Insufficient Unit
Testing

Technical

Develop a
thorough testing
plan.


Individuals test
their own code
as well as having
a Peer test it.

High

Green

R
-
05

Insufficient
Integration
Testing

Technical

Use good Design
principle to
mitigate
overhead when
combining
modules.


Test on multiple
platforms
-

PC
(Running as
Applet) and on
Android OS.


Have a thorough
testing plan.

High

Green

R
-
06

Artists Missing a
Deadline

Project

Add temporary
(crude)
Sprites
as place holders.


Give them a
stern talking to if
game is late in
development.

Medium

Yellow

R
-
07

Bugs created
from Porting to
Android

Technical

Use a different
version of
Android OS.


Re
-
Test
Modules.


Remove as many
functions Native
to Java as
possible.

V. High

Yellow

R
-
08

Negative Player
Project and
Take the
V. High

Yellow

Response
During Beta
Testing (Game
isn't Fun)

Technical

feedback given
by players and
redesign game
accordingly.


Have multiple
features

implemented so
swapping and
combining to
create a fun
experience will
be easier.


Implement/

Write code in
such a way to
make it easy to
change.

R
-
09

Java
Functionality
Deprecated from
an Update

Technical

Re
-
write feature
or affected part
with a work
around.

V. High

Green

R
-
10

Android OS
Update causing
Bugs

Technical

Re
-
write feature
or affected part
with a work
around.

V. High

Green

R
-
11

Development
Hardware
Failure

Project and
Technical

We are using an
online
Repository to
preserve work



nothing is
localized. We
have Computer
labs and multiple
machines
(Laptops and
Phones)
available to the
Group

Low

Green




Citations


Brackeen, David.
Developing Games in Java.

Berkeley: New Riders Publishing, 2004.

KiloBolt.

11 February 2013 <http://www.kilobolt.com/>.