Final Year Project Report

Transcription

1 Final Year Project Report ios Game Utilising an A* Path Finding Algorithm Project ID: R002 BSc Applied Computer Science University of Reading School of Systems Engineering SE3IP11 Individual Project Blair Peter Trusler Project Supervisor: Dr James Ferryman Second Reader: Dr Hong Wei 20/04/2012

2 Abstract The goal of this project was to develop a game for the Apple ios platform. The project combined four core components; learning ios development, utilising Cocos2D (game/graphics engine), creating user control methods, and implementing an A* path finding algorithm. It also involved integrating the game with Apple s Game Center application programmable interface (API) to include achievement and leaderboard features. The game was developed as a universal application, meaning that it was compatible with all Apple ios devices such as the iphone and ipad. A detailed set of requirements and specifications was set out at the beginning of the project. One example of a requirement was that the game was to be developed in a 2D orthogonal style. Another requirement was that five levels of varying difficulty were to be developed. All of the specified requirements were fulfilled upon the completion of the project. Writing a full set of specifications early on helped greatly in prioritising features to implement and manage the time spent on each section of the project. All of these elements were combined to create an overall game, The Minotaur s Lair. The objective of the game was to escape the labyrinth of the Minotaur without being caught. There were two types of enemies within the labyrinth; the Minotaur and Guards. If the player was caught by a Guard, they would be returned to the start of the level. If the player was caught by the Minotaur, the game would be over. Levels four and five were developed with dynamic elements to them (for example randomised spawn points). The game was released on the Apple App Store towards the end of the project lifecycle. It received over one thousand downloads in it s first week on the store. Potential future developments of the game were considered upon completion of the project. This included procedural map generation (ensuring a new and varied game experience every time), multiplayer modes and porting the game to the Mac and Android platforms. 2

3 Contents 1. Introduction Background Aims and Objectives Academic Objectives and Outputs Personal Objectives and Outputs Research The Video Games Industry and ios Gaming A* Path Finding A* Path Finding in Video Games Overall Specification Analysis and Design Analysis Requirements Analysis Specification Risk Analysis Design Game Theme Game Objectives Menu Design Interface/HUD Level Design Sprite Design Program Flow Development and Implementation Software and Device Specifications Development Plan Implementation Stages Stages 1 5: Underlying Game Components Stages 6 8: Heads-Up-Display Components: Directional Pad and Buttons Stage 9: Sprite Animation Stages 10-11: Spawning the Minotaur and Level Stages 12-13: Gameplay Mechanic: Implementing A* Path Finding Algorithm Stages 14-16: Menus, Universal Device Scaling and Game Center Integration Stages 16-17: Expanding the game: Tilt Controls and Additional Levels Stages 19-20: Guard Sprites and Patrolling the Labyrinth Stage 21: Adding Variation Stage 22: Music and Sound Effects Stage 23: Testing, Bug Fixing and Polishing Stages 24-25: App Store Submission and Feedback

4 4. Results A* Path Finding Overall Game App Store Testing and Quality Testing Problems Encountered During Testing Quality Assurance Summary, Conclusions and Critique Completion Assessment Time Cost Analysis Potential Improvements to Project Approach Potential Future Development Conclusion References Appendices Appendix A Risk and Time Analysis Appendix B Screen Designs Appendix C Level Design Appendix D Spritesheets Appendix E Menu/Level Flow Diagrams Appendix F Class Diagrams Appendix G Final Game Results Appendix H Generated Coordinates between Minotaur and Player spawns (Level 1) Appendix I App Store Data and Reviews Appendix J Coverage on Hookshot Inc Appendix K Questionnaire Results Appendix L Actual Development Time Gantt Chart Appendix M Game User Guide Appendix N Project Log Book Appendix O Code

5 Glossary NPC HUD D-Pad ios Non-Player Character Heads-Up Display Directional Pad i Operating System (operating system used by Apple portable devices) 5

6 1. Introduction This document will provide a detailed review of the many aspects involved in developing a game for the ios [1] platform (the operating system that is used on Apple portable devices). The project combines work in two of the most dynamic and exciting fields in the world of modern computing; ios and video game development. The report will cover the analysis and design phases (Section 2), development and implementation stages (Section 3), the results achieved (Section 4), testing and quality assurance taken place (Section 5) and an overall summary and conclusion of the project (Section 6). 1.1 Background Video games are becoming an increasing part of everyday life thanks to the birth of the smart phone and tablet (such as the iphone [2] and ipad [3]). Casual gaming has become one of the fastest growing genres of video games in recent years, particularly on handheld devices. A casual game is a video game aimed at a wide demographic. These are typically simple games with intuitive and addictive gameplay. Casual games do not require a large amount of time to be dedicated to them, unlike the classic style of hardcore games. Hardcore games traditionally have complex story and gameplay mechanics which take time to master. Hardcore games often make use of complicated, high-end graphics that require a high-specification device to run them effectively and they are therefore expensive to purchase. In contrast, casual games are usually much more favourably priced in order to reach a greater audience. Casual games are also spreading into the traditionally hardcore console market; nine of the top thirty games sold in 2010 were casual games (mostly on the Nintendo Wii) [4]. Casual games are the most heavily downloaded genre of game on ios devices. The most popular and well known casual game on the ios platform is Angry Birds, which recently reached a monumental milestone of 500 million downloads [5]. 6

7 The first commercially successful casual game was Pac-Man [6], which was originally released in Casual games have changed drastically since then with the increased portability of electronic devices and the emergence of platforms such as the Apple App Store [7]. These platforms have allowed both professional and indie [8] game developers to reach a wide audience of gamers worldwide for a very low initial cost (to release a game or application on the App Store, an Apple Developer s License would be required at the cost of 60[9]). 1.2 Aims and Objectives The overall objective of this project was to create an expandable framework for an ios game that could be developed further in the future to release more content and features to the players. Game development is a very time consuming process with many aspects to consider ranging from the highest level of what the player will see to the lowest level to the features that allow the game to run, for example the art style of the game to game engine development. Video games are typically developed in teams over a long period of time. Because of these factors and the time constraints of the project, the objective was to develop a 2D prototype of a game. The goal was to create five levels of varying difficulty to give an overview of what the complete game would be like. Given more time, additional levels and features could be added to substantiate a full game. The ultimate aim for the project was to release the game to the App Store as a free download to share with gamers around the world. This would also assist in receiving feedback on any bugs or potential improvements that could be made to the game Academic Objectives and Outputs There were several key academic objectives that needed to be achieved throughout the development of the project. The first objective was to become proficient in programming 7

8 with the Objective-C language whilst conforming to the conventional standards recommended by Apple. This also involved utilising Cocos2D, a third party game/graphics engine, which provided the ability to render and animate scenes and sprites. A second academic objective was to learn the foundations of game design (such as game balancing and level design) and programming (for example game loops and sprite animations). Utilising these established techniques and implementing them efficiently was one of the key objectives of the project. A large part of the game design revolved around the concept of path finding algorithms. The A* method of path finding was used in this project. Understanding and implementing this type of path finding algorithm into the game was the largest challenge of the project. The overall academic objective was to learn and implement all of these concepts to a high standard Personal Objectives and Outputs There were two main personal objectives for undertaking this project. As mentioned previously, one goal of the project was to learn the various elements of game design and development. A personal goal is to work in the video games industry and so achieving a greater understanding of how to develop games was an important objective. The second personal objective was to develop the game to the highest technical level possible so that it could be demonstrable to video game companies when looking for jobs in the industry. 8

9 1.3 Research The Video Games Industry and ios Gaming The video games industry has become one of the largest industries in the world with more than $18.58 billion in revenue in 2010 alone [10]. Video games have become one of the primary sources of entertainment and in recent years have become an ever-growing threat to the movie industry. The movie industry had a total box office gross of $31.8 billion in 2010 [11]. This bodes well for the evolving video games industry as it will challenge for market share in the coming years. Developing for ios devices has become an industry in itself in recent years. With over 160 million ios devices sold worldwide [12], it has become a major market for software developers around the world. Apple created the App Store in such a way that it is easy for even the smallest of developers to release Apps and make a career out of developing games. The combination of video games and ios is a special one. Over 5 million ios games are downloaded every day [13], and the popular game Angry Birds (which was released in December 2009) has grossed roughly $70 million [14]. This project provided the opportunity to learn about game development and ios development techniques. These are two very prominent and ever emerging markets, which show signs of further growth in the future A* Path Finding A* path finding was a major part of the project and so it was important to understand the methodology behind it. A high level definition of A* path finding is that it is an algorithm which calculates the shortest path between two points on a plane [15]. Many definitions of A* use the concept of nodes. A node is a point on the plane that can be traversed. In the context of the game, each node represents one individual tile on the game map. 9

