SlideShare a Scribd company logo
1 of 75
Download to read offline
Institute of Technology Tallaght



Comparing Game
Development for
Android and
Windows Phone 7
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
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.     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
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
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
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
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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
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
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
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).
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
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
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.
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
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.
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.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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 □
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
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
<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
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.
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
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
              }
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
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
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
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
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;

}
4.2.2 Schema for Online High Score Storage
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
       targetNamespace="http://www.nathanielgames.com"
       xmlns="http://www.nathanielgames.com"
       elementFormDefault="qualified">


  <xs:element name="player_info">

    <xs:complexType>
      <xs:sequence>

        <xs:element name="name">
          <xs:simpleType>
            <xs:restriction base="xs:string">
              <xs:maxLength value="15"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>
        <xs:element name="high_score">
          <xs:simpleType>
            <xs:restriction base="xs:integer">
              <xs:maxInclusive value="10000"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>



        <xs:element name="hours">
          <xs:simpleType>
            <xs:restriction base="xs:integer">
              <xs:minInclusive value="0"/>
              <xs:maxInclusive value="100"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>
        <xs:element name="minutes">
          <xs:simpleType>
            <xs:restriction base="xs:integer">
              <xs:minInclusive value="0"/>
              <xs:maxInclusive value="59"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>

        <xs:element name="seconds">
          <xs:simpleType>
            <xs:restriction base="xs:integer">
              <xs:minInclusive value="0"/>
              <xs:maxInclusive value="59"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:element>


      </xs:sequence>
    </xs:complexType>

  </xs:element>
</xs:schema>
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.
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.
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
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.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.
Comparing Game Development on the Android and Windows Phone 7 Platforms.

More Related Content

What's hot

Instructor utilities guide
Instructor utilities guideInstructor utilities guide
Instructor utilities guideapaezgonzal
 
SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_en
SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_enSAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_en
SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_enJim Miller, MBA
 
ARQUIVO ROUBADO
ARQUIVO ROUBADOARQUIVO ROUBADO
ARQUIVO ROUBADOD813061988
 
Open edX Building and Running a Course
Open edX Building and Running a CourseOpen edX Building and Running a Course
Open edX Building and Running a CourseAmish Gandhi
 
TopStyle Help &amp; &lt;b>Tutorial&lt;/b>
TopStyle Help &amp; &lt;b>Tutorial&lt;/b>TopStyle Help &amp; &lt;b>Tutorial&lt;/b>
TopStyle Help &amp; &lt;b>Tutorial&lt;/b>tutorialsruby
 
W java81
W java81W java81
W java81rasikow
 
Xi3 voyager userguide_en
Xi3 voyager userguide_enXi3 voyager userguide_en
Xi3 voyager userguide_enAnil Damara
 
Hibernate Reference
Hibernate ReferenceHibernate Reference
Hibernate ReferenceSyed Shahul
 
Michael Johnson's AIAA Business Jet Design Report
Michael Johnson's AIAA Business Jet Design ReportMichael Johnson's AIAA Business Jet Design Report
Michael Johnson's AIAA Business Jet Design ReportMichael Johnson
 
Hp man ppm9.20_whats_new_pdf
Hp man ppm9.20_whats_new_pdfHp man ppm9.20_whats_new_pdf
Hp man ppm9.20_whats_new_pdfugunal
 
Threading in c_sharp
Threading in c_sharpThreading in c_sharp
Threading in c_sharpTiago
 
ES410 Report
ES410 ReportES410 Report
ES410 ReportMatt Dent
 

What's hot (20)

Instructor utilities guide
Instructor utilities guideInstructor utilities guide
Instructor utilities guide
 
SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_en
SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_enSAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_en
SAP_HANA_Modeling_Guide_for_SAP_HANA_Studio_en
 
Red book Blueworks Live
Red book Blueworks LiveRed book Blueworks Live
Red book Blueworks Live
 
ARQUIVO ROUBADO
ARQUIVO ROUBADOARQUIVO ROUBADO
ARQUIVO ROUBADO
 
Open edX Building and Running a Course
Open edX Building and Running a CourseOpen edX Building and Running a Course
Open edX Building and Running a Course
 
