2d cargame for android

Transcription

2d cargame for android
technical report
5/18/2012
[Type the company name]
David Murphy student number – x08678383
Contents
Technical Report ....................................................................................................................... 4
1
Executive Summary ........................................................................................................... 5
2
Introduction ........................................................................................................................ 5
3
2.1
Background .................................................................................................................. 5
2.2
Aims ............................................................................................................................. 6
2.3
Technologies ................................................................................................................ 6
2.4
Structure....................................................................................................................... 7
System ............................................................................................................................... 8
3.1
Requirements ............................................................................................................... 8
3.1.1
Functional requirement .......................................................................................... 8
3.1.2
Data requirements ................................................................................................. 8
3.1.3
User requirements ................................................................................................. 8
3.1.4
Environmental requirements .................................................................................. 9
3.1.5
Usability requirements ........................................................................................... 9
3.2
Design and Architecture ............................................................................................... 9
3.3
Implementation ........................................................................................................... 11
3.4
Testing ....................................................................................................................... 16
3.5
Graphical User Interface (GUI) Layout ....................................................................... 17
3.6
Customer testing ........................................................................................................ 18
3.7
Evaluation .................................................................................................................. 18
4
Conclusions...................................................................................................................... 18
5
Further development or research ..................................................................................... 19
6
Bibliography ..................................................................................................................... 19
7
Appendix .......................................................................................................................... 20
7.1
Project Proposal ......................................................................................................... 20
TITLE – android 2d car game .................................................................................................. 20
7.1.1
Objectives ............................................................................................................ 22
7.1.2
Background ......................................................................................................... 22
7.1.3
Technical Approach ............................................................................................. 22
7.1.4
Special resources required .................................................................................. 22
7.1.5
Technical Details ................................................................................................. 23
7.1.6
Evaluation ............................................................................................................ 24
7.1.7
Consultation 1 ...................................................................................................... 24
7.1.8
Consultation 2 ...................................................................................................... 24
7.1.9
Proposed Supervisor ........................................................................................... 24
7.2
Project Plan ................................................................................................................ 24
7.3
Requirement Specification ......................................................................................... 24
Introduction ............................................................................................................................. 24
7.3.1
Purpose ............................................................................................................... 24
7.3.2
Project Scope ...................................................................................................... 24
7.3.3
Definitions, Acronyms, and Abbreviations ........................................................... 25
7.3.4
User requirements definition ................................................................................ 25
7.3.5
System architecture ............................................................................................. 26
7.3.6
Touch screen ....................................................................................................... 27
7.3.7
Description & Priority ........................................................................................... 27
7.3.8
Functional requirements ...................................................................................... 27
7.3.9
Requirement 4 – tilt controls ................................................................................ 29
7.3.10
Requirement 5 – touch screen controls ............................................................ 29
7.3.11
Requirement 6 – collision detection .................................................................. 30
7.3.12
Requirement 7 - finish ...................................................................................... 30
7.3.13
Documentation requirements ........................................................................... 31
7.3.14
Non-Functional Requirements .......................................................................... 31
7.3.15
The response times need to be instantaneous as lag is a game killer. ............ 31
7.3.16
A quick load time .............................................................................................. 31
7.3.17
Catchy tune for each tracks .............................................................................. 31
7.3.18
System models ................................................................................................. 31
7.3.19
System evolution .............................................................................................. 33
7.3.20
Appendices....................................................................................................... 33
7.3.21
Use case A1 ..................................................................................................... 33
7.3.22
Use case A2 ..................................................................................................... 34
7.3.23
Use case A3 ..................................................................................................... 34
7.3.24
Use case A4 ..................................................................................................... 35
7.4
Monthly log book ........................................................................................................ 36
1.Reflective journal .................................................................................................................. 36
2.Reflective journal .................................................................................................................. 37
3. Reflective journal ................................................................................................................. 37
7.5
Other material Used ................................................................................................... 39
7.5.1
1. how often do u play games? ............................................................................ 39
7.5.2
2. how do rate the look of this game? .................................................................. 39
7.5.3
3. what changes would you make to this game? ................................................. 39
7.5.4
4. what do you think of the control system? ......................................................... 39
7.5.5
5. what changes would you make to the control sytem? ...................................... 39
7.5.6
6. how likely would you be to download this game? ............................................ 40
7.5.7
7. any additional comments? ............................................................................... 40
Technical Report
1 Executive Summary
This is the technical report of the theGame project for android for my 4th year project. This
document describes in detail the various stages of design and implementation. This document
covers:
 Architecture how the game sits in regards to the phone.
 Implmentation i.e. how it was made giving sample code and bringing you through the main
class of the project and explaining its implementation and ideas such as collision the axis’
motion is covered even though not used.
 Design I changed the games design about 1 month in which lead to the design being altered
its still a 2d car game but the objectives are different as is the flow.
 Testing- this covers what testing was implemented and the problems it encountered and the
work around solutions I developed.
 Gui important in any game is its gui and the section covers the gui implementation
 The appendix is – a list of references to other relevant material.