10 At its core, A* consists of two elements; an Open List and a Closed List [16]. The Open List is a list that contains the coordinates of tiles yet to be explored. The Closed List is a list that contains the coordinates of tiles that have already been explored and make up part of the optimum path. The key factor that differentiates A* from other path finding techniques (such as rational/non rational [17] and Depth-First Search [18]) is the heuristic (estimation) element to it [19]. The equation often used to explain how A* determines the optimum path is shown below: F = G + H [16] F represented the total cost of the path. G represented the cost to move from the starting point to a given tile on the map. H was the heuristic element. It represented the estimated cost to move from a given tile on the map to the final destination tile. The closer H was to the actual distance, the more efficient the path would be. A path would be generated by repeatedly cycling through the tiles in the Open List. The tile with the lowest F score would be chosen upon each cycle. This path would then be used to provide the coordinates used to control Non-Player Character (NPC) sprite movement. Further details on A* path finding will be discussed in the implementation section of the report A* Path Finding in Video Games One of the most common uses of A* path finding is found in video games for controlling character movement around a game world (both user-controlled or computer-controlled characters). The most frequent occurrence can be seen in real-time strategy games [15][20] whereby the player directs the movement of a large number of units or sprites around a game map. 10

11 The use of A* is not restricted to this type of game but it is also used in a wide range of genres for controlling enemy character movement patterns. A* is most common in 2D, isometric and/or orthogonal [21] games as the movement plane is more simple. In 3D games, a combination of path finding methods is often used (such as waypoints or navigation meshes) [22]. As the game was to be designed in a 2D orthogonal plane, it was decided to use the A* method of path finding in the project to control the movement of the NPCs. 1.4 Overall Specification The game should be developed as an orthogonal, 2D game for the ios platform. There should be a menu system allowing the user to access the game levels and various other features easily and intuitively. Once in a level, there should be a Heads-Up-Display (HUD) layer to enable user inputs and interactions. There should be a player-controllable sprite in the game, along with NPC sprites. There should be a collision detection system so that the player can interact with obstacles and is restricted to the confines of the game world. A more detailed set of requirements and specifications can be found in Section 2 of this document. 11

12 2. Analysis and Design 2.1 Analysis There are many aspects to consider and to take into account when developing a game. Therefore, it was essential to perform a detailed level of requirements analysis in order to produce a complete specification to aid the development of the game. The results of this analysis are outlined within this section of the report. The primary outcome of the analysis resulted in the generation of a full set of requirements and a respective set of specifications for the project. 2.2 Requirements Analysis A detailed requirements analysis of the project was performed before development began. The result of this analysis can be seen below. The game should be developed as a universal application [23]. o To enable use on all types of ios devices (such as ipad, iphone, ipod Touch etc). A Main Menu should appear upon launching the game. There should be a Credits and Guide screen, accessible from the Main Menu. o The Credits screen should show references for any art and sound used in the game. o The Guide screen should provide a basic explanation of the game rules and mechanics. The Level Select screen should allow the user to select a level to play, accessible from the Main Menu. o It should show high scores for each level (if applicable). o There should be an option to select a level at random. There should be a pause menu located in the game and on the Main Menu and Level Select screens. 12

13 It should be easy for the user to navigate through the application. o The buttons should be appropriately labeled. o There should be a way to return to the Main Menu through the Pause screen. There should be sound effects and music in the game. o It should be possible to mute the sound through the pause menu. There should be an option for the user to select a preferred game control method. o These options should allow the user to choose between D-Pad or Accelerometer controls. The game itself should be 2D with an orthogonal point of view of the game world. There should be collision detection so that the player cannot walk through obstacles or objects on the game map. Once in a level, there should be a Heads-Up-Display (HUD) to enable user inputs. o There should be a D-Pad located on the bottom-left hand-side of the screen. o There should be a player speed boost button located on the bottom-right hand-side of the screen. o There should be a pause button located on the top-right hand-side of the screen. Two types of Non-Player Characters (NPCs) should be generated. One NPC sprite should chase the player around the labyrinth. o If the player is caught by this sprite, the game is over. Other sprites should patrol around parts of the map. o If the player is caught by these sprites, the player should be sent back to the beginning of the level. The game should be integrated with Apple s Game Center API [24]. o Options to view achievements and leaderboards should be provided within the game. 13

14 2.3 Specification After formulating the requirements for the project, a full set of specifications was drawn up. This was necessary in order to ensure all of the desired objectives were achieved. The specifications for each of the requirements for the project are shown below. Requirement(s) The game should be developed as a universal application. A Main Menu should appear when launching the game. There should be a Credits and Guide screen, accessible from the Main Menu. There should be a Credits and Guide screen, accessible from the Main Menu. Specification Project set as Universal Application within Xcode [23]. Menu and HUD elements should be aligned within the confines of the ios device screen. ipad: 1024x768 iphone: 960x640 Operate in landscape orientation. Image based on the game theme positioned centrally in background. Offer options to access the following: Level Select screen Guide screen Credits screen Pause Menu Game Over/Level Complete screen Position menu components within the confines of the ios device screen. ipad: 1024x768 iphone: 960x640 Operate in landscape orientation. Button positioned at top-right of screen to return menu to Main Menu. Fit screen components within the confines of the ios device screen. ipad: 1024x768 14

15 iphone: 960x640 The Level Select screen Operate in landscape orientation. should allow the user to Scroll View to scroll through multiple screens. select a level to play, Each scroll view screen will represent one level to be accessible from the Main Menu. selected. Represent high scores as stars (up to 3 stars). High scores stored in NSUserDefaults. If running on ipad, show screenshot of level in centre of screen. If running on iphone, do not show screenshot of level. The random level select button should be located on the first scroll view screen. Fit screen components within the confines of the ios device screen. ipad: 1024x768 iphone: 960x640 There should be a Pause Menu located in the game and on the Main Menu and Level Select screens. Operate in landscape orientation. If accessed from Main Menu or Level Select, offer option to return to previous screen. If accessed from within game, offer option to return to Main Menu or Retry Level. Offer option to Mute Sound. Fit screen components within the confines of the ios device screen. ipad: 1024x768 iphone: 960x640 It should be easy for the user Minimum button size of 32x32 pixels. to navigate through the Design buttons so that functionality is intuitive. application. There should be sound One song for all menu screens. 15

16 effects and music in the game. There should be an option for the user to select a preferred game control method. The game itself should be 2D with an orthogonal point of view of the game world. There should be collision detection so that the player cannot walk through obstacles or objects on the game map. Once in a level, there should be a Heads-Up-Display (HUD) to enable user inputs. Different music for each game level. Sound mute button located in Pause Menu. Located on the Main Menu screen. Choice between D-Pad or Accelerometer controls. Implement D-Pad using SneakyInput [25] framework. Label choice as D-Pad or Tilt. Position option on Main Menu. Disable touch input on layer. Maps designed using Tiled [26] map editing software. Tiles 32x32 pixels in size. Overall map between 40x40 to 60x60 tiles in size. Consist of four layers; Background, Objects, Foreground and Meta. Player and NPC spawn points set in Objects layer. Walls and obstacles highlighted in Meta layer. Objects and Meta layer set to hidden. Check player position against tiles marked as hidden. Detect using update method (check every 1/60 th of a second). Bounding boxes to detect sprite collisions. Enable touch input on layer. D-Pad made up of two PNG images; one for movement pad, one for outline pad. D-Pad positioned at bottom-left of layer. D-Pad only visible if D-Pad controls has been selected from Main Menu screen. Player Speed Boost button positioned at bottom-right of layer. Pause Menu button positioned at top-right of screen. Fit HUD components within the confines of the ios device 16

17 Two types of Non-Player Characters (NPCs) should be generated. One NPC sprite should chase the player around the labyrinth. Other sprites should patrol around parts of the map. The game should be integrated with Apple s Game Center API. screen. ipad: 1024x768 iphone: 960x640 Two different spritesheets. Spritesheets consist of 12 images. 3 images for each direction; up, down, left, right. Using A* path finding algorithm. Path should avoid collisions with walls and other obstacles. Check at regular intervals for new path. One of these types of sprite in each level. Using A* path finding algorithm. Path should avoid collisions with walls and other obstacles. Only calculate paths upon level launching. Number of sprites varies depending on level. Achievement and Leaderboard features. Achievements rewarded for completing levels etc. Leaderboards to show best times for completing levels. Both features accessible from within the application. Achievement button on Main Menu screen. Leaderboard button on Level Select scrolling screens. Table 2.1 Project specifications 2.4 Risk Analysis As with any software development project, there was an element of risk in undertaking the project. Therefore, it was important to identify, manage and prepare for any potential risks early on in the project lifecycle. 17