Ppm7.5 demand cg
Ppm7.5 demand cgPpm7.5 demand cg
Ppm7.5 demand cg
 
Ppm7.5 cmd tokval
Ppm7.5 cmd tokvalPpm7.5 cmd tokval
Ppm7.5 cmd tokval
 
Tommy Marker
Tommy MarkerTommy Marker
Tommy Marker
 
TopStyle Help &amp; &lt;b>Tutorial&lt;/b>
TopStyle Help &amp; &lt;b>Tutorial&lt;/b>TopStyle Help &amp; &lt;b>Tutorial&lt;/b>
TopStyle Help &amp; &lt;b>Tutorial&lt;/b>
 
W java81
W java81W java81
W java81
 
Threading
ThreadingThreading
Threading
 
Xi3 voyager userguide_en
Xi3 voyager userguide_enXi3 voyager userguide_en
Xi3 voyager userguide_en
 
Hibernate Reference
Hibernate ReferenceHibernate Reference
Hibernate Reference
 
Hibernate Reference
Hibernate ReferenceHibernate Reference
Hibernate Reference
 
Michael Johnson's AIAA Business Jet Design Report
Michael Johnson's AIAA Business Jet Design ReportMichael Johnson's AIAA Business Jet Design Report
Michael Johnson's AIAA Business Jet Design Report
 
Hibernate reference
Hibernate referenceHibernate reference
Hibernate reference
 
Hp man ppm9.20_whats_new_pdf
Hp man ppm9.20_whats_new_pdfHp man ppm9.20_whats_new_pdf
Hp man ppm9.20_whats_new_pdf
 
Drools expert-docs
Drools expert-docsDrools expert-docs
Drools expert-docs
 
Threading in c_sharp
Threading in c_sharpThreading in c_sharp
Threading in c_sharp
 
ES410 Report
ES410 ReportES410 Report
ES410 Report
 

Viewers also liked

Evolution Explosion - Final Year Project Presentation
Evolution Explosion - Final Year Project PresentationEvolution Explosion - Final Year Project Presentation
Evolution Explosion - Final Year Project Presentationdesirron
 
Monopoly --in microeconomics
Monopoly --in microeconomicsMonopoly --in microeconomics
Monopoly --in microeconomicsNilormi Das
 

Viewers also liked (6)

Evolution Explosion - Final Year Project Presentation
Evolution Explosion - Final Year Project PresentationEvolution Explosion - Final Year Project Presentation
Evolution Explosion - Final Year Project Presentation
 
Monopoly
MonopolyMonopoly
Monopoly
 
PPT on Monopoly
PPT on MonopolyPPT on Monopoly
PPT on Monopoly
 
Monopoly --in microeconomics
Monopoly --in microeconomicsMonopoly --in microeconomics
Monopoly --in microeconomics
 
Monopoly ppt
Monopoly pptMonopoly ppt
Monopoly ppt
 
Introduction to Game Development
Introduction to Game DevelopmentIntroduction to Game Development
Introduction to Game Development
 

Similar to Comparing Game Development on the Android and Windows Phone 7 Platforms.

Engineers guide to technical writing
Engineers guide to technical writingEngineers guide to technical writing
Engineers guide to technical writingTakele Getachew
 
1 engineer's guide to technical writing
1 engineer's guide to technical writing1 engineer's guide to technical writing
1 engineer's guide to technical writingLAGB2018
 
Soa In The Real World
Soa In The Real WorldSoa In The Real World
Soa In The Real Worldssiliveri
 
html-css-bootstrap-javascript-and-jquery
html-css-bootstrap-javascript-and-jqueryhtml-css-bootstrap-javascript-and-jquery
html-css-bootstrap-javascript-and-jqueryMD. NURUL ISLAM
 
Configuring Microsoft Windows IP Security to Operate with HP ...
Configuring Microsoft Windows IP Security to Operate with HP ...Configuring Microsoft Windows IP Security to Operate with HP ...
Configuring Microsoft Windows IP Security to Operate with HP ...webhostingguy
 
