A WarioWare Inspired Android Powered Game Salisbury University

Verge
A WarioWare Inspired Android Powered Game
Salisbury University
COSC 425 / 426
Dr. Steven Lauterburg
Spring 2013
Authors
Ronald Baasland
Ryan Langley
Jon Palmateer
Jason Tominack
Matthew Wolf
Table of Contents
Introduction .............................................................................................................................. 1
Verge ..................................................................................................................................... 1
The Team ............................................................................................................................... 2
Explanation of Terms.............................................................................................................. 2
Note to the Reader ................................................................................................................. 3
Description Of Process ........................................................................................................... 4
Problems Encountered ........................................................................................................... 4
Successful Practices .............................................................................................................. 6
Conclusion of Process ............................................................................................................ 7
Requirements ........................................................................................................................... 8
User Stories............................................................................................................................ 8
Use Case ............................................................................................................................... 9
Use Case Issues ...................................................................................................................10
Architecture and Design .........................................................................................................11
Beginning Android Game Development .................................................................................11
Avoiding Android Specific Development ................................................................................11
Package Hierarchy ................................................................................................................12
Asset Management................................................................................................................12
Asset Internal Storage ...........................................................................................................13
Asset Memory Management ..................................................................................................13
Audio Library .........................................................................................................................14
Graphics / OpenGL................................................................................................................17
Accelerometer and Multi-Touch Input ....................................................................................17
Bluetooth ...............................................................................................................................17
MicroGame State Machine Structure .....................................................................................21
Mode State Machine Structure ..............................................................................................21
Local High Scores .................................................................................................................22
Future Planning.......................................................................................................................24
More MicroGames .................................................................................................................24
Story Mode ............................................................................................................................24
Enhance Visuals ....................................................................................................................24
Database For Global High Scores .........................................................................................24
Expand Multiplayer ................................................................................................................25
Cross-platform .......................................................................................................................25
Release It To The Public .......................................................................................................26
Introduction
Verge
Verge is a new, innovative game for the Android operating system which pulls inspiration from
the game WarioWare, Inc. which released back in 2003 for the Game Boy Advance. WarioWare, Inc. was
composed of several small games called MicroGames, which are games that are about five seconds long
and have a simple objective that required the player to use the Game Boy Advance’s directional pad and
/ or the A button to complete. The driving force behind the gameplay in WarioWare, Inc. was to put
these MicroGames in a random order and have the player play them back to back. This created a very
frantic experience, especially when the game would increase the difficulty and speed of the MicroGames
as the player progressed. WarioWare, Inc. also supported several gameplay Modes such as Survival,
which would endlessly throw MicroGames at the player until they lost all of their four lives, and Time
Attack, which would record the player’s time as they played through a pre-made set of MicroGames
until they completed all of them.
Our game takes these concepts to the next level by infusing them with the power of the Android
operating system and Modern technologies. As stated, WarioWare, Inc. uses the Game Boy Advance’s
directional pad and the A button in gameplay. In Verge, we utilize features of the player’s Android
device to power gameplay. These features can range from single touching the screen to fire a laser, or
multi-touching the screen to connect a circuit, using simple gestures like making a flicking motion to toss
a ball, or using the accelerometer to weave a car in and out of traffic. We also decided to add more
detail to our MicroGames and because of that we have also allowed for more time to complete certain
objectives. Additionally, we thought the experience would be better shared with friends, so we
developed a multiplayer component that was missing in the original WarioWare, Inc. With a large
audience in mind, we attempted to design our game to be accessible as possible. We focused on
simplicity throughout the application to make sure it could be enjoyed by children and less tech savvy
individuals.
1
The Team
We are a group of five Senior undergraduate Computer Science majors at Salisbury University
taking a course in software engineering instructed by Professor Steven Lauterburg. During the project,
many of us were involved in taking heavy senior level courses, as well as others working full time. This
caused many restrictions on being able to meet in person to work on the project. As a result our team
managed to have conference meetings using Skype. We would try to set aside one day a week where we
could all get together and pair program.
The team consists of:
●
Christopher “Ryan” Langley
●
Matt Wolf
●
Jon Palmateer
●
Jason Tominack
●
Ron Baasland
Explanation of Terms
●
Android Activity - Activities represent the application screens. It is similar to a window or
dialog on a desktop operating system.
●
Eclipse - A popular and feature-rich open source Java integrated development environment.
There is a plugin for Eclipse called Android Development Tools which is designed to give you a
powerful, integrated environment to build android applications.
●
GIT - A distributed revision control and source code management system.
●
OpenGL ES 1.1 - A subset of the OpenGL 3D graphics application programming interface
designed for embedded systems such as mobile phones. It is cross-platform compatible.
●
API - Which stands for application programming interface is a protocol intended to be used as an
interface by software components. It is a library that may include specifications for routines,
data structures and object classes.
●
SD Card - An ultra-small flash memory card designed to provide high capacity memory in a small
card.
●
Wrapper Class - A wrapper class is any class which "wraps" or "encapsulates" the functionality of
another class or component. They provide a level of abstraction from the implementation of
the underlying class or component.
●
Use case - A list of steps, typically defining interactions between a role and a system to achieve a
goal. The role can be a human or an external system.
Note to the Reader
The concepts in this document assume familiarity with the following programming languages,
techniques, technologies, standards, libraries and frameworks:
●
Java SDK 6
●
UML
●
Object Oriented Programming - Architecture and design
●
Bluetooth
●
OpenGL ES 1.1/2.0
●
This is, quite possibly, the best game ever created for Android!
3
Description Of Process
Throughout the development of Verge, we used Extreme Programming practices such as pair
programming, the planning game, iteration planning, continuous process, continuous automated
testing, and various coding standards. However, with each of these practices we encountered problems
and roadblocks.
Problems Encountered
The first roadblock we encountered was the initial learning spike. Our group had none to
minimal experience with android applications involving OpenGL ES. This resulted in an initial learning
spike that lasted longer than the first iteration and the time expected to meet the learning spike. This
was due to the research needed to understand how to first set up an android application, but this still
only gave us a basic understanding of android applications and Canvas. However our game was unique
which had meant there wasn’t one source that we could our solutions. We had to constantly look for
new resources, and it was mostly trial and error with adding any additional aspects of the game.
Another problem/roadblock that we encountered was using some kind of version control
software that allowed us to not only backup the project for redundancy purposes, but allowed our
group of five programmers to simultaneously work on the project and merge code together. We chose
to use GIT which would allow any member of the group to grab the most updated project at any point in
time, and also made sure the changes successfully merge with the current master project before
uploading it to the repository. However, using GIT also came with some obstacles as well. In the
beginning we weren’t familiar with using GIT so there were a few occasions where instead of having all
the branches (when someone checks out the code to edit it) eventually merge back into the main trunk
or thread of the project, we had branches off of branches causing almost multiple trunks while working
on the project. Also, there are many features from GIT that were useful but we needed time to
understand how to use them such as the merging tool, pull/push to upstream, committing a change, and
recording issues.
Another earlier roadblock that our group encountered was how to implement some form of
automated testing. Our first attempt was to try and implement a form of white box testing. This form of
4
testing was to test the structures, functions, and classes of the project rather than test it from a user’s
perspective. To perform this type of testing we tried to implement JUnit tests. Although it was
functional, it was very impractical and time intensive. Most of the functions were unique and basic, so
testing was not necessary and it was far easier for us to test it manually and trying to implement these
tests was taking way too much time away from other aspects of the projects that had higher priority.
The next time in our automated testing attempt was to implement black box testing, which was from
the user’s perspective rather than the programmer’s perspective. In order to use this method of testing
we began research on Robotium which is a test framework specifically built for automatic black-box test
cases for Android Applications. At first this seemed to be a great fit for our project, however Robotium
had its pitfalls. The biggest problem we faced was Robotium was designed for Android GUI, not an
openGL GUI, which our project used in order to support cross-platform technology. Therefore, we very
limited on what resources we could use from Robotium. The few Robotium tests that we wrote for the
project were very basic GUI interface tests and the tests were relatively useless. Therefore, we chose to
stay with manual testing. This seemed to be the most effective and efficient, since we are a small group
of programmers it was very easy to know who changed what and where we should test the changes.
Also, with the more advanced android controls such as the accelerometer and multi-touch, it was easier
to manual test it. This was because we had to constantly change velocities, rate of accelerations, and
other object speeds in order to make it user-friendly and a smoother game. For example, we had to add
an offset into the accelerometer to make the game feel natural where to stay still, you don’t have to lay
the phone perfectly flat which has an unnatural feel. This wasn’t necessarily something a test would
catch, it just had to deal with the user-friendliness of the program. Overall, manual testing is still the
best option for our current project and although there is some use for white-box and black-box testing,
the time needed to implement those tests was far greater than the time automated testing would've
saved us.
A major roadblock that we encountered in our second semester of this project is the fact that all
5 members of our group are graduating after this semester. This is a significant problem since we are
spending time applying for jobs, going to job fairs, and doing interviews, when this time would have
been spent working on this project. This also causes priority of the group to change. Even though Verge
is important to all the members of the group, the goal of this semester is to find a job when we graduate
unlike last semester where our top priority was this project. Also, since we are all seniors, we all are
5
taking higher level computer science courses which are very time intensive. This caused us to cut back
the hours spent on this project compared to the previous semester.
Refactoring is a major practice Extreme Programming and one that we used very thoroughly.
Generally, we would completely develop a functional portion of the software for one of our user stories
and then we would return to it and refactor it so it was easily readable and efficient. This practice
helped us create high quality code but unfortunately it was a major time sink at the end of the day.
Successful Practices
Despite the roadblocks and problems we had with some of the Extreme Programming practices,
we had successes with the other practices of Extreme Programming.
The most successful and rewarding practice was Pair Programming. Even though pair
programming doesn’t necessarily mean that twice as much code is being written, the quality of the code
was far better than an individual programmer’s code. This was important because when you have 5
different programmer’s working on the same project, it is likely that you will have 5 different qualities of
code and 5 different coding patterns. The problem with this was that when another programmer had to
either add or edit existing source code, it was difficult to write code successfully and difficult to refactor
in general. Also, learning spikes were shortened because once one person had experience in a particular
area of the game, such as multi-touch, another person in the group could work with that person and
teach as they go, rather than having every person in the group having to teach themselves. Another
benefit of pair programming was motivation. When we were working alone for long periods of time, we
would begin to get tired of a particular section of the project and just lose motivation which decreased
the efficiency of the time we spent programming. When you would work with other people in the group,
you could have someone to help you keep concentrated and once you got tired or hit a roadblock, the
other person can come up with new fresh ideas. Overall, the greatest benefit to pair programming was
to prevent one-minded thinking. When anyone works on a project for long periods of time, they begin
to think in a very narrow way, and having a partner there helps you break out of that narrow way of
thinking.
6
Another successful practice was using iterations to set goals. As previously stated, everyone in
our group are graduating seniors, this added with having a two semesters to complete a project could
lead to procrastination. Especially since many of us had other projects to do, without iterations we could
have fallen into the mindset of giving this project lower priority since we have longer to do it. With
iterations, every 3 weeks was equivalent to a project due date so it provided the motivation to meet the
goals for every iteration thus preventing procrastination. Having iterations also gave us an idea of how
long future goals will take. For example, we had an idea of how long games should take, how long
changing the architecture should take, as well as other changes to the project. It also provided an
outline of what our realistic goals were for each semester and allowed us to realize if we are ahead or
behind of schedule.
Conclusion of Process
Overall, our project did not fit the XP paradigm so many of the XP practices were not of benefit
or relevance to our project which caused some time loss and delays. However, despite the roadblocks
and problems we encountered with the Extreme Programming practices, there were some practices
which worked out very well for us and we were able to provide a functional Android game called Verge.
7
Requirements
User Stories
All the user stories of our game fell into either the actual MicroGames or the layout and
capability of the game in general. The following user stories are for the layout and capability of the game
that pertained to things such as user friendliness, easy to navigate, minimal lag/loading, different
Modes, possible multiplayer, and keep track of scores.
●
As a user, I would like a menu system to navigate the game with ease
●
As a user, I would like a visually pleasing layout to see my current progression as I play the game
and a place to return to games I've played. (GameGridScreen)
●
As a user, I would like leaderboards to save my top scores
●
As a user, I would like the ability to control sound, just in case I am using the game in a place
where I need to be quiet.
●
As a user, I would like several different gameplay Modes such as a survival Mode or time
challenge
●
As a user, I would like the game to be user-friendly.
●
As a user, I would like a game that doesn't take FOREVER to load.
●
As a user, I would to play with my friends using Bluetooth.
The other user stories were pertaining to specific MicroGames such as a dodging traffic game,
fishing game, motorcycle game, connect the circuit game, a basketball game, and many other ideas for
games. However, the following user stories give more general requirements for games such as the type
of game or how the game is played.
●
As a user, I would like a time based loss/win game
●
As a user, I would like to utilize the full capability of my Android device for gameplay.
○
Accelerometer
○
Single/Rapid Touch
8
○
Multi-touch
○
Gestures
Use Case
For our use cases, our game only has one true use case. This use case is the User/Gamer. The
reason for this is there is not truly an AI or another perspective. It is the user playing the game trying to
beat his previous score. The user has the options to view their high scores, play survival Mode, play time
attack Mode, play any MicroGame, or exit the game and save their high score. The game does the have
the option to play multiplayer but that just includes more actors of the same use case with the same
choices, therefore there is still only one use case.
Figure 1: Use Case Diagram
9
Use Case Issues
When creating this use case diagram, our group had a long debate of how many user cases do
we have.
The first option was we only had one use case which was the user/gamer. The reason we said
only user case for this is because there is only one type of player. The game is not like a website where
you would have a general user, an administrator, or other users that had special privileges. Our game
also doesn't have an AI that acts like another user to perform some other goal. Our game does have
some automated movement such as the opposing traffic in the traffic MicroGame, the fly in the fly
MicroGame, or the fish in the fish MicroGame. However, we’ve decided that this small automated
movements of objects were not AI or had a goal, they were simply following a pre-existing path or
performing some meaningless task. Therefore, the user/gamer is the only true use case.
The other option was to have two use cases. The use cases would be the user/gamer and
physical SD card within the android device. The user/gamer use case would be the same use case as
stated above. for the SD card, one could argue that the SD card does have a goal of saving the local high
score of the game as well as displaying/retrieving the local high score. There was no wrong or right
answer of whether the SD card could truly be a use case. However, overall we decided the SD card
doesn’t necessarily need its own use case so we decided the exclude the SD card use case diagram.
10
Architecture and Design
Beginning Android Game Development
When we were first starting this project only half of us had any Android experience at all and
even less had experience in game development and graphics programming, so we looked for a resource
that would make it easy to learn everything we needed in a short amount of time. The resource we
ended up going with was Beginning Android 4 Games Development by Mario Zechner and Robert Green.
Our initial framework for our game was based off an implementation provided in the book and we made
changes and improvements to it as we developed the project. At this point in development the
framework is vastly different in a lot of respects, but still similar in other ways, such as using one thread
for handling and updating the game logic and one thread for drawing the graphics to the screen.
Avoiding Android Specific Development
We approached this project with the idea of flexibility. This allows us the opportunity to port our
code to other mobile operating systems easily using the cross-platform library OpenGL ES (Open
Graphics Library Embedded Systems.) OpenGL ES provides us the ability to use our specific code across
other mobile operating systems such as Apple’s iOS. By focusing on OpenGL ES instead of an Android
specific implementation such as Canvas, we have extended the reusability of our code across any
platform that supports the standard OpenGL ES library.
Not only does this approach allow us to avoid an Android specific implementation, it also retains
the intended look and feel of our application, without the need to heavily modify the existing source
code.
With this strategy in place, we have successfully reduced our work load and introduced a
broader market space for our game to touch upon publicly unveiling our app.
11
Package Hierarchy
Figure 2. Package Diagram
●
com.dbz.framework- Contains all of the audio, openGL, input, math, Bluetooth, and other
core framework.
● com.dbz.verge - Contains all super classes for menus, Modes, and MicroGames.
● com.dbz.verge.menus - Contains all the java class files for menu screens
● com.dbz.verge.Modes - Contains the class files for Time Attack and Survival Modes.
● com.dbz.verge.MicroGames - Contains all of the classes for each MicroGames.
● com.dbz.verge.MicroGames.objects - Contains objects for MicroGames.
Asset Management
In general, an asset is any multimedia file that is incorporated into a video game. Verge has two
main types of assets, image files and audio files. Intrinsically, the ways these assets are managed have a
direct impact on runtime performance.
There are two concerns for the management of assets:
●
How the assets are stored internally
12
●
How the assets are managed in main memory
Asset Internal Storage
Internally, the assets should be compressed to save on space. All the audio files are stored in an
Ogg format to maximize both compression and sound quality. For images, we use the Portable Network
Graphics (PNG) format. Although PNG’s are not optimal for compression, they do have a better than
average image quality and support alpha compositing.
We did explore other image compression formats supported by android, but have yet to
implement them due to time constraints. Note, that the formats are not universal; each device supports
its own image compression format. The following is a quick overview of the supported image formats:
●
ETC1 (Ericcson texture compression) - Supported by all Android phones. Does not support alpha
compositing.
●
PVRTC (PowerVR texture compression) - Supported by devices with PowerVR GPUs
●
ATITC (ATI texture compression) - Supported by devices with Adreno GPU from Qualcomm
●
S3TC (S3 texture compression) - Supported by devices with in the NVIDIA chipset integrated
devices.
Asset Memory Management
Managing the images in main memory is especially important on android devices because
Android limits the available memory per application. In addition, allocation and de-allocation of image
data can be computationally expensive. This is because the garbage collector is scheduled to run after
memory has been allocated or de-allocated.
Image management is a problem for Verge because there are several image assets per
MicroGame. Intuitively, the number of assets will grow as the number of total games grows. Thus there
is no bound on the number of images we will need for the game. To address these issues, we came up
13
with a design to ensure that only the necessary assets are in main memory at a given moment. The
simplified UML diagram in Figure 3 describes the design/implementation.
Figure 3: Generalized UML of Verge Asset Management
In essence, each MicroGame is responsible for providing functions to allocate, de-allocate, and
re-allocate assets. AssetManager’s job is to hold a reference to the current MicroGame and load its
corresponding assets. If a new MicroGame is loaded, the previous MicroGame is unloaded. In the case
that the Activity loses focus, i.e. the application is moved off screen, the assets are automatically deallocated by the system. So, when the user reopens the Activity again, AssetManager reloads all
previously referenced assets to return the game to its previous state. Note that AssetManager’s
load() method is used to preload the most frequently used assets and keep them in memory
throughout the lifecycle of the application.
Audio Library
An integral part of developing any successful game is implementing audio into the game play.
Audio, whether it is a sound effect or background music, can either enhance or ruin the gaming
experience. Android hosts two primary API’s for playing audio, MediaPlayer and SoundPool.
MediaPlayer was designed to implement larger music files or streams. As such, music files are
loaded from either internal storage or external storage (SD card). Although this saves on main memory
usage, reading and decompressing a file from internal/external storage will introduce a small delay each
time a request to play a sound is made. SoundPool on the other hand, was designed to implement
14
shorter sound files pre-loaded in main memory. This certainly circumvents the delay seen for
MediaPlayer, however, there is a limit on how much memory can be reserved in the heap.
According to the Android API, the per-application baseline memory class (heap size) is 16MB – though
this varies from device to device. Based on the information found on each API, we devised a plan to
develop a set of wrapper classes to simplify their use.
Figure 4: UML Diagram of Verge Audio Package
Figure 4 illustrates a simplified UML Diagram of the wrapper classes highlighting the prominent
parts of the implementation. The Sound and SoundManager classes work in tandem to wrap
SoundPool and the Music class wraps MediaPlayer. The Audio class is used to manage the
instantiation of each class to more effectively hide implementation details. Also notice that
SoundManager implements the singleton pattern. This design pattern was used to prevent
15
unnecessary SoundPool threads from being loaded into main memory. In addition, limiting ourselves
to a single SoundPool instance simplifies thread cleanup at the end of the application’s lifecycle.
16
Graphics / OpenGL
When we first started this project we made the decision to do our graphics using Android’s built
in API, Canvas. However, this was a mistake and it didn’t take us long to realize it as we found out the
limitations before our ‘Spike Iteration’ was even completed. In the end, we decided to go with OpenGL
to display our graphics because of it being cross platform supported which would allow us to port our
game to another operating system in the future, and because the power and performance was miles
ahead of Canvas. The only drawback was the massive learning curve that came attached to it, but that
was a drawback we were able to overcome.
Accelerometer and Multi-Touch Input
Android devices equipped with an Accelerometer provide a simple mechanism for retrieving the
relative x, y, and z positions of the device. One simply needs to register a listener to the accelerometer
and then poll the device for the tilt. Each MicroGame is responsible for handling the coordinates
returned from this listener. This allows flexibility in the game play for each MicroGame.
Similar to the Accelerometer, the multi-touch implementation listens for input events and saves each
touch event’s coordinate in an ArrayList. Each MicroGame iterates through the ArrayList every
frame and processes them as needed. Previous touch coordinates are removed from the array
whenever a new event is returned by the listener.
Bluetooth
We have given the player the capability to invite a friend to play head to head in an intense
mind numbing multiplayer battle royale using the short range networking protocol Bluetooth. The
multiplayer feature can be played with our survival game Mode, where players are pushed to the limit
of their reaction times with increasingly difficult MicroGames. The short range capability of Bluetooth
gives the feeling of a classic console experience where players can immerse themselves into the intense
fast paced action where players can see the agony on their opponent’s face.
17
We focused our multiplayer implementation to be as user friendly as possible. In a typical
Bluetooth process, the user is required to choose from a list of nearby devices by their respective
Bluetooth network names. This requires some understanding of the user of their devices and can be
confusing. We shifted our approach to automated this process by scanning nearby devices and
connecting automatically. This way the user only needs to wait until the connection process is
completed. We notify the user of the connection process in a unique fashion that intertwines with our
intended user experience.
Instead of using a typical dialog box to display a list of nearby Bluetooth devices, we are using
an automated process where a thread we called the ControlThread is created to iterate
through the nearby Bluetooth devices. First, we initiate the discovery process which is unique to
Bluetooth as a networking protocol. Before a connection can be established using Bluetooth, the
device’s Bluetooth name and MAC address must be identified. To do this, Bluetooth uses a discovery
process where nearby devices will broadcast their information with each other. During the discovery
process, our program builds a Hash Table consisting of all devices sniffed.
After the discovery process, our ControlThread sifts through the list of Bluetooth devices
and attempts to establish a connection with each one. We use a unique UUID as a handshake to verify
the proper recipient.
We have employed a server-side client networking scheme to establish and manage the
connection process. This process includes a thread dubbed the AcceptThread to act as a listen server
which uses a BluetoothServerSocket to listen for a connection from a client. We use a thread
dubbed the ConnectThread to act as our client which uses a BluetoothSocket to connect with the
listen server. The server and client pass the UUID to each other to verify both devices are Running our
app. Data transmissions are done using a thread we define as ConnectedThread which data is
transmitted as bytes in chunks of 1024.
18
Figure 5. Connection-State Diagram
19
Figure 6. Bluetooth UML Diagram.
20
MicroGame State Machine Structure
Figure 7: MicroGame State Diagram
As Figure 7 shows, the MicroGames are built with a state machine at their core. When the
player starts a MicroGame outside of a Mode it enters a Ready state where it will stay until a Ready
signal is sent to the system. Once the player has signaled they are ready it will go straight into the
Running state of the selected MicroGame until it completes via winning or losing the game. The state
machine will handle this by going to the respective state, Won or lost. At any point during the Running
state, the player may pause the MicroGame via a pause button supplied in the upper right corner and
return to the Running state via the same button.
Mode State Machine Structure
Figure 8: Mode State Diagram
21
As Figure 8 shows, the Modes are structured in a very simple format with a state machine built
into it, much like the MicroGame structure. When the player starts the Mode it will start in a Ready
state where it will wait until a ready signal is received. This signal is given when the player presses the
center of the screen. Once the signal is received it will switch to the Transition screen where it will
load the next MicroGame and prepare to launch it in the Running state. After a brief period of time
the Running state will begin and the player will play the MicroGame that was just loaded in the
previous Transition state. Upon completion of the MicroGame the Mode will update the live count
and go back the Transition state if there are still lives remaining. If there are no lives remaining the
state machine will go to the lost state and if the player completes all of the games successfully the state
machine will go to the Won state. At any point in time during the Transition or Running state the
player may enter the Paused state by pressing the pause button provided in the top right corner of the
screen.
Local High Scores
Every time the user completes survival or time attack Mode by either losing all their lives or
completing all the challenges/games, their score is then saved locally on the SD card in the file
vergehighscores. Only the top 5 scores for both survival and time attack Mode are saved on the SD
card, this is to save space and the gamer is only going to care about what his current top scores are,
since the goal of the game is to beat your previous scores. Survival scores are determined by the last
level you completed before you lose all your lives. This value is simply an integer and is compared to all
pre-existing scores on the SD card within the vergehighscore file to see if it is greater than any of the
other 5 scores. If it is, than the array of integers are then sorted greatest to least and only the top 5
scores are saved back into the file. When playing time attack, the goal is to complete all the levels fast as
possible. So once the user/game completes all the levels, the total time in seconds that it took to
complete levels is compared to the pre-existing 5 times already in the same file, vergehighscores,
under the heading “Time Attack High Scores”. If the time is less than any of the existing times, the list is
sorted least to greatest and only the lowest 5 are saved to the SD card.
The user can access these scores by simply pressing “high scores” on the main menu. When
displayed the survival high scores are displayed as integers from highest to the 5th highest level and the
22
time attack displays the shortest 5 times in the format of minutes, seconds, than microseconds, which is
rounded to two decimal places.
By default, the survival high score is 0, and the time attack’s default value is 3600 seconds or 60
minutes.
Figure 9. Verge high score’s screen.
23
Future Planning
More MicroGames
We still have countless ideas for MicroGames that have yet to be implemented that we want to
put in Verge. Since we spent the majority of our time improving and adding features to our framework
we didn’t have enough time up to this point to add every MicroGame that we wanted. However, our
framework is now a well-oiled machine and it will allow us to make new MicroGames with ease and help
us put every idea that we have into the final product.
Story Mode
A story for Verge was actually written very early on with plans of adding a Story Mode. The story
has actually influenced the game’s art direction up to this point but currently lacks any kind of
description for the player as of now. In the near future, we hope to develop the story Mode and provide
the player with a deeper interest and understanding of the game.
Enhance Visuals
We plan on recreating all of our current and creating new art assets to improve overall visual
quality of the game. A simple particle system has been developed alongside of Verge but has yet to be
implemented into the Verge framework. To accomplish this future goal we will also bring the particle
system into the application to provide better looking special effects such as smoke, fire, water, and
more.
Database For Global High Scores
Within the next few iterations, we plan to expand the high score system and move away from
only storing the high scores on the local SD card. The goal is to create a global database that can store all
high scores for the various Modes in our game such as survival Mode and time attack Mode. This
database would also allow you to record your score with an appropriate identification key, such as
24
initials, that will allow you and others to look at the high scores for all people that have played the
game. This would allow for a global competition to try and earn the highest score for Verge in the world.
Expand Multiplayer
In the next chapter of our saga, we intend to expand our multiplayer implementation to include
a real-time cooperative Mode. As it stands, our current implementation only allows for per MicroGame
multiplayer. We want to integrate additional features to give the player a more visceral experience. We
plan to add new challenges for each MicroGame so as to create the ability for players to play together
simultaneously on each MicroGame. A simple modification to the TrafficMicroGame would be to
add an extra car controlled by a second player and force each player to not only avoid crashing into the
traffic but each other as well.
So for each MicroGame we would expand our existing code into a co-op version with slight
modification to increase the value of each MicroGame. Not only does this make it easier for us to
increase the number of MicroGames for co-op but also gives the players a familiar environment when
they play single player.
Cross-platform
When we first started conceptualizing this project, we chose OpenGL ES specifically for its crossplatform capabilities and wide range of acceptance. With this known fact in mind, we ventured forward
intending to branch our code into other operating systems. Most notably, we have iOS locked in our
crosshairs. At some point in the near future, we are planning to port our existing OpenGL ES code we are
using for Android over to iOS. The only foreseen difficulties that we are aware of are implementing
sound and Bluetooth features, since the current implementation is Android specific.
25
Release It To The Public
After we polish everything up and add the above additional features, the plan is to release the
application to the public. However, we still aren’t entirely sure how we are going to do it at this point in
time. We are faced with the position to potentially monetize the application and try to turn a profit or
we could help power the mobile application development community by releasing our product under an
open source license. One thing is certain though, we do plan on putting the application on the Google
Play store.
26