18 One of the largest risks considered in a project such as this was data loss. Hard drives have a tendency to be temperamental and so it was important to account for possibility of data loss. To mitigate this risk, a cloud-hosted subversion was used throughout the development of the project. This ensured that any work or modifications to the project were regularly saved and maintained in a secure remote location. To further reduce the risk of data loss, regular back-ups of the project and documentation were committed to an external hard drive and a Dropbox [27] folder (cloud-hosted file storage system). Another important risk that was considered was the allocation of time for the project. There was the possibility that other pieces of coursework for other modules on the degree programme could have had an impact on the time dedicated to the project. To counter this, it was important to produce a time plan of the project in advance allowing for contingency time in case the issue arose. If this issue was to arise, it was important to allocate additional time to focus on the project on the following days or weeks to catch up and get back on schedule. A Gantt chart was produced in order to achieve an overview of how the development flow should be. The chart can be found in Appendix A of the report. It was also likely that some difficulties in the development process would be encountered. Some problems may have taken more time to resolve than others (such as syntax errors or problems with an algorithm). To reduce this risk, the project was developed in an agile, iterative approach. Small, achievable milestones and goals were set each week. This helped to cut down the risk of the project becoming stagnant for long periods of time. It was also important to have a clear vision for the project throughout and so the production of a solid set of requirements and specifications was important. The risk register for the project can be found in Appendix A of the report. The register highlighted the likelihood, impact and significance of each potential risk. 18

19 2.5 Design Game Theme In order to create a game out of the specifications set out above, a theme needed to be determined. It was decided to theme the game around the tale of Theseus and the Minotaur from Greek mythology. The name given to the game was "The Minotaur's Lair". In the tale, Theseus was sent into the labyrinth to slay the Minotaur. In the game adaptation, Theseus is trapped in the labyrinth and must escape the labyrinth Game Objectives A win-loss mechanic was needed in order to create a game out of the theme. The main objective of the game was for the player to escape the labyrinth without being caught by the Minotaur. If the Minotaur caught the player, the game would be over and the player would receive the option to retry the level or return to the Main Menu screen. There would also be additional enemy NPCs located at various positions of the labyrinth. These NPCs were called "Guards". The Guard NPCs would patrol around sections of the map (using the same path finding algorithm) to add an extra element of difficulty. If the player were caught by one of the Guards, they would be sent back to the beginning of the map Menu Design The user would interface with the game menus through touch input. The menus were designed in accordance to Apple s interface guidelines and suggestions. There were seven menu screens to be designed; Main Menu, Level Select Menu, Pause Menu, Guide Menu, Credits Menu, Game Over Menu and Level Complete Menu. 19

20 Figure 2.1 shows the design for the Main Menu screen of the game. Designs of the other menu screens can be found in Appendix B. Achievements button Pause Menu button The Minotaur s Lair Background Image Level Select Guide D- Pad/Tilt Credits Figure 2.1 Main Menu screen design (ipad aspect ratio) Interface/HUD As with the Menu design, the game HUD will be fully accessible through touch input. The aim was to create a similar interface as handheld video game consoles when in a game level. A typical layout of a handheld video games console can be seen in Figure 2.2 with the Nintendo Gameboy Advance. D-Pad Action Buttons Figure 2.2 Nintendo Gameboy Advance 20

21 Unlike the Nintendo Gameboy, ios devices do not use physical buttons, thus a graphical user interface (GUI) layer must sit above the game itself. The GUI has been designed so that it is simple and intuitive to use so that the player can have their full attention directed to the game itself. The D-Pad was positioned on the bottom-left hand side of the screen to allow the user to move the sprite around the game map. An action button was positioned on the bottom-right hand side of the screen to allow the player to boost their running speed temporarily. The design of the HUD is shown in Figure 2.3. Level Number Timer: 0:00 Pause Menu button Game World D- Pad Speed Boost button Figure 2.3 Heads-Up-Display design (ipad aspect ratio) Level Design Level design is a vital part of any game. The game levels were designed using the Tiled [26] map editing software. The maps were manually constructed using 32x32 pixel-sized tiles. Each map consisted of four layers of tiles; Background, Objects, Foreground and Meta layers. The Background layer contained the floor tiles of the map. The Objects layer contained the coordinates of the spawn points for all of the sprites in the level. It also contained coordinates for patrol points for the Guard sprites. The Foreground layer 21

22 contained the tiles for the walls, obstacles and other details that sat above the background of the map. The Meta layer consisted of transparent tiles. These tiles were tagged as Collidable or Warp tiles. The Collidable tiles were positioned on walls and other obstacles in the level. The purpose of the Collidable tiles was to confine the player to the space of the game level. The Warp tiles were positioned at the level exits. The purpose of the Warp tiles was to check if the level was complete and act as a trigger to launch the Level Complete screen. The Objects and Meta layer were set as hidden when running in the game. These layers are not necessary to be viewed by the player and hinder the level of immersion with the game. Figure 2.4 shows a level of the game being designed using Tiled Map Editor. Appendix C contains further screenshots of each individual level of the game being designed in Tiled and the completed level that the player would see (Objects and Meta layers hidden). The tileset used to design the levels was not designed specifically for this project and was referenced in the Credits screen of the game and in Appendix B. Figure 2.4. Level 1 being designed in Tiled Map Editor 22

23 2.5.6 Sprite Design Each type of sprite in the game was made up of twelve separate images that were combined into a singular spritesheet. There were three images for each direction the character could move in. This was needed in order to animate the sprites when moving around the game level. Containing all of the images in a single spritesheet was the most efficient way of accessing and storing sprite information from within the game. The spritesheets used in the game were not designed specifically for this project and were taken from various game design websites. Figure 2.5 shows the spritesheet for the player character. All of the spritesheets used in the project can be found and referenced in Appendix D. They were also referenced in the Credits screen of the game. Figure 2.5 Player character spritesheet 23

24 2.5.7 Program Flow At the beginning of the project it was important to achieve an understanding of how the application would run. As such, two flow diagrams showing menu and level flow were produced to aid the implementation process of the project. All of the flow diagrams produced for this project can be found in Appendix E. Figure 2.6 Menu flow 24

25 Figure 2.7 Game flow 25

26 3. Development and Implementation 3.1 Software and Device Specifications The development of the game took place on an imac 27 [28] desktop computer and a MacBook Pro 13 [29] laptop. The game development itself was took place in the Xcode development environment. Xcode is the standard development environment used for developing ios and Mac applications. The Cocos2D game engine framework was used to develop the game. The Cocos2D files and headers were imported into the Xcode project in order to utilise them. A subversion repository [30] was kept throughout development as well as regular back-ups to a Dropbox account [27] and external hard drive. 3.2 Development Plan The previous section explaining the analysis and design of the project has shown that there were many aspects to consider when developing the game. As such, it was important to create a plan to determine the order in which to implement each feature as required in the specifications. This plan can be seen in Table 3.1. Stage Feature to implement 1 Load simple.tmx Tiled map on screen (consisting of the four defined layers; Background, Objects, Foreground and Meta). 2 Load a static (non-animated) sprite on screen (using the spawn point allocated in the.tmx map). 3 Implement camera to maintain screen focused on player s sprite position. 4 Allow basic user input to control sprite movement around map (tap-to-move). 5 Implement collision detection between player sprite and obstacles. 6 Implement an additional layer above gameplay layer to act as the game HUD. 26

27 7 Add buttons/d-pad to HUD and detect input. 8 Implement D-Pad to control player s sprite movement using SneakyInput (disable previous movement method). 9 Animate player s sprite during movement using spritesheet (3 frames for each direction of movement). 10 Spawn NPC (Minotaur) sprite in map. 11 Design Level 1 maze with player sprite and Minotaur at opposite ends of maze. 12 Implement an A* path finding algorithm to calculate path between the two sprites through the maze. 13 Move and animate Minotaur along generated path to player position. 14 Create menu screens and ensure flow conforms to program flow as defined in Section Scale Menus and HUD to iphone screen size as well as ipad. 16 Implement Game Center achievements and leaderboards to game. 17 Implement accelerometer/tilt control method. 18 Make additional levels using same method as before. 19 Spawn additional NPC sprites (Guards). 20 Move Guards along set patrol paths using A* path finding algorithm. 21 Add elements of variation to spawning and patrol paths in levels. 22 Add sound effects and music. 23 Testing, bug fixing and game polishing/tweaking. 24 Submit to App Store. 25 Receive feedback and fix any bugs or errors reported by users. Table 3.1 Development hierarchy 27