Python_Programming_and_Numerical_Methods_A_Guide_for_Engineers_and.pdf
Python_Programming_and_Numerical_Methods_A_Guide_for_Engineers_and.pdfPython_Programming_and_Numerical_Methods_A_Guide_for_Engineers_and.pdf
Python_Programming_and_Numerical_Methods_A_Guide_for_Engineers_and.pdfjankoabel2022
 
A Beginners Guide To Visual Prolog
A Beginners  Guide To Visual PrologA Beginners  Guide To Visual Prolog
A Beginners Guide To Visual PrologJennifer Holmes
 
spring-security-reference.pdf
spring-security-reference.pdfspring-security-reference.pdf
spring-security-reference.pdfhorica9300
 
Uni leicester
Uni leicesterUni leicester
Uni leicesterN/A
 
Data source integration guide for HP Performance Agent
Data source integration guide for HP Performance AgentData source integration guide for HP Performance Agent
Data source integration guide for HP Performance Agenthernajes
 

Similar to Comparing Game Development on the Android and Windows Phone 7 Platforms. (20)

Pentest standard
Pentest standardPentest standard
Pentest standard
 
Bwl red book
Bwl red bookBwl red book
Bwl red book
 
Sg246776
Sg246776Sg246776
Sg246776
 
Graduation Report
Graduation ReportGraduation Report
Graduation Report
 
test6
test6test6
test6
 
Gemini Manual
Gemini ManualGemini Manual
Gemini Manual
 
Engineers guide to technical writing
Engineers guide to technical writingEngineers guide to technical writing
Engineers guide to technical writing
 
1 engineer's guide to technical writing
1 engineer's guide to technical writing1 engineer's guide to technical writing
1 engineer's guide to technical writing
 
Soa In The Real World
Soa In The Real WorldSoa In The Real World
Soa In The Real World
 
By d ui_styleguide_2012_fp35
By d ui_styleguide_2012_fp35By d ui_styleguide_2012_fp35
By d ui_styleguide_2012_fp35
 
cs-2002-01
cs-2002-01cs-2002-01
cs-2002-01
 
html-css-bootstrap-javascript-and-jquery
html-css-bootstrap-javascript-and-jqueryhtml-css-bootstrap-javascript-and-jquery
html-css-bootstrap-javascript-and-jquery
 
Fraser_William
Fraser_WilliamFraser_William
Fraser_William
 
Configuring Microsoft Windows IP Security to Operate with HP ...
Configuring Microsoft Windows IP Security to Operate with HP ...Configuring Microsoft Windows IP Security to Operate with HP ...
Configuring Microsoft Windows IP Security to Operate with HP ...
 
Python_Programming_and_Numerical_Methods_A_Guide_for_Engineers_and.pdf
Python_Programming_and_Numerical_Methods_A_Guide_for_Engineers_and.pdfPython_Programming_and_Numerical_Methods_A_Guide_for_Engineers_and.pdf
Python_Programming_and_Numerical_Methods_A_Guide_for_Engineers_and.pdf
 
A Beginners Guide To Visual Prolog
A Beginners  Guide To Visual PrologA Beginners  Guide To Visual Prolog
A Beginners Guide To Visual Prolog
 
spring-security-reference.pdf
spring-security-reference.pdfspring-security-reference.pdf
spring-security-reference.pdf
 
Programming
ProgrammingProgramming
Programming
 
Uni leicester
Uni leicesterUni leicester
Uni leicester
 
Data source integration guide for HP Performance Agent
Data source integration guide for HP Performance AgentData source integration guide for HP Performance Agent
Data source integration guide for HP Performance Agent
 

Comparing Game Development on the Android and Windows Phone 7 Platforms.

  • 1. Institute of Technology Tallaght Comparing Game Development for Android and Windows Phone 7
  • 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; }
  • 53. 4.2.2 Schema for Online High Score Storage <?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.nathanielgames.com" xmlns="http://www.nathanielgames.com" elementFormDefault="qualified"> <xs:element name="player_info"> <xs:complexType> <xs:sequence> <xs:element name="name"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="15"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="high_score"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:maxInclusive value="10000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="hours"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="minutes"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="59"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="seconds"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="59"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
  • 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.