Institute of Technology Tallaght

Comparing Game Development for Android and Windows Phone 7

Contents1. Abstract.................................................................................................7

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)....................................................................................................................7

Figure 2 (Distmo Report Q3 2010, pg 3).....................................................8

Figure 3 Distribution of Android releases currently active (Android, 2010).9

Figure 4 Percentage of game sold on Android Market. (Androlib, 2010)...10

Figure 5 A simple mock up of how the game interface might look...........13

Figure 6 a high level game architecture....................................................14

Figure 7 components of the application layer...........................................15

Figure 8 components of game logic layer.................................................15

Figure 9 representation of the game view for human player....................16

Figure 10 representation of game view for AI agent.................................17

Figure 11 the XNA game loop....................................................................21

Figure 12 process of the XNA content pipeline.........................................23

Figure 13: Main screen options.................................................................24

Figure 14: System Model...........................................................................28

Figure 15: Game Play Use Case Diagram..................................................29

Figure 16: Detailed Game Play Use Case Diagram....................................29

Figure 17: Enemy AI Use Case Diagram....................................................30

Figure 18: Defensive Structure AI Use Case Diagram...............................30

Figure 19: Activity for the Standard Game Loop.......................................30

Figure 20: Question 1: Age Group.............................................................40

Figure 21: Question 2: Type of Handset Owned........................................40

Figure 22: Question 3: Regularity of Mobile Games Played.......................40

Figure 23: Question 4: Average Time Spent Playing Mobile Games..........40

Figure 24: Question 5: Importance of Story in Mobile Games...................41

Figure 25: Question 6: Cut Scenes Watched or Skipped...........................41

Figure 26: Question 7: Favourite Game Genre..........................................41

Figure 27: Question 8: Number of Mobile Games Downloaded.................41

Figure 28: Question 9: Number of Mobile Games Paid For........................42

Figure 29: Question 10: Average Price (in Euros) Paid for Games.............42

Figure 30: First Cut Class Diagram............................................................42

Figure 31 Test Logs...................................................................................62

Figure 32 Bug reporting............................................................................62

Figure 33 Application Deploymenjt Screen...............................................64

Figure 34 Main Menu Screen.....................................................................65

Figure 35 Gameplay Screen......................................................................65

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.

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.

Other information such as Health Hermes &

Nathaniel

Defensive structure destroyin

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 GameApplication Layer

Logic

View

The Game Application Layer

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

Figure 8 components of game logic layer

Devices

input

Files

Files

Operating System

DLL

Threads

Network

Language

Game Lifetime

Main Loop

Inititalize and Shutdown

Game State & Data Structures

Physics Events Process Manager

Command Interpreter

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.3The Game View

The game view relates to the graphics and sounds a player sees as well as handling all interaction with the game.

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 - Human

Display AudioInput

Interpreter

Process Manager Options

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

Game View - AI

Stimulus Interpreter

Decision System

Process Manager Options

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.

draw()

Invalidate view

Phone Screen

XML UI

Nathaniel.Java <Activity>

NathanielGame.java <StrategyGame>

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 DesignThe 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 OptionsThe 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 FameThe 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: PlayActor (s): PlayerGoal: 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: WatchActor (s): PlayerGoal: 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.OrPlayer 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 OptionsActor (s): PlayerGoal: 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 ScoreActor (s): PlayerGoal: 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 ScoresActor (s): PlayerGoal: 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: SaveActor (s): PlayerGoal: 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: LoadActor (s): PlayerGoal: 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- There is a saved game in persistent storage.

ConditionsPost-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 ScoresActor (s): Web ServiceGoal: 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 ScoresActor (s): Web ServiceGoal: 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: LoseActor (s): UserGoal: 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): PlayerGoal: 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 DefenceActor (s): PlayerGoal: 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 EnemyActor (s): PlayerGoal: 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 CharacterActor (s): PlayerGoal: 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 ResourcesActor (s): PlayerGoal: 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 impor-tant

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.

Level

Item

+size

Agent

+HealthPoints+isMoveable

+Attack()+Move()+Die()

GameManager

CommandProcessor

Buffer

Utilities

AI_Agent

+GetTarget()

NathanielHermes

+BuildStructure()

Game_Entity

RTSGame

NathanielGame