28 3.3 Implementation Stages The following section describes how each major section of the project was implemented. Class diagrams for the project can be found in Appendix F Stages 1 5: Underlying Game Components Stages 1 to 5 were crucial to the overall outcome of the project. During these a solid underlying framework was developed for the game which could then be developed further. These features were implemented as the gameplay layer (using CCLayer [31]) in a class called Level1. CCLayer inherits many Cocos2D features such as camera and touch delegates. As the name describes, CCLayer allows multiple screens to be layered on top of one another within one single scene, allowing for a HUD to be implemented later on in the project. Stages 1 and 2 were very quick to implement as Cocos2D provides the ability to load sprites, maps and other files with very little code. Implementing a camera to focus on the player sprite position was more challenging. Initially, the camera was developed so that the position was always directly above the player sprite position no matter where the sprite was located on the map. However this became an issue when the sprite was positioned near the edge of the map. It resulted in a large quantity of blank space taking up a significant portion of the screen estate of the device. As such, it was important to check the actual position of the sprite as well as the centered position. This meant performing a subtraction of the actual position with the centered position of view. Camera viewpoint coordinates = subtract (centre of view, actual position) Once the camera feature had been implemented, it was necessary to develop an initial form of user-controlled sprite movement. This was a very simple tap-to-move mechanic. This was achieved by using the cctouchended [32] method included in the 28

29 Cocos2D framework (within the CCTouchDispatcher [32] header). This method is called once a touch input has been received and ended (when the user releases their finger(s) from the screen). Once a touch was registered, the position of the touch was stored within a CGPoint [33] (variable used to store coordinates). The sprite was then moved from its current position to the touch position using a simple CCAction [34] (method for performing a simple action or animation on a sprite). The next priority was to implement a collision detection system. This was to ensure that the sprite position was restricted to the confines of the designed map. In order to do this, it was first important to schedule an update method in the game. The update was scheduled simply by calling the scheduleupdate [35] function in the initialization method of the level. This scheduled an update method to be called every 1/60 th of a second. Within this method, a simple check was performed between the current player sprite position and whether this position matched that of the tiles marked as Collidable in the.tmx map. If this check returned a true value, the player sprite was hitting an obstacle on the map and so the player movement was terminated and the method was returned Stages 6 8: Heads-Up-Display Components: Directional Pad and Buttons Before implementing the HUD, it was important to disable touch inputs from being registered on the gameplay layer that had been developed in the previous stages. This was necessary in order to allow for the HUD to register touch inputs (for the D-Pad and other on-screen buttons). This meant disabling and removing the initial user sprite movement method. A single HUD class was developed in order to allow it to be used across multiple levels. As with the gameplay layer, the HUD was implemented as a CCLayer. This layer was called once the level was launched and was positioned above the gameplay layer. There were three main elements to implement in the HUD; the D-Pad, Pause Menu button and Speed Boost button. The first element implemented was the D-Pad. 29

30 Various methods of creating a D-Pad for the user to control the player character were tried and tested. However, the most effective and fluid D-Pad was achieved by using SneakyInput [25]. SneakyInput is an open-source ios framework for implementing a D-Pad or fully directional joystick into a project. Using this framework to implement the D-Pad helped to save a vast quantity of time and accelerated the development process of the project. It was decided to use the D-Pad as opposed to the fully directional joystick for several reasons. Primarily, it would add a further element of difficulty when traversing the labyrinth and running away from the Minotaur and Guards. The D-Pad option also meant that only four directions of animation needed to be considered (up, down, left, right) as opposed to eight or more (varying degrees of diagonal movement). The reasoning for this decision was discussed further in Section Once this initial control method was established, it was decided to focus on implementing other features of the game and to implement the accelerometer control method later on in the project. The two remaining HUD elements to implement were the Pause Menu and Speed Boost buttons. These were implemented in the same way using CCMenuItem [36], even though their functionality was vastly different. Once pressed, the Speed Boost button increased the player sprite movement speed by a multiplier of 120 for four seconds. Once the button was pressed the function was then disabled for twenty seconds. This was to prevent the boost from being over used by the player and hence making the game too easy. The Pause Menu button performed two main actions. Firstly, it used the CCDirector [37] functionality to pause the current scene. Then, a new scene was pushed on top of the current scene to represent the Pause Menu (scenes in Cocos2D behave in a similar way to stacks [38][39]). This scene was developed with limited functionality and only contained a button to return to the previous scene and un-paused the CCDirector. The Pause Menu was fully implemented with additional functionality in Stage 14 of the implementation process. 30

31 3.3.3 Stage 9: Sprite Animation At this stage in the implementation process, a HUD and a basic game map had been implemented. The D-Pad in the HUD allowed the user to move the player sprite around the game map. However, the player sprite was a static image and was not animated to simulate walking. As mentioned in Section 2.2.2, the D-Pad was chosen as the user control method as it limited the number of sprite directions to four. This was not a problem in terms of programming the animations, but finding multiple spritesheets of a similar art style that contained that many directional possibilities was more challenging. In order to animate the sprite, the method of generating sprites needed to be modified. First, a Player Sprite class was developed to handle the sprite information such as animations, player states (for example a collision state to terminate animations when colliding with an object) and bounding boxes. Next, a Game Object class was developed. The primary function of this class was to handle animation data from the sprite animation Property List (.plist) file. There were several Property List files used in the game. One Property List file was generated when creating the overall spritesheet (see Appendix D). This list contained basic sprite data (such as size and position on the spritesheet) for each sprite used in the game. From this, separate Property List files were created to handle individual sprite animations. The Property List for the player sprite animations consisted of four items; walkanimdown, walkanimup, walkanimright and walkanimleft. Each of these items contained three pieces of data; animation frames, time delay between frames and the filename prefix. The animation frames contained three integer values (1,2,3). The filename prefix contained the name of the frame in the overall spritesheet Property List file. The Game Object class method was called from within the Player Sprite class. This loaded the player sprite Property List file and loaded the specified animations by combining the filename prefix and animation frame value (walkanimdown1, walkanimdown2, walkanimdown3 etc). A CCAnimation [40] was then returned 31

32 containing the combined sprite data and delay time between frames. For example the sprite animation was called by setting the player sprite state to walking left when the D-Pad was being directed to the left Stages 10-11: Spawning the Minotaur and Level 1 Spawning the first NPC (the Minotaur) in the game was a very similar process to that of spawning the player sprite. The Game Object class was used, however a separate Enemy Sprite class was created to handle the specific needs of the NPC. The main difference between the Player Sprite and Enemy Sprite class was that there was no need to check for D-Pad inputs to determine which direction to animate movement of the NPC sprite. At this point, the NPC sprite was only generated at its spawn point as allocated on the tiled map and was given a bounding box for collision detection with the player sprite. The NPC movement was handled in the following stage when navigating the generated path from the A* path finding algorithm. The bounding box for the Minotaur was set so that when it intersected with the player sprite bounding box, it would cause the game to load the Game Over screen. As the following stage in development was to implement the path finding algorithm, it was important at this point to have designed the first level of the game (the first maze). This was very important to implement, as it would have been more difficult to test whether the algorithm was functioning properly in a simpler map. The level was designed in Tiled Map Editor as described in Section All of the levels designed and used in the game can be found in Appendix C Stages 12-13: Gameplay Mechanic: Implementing A* Path Finding Algorithm Implementing an effective and efficient A* path finding algorithm was an integral part of the project and as such it was important to fully understand the methodology behind it. Lots of research was undertaken prior to the implementation stage in order to understand the underlying concepts of the algorithm (as discussed in Section 1.3). 32

33 The algorithm was implemented within the level code. It was developed as a BOOL method. The method would return NO if a path could not be generated or YES if a path was generated. It took four integer inputs; the starting x and y coordinates of the path (the Minotaur s tile position) and the ending x and y coordinates of the path (the player sprite tile position). The first action within the method was a short if statement to check whether the start and end coordinate inputs were the same. If they were, the method should return a NO value, as there would be no need to generate the path as the destination had already been reached. Otherwise, the method would continue. Two NSMutableArrays [41] were created for the Open List and Closed List. Three PathNode objects were then created to store the node data (x and y coordinates, cost, and parent node). One PathNode object for the starting node was created using the starting coordinates, a cost of zero and parent node equaling nil. This was added to the Open List. The two other PathNode objects created were set as nil and were called currentnode and anode. Then, a while loop was created to continue looping while the Open List count was not equal to zero. Following this there was a check to determine whether the currentnode x and y coordinates were the same as the ending x and y coordinates of the path. If this returned a True value, it meant that the path had been determined. A while loop was used to cycle through the parent nodes. The parent node coordinates were added to an array that could then be accessed to move the Minotaur sprite. If the check returned false, it meant that the path had not yet been fully generated (if at all). The four surrounding tiles of the currentnode were checked for their position and cost. The node with the lowest cost was added to the Closed List. This node then became the parent node and the process was repeated until the full path was generated. The cost of the node was calculated by using the following equation: Node Cost = (currentx endx)+(currenty endy) 33

