Comparing Game Development on the Android and Windows Phone 7 Platforms.
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

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

  • 1,590 views
Uploaded on

A document I did in College for my final year project detailing my experience developing the same game for both the Android and Windows Phone 7 mobile platforms.

A document I did in College for my final year project detailing my experience developing the same game for both the Android and Windows Phone 7 mobile platforms.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,590
On Slideshare
1,585
From Embeds
5
Number of Embeds
2

Actions

Shares
Downloads
9
Comments
0
Likes
1

Embeds 5

http://www.linkedin.com 4
https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Institute of Technology TallaghtComparing GameDevelopment forAndroid andWindows Phone 7
  • 2. Contents1. Abstract .................................................................................... 82. Introduction ............................................................................... 83. The Android Platform .................................................................. 104. The Windows Phone 7 Platform ...................................................... 125. 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 ............................................................... 186. Developing Games for Android ....................................................... 20 6.1 Native Code ........................................................................... 20 6.2 Java..................................................................................... 20 6.3 Android Game Architecture and considerations ................................. 207. 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 ........................................................................... 258. Conclusion ............................................................................... 25Requirements Analysis Document ......................................................... 261. Preface ................................................................................... 26
  • 3. 2. Game Specification .................................................................... 26 2.1 Game Play ............................................................................. 26 2.1.1 Nathaniel: ........................................................................ 26 2.1.2 Hermes: ........................................................................... 27 2.1.3 Game Flow Design ............................................................... 27 2.2 Options ................................................................................. 27 2.3 Hall of Fame........................................................................... 28 2.2 Functional Requirements ......................................................... 28 2.3 Non Functional Requirements .................................................... 293. System Model ........................................................................... 304. Use Cases ................................................................................ 33 System Use Cases: ........................................................................ 33 Game Play Use Cases: .................................................................... 375. Questionnaire ........................................................................... 41 5.1 Analysis of Questionnaire Results ............................................... 426. Class Diagram ........................................................................... 44Game Design Document ..................................................................... 45 1. Abstract ............................................................................. 452. 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.......................................................... 483. Game Story .............................................................................. 48
  • 4. 4. Game System............................................................................ 49 4.1 Model for Restful Web Service...................................................... 50 4.1.2 REST Application Data .......................................................... 50 4.2 Persistent Storage Design ........................................................... 51 4.2.1 Save Game Data ................................................................. 51 4.2.2 Schema for Online High Score Storage ...................................... 53 4.3 Game Play and Screen Design ...................................................... 54 4.3.3 Player Actions .................................................................... 54 4.3.2 Defensive Structures ............................................................ 54 4.3.3 Game AI ........................................................................... 55 4.3.4 Win/Lose Conditions ............................................................ 55 4.3.5 Normal Game Play Screen...................................................... 56 4.3.6 Player Being Attacked .......................................................... 56 4.3.7 Building Structure Screen ...................................................... 57 4.4 Logic Design ........................................................................... 575. Title and Information Screens ........................................................ 61 5.1 Main Menu Screen .................................................................... 61 5.2 Option Screen ......................................................................... 62 5.3 Hall of Fame Screen .................................................................. 626. Audio Requirements.................................................................... 627. Testing Strategy and Plan ............................................................. 62 7.1 Testing Strategy ...................................................................... 62 7.2 Testing Plan......................................................................... 64 7.2.1 Logging and Reporting .......................................................... 64 7.2.2 Components to Test ............................................................. 65
  • 5. 7.2.3 Performance Testing ............................................................ 65Installation Manual Document ............................................................. 66 1. Windows Phone 7 .................................................................. 66 2. Android .............................................................................. 66Post Project Review Document ............................................................ 67 1. Review ............................................................................... 67 2. Future of the Project .............................................................. 68 3. Minutes of Meetings ............................................................... 69Bibliography .................................................................................. 73 Further Reading ........................................................................ 74
  • 6. Table of FiguresFigure 1 Percentage of apps by category in Apple App Store (Apptizr 2010) ......... 9Figure 2 (Distmo Report Q3 2010, pg 3) .................................................. 10Figure 3 Distribution of Android releases currently active (Android, 2010) ......... 11Figure 4 Percentage of game sold on Android Market. (Androlib, 2010) ............ 12Figure 5 A simple mock up of how the game interface might look. .................. 15Figure 6 a high level game architecture .................................................. 16Figure 7 components of the application layer ........................................... 17Figure 8 components of game logic layer ................................................ 17Figure 9 representation of the game view for human player ......................... 18Figure 10 representation of game view for AI agent ................................... 19Figure 11 the XNA game loop .............................................................. 23Figure 12 process of the XNA content pipeline .......................................... 25Figure 13: Main screen options ............................................................ 26Figure 14: System Model .................................................................... 30Figure 15: Game Play Use Case Diagram ................................................. 31Figure 16: Detailed Game Play Use Case Diagram ...................................... 31Figure 17: Enemy AI Use Case Diagram ................................................... 32Figure 18: Defensive Structure AI Use Case Diagram ................................... 32Figure 19: Activity for the Standard Game Loop ........................................ 32Figure 20: Question 1: Age Group ......................................................... 42Figure 21: Question 2: Type of Handset Owned ......................................... 42Figure 22: Question 3: Regularity of Mobile Games Played ............................ 42Figure 23: Question 4: Average Time Spent Playing Mobile Games .................. 42Figure 24: Question 5: Importance of Story in Mobile Games ......................... 43
  • 7. Figure 25: Question 6: Cut Scenes Watched or Skipped................................ 43Figure 26: Question 7: Favourite Game Genre .......................................... 43Figure 27: Question 8: Number of Mobile Games Downloaded ........................ 43Figure 28: Question 9: Number of Mobile Games Paid For............................. 44Figure 29: Question 10: Average Price (in Euros) Paid for Games .................... 44Figure 30: First Cut Class Diagram ........................................................ 44Figure 31 Test Logs .......................................................................... 64Figure 32 Bug reporting ..................................................................... 64Figure 33 Application Deploymenjt Screen .............................................. 66Figure 34 Main Menu Screen ................................................................ 67Figure 35 Gameplay Screen ................................................................ 67
  • 8. 1. AbstractMobile devices have become an important sector for game development. The appstore business model allows low budget, small scale development companies todevelop, distribute and monetize games. This document will research and outlinethe design and development process for a game on a mobile platform. The focuswill be on comparing and contrasting the process for developing a game for theAndroid and Windows phone 7 platforms. 2. IntroductionThis document will explore the design and development paradigms specific togames development and how these are supported by the Android and WindowsPhone 7 platforms. The most sensible approach to this is to develop the samegame for each platform. To begin there will be a brief description of the currentmarket for mobile games followed by details of the kind of game that will bedeveloped.Currently Apple is one of the biggest players in the smart phone market. An articlepublished by Reuters (Carew & Madway, 2010) reported that over 50 millioniPhones have been sold since the first release in 2007. Apples App Store waslaunched on July 11th 2008.The analytics firm Flurry (Farago, 2010) estimates there are currently over 150,000applications available for download on the app store with 250 new applicationsbeing added each day. The revenue generated is substantial. In the month ofDecember 2009, $250 million USD was generated. Apple takes 30% of revenue anddevelopers receive the remaining 70%. In that one month apple earned $75 millionUSD. Developers earned $175 million USD.A large percentage of this revenue was generated by games. The company Apptizrhave created an application that helps users to search and download from ApplesApp Store. The application is provided free of charge and allows the company togather data on what their users have downloaded. This graph provided by Apptizrgives information on what category of applications are being downloaded the mostby their users. This graph puts the figure at a modest 28% although some estimatesput the figure as high as 65% (Chen, 2009).
  • 9. Figure 1 Percentage of apps by category in Apple App Store (Apptizr 2010)Figure 2 from a report published in September (Distimo, 2010) shows thepercentage of games in the top 100 downloads for the largest mobile applicationstores. The Android market is not included here because Google has differentcategories for games and applications.
  • 10. Figure 2 (Distmo Report Q3 2010, pg 3)The Apple, App Store is a precursor to the Android Marketplace and the WindowsApp Hub. It is reasonable to speculate that the trends shown here should continuefor other mobile application marketplaces and, that games will continue to be animportant source of revenue for mobile companies. The question beinginvestigated here is what importance has been put on games development byAndroid and windows phone 7 and which platform provides the best support for thedevelopment process. 3. The Android PlatformThe Android marketplace was launched in 22nd October 2008 (Chu, 2008). Googlebecame one of the biggest players in global technology market very rapidly. This iseven more impressive as they are now competing against the long term marketstandings of Microsoft and Apple (Parr, 2010). Each company is now in directcompetition however it could be said that each has gained success and innovationthrough that competition. The entry of these three companies into the mobilemarketplace has led to some very interesting developments for consumers anddevelopers alike.The entry of Google into the Smartphone market to compete with Apple was awelcome development. Google has a good reputation with developers aided by itssupport for open source projects and extensive free education resources. This hashelped Android to become a very popular platform for developers of all levels. Incontrast the iPhone is notoriously hard to develop for but is hugely popularity.
  • 11. Innovative design and near perfect user interface ensures that iPhone applicationswill continue to be developed in large volumes for some time to come. Manydevelopers complain that objective C is far behind with regard to productivity butat least developers can be sure of the hardware they are developing for. Androidallows you to develop with managed code using a version of java run in the Dalvikvirtual machine or with native code using the NDK. The Dalvik virtual machine isfunctionally similar to the java virtual machine. It converts the java programminglanguage to byte code which has been optimized for mobile devices.Android was not the perfect answer that developers had hoped for and there havebeen many issues with Android as a development platform. The main complaintsare Too many release versions of the operating system are available Too many different devices with different input options and specifications A poorly designed marketplaceFigure 3 Distribution of Android releases currently active (Android, 2010)Figure 3 is provided by the Android developer network and gives a breakdown ofthe different operating systems currently deployed in the market. Developers haveto consider which version to target. Targeting the earlier releases 1.5 / 1.6 has itsadvantages. All later versions are backward compatible so more users will beeligible to purchase the application. If they wish to use the more advancedfeatures of later versions then a large portion of the possible customer base isremoved. For the purpose of this project version 1.5 will be targeted. This willensure compatibility with most Android devices.
  • 12. Figure 4 Percentage of game sold on Android Market. (Androlib, 2010)Figure 5 (Adrolib, 2010) shows percentage of games downloaded by Android usersis generally much lower than users of Apples App Store. This is predicted to changeas bigger developers come on board for Android. There are different reasons givento explain the low market activity of Android games. One is perhaps people whobuy Android devices just aren‟t big into games. Another is maybe it is just verydifficult to make good games for Android. This is a topic that will be exploredfurther throughout this project. One thing that should not be disregarded by gamedevelopers is that in the short time Android has been available the number ofAndroid handsets being sold has overtaken the number of iPhones being sold(Tofel, 2010). 4. The Windows Phone 7 PlatformWindows Phone 7 was officially launched on October 11th 2010 (Garza, 2010). Thereis a lot of debate on how successful this smart phone OS will be. Microsoft hasbrought about some interesting ideas and handset requirements that could be veryuseful for both consumers and developers alike. All windows phones will have aminimum hardware specification which means that developers can be sure anyphone their application is deployed on will have at least these required features.
  • 13. The requirements are Capacitive touch screen with four or more contact points Two possible screen sizes and resolutions - 4.3 inch (800x480) and 3.4 inch (480x320) Sensors: A-GPS, Accelerometer, Compass, Light, Proximity Camera that is 5 megapixels or more, flash required and dedicated camera button required Three dedicated hardware buttons - Start, Search, and Back Memory: 256MB RAM or more with 8GB flash or more GPU: DirectX 9 acceleration CPU: 1GHz ARMv7 Cortex/Scorpion or betterDevelopers have two choices of framework to develop applications. Forapplications there is Silverlight 3.0 and for games there is XNA 4.0. C# is the onlysupported language although some support has been introduced for VisualBasic.NET. All development can be done in Visual Studio 2010. There is goodsupport for developing Silverlight applications in Expression Blend 4.0.There is no doubt developing applications for the windows phone will be easierthan for iPhone or Android. Windows phone is also the only operating system thatwas released with a development platform specific to games which is interesting.The question now is will people buy the devices and will the operating systemstand up to the scrutiny of a very competitive market. It is worth noting thatdeveloping games using XNA allows for multi platform targeting. This means thatdevelopers can create the same game for Windows Phone 7, Zune, Xbox 360 andWindows PC without much extra effort. This will almost certainly make WindowsPhone 7 a popular platform for game developers.
  • 14. 5. Developing a GameThe game should have enough scope to explore most of the resources available forgame development on each platform. 3 dimensional graphics and networkedmultiplayer will not be included for the initial game design.5.1 Game ConceptThe name chosen for the game is Nathaniel. This is the name of the maincharacter.The story for the game is set some time in the future. Most of humanity has beenwiped out by a cataclysmic event. Those that have survived are now hunted byhordes of zombies, werewolves and other undesirable characters. Where thesehave come from nobody knows. One man named Nathaniel has made it his missionto cleanse his homeland of these beasts. Although a formidable warrior himselfNathaniel has an invaluable sidekick. A legacy from a better world in the form of ahighly advanced robot named Hermes. Hermes has the ability to construct objectsby consuming large amounts of biomass materials and restructuring the moleculesinto complex devices and structures. The structures he can build depend on whathe has schematics for. The original purpose of the Hermes design is unclear butnow 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 differentchallenges. The strategy in the game is to build the right kind of defences tocombat different monsters while ensuring you are not overrun. Nathaniel andHermes must survive and all enemies must be eliminated. Occasionally the playerwill have to protect NPCs (non playable characters). The ultimate goal withregards 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 Hermesthe robot will be immobilised to allow for building defences. Without buildingdefences the player will not survive. Hermes does have a short range laser weaponto provide a last line of defence. The player will constantly be taking risks toacquire resources for Hermes which involves picking up dead enemies anddelivering them for consumption. Nathaniel also has the ability to fight monstershimself. As the game goes on the option of learning to build new structures or toimprove Nathaniel in some way will be offered.
  • 15. Graphically the game will have a simple 2 dimensional top down view. Layeredimages will be used for the background and sprites will be used for most visualobjects in the game.Health bars Hermes & Nathaniel Other information such as resources Defensive structure destroying an enemyFigure 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 isguaranteed on all Android and Windows 7 phones. The graphical user interface willbe very simple. Nathaniel and Hermes are selectable by touch. Nathaniel moves towherever the user touched the screen. If there is an enemy there Nathanielattacks. If there is a dead enemy there he will harvest. When Hermes is selected amenu will appear with build options. Selecting an option will allow the user toplace 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 andHermes will have energy levels that will recharge slowly if they have beendepleted.5.2 Game ArchitectureThis section will explore best practices followed by game developers whendesigning a game architecture.
  • 16. The Game Application Layer Logic ViewFigure 6 a high level game architectureWhen designing the architecture for most games the Model-View-Controller designpattern is best suited with an added layer for hardware subsystems (McSaffery,2009).5.2.1 Application LayerThe 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 downin the application layer.
  • 17. The Game Application Layer Operating Game Devices System Lifetime input DLL Main Loop Inititalize and Files Threads Shutdown Files Network LanguageFigure 7 components of the application layerIn theory the application layer should be the only part of a game that changesacross devices and operating system.5.2.2 Game LogicGame Logic Layer Game Physics Events Process Command State & Manager Interpreter Data StructuresFigure 8 components of game logic layer
  • 18. Game logic is where the life of the game resides. This is where the game world oruniverse is defined. Each objects existence in the game world and how it acts andinteracts is defined here.Depending on the complexity of the game different data structures will be used tostore all the game objects. This is an area where big O evaluations may come inhandy. Developing for a mobile device requires the developer to consider whatmemory or processing overheads are acceptable. During the design phase questionsmust be asked. Is a binary search necessary or not in a given situation? Are hashtables the way to go or a flat search 2D array? Does a structure need to besearched more efficiently or have more flexibility.Game states store state information such as player health, player scores and theposition of objects to be drawn to the screen.Events are used to determine what happens when the player or AI interact withanything else in the game.The process manager keeps track of all the pieces of code that are running andallocates a little CPU time to each. How much the developer is involved in thisdepends on how much control over the system is allowed.The command Interpreter takes input from the human player as well as actionfrom the AI and decides what to do with it. 5.2.3 The Game ViewThe game view relates to the graphics and sounds a player sees as well as handlingall interaction with the game. Game View - Human Input Process Display Audio Options Interpreter ManagerFigure 9 representation of the game view for human player
  • 19. It is fairly standard that in large scale game projects most of the budget could goon 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 alsobuy games based on how good the graphics look. If a company spends 30 million ona game they should be able to advertise it like it is a movie. For mobile devicesgreat graphics are not an absolute requirement. Following good practices in thisarea is still important with regards to performance. The main focus here will be onresearching how well graphics are supported in each platform. Importance will alsobe placed on designing a good user interface and developing the art to have anattractive looking game.Audio can also be as much a part of a games experience as the graphics. I recentlyplayed medal of honour and noticed how impressive the level of noise was in themidst of a battle. A high level of realism was represented. The budget for theaudio alone must have been huge. Audio for a mobile game may not be such animportant factor. How well various types of audio such as sound effects and musicare supported on the different mobile platforms will be investigated.The view process manager is similar to the one in the application layer but controlsfunctions 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 ifpossible. Game View - AI Stimulus Decision Process Options Interpreter System ManagerFigure 10 representation of game view for AI agentThe game view for the AI is similar to the game view for a human although the AIdoesn‟t need any visual or audio information. The artificial intelligence agents in a
  • 20. game should react to stimulus and the game world should react to AI agents. Theseinteractions should be similar to interactions between the human player and thegame 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 programwill fulfil its purpose for this game. It will also test the performance and support ofeach development platform for gaming AI. 6. Developing Games for AndroidGame developers for Android recommend that anyone wishing to make a goodgame for the Android Marketplace should start with a good knowledge of gamedevelopment, excellent Java, C++, OpenGL and C programming skills as well asreasonable knowledge of Linux and Shell scripting (Silva, 2010).6.1 Native CodeUsing Native code and having to get the GNU Tool chain for ARM Processors to useC is a lot of work. Developing custom compilation scripts and using hybrid graphicswith OpenGL and JNI offers a lot of flexibility but is difficult for a beginner togame programming. Where performance is important as it usually is with gamesthese tools should be used. For this project the game will be developed entirely inJava. This makes sense for testing the platform as Java is the main languagesupported and Android specific APIs will be used.6.2 JavaDeveloping 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 XWindow system and it doesn‟t support standard GNU libraries. This reduces codereusability form Linux applications.Androids version of Java running on the Dalvik virtual machine is not the same asthe 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 Androidwhile some custom Android APIs are used instead. This means that is not too likelyyou could take an existing game built in Java ME and easily deploy it on Androidwithout a good amount of modifications first. The development process for Androidis similar to building any other application in java however and all the mainfeatures and object orientation can be used.6.3 Android Game Architecture and considerationsThe screens in any Android application are called Activities. As a simple exampletake the main game activity for the project called Nathaniel.java which extendsAndroids Activity.java. This would retrieve and load the game layout mostly froman XML file. The activity also processes events. There would be an abstract classcalled Game.java or StrategyGame.java. This class provides common functionality
  • 21. and defines the game loop. NathanielGame.java extends StrategyGame.java andwould provide most of the core functionality. XML Nathaniel.Java <Activity> Phone UI Screen draw() NathanielGame.java <StrategyGame> Invalidate view StrategyGame <LinearLayout> Timer TaskFor graphics in a java game built for Android, OpenGL should be used although theprocessing libraries from processing.org could possibly be used in certain cases. Itis recommended to use OpenGL ES 1.0 (Pruett, 2010) to allow for goodperformance and support for most Android releases and devices. Fortunately thereis 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 graphicslibrary that will be used. What other considerations should be taken into accountwhen planning to build a game for Android?Chris Pruett (2010): “Before you get too deep into your epic ragdoll physics-basedspace marine action online RPG with branching endings and a morality system,take a minute to think about your end users. Specifically, there are two areasthat 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 orapplication is mercilessly killed. Touch screen is the only input a developer has toplan for. With Android things can be a little bit more complicated than that.Android have a Compatibility Definition Document which states that all Androiddevices that have Android Marketplace are required to have a touch screen andthree-axis accelerometer. Developers have this guarantee. Some phones areprimarily touch screen, possibly with multi-touch. Some will have keyboards,trackballs or directional pads. A game developer does not have to design for allthese inputs but it is good practice to at least try and include some of these as anoption.Compressing textures sounds like a great idea but for my project I will avoid thatidea entirely. On the Android developer site they say compressing texture data can
  • 22. improve draw performance and allow you to put more textures into vram.Unfortunately different graphic card vendors support different texture formats.The three main compression formats supported are ATITC, PVRTC and DXT. Theseare singularly supported by different devices. All OpenGL ES 2.0 devices supportthe ETC1 format but targeting these devices reduces the target marketdramatically. I will stick to using OpenGL ES 1.0 for this project and avoid usingtexture compression. For a game of this level it should make little or nodifference. 7. Developing Games for Windows Phone 7Game 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 notpermitted yet. Although there are two distinct platforms on windows phone theydo often have to interact. For example for location, vibration and accelerometercontrols are provided by Silverlight to XNA. Silverlight also has access to much ofthe XNA framework.7.1 SilverlightWhile Silverlight is not designed for game development it can still be the rightoption 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 manypuzzle games. The ability to design the interface and much of the graphics inExpression Blend 4.0 is a boon to many developers. It is actually quite possible tocreate a simple puzzle game without knowing how to code at all. Story boarding inexpression blend allows developers or designers to create animations and eventsentirely through the editor created declaratively in XAML. When complicated gamelogic, large resource management and time critical updating and drawing are notnecessary and where speed and performance is not critical using Silverlight is agood and easy way to make a game.7.2 XNADuring the Windows Phone 7 developer launch 12th October 2010 XNA Kenny Spadejokingly stated that XNA stands for XNA is Not an Acronym. It appears that thename came about by accident and that there is no real meaning for it. It is thename of the game development platform Microsoft. XNA is different to Silverlightin that creating a user display such as a menu and some minor animations takesabout 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 gamedevelopment. Creating a new XNA WP7 game project will provide you with all thestart-up code needed to begin making a game. If you run the project without doinganything at all it will give you a plain blue screen (Kenny Spade referred to this asthe blue screen of life).
  • 23. This is very useful because without any work done by the developer the XNAGraphicsDeviceManager sets up the screen size. Although nothing visually ishappening the game is running in a loop and updating already.7.3.1 XNA Game ArchitectureThe default class provided when you build an XNA game project inherits theMicrosoft.Xna.Framework.Game class. Once the Game is created there is a set ofsteps carried out by default. GraphicsDeviceManager is created first to handle the display. The inherited Initialize method from the Game class is then called. This method can be overriden to query for services and load non-graphics resources. Next Load Content is called. This is used to load any graphical content required by the game. Once everything is loaded the game loop can begin. The methods Update and draw are called continuously. They are passed a GameTime object as a parameter. GameTime is the time passed since the last call to the respective methods. This allows update and draw to keep track of where the game is at. Finally the UnloadContent method is called. This is where the game unloads all content to free up any resources used by your game. This is done once in the game lifetime.Figure 11 the XNA game loop
  • 24. Update is the method used to handle changes in the game state. Draw willrepresent the changes handled by update and draw them to the screen. Updateand draw can be set to run at different rates. The game class has a propertyIsFixedTimeStep which is a bool. If it is set to true Update and Draw will be calledas often as resources allow, in the order Update and then Draw. If IsFixedTimeStepis false Draw will still be called as often as possible but update will be called at aninterval set by the TargetElapsedTime property of the Game class which is aTimeSpan property.XNA provides you with all the logic to start a game running for free which savestime. There are many other interesting facilities provided which will now beoutlined 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 RenderingXNA uses profiles to allow developers target the same game to WP7, XBOX 369 andWindows PC. Reach and HiDef are the two profiles. HiDef allows for veryimpressive graphics while Reach allows more devices to be targeted. It is mostlikely that in developing for a phone the Reach profile will be used.There are configurable effects available in both profiles. The classes used andtheir main properties are BasicEffect – basic rendering effect SkinnedEffect – configurable rendering of skinned character models EnvironmentMapEffect – configurable effect for environment mapping DualTextureEffect – configurable effect for two-layer multitexturing AlphaTestEffect – configurable effect for alpha testing
  • 25. XNA provides huge resources and methods to allow graphics to be renderedrelatively easily. Hardcore game developers will probably prefer to have directcontrol over directX but small scale developers will be happy with the ease ofdevelopment provided by this level of abstraction through the XNA APIs.7.3.4 ContentThe content pipeline is used in XNA to bring content form the assets folder into thegame.Figure 12 process of the XNA content pipelineThe four main components of the Content Pipeline are importers, Processors,Writers and Readers. These are very useful tools for game development. Theysupport using XML file for content in a game, processing built in data types, customdata types and sharing data types between build and runtime. 8. ConclusionThis is an intriguing time to be developing mobile applications. Many of theoperating systems are still new but maturing all the time. The developmentplatforms are interesting to use and full of potential. Eventually the applicationmarket may reach a level of saturation making it very difficult for developers tosee any rewards. Mobile technology may improve to the point where gamecompanies will be allocating huge budgets for mobile development. For nowhowever the sector is a rich area for individual creativity and innovation. Thisproject will explore to what extent two of the major mobile platforms encourageinnovation and how much support there is for a small scale developer to form aconcept into good software.
  • 26. Requirements Analysis Document 1. PrefaceThis document is the summary of requirement analysis and general information forthe proposed mobile game called “Nathaniel”. The game will be developed for theAndroid 1.5+ and Windows Phone 7 XNA platforms. The game genre is real timestrategy (RTS). 2. Game SpecificationFigure 1 shows the options a player will be presented with when the game is run.Figure 13: Main screen options2.1 Game PlayThe gameplay is simple real time strategy. The player will control two characterswithin the game, Nathaniel and Hermes. This is the specification of what actions aplayer may perform. All these actions assume that the respective character iscurrently selected.2.1.1 Nathaniel: Move – the character can move to any unoccupied area of the screen. Attack – the character can attack enemy agents in the game. Nathaniel will have 2 weapons. A ranged and a melee. The ranged weapon will have a maximum range which may be upgraded as the game progresses. When Nathaniel is issued an attack order he will move to attack. As soon as he is in range he will begin firing automatically. If an enemy is within melee range Nathaniel will switch to melee attack. Each attack has different attributes which may change throughout the game. Gather resources – the character must pick up dead enemies and deliver them to Hermes for processing. Resources are gathered by selecting a corpse. Nathaniel moves to corpse and picks it up. While Nathaniel is holding the corpse the player must select Hermes. Nathaniel will move to Hermes and deliver the corpse. This provides the player with resources to build structures. Each category of enemy provides different amounts of
  • 27. resources. Once an enemy is dead there is a limited amount of time before the corpse disappears and its resources can no longer be retrieved.2.1.2 Hermes: Move – at certain points in the game Hermes will be allowed to move. The move command is not available during battle sequences. Hermes must remain stationary to build structures and to use his defensive laser. During battle sequences Hermes is essentially a base structure. Build structure – when Hermes is in battle mode a menu will appear with a view of what structures are currently available to build. As the game progresses more structures will become available. Each structure will have a cost. If the player has enough resources available, displayed buildings in the build menu will have a bright background and may be built. If enough resources are not available the buildings will have a grey background and may not be built. Hermes can materialize structures at a large distance so structures can be placed almost anywhere in the game area that is not already occupied. The player must rely on these actions alone to complete the game. The player has no control over any defensive structure once it is built. The player cannot command Hermes to attack. Hermes‟ defensive laser is automatic.2.1.3 Game Flow Design The game flow structure is broken down into four chapters. Each chapter contains levels. The final level of each chapter contains a boss. On completion of the four chapters the game is complete. Each level will have win and lose conditions. In general the main lose condition will be a main characters death. The player loses when Hermes or Nathaniel has lost all their health points from enemy attack and that character dies. Some levels may be timed or require the player to protect a non-playable character (NPC). In general the win condition for each level will be to eliminate all enemies. Other win conditions may be introduced such as gathering a certain amount of resources or surviving a certain amount of time. Once a chapter or the entire game is completed the player will be given the option to upload their high score.2.2 OptionsThe player may edit certain game options. These options are accessed by selectingthe options button in the main menu. The player can change the sound effectsvolume, the music volume and the game difficulty options in this screen.
  • 28. 2.3 Hall of FameThe player can select the Hall of Fame option in the main menu. This allows theplayer to view the top scores of all players who have uploaded their high scores. 2.2 Functional RequirementsFor the overall system: When game application is loaded main screen must be visible. Options must be editable. Options must be saved once edited. Game client must send game score data to web service. Game client must receive high score data from the web service. High scores must be visible when the hall of fame option is selected. Game must play when play game option is selected. Game must load saved game if continue game option is selected. Game must save at certain intervals. Once a win or lose condition is met the current game must end.For the gameplay: Nathaniel must be moveable. Nathaniel must attack when given an appropriate target. Nathaniel must pick up corpse if given a corpse as a target and is at the corpse position. Nathaniel must deliver corpse if given Hermes as a target and Nathaniel is holding a corpse. Nathaniel cannot attack when holding a corpse. Nathaniel drops corpse if attacked or given an attack order. Hermes may only be moveable at certain stages in the game. When Hermes is moveable he may not attack. When Hermes is moveable there will only be two commands available. Move and enter battle mode. Entering battle mode will cause Hermes to become stationary and will change commands available. When Hermes is stationary selecting him will cause the build structure options to be displayed. When Hermes is stationary he will have the ability to process enemy corpses and convert them to resources.
  • 29. When Nathaniel delivers a corpse to Hermes the corpse is processed automatically. Processed resources are added to the players‟ total resources and the new total will be displayed in the heads up display (HUD). Resources are used to build structures. Resources are also used to help calculate player score. Structures that are available to build in the build structure menu depend on the amount of resources available and what structures the player has unlocked. All game agents must lose health points when attacked proportional to the attack power of the attacker. When any game agents health points value = 0 that agent must die.For the AI: Defensive structures are stationary. The attack function is activated when an enemy comes within range. The target is chosen depending on the attack level of all enemies in range. The agent with the highest attack level will be seen as the highest threat and attacked first. Enemy AI agents in the game also use the threat level targeting system. Generally Nathaniel will have the highest threat but some structures may have a higher attack power and be targeted first. Once an enemy AI agent has acquired a target they will move towards that target until they are within their specified attack range. Other requirements: For a game to be playable a minimum frame rate of 30 frames per second is recommended. For high scores to be uploaded and viewed a connection to a web service must be established. Files must be transferred in an acceptable data format i.e. JSON, XML. 2.3 Non Functional RequirementsThe game is designed specifically for mobile devices. There are many non-functional requirements which do not affect the game logic but do affect thegames viability for running on a mobile device. Battery life - game code must be optimized to reduce the amount of processing and rendering that must be performed.
  • 30. Memory – memory is very limited on mobile devices and there are many ways to reduce the amount of memory a program uses by optimizing code. Touch screen input – the game design may allow for many different types of input but initial implementation will only allow touch screen input as this is standard to both target devices. 3. System ModelThis is a high level representation of the proposed game system.Figure 14: System ModelFigure 3 shows the basic actions that are performed by the player duringgameplay.
  • 31. Figure 15: Game Play Use Case DiagramFigure 4 gives a more detailed view of how the system operates during gameplay.Figure 16: Detailed Game Play Use Case Diagram
  • 32. Figure 5 shows the functionality used by the games enemy artificial intelligenceagents. Each enemy may have different attributes but all will follow thisfunctionality.Figure 17: Enemy AI Use Case DiagramFigure 6 shows the behaviour of defensive structures that have been placed by theplayer.Figure 18: Defensive Structure AI Use Case DiagramFigure 19: Activity for the Standard Game Loop
  • 33. 4. Use CasesSystem 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 metTitle: WatchActor (s): PlayerGoal: Game displays story information to playerOverview: This is a high level use case which shows that a player can watch cut scenes during the game. These are very simple scenes to provide story information to the player. All cut scenes can be skipped.Pre-Conditions Cut scene is initiated by game.Post-Conditions Cut scene time has expired. Or Player has selected skip to end scene.Successful Scenario: 1. Cut scene is displayed to screen. 2. Player watches cut scene or skips it. 3. Cut scene ends and game continues.
  • 34. Title: Update 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.
  • 35. 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.
  • 36. 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-Conditions There is a saved game in persistent storage.Post-Conditions The game loads at the point specified in the saved game with all the correct data.Successful Scenario: 1. Player selects „Continue Game‟ from the play game menu screen. 2. Loading dialogue appears. 3. Game begins at the point specified in the saved game file. 4. The game state is exactly as it was when the game was saved. 5. Player can continue playing the game from this point.Title: Receive High 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.
  • 37. 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.
  • 38. Title: WinActor (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.
  • 39. 6. Player selects an area in the game that is available to be built on. 7. Player confirms decision. 8. Structure is placed.Title: Attack 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.
  • 40. 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.
  • 41. 5. QuestionnaireThe questionnaire has been designed to gather some basic information on possiblesystem usage.Pre-conditions: All individuals own a mobile phone All individuals download and play mobile gamesIssues:All those that were asked to fill out the application are acquaintances or familymembers of the proposed system developer. Questions directly related to thesystem would be biased by this association.Questionnaire design:The questions have been modelled to gather information on the general usage ofmobile games. Design issues such as level time, customisation and gameplaycomplexity will be explored using the data gathered in the questionnaire. Othermore arbitrary data such as average prices paid for games and number of gamesdownloaded 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 ifapplicable)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 tellthe game story or do you skip them?Always skip □ Sometimes skip □ Always watch □Q7. What is your favourite game genre?Action □ Adventure □ Role Playing (RPG) □ First Person Shooter (FPS) □Real Time Strategy (RTS) □ Simulation □ Online Games □ Puzzle □Q8. How many games have you downloaded for your mobile device(s)?Less than 5 □ 5 – 10 □ 10 – 15 □ 15 – 20 □ More than 20 □Q9. Of the game you have downloaded, how many were paid (not free) games?Less than 5 □ 5 – 10 □ 10 – 15 □ 15 – 20 □ More than 20 □Q10. On average what price have you paid for mobile phone games? Less than €1 □ €1 - €2 □ €2 - €3 □ €3 - €4 □ €4 - €5 □ More than €5 □
  • 42. 5.1 Analysis of Questionnaire Results Twelve individuals completed the questionnaire. The results should be fairly representative of a large portion of the target users for this application. Here is a breakdown of the results. < 18 18 - 25 26 - 35 36 - 45 46 - 55 56+Figure 20: Question 1: Age Group iPhone Android WP7 OtherFigure 21: Question 2: Type of Handset Owned Every day Every Other Day Once A Week Less Than Once a WeekFigure 22: Question 3: Regularity of Mobile Games PlayedQuestion 3 is important when considering many aspects of a games design. Ifplayers are likely to play a game every day until they complete it then it would beacceptable to make the game fairly complex. If a player only plays once a week itis likely they will have forgotten a lot of the more complicated game featureswhen they play it next. This could lead to the end of the game on the users‟device. < 10 10 -- 20 20 -- 30 30 -- 40 40 -- 50 50 -- 60 60+Figure 23: Question 4: Average Time Spent Playing Mobile Games
  • 43. Question 4 provides another useful piece of information. If users are not likely toplay a game for much more than 15 minutes at a time then it may be a good ideato limit the time of a game level to around 15 minutes. Not Important Somewhat important Very ImportantFigure 24: Question 5: Importance of Story in Mobile GamesThis information may be used to aid in decision making when it comes to decidingwhat functionality is required and what can be discarded if the project is delayed. Always Skip Sometimes Skip Always WatchFigure 25: Question 6: Cut Scenes Watched or SkippedThere will be a skip option if cut-scenes are added to the game. Adventure RPG FPS RTS Simulation Online Games Puzzle ActionFigure 26: Question 7: Favourite Game Genre <5 5 -- 10 10 -- 15 15 -- 2- > 20Figure 27: Question 8: Number of Mobile Games Downloaded
  • 44. <5 5 -- 10 10 -- 15 15 -- 2- > 20Figure 28: Question 9: Number of Mobile Games Paid For <1 1 -- 2 2 -- 3 3 -- 4 4 -- 5 >5Figure 29: Question 10: Average Price (in Euros) Paid for Games 6. Class DiagramThis is a simple overview of the objects that will exist in the game. Somemodifications will be made for each development platform. For example extraclasses for handling audio may be required when developing for Android whereasthose classes are already provided with XNA. RTSGame Game_Entity Item Tree CommandProcessor +size NathanielGame Rock +Initialize() Sprite Agent Buffer +LoadContent() +Update() Level +HealthPoints Corpse +Draw() +isMoveable +UnloadContent() +resources +Attack() +Move() AI_Agent +Die() GameManager ContentManager Weapon Utilities +GetTarget() +power PlayerAgent MeleeWeapon RangedWeapon NPC Monster +range +Hit() +Shoot() Grunt Boss DefensiveStructure Hermes Nathaniel +BuildStructure()Figure 30: First Cut Class Diagram
  • 45. Game Design Document 1. AbstractThis document will outline the design criteria for implementing the Nathanielgame on Android 1.5 and Windows phone 7. The goal of this deliverable is toprovide a detailed specification for the game project. This will be done usingstandard object oriented design methodology and the unified modeling language.All the game storyline, artwork and logic are uniform across platforms. Thedifferent requirements of each platform in the development process will beidentified, elaborated on and compared where appropriate. 2. IntroductionThe 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 thegame should progress.Section 3 will cover the game system design. This will cover the details of actualgame development with regard to logic, storage and screen design.Section 4 covers game play. This section elaborates on the logical and screendesign sections. Here methodologies for ensuring a good user experience areexplored.Section 5 will give images to clarify how the title and menu screens are expectedto look. Section 6, Audio requirements, will detail any special audio requirementsand how they should be dealt with. Finally section 7 will explain the projecttesting strategy, how it will be implemented and any risks involved. 2.2 DescriptionThe game Nathaniel is a 2 dimensional game. It could be considered a 2.5dimensional game as it will be attempting to represent a 3 dimensional world usingonly 2 dimensional textures. The term 2.5 dimensional, often used to describe 2dimensional games with 3 dimensional characteristics, has become more popularwith the increase of game development for mobile devices (Hansford, 2010).The game will use a point and click style control interface. For the initial designthere will be eight levels. The setting is a post-apocalyptic world overrun bymonsters. The user will have control of two characters. The ultimate goal is tosurvive each level and complete the game.
  • 46. 2.3 GenreThe game genre is real time strategy (RTS). A more accurate term for the gamemay be tactical role playing. The term RTS is more widely used for games of thistype however. The characteristics of a real time strategy (RTS) game will beexplained briefly. The term is credited to Brett Sperry which he apparently coinedwhile marketing the game Dune II (Geryk, 2008).RTS is a strategy game which is not turn based but progresses in real time. Realtime strategy is stochastic in nature whereas turn based strategy is deterministic.In an RTS game the participants position and manoeuvre units or structures tosecure areas and/or destroy their opponents assets (Anon, 2010).Generally units and structures are built using resources. Resources are usuallylimited and the gathering of resources is a typical feature of RTS games. These arecharacteristics of the Nathaniel game determined during requirements analysisthat 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 ScenarioThis section will elaborate on a similar section in the requirements analysisdocument by clarifying what scenarios have been decided upon and will now beincorporated to the game.Although there are different levels to the game the basic scenario for each level isthe same. When the game loads the world view will consist of a single area ormap. The map size may vary during the feature adding phase but for initialdevelopment the map size will equal phone screen size.There will be two controllable entities in the game. These are the two maincharacters. The primary character is called Nathaniel. Nathaniel is essentially theonly moveable character that is controllable by the player. The player may selectNathaniel by touching his position on the screen. The player may then touch anyposition on the screen and Nathaniel will move to that position. Nathaniel canattack enemies and collect resources.The other controllable entity is Nathaniel‟s companion called Hermes. Hermes is arobot and during normal game play he is not moveable by the player. The playercan select Hermes by touching his position. When Hermes is selected a menu will
  • 47. appear with a list of available structures that may be built. The player may selecta structure and place that structure by touching an area on the screen or bydragging and dropping a structure from the build menu. Due to screen sizerestrictions and touch screen controls there may be some idiosyncrasies that willhave to be explored during prototyping and development.That is the full list of action a player may perform. There are many variations andrestrictions which will be elaborated on throughout this document but those arethe main actions and functionality that must be considered for the implementationof the player control interface.The other entities that will be visible to a player during the game are the artificialinteligents (AI) agents. These will vary in appearance and characteristics but allwill exhibit similar behaviour and functions. Each AI agent or „Monster‟ will enterfrom outside the map area. Once an AI agent appears on the map they will select atarget. The target is determined by a perceived threat level. Once a target isacquired the AI agent will attack that target until either the target or that AI agentis 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. Attackpower is usually measured in damage per second (DPS). DPS will also be used todetermine which entity on the map exhibits the highest threat.Another component to each level map is the structures. These will likely be themost difficult feature to implement. Some structures may be part of the map andonly exist as obstacles. Some structure may have been built by the player. Eachplayer made structure will have different characteristics. All structures areimmobile. Player made structures will all have an AI component. Some will attackenemy AI agents based on the same threat perception algorithm that the enemy AIagent use. Some structures may heal Nathaniel. Structures on the map willintroduce the need for path finding algorithms in all moveable entities in thegame.2.4.1 Threat Perception Algorithm Create List of targets in range If(list of targets.length > 0) { While (list of targets.length > 0) { Sort list by attackPower in descending order Target = list of targets [0] } } Else { Move to Nathaniel }
  • 48. 2.4.2 Path finding Algorithm Create list of nodes While(Target not reached) { Move to target If(this node = target) { done } Else { If (current node not = Target & is not passable) { Move to empty neighbour node } } } 3. Game StoryThe game story begins approximately fifty years in the future. Earth has become arelatively peaceful place with many great advances in technology althoughadvanced space flight has not yet been achieved. One day a massive objectappeared in the sky over Central Europe. This was an unexpected and fascinatingevent. The fascination was short lived however as the object soon came crashingto the ground. The impact wiped out most of Paris, which wouldn‟t have been toobad, but soon after strange things began to happen around the crash site.People began to change, rapidly. Once, normal human beings soon became violentmonster. Those that didn‟t become monsters went in to hiding or were soon killed
  • 49. by them. Despite all the efforts made by all the counties in the world the outbreakcould not be contained. Within weeks the world was changed forever. Anapocalypse had begun.The actual game play begins 5 years later. There are some safe havens still left onEarth where people who appear to be immune to the strange effects of the alienobject stay together in an effort to survive. Nathaniel and his father have lived aspart of a small community where every day they are subjected to violent attacksfrom 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 andcreation but now uses his talents for the creation of weapons. Alexander hasnearly completed modifications to one of his greatest constructs, Hermes.The opening scene of the game which the player is involved in has Nathaniel andhis father out gathering food. During this sequence they are attacked. Alexander iskilled. Control of Hermes is now entrusted to Nathaniel. After the event Nathanielresolves himself to seek revenge for all that he has lost. He has decided to searchfor 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 alienobject. The hope is that cut scenes may be incorporated into the game in the formof simple comic strips and not animations. This method has been used in othermobile titles and is relatively easy to implement. 4. Game SystemAs part of the overall system there will be three separate applications. Android Game targeted for Android 1.5 and above Windows Phone 7 Game built on the XNA 4.0 framework Windows Communication Foundation 4 RESTful Web Service
  • 50. 4.1 Model for Restful Web ServiceThe ability to upload and download game record data is a small part of the overallapplication. Although it is does not affect the overall game play it is a commonfeature of many games. Offering a player some record of achievement for theirefforts is a good way to enhance the gaming experience. This functionality willalso enable the easy addition of extra features at a later date if they arewarranted. For example the ability for players to set up an online account could beadded.AZURE WCF 4 RESTful Web Service Game Client GetHighScore() GetTopTen() SendTopTen() SendHighScore()The online presence for the game will be hosted on Microsoft‟s cloud computingplatform, Azure. This platform is suitable for an application of this nature due toease 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 datadepending on the request from the game client.4.1.2 REST Application DataWhen a player completes the game they may upload their high score. This action iselective. The client application might never connect to the WCF 4 web service butthe option is available.Data that must be sent to the web service: Players name Players high score Time taken to complete game
  • 51. There will also be an option for a player to view a hall of fame screen in the game. For this, data is requested from the game server. The returned data consists of player scores uploaded from different game clients. The scores are sorted on the server and saved to an XML file.4.2 Persistent Storage Design4.2.1 Save Game DataThe methods to save a games state on the Android and Windows Phone 7 platformsdiffer slightly. The concept and end result is virtually the same however. When thegame 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 notedthat serialization can become very cumbersome on Android devices. To avoidcomplications serialization will be used but during testing but this is an issue thatshould be noted. One interesting alternative is using JSON. Due to the recentlyoptimized Android JSON APIs it is said to be much faster (Lew, 2010). It is alsopossible to GZip saved data. This could be useful if saved game data is to be storedon a server. This is not a requirement of initial design however and may be addedas an extra feature if the schedule permits.For Android the Context manager API will be used to read and write from internalstorage. Any file stored internally is private to the application and cannot bemodified by the user. In the case of Windows Phone 7 the EasyStorage library fromcodeplex will be used to simplify storage. This library uses an API which simplifies
  • 52. reading and writing files to Windows Phone 7 Isolated storage. The library has beenbuilt specifically for the XNA framework.The saved game structure will be set out in the saved game class. Simply savingthe state of every active game object is possible but importance must be placed onkeeping the save file size to a minimum. Game agents such as Hermes, Nathanieland any AI agents should be fully saved as objects. This is required as almost allproperties may be different to the default initialization.Other objects can have individual properties saved such as game screens. It willnot be necessary to save all texture states for example but certain values will needto be set differently during initialization such as current level. Loading the gamewill 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 gameis being loaded or if this is a new level. If the IsBeingLoaded property is true thevalues will be read from the save game file to initialize the level variables andobjects.This is the data that should be written to the saved game file:Class SaveGame{Int level;GameTime gameTime;Player player;Nathaniel Nathaniel;Hermes hermes;ArrayList<AIAgent> enemies;ArrayList<DefensiveStructure> structures;}
  • 53. 4.2.2 Schema for Online High Score Storage<?xml version="1.0"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.nathanielgames.com" xmlns="http://www.nathanielgames.com" elementFormDefault="qualified"> <xs:element name="player_info"> <xs:complexType> <xs:sequence> <xs:element name="name"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="15"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="high_score"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:maxInclusive value="10000"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="hours"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="100"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="minutes"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="59"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="seconds"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="0"/> <xs:maxInclusive value="59"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element></xs:schema>
  • 54. 4.3 Game Play and Screen Design4.3.3 Player ActionsThis game is designed to be played on a hand held device. The screen resolutionsbeing supported initially are 320x480(HVGA) and 480x800(WVGA). The game playand user input will be as simple as possible. All actions should be achievable by theplayer with the use of one hand. All input is through touch screen.There are two basic actions the player performs through touch. Select a selectableelement 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 HermesThose are the only action available to the player. Any goals set for the player tocomplete a level must be accomplished using only these actions. Strategy isapplied by using the correct defensive structures.4.3.2 Defensive StructuresDefensive structures require resources. When an enemy is killed they leave acorpse. Nathaniel can pick up a corpse and deliver it to Hermes to be processedinto resources.The player achieves this by issuing a collect resource order to Nathaniel. Nathanielmust 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 theplayer then selects Hermes the deliver resource order is issued to Nathaniel and hewill move to within range and deliver the corpse.Once Nathaniel is within range Hermes automatically collects the corpse andprocesses it into resources. If Nathaniel is attacked or is issued an attack orderwhile holding a corpse the corpse will be dropped and will disappear.
  • 55. Each defensive structure has a build cost. This cost varies depending on thestructure. If the player does not have enough resources to build a particularstructure 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 structuresavailable. As the game progresses the player will gain the ability to build morestructures with different abilities.The player will have to use strategy in building the correct structures for differentsituations as some will be more effective against certain enemies. Other possibleeffects structures will have may be to heal the player, increase defence, increaseattack or reduce enemy speed. Most structures will have a cool down time afterability is used. For example a structure may only be able to attack in 2 secondintervals or may only be able to heal the player every 30 seconds.4.3.3 Game AIMost elements in the game posses some form of artificial intelligence. Hermes isequipped with a defensive laser. If an enemy comes within range Hermes will fireupon that enemy. Defensive structures that have the ability to attack will fireupon an enemy that is in range. Enemy agents will attack any player agents thatare in range. If there are multiple targets in range the game AI will use a threatdetection 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 spawnedtheir first action is to move towards Nathaniel. The enemy target may changedepending on the effect of the threat algorithm.4.3.4 Win/Lose ConditionsIf Nathaniel or Hermes is killed the player loses. They will then be given the optionof restarting the level or loading a saved game.There will be different win conditions for each level. The standard win conditionwill be to kill all enemies. A level may have a set amount of enemies that will bespawned. Once all have been eliminated the level is won. Other win conditionsmay be specified. Some levels may have an amount of time the player must surviveor have a certain amount of resources to be collected to achieve the wincondition.
  • 56. 4.3.5 Normal Game Play Screen 51 2 3 4 7 6 1. Resource display 2. Nathaniel‟s health bar 3. Hermes health bar 4. Time 5. Menu 6. Nathaniel 7. Hermes 4.3.6 Player Being Attacked 1 1. Enemies
  • 57. 4.3.7 Building Structure Screen 1 2 1. Defensive structure 2. Build menu4.4 Logic DesignThis section will explain what objects exist in the game system and how theyinteract to make up the game. Any complex algorithms and implementationconsiderations will also be discussed.There are some notable differences in the logical design required to implement agame 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 aspossible. XNA 4.0 provides a huge amount of game specific classes that developer‟sgame classes should derive from to ensure stable game functionality.For Android there is no game framework so all game functionality must be codedfrom 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 bespecific to Android.When developing for Android a DrawableGameComponent class will need to becreated. This will allow the already developed classes below to be converted toJava relatively easily without the need to redevelop the game logic. If the gamelogic was to be developed for Android first code reusability would be reduced dueto the fact that none of the classes are guaranteed to conform to the XNAstandards. Developing with XNA first will give a blueprint for overall gamedevelopment.
  • 58. DrawableGame Component GameComponent Game GameAgent +Random random; +SpriteBatch spriteBatch; +Dictionary<string, Animation> animaitons; ScreenManager +bool animationRunning; AudioManager +public Vector2 Position; +List<GamScreen> screens; +public string Name; +SoundEffectInstance musicSound; +List<GameScreen> screensToUpdate; +SpritEffects spriteEffects; +Dictionary<string, SoundEffectInstance> soundBank; +InputState input; MenuEntry +public int currentHP; +bool isInititalised; BuildMenu +void LoadSounds() +public bool IsSelected; +bool traceEnabled; +public int attackPower; +void PlaySounds() Player +SpriteBatch spriteBatch; +void PlayMusic() +void TraceScreens() +Dictionary<string, Animation; +Dictionary<string, int> splitFrames; +void StopSounds() +void AddScreens(GameScreen) +protected NathanielGame curGame; +public Vector2 position; +Texture2D idleTexture; +void RemoveScreen(GameScreen screen) +protected SpriteBatch spriteBatch; +bool IsVisible; +public int moveSpeed; +public Nathaniel nathaniel; +ArrayList<Texture2D> availableStructures; +int range +public Hermes hermes; SaveGame +public int resources; +void getSelectedStructure() +bool CheckTargetInRange() +public int score; +void close() +void Attack() +Int level; +void Draw() +void GetTarget() NathanielGame InpuState +public string name; +GameTime gameTime; +void Draw() +Player player; +public void HandleInput() +void Update(GameTime gameTime) +GraphicsDeviceManager graphics; +TouchCollection TouchState; +Nathaniel Nathaniel; +public override void Draw() +ScreenManager screenManager; +List<GestureSample> Gestures; +Hermes hermes; MenuScreen +public bool SaveGame() +ArrayList<DefensiveStructure> structures; +public bool LoadGame() Hermes +ArrayList<AIAgent> enemies; +public void PlaceStructure() DefensiveStructure +bool IsBuilding; +int buildCost; +BuildMenu buildMenu; MainMenuScreen BackgroundScreen +bool CheckFriendlyHealth() +void ShowBuildMenu() AI_Agent +Texture2D background; +void ProtectFriendly() +int ProcessResources() HallOfFameScreen +void MoveToTarget() +void Retreat() Global InstructionsScreen+bool IsBeingLoaded; +SpriteFont font;+string optionsFile; +GamePlayScreen gamePlayScreen; OptionsScreen+string saveGameFile; +Thread thread;+IAsyncSaveDevice SaveDevice; Nathaniel +public bool HasResource; +public Resource resource; +bool InAggresiveMode; PlayerAgent ArmedMonster Monster Boss +public void getResource() GameScreen +void Move() +Weapon weapon; +Weapon Weapon; +Weapon weapon; GamePlayScreen +Operation1() +public bool IsPopup; +void RechargeHealth() +Texture2D foreground; +public TimeSpan transitionOnTime; +void SpecialAttack() +ArrayList<Texture2D screenTextures>; +public TimeSpan TransitionOffTime; +Vector2 HUDPosition; +public float transitionPosition; +Player player; +public float TransitionAlpha; +public ScreenState ScreenState; Zombie +Nathaniel nathaniel; Animation +Hermes hermes; +public bool IsExiting; +ArrayList<AIAgent> enemies; +public bool IsActive; +Texture2D animatedCharacter; +void EatFlesh() +ArrayList<AIAgent> structures; +public ScreenManager ScreenManager; +Point sheetSize; +bool gameOver; +public GestureType EnableGestures; +public Point currentFrame; +Random random; +public bool IsSerializable; +Point frameSize; +public int level; +public int FrameCount; +void Update(GameTime gameTime, bool, bool) +public Vector Offset +void DrawHud() +void Draw(GameTime gameTime) +public int FrameIndex; +void Start() +bool UpdateTransition(GameTime, TimeSpan, int direction) +public bool IsActive; +void DrawPlayer(GameTime gameTime) +void Serialize(Stream stream) +public Animation; +void DrawAI(GameTime gameTime) +void Deserialize(Stream stream) +void endGame() +void ExitScreen() +void Update() +void LoadLevel() +void HandleInput(InputState input) +void Draw(SpriteBatch spriteBatch, Vector2 position, SpriteEffects spriteEffect) +void PauseGame() +void Draw(SpriteBatch spriteBatch, Vector2 position, float scale, SpriteEffects spriteEffect) +public void PlayFromFrameIndex(int frameIndex)
  • 59. The following classes are provided by the XNA 4.0 framework and are derived fromin the game class structure. Game GameComponent DrawableGameComponentThis is a list of classes that make up the game. A short description of each class isalso 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 GamePlayScreen o Purpose: Extends GameScreen. All game play takes place in this class. All game agents are instantiated and drawn here o The GamePlayScreen class is serializable to allow saving and loading BackgroundScreen o Purpose: Extends GameScreen. Provides a uniform background for menu and title screens ManuScreen o 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 OptionsScreen o Purpose: Extends GameScreen. Allows the player to edit sound options o May be extended to offer more options HallOfFameScreen o 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
  • 60. BuildMenu o Purpose: This class displays a menu of available structures o 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 Global o Purpose: Provides access to any necessary global variables AudioManager o 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 classGame Agent Classes Player o 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 GameAgent o Purpose: This is an abstract class to provide attributes and functionality to derived game agent classes o 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 DefensiveStructure o 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 Hermes o Purpose: Extends PlayerAgent. Hermes is a static object. Provides functionality for processing resources and building structures Nathaniel o Purpose: Extends PlayerAgent. This class represents the main character in the game. All actions are through player input AIAgent o 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.
  • 61. It does not extend the Monster class as it uses different functionality rather than extending functionality Monster o 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 Zombie o 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. Boss o Purpose: Extends AIAgent. This class will be used to create game bosses. 5. Title and Information ScreensThe following are some mock ups of the main menu, options and hall of famescreen.5.1 Main Menu Screen
  • 62. 5.2 Option Screen5.3 Hall of Fame Screen 6. Audio RequirementsAll audio for an Android application must be saved in the res/raw folder. The Javaimplementation of sound is done through the MediaPlayer API. Mp3 files will beused for audio. For XNA the SoundEffect and Stream classes will be used. Wav files are thepreferred format but without any special requirements mp3 files are acceptable. 7. Testing Strategy and Plan7.1 Testing StrategyDue to the complexity of a game system constant testing is required. Thedevelopment process will be agile in nature.
  • 63. Coding unit testing (white box testing) system testing (black box testing)These will occur in a cyclical manner. As the game is developed component testingwill be carried out to ensure each module is working correctly. Featuredevelopment will be graduated in a set timeline at which system testing mustoccur. This should be done in two week rotations. For example once developmentstarts 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 charactersThis core functionality should be achievable and testable within two weeks. Fourweeks are allocated so there is a margin for error. Each function is testable. Oncethe main character is coded an image of that character can be rendered to thegame screen. The ability to move can be tested. If all functionality is ready withintwo weeks the system can be tested as a whole. Strange bugs can appear at thispoint 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 tested 2. The project must build every day 3. A predetermined set of functionality must be added every two weeks 4. At each two week milestone the game must be fully playable. 5. Exhaustive play testing will be carried out 6. Functionality will be planned for the next two week to include bug fixes discovered and functionality that wasn‟t completed on time
  • 64. 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 System UI Task Name Description Passed/Failed Test Test Test Figure 31 Test LogsTask: Date:Action:Expected Result:Actual Result:Comments: Figure 32 Bug reporting
  • 65. 7.2.2 Components to TestWhile functionality is the most obvious aspect of the game to test other areas mustbe 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 optionsThese components may be tested positively in play testing.7.2.3 Performance TestingPerformance is always an important issue with games. Due to this game running onmobile devices with limited resources performance is a critical testing area.Memory management, intensive computing leading to battery drain and framerates 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
  • 66. Installation Manual Document 1. Windows Phone 7The windows phone 7 version of the software is packaged in a .XAP file. To run theapplication in an emulator the windows phone developer tools are required. Theseare available for free at http://create.msdn.com/en-US/.The tools provide an application deployment interface to deploy to either thedeveloper tools emulator or to an actual device. Once run the screen shown inFigure 33 is displayed. Browse to the location of the XAP file and choose the targetplatform to deploy to. That‟s all there is to deploying the software for windowsphone 7.Figure 33 Application Deployment Screen 2. AndroidThe Android version of the software is packaged in a .apk file. To deploy to adevice or emulator the android SDK is required. The SDK is available herehttp://developer.android.com/sdk/index.html.If you are deploying to a device some settings may need to be altered. On thephone go to Settings, select “Application Settings” and then enable “UnknownSources.” Also under Settings, select “SD Card” and “Phone Storage,” and finallyenable “Disable Use for USB Storage”.All going well once you have installed the SDK in Windows, Mac or Linux the adbshould be added to your build path. This should allow deployment to the emulatorif it is running or to a device if it is connected using this simple command in thesystem command prompt console. “adb install ”application path””applicationname”.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:ruairigamesNathaniel.apk”.
  • 67. Post Project Review Document 1. ReviewDeveloping a game is a long and challenging process. So many aspects of softwaredevelopment are involved in the creation of such a complex interactiveapplication. Although at times the project seemed like a bad idea, mainly due tothe volume of work required and countless problems to overcome, the experienceand knowledge gained from completing it were invaluable.Figure 34 Main Menu ScreenGame 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 andprofessional software engineers currently working in any field of computing. Theskill level required to implement extremely complex AI, graphics and performanceenhancements is quite high.Figure 35 Gameplay Screen
  • 68. The project did not end up exactly what as was intended first day. In some ways itis better in others worse. Sometimes aspects of programming could clash withrequirements of good game play. The human element had to be considered at alltime.Planning for human interaction is in my opinion what makes game developmentand many other forms of software development so interesting and enjoyable totake part in. Overall the project was an extremely enjoyable and beneficialexperience. 2. Future of the ProjectThe original intention of the project was to have an Android game released on theAndroid Market before April 2011 and a Windows Phone 7 game on MicrosoftsAppHub before April 2011. This didn‟t happen due to issues with game art. Opensource art had to be used but it would be far preferable to use original art. At thetime of writing, exams are now a priority so the release of the game to market isbeing temporarily shelved.In the future the game will be improved, better art will be added and it will bereleased for free and open sourced. Perhaps in the long term as personal softwaredevelopment skills are improved an nice version 2 can be made and charged for.
  • 69. 3. Minutes of Meetings05 – 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 platformResearch paper, first draft is due tomorrow the 13th of October 2010.
  • 70. PrototypeThe prototype demonstrates a minimalistic set of features that will be present inthe complete application. Little effort has been put in to how the display ispresented 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.
  • 71. 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 attackedAll the functionality mentioned above has been fully implemented. The enemy AI isstill fairly basic. Enemies will try to attack the man character. If they are closer tothe 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 elementof 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 somemore features ready by tomorrow such as saving a game and building defensivestructures.
  • 72. 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.
  • 73. BibliographyAnon, 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 [Accessed13 October 2010].Chen, B., 2009. Gadgetlad. [Online] Available at:http://www.wired.com/gadgetlab/2009/11/appstore/ [Accessed 14 October2010].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/ [Accessed13 Octiber 2010].McSaffery, M., 2009. Game Programming Complete. Charles River Media.
  • 74. Parr, B., 2010. Google Is Now Appless Greatest Enemy: Heres 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 ReadingMann, 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.phpHargreaves, S (2008). Game programming with the XNA Framework. RetrievedOctober 14, 2010, Available from:http://blogs.msdn.com/b/shawnhar/archive/2008/11/24/content-pipeline-assemblies.aspxIoannis (2009). XNA Game Development. Progware. Retrieved October 14, 2010,Available from: http://www.progware.org/Blog/post/XNA-Game-Development-(First-Steps).aspx