At the end of this document you should know, how it works, why it’s built and where it will go
from here. I will also give my thought and feeling on this project in the form of a conclusion.
2 Introduction
The purpose of this document is to outline all aspects of the project created as part of the final year
project for the bshss course. Over the following document I shall, explain the reasons for the game,
explain how the game works and give you my idea for the future of this game and others which will
be made from it.
2.1 Background
This project is the creation and implementation of a game using the android system as my final year
project. The reasons for creating this game on the android system are many, the android market
currently has the largest market share of mobile devices and is growing, it eliminates the need for
expensive hardware as most (if not all) android development tools are freely available. The reason
for developing a mobile game is that it is a currently growing and vibrant market with more people
playing mobile games than traditional games on console meaning a greater market share potential
and can be developed for without needing a team of people. Lastly why develop a game, a game is
unlike anything I’ve developed before needing a lot of planning and logical thinking but the
structure of a game with constantly changing states presented a unique challenge and I’ve always
had a keen interest in games which I why I wished to understand how they worked. I did a little
programming in xna but nothing substantial and the language style is very different. The original
idea for the game changed over the course of the build as it was first a racing game however this
seemed dull (I also knew I could never beat Mario cart) so this seemed like a better alternative. The
project proposal for this game contains a plan for the development of a racing game however as
stated before this idea is more accessible and allows for greater enjoyment while still implementing
several key racing concepts (movement, collisions).
2.2 Aims
The goals of this project was the creation of an easy to use, pick up and play game that could be
played by all ages as long as they have an android phone and a touch screen. The reason was as
stated above there are more casual gamers than traditional gamers meaning a larger potential market.
2.3 Technologies
Programming languages.
Java:
Java- android is mostly programmed using java tools and techniques however the syntax structure
for implantation is different than traditional java. Most of the code contained in this project is java
based.
Xml:
Basic layout and resources are controlled referenced and edited in the various xml files located
throughout the project. It also contains the permission requests, these are the things needed to run
your app i.e. <uses-permission
android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> request permission to
access the external storage so an SD card, and the run instructions i.e. orientation can be portrait or
landscape depending on your needs.
Development tools
Eclipse ide:
The recommended development environment for android. Eclipse is an open source ide (integrated
development environment) which can be downloaded at http://www.eclipse.org/. The reason it is
advised to use eclipse is that eclipse is a plug-in based system and there is pre-built plug-ins and
android libraries that easy to use and install, source files for plug-ins at https://dlssl.google.com/android/eclipse/. This will give an easy, free and more importantly useful
tool for developing any android app.
Paint:
The free program installed on every windows pc. Don’t underestimate the value of paint when
designing image, while there’s more useful tools and the functionality of paint might be limited its
simplicity can be a great resource when touching up an image on the fly without having to decide
which of 9,000 shades of gray you’d like.
Gimp:
Gimp is the open source, meaning freely available programs without heavy license agreements,
version of Photoshop and while it is a lot more complicated to use, it provides the same functionality
which is especially useful for adding transparency to an image for use in applications. An image
done through paint will always have a white box surrounding it gimp however sets this to invisible.
Android SDK:
This contains all files need to create test and run android application. It also contains an emulator for
android devices however; I personally found this to be unreliable, unstable and occasionally just
non-functional. All my personal testing was done using my phone a Samsung galaxy ace, which it
runs quite happily on.
2.4 Structure
Chpt.1 is simply the executive summary
Chpt.2 contains a background to the project, i.e. why did what I did. The aim of the project brief
description on what the project contains. Technologies used what I’m using and a brief description
on details of each.
Chpt.3 contains a list of requirements both functional and non functional for the project as well as
varies descriptions of the system architecture, user interfaces, and the game mathematical equations
(most of the game physics is based on maths). It will also describe how the game runs what classes
are used etc. I will discuss how the game was tested and evaluated.
Chpt.4 is my thought on the project and how it went.
Chpt.5 where the project is heading on my thoughts on how it should\could evolve.
Chpt.6 is the bibliography just a list of references used in the creation of the project referenced
Harvard style.
Chpt.7 appendix everything not included within the document itself but relative to the document.
3 System
3.1 Requirements
3.1.1 Functional requirement
The game must load all resources including images, sound, xml layout files and resource
files (this should all load through the apk file).
This is an extremely important requirement as u if the layout is messed up the game looks
bad, without one of the images you would explode without reason or run forever.
These images include:
User.png, otherCars.png, background.png
The xml files
Main.xml manifest .xml.
The game should respond to inputs on screen as they take place, if not the game appears
unresponsive.
Left = left.
Right side = right.
The game should detect collisions between the user and the othercars otherwise the game
has no point.
The game should display score in a meaningful manner with increments based on the
increased difficulty.
3.1.2 Data requirements
The game current requests access to the external resource for memory and while no storage
is accessed, this should be noted. It was going to send high scores to a file on the sd card
then retrieve them using java io file, however due to time restraint this was not implement
manly due to a slight miss sight could potential erase the sd contents (so time and care is
needed to make sure you don’t erase the entire card).
It also access temp storage for images.
3.1.3 User requirements
The user needs an android phone android version 2.1 or greater. They also need an API lv7
(the java) or greater. The device also needs a touch screen. Other than the user installs the
apk and clicks the icon.
3.1.4 Environmental requirements
The environment used to create this project was eclipse using the android sdk plug-in. The
images were created using a combination of gimp and paint. The sounds file while originally
going to be created by me were downloaded from www.freesounds.org (they don’t mind
unless you don’t give them credit). It was created using a windows seven operating system
and a decent processor. The run environment was the Samsung galaxy ace (aka my phone). I
dislike the emulator in its entirety and various things failed to run i.e. the sound files would
stop the images loading, the images would be misplaced, there’s really no end to my
problems with the emulator.
3.1.5 Usability requirements
For usability requirements I kept the game very simple this will allow all users young and
old to play it with ease. The user is a bright colour there is simple graphics with a simple
control scheme. So the game is easy to play.
3.2 Design and Architecture
The design will be simple and cheerful to encourage more user of a wider range to play. While
hardcoded at the minute the game will be implemented using scaling techniques to scale it to
other devices to reach wider audiences.
The basic project structure the three classes feed methods into the gameview which then is
displayed using theGameActivity.
This is the basic architecture for a game on android (for the android system architecture there
is a drawing in the requirement specification document). In its basic terms it’s the user inputs
something the system applies some logic to it this is then returned as output. For instance in my
game when touch event = true the user image x is subtracted or added to simulate horizontal
movement
public boolean onTouchEvent(MotionEvent event) {
image.setmovementforX(2);
return true;
}
There’s some pseudo code basically it should on a touch event add to the image x axis meaning
it moves to the right. Inputs are handled by key events or sensors and are taken in by android
which uses predefined game logic to apply an effect and return either graphics to the canvas or
audio to the speakers.
The main algorithm is tough to decide because there’s so many working in unison to produce
the output there’s collision detection algorithm, there’s the user movement algorithm, etc.
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mGameView = new GameView(this);
setContentView(R.layout.main);
setContentView(mGameView);
}
This function loads the mGameView which loads every other class method and
algorithm, which uses this function to move the user:
//get the x value of the touch then if it’s more than an x amount go right else go
left unless your nearing the edges of the screen
float x = event.getX();
if(user.collision(otherCars)){
user.setXSpeed(0);
}
else{
if(x<100){
if(user.getX()<=90){
user.setX(user.getX() -0);
}
else{
user.setX(user.getX()-20);
}
}
if(x>=100){
if(user.getX()>=220){
user.setX(user.getX()+0);
}
else{
}
}
}
return true;
}
3.3 Implementation
The xml file chooses which file to load in my case the AndroidManifest.xml file chooses the
TheGameActivity.java which contains the onCreate method (see above) see contains the call to
the mGameView which tell the activity to load commands from it
GameView; this is the workhorse of the project basically it contains several methods call to each
of the other classes as well as some algorithms, image references. It’s easiest to consider the
gameActivity as a gate then this is the house containing everything.
private
private
private
private
private
private
private
ArrayBlockingQueue<InputObject> inputObjectPool;
SpriteControl user;
SpriteControl bg;
SpriteControl otherCars;
MyGameCommands mGameCommands;
double ySpeed = .1;
int gScore = 0;
ySpeed = .1 means that the current value for y speed = .1 has to be a double because its less than
one it’s this way because moving at a speed of one is too fast for the othercars and the game
becomes unplayable. gScore is simply a variable to track score. SpriteControl user creates a new
sprite called user to be defined at a later stage but using commands from SpriteControl. It’s the
same for otherCars and bg. myGame Commands mGameCommands makes a reference to the
class myGameCommands.java.
user = new SpriteControl(BitmapFactory.decodeResource(getResources(),
R.drawable.car1), 150, 390);
bg = new SpriteControl(BitmapFactory.decodeResource(getResources(),
R.drawable.background),160,200);
otherCars = new SpriteControl(BitmapFactory.decodeResource(getResources(),
R.drawable.othecars), 165, -40);
This assigns the user, bg and othercars an image. Spritecontol is creating an object using the
method in spritecontrol.java(with the variables (bitmap), x value, y value). R.drawable.image ,
could be user bg otherscar is a reference to the R file (just so u know R.java is auto generated
and messing with it in any way upsets your application) containing references to the images
stored within the resources folder (public static final int background=0x7f020000 is a reference
to the background.png that I created then dragged and dropped into the resources folder;. The
160 is the starting x value on the screen whereas the -40 is the starting y value, minus 40
because I want the car to appear as though driving on the screen. Just a point about the co
ordinates 0,0 starts at top left so all –numbers for x or out of screen to the left and all –y
numbers are out of screen to the top and my phones screen is roughly 350 450. Ideally I get the
screen width and height with getHeight(),getWidth respectively however these variables are
assigned to = to 0 at time the constructor is created meaning get width() = 0 so you’d create an
image at 0, 0 or top left.
mGameCommands.setGameState(MyGameCommands.RUNNING);
This defines the game state as running.
otherCars.setYSpeed(ySpeed);
This set the speed of others cars to .1 along the y axis
public void update(int adj_mov){
//detects collision between the user image and the other car then tells the system
what to do
//gScore stops counting up
gScore = gScore + 0;
//get current user location
double currentX = user.getX();
double currentY = user.getY();
//stop movement a temp solution to a problem it should change the state
to a gameover screen
otherCars.setYSpeed(0);
user.setXSpeed(0);
// change the user to an explosion
user = new SpriteControl(BitmapFactory.decodeResource(getResources(),
R.drawable.tempexplosion), (int)currentX , (int)currentY);
}
//if not collision continue with game
else{
user.update(adj_mov);
otherCars.update(adj_mov);
//determines if cargoes true screen i set it high so there was a delay between
returning
if(otherCars.getY()>750){
//this is the start of code to retrieve external storage to send out and store high
scores
//String state = Environment.getExternalStorageState();
//File externalDir = Environment.getExternalStorageDirectory();
//this randomly selects a variable for the x for the othercars
double RandomisedXvars[] = {230, 90, 170};
double j = Math.round((Math.random() *2));
//this set the x value to the random amount
otherCars.setX(RandomisedXvars[(int)j]);
otherCars.setY(-50);
//this is used to increment speed across the game and add points the bonus points is
based on current speed
if(ySpeed< .5){
ySpeed = ySpeed + .03;
gScore = gScore +1;
}
else
if(ySpeed > .5 && ySpeed < .6){
ySpeed = ySpeed + .01;
}
else{
}
}
}
}
Update is possibly the largest function I have and what it does is simple, it instructs the project
to update the movement of images based one the update command from
MyGameCommand.java then applies various check the first collision if that occurs then there no
point in updating. If collision has it changes the image of user to explosion that way you know
that the game is over, if it hasn’t it updates movement for the othercar until other car hits 750, its
750 to cause a respawn delay very easily remove it at the edge but this made it more playable.
Also cause the car to speed up by a certain amount and awards points based on the speed
anything over .7 speed nets 100 points a time but is difficult to maintain. The reason it
increments at .03 is because it gives u time to get into the swing of things.
//get the x value of the touch then if it’s more than an x amount go right else go
left unless your nearing the edges of the screen
float x = event.getX();
user.setXSpeed(0);
}
else{
if(x<100){
If(user.getX()<=90){
user.setX(user.getX() -0);
}
else{
user.setX(user.getX()-20);
}
}
if(x>=100){
if(user.getX()>=220){
}
else{
}
}
}
return true;
}
This is the control for the touch event it does two important things 1 check if touch has
occurred, 2 update user based on touch. So if the touch event has occurred it retrieves the x
value of the event if the x is greater than 100 it’s on the right side of the screen whereas if the x
is less than 100 left side of the screen, then it updates the user based on this value either left for
a left touch right for a right touch unless your too far to the left than u can’t go left and the same
for right. It only makes sense that can’t cheat by driving on the path. I explain an if in detail
now: if (x<100) just above we defined x as the touch event x cords.
Nested if(user- the image user defined earlier as sprite- .getX()- defined in sprite control
allows u retrieve the x value for a sprite- <=90{
User.setX – defined in the sprite controls allows us to set x for a given sprite(user.get()0) the minus 0 is only a precaution.
Else{
User.setX(user.getX()-20)
}
So this means that first check the touch event if it left side of the screen minus the x axis but
first check the location of the user sprite and if it location is ninety or lower don’t move him left
if not, move him 20 pixels left (0 on the x axis is the left side of the screen so minus x goes left).
canvas.drawColor(Color.BLACK);
//draws a a backgroud over the black
bg.draw(canvas);
//draws the other cars on the background bg
otherCars.draw(canvas);
//draws a user over the bg background
user.draw(canvas);
//this is the setting up of a canvas for the text field gScore
Paint paint = new Paint();
paint.setColor(Color.WHITE);
String sc = String.valueOf(gScore);
canvas.drawText(sc, getWidth()/2, 10, paint);
The comments take care of most of the explanation but this is the onCanvas method this
basically allows the System to draw images to the canvas whether they are cars, users. The
interesting part is that linearLayout view which the game runs in is actually running in text view
with the paint paint = new paint(); it allows u to dynamically print the String sc and u can set the
colour, I picked white to stand out against the black.
.drawText uses three fields string, x value, y value and the forth assigns it to paint.
This is the key functions of the main class although the class implements using spriteobject.java
and myGameCommands these classes contain useful functions and act like library. Some useful
functions are:
public boolean collision(SpriteControl enemy){
double lside, enemy_left;
double right, enemy_right;
double top, enemy_top;
double bottom, enemy_bottom;
lside = x;
enemy_left = enemy.getX();
right = x + bitmap.getWidth();
enemy_right = enemy.getX() + enemy.getBitmap().getWidth();
top = y;
enemy_top = enemy.getY();
bottom = y + bitmap.getHeight();
enemy_bottom = enemy.getY() + enemy.getBitmap().getHeight();
if (bottom < enemy_top) {
return false;
}
if (top > enemy_bottom){
return false;
}
if (right < enemy_left) {
return false;
}
if (lside > enemy_right){
return false;
}
return true;
}
This is the collision detection method used by the game. this used to detect if image a hits image
b it achieves this getting x and y for both image a and image b the comparing the values as
follows if the top of image as is lower than the bottom of image b, if the bottom of image as is
higher than the top of image b, if image a right is lower on the y axis then image b left, or if
image a left is higher than image b or than there can’t be collision if one of these is untrue
there’s collisions.
3.4 Testing
White box- every time a new element was added I allowed the program to run for an extended
period to ensure that each element caused no undesirable effects. The use of log calls to the
logcat proved very helpful in this testing. I always ran through the new function in particular
with the result I expected.
This led a lot to complications in particular the game states. I could not get them to work and
in the end built workarounds for them which in the end show the core game mechanics are
functional however it would be greatly improved with the game states changing. Particularly
noticeable at the end when the collision detects and it does not transgress to a game over
screen. The workaround is simple it stops the game mechanic and shows the score.
Another issue received through white box testing was the accelerometer the original idea was
to control left and right movement with it however based on how the accelerometer seems to
work that is it doesn’t seem to detect the roll direction but instead detects the angle of the roll,
you might wonder why this is a problem well 90degrees to right = 90degree to the left, the
system can’t distinguish between them. My theory is you need an additional sensor input to
detect the orientation of the roll but due to time I couldn’t research this fully.
Environmental testing- tested extensively on the target device works and plays well.
Black box- I gave the game to people to test and asked their opinion I also got people to fill
out surveys. Testers installed the game on their phone devices and it tested fine.
Unit testing – to test the different process I removed certain elements to create test cases. For
example I removed collision when trying to test the speed increases and removed speed
increases to test collision detection. I either increased or decreased amount based on what I
thought was fair (i.e. the speed never reaches more than .6 to make the game more playable).
Verification and validation- setting key tests showed what didn’t work as expected and was
either fixed or ultimately removed it from the project.
A lot of these were testing by running the game looking for key events and fixing them. Only
black box testing was uncontrolled with log commands disabled. It is always helpful to see the
log outputs from tests to see something fishy occurring.
3.5 Graphical User Interface (GUI) Layout
This is the starting screen for the game as u can see the bright user car clearly defined left and
right borders to prevent u from hiding in the corner. Simple design but it is effective.
This shot shows the user can move and an update to the score tracking also shows that the
othercars position changes.
This is a screenshot of what happens when the two cars collide, an explosion occurs.
This is the basic design of the game it control by series of loops, if and reference calls.
3.6 Customer testing
I gave the app to several colleagues and asked for their opinions. They are around who the key
demographic for the app would be. They tested the game and its contents and filled out the
survey to let me know if they used the app.
3.7 Evaluation
Survey used for measuring the app responses vary but if the additional content I wanted to put
in then it would have been better received. Motion detection controls were brought up and I
think a future development of the game with that implemented would be a good improvement.
4 Conclusions
I really enjoyed making this game using new techniques and new technologies however as I was
only beginning to understand android development and have only scratched the surface of what
I can do with the android sdk. The advantages of this project were learning development of
mobile technologies and game structure and development. The only thing that was a
disadvantage was being constrains with a time limit and not able to fully develop as much as
like however I fully intend to continue research and development. The opportunities are
staggering as most if not all company are wanting mobile technologies and with the android
market only having a twenty five euro entry barrier it means indie games are almost free to sell
to the entire market share. I can also use this as a basis for more projects i.e. a space shooter
scrolls sideways fires lasers. The only real limit is what knowledge I know about android, in
future versions however open gl or opengl2.0 for 3d would be used.
5 Further development or research
The following is what I’m going to research in the future:
 Sensors
 3d programming
 Lifecycle
 Game development
I intend to fully develop this game in the future implementing various technologies. These will
include game states, accelerometer for movement and a social upload of your new highscore to
twitter. This will not only improve the social aspect to the game but create free advertising from
users tweeting their scores in the game. I also have planned to reuse a lot of the source code in
future projects as well. The layout of the folders is also helpful in future projects with the
structure of sprite, inputs, logic being funnelled into a view which is then displayed by an
activity.
6 Bibliography
Websites
google. (2010). dev guide. Available: http://developer.android.com/guide/basics/what-isandroid.html. Last accessed 15 may 2012.
midiworld. (1995). midi audio file download. Available:
http://www.midiworld.com/search/?q=killer. Last accessed 10 may 2012.
william j francis. (2011). A quick tutorial on coding Android’s accelerometer. Available:
http://www.techrepublic.com/blog/app-builder/a-quick-tutorial-on-coding-androidsaccelerometer/472. Last accessed 20 februaury 2012.
none forum. (2011). Android phone orientation overview including compass. Available:
http://stackoverflow.com/questions/4819626/android-phone-orientation-overview-includingcompass. Last accessed 10 februaury 2012.
forum. (2012). various articles. Available: http://stackoverflow.com/. Last accessed 16th may
2012
unknown. (2011). various sounds. Available: http://www.freesound.org/. Last accessed 20
februaury 2012
ellie for edu for java. (2010). Android Game Programming 2. Drawing an image using
SurfaceView. Available: http://www.edu4java.com/androidgame/androidgame2.html. Last
accessed 30 september 2011
Andreas Agvard. (2011). UPDATED: How to scale images for your Android™ application.
Available: http://developer.sonymobile.com/wp/2011/06/27/how-to-scale-images-for-yourandroid%E2%84%A2-application/. Last accessed 10th december 2011.
books
Mario Zechner (2011). Beginning Android Games. New York,: Springer Science+Business
Media, LLC., 233 Spring Street, 6th Floor, New York. 673.
Jeremy Kerffs (2011). Begining Tablet Game Programming. e-book: apres. 202.
7 Appendix
7.1 Project Proposal
Project Proposal the original proposal was a racing game however was later changed to more of
an obstacle game because seemed more enjoyable much remains applicable. The game state
remains the flow should be (removed character and track select) the game flow is main menugame-crash-submit score. The functions should be based on the new game should be highscores
the functions regarding lap times should be this, the rest of this document is applicable.
TITLE – android 2d car game
David Murphy, 08678383, [email protected]
BSc (Hons) in Software Systems
Date: 21/09/11
7.1.1 Objectives
This objective of this project is making a car game. The idea is more fun based rather than a
highly graphical game. To this end I hope to meet the following objectives:
8 (or more) unique characters
At least 10 unique tracks
Some sort of tournament mode
A time tracking for laps and entire races so players can compete for best time.
7.1.2 Background
I decided to do this project because I have an interest in games and I’m interested in how
they work and how to develop them. I chose a car game because with all the actions that
happen and the entire individual components mean I’ll have to understand all the
functionality and the processes involved in game development. I originally intended to do a
3d Xbox game but Keith Maycock suggested it would be better to make a 2d android game.
7.1.3 Technical Approach
I have to research android how to setup and control the flow of the game. I’ll be using
eclipse ide and the android sdk. I’ll probably need to practice using a graphic tool. I’ll
probably need to investigate a sound development tool.
7.1.4 Special resources required
As this is early on in the project the full list of resources needed is unknown at this time but
most likely I’ll use on line tutorials, books, some graphic designer, eclipse is a free ide,
android sdk and I may need to get a platform to test the project on when it’s finished.
7.1.5 Technical Details
This project will be done through java. Some memory system will need to be used to store
lap times. Each track will need some music, each character will need and the tournament or
cup mode will need to track wins with a fairly standard point system i.e. 10 for a win, nine
for second etc. the game flow will go something like:
Start game
music
Different
game
modes
Once
winner has
been
declared
return to
menu
Main menu
Menu graphics
Game select
menu
8 unique
chars
Character
select
Track select
(could be
random)
race
Winner/
time result
Different
tracks
Different
themes
Different
music
If its cup
mode
several
races
7.1.6 Evaluation
To evaluate this system I’ll test its functions under normal conditions i.e. can u pick a character,
can a car finish a track without falling through the stage. Then I’ll see what happens when u go
outside the normal conditions i.e. what happens if u drive around the track backwards or if u
drive of the track do u teleport to spot u fell from. I hope to bring the game to a nearby school to
test it there but I’ll have to see if this is possible. I’ll probably need some sort of questions
designed to test the different functions of it i.e. ease of use, colour selections etc.
7.1.7 Consultation 1
Keith Maycock
Suggested switching from Xna to android development, also suggested switching from 3d to
2d graphics due to quality.
7.1.8 Consultation 2
Dr. Dietmar Janetzko
Suggested I add more details i.e. what graphic designer I’d use etc.
7.1.9 Proposed Supervisor
Names of academic staff member that has agreed to act as a supervisor for this project.
7.2 Project Plan
7.3 Requirement Specification
Requirements Specification (RS)
Introduction
7.3.1 Purpose
The purpose of this document is to set out the requirements for the development of Android 2D car
game.
The intended customer is really anyone with an android device. A car game is simple and fun to play
making it available to anyone.
7.3.2 Project Scope
The scope of the project is to develop an android 2d car game. The system shall use the android
accelerometer to detect movement for turning the car. The android type will be 2.2.
This game idea was suggested by other students and refined after talking to a lecturer.
This project will be built in eclipse(this is an ide) tested using android sdk(this a tool-kit). I will run the
project on an android phone when finished for testing purposes but most testing will take place on the
android emulator(called android emulator and comes with the android sdk). This project has a six
month time restraint.
7.3.3 Definitions, Acronyms, and Abbreviations
IDE
SDK
Pick up and play
Lag
……..
Interactive development environment
Software Development Kit
a game where u can stop and start where you see fit with easy to use controls and
not a lot of time required to enjoy it.
a sudden stop in a game flow
7.3.4 User requirements definition
This section describes the set of objectives and requirements for the system from the customer’s
perspective. As I have no specific user in mind I will say what a gamer would expect.

First it has to be fun

Secondly it needs to have some competiveness (either between player and computer or player
and player) this adds to the longevity of the game.

Third it needs to run smoothly, a glitch filled game is a bad game.

Fourth because it’s an android game its need to be pick up and play.
Graphical components





Individual sprites for characters
Backgrounds for each track
The tracks
Menu
Options
Music



Menu music
Track music
Sound effects
7.3.5 System architecture
This system describes the architecture view of the system.
Source: http://developer.android.com/guide/basics/what-is-android.html on the 8/10/2011.
I couldn’t think of a better architecture view then the one from this site. It show you that the system
runs on a Linux platform, shows the library, etc.
4.1 Physical Environment Requirements
The only physical is an android capable device with version 2.2 or greater which most devices run.
4.2 Interface Requirements
This section describes how the software interfaces with other software products or users for input or
output. Examples of such interfaces include library routines, token streams, shared memory, data
streams, and so forth. Examples of Interfaces are

Touchscreen

Accelerometer(for detecting movement)
7.3.6 Touch screen
7.3.7 Description & Priority
The touch screen will be used for displaying as well as for starting the car.
7.3.8 Functional requirements







Main menu
Select character
Select track
Tilt controls
Touch screen accelerator
Collision detection
Finish
7.3.8.1 Requirement 1 – main menu
7.3.8.2 Description & Priority
All games have a main menu needed for navigation of games types.
7.3.8.3 Requirement Activation
Should be available on startup.
7.3.8.4 Technical issues
Needs graphics and music and a method for navigation.
7.3.8.5 Risks
The could be a system failure or the images may fail to load.
7.3.8.6 Dependencies with other requirements
This is the basis for all other requirements, this requirements happens at the start of the game
meaning if this fails the game cant continue
7.3.8.7 Functional Requirements
Use Case 1 …… see apeendix A1
7.3.8.8 Requirement 2 select character
Not that important but ascetically appealing for the user
The menu brings you to the character select.
Might not be an important feature.
7.3.8.12 Risks
Again image fail or the system fails to load.
Needs user to go from menu requirement then this requirement traverses to track select.
Use Case 1 ………see appendix A2
7.3.8.15 Requirement 3 – select track
The user select the track, important for the system to know what the images are to load.
The user selects it
Needs graphics and music, collision detection, other racers.
7.3.8.19 Risks
There could be a system failure or the images may fail to load.
This is depending on character select to load the characters onto the track
Use Case 1 …… see apeendix A3
7.3.9 Requirement 4 – tilt controls
The handling will be controlled by the accelerometer which is a device which monitors the tilt of
the device.
Should be available on start-up.
The device may not have an accelerometer .
7.3.9.4 Risks
The accelerometer could fail.
This requirements will connect with all other requirements.
Use Case 1 …… see apeendx a4
7.3.10
Requirement 5 – touch screen controls
The accelerator will be controlled with the touch screen
Should be available on start-up.
none
7.3.10.4 Risks
The touch screen could break.
This requirements will connect with all other requirements.
Use Case 1 …… see appendix A5
7.3.11
Requirement 6 – collision detection
The system needs to track the user and the other game objects and decide if they hit and what the
outcome of that will be.
Two objects have to collide.
The system might not track objects.
7.3.11.4 Risks
none
This requirements will run concurrently within the racing environment.
Use Case 1 …… see appendix A4
7.3.12
Requirement 7 - finish
This is the actual race plus the end otherwise the race would continue endlessly.
The user has selected the character and track so the system knows which images to load.
Might not load selected images.
7.3.12.4 Risks
Again image fail or the system fails to load.
Use Case 1 ………see appendix A4
7.3.13
Documentation requirements
Examples of document requirements are

There will be a small in game tutorial to explain the game function
7.3.14
Non-Functional Requirements
7.3.15
The response times need to be instantaneous as lag is a game killer.
7.3.16
A quick load time
7.3.17
Catchy tune for each tracks
7.3.18
System models
Use case
race
Context diagram
7.3.19
System evolution
Well other then fine tuning i.e. repairing the glitches. U could add expansion i.e. extra tracks new
characters. You could set up an online community where people could post there times etc.
7.3.20
Appendices
7.3.21
Use case A1
Use case
Main menu
Scope
The scope of this use case is to define the user interaction of the main menu.
Description
This use case describes the interaction in the main menu
Flow Description
Precondition
The system is inactive
Activation
This use case starts when an the user loads the game
Main flow
1. The system loads up an image
2. The system loads up the sound
3. The system loads up a list of options
4. The user selects an option(see a1 for alternate flow)
5. The system brings up the character select menu
Alternate flow
A1 : < A1>
1. The user shuts the system down
2. The system enter pre- run state
Exceptional flow
E1 : <E1>
3. The system crashes
Termination
The system presents the user with the character select screen
Post condition
The system goes to a wait stage
7.3.22
Use case A2
Use case
Character select
Scope
The scope of this use case is to define the user interaction of the character menu
Description
This use case describes the interaction between the user and the system in the character menu.
Flow Description
Precondition
The system is in the character menu
Activation
This use case starts when the user navigates to the character select screen.
Main flow
3. The system loads up a list of characters
4. The user selects an option(see a1 and a2 for alternate flow)
5. The system brings up the track select menu
Alternate flow
A1 : < A1>
1. The user returns to main menu
2. The system loads up main menu sound and images
A2 : < A2>
1. The user restart the system
2. The system begins initialisation
Exceptional flow
E1 : <E1>
Termination
The user selects a character
Post condition
The system goes to a wait stage
7.3.23
Use case
Track select
Scope
Use case A3
The scope of this use case is to define the user interaction while selecting tracks.
Description
This use case describes the interaction in the main menu.
Flow Description
Precondition
The system is waiting for user to select the track
Activation
This use case starts when the user has selected his character.
Main flow
3. The system loads up a list of tracks
4. The user selects an track(see a1 for alternate flow)
5. The system begins the race(finish use case)
Alternate flow
A1 : < A1>
1. The user returns to the select character screen.
2. The system returns to the character select screen
Exceptional flow
E1 : <E1>
Termination
The system loads the race(finish use case)
Post condition
The system begins the race
7.3.24
Use case A4
****Not applicaple on new game*****
Use case
Race
Scope
The scope of this use case is to define the process of the race
Description
This use case describes the interaction between the user and the system in the race.
Flow Description
Precondition
The user has selected both character and track.
Activation
This use case starts when the user begins the race.
Main flow
3. The system loads up the other racers
4. The system loads up the player
5. The user holds the touch screen(see a1)
6. The system moves the player car image forward
7. The player turns using the accelerometer (see a2)
8. the system moves player image in the desired direction
9. The system tracks the users image to detect things like impacts or if the user falls off the stage.
10. The user finishes the race
11. The system notes the time and place
12. The system present the user with its results
13. The user selects to return to menu
Alternate flow
A1 : < A1>
1. The user holds reverse
2. The system moves the user car image in the desired direction
A2 : < A2>
1. The user doesn’t turn
2. The system leaves it alone
Exceptional flow
E1 : <E1>
Termination
The user finishes the race
Post condition
The system returns to main menu
7.4 Monthly log book
1.Reflective journal
Over the last month I have:

Drew up the requirement specification



Set up the development environment by downloading and installing Eclipse IDE and downloading and
installing the android sdk
Began following tutorials on android development including the infamous helloworld app (used in every
programming language).
Set up an emulator to run the apps created
Over the course of the month I have encountered several problems such as the android sdk not installing
properly or the apps not being able to find the specified path when they worked fine the day before. I
have fixed these problems and have a working edition of both the android sdk and Eclipse IDE. This
will give me a solid platform to work on the project, especially over the upcoming “reading week”.
2.Reflective journal




Continued following tutorials on android development.
Began drawing designs
Learned more code
Learned how to use image creator gimp.
Mostly over the last month I have been creating images and learning code to implement these
images in android development. I've been coming up with a flow for the game and ideas for user
inputs.
3. Reflective journal





Rethought designs
Learned more code
Learned more about frame rates collisions
Created presentation for prototype
Mostly over the last month I have been editing code, following tutorials and preparing for prototype
presentation. This meant preparing power point presentation and an example of some functions.




Addressed memory consumption issue
Learned more code
Learned more about collision detection
Mostly over the last month I have been trying to deal with the memory issue my game encountered
strange error in which the game constantly using memory until the games image files failed and the
game crashed and I have been dealing with this error. I have also been researching more into
collision detection and updating the images used in the game. I’m still looking at different tutorials
for android and I’m looking at implementing the accelerometer to detect movement.




Got a book that can teach movement in android games.
Learned more code
Mostly over the last month I have been looking at different tutorials for android. Recently got a
book which walks you through the creation of snake on the android phone, this will teach me
enough about the accelerometer to implement it in my game. The book is fairly big so it takes a lot
of time to read and more importantly understand. Still looking at the collision detection issue I been
having where the game doesn’t detect that a car has collided with another, I believe the problem lies
with x, y graph formula I’m using.



Learned more code
Mostly over the last month I have continued looking at different tutorials for android. Continued
reading the book on android game development. Continued coding the game. Been unable to fully
focus on it with other projects being due however can now return to work on it.
7.5 Other material Used
http://www.surveymonkey.com/s/YYLTCT9
7.5.1 1. how often do u play games?
how often do u play games? daily
weekly
almost never
7.5.2 2. how do rate the look of this game?
how do rate the look of this game? very good
good
not good
terrible
7.5.3 3. what changes would you make to this game?
what changes would you make to this game?
7.5.4 4. what do you think of the control system?
what do you think of the control system? V.good
good
alright
bad
terrible
7.5.5 5. what changes would you make to the control sytem?
what changes would you make to the control sytem?
7.5.6 6. how likely would you be to download this game?
how likely would you be to download this game? very likely
likely
not likely
you wouldn't
7.5.7 7. any additional comments?
CD containing code should be glued to the technical report.

2d cargame for android

Transcription

Similar documents

Able2Extract mobile Quick Start Guide

Setting an Android Device to AutoFill Password Fields in

here - Northeastern NY PGA

J.P. Uniac mobile!

Greystripe signs ten more channel partners | Mobile Industry

SETUP EXCHANGE ON ANDROID DEVICES

April Android TV Box.cdr - April Digital Technology

3D Snow Rally Canada

64Bit Processor --- KINGZONE N3 PLUS Is Coming

Game Development in Android