34 The diagram in Figure 3.1 shows a high level view of the logic flow of the path finding algorithm. Figure 3.1 A* path finding algorithm logic flow The path finding method was called every three seconds to update the path between the Minotaur and the player as the player would have likely changed position on the map. The Minotaur was then animated and moved along the generated path using CCActions [34]. The only issue with using the A* method was that the map size had to be restricted to a maximum of 60x60 tiles. Any map larger this size resulted in reduced performance. This was because the A* path finding method was very resource-heavy. In 34

35 a larger map, there were more nodes that needed to be checked when generating the path. As such this resulted in sudden frame-rate drops when generating the path, which was an issue when the path was being generated every three seconds Stages 14-16: Menus, Universal Device Scaling and Game Center Integration At this stage, the core mechanics of the game had been established and implemented. It was therefore important to begin to make the application more presentable in preparation for the App Store submission. The first task in order to do this was to implement a system of menus to allow the user to easily navigate the application. The menu flow was carefully considered in the design phase of the project (see Figure 2.6 or Appendix E). This was very useful when implementing the menu interactions and connections. The menus were implemented as separate CCScenes [42]. This allowed them to be ordered in a scene stack that could be pushed or popped depending on the user input received. The menus components were designed using Gimp [43] (GNU Image Manipulation Program). These components were put together using multiple CCSprites [44] to contain each individual component. This allowed them to be positioned and scaled with ease. The only menu screen that was significantly different to implement was the Level Select screen. This was implemented using a CCScrollLayer [45]. This allowed multiple screens to be created within the same scene. This provided a scrolling menu for choosing different levels (one level per screen). This also provided a readily scalable and expandable menu screen for adding additional levels as they were developed. 35

36 Figure 3.2 Scrolling across the Level Select screen Saving the player s score for each level was the next feature to be implemented. This was done using NSUserDefaults [46]. NSUserDefaults is the method of saving application data to the system memory. When the Level Select screen was launched, any previous scores saved to the NSUserDefaults were called. If no scores were present, a slot in memory was initialized so that scores could be saved to in the future. Once the user reached the Level Complete screen after a certain level, the time taken was converted into a score integer (1, 2 or 3) to represent stars. The conversion depended on what level had been completed (earlier levels were designed so that it was easier to achieve a score of 3). If the score was higher than the one previously saved to the NSUserDefaults, then the score was overwritten. The high score was then represented on the Level Select screen as stars. It was at this point that it was important to consider universal scaling to enable the application to run properly on various types of ios devices (primarily the ipad and iphone). Up until this stage, the menus and HUD elements had been positioned and scaled to fit the ipad screen size. In order to add iphone scaling to the project, a simple device check was needed. A simple if statement was added to the component loading 36

37 section of the code within each menu screen and the HUD. This statement checked if the device was an ipad. If true, the positioning and scaling already set would be loaded. If false, scaling and positioning for the iphone screen size would be loaded. The main challenge in this was scaling the menu elements to an appropriate, easily readable size for the iphone screen without it becoming cluttered. It was then time to investigate the process of implementing Game Center features to the application. There was a large quantity of pre-canned code provided by Apple in order to enable the features, however it was still important to understand how it functioned in order to implement it effectively. The majority of code provided was for logging in and registering with Game Center to access user accounts and personal details. The first task was to implement achievements into the game. Achievements are common features in most modern games and act as a reward for completing certain tasks within a game [47]. Firstly, the achievements had to be registered in itunes Connect [48], the Apple developer portal. Each achievement required an Achievement ID, Reference Name, Point Value, Title, Description and Icon. Once registered, the achievements needed to be defined within the application so that Game Center could call the specific achievements when needed. The next task was to enable the capability to reward the achievements. When the specific criteria to unlock the achievement had been completed (for example finishing a level), a rewardachievement method was called. This method first checked whether Game Center was enabled and logged in. If not, the achievement would not be rewarded. If the user was logged in to Game Center and the achievement had not already been unlocked, the achievement was rewarded and saved to the specific user s ID. Implementing leaderboards was a similar process. Leaderboards allow users to compare their game scores against their friends and other users worldwide. In the case of The Minotaur s Lair, the scores that would be compared were level completion times (in seconds). As with achievements, the leaderboards needed to be defined in itunes Connect. The same criteria (such as Leaderboard ID) were required to register the leaderboards. 37

38 The process for registering a time on the leaderboard was slightly different to that of rewarding achievements. The leaderboard time was registered upon completion of a level. As with achievements, it was necessary to check whether the user was connected to Game Center. If connected, the time taken to complete the level was converted into seconds and stored as an integer. This integer was submitted to the Game Center and registered on the Leaderboard. Figure 3.3 shows the achievements being displayed to the user from within the application. Further screenshots showing Game Center features can be seen in Appendix G. Figure 3.3 Achievements displayed within the application Stages 16-17: Expanding the game: Tilt Controls and Additional Levels As specified in the requirements, it was necessary to provide an optional tilt control method for player sprite movement. The accelerometer was scheduled the same way as 38

39 the update method for collision detection (updating every 1/60 th of a second). The accelerometer then detected changes in direction of the device. The player sprite would then be animated depending on the direction the device was tilted. The option to choose between the D-Pad and Tilt controls was provided on the Main Menu screen of the game. In addition to adding the additional control feature, a further four levels were developed. These were designed and implemented in the same way as the first level had been developed using Tiled Map Editor. These were implemented as separate classes in order to be able to add elements of variation to each individual level Stages 19-20: Guard Sprites and Patrolling the Labyrinth Each of the new levels developed in the previous stage contained spawn points for not only the player and Minotaur, but also Guard sprites. There were also patrol points marked in the map files for each Guard sprite. The Guard sprites were spawned in the same way as the Minotaur. Upon loading one of these levels, paths were generated for each Guard sprite using their spawn point and their patrol point and utilising the path finding method. The Guards then moved up and down these patrol paths using an infinitely repeatable CCAction. The Guard sprite bounding boxes were set to return the player sprite to the player spawn point if they were to intersect with each other Stage 21: Adding Variation At this point the game was near completion. There were only two main features to implement in order to polish the game. The first of these was to add a dynamic element into the game to add variation and longevity. It was decided to modify the fourth and fifth levels of the game. 39

40 In the fourth level, each NPC (including the Minotaur) was given three possible spawn points and related patrol points. These spawn points were selected for each NPC sprite at random upon loading the level. The map was also designed with four exits. It was then modified so that only one of these exits would be the real exit to the level. As with the spawn points, the exit was determined upon loading the level. four. The calculation below shows the total number of possible permutations of level 3 4 (spawn points) * 4 (possible exits) =324 possible permutations A similar approach was taken to level five. The same number of spawn points were allocated to each NPC sprite. However, instead of using four potential exits, three slightly different level designs were used (see Appendix C). The level design used was determined upon loading the level. five. The calculation below shows the total number of possible permutations of level 3 4 (spawn points) * 3 (possible levels) =243 possible permutations Whilst Level 5 had fewer possible permutations, the labyrinth designs were more complicated with only one or two possible routes to escape. The final addition to the level selection was a simple Random Level select screen. This was positioned as the first screen that would appear on the Level Select screen. When used, this feature randomly selected any of the five levels for the user to play Stage 22: Music and Sound Effects Music and sound effects are defining factors in any video game. A game can be perfect in terms of gameplay and visual presentation, but a poor soundtrack can often distance the 40

41 user from the game. As such, it was important to find music and sound effects fitting to the game style. The sounds were taken from various online sources (referenced in the Audio Manager code, see Appendix O). All of the sounds used in the game were license free and so could be used when put on the App Store. The sounds were preloaded into memory upon launching the application, allowing them to be called quickly and seamlessly when needed using the Cocos2D sound engine Stage 23: Testing, Bug Fixing and Polishing The project was developed with an agile approach [49][50] and therefore testing and bug fixing was an ongoing process throughout development of the game. Further details on the testing taken place throughout the course of the project are discussed in Section 6 of the report. In order to polish the game further, a lighting effect was added to the ipad version. The lighting effect implemented created a circle of light around the player sprite, restricting the view of the entire screen. This added an element of difficulty and intrigue to the ipad version, as it reduced the field of view. This also kept the gameplay experience similar to the iphone version of the game, where the view is naturally restricted due to screen size. The lighting was implemented by adding a black render layer between the gameplay and HUD layers. A light was then shone through the layer centered on the player position. This was implemented using an open source plugin to generate the render layer. The plugin used was CCSpotLight [51]. The light position followed the player around the map in the same way as the camera. 41

