A document I did in College for my final year project detailing my experience developing the same game for both the Android and Windows Phone 7 mobile platforms.
2. Contents
1. Abstract .................................................................................... 8
2. Introduction ............................................................................... 8
3. The Android Platform .................................................................. 10
4. The Windows Phone 7 Platform ...................................................... 12
5. Developing a Game ..................................................................... 14
5.1 Game Concept ........................................................................ 14
5.2 Game Architecture ................................................................... 15
5.2.1 Application Layer ................................................................ 16
5.2.2 Game Logic ....................................................................... 17
5.2.3 The Game View ............................................................... 18
6. Developing Games for Android ....................................................... 20
6.1 Native Code ........................................................................... 20
6.2 Java..................................................................................... 20
6.3 Android Game Architecture and considerations ................................. 20
7. Developing Games for Windows Phone 7............................................ 22
7.1 Silverlight .............................................................................. 22
7.2 XNA ..................................................................................... 22
7.3.1 XNA Game Architecture ........................................................ 23
7.3.2 What is in XNA? .................................................................. 24
7.3.3 Rendering ......................................................................... 24
7.3.4 Content ........................................................................... 25
8. Conclusion ............................................................................... 25
Requirements Analysis Document ......................................................... 26
1. Preface ................................................................................... 26
3. 2. Game Specification .................................................................... 26
2.1 Game Play ............................................................................. 26
2.1.1 Nathaniel: ........................................................................ 26
2.1.2 Hermes: ........................................................................... 27
2.1.3 Game Flow Design ............................................................... 27
2.2 Options ................................................................................. 27
2.3 Hall of Fame........................................................................... 28
2.2 Functional Requirements ......................................................... 28
2.3 Non Functional Requirements .................................................... 29
3. System Model ........................................................................... 30
4. Use Cases ................................................................................ 33
System Use Cases: ........................................................................ 33
Game Play Use Cases: .................................................................... 37
5. Questionnaire ........................................................................... 41
5.1 Analysis of Questionnaire Results ............................................... 42
6. Class Diagram ........................................................................... 44
Game Design Document ..................................................................... 45
1. Abstract ............................................................................. 45
2. Introduction ............................................................................. 45
2.2 Description .......................................................................... 45
2.3 Genre ................................................................................ 46
2.4 Scenario ............................................................................. 46
2.4.1 Threat Perception Algorithm .................................................. 47
2.4.2 Path finding Algorithm.......................................................... 48
3. Game Story .............................................................................. 48
4. 4. Game System............................................................................ 49
4.1 Model for Restful Web Service...................................................... 50
4.1.2 REST Application Data .......................................................... 50
4.2 Persistent Storage Design ........................................................... 51
4.2.1 Save Game Data ................................................................. 51
4.2.2 Schema for Online High Score Storage ...................................... 53
4.3 Game Play and Screen Design ...................................................... 54
4.3.3 Player Actions .................................................................... 54
4.3.2 Defensive Structures ............................................................ 54
4.3.3 Game AI ........................................................................... 55
4.3.4 Win/Lose Conditions ............................................................ 55
4.3.5 Normal Game Play Screen...................................................... 56
4.3.6 Player Being Attacked .......................................................... 56
4.3.7 Building Structure Screen ...................................................... 57
4.4 Logic Design ........................................................................... 57
5. Title and Information Screens ........................................................ 61
5.1 Main Menu Screen .................................................................... 61
5.2 Option Screen ......................................................................... 62
5.3 Hall of Fame Screen .................................................................. 62
6. Audio Requirements.................................................................... 62
7. Testing Strategy and Plan ............................................................. 62
7.1 Testing Strategy ...................................................................... 62
7.2 Testing Plan......................................................................... 64
7.2.1 Logging and Reporting .......................................................... 64
7.2.2 Components to Test ............................................................. 65
5. 7.2.3 Performance Testing ............................................................ 65
Installation Manual Document ............................................................. 66
1. Windows Phone 7 .................................................................. 66
2. Android .............................................................................. 66
Post Project Review Document ............................................................ 67
1. Review ............................................................................... 67
2. Future of the Project .............................................................. 68
3. Minutes of Meetings ............................................................... 69
Bibliography .................................................................................. 73
Further Reading ........................................................................ 74
6. Table of Figures
Figure 1 Percentage of apps by category in Apple App Store (Apptizr 2010) ......... 9
Figure 2 (Distmo Report Q3 2010, pg 3) .................................................. 10
Figure 3 Distribution of Android releases currently active (Android, 2010) ......... 11
Figure 4 Percentage of game sold on Android Market. (Androlib, 2010) ............ 12
Figure 5 A simple mock up of how the game interface might look. .................. 15
Figure 6 a high level game architecture .................................................. 16
Figure 7 components of the application layer ........................................... 17
Figure 8 components of game logic layer ................................................ 17
Figure 9 representation of the game view for human player ......................... 18
Figure 10 representation of game view for AI agent ................................... 19
Figure 11 the XNA game loop .............................................................. 23
Figure 12 process of the XNA content pipeline .......................................... 25
Figure 13: Main screen options ............................................................ 26
Figure 14: System Model .................................................................... 30
Figure 15: Game Play Use Case Diagram ................................................. 31
Figure 16: Detailed Game Play Use Case Diagram ...................................... 31
Figure 17: Enemy AI Use Case Diagram ................................................... 32
Figure 18: Defensive Structure AI Use Case Diagram ................................... 32
Figure 19: Activity for the Standard Game Loop ........................................ 32
Figure 20: Question 1: Age Group ......................................................... 42
Figure 21: Question 2: Type of Handset Owned ......................................... 42
Figure 22: Question 3: Regularity of Mobile Games Played ............................ 42
Figure 23: Question 4: Average Time Spent Playing Mobile Games .................. 42
Figure 24: Question 5: Importance of Story in Mobile Games ......................... 43
7. Figure 25: Question 6: Cut Scenes Watched or Skipped................................ 43
Figure 26: Question 7: Favourite Game Genre .......................................... 43
Figure 27: Question 8: Number of Mobile Games Downloaded ........................ 43
Figure 28: Question 9: Number of Mobile Games Paid For............................. 44
Figure 29: Question 10: Average Price (in Euros) Paid for Games .................... 44
Figure 30: First Cut Class Diagram ........................................................ 44
Figure 31 Test Logs .......................................................................... 64
Figure 32 Bug reporting ..................................................................... 64
Figure 33 Application Deploymenjt Screen .............................................. 66
Figure 34 Main Menu Screen ................................................................ 67
Figure 35 Gameplay Screen ................................................................ 67
8. 1. Abstract
Mobile devices have become an important sector for game development. The app
store business model allows low budget, small scale development companies to
develop, distribute and monetize games. This document will research and outline
the design and development process for a game on a mobile platform. The focus
will be on comparing and contrasting the process for developing a game for the
Android and Windows phone 7 platforms.
2. Introduction
This document will explore the design and development paradigms specific to
games development and how these are supported by the Android and Windows
Phone 7 platforms. The most sensible approach to this is to develop the same
game for each platform. To begin there will be a brief description of the current
market for mobile games followed by details of the kind of game that will be
developed.
Currently Apple is one of the biggest players in the smart phone market. An article
published by Reuters (Carew & Madway, 2010) reported that over 50 million
iPhones have been sold since the first release in 2007. Apples App Store was
launched on July 11th 2008.
The analytics firm Flurry (Farago, 2010) estimates there are currently over 150,000
applications available for download on the app store with 250 new applications
being added each day. The revenue generated is substantial. In the month of
December 2009, $250 million USD was generated. Apple takes 30% of revenue and
developers receive the remaining 70%. In that one month apple earned $75 million
USD. Developers earned $175 million USD.
A large percentage of this revenue was generated by games. The company Apptizr
have created an application that helps users to search and download from Apples
App Store. The application is provided free of charge and allows the company to
gather data on what their users have downloaded. This graph provided by Apptizr
gives information on what category of applications are being downloaded the most
by their users. This graph puts the figure at a modest 28% although some estimates
put the figure as high as 65% (Chen, 2009).
9. Figure 1 Percentage of apps by category in Apple App Store (Apptizr 2010)
Figure 2 from a report published in September (Distimo, 2010) shows the
percentage of games in the top 100 downloads for the largest mobile application
stores. The Android market is not included here because Google has different
categories for games and applications.
10. Figure 2 (Distmo Report Q3 2010, pg 3)
The Apple, App Store is a precursor to the Android Marketplace and the Windows
App Hub. It is reasonable to speculate that the trends shown here should continue
for other mobile application marketplaces and, that games will continue to be an
important source of revenue for mobile companies. The question being
investigated here is what importance has been put on games development by
Android and windows phone 7 and which platform provides the best support for the
development process.
3. The Android Platform
The Android marketplace was launched in 22nd October 2008 (Chu, 2008). Google
became one of the biggest players in global technology market very rapidly. This is
even more impressive as they are now competing against the long term market
standings of Microsoft and Apple (Parr, 2010). Each company is now in direct
competition however it could be said that each has gained success and innovation
through that competition. The entry of these three companies into the mobile
marketplace has led to some very interesting developments for consumers and
developers alike.
The entry of Google into the Smartphone market to compete with Apple was a
welcome development. Google has a good reputation with developers aided by its
support for open source projects and extensive free education resources. This has
helped Android to become a very popular platform for developers of all levels. In
contrast the iPhone is notoriously hard to develop for but is hugely popularity.
11. Innovative design and near perfect user interface ensures that iPhone applications
will continue to be developed in large volumes for some time to come. Many
developers complain that objective C is far behind with regard to productivity but
at least developers can be sure of the hardware they are developing for. Android
allows you to develop with managed code using a version of java run in the Dalvik
virtual machine or with native code using the NDK. The Dalvik virtual machine is
functionally similar to the java virtual machine. It converts the java programming
language to byte code which has been optimized for mobile devices.
Android was not the perfect answer that developers had hoped for and there have
been many issues with Android as a development platform. The main complaints
are
Too many release versions of the operating system are available
Too many different devices with different input options and specifications
A poorly designed marketplace
Figure 3 Distribution of Android releases currently active (Android, 2010)
Figure 3 is provided by the Android developer network and gives a breakdown of
the different operating systems currently deployed in the market. Developers have
to consider which version to target. Targeting the earlier releases 1.5 / 1.6 has its
advantages. All later versions are backward compatible so more users will be
eligible to purchase the application. If they wish to use the more advanced
features of later versions then a large portion of the possible customer base is
removed. For the purpose of this project version 1.5 will be targeted. This will
ensure compatibility with most Android devices.
12. Figure 4 Percentage of game sold on Android Market. (Androlib, 2010)
Figure 5 (Adrolib, 2010) shows percentage of games downloaded by Android users
is generally much lower than users of Apples App Store. This is predicted to change
as bigger developers come on board for Android. There are different reasons given
to explain the low market activity of Android games. One is perhaps people who
buy Android devices just aren‟t big into games. Another is maybe it is just very
difficult to make good games for Android. This is a topic that will be explored
further throughout this project. One thing that should not be disregarded by game
developers is that in the short time Android has been available the number of
Android handsets being sold has overtaken the number of iPhones being sold
(Tofel, 2010).
4. The Windows Phone 7 Platform
Windows Phone 7 was officially launched on October 11th 2010 (Garza, 2010). There
is a lot of debate on how successful this smart phone OS will be. Microsoft has
brought about some interesting ideas and handset requirements that could be very
useful for both consumers and developers alike. All windows phones will have a
minimum hardware specification which means that developers can be sure any
phone their application is deployed on will have at least these required features.
13. The requirements are
Capacitive touch screen with four or more contact points
Two possible screen sizes and resolutions - 4.3 inch (800x480) and 3.4 inch
(480x320)
Sensors: A-GPS, Accelerometer, Compass, Light, Proximity
Camera that is 5 megapixels or more, flash required and dedicated camera
button required
Three dedicated hardware buttons - Start, Search, and Back
Memory: 256MB RAM or more with 8GB flash or more
GPU: DirectX 9 acceleration
CPU: 1GHz ARMv7 Cortex/Scorpion or better
Developers have two choices of framework to develop applications. For
applications there is Silverlight 3.0 and for games there is XNA 4.0. C# is the only
supported language although some support has been introduced for Visual
Basic.NET. All development can be done in Visual Studio 2010. There is good
support for developing Silverlight applications in Expression Blend 4.0.
There is no doubt developing applications for the windows phone will be easier
than for iPhone or Android. Windows phone is also the only operating system that
was released with a development platform specific to games which is interesting.
The question now is will people buy the devices and will the operating system
stand up to the scrutiny of a very competitive market. It is worth noting that
developing games using XNA allows for multi platform targeting. This means that
developers can create the same game for Windows Phone 7, Zune, Xbox 360 and
Windows PC without much extra effort. This will almost certainly make Windows
Phone 7 a popular platform for game developers.
14. 5. Developing a Game
The game should have enough scope to explore most of the resources available for
game development on each platform. 3 dimensional graphics and networked
multiplayer will not be included for the initial game design.
5.1 Game Concept
The name chosen for the game is Nathaniel. This is the name of the main
character.
The story for the game is set some time in the future. Most of humanity has been
wiped out by a cataclysmic event. Those that have survived are now hunted by
hordes of zombies, werewolves and other undesirable characters. Where these
have come from nobody knows. One man named Nathaniel has made it his mission
to cleanse his homeland of these beasts. Although a formidable warrior himself
Nathaniel has an invaluable sidekick. A legacy from a better world in the form of a
highly advanced robot named Hermes. Hermes has the ability to construct objects
by consuming large amounts of biomass materials and restructuring the molecules
into complex devices and structures. The structures he can build depend on what
he has schematics for. The original purpose of the Hermes design is unclear but
now Nathaniel feeds Hermes dead monsters to give him the resources to build.
The game will have a number of levels where the player will face different
challenges. The strategy in the game is to build the right kind of defences to
combat different monsters while ensuring you are not overrun. Nathaniel and
Hermes must survive and all enemies must be eliminated. Occasionally the player
will have to protect NPCs (non playable characters). The ultimate goal with
regards to the story is to find the source of all these monsters and to destroy it.
The game play is a simple action, strategy mix. During an action sequence Hermes
the robot will be immobilised to allow for building defences. Without building
defences the player will not survive. Hermes does have a short range laser weapon
to provide a last line of defence. The player will constantly be taking risks to
acquire resources for Hermes which involves picking up dead enemies and
delivering them for consumption. Nathaniel also has the ability to fight monsters
himself. As the game goes on the option of learning to build new structures or to
improve Nathaniel in some way will be offered.
15. Graphically the game will have a simple 2 dimensional top down view. Layered
images will be used for the background and sprites will be used for most visual
objects in the game.
Health bars Hermes &
Nathaniel Other information such as resources
Defensive
structure
destroying
an enemy
Figure 5 A simple mock up of how the game interface might look.
All interaction will be through touch screen. This is the one form of input that is
guaranteed on all Android and Windows 7 phones. The graphical user interface will
be very simple. Nathaniel and Hermes are selectable by touch. Nathaniel moves to
wherever the user touched the screen. If there is an enemy there Nathaniel
attacks. If there is a dead enemy there he will harvest. When Hermes is selected a
menu will appear with build options. Selecting an option will allow the user to
place and build that object by touching an area of the screen.
The user will only get one life per level. Dying restarts the level. Nathaniel and
Hermes will have energy levels that will recharge slowly if they have been
depleted.
5.2 Game Architecture
This section will explore best practices followed by game developers when
designing a game architecture.
16. The Game
Application Layer
Logic
View
Figure 6 a high level game architecture
When designing the architecture for most games the Model-View-Controller design
pattern is best suited with an added layer for hardware subsystems (McSaffery,
2009).
5.2.1 Application Layer
The application layer deals with devices, operating systems and the game lifetime.
This is where input and memory is managed. The game is initialized and shut down
in the application layer.
17. The Game Application Layer
Operating Game
Devices
System Lifetime
input DLL Main Loop
Inititalize and
Files Threads
Shutdown
Files Network
Language
Figure 7 components of the application layer
In theory the application layer should be the only part of a game that changes
across devices and operating system.
5.2.2 Game Logic
Game Logic Layer
Game Physics Events Process Command
State & Manager Interpreter
Data
Structures
Figure 8 components of game logic layer
18. Game logic is where the life of the game resides. This is where the game world or
universe is defined. Each objects existence in the game world and how it acts and
interacts is defined here.
Depending on the complexity of the game different data structures will be used to
store all the game objects. This is an area where big O evaluations may come in
handy. Developing for a mobile device requires the developer to consider what
memory or processing overheads are acceptable. During the design phase questions
must be asked. Is a binary search necessary or not in a given situation? Are hash
tables the way to go or a flat search 2D array? Does a structure need to be
searched more efficiently or have more flexibility.
Game states store state information such as player health, player scores and the
position of objects to be drawn to the screen.
Events are used to determine what happens when the player or AI interact with
anything else in the game.
The process manager keeps track of all the pieces of code that are running and
allocates a little CPU time to each. How much the developer is involved in this
depends on how much control over the system is allowed.
The command Interpreter takes input from the human player as well as action
from the AI and decides what to do with it.
5.2.3 The Game View
The game view relates to the graphics and sounds a player sees as well as handling
all interaction with the game.
Game View - Human
Input Process
Display Audio Options
Interpreter Manager
Figure 9 representation of the game view for human player
19. It is fairly standard that in large scale game projects most of the budget could go
on graphics. Performance is paramount here as inefficiencies affect a games fps
(frames per second) which is a big issue for hardcore gamers. Many people will also
buy games based on how good the graphics look. If a company spends 30 million on
a game they should be able to advertise it like it is a movie. For mobile devices
great graphics are not an absolute requirement. Following good practices in this
area is still important with regards to performance. The main focus here will be on
researching how well graphics are supported in each platform. Importance will also
be placed on designing a good user interface and developing the art to have an
attractive looking game.
Audio can also be as much a part of a games experience as the graphics. I recently
played medal of honour and noticed how impressive the level of noise was in the
midst of a battle. A high level of realism was represented. The budget for the
audio alone must have been huge. Audio for a mobile game may not be such an
important factor. How well various types of audio such as sound effects and music
are supported on the different mobile platforms will be investigated.
The view process manager is similar to the one in the application layer but controls
functions like button animations and media streaming.
Most games should have options. Players like to customize their experience.
Options such as difficulty or changes to sound effects are always a good idea if
possible.
Game View - AI
Stimulus Decision Process
Options
Interpreter System Manager
Figure 10 representation of game view for AI agent
The game view for the AI is similar to the game view for a human although the AI
doesn‟t need any visual or audio information. The artificial intelligence agents in a
20. game should react to stimulus and the game world should react to AI agents. These
interactions should be similar to interactions between the human player and the
game world even if the AI agents have very different properties and abilities.
For the purpose of this project the AI will not be overly intelligent. The AI program
will fulfil its purpose for this game. It will also test the performance and support of
each development platform for gaming AI.
6. Developing Games for Android
Game developers for Android recommend that anyone wishing to make a good
game for the Android Marketplace should start with a good knowledge of game
development, excellent Java, C++, OpenGL and C programming skills as well as
reasonable knowledge of Linux and Shell scripting (Silva, 2010).
6.1 Native Code
Using Native code and having to get the GNU Tool chain for ARM Processors to use
C is a lot of work. Developing custom compilation scripts and using hybrid graphics
with OpenGL and JNI offers a lot of flexibility but is difficult for a beginner to
game programming. Where performance is important as it usually is with games
these tools should be used. For this project the game will be developed entirely in
Java. This makes sense for testing the platform as Java is the main language
supported and Android specific APIs will be used.
6.2 Java
Developing a game in Android is not the same as developing a game in Java ME.
Android doesn‟t use the standard Linux Kernel. Android doesn‟t use a native X
Window system and it doesn‟t support standard GNU libraries. This reduces code
reusability form Linux applications.
Androids version of Java running on the Dalvik virtual machine is not the same as
the Java generally in use. The standard Java SE and Java ME are not supported.
Not all the usual Java APIs, classes and libraries are provided for use on Android
while some custom Android APIs are used instead. This means that is not too likely
you could take an existing game built in Java ME and easily deploy it on Android
without a good amount of modifications first. The development process for Android
is similar to building any other application in java however and all the main
features and object orientation can be used.
6.3 Android Game Architecture and considerations
The screens in any Android application are called Activities. As a simple example
take the main game activity for the project called Nathaniel.java which extends
Androids Activity.java. This would retrieve and load the game layout mostly from
an XML file. The activity also processes events. There would be an abstract class
called Game.java or StrategyGame.java. This class provides common functionality
21. and defines the game loop. NathanielGame.java extends StrategyGame.java and
would provide most of the core functionality.
XML Nathaniel.Java <Activity> Phone
UI Screen
draw()
NathanielGame.java
<StrategyGame>
Invalidate view
StrategyGame
<LinearLayout>
Timer Task
For graphics in a java game built for Android, OpenGL should be used although the
processing libraries from processing.org could possibly be used in certain cases. It
is recommended to use OpenGL ES 1.0 (Pruett, 2010) to allow for good
performance and support for most Android releases and devices. Fortunately there
is a class GLSurfaceView.java that make handling OpenGL in java a lot easier.
That covers the structure of a game written in Java for Android and the graphics
library that will be used. What other considerations should be taken into account
when planning to build a game for Android?
Chris Pruett (2010): “Before you get too deep into your epic ragdoll physics-based
space marine action online RPG with branching endings and a morality system,
take a minute to think about your end users. Specifically, there are two areas
that require consideration for Android games that you might not be used to:
texture compression and input systems.”
The iPhone has one button. That‟s it. If the user presses it your game or
application is mercilessly killed. Touch screen is the only input a developer has to
plan for. With Android things can be a little bit more complicated than that.
Android have a Compatibility Definition Document which states that all Android
devices that have Android Marketplace are required to have a touch screen and
three-axis accelerometer. Developers have this guarantee. Some phones are
primarily touch screen, possibly with multi-touch. Some will have keyboards,
trackballs or directional pads. A game developer does not have to design for all
these inputs but it is good practice to at least try and include some of these as an
option.
Compressing textures sounds like a great idea but for my project I will avoid that
idea entirely. On the Android developer site they say compressing texture data can
22. improve draw performance and allow you to put more textures into vram.
Unfortunately different graphic card vendors support different texture formats.
The three main compression formats supported are ATITC, PVRTC and DXT. These
are singularly supported by different devices. All OpenGL ES 2.0 devices support
the ETC1 format but targeting these devices reduces the target market
dramatically. I will stick to using OpenGL ES 1.0 for this project and avoid using
texture compression. For a game of this level it should make little or no
difference.
7. Developing Games for Windows Phone 7
Game developers are given two framework options for developing games on WP7
(Windows Phone 7). One is Silverlight 3 the other is XNA 4.0. Native APIs are not
permitted yet. Although there are two distinct platforms on windows phone they
do often have to interact. For example for location, vibration and accelerometer
controls are provided by Silverlight to XNA. Silverlight also has access to much of
the XNA framework.
7.1 Silverlight
While Silverlight is not designed for game development it can still be the right
option for some games. It is perfect for 2 dimensional turn base strategy games.
This covers games like Chess, Draughts or Monopoly. It is also great for many
puzzle games. The ability to design the interface and much of the graphics in
Expression Blend 4.0 is a boon to many developers. It is actually quite possible to
create a simple puzzle game without knowing how to code at all. Story boarding in
expression blend allows developers or designers to create animations and events
entirely through the editor created declaratively in XAML. When complicated game
logic, large resource management and time critical updating and drawing are not
necessary and where speed and performance is not critical using Silverlight is a
good and easy way to make a game.
7.2 XNA
During the Windows Phone 7 developer launch 12th October 2010 XNA Kenny Spade
jokingly stated that XNA stands for XNA is Not an Acronym. It appears that the
name came about by accident and that there is no real meaning for it. It is the
name of the game development platform Microsoft. XNA is different to Silverlight
in that creating a user display such as a menu and some minor animations takes
about 20 times longer. Despite this most games will be made using XNA.
This is because XNA provides a wealth of resources and libraries to aid in game
development. Creating a new XNA WP7 game project will provide you with all the
start-up code needed to begin making a game. If you run the project without doing
anything at all it will give you a plain blue screen (Kenny Spade referred to this as
the blue screen of life).
23. This is very useful because without any work done by the developer the XNA
GraphicsDeviceManager sets up the screen size. Although nothing visually is
happening the game is running in a loop and updating already.
7.3.1 XNA Game Architecture
The default class provided when you build an XNA game project inherits the
Microsoft.Xna.Framework.Game class. Once the Game is created there is a set of
steps carried out by default.
GraphicsDeviceManager is created first to handle the display.
The inherited Initialize method from the Game class is then called. This
method can be overriden to query for services and load non-graphics
resources.
Next Load Content is called. This is used to load any graphical content
required by the game.
Once everything is loaded the game loop can begin. The methods Update
and draw are called continuously. They are passed a GameTime object as a
parameter. GameTime is the time passed since the last call to the
respective methods. This allows update and draw to keep track of where the
game is at.
Finally the UnloadContent method is called. This is where the game unloads
all content to free up any resources used by your game. This is done once in
the game lifetime.
Figure 11 the XNA game loop
24. Update is the method used to handle changes in the game state. Draw will
represent the changes handled by update and draw them to the screen. Update
and draw can be set to run at different rates. The game class has a property
IsFixedTimeStep which is a bool. If it is set to true Update and Draw will be called
as often as resources allow, in the order Update and then Draw. If IsFixedTimeStep
is false Draw will still be called as often as possible but update will be called at an
interval set by the TargetElapsedTime property of the Game class which is a
TimeSpan property.
XNA provides you with all the logic to start a game running for free which saves
time. There are many other interesting facilities provided which will now be
outlined in a description of the XNA framework.
7.3.2 What is in XNA?
Resources available from XNA for WP7:
Audio – Allows sound effects play audio and get input form a microphone.
Content – The content Pipeline manages game content and will be discussed
further in this document.
GamerServices – For interaction with gamer i.e. gamer data, profile etc.
Graphics – Graphics API with hardware acceleration and support for 3
dimensional objects.
PackedVector – is a new in XNA 4.0 which allows components that are not
multiples of 8 bits.
Input.Touch – Allows input on the WP7.
Media – Has many classes for sounds and images. This is used to allow access
to large amounts of media. The msdn library states the Media classes are
used to enumerate, play and view songs, albums, playlists and pictures. This
is very useful if a game is going to have a lot of content although for a
windows phone game the content should be kept to a minimum.
Net – Game networking
Storage – Classes for reading and writing files in storage.
7.3.3 Rendering
XNA uses profiles to allow developers target the same game to WP7, XBOX 369 and
Windows PC. Reach and HiDef are the two profiles. HiDef allows for very
impressive graphics while Reach allows more devices to be targeted. It is most
likely that in developing for a phone the Reach profile will be used.
There are configurable effects available in both profiles. The classes used and
their main properties are
BasicEffect – basic rendering effect
SkinnedEffect – configurable rendering of skinned character models
EnvironmentMapEffect – configurable effect for environment mapping
DualTextureEffect – configurable effect for two-layer multitexturing
AlphaTestEffect – configurable effect for alpha testing
25. XNA provides huge resources and methods to allow graphics to be rendered
relatively easily. Hardcore game developers will probably prefer to have direct
control over directX but small scale developers will be happy with the ease of
development provided by this level of abstraction through the XNA APIs.
7.3.4 Content
The content pipeline is used in XNA to bring content form the assets folder into the
game.
Figure 12 process of the XNA content pipeline
The four main components of the Content Pipeline are importers, Processors,
Writers and Readers. These are very useful tools for game development. They
support using XML file for content in a game, processing built in data types, custom
data types and sharing data types between build and runtime.
8. Conclusion
This is an intriguing time to be developing mobile applications. Many of the
operating systems are still new but maturing all the time. The development
platforms are interesting to use and full of potential. Eventually the application
market may reach a level of saturation making it very difficult for developers to
see any rewards. Mobile technology may improve to the point where game
companies will be allocating huge budgets for mobile development. For now
however the sector is a rich area for individual creativity and innovation. This
project will explore to what extent two of the major mobile platforms encourage
innovation and how much support there is for a small scale developer to form a
concept into good software.
26. Requirements Analysis Document
1. Preface
This document is the summary of requirement analysis and general information for
the proposed mobile game called “Nathaniel”. The game will be developed for the
Android 1.5+ and Windows Phone 7 XNA platforms. The game genre is real time
strategy (RTS).
2. Game Specification
Figure 1 shows the options a player will be presented with when the game is run.
Figure 13: Main screen options
2.1 Game Play
The gameplay is simple real time strategy. The player will control two characters
within the game, Nathaniel and Hermes. This is the specification of what actions a
player may perform. All these actions assume that the respective character is
currently selected.
2.1.1 Nathaniel:
Move – the character can move to any unoccupied area of the screen.
Attack – the character can attack enemy agents in the game. Nathaniel will
have 2 weapons. A ranged and a melee. The ranged weapon will have a
maximum range which may be upgraded as the game progresses. When
Nathaniel is issued an attack order he will move to attack. As soon as he is
in range he will begin firing automatically. If an enemy is within melee
range Nathaniel will switch to melee attack. Each attack has different
attributes which may change throughout the game.
Gather resources – the character must pick up dead enemies and deliver
them to Hermes for processing. Resources are gathered by selecting a
corpse. Nathaniel moves to corpse and picks it up. While Nathaniel is
holding the corpse the player must select Hermes. Nathaniel will move to
Hermes and deliver the corpse. This provides the player with resources to
build structures. Each category of enemy provides different amounts of
27. resources. Once an enemy is dead there is a limited amount of time before
the corpse disappears and its resources can no longer be retrieved.
2.1.2 Hermes:
Move – at certain points in the game Hermes will be allowed to move. The
move command is not available during battle sequences. Hermes must
remain stationary to build structures and to use his defensive laser. During
battle sequences Hermes is essentially a base structure.
Build structure – when Hermes is in battle mode a menu will appear with a
view of what structures are currently available to build. As the game
progresses more structures will become available. Each structure will have a
cost. If the player has enough resources available, displayed buildings in the
build menu will have a bright background and may be built. If enough
resources are not available the buildings will have a grey background and
may not be built. Hermes can materialize structures at a large distance so
structures can be placed almost anywhere in the game area that is not
already occupied.
The player must rely on these actions alone to complete the game. The player
has no control over any defensive structure once it is built. The player cannot
command Hermes to attack. Hermes‟ defensive laser is automatic.
2.1.3 Game Flow Design
The game flow structure is broken down into four chapters. Each chapter
contains levels. The final level of each chapter contains a boss. On completion
of the four chapters the game is complete.
Each level will have win and lose conditions. In general the main lose condition
will be a main characters death. The player loses when Hermes or Nathaniel
has lost all their health points from enemy attack and that character dies.
Some levels may be timed or require the player to protect a non-playable
character (NPC).
In general the win condition for each level will be to eliminate all enemies.
Other win conditions may be introduced such as gathering a certain amount of
resources or surviving a certain amount of time. Once a chapter or the entire
game is completed the player will be given the option to upload their high
score.
2.2 Options
The player may edit certain game options. These options are accessed by selecting
the options button in the main menu. The player can change the sound effects
volume, the music volume and the game difficulty options in this screen.
28. 2.3 Hall of Fame
The player can select the Hall of Fame option in the main menu. This allows the
player to view the top scores of all players who have uploaded their high scores.
2.2 Functional Requirements
For the overall system:
When game application is loaded main screen must be visible.
Options must be editable.
Options must be saved once edited.
Game client must send game score data to web service.
Game client must receive high score data from the web service.
High scores must be visible when the hall of fame option is selected.
Game must play when play game option is selected.
Game must load saved game if continue game option is selected.
Game must save at certain intervals.
Once a win or lose condition is met the current game must end.
For the gameplay:
Nathaniel must be moveable.
Nathaniel must attack when given an appropriate target.
Nathaniel must pick up corpse if given a corpse as a target and is at the
corpse position.
Nathaniel must deliver corpse if given Hermes as a target and Nathaniel is
holding a corpse.
Nathaniel cannot attack when holding a corpse.
Nathaniel drops corpse if attacked or given an attack order.
Hermes may only be moveable at certain stages in the game.
When Hermes is moveable he may not attack.
When Hermes is moveable there will only be two commands available. Move
and enter battle mode. Entering battle mode will cause Hermes to become
stationary and will change commands available.
When Hermes is stationary selecting him will cause the build structure
options to be displayed.
When Hermes is stationary he will have the ability to process enemy corpses
and convert them to resources.
29. When Nathaniel delivers a corpse to Hermes the corpse is processed
automatically.
Processed resources are added to the players‟ total resources and the new
total will be displayed in the heads up display (HUD).
Resources are used to build structures.
Resources are also used to help calculate player score.
Structures that are available to build in the build structure menu depend on
the amount of resources available and what structures the player has
unlocked.
All game agents must lose health points when attacked proportional to the
attack power of the attacker.
When any game agents health points value = 0 that agent must die.
For the AI:
Defensive structures are stationary.
The attack function is activated when an enemy comes within range.
The target is chosen depending on the attack level of all enemies in range.
The agent with the highest attack level will be seen as the highest threat
and attacked first.
Enemy AI agents in the game also use the threat level targeting system.
Generally Nathaniel will have the highest threat but some structures may
have a higher attack power and be targeted first.
Once an enemy AI agent has acquired a target they will move towards that
target until they are within their specified attack range.
Other requirements:
For a game to be playable a minimum frame rate of 30 frames per second is
recommended.
For high scores to be uploaded and viewed a connection to a web service must
be established. Files must be transferred in an acceptable data format i.e.
JSON, XML.
2.3 Non Functional Requirements
The game is designed specifically for mobile devices. There are many non-
functional requirements which do not affect the game logic but do affect the
games viability for running on a mobile device.
Battery life - game code must be optimized to reduce the amount of
processing and rendering that must be performed.
30. Memory – memory is very limited on mobile devices and there are many
ways to reduce the amount of memory a program uses by optimizing code.
Touch screen input – the game design may allow for many different types of
input but initial implementation will only allow touch screen input as this is
standard to both target devices.
3. System Model
This is a high level representation of the proposed game system.
Figure 14: System Model
Figure 3 shows the basic actions that are performed by the player during
gameplay.
31. Figure 15: Game Play Use Case Diagram
Figure 4 gives a more detailed view of how the system operates during gameplay.
Figure 16: Detailed Game Play Use Case Diagram
32. Figure 5 shows the functionality used by the games enemy artificial intelligence
agents. Each enemy may have different attributes but all will follow this
functionality.
Figure 17: Enemy AI Use Case Diagram
Figure 6 shows the behaviour of defensive structures that have been placed by the
player.
Figure 18: Defensive Structure AI Use Case Diagram
Figure 19: Activity for the Standard Game Loop
33. 4. Use Cases
System Use Cases:
Title: Play
Actor (s): Player
Goal: When the player selects „New Game‟ or „Continue Game‟
from the main menu and the game initializes.
Overview: This is a high level use case indicating that the player
has started the game and the system has initialized the
game loop. The majority of the systems functionality is
contained within the play use case.
Pre-Conditions The player has selected “New Game” and started a new
game.
or
The player has selected “Continue Game” and
successfully loaded a saved game.
Post-Conditions Play has ended with a Win, Lose or Save condition and all
relevant data is recorded.
Successful Scenario:
1. Game play begins at correct point if saved or at beginning if new
game.
2. All functionality is present in game play.
3. Game play ends when game end condition is met
Title: Watch
Actor (s): Player
Goal: Game displays story information to player
Overview: This is a high level use case which shows that a player
can watch cut scenes during the game. These are very
simple scenes to provide story information to the player.
All cut scenes can be skipped.
Pre-Conditions Cut scene is initiated by game.
Post-Conditions Cut scene time has expired.
Or
Player has selected skip to end scene.
Successful Scenario:
1. Cut scene is displayed to screen.
2. Player watches cut scene or skips it.
3. Cut scene ends and game continues.
34. Title: Update Options
Actor (s): Player
Goal: Allow the player to change sound effects volume, music
volume or difficulty options.
Overview: This use case represents the players‟ ability to change
options that are standard in most games. Sound effects
volume, music volume and game difficulty can be
modified by the player.
Pre-Conditions Player has selected „Options‟ from the main menu.
Post-Conditions Any changes have been saved.
Successful Scenario:
1. The options screen is displayed.
2. Player can increase or decrease sound effects volume by sliding the
selection bar.
3. Player can increase or decrease music volume by sliding the selection
bar.
4. Player can increase or decrease game difficulty by sliding the
selection bar.
5. Any changes are saved.
Title: Upload High Score
Actor (s): Player
Goal: Data regarding the players‟ high score is sent to the
game web service and saved there.
Overview: This use case occurs when the player has completed a
chapter in the game as well as when the player
completes the entire game. The player will be given the
option to upload their current score.
Pre-Conditions A game chapter has been completed or the entire game
has been completed.
Post-Conditions Server has received the data and saved it.
Successful Scenario:
1. Player completes a chapter/game.
2. Button appears asking player if they wish to upload their score.
3. Button is pressed and a dialogue appears indicating the data is being
sent.
4. Player receives a response indicating their current ranking.
35. Title: View High Scores
Actor (s): Player
Goal: Display global high scores to player.
Overview: The player can view high scores by selecting the „Hall of
Fame‟ option in the main menu. The high scores are
downloaded from the game server and displayed in the
hall of fame screen.
Pre-Conditions Player selects „Hall of Fame‟ option in main menu.
Post-Conditions Global high scores are downloaded and displayed to
player.
Successful Scenario:
1. Player selects the „Hall of Fame‟ option in main menu.
2. The hall of fame screen is displayed.
3. High score data is requested from server.
4. If there is connectivity download high scores.
5. Display high scores.
6. If there is no connectivity display most recent high scores.
Title: Save
Actor (s): Player
Goal: Save game progress to persistent storage.
Overview: During gameplay the player will have the option to save
the game. Although the game will automatically save at
certain points the option to save will still be provided.
Pre-Conditions The game is running and in play mode.
Post-Conditions The current game state is saved to persistent storage.
Successful Scenario:
1. Player selects save option.
2. Current game state is saved to persistent storage.
3. Player returns to game or exits game.
36. Title: Load
Actor (s): Player
Goal: Load a saved game state and begin gameplay from that
point.
Overview: Once the player has played the game and the state of
that game has been saved the „Continue Game‟ option
will be available. This will load the most recent saved
game.
Pre-Conditions There is a saved game in persistent storage.
Post-Conditions The game loads at the point specified in the saved game
with all the correct data.
Successful Scenario:
1. Player selects „Continue Game‟ from the play game menu screen.
2. Loading dialogue appears.
3. Game begins at the point specified in the saved game file.
4. The game state is exactly as it was when the game was saved.
5. Player can continue playing the game from this point.
Title: Receive High Scores
Actor (s): Web Service
Goal: High scores are received from any game that sends them
and are stored on the server.
Overview: The web service should receive data from any game that
attempts to upload the data. This is used to provide
global high scores to all games that request them.
Pre-Conditions Game client must connect to web service and request
the service accepts the data.
Post-Conditions Web service receives data and saves it to the high scores
database.
Successful Scenario:
1. Game client sends HTTP request to deliver high score data.
2. Web service responds and accepts the data being sent.
3. Data is verified and saved to server.
4. Connection terminated.
37. Title: Provide Global High Scores
Actor (s): Web Service
Goal: Send global high scores to any game client that requests
it.
Overview: Players of the game have the option to view global high
scores in the hall of fame. The game server sorts high
scores and serves a file with the top scores in order on
it.
Pre-Conditions Game client must request the high scores resource from
the web service. There must be a high scores file stored
on the server.
Post-Conditions Game client confirms the data has been received.
Successful Scenario:
1. Game client sends HTTP request asking the web service to send the
high scores resource.
2. Web service responds and sends the resource.
3. Game service confirms data received.
4. Connection terminated.
Game Play Use Cases:
Title: Lose
Actor (s): User
Goal: End the current game if a lose condition is met.
Overview: If the player dies or some other losing condition is met
then the game must end.
Pre-Conditions Lose condition met.
Post-Conditions Gameplay is ended and continue options are displayed.
Successful Scenario:
1. Lose condition is met.
2. You Lose message displayed to player.
3. Options to continue from last save or exit to main menu are
displayed.
38. Title: Win
Actor (s): Player
Goal: Current gameplay is stopped and the game continues to
the next level.
Overview: Once a win condition is met such as all enemies in a
certain level are eliminated then the current gameplay
should be exited. A message and the options to continue
or retry level will be displayed to the player. The game
will automatically save.
Pre-Conditions Win condition is met.
Post-Conditions Current game play is ended.
Game is saved.
Option is displayed to continue or retry level.
Successful Scenario:
1. Level is won by win condition being met.
2. Current game play ends.
3. Winning screen appears with options to continue or retry level.
Title: Build Defence
Actor (s): Player
Goal: Allow the player to place defensive structures.
Overview: The player can build defensive structures in the game by
selecting Hermes, selecting an available structure from
the menu and placing the structure in the game area.
Pre-Conditions Hermes is selected.
Structure is selected.
Enough resources are available to build structure.
Viable location is selected to place structure.
Build structure is confirmed.
Post-Conditions Structure is placed in the game area.
Successful Scenario:
1. Player selects Hermes.
2. Build options are displayed.
3. Options with enough resources available to build a highlighted.
4. Options that do not have enough resources to build are greyed out.
5. Player selects a highlighted build option.
39. 6. Player selects an area in the game that is available to be built on.
7. Player confirms decision.
8. Structure is placed.
Title: Attack Enemy
Actor (s): Player
Goal: Have the main character attack an enemy.
Overview: In this game once Nathaniel is selected and an enemy is
then targeted, Nathaniel will move to attack that
enemy. The attack is automatic from then on until
Nathaniel is issued with another instruction or the enemy
dies.
Pre-Conditions Nathaniel is selected and an enemy is targeted.
Post-Conditions The enemy has been attacked.
The enemy dies, Nathaniel dies or another order is
issued to Nathaniel.
Successful Scenario:
1. Player selects Nathaniel.
2. Player targets an enemy.
3. If enemy is out of range Nathaniel moves towards enemy.
4. If enemy is in range Nathaniel attacks the enemy.
5. The enemy dies or Nathaniel dies or Nathaniel is issued another
order.
40. Title: Move Character
Actor (s): Player
Goal: Move the selected character to a specified location.
Overview: The player can select and move Nathaniel to any
unoccupied area on the game screen. Hermes can also be
selected and moved when he is not in battle mode.
Pre-Conditions Character is selected and can move.
Selected „move to‟ area is not occupied.
Post-Conditions Character has moved to the selected location.
Successful Scenario:
1. Player selects moveable character.
2. Player selects area to move to.
3. Selected character moves to selected area.
Title: Increase Resources
Actor (s): Player
Goal: Add resources to the players total resource value.
Overview: Resources are used to build structures and to help
calculate high scores. The player increases their
resources by using Nathaniel to gather enemy corpses
and deliver them to Hermes. Hermes processes the
corpses and resources are increased.
Pre-Conditions Corpses have been gathered and processed.
Post-Conditions Player resources total has increased.
Successful Scenario:
1. Nathaniel picks up a corpse.
2. Nathaniel delivers the corpse to Hermes.
3. Hermes processes the corpse.
4. The players‟ total resources are updated and increased.
41. 5. Questionnaire
The questionnaire has been designed to gather some basic information on possible
system usage.
Pre-conditions:
All individuals own a mobile phone
All individuals download and play mobile games
Issues:
All those that were asked to fill out the application are acquaintances or family
members of the proposed system developer. Questions directly related to the
system would be biased by this association.
Questionnaire design:
The questions have been modelled to gather information on the general usage of
mobile games. Design issues such as level time, customisation and gameplay
complexity will be explored using the data gathered in the questionnaire. Other
more arbitrary data such as average prices paid for games and number of games
downloaded is also gathered.
Q1. Which age group are you belong to?
Under 18 □ 18 – 25 □ 26 – 35 □ 36 – 45 □ 46 - 55 □ 56+ □
Q2. Which of these categories of mobile phones do you own? (Tick more than one if
applicable)
Apple iPhone □ Android Phone □ Windows Phone 7 □ Other □
Q3. How often do you play games on your phone(s)?
Every day □ Every other day □ Once a week □ Less than once a week □
Q4. What is the average length of time you play a game in a single session?
Less than 10 minutes □ 10 – 20 minutes □ 20 – 30 minutes □ 30 – 40 minutes
□ 40 – 50 minutes □ 50 – 60 minutes □ More than one hour □
Q5. In general how important do you consider a good storyline for a mobile game?
Not important □ Somewhat important □ Very important □
Q6. Regarding mobile games you have played do you watch the cut-scenes that tell
the game story or do you skip them?
Always skip □ Sometimes skip □ Always watch □
Q7. What is your favourite game genre?
Action □ Adventure □ Role Playing (RPG) □ First Person Shooter (FPS) □
Real Time Strategy (RTS) □ Simulation □ Online Games □ Puzzle □
Q8. How many games have you downloaded for your mobile device(s)?
Less than 5 □ 5 – 10 □ 10 – 15 □ 15 – 20 □ More than 20 □
Q9. Of the game you have downloaded, how many were paid (not free) games?
Less than 5 □ 5 – 10 □ 10 – 15 □ 15 – 20 □ More than 20 □
Q10. On average what price have you paid for mobile phone games?
Less than €1 □ €1 - €2 □ €2 - €3 □ €3 - €4 □ €4 - €5 □ More than €5 □
42. 5.1 Analysis of Questionnaire Results
Twelve individuals completed the questionnaire. The results should be fairly
representative of a large portion of the target users for this application.
Here is a breakdown of the results.
< 18
18 - 25
26 - 35
36 - 45
46 - 55
56+
Figure 20: Question 1: Age Group
iPhone
Android
WP7
Other
Figure 21: Question 2: Type of Handset Owned
Every day
Every Other Day
Once A Week
Less Than Once a
Week
Figure 22: Question 3: Regularity of Mobile Games Played
Question 3 is important when considering many aspects of a games design. If
players are likely to play a game every day until they complete it then it would be
acceptable to make the game fairly complex. If a player only plays once a week it
is likely they will have forgotten a lot of the more complicated game features
when they play it next. This could lead to the end of the game on the users‟
device.
< 10
10 -- 20
20 -- 30
30 -- 40
40 -- 50
50 -- 60
60+
Figure 23: Question 4: Average Time Spent Playing Mobile Games
43. Question 4 provides another useful piece of information. If users are not likely to
play a game for much more than 15 minutes at a time then it may be a good idea
to limit the time of a game level to around 15 minutes.
Not Important
Somewhat
important
Very Important
Figure 24: Question 5: Importance of Story in Mobile Games
This information may be used to aid in decision making when it comes to deciding
what functionality is required and what can be discarded if the project is delayed.
Always Skip
Sometimes Skip
Always Watch
Figure 25: Question 6: Cut Scenes Watched or Skipped
There will be a skip option if cut-scenes are added to the game.
Adventure
RPG
FPS
RTS
Simulation
Online Games
Puzzle
Action
Figure 26: Question 7: Favourite Game Genre
<5
5 -- 10
10 -- 15
15 -- 2-
> 20
Figure 27: Question 8: Number of Mobile Games Downloaded
44. <5
5 -- 10
10 -- 15
15 -- 2-
> 20
Figure 28: Question 9: Number of Mobile Games Paid For
<1
1 -- 2
2 -- 3
3 -- 4
4 -- 5
>5
Figure 29: Question 10: Average Price (in Euros) Paid for Games
6. Class Diagram
This is a simple overview of the objects that will exist in the game. Some
modifications will be made for each development platform. For example extra
classes for handling audio may be required when developing for Android whereas
those classes are already provided with XNA.
RTSGame
Game_Entity Item Tree
CommandProcessor
+size
NathanielGame Rock
+Initialize() Sprite Agent
Buffer +LoadContent()
+Update() Level
+HealthPoints Corpse
+Draw() +isMoveable
+UnloadContent() +resources
+Attack()
+Move()
AI_Agent +Die()
GameManager ContentManager Weapon
Utilities
+GetTarget() +power
PlayerAgent
MeleeWeapon RangedWeapon
NPC Monster +range
+Hit()
+Shoot()
Grunt Boss DefensiveStructure Hermes Nathaniel
+BuildStructure()
Figure 30: First Cut Class Diagram
45. Game Design Document
1. Abstract
This document will outline the design criteria for implementing the Nathaniel
game on Android 1.5 and Windows phone 7. The goal of this deliverable is to
provide a detailed specification for the game project. This will be done using
standard object oriented design methodology and the unified modeling language.
All the game storyline, artwork and logic are uniform across platforms. The
different requirements of each platform in the development process will be
identified, elaborated on and compared where appropriate.
2. Introduction
The following section will outline some general concepts of the Nathaniel game.
Section 2 will explain the game story. This will give a specification for how the
game should progress.
Section 3 will cover the game system design. This will cover the details of actual
game development with regard to logic, storage and screen design.
Section 4 covers game play. This section elaborates on the logical and screen
design sections. Here methodologies for ensuring a good user experience are
explored.
Section 5 will give images to clarify how the title and menu screens are expected
to look. Section 6, Audio requirements, will detail any special audio requirements
and how they should be dealt with. Finally section 7 will explain the project
testing strategy, how it will be implemented and any risks involved.
2.2 Description
The game Nathaniel is a 2 dimensional game. It could be considered a 2.5
dimensional game as it will be attempting to represent a 3 dimensional world using
only 2 dimensional textures. The term 2.5 dimensional, often used to describe 2
dimensional games with 3 dimensional characteristics, has become more popular
with the increase of game development for mobile devices (Hansford, 2010).
The game will use a point and click style control interface. For the initial design
there will be eight levels. The setting is a post-apocalyptic world overrun by
monsters. The user will have control of two characters. The ultimate goal is to
survive each level and complete the game.
46. 2.3 Genre
The game genre is real time strategy (RTS). A more accurate term for the game
may be tactical role playing. The term RTS is more widely used for games of this
type however. The characteristics of a real time strategy (RTS) game will be
explained briefly. The term is credited to Brett Sperry which he apparently coined
while marketing the game Dune II (Geryk, 2008).
RTS is a strategy game which is not turn based but progresses in real time. Real
time strategy is stochastic in nature whereas turn based strategy is deterministic.
In an RTS game the participants position and manoeuvre units or structures to
secure areas and/or destroy their opponents assets (Anon, 2010).
Generally units and structures are built using resources. Resources are usually
limited and the gathering of resources is a typical feature of RTS games. These are
characteristics of the Nathaniel game determined during requirements analysis
that conform to this genre specification.
The game progresses in real time
The player manoeuvres a character to control map areas, destroy opponent
assets and collect resources
The player builds structures to control map areas and destroy opponent
assets
Resources are required to build structures
2.4 Scenario
This section will elaborate on a similar section in the requirements analysis
document by clarifying what scenarios have been decided upon and will now be
incorporated to the game.
Although there are different levels to the game the basic scenario for each level is
the same. When the game loads the world view will consist of a single area or
map. The map size may vary during the feature adding phase but for initial
development the map size will equal phone screen size.
There will be two controllable entities in the game. These are the two main
characters. The primary character is called Nathaniel. Nathaniel is essentially the
only moveable character that is controllable by the player. The player may select
Nathaniel by touching his position on the screen. The player may then touch any
position on the screen and Nathaniel will move to that position. Nathaniel can
attack enemies and collect resources.
The other controllable entity is Nathaniel‟s companion called Hermes. Hermes is a
robot and during normal game play he is not moveable by the player. The player
can select Hermes by touching his position. When Hermes is selected a menu will
47. appear with a list of available structures that may be built. The player may select
a structure and place that structure by touching an area on the screen or by
dragging and dropping a structure from the build menu. Due to screen size
restrictions and touch screen controls there may be some idiosyncrasies that will
have to be explored during prototyping and development.
That is the full list of action a player may perform. There are many variations and
restrictions which will be elaborated on throughout this document but those are
the main actions and functionality that must be considered for the implementation
of the player control interface.
The other entities that will be visible to a player during the game are the artificial
inteligents (AI) agents. These will vary in appearance and characteristics but all
will exhibit similar behaviour and functions. Each AI agent or „Monster‟ will enter
from outside the map area. Once an AI agent appears on the map they will select a
target. The target is determined by a perceived threat level. Once a target is
acquired the AI agent will attack that target until either the target or that AI agent
is dead.
Each level will have different amounts of monsters with varied levels of difficulty.
Difficulty is determined by health points (HP), speed and attack power. Attack
power is usually measured in damage per second (DPS). DPS will also be used to
determine which entity on the map exhibits the highest threat.
Another component to each level map is the structures. These will likely be the
most difficult feature to implement. Some structures may be part of the map and
only exist as obstacles. Some structure may have been built by the player. Each
player made structure will have different characteristics. All structures are
immobile. Player made structures will all have an AI component. Some will attack
enemy AI agents based on the same threat perception algorithm that the enemy AI
agent use. Some structures may heal Nathaniel. Structures on the map will
introduce the need for path finding algorithms in all moveable entities in the
game.
2.4.1 Threat Perception Algorithm
Create List of targets in range
If(list of targets.length > 0)
{
While (list of targets.length > 0)
{
Sort list by attackPower in descending order
Target = list of targets [0]
}
}
Else
{
Move to Nathaniel
}
48. 2.4.2 Path finding Algorithm
Create list of nodes
While(Target not reached)
{
Move to target
If(this node = target)
{
done
}
Else
{
If (current node not = Target & is not passable)
{
Move to empty neighbour node
}
}
}
3. Game Story
The game story begins approximately fifty years in the future. Earth has become a
relatively peaceful place with many great advances in technology although
advanced space flight has not yet been achieved. One day a massive object
appeared in the sky over Central Europe. This was an unexpected and fascinating
event. The fascination was short lived however as the object soon came crashing
to the ground. The impact wiped out most of Paris, which wouldn‟t have been too
bad, but soon after strange things began to happen around the crash site.
People began to change, rapidly. Once, normal human beings soon became violent
monster. Those that didn‟t become monsters went in to hiding or were soon killed
49. by them. Despite all the efforts made by all the counties in the world the outbreak
could not be contained. Within weeks the world was changed forever. An
apocalypse had begun.
The actual game play begins 5 years later. There are some safe havens still left on
Earth where people who appear to be immune to the strange effects of the alien
object stay together in an effort to survive. Nathaniel and his father have lived as
part of a small community where every day they are subjected to violent attacks
from the seemingly infinite number of, once human monsters roaming the land.
Thus far they have survived primarily thanks to the ingenuity of Nathaniel‟s father,
Alexander. Alexander is an inventor who once used his talents for philanthropy and
creation but now uses his talents for the creation of weapons. Alexander has
nearly completed modifications to one of his greatest constructs, Hermes.
The opening scene of the game which the player is involved in has Nathaniel and
his father out gathering food. During this sequence they are attacked. Alexander is
killed. Control of Hermes is now entrusted to Nathaniel. After the event Nathaniel
resolves himself to seek revenge for all that he has lost. He has decided to search
for the thing that has caused so much suffering to his world and put an end to it.
The rest of the game details the journey that will ultimately lead to the alien
object. The hope is that cut scenes may be incorporated into the game in the form
of simple comic strips and not animations. This method has been used in other
mobile titles and is relatively easy to implement.
4. Game System
As part of the overall system there will be three separate applications.
Android Game targeted for Android 1.5 and above
Windows Phone 7 Game built on the XNA 4.0 framework
Windows Communication Foundation 4 RESTful Web Service
50. 4.1 Model for Restful Web Service
The ability to upload and download game record data is a small part of the overall
application. Although it is does not affect the overall game play it is a common
feature of many games. Offering a player some record of achievement for their
efforts is a good way to enhance the gaming experience. This functionality will
also enable the easy addition of extra features at a later date if they are
warranted. For example the ability for players to set up an online account could be
added.
AZURE
WCF 4 RESTful Web
Service
Game Client
GetHighScore()
GetTopTen()
SendTopTen()
SendHighScore()
The online presence for the game will be hosted on Microsoft‟s cloud computing
platform, Azure. This platform is suitable for an application of this nature due to
ease of deployment, scalability and low cost.
The WCF RESTful web service will expose a single endpoint to the game client.
There will be two operations available. The web service can send or receive data
depending on the request from the game client.
4.1.2 REST Application Data
When a player completes the game they may upload their high score. This action is
elective. The client application might never connect to the WCF 4 web service but
the option is available.
Data that must be sent to the web service:
Players name
Players high score
Time taken to complete game
51. There will also be an option for a player to view a hall of fame screen in the
game. For this, data is requested from the game server. The returned data
consists of player scores uploaded from different game clients. The scores are
sorted on the server and saved to an XML file.
4.2 Persistent Storage Design
4.2.1 Save Game Data
The methods to save a games state on the Android and Windows Phone 7 platforms
differ slightly. The concept and end result is virtually the same however. When the
game is saved the object states will be written to a file in persistent storage.
For Android this is done by implementing the java.io.serialiizable interface.
For example:
Class saveGameData implements Serializable{
Data to be saved;
}
In XNA this is done by making a class serializable.
[Serializable]
Class saveGameData{
Data to be saved;
}
Using serialized classes to save a games state is a common method used in games.
During development there may be some further considerations. It has been noted
that serialization can become very cumbersome on Android devices. To avoid
complications serialization will be used but during testing but this is an issue that
should be noted. One interesting alternative is using JSON. Due to the recently
optimized Android JSON APIs it is said to be much faster (Lew, 2010). It is also
possible to GZip saved data. This could be useful if saved game data is to be stored
on a server. This is not a requirement of initial design however and may be added
as an extra feature if the schedule permits.
For Android the Context manager API will be used to read and write from internal
storage. Any file stored internally is private to the application and cannot be
modified by the user. In the case of Windows Phone 7 the EasyStorage library from
codeplex will be used to simplify storage. This library uses an API which simplifies
52. reading and writing files to Windows Phone 7 Isolated storage. The library has been
built specifically for the XNA framework.
The saved game structure will be set out in the saved game class. Simply saving
the state of every active game object is possible but importance must be placed on
keeping the save file size to a minimum. Game agents such as Hermes, Nathaniel
and any AI agents should be fully saved as objects. This is required as almost all
properties may be different to the default initialization.
Other objects can have individual properties saved such as game screens. It will
not be necessary to save all texture states for example but certain values will need
to be set differently during initialization such as current level. Loading the game
will invoke the game screen class which in turn will invoke the load level method.
A global bool value will be used by the load level method to determine if the game
is being loaded or if this is a new level. If the IsBeingLoaded property is true the
values will be read from the save game file to initialize the level variables and
objects.
This is the data that should be written to the saved game file:
Class SaveGame{
Int level;
GameTime gameTime;
Player player;
Nathaniel Nathaniel;
Hermes hermes;
ArrayList<AIAgent> enemies;
ArrayList<DefensiveStructure> structures;
}
54. 4.3 Game Play and Screen Design
4.3.3 Player Actions
This game is designed to be played on a hand held device. The screen resolutions
being supported initially are 320x480(HVGA) and 480x800(WVGA). The game play
and user input will be as simple as possible. All actions should be achievable by the
player with the use of one hand. All input is through touch screen.
There are two basic actions the player performs through touch. Select a selectable
element in the game and performing an action with the selected element.
1. Select
Selecting Nathaniel allows the player to issue orders to that
character
Selecting Hermes invokes the build structure screen
Selecting a structure from the build menu allows that structure to be
built
Only one character may be selected at a time. If Nathaniel is
selected, selecting Hermes will deselect Nathaniel. If Hermes is
selected touching any other area on the screen will deselect Hermes
2. Issue order
When Nathaniel is selected there are four orders available. Move,
attack, collect resource and deliver resource.
Selecting a structure from the build menu and placing that structure
to be built issues a build order to Hermes
Those are the only action available to the player. Any goals set for the player to
complete a level must be accomplished using only these actions. Strategy is
applied by using the correct defensive structures.
4.3.2 Defensive Structures
Defensive structures require resources. When an enemy is killed they leave a
corpse. Nathaniel can pick up a corpse and deliver it to Hermes to be processed
into resources.
The player achieves this by issuing a collect resource order to Nathaniel. Nathaniel
must first be selected. The order is issued when the player selects a corpse.
Nathaniel moves to the selected area on the screen and collects the corpse. If the
player then selects Hermes the deliver resource order is issued to Nathaniel and he
will move to within range and deliver the corpse.
Once Nathaniel is within range Hermes automatically collects the corpse and
processes it into resources. If Nathaniel is attacked or is issued an attack order
while holding a corpse the corpse will be dropped and will disappear.
55. Each defensive structure has a build cost. This cost varies depending on the
structure. If the player does not have enough resources to build a particular
structure then that structure will not be available to build in the build menu.
At the beginning if the game there will be a limited amount of structures
available. As the game progresses the player will gain the ability to build more
structures with different abilities.
The player will have to use strategy in building the correct structures for different
situations as some will be more effective against certain enemies. Other possible
effects structures will have may be to heal the player, increase defence, increase
attack or reduce enemy speed. Most structures will have a cool down time after
ability is used. For example a structure may only be able to attack in 2 second
intervals or may only be able to heal the player every 30 seconds.
4.3.3 Game AI
Most elements in the game posses some form of artificial intelligence. Hermes is
equipped with a defensive laser. If an enemy comes within range Hermes will fire
upon that enemy. Defensive structures that have the ability to attack will fire
upon an enemy that is in range. Enemy agents will attack any player agents that
are in range. If there are multiple targets in range the game AI will use a threat
detection algorithm. In game design this is commonly referred to as agro.
All enemy AI will have access to Nathaniel‟s position. When an enemy is spawned
their first action is to move towards Nathaniel. The enemy target may change
depending on the effect of the threat algorithm.
4.3.4 Win/Lose Conditions
If Nathaniel or Hermes is killed the player loses. They will then be given the option
of restarting the level or loading a saved game.
There will be different win conditions for each level. The standard win condition
will be to kill all enemies. A level may have a set amount of enemies that will be
spawned. Once all have been eliminated the level is won. Other win conditions
may be specified. Some levels may have an amount of time the player must survive
or have a certain amount of resources to be collected to achieve the win
condition.
56. 4.3.5 Normal Game Play Screen
5
1
2 3 4
7 6
1. Resource display
2. Nathaniel‟s health bar
3. Hermes health bar
4. Time
5. Menu
6. Nathaniel
7. Hermes
4.3.6 Player Being Attacked
1
1. Enemies
57. 4.3.7 Building Structure Screen
1
2
1. Defensive structure
2. Build menu
4.4 Logic Design
This section will explain what objects exist in the game system and how they
interact to make up the game. Any complex algorithms and implementation
considerations will also be discussed.
There are some notable differences in the logical design required to implement a
game on the Windows Phone 7 XNA 4.0 Framework and the Android Java platform.
The goal during design and implementation is to ensure as much code reusability as
possible. XNA 4.0 provides a huge amount of game specific classes that developer‟s
game classes should derive from to ensure stable game functionality.
For Android there is no game framework so all game functionality must be coded
from scratch. The strategy that will be used here is to develop for XNA 4.0 first.
This will essentially force a bottom up approach when developing for Android.
Functionality similar to the XNA 4.0 framework will have to be provided but be
specific to Android.
When developing for Android a DrawableGameComponent class will need to be
created. This will allow the already developed classes below to be converted to
Java relatively easily without the need to redevelop the game logic. If the game
logic was to be developed for Android first code reusability would be reduced due
to the fact that none of the classes are guaranteed to conform to the XNA
standards. Developing with XNA first will give a blueprint for overall game
development.