+Initialize()+LoadContent()+Update()+Draw()+UnloadContent()

ContentManager

NPC Monster

DefensiveStructureGrunt Boss

PlayerAgent

Tree

Rock

Corpse

+resources

Sprite

Weapon

+power

MeleeWeapon

+Hit()

RangedWeapon

+range

+Shoot()

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 rangeIf(list of targets.length > 0){

While (list of targets.length > 0){Sort list by attackPower in descending orderTarget = 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.

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.

WCF 4 RESTful Web Service

GetHighScore()

SendTopTen()

Game Client

GetTopTen()

SendHighScore()

AZURE

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

1. Resource display2. Nathaniel’s health bar3. Hermes health bar4. Time5. Menu6. Nathaniel7. Hermes

4.3.6 Player Being Attacked

1. Enemies

12 3 4

5

67

1

4.3.7 Building Structure Screen

1. Defensive structure2. 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.

1

2

Player

+protected NathanielGame curGame;+protected SpriteBatch spriteBatch;+public Nathaniel nathaniel;+public Hermes hermes;+public int resources;+public int score;+public string name;

+public void HandleInput()+public override void Draw()+public bool SaveGame()+public bool LoadGame()+public void PlaceStructure()

DrawableGam

e Component

AI_Agent

+void MoveToTarget()+void Retreat()

PlayerAgent

+Weapon weapon;

ArmedM

onster

+Weapon W

eapon;

Nathaniel

+public bool HasResource;+public Resource resource;+bool InAggresiveMode;

+public void getResource()+void Move()+Operation1()

Zombie

+void EatFlesh()

DefensiveStructure

+int buildCost;

+bool CheckFriendlyHealth()+void ProtectFriendly()

BuildMenu

+SpriteBatch spriteBatch;+Dictionary<string, Animation;+public Vector2 position;+bool IsVisible;+ArrayList<Texture2D> availableStructures;

+void getSelectedStructure()+void close()+void Draw()

GameScreen

+public bool IsPopup;+public TimeSpan transitionOnTime;+public TimeSpan TransitionOffTime;+public float transitionPosition;+public float TransitionAlpha;+public ScreenState ScreenState;+public bool IsExiting;+public bool IsActive;+public ScreenManager ScreenManager;+public GestureType EnableGestures;+public bool IsSerializable;

+void Update(GameTime gameTime, bool, bool)+void Draw(GameTime gameTime)+bool UpdateTransition(GameTime, TimeSpan, int direction)+void Serialize(Stream stream)+void Deserialize(Stream stream)+void ExitScreen()+void HandleInput(InputState input)

InpuState

+TouchCollection TouchState;+List<GestureSample> Gestures;

MenuEntry

MenuScreen

ScreenManager

+List<GamScreen> screens;+List<GameScreen> screensToUpdate;+InputState input;+bool isInititalised;+bool traceEnabled;

+void TraceScreens()+void AddScreens(GameScreen)+void RemoveScreen(GameScreen screen)

BackgroundScreen

+Texture2D background;

OptionsScreen

MainM

enuScreen

HallOfFameScreen

InstructionsScreen

+SpriteFont font;+GamePlayScreen gamePlayScreen;+Thread thread;

GamePlayScreen

+Texture2D foreground;+ArrayList<Texture2D screenTextures>;+Vector2 HUDPosition;+Player player;+Nathaniel nathaniel;+Hermes hermes;+ArrayList<AIAgent> enemies;+ArrayList<AIAgent> structures;+bool gameOver;+Random random;+public int level;

+void DrawHud()+void Start()+void DrawPlayer(GameTime gameTime)+void DrawAI(GameTime gameTime)+void endGame()+void LoadLevel()+void PauseGame()

NathanielGame

+GraphicsDeviceManager graphics;+ScreenManager screenManager;

Animation

+Texture2D animatedCharacter;+Point sheetSize;+public Point currentFrame;+Point frameSize;+public int FrameCount;+public Vector Offset'+public int FrameIndex;+public bool IsActive;+public Animation;

+void Update()+void Draw(SpriteBatch spriteBatch, Vector2 position, SpriteEffects spriteEffect)+void Draw(SpriteBatch spriteBatch, Vector2 position, float scale, SpriteEffects spriteEffect)+public void PlayFromFrameIndex(int frameIndex)

AudioManager

+SoundEffectInstance musicSound;+Dictionary<string, SoundEffectInstance> soundBank;

+void LoadSounds()+void PlaySounds()+void PlayMusic()+void StopSounds()

Game

GameCom

ponent

Hermes

+bool IsBuilding;+BuildMenu buildMenu;

+void ShowBuildMenu()+int ProcessResources()

GameAgent

+Random random;+SpriteBatch spriteBatch;+Dictionary<string, Animation> animaitons;+bool animationRunning;+public Vector2 Position;+public string Name;+SpritEffects spriteEffects;+public int currentHP;+public bool IsSelected;+public int attackPower;+Dictionary<string, int> splitFrames;+Texture2D idleTexture;+public int moveSpeed;+int range

+bool CheckTargetInRange()+void Attack()+void GetTarget()+void Draw()+void Update(GameTime gameTime)

Boss

+Weapon weapon;

+void RechargeHealth()+void SpecialAttack()

Global

+bool IsBeingLoaded;+string optionsFile;+string saveGameFile;+IAsyncSaveDevice SaveDevice; SaveGam

e

+Int level;+GameTime gameTime;+Player player;+Nathaniel Nathaniel;+Hermes hermes;+ArrayList<DefensiveStructure> structures;+ArrayList<AIAgent> enemies;

Monster

The following classes are provided by the XNA 4.0 framework and are derived from in the game class structure.

Game GameComponent DrawableGameComponent

This is a list of classes that make up the game. A short description of each class is also provided.

Screen Classes

ScreenManager o Purpose: This class keeps a record of what screens are in the

game and what screens need to be updated. This is used in the main game class

o This class is called by the main game class when the game is run

GameScreen o Purpose: For Windows Phone 7 this is an abstract class which

all game screens are derived from. For Android this class will extend the Android Activity class

o Provides uniform functionality for all game screens. Also checks if a screen is a minimal pop up screen to minimize screen transitioning

GamePlayScreeno Purpose: Extends GameScreen. All game play takes place in

this class. All game agents are instantiated and drawn hereo The GamePlayScreen class is serializable to allow saving and

loading BackgroundScreen

o Purpose: Extends GameScreen. Provides a uniform background for menu and title screens

ManuScreeno Purpose: Extends GameScreen. This is an abstract class to

provide functionality to all derived menu screens MainMenuScreen

o Purpose: Extends MenuScreen. Gives the player options to play the game, edit game options or view hall of fame

o This class is invoked each time the game is run and is the start point for player interaction with the game

OptionsScreeno Purpose: Extends GameScreen. Allows the player to edit

sound optionso May be extended to offer more options

HallOfFameScreeno Purpose: Extends GameScreen. Provides a view of high scores

downloaded from the game web service InstructionsScreen

o Purpose: Extends GameScreen. This screen will display instructions on how to play the game

o This will be done using text, images and animations BuildMenu

o Purpose: This class displays a menu of available structureso Structures displayed in the build menu are selectable and can

be dragged to the game map. This class does not extend GameScreen. It is a drawable game component with its own functionality.=

Utility Classes

Globalo Purpose: Provides access to any necessary global variables

AudioManagero Purpose: This class manages the play back of sound effects

and background music Animation

o Purpose: Access to animation resources and definitions are managed by this class

Game Agent Classes

Playero Purpose: The Player class provides functionality to the player

as well as specifying the heads up display HUD. The player are stored In this class

GameAgento Purpose: This is an abstract class to provide attributes and

functionality to derived game agent classeso A game agent is any player or AI controlled object that will be

drawn to screen PlayerAgent

o Purpose: Extends GameAgent. Reduces abstraction to specify attributes specific to player controlled objects

DefensiveStructureo Purpose: Extends PlayerAgent. Defensive structures are

owned by the player although they are entirely controlled by AI. The class is invoked when a structure is built from the build menu

Hermeso Purpose: Extends PlayerAgent. Hermes is a static object.

Provides functionality for processing resources and building structures

Nathanielo Purpose: Extends PlayerAgent. This class represents the main

character in the game. All actions are through player input

AIAgento Purpose: Extends GameAgent. Reduces abstraction to specify

attributes specific to AI controlled objects ArmedMonster

o Purpose: Extends AIAgent. This class represents an AI controlled game character. Armed monsters use ranged weapons to attack the player. It does not extend the Monster class as it uses different functionality rather than extending functionality

Monstero Purpose: Extends AIAgent. This class represents a simple AI

controlled character. Monsters will move to player agent locations and attack. Monsters have no weapon and always uses melee attacks

Zombieo Purpose: Extends Monster. The same functionality as Monster

but allows the eat flesh attack which take HP form player controlled agents and replenishes the Zombie HP.

Bosso Purpose: Extends AIAgent. This class will be used to create

game bosses.

5. Title and Information Screens

The following are some mock ups of the main menu, options and hall of fame screen.

5.1 Main Menu Screen

5.2 Option Screen

5.3 Hall of Fame Screen

6. Audio Requirements

All audio for an Android application must be saved in the res/raw folder. The Java implementation of sound is done through the MediaPlayer API. Mp3 files will be used for audio.

For XNA the SoundEffect and Stream classes will be used. Wav files are the preferred format but without any special requirements mp3 files are acceptable.

7. Testing Strategy and Plan

7.1 Testing Strategy

Due to the complexity of a game system constant testing is required. The development process will be agile in nature.

Coding unit testing (white box testing) system testing (black box testing)

These will occur in a cyclical manner. As the game is developed component testing will be carried out to ensure each module is working correctly. Feature development will be graduated in a set timeline at which system testing must occur. This should be done in two week rotations. For example once development starts the goal will be that in two week a prototype of the game should be ready. Here is a list of required functionality.

The game map is rendered to the screen The player character is rendered to the screen The player character is moveable An enemy character is rendered to the screen The enemy character moves towards the player character The player can shoot and kill enemy characters

This core functionality should be achievable and testable within two weeks. Four weeks are allocated so there is a margin for error. Each function is testable. Once the main character is coded an image of that character can be rendered to the game screen. The ability to move can be tested. If all functionality is ready within two weeks the system can be tested as a whole. Strange bugs can appear at this point such as a character suddenly disappearing or the map turning into number. As part of the testing strategy exhaustive play testing will be required.

Abbreviated the testing strategy is as follows:

1. Functionality is added iteratively and unit tested2. The project must build every day3. A predetermined set of functionality must be added every two

weeks4. At each two week milestone the game must be fully playable.5. Exhaustive play testing will be carried out6. Functionality will be planned for the next two week to include bug

fixes discovered and functionality that wasn’t completed on time

7.2 Testing Plan

As part of the testing plan each test will be documented. Testing requirements will be gathered based on the functionality specified at the beginning of each two week rotation. Here is an example of the documentation that will be used.

7.2.1 Logging and Reporting

Unit Test

System Test

UI Test

Task Name

Description Passed/Failed

Figure 31 Test Logs

Task: Date:

Action:

Expected Result:

Actual Result:

Comments:

Figure 32 Bug reporting

7.2.2 Components to Test

While functionality is the most obvious aspect of the game to test other areas must be explored also. Here is a list of testable components in the game.

Game flow and logic Collision detection Animation Game art Music Sound and sound effects Game rules Character attributes Events and triggers Scoring mechanism AI Controls Basic game options

These components may be tested positively in play testing.

7.2.3 Performance Testing

Performance is always an important issue with games. Due to this game running on mobile devices with limited resources performance is a critical testing area. Memory management, intensive computing leading to battery drain and frame rates are the main issues to look at.

Methods to test performance:

Keep running the game – this will show up stability issues Leave the game run for as long as possible – this may identify issues

with memory management Write test classes to push the game – make a class that renders

vast amounts of objects to see how the game and hardware react Try to find actions that were not considered before and see how the

game reacts – this is done by play testing

Installation Manual Document

1. Windows Phone 7

The windows phone 7 version of the software is packaged in a .XAP file. To run the application in an emulator the windows phone developer tools are required. These are available for free at http://create.msdn.com/en-US/.

The tools provide an application deployment interface to deploy to either the developer tools emulator or to an actual device. Once run the screen shown in Figure 33 is displayed. Browse to the location of the XAP file and choose the target platform to deploy to. That’s all there is to deploying the software for windows phone 7.

Figure 33 Application Deployment Screen

2. Android

The Android version of the software is packaged in a .apk file. To deploy to a device or emulator the android SDK is required. The SDK is available here http://developer.android.com/sdk/index.html.

If you are deploying to a device some settings may need to be altered. On the phone go to Settings, select “Application Settings” and then enable “Unknown Sources.” Also under Settings, select “SD Card” and “Phone Storage,” and finally enable “Disable Use for USB Storage”.

All going well once you have installed the SDK in Windows, Mac or Linux the adb should be added to your build path. This should allow deployment to the emulator if it is running or to a device if it is connected using this simple command in the system command prompt console. “adb install

”application path””application name”.apk”. Obviously enough the application path is the location of the apk file. The application name is the name which in this case would be Nathaniel. Example “adb install C:ruairi\games\Nathaniel.apk”.

Post Project Review Document

1. Review

Developing a game is a long and challenging process. So many aspects of software development are involved in the creation of such a complex interactive application. Although at times the project seemed like a bad idea, mainly due to the volume of work required and countless problems to overcome, the experience and knowledge gained from completing it were invaluable.

Figure 34 Main Menu Screen

Game development may seem like a fun or trivial pursuit and it can be at times. However the computer games industry contains some of the most skilled and professional software engineers currently working in any field of computing. The skill level required to implement extremely complex AI, graphics and performance enhancements is quite high.

Figure 35 Gameplay Screen

The project did not end up exactly what as was intended first day. In some ways it is better in others worse. Sometimes aspects of programming could clash with requirements of good game play. The human element had to be considered at all time.

Planning for human interaction is in my opinion what makes game development and many other forms of software development so interesting and enjoyable to take part in. Overall the project was an extremely enjoyable and beneficial experience.

2. Future of the Project

The original intention of the project was to have an Android game released on the Android Market before April 2011 and a Windows Phone 7 game on Microsofts AppHub before April 2011. This didn’t happen due to issues with game art. Open source art had to be used but it would be far preferable to use original art. At the time of writing, exams are now a priority so the release of the game to market is being temporarily shelved.

In the future the game will be improved, better art will be added and it will be released for free and open sourced. Perhaps in the long term as personal software development skills are improved an nice version 2 can be made and charged for.

3. Minutes of Meetings

05 – October - 2010

Next week (Wednesday - 13 - October) first draft of research paper to be ready.

Game play to be specified. Story board. 2D or 3D game? AI? Number of lives? Scoring and winning conditions? Etc…. Research different platform

Abdroid? APIs, emulators, devices? Windows Phone 7? XNA, Silverlight? iPhone, J2ME?

Research website and restful web service for upload and download.

12 – October - 2010

The project will have a research focus.  Critique, compare and contrast the development process for

Android and Windows phone 7 games. Developing with XNA framework for windows phone 7. There is no specialized game framework currently supported by

Google for Android but I will develop with the Java SE and Android APIs provided.

The game concept is now: Strategy based Non scrolling Some AI Less resource content to save time but more logic to explore

the development process in depth for each platform

Research paper, first draft is due tomorrow the 13th of October 2010.

Prototype

The prototype demonstrates a minimalistic set of features that will be present in the complete application. Little effort has been put in to how the display is presented other than to demonstrate functionality.

1. A basic main menu screen has been implemented. More options and a more visually appealing interface will be implemented for final release. Pressing Play continues to an instruction screen. Exit terminates the application.

2. A basic instruction screen. While this is displayed a separate thread has been fired off to load the game. Again in the final release this will be greatly improved with animations and possible user interaction.

3. This is the main game play screen. On the top information is provided to the user such as game time and resources collected.

This is Hermes. The user can deliver enemy corpses here to gain resources.

This is an enemy going to attack Nathaniel.

This is Nathaniel collecting a corpse and being attacked

All the functionality mentioned above has been fully implemented. The enemy AI is still fairly basic. Enemies will try to attack the man character. If they are closer to the robot Hermes than they are to the main character they will attack him instead. Enemies are spawned randomly but in the finished game there will be an element of scripting to produce enemies at certain intervals and events.

4. If the main character or Hermes dies a game over message is displayed or if a certain amount of resources are collected a game won message is displayed.

This is all the functionality I have ready for the prototype. I hope to have some more features ready by tomorrow such as saving a game and building defensive structures.

06 – February - 2011

Begin work on the Android project. Begin testing on device. Note design issues. Note performance issues. Some problems arose with development tools but were easily fixed.

Unfortunate waste of time.

20 – February – 2011

Work has begun on WCF Restful Service. Decided to go with XML over JSON for now. Slight redesign in game architecture to allow level editor

integration. Work on AI algorithms.

06 – March - 2011

Changed from custom C# level editor to pre–existing TiledQT level editor.

Another modification in design to allow .tmx integration. Research A* path finding for AI. Implement build structure capability.

20 - March - 2011

Prepare for final test and fix iteration. Currently alpha phase. A* path finding implemented. Some menus implemented. Work on finalizing features. Keep Android version trimmed down due to time constraints.

Bibliography

Anon, 2010. Real-time strategy. [Online] Available at: http://en.wikipedia.org/wiki/Real-time_strategy [Accessed 10 November 2010].

Geryk, B., 2008. A History of Real-Time Strategy Games. [Online] Available at: http://www.gamespot.com/gamespot/features/all/real_time/p4_02.html [Accessed 10 November 2010].

Hansford, S., 2010. The 2.5D trend. Editorial. thisismyjoystick.com.

Lew, D., 2010. Android: Serializable Considered Harmful. [Online] Available at: http://daniel-codes.blogspot.com/2010/01/android-serializable-considered-harmful.html [Accessed 10 November 2010].

Adrolib, 2010. Statistics. [Online] Available at: http://www.androlib.com/appstatstype.aspx [Accessed 13 October 2010].

Android, 2010. Platform versions. [Online] Available at: http://developer.android.com/resources/dashboard/platform-versions.html [Accessed 13 October 2010].

Carew, S. & Madway, G., 2010. Apple boasts 1.7 million iPhone 4 Sales. [Online] Available at: http://www.reuters.com/article/idUSTRE65O6FE20100628 [Accessed 13 October 2010].

Chen, B., 2009. Gadgetlad. [Online] Available at: http://www.wired.com/gadgetlab/2009/11/appstore/ [Accessed 14 October 2010].

Chu, E., 2008. Android developers blog. [Online] Available at: http://android-developers.blogspot.com/2008/10/android-market-now-available-for-users.html [Accessed 13 October 2010].

Distimo, 2010. Distimo Report. Distimo.

Farago, P., 2010. http://blog.flurry.com/. [Online] Available at: http://blog.flurry.com/ctl/all-posts/ [Accessed 14 October 2010].

Garza, G., 2010. Windows Phone 7 Debut. [Online] Available at: http://www.windows7news.com/2010/10/11/windows-phone-7-debut/ [Accessed 13 Octiber 2010].

McSaffery, M., 2009. Game Programming Complete. Charles River Media.

Parr, B., 2010. Google Is Now Apples's Greatest Enemy: Here's why. [Online] Available at: http://mashable.com/2010/01/20/apple-microsoft-v-google/ [Accessed 14 October 2010].

Pruett, C., 2010. Game development for Android: A quick primer. [Online] Available at: http://android-developers.blogspot.com/2010/06/game-development-for-android-quick.html [Accessed 14 October 2010].

Silva, V., 2010. Pro Android Games. New York: Apress.

Tofel, K., 2010. Android Sales Overtake iPhone in the U.S. [Online] Available at: http://gigaom.com/2010/08/02/android-sales-overtake-iphone-in-the-u-s/ [Accessed 13 October 2010].

Further Reading

Mann, J (2010). Just How Big Is The iDevice Gaming Market? UBM TechWeb. Retrieved October 13, 2010, Available from: http://www.gamasutra.com/blogs/JamieMann/20101008/6107/Just_How_Big_Is_The_iDevice_Gaming_Market.php

Hargreaves, S (2008). Game programming with the XNA Framework. Retrieved October 14, 2010, Available from: http://blogs.msdn.com/b/shawnhar/archive/2008/11/24/content-pipeline-assemblies.aspx

Ioannis (2009). XNA Game Development. Progware. Retrieved October 14, 2010, Available from: http://www.progware.org/Blog/post/XNA-Game-Development-(First-Steps).aspx