42 Stages 24-25: App Store Submission and Feedback The game was submitted to the App Store on the 27 th of February 2012 and was released on the Store on the 3 rd of March The game received over one thousand downloads in the first week of release. The game was released without levels four and five, as they were still being tested and bug fixed. An update was submitted and released the following week containing the finished version of the game. 42

43 4. Results As Section 3 of the report has shown, all of the requirements that were set were fulfilled and implemented to the specified standard and quality. The following sections will show the results produced from the development of the game. 4.1 A* Path Finding Figure 4.1 shows the path generated between two sprites using the A* path finding algorithm implemented in the project. Each blue dot represents a node or tile on the map. Figure 4.1 Path generated between Minotaur and Player sprites (ipad) The table in Appendix H shows an example set of coordinates forming a path generated from the A* method. The coordinates were taken from Level 1 of the game between the Minotaur and player sprites spawn points. 43

44 4.2 Overall Game The figures below contain screenshots of the overall finished game. Additional screenshots can be found in Appendix G. Figure 4.2 Main Menu screen (ipad) Figure 4.3 Level 2 (ipad) 44

45 4.3 App Store As mentioned previously, the game was released on the Store on the 3 rd of March The game received over one thousand downloads in the first week of release. Figure 4.4 shows the game available for download on the App Store. Figure 4.4 Game available for download on the Apple App Store See Appendix I for screenshots of App Store reviews and download data. The game also received coverage from a popular downloadable gaming site named Hookshot Inc [52]. The article was written by Christian Donlan, a Games Media Award (GMA) winning journalist. The article published can be found in Appendix J. 45

46 6. Testing and Quality 6.1 Testing Testing was an ongoing process throughout the development of the project. The primary form of testing that took place was dynamic testing [53] (testing through code execution). Testing for each feature took place while they were being developed. The testing took place on an ipad 2 device, iphone 4 device, ipad simulator and iphone simulator. The devices and simulator were all running ios version 5.0. Whilst testing functionality was the primary exercise, it was also important to test for memory leaks. This was done using the Instruments tool [54] provided with Xcode. This allowed for performance testing of the application on both the simulator and device. It also helped to determine where specific problems or errors were occurring within the code. Acceptance testing also took place by providing peers at the university a beta version of the game to test. This is discussed further in Section 6.3. Once all of the features of the project had been implemented, full system tests took place whereby the game was tested repeatedly to detect any failures or errors that may have occurred. The errors detected at this point were minor and were fixed with relative ease as each individual feature had been thoroughly tested throughout development. Various methods of static testing [55] also took place throughout the course of the project. The requirements and specifications documents were revisited on a regular bases to ensure the project was heading in the desired direction. The source code was also examined often to ensure the code that was being produced was up to a high standard. 46

47 6.2 Problems Encountered During Testing The main problem encountered throughout the testing process was testing on the simulator. Most of the time, the simulator provided an accurate representation of what would occur when using the device. However on some occasions (in particular when testing the collision detection mechanism), the device provided a different output or reaction to a particular component. It therefore became a priority to test on the device rather than the simulator as much as possible when implementing large features, as that was found to be the closest to the actual end user experience. 6.3 Quality Assurance A questionnaire was produced during the latter phases of development in order to receive some constructive feedback from peers at the university. The game was provisioned onto an ipad 2 and iphone 4 for the sample group to test on. The game was also provisioned to various other devices (for example the first generation ipad, iphone 3GS and iphone 4S) that were owned by the testers. This was a very useful exercise to undertake. The main benefit of this process was that it helped to detect bugs and errors when running on the previously untested devices. It also allowed some feedback and suggestions to improve the game. The questionnaire was taken halfway through the project lifecycle in order to potentially allow time to add any additional functionality or modifications that were suggested. The questionnaire and results can be found in Appendix K. 47

48 7. Summary, Conclusions and Critique 7.1 Completion Assessment There were a large number of requirements that needed to be fulfilled throughout the course of the project. Table 7.1 shows the requirements set out in the planning and design phase of the project and their status at the completion of the project. Requirement(s) Status The game should be developed as a universal application. Fulfilled A Main Menu should appear when launching the game. Fulfilled There should be a Credits and Guide screen, accessible from the Main Menu. There should be a Credits and Guide screen, accessible from the Main Menu. Fulfilled The Level Select screen should allow the user to select a level to play, Fulfilled accessible from the Main Menu. There should be a Pause Menu located in the game and on the Main Menu and Fulfilled Level Select screens. It should be easy for the user to navigate through the application. Fulfilled There should be sound effects and music in the game. Fulfilled There should be an option for the user to select a preferred game control Fulfilled method. The game itself should be 2D with an orthogonal point of view of the game Fulfilled world. There should be collision detection so that the player cannot walk through Fulfilled obstacles or objects on the game map. Once in a level, there should be a Heads-Up-Display (HUD) to enable user Fulfilled inputs. Two types of Non-Player Characters (NPCs) should be generated. Fulfilled One NPC sprite should chase the player around the labyrinth. Fulfilled Other sprites should patrol around parts of the map. Fulfilled The game should be integrated with Apple s Game Center API. Fulfilled Table 7.1 Project requirements completion status 48

49 As table 7.1 has shown, all of the goals that were set out at the beginning of the project were achieved. 7.2 Time Cost Analysis Time costs were estimated and predicted in the Project Initiation Document (PID). The Gantt chart created during this analysis is provided in Appendix A. In order to compare and analyse this against the actual time taken throughout the project, another Gantt chart was produced throughout the development of the project. This chart reflected the actual time taken to develop the project. This can be found in Appendix L. As the charts show, the actual time taken was very close to the estimated time. The only major difference was in the Completing the System phase of development. This took longer than anticipated as implementing the A* algorithm effectively and efficiently was more challenging than initially perceived. This was not a problem, however, as contingency time had been accounted for when planning the development of the system. 7.3 Potential Improvements to Project Approach If the project was to be repeated, there are several ways that the development process would be adjusted. As mentioned in Section 7.2, the implementation of the A* algorithm took longer than initially anticipated. Therefore, it would become a priority to begin this aspect of development at an earlier stage of the project. Other features of the project would be given a lower priority (such as the implementation of menus and sound effects). Implementing dynamic elements to the levels at an earlier stage would also be considered, as this would have helped to sculpt the overall structure of the game at an earlier stage of development. 49

50 7.4 Potential Future Development There were several areas of development that could be considered given more time to work on the project. The primary area of research would be in Procedural Map Generation [56]. Procedural map generation is the method of generating content algorithmically rather than manually. This would be a clever way to generate new levels for the game. Many dungeon-style games (such as the popular series Diablo [57]) have used this method of level generation. Procedural generation has many benefits. The main, long-term benefit is that it would save time, as the levels would not need to be created manually. It would also keep the game feeling fresh and new to the user, as it would always generate a different level layout to play through each time. Procedural generation would also provide the benefit of reducing the amount of storage space needed for the game to be installed, as there is no need to store data for pre-made levels. A further area of development would be in creating a multiplayer experience for the game. The Game Center API offers the potential to create a connection between ios users. This would allow for multiplayer modes to be implemented with relative ease. A possible multiplayer mode in the game could be implemented as follows. Two or more players would be spawned in a level. Once the game began, the timer would start and the first player to escape the labyrinth would be the winner. This could be further experimented with and built upon to create an exciting multiplayer experience. The final area of future development would be porting the application to the Mac and Android devices. Porting to the Mac would be relatively straightforward. This would involve removing all of the touch-input based controls and replacing them with keyboard and mouse inputs (for example the directional arrows to control player sprite movement). 50

51 7.5 Conclusion The development of the project was a challenging yet rewarding process. The learning curve of the project was consistently steep but this has resulted in a great deal of learning and self-improvement. The project provided invaluable experience in developing a large project over many months. Efficient project and time management were crucial factors in ensuring the full completion of the game. There were three main challenges in the project; learning how to develop for the ios platform using the Objective-C programming language, utilising Cocos2D effectively, and implementing an A* path finding algorithm efficiently. All of these challenges were overcome to create the full game The Minotaur s Lair. Releasing the game on the App Store was a significant milestone in marking the completion of the project. The game received over 1,000 downloads in its first week on sale and it was extremely rewarding knowing that ios gamers around the world could play and appreciate the game. The project was an educational and academic approach to game development. A great deal of information and knowledge has been learnt which will come in very useful when developing any future games or projects. 51

52 References [1] Apple UK. (Apr 2012). ios 5. [Online]. Available: [2] Apple UK. (Apr 2012). iphone 4S. [Online]. Available: [3] Apple UK. (Apr 2012). ipad. [Online]. Available: [4] VGChartz. (Jan 2011). Top Selling Games of [Online]. Available: [5] Business Insider. (Nov 2011). Angry Birds Just Hit 500 Million Game Downloads Worldwide. [Online]. Available: 02/tech/ _1_rovio-angry-birds-black-ops [6] Pac-Man. (2011). The Official Pac-Man Destination. [Online]. Available: [7] Apple UK. (Apr 2012). The App Store. [Online]. Available: [8] NinjaBee. (Jun 2009). Indie Game Developer: The Definition. [Online]. Available: [9] Apple UK. (Apr 2012). Apple Developer Portal. [Online]. Available: [10] Game Politics. (Jan 2011). Video Game Sales Down in [Online]. Available: [11] LA Times. (Feb 2011). International Box-Office Revenue Soars in [Online]. Available: [12] Apple Insider. (Jan 2011). Apple sells 160 millionth ios device. [Online]. Available: ge_iphone_price_grows_to_625.html 52

53 [13] Newzoo. (May 2011). Over 5 Million ios Games Downloaded per Day by 63 Million ios Gamers in US and EU. [Online]. Available: [14] Industry Gamers. (Mar 2011). Angry Birds One of the Most Profitable Games in History. [Online]. Available: [15] Khammapun Khantanapoka, Krisana Chinnasarn, Pathfinding of 2D & 3D Game Real-Time Strategy with Depth Direction A* Algorithm for Multi-Layer, Eighth International Symposium on Natural Language Processing, [Online]. Available: Conference+Publications&queryText%3DA+pathfinding [16] Policy Almanac, Patrick Lester. (Jul 2005). A* Pathfinding for Beginners. [Online]. Available: [17] Data Structures and Algorithms, University of Auckland. (1998). Dijkstra s Algorithm. [Online]. Available: [18] Algorithms and Data Structures. (Apr 2009). Depth-first search (DFS) for undirected graphs. [Online]. Available: [19] CS Students, Stanford University. (Nov 2010). Short Description of A*. [Online]. Available: [20] About.com, Internet Games. (Apr 2012). RTS Real-Time Strategy. [Online]. Available: [21] Stack Exchange, Game Development. (Jan 2012). Difference between orthogonal map and isometric map. [Online]. Available: [22] Game/AI, Paul Tozour. (Jul 2008). Fixing Pathfinding Once and For All. [Online]. Available: 53

54 [23] Apple Inc. (2010). Introducing Universal Applications for iphone OS. [Online]. Available: [24] Apple Developer. (Apr 2012). Game Center for Developers. [Online]. Available: [25] QcMat. (Jul 2010). SneakyInput Joystick, dpad and buttons for Cocos2D. [Online]. Available: [26] Tiled Map Editor. (Feb 2012). Tiled Map Editor. [Online]. Available: [27] Dropbox. (Apr 2012). About Dropbox. [Online]. Available: [28] Apple UK. (Apr 2012). imac. [Online]. Available: [29] Apple UK. (Apr 2012). MacBook Pro. [Online]. Available: [30] Subversion. (Apr 2012). Apache Subversion. [Online]. Available: [31] Cocos2D. (Apr 2012). CCLayer Class Reference. [Online]. Available: [32] Cocos2D. (Dec 2011). Standard Touch Delegate. [Online]. Available: [33] Touch Code Magazine. (Jan 2012). CGPointMake, CGSizeMake, etc. shortcuts. [Online]. Available: [34] Cocos2D. (Apr 2012). CCAction Class Reference. [Online]. Available: [35] Cocos2D. (Mar 2011). Cocos2D Best Practices Timers. [Online]. Available: 54

55 [36] Cocos2D. (Apr 2012). CCMenuItem Class Reference. [Online]. Available: [37] Cocos2D. (Apr 2012). CCDirector Class Reference. [Online]. Available: [38] C Programming. (Nov 2011). The Stack Data Structure in C and C++. [Online]. Available: [39] Cocos2D. (Feb 2012). Cocos2D Basic Concepts. [Online]. Available: [40] Cocos2D. (Apr 2012). CCAnimation Class Reference. [Online]. Reference: [41] Mac OS X Developer Library. (Aug 2010). NSMutableArray Class Reference. [Online]. Available: asses/nsmutablearray_class/reference/reference.html [42] Cocos2D. (Apr 2012). CCScene Class Reference. [Online]. Available: [43] Gimp. (Apr 2012). Gimp 2.6 The GNU Image Manipulation Program. [Online]. Available: [44] Cocos2D. (Apr 2012). CCSprite Class Reference. [Online]. Available: [45] Giv Parvaneh. (Dec 2010). Scrolling Menus in Cocos2D. [Online]. Available: [46] Mac OS X Developer Library. (Jan 2012). NSUserDefaults Class Reference. [Online]. Available: asses/nsuserdefaults_class/reference/reference.html [47] 1 Up. (Jul 2010). The Necessity Of Achievements In Video Games. [Online]. Available: 55

56 [48] itunes Connect. (Apr 2012). itunes Connect Login. [Online]. Available: [49] Version One. (Apr 2012). Agile Development 101. [Online]. Available: [50] Patrick Stacey, Joe Nandhakumar, Opening Up to Agile Games Development, Communications of the ACM, Dec [Online]. Available: h&an= [51] Super Su Raccoon s World. (Sept 2011). Spot Light Demo. [Online]. Available: [52] Hookshot Inc. (Mar 2012). Hot Shot: The Minotaur s Lair. [Online]. Available: [53] One Stop Testing. (Apr 2012). Dynamic Testing. [Online]. Available: [54] Apple Developer. (Apr 2012). Developer Tools. [Online]. Available: [55] One Stop Testing. (Apr 2012). Static Testing. [Online]. Available: [56] Daniel Ashlock, Colin Lee, Cameron McGuiness, Search-Based Procedural Generation of Maze-Like Levels, IEEE Transactions on Computational Intelligence and AI in Games, Vol 3, No 3, Sept [Online]. Available: ournals+%26+magazines&querytext%3dprocedural+generation [57] Blizzard Entertainment Europe. (Apr 2012). Diablo 3 Conquer and Infinite Battlefield. [Online]. Available: 56

57 Appendices Appendix A Risk and Time Analysis Risk Register Risk Classification: Impact High A B C Medium B C D Low C D E High Medium Low Likelihood 57

58 58

59 Appendix B Screen Designs Main Menu Screen: Achievements button The Minotaur s Lair Pause Menu button Background Image Level Select Guide D- Pad/Tilt Credits Credits Screen: Return to Menu button Credits Audio - References Art - References Developed by Blair Trusler 59

60 Guide Screen: Return to Menu button Guide Objective Reach the end of the labyrinth without being caught by the Minotaur. Avoid Guards as they will send you back to your cell. Characters [Sprite Image] Theseus (You) [Sprite Image] Minotaur [Sprite Image] Guard HUD Layer: Level Number Timer: 0:00 Pause Menu button Game World D- Pad Speed Boost button 60

61 Level Select Screen: Return to Main Menu button Level X High Score (eg ***) Pause Menu button Scroll View Map Overview Scroll View D- Pad Play Leaderboard Speed Boost button 61

62 Appendix C Level Design Tileset reference: Level 1 Tiled Map Editor Level 1 Complete (Objects and Foreground Hidden) 62

63 Level 2 Tiled Map Editor Level 2 Complete (Objects and Foreground Hidden) 63

64 Level 3 Tiled Map Editor Level 3 Complete (Objects and Foreground Hidden) 64

65 Level 4 Tiled Map Editor 3 possible spawn points/patrol points per sprite Level 4 Complete (Objects and Foreground Hidden) 65

66 Level 5 Tiled Map Editor 3 possible spawn points/patrol points per sprite Level 5 Complete (Objects and Foreground Hidden) 3 Variations 66

67 Appendix D Spritesheets Player Sprite Reference: ?q=gallery%3Amez1009%2F &qo=32 Minotaur Sprite Reference: Guard Sprite Reference: px 67

68 Combined Overall Spritesheet 68

69 Appendix E Menu/Level Flow Diagrams Menu Flow 69

70 Game Flow 70

71 Path Finding Logic Flow 71

72 Appendix F Class Diagrams Levels Level_N CCTMXTiledMap *_tilemap; CCTMXLayer *_background; CCTMXLayer *_foreground; CCTMXLayer *_meta; CCSprite *_player; CCSpriteBatchNode *_playersprite; HUD *_hud; CGPoint enemyspawnpos1; PlayerSprite *playerone; EnemySprite *enemyone; unsigned char tilearray[tile_cols]; NSMutableArray *pointertoopenlist; int startx, starty, endx, endy; NSMutableArray *movementpathx, *movementpathy; BOOL allowdiags; - (PathNode *)lowestcostnodeinarray:(nsmutablearray *) openlist1; - (void)createpath:(cctime)dt; - (void)clear:sender; - (BOOL)isWall:(CGPoint)position; - (BOOL)findPath:(int)sx :(int)sy :(int)ex :(int)ey; - (void)fliptilearray; - (CGPoint)tilePositionForCoord:(CGPoint)coord; - (void)moveonpath; + scene; + (NSString *)getdefaultlevel; - (void)loadmap; - (void)setviewpointcenter:(cgpoint)position; - (CGPoint)tileCoordForPosition:(CGPoint)position; - (CGPoint)positionForTileCoord:(CGPoint)tileCoord; 72

73 Menus StatMenuScene + scene; - (void)loadscreencontents; - (void)muteaction:sender; - (void)retrylevel:sender; - (void)returnmenu:sender; - (void)mute:sender; - (void)unmute:sender; Credits - (void)loadscreencontents; - (void)returntotitlescreen:sender; - (void)rewardachievements; LevelCompleteLayer int score; - (void)returnmenu:sender; - (void)retrylevel:sender; - (void)returnscore; - (void)rewardachievements; LevelSelect CCLayer *page0; CCLayer *page1; CCLayer *page2; CCLayer *page3; CCLayer *page4; CCLayer *page5; GKLeaderboardViewController *tempvc; + scene; - (void)loadscreencontents; - (void)returntotitlescreen:sender; - (void)setupsaves; - (void)playlevel1:sender; - (void)playlevel2:sender; - (void)playlevel3:sender; - (void)playlevel4:sender; - (void)playlevel5:sender; - (void)playrandomlevel:sender; - (void)showleaderboards:sender; - (void)showleaderboards2:sender; - (void)showleaderboards3:sender; - (void)showleaderboards4:sender; - (void)showleaderboards5:sender; - (void)leaderboardviewcontrollerdidfinish: (GKLeaderboardViewController *)viewcontroller; GameOverLayer - (void)returnmenu:sender; - (void)retrylevel:sender; - (void)rewardachievements; MainMenuScene UIViewController *tempvc; + scene; - (void)setupmenu; - (void)muteaction:sender; - (void)showachievements:sender; - (void)showleaderboards:sender; - (void)levelselect:sender; - (void)achievementviewcontrollerdidfinish: (GKAchievementViewController *)viewcontroller; - (void)leaderboardsviewcontrollerdidfinish: (GKLeaderboardViewController *)viewcontroller; - (void)smokeeffecttimer:(cctimer *)dt; - (void)loadcreditsscene:sender; - (void)loadguidescene:sender; - (NSString *)platform; - (NSString *)platformstring; - (void)rewardachievements; Managers SceneManager SceneTypes currentscene; + (SceneManager *) sharedscenemanager; - (void)runscenewithid:(scenetypes) sceneid; AudioManager + (void)preloadaudio; + (void)playlevel1music; + (void)playlevel2music; + (void)playlevel3music; + (void)playlevel4music; + (void)playlevel5music; + (void)levelcompletemusic; + (void)gameovermusic; + (void)playmainmenumusic; + (void)playmenubuttonclick; + (void)gameoversound; + (void)levelcomplete; + (void)powerup; + (void)powerupover; + (void)collisionsound; + (void)doorlocksound; GuideScene - (void)returntotitlescreen:sender; - (void)loadscreencontents; 73

74 Game Objects Sprites GameObject BOOL isactive; BOOL reactstoscreenboundaries; GameObjectType gameobjecttype; - (void)changestate:(characterstates) newstate; - (void)updatestatewithdeltatime: (cctime)deltatime andlistofgameobjects:(ccarray *) listofgameobjects; - (CGRect)adjustedBoundingBox; - (CCAnimation *) loadplistforanimationwithname: (NSString *)animationname andclassname:(nsstring *) classname; GameCharacter CharacterStates characterstate; EnemySprite2 CCAnimation *walkdownanim; CCAnimation *walkupanim; CCAnimation *walkleftanim; CCAnimation *walkrightanim; GameCharacter *enemycharacter; int originalpositionx; int originalpositiony; CGPoint originalpos; - (void)changestate:(characterstates) newstate; EnemySprite CCAnimation *walkdownanim; CCAnimation *walkupanim; CCAnimation *walkleftanim; CCAnimation *walkrightanim; GameCharacter *enemycharacter; int originalpositionx; int originalpositiony; CGPoint originalpos; - (void)changestate:(characterstates) newstate; PlayerSprite CCAnimation *walkdownanim; CCAnimation *walkupanim; CCAnimation *walkleftanim; CCAnimation *walkrightanim; SneakyJoystick *joystick; BOOL left, right, up, down; + node; PathNode int nodex, nodey; int cost; PathNode *parentnode; 74

75 Appendix G Final Game Results Main Menu Screen ipad: Achievements Button Pause Menu Button Guide Screen Button Credits Screen Button Control Toggle iphone: 75

76 Guide Screen ipad: iphone: 76

77 Credits Screen ipad: iphone: 77

78 Game Center Achievements ipad: iphone: 78

79 Level Select Screen ipad: Return to Main Menu Button Play Level Button Leaderboard Button Scrolling Menu iphone: 79

80 Game Center Leaderboards ipad: iphone: 80

81 Gameplay ipad: D- Pad Speed Boost Button iphone: 81

82 Game Over Screen ipad: iphone: 82

83 Level Complete Screen ipad: iphone: 83

84 Game Center Application ipad: iphone: 84

85 Appendix H Generated Coordinates between Minotaur and Player spawns (Level 1) Generated Coordinate (X-axis) Generated Coordinate (Y-axis) 85

86 Coordinates generated between Enemy Spawn (18,13) and Player Spawn (7,32): Origin (0,0) Enemy Spawn Player Spawn 86

87 Appendix I App Store Data and Reviews The Minotaur s Lair in the App Store. Download data for the first few weeks of release from itunes Connect. 87

88 App Icons Standard Icon (iphone 3GS) Standard Icon (ipad 1/2) Retina Icon (iphone 4/4S and ipad 3) App Store Icon (itunes) 88

89 App Store Reviews 89

90 Appendix J Coverage on Hookshot Inc Source: 90

91 Appendix K Questionnaire Results 91

92 92

93 93

94 Appendix L Actual Development Time Gantt Chart 94

95 Appendix M Game User Guide 1. Download The Minotaur s Lair from the App Store onto your device or to itunes 1.a. If downloaded on itunes, sync application to device. 2. Once downloaded onto the device, tap the game icon to launch the game. 95

96 3. The Main Menu screen will appear. 3.a. A level can be chosen to play by tapping the Level Select button in the centre of the screen. 3.b. The D-Pad or Tilt game controls can be toggled by tapping the displayed control method at the bottom-centre of the screen. 3.c. If you have a Game Center account, you will automatically be logged in once the menu has loaded. If not, you will be asked to create an account in order to make use of the achievement and leaderboard features. 3.d. The sound volume can be adjusted using the toggle mute switch on the device and volume controls. The sound can also be muted from the Pause Menu, located at the top-right hand side of the screen. 3.e. The Game Center achievements can be accessed by tapping the Game Center icon at the top-left hand side of the screen. 3.f The Guide and Credits screens can be accessed from the main menu by tapping the buttons at the bottom-left and right hand sides of the screen. Achievements Button Pause Menu Button Guide Screen Button Credits Screen Button Control Toggle Level Select Button 96

97 4. Tap Level Select to choose a level to play. 5. Use the horizontal scroll menu to choose one of five levels to play from. If you cannot decide on a level to play, select the random level play button. 5.a. High scores will be displayed underneath the level name in stars if you have earned them. 5.b. The leaderboard data for each level can be accessed by tapping the Leaderboard button at the bottom of each level selection screen. 5.c. You can return to the Main Menu by tapping the return button at the top-left hand side of the screen. Return to Main Menu Button Play Level Button Leaderboard Button Scrolling Menu 97