Mawi: A 2D side-scrolling platform game Third Year Project (COMP30040)

Student: Mal Berbatovci Degree Programme: MEng (Hons) Computer Science

Supervisor: Sean Bechhofer

The University of Manchester The School of Computer Science

April 2016

Page � of �2 47

Mawi: A 2D side-scrolling platform game Third Year Project (COMP30040)

Student: Mal Berbatovci Supervisor: Sean Bechhofer

April 2016

I. ABSTRACT

This report outlines the process that was taken to develop a 2D side-scrolling platform game for Android devices. Instead of using an existing game engine, the decision was made to develop my own. This meant that as a natural consequence of the development effort, an advanced understanding of the logistics required in game development was achieved. By utilising a number of different agile practices, and carefully considering the design of the software, the development was approached in a methodological manner which allowed extensible software to be created. The submitted product implemented all the functional and non-functional requirements which were specified in the planning phase, and also reached the outlined project goals. This was quantified using a range of evaluation methods, and lends support to the success of the project.

Page � of �3 47

II. ACKNOWLEDGEMENTS

I would like to firstly thank Mr. Sean Bechhofer, who has helped me flourish into the computer scientist I am today with his continued support and guidance. I would also like to thank my boyfriend Sam, who throughout my degree has acted as my Northern Star - without whom I would be lost. And finally, I would like to thank my parents; as without them none of this would have been possible.

Page � of �4 47

Table Of Contents

I. Abstract ........................................................................................................................... II. Acknowledgements ......................................................................................................... III. Introduction ..................................................................................................................... A. Project Description ....................................................................................................... B. Project Goals ................................................................................................................ IV. Context ............................................................................................................................ A. Alternate Game Ideas .................................................................................................. 1) 3D Graphics ............................................................................................................ 2) Puzzle Games .......................................................................................................... 3) Infinite Runner Games ............................................................................................ 4) Side-scrolling Platform Games ............................................................................... B. Existing Technology..................................................................................................... 1) Existing Game Engines ........................................................................................... 2) Existing Platform Games ........................................................................................ V. Design ............................................................................................................................. A. Requirements .............................................................................................................. 1) Functional Requirements ........................................................................................ 2) Non-Functional Requirements ................................................................................ B. Game Design ............................................................................................................... 1) Game Objective ...................................................................................................... 2) Player ...................................................................................................................... 3) Enemies .................................................................................................................. 4) Health System and Collectables ............................................................................. 5) Level Representation .............................................................................................. C. Technology Used ........................................................................................................ 1) Operation System ................................................................................................... 2) Game Framework ................................................................................................... D. Planning ...................................................................................................................... 1) Agile Methodology ................................................................................................. a. Short Incremental Iterations .............................................................................. b. User Stories ....................................................................................................... c. Physical Task Board .......................................................................................... E. Softare Design ............................................................................................................. 1) General Responsibility Assignment Software Patterns............................................ a. Factory Pattern .................................................................................................. b. Indirection Pattern ............................................................................................. c. Information Hiding Pattern ............................................................................... d. Polymorphism Pattern ....................................................................................... 2) High-level Description of System Architecture ...................................................... a. Class Diagram ................................................................................................... b. Activity Diagram ............................................................................................... VI. Implementation ............................................................................................................... A. Play State .................................................................................................................... 1) Physics .................................................................................................................... a. Enemy and Collectables .................................................................................... b. Projectile ...........................................................................................................

2 3 7 7 7 9 9 9 9 9 10 10 10 11 12 12 12 13 14 14 14 15 16 17 18 18 19 19 19 20 20 20 21 21 22 22 22 22 23 23 23 26 26 26 26 27

Page � of �5 47

c. Player ................................................................................................................ 2) Collision Detection and Optimisations ................................................................... a. Player ................................................................................................................ b. Enemies and Collectables ................................................................................. c. Projectiles .......................................................................................................... 3) Health System ......................................................................................................... 4) Camera .................................................................................................................... 5) Rendering and Optimisations ................................................................................. B. Level Editor State ....................................................................................................... 1) Editing Toolkit ........................................................................................................ 2) Editing Tools and Camera ...................................................................................... 3) Level Size ............................................................................................................... 4) Saving and Using Edited Levels ............................................................................. 5) Playing Edited Levels ............................................................................................. VII. Evaluation ....................................................................................................................... A. Software Testing ......................................................................................................... 1) Manual Testing ....................................................................................................... 2) Unit Testing ............................................................................................................ 3) Performance Testing .............................................................................................. B. External Testing .......................................................................................................... VIII. Reflections and Conclusions ........................................................................................... A. Objective Reflection ................................................................................................... B. Feature Reflection ....................................................................................................... C. Lessons Learnt ............................................................................................................ D. Future Work ................................................................................................................ E. Final Summary ............................................................................................................ IX. References ....................................................................................................................... X. Glossary .......................................................................................................................... XI. Appendix ......................................................................................................................... A. Questionnaire ..............................................................................................................

28 28 29 30 30 31 32 33 33 33 34 34 35 35 36 36 36 36 37 38 40 40 40 41 42 42 43 45 46 46

Page � of �6 47

List of Figures

Figure 1 - Super Mario Bros ........................................................................................................ Figure 2 - Sonic the Hedgehog .................................................................................................... Figure 3 - Player Design .............................................................................................................. Figure 4 - Enemy Class Design ................................................................................................... Figure 5 - Mover Sprite Design ................................................................................................... Figure 6 - Collectable and Item Box Design ............................................................................... Figure 7 - Tile Design .................................................................................................................. Figure 8 - Top SmartPhone Platforms ......................................................................................... Figure 9 - Physical Task Board Mid-iteration .............................................................................. Figure 10 - Class Diagram ............................................................................................................. Figure 11 - Activity Diagram ......................................................................................................... Figure 12 - Gravity Pseudocode .................................................................................................... Figure 13 - Projectile Path ............................................................................................................. Figure 14 - Player Scan Lines for X movement ............................................................................ Figure 15 - Player Scan Lines for Y movement ............................................................................. Figure 16 - Effect of Collision with Enemies ................................................................................ Figure 17 - Camera Threshold Positions ....................................................................................... Figure 18 - Camera Pseudocode for Movement in X .................................................................... Figure 19 - Level Editor Toolkit States .......................................................................................... Figure 20 - Final Unit Test Coverage Statistics ............................................................................. Figure 21 - Statistics illustrating Responses to Questionnaire ...................................................... Figure 22 - Qualitative Questionnaire Section ...............................................................................

List of Tables

Table 1 - Functional Requirements .............................................................................................. Table 2 - Non-Functional Requirements ...................................................................................... Table 3 - Projectile Preliminary Checks ....................................................................................... Table 4 - Frame-Rate Tests .......................................................................................................... Table 5 - Glossary ........................................................................................................................ Table 6 - Likert-Scale Questions ..................................................................................................

11 11 14 15 16 17 17 18 21 24 25 27 28 29 29 31 32 32 34 37 39 46

12 13 30 38 45 46

Page � of �7 47

III. INTRODUCTION

HIS chapter will introduce the project by detailing the assignment description and goals; in turn outlining the scope. This will give a clear representation of what will constitute a successful project, and what the deliverables were. T

A. Project Description

This project entailed the development of a one player 2D side-scrolling platform game for Android devices, called ‘Mawi’. To aid the preliminary stages of development, a simple game framework provided in ‘The Beginner's Guide to Android Game Development’ [1] was used. To successfully deliver a fully-functional platform game however, the development of a game engine that advances on the features provided in the framework was necessary. This game engine needed to provide some of the core functionality seen within platform games; including rendering, physics, I/O handling and collision decision - whilst also being easily extensible.

By utilising this game engine’s functionality, Mawi was built by adding the appropriate features. These included game-world objects such as enemies, the varying logistics necessary for different game states, and the creation of game art. The end game consists of a number of levels with the ultimate objective of reaching the end of the level. To traverse through a level, the player is equipped with a move set which allows a combination of running, jumping and shooting.

B. Project Goals

Originally, I had set out four main goals that I wanted to achieve:

1. To create a memory efficient and responsive game, running at a frame-rate of at least 30PS. 2. To model the game world and all associated physics successfully. 3. To create a ‘fun’ game by developing an immersive game world with many features and game-

world objects, as well as having a suitably challenging difficulty throughout the game. 4. To develop key technical skills and knowledge regarding both software and game

development.

Throughout the development process however, I was able to gauge a better understanding of the effort required to implement features. This had a direct effect on the plausibility of the third goal. This, together with the redundancy of memory efficiency as a goal due to the memory available and the garbage collector, meant that it was necessary to revise these goals. The newly established goals were:

1. To create a responsive game which runs at a frame-rate of at least 30FPS. 2. To model the game world and all associated physics successfully. 3. To encapsulate elements of fun within the game by providing the basis needed for these game

features, which are easily extensible. 4. To develop key technical skills and knowledge regarding both software and game

development.

In order to reach these goals there were a number of concrete actions that were taken. Algorithms used regularly were optimised to reduce their complexity; in turn allowing the target frame-rate to be achieved. To model the game world successfully, robust collision detection

Page � of �8 47

algorithms were developed, and an efficient link between 2D space and the corresponding level was also established. By implementing only the basic logistics necessary for ‘fun’ features, and following software practices to allow for extensibility, I was be able to include scalable ‘fun’ features whilst having a more realistic goal to aim for. Finally, the development of key skills followed as a consequence of the development effort, and the use of the agile software methodology.

Page � of �9 47

IV. CONTEXT

HIS chapter will examine the broad context of mobile games, and establish the rationale for development decisions made throughout the project. Existing game engines and platform games are also analysed to allow for insights into the features necessary. T

A. Alternate Game Ideas

A wide range of mobile game genres exist that could have been utilised for this project. Each of these has a varying complexity and scope, and therefore choices made had to find a balance between the difficulty of the project, and the development of technical skills.

1) 3D Graphics

Although not specifically a game genre, the decision about whether to employ 3D or 2D graphics was pivotal due to its impact on the entire developmental process. The complexity difference of both approaches, and the contrast of benefits each provide further stresses this importance.

The pipeline for 3D graphics is considerably more involved than that of its 2D counterpart; extending from modelling game objects, to rendering the game scene. Given the time scale, the use of an existing engine would have been necessary to adequately perform these task and produce a significant software artefact. This would have consequently provided a substantially abstracted view of the logistics involved, which in turn would have limited my comprehension of these techniques. It was therefore decided that the game would be developed in 2D. This allowed a more advanced understanding of the concepts involved, and meant development was not restricted to the constraints of an engine.

2) Puzzle Games

The puzzle game genre refers to a selection of games which place a primary focus on conceptual and logical challenges [2]. The scope of these games vary greatly, extending from physics-based puzzle games like Angry Birds [3], to tile-matching games like Candy Crush [4]. This demonstrates a flexible scope from which the previously outlined goals could potentially be achieved. With the success of these games relying on a fundamental focus of level content [5] however, a large part of development would have been dedicated to this consideration. In turn, this lack of technical focus makes this genre less plausible in reaching the project goals. This is especially true with the development of key technical skills regarding game development - making other genres more plausible.

3) Infinite Runner Games

Examples of infinite runners include games like TempleRun [6], and this genre has proven to be continuously popular within the mobile gaming community [7]. In contrast to puzzle games, the scope of these games is far more limited due to their more simplistic nature, as primarily signified by the minimal move-set.

The implications of such a restricted scope directly limit the overall technical complexity of such a project, and would ultimately have had an adverse effect in reaching my goals. This is emphasised by the simplified logistics employed for collision detection and map representation; particularly when compared with other genres. Beyond this, the limited scope and move-set also

Page � of �10 47

places restrictions on the features and content that can be implemented within the game. For these reasons, it was decided that this genre would not be suitable for the project.

4) Side-Scrolling Platform Games

A platform game is defined by the user’s ability to control a character who is able to run and jump onto platforms depicted on the game screen [8]. The side-scrolling element defines gameplay in which the screen is observed from a single-view camera that is moved simultaneously with the player.

The scope of these games is largely flexible, and this is highlighted when the move sets and features of existing games are compared. A specific example of this can be seen when comparing the games ‘Sonic the Hedgehog’ and ‘Super Mario Bros’. Although they share common features like a health system, enemies, and the ability to run and jump; the specifics of these and how they are handled vary greatly. An ideal platform to reach my project goals is therefore provided through this adjustable scope. With the genre also not simplifying key features like collision detection and level map representation, this genre was consequently chosen for development.

B. Existing Technology

Examining existing technology was important to establish whether any such technology would be vital for development. For these considerations, a trade-off was necessary which would allow me to develop an advanced understanding of the logistics involved in game development, whilst ensuring that valuable software was delivered.

1) Existing Game Engines

To examine existing game engines, a list of features a prospective engine would have to posses to be suitable for the project was established. This list, and an explanation of the feature’s importance is outlined below:

• The engine must use a programming language I am already familiar with: Given the limited time available, having to learn another language would have a detrimental effect on what is achievable.

• The engine must have up to date documentation: This is important as it will allow me to become familiar with the API quickly, and also aid in any troubleshooting/debugging matters.

• The engine must be open-source: This will mean that I will be able to customise the engine as I see fit, and will not be restricted to the implementation of the engine.

• The engine must support the Android OS: This is the operating system my game will run on, and is therefore a key feature of a prospective engine.

• The engine must be completely free: If using an engine, I want to be able to utilise all of its features at no extra cost.

The only engine which completely fulfilled this brief was the libDGX engine [8]. Upon examination of the API that the libDGX engine offers, it was evident that the development of

Page � of �11 47

technical skills would be limited. This was because the underlying logistics of the engine’s features are highly abstracted from the calling code; ultimately restricting technical understanding. This abstraction ranged from features like map-representation right through to physics and collision detection - consequently effecting the entire development pipeline. Although the engine is open-source, and the option to further enhance and analyse the code was available, it was established that using an engine would only be suitable if the goal of the project was to develop a successful game which was feature rich.

2) Existing Platform Games

Given the success of the side-scrolling platform games Mario Super Bros [9] (figure 1) and Sonic the Hedgehog [10] (figure 2), these games were used to aid in feature selection. Common technical decisions that were made were also analysed, and assisted in defining my game’s technical design.

One of the most fundamental technical similarities between the two games was the tile-map representation of levels [11] - a technique which was therefore adopted in my game. Similarities between the physics evident in each game were also established, and mimicked within my implementation. These include the impulse jumping mechanisms which preserve the player’s previous momentum when jumping, and the implementation of aerial acceleration which allows the player to move horizontally whilst airborne.

The intrinsic role that enemies play within these games was also clearly highlighted through this analysis. This concerns not only the development of enemies, but also the creation of a combat system - features which were both implemented in the project. Beyond this, common game world objects like power-ups and coin-like collectables are also featured in both games. These play a role in extending the move-set and determining the player’s score, and were therefore given appropriate consideration during development. Whilst other features like one-way and moving platforms were both evident within the games, they were not established as high priority, and are therefore not present in the project.

FIGURE 1. Super Mario Bros. A screen capture of Super Mario Bros, released in 1985 - Image credit: GamesSaga.

FIGURE 2. Sonic the Hedgehog A screen capture of Sonic the Hedgehog, released in 1991 - Image credit: Wikipedia.

Priority Feature Description

Must The game must include a player with the abilities to run and jump, which the user can control.

This is a feature that is inherent in all platform games, and must therefore also be present within my software.

Must The game must employ a physics engine to model movement.

This is a fundamental part of modelling the game world and is therefore essential to the game.

Must The game must employ robust and validated collision detection algorithms.

This is another necessary element of being able to successfully model the game world, and is therefore an essential feature of the game.

Must The game must have a camera mechanism that allows side-scrolling.

Allowing the player to move freely around the map in the X and Y direction is necessary for a side-scrolling platform game.

Must The game must include a level editor to create and edit levels.

This will not only streamline the process of creating levels, but will allow me to explore and develop key technical skills.

Must The game must include at least one enemy.

This was previously highlighted as an important feature and will allow the development of technical skills, so is of high priority.

Must The game must include at least one collectable.

This will allow the exploration of the logistics required behind an important and common feature in platform games.

Must The game must include at least one level.

Levels are an important aspect of platform games, and therefore the game must feature at least one level, and preferably more.

Page � of �12 47

V. DESIGN

HIS chapter is concerned with outlining the various design decisions that were made regarding the software. These considerations span the entire development process, from requirement elicitation to architectural considerations. This chapter will therefore give a detailed understanding of the project’s design, as well as providing appropriate justification for these decisions.

T

A. Requirements

By using the information outlined in the previous chapter, a series of features deemed necessary for the software were highlighted. In order to prioritise these requirements, the MoSCoW prioritisation method [12] was used. This allowed appropriate focus to be placed on requirements, and ensured the delivery of valuable software at the end of the development cycle.

1) Functional Requirements

The collection of functional requirements which define the system, and their respective priorities, are outlined in table 1. This prioritisation was established using information summarised in the ‘existing technology’ chapter, together with the feature’s importance in reaching my project goals.

TABLE 1. FUNCTIONAL REQUIREMENTS

Should The game should include a level selection screen which the player can freely move about in.

A common feature in successful games is a level selection state, and this should be implemented if there is enough time.

Should The game should save the player’s level progress.

If more than one level is developed as well a level-selection screen, then saving the player's progress will be necessary

Should The game should implement a range of enemies.

If there is enough time, then a range of enemies should be added in order to add to the ‘fun’ aspect and create an immersive game world.

Should The game should implement a variety of game worlds.

If there is enough time, then a variety of game worlds should be implemented to develop a more comprehensive game.

Should The game should allow the player to shoot projectiles.

This is another common feature in platform games, and if there is time this should be implemented.

Won’t The game won’t feature extensive art.

Although this would make the game more aesthetically pleasing, this does not have any technical benefit and will not be implemented.

Won’t The game won’t implement boss enemies at the end of levels.

Although a common feature in platform games, time constraints mean that this will be impossible to implement.

Priority Feature Description

Must The game must be efficient and run at a frame-rate of at least 30FPS.

This was an explicitly outlined project goal, and so a vital non-functional requirement

Must The game must model the game world well by being robust and well tested.

This is another project goal, and must therefore also be implemented.

Must The game must incorporate elements of fun and be easily extensible.

Again, this was one of the previously defined project goals and must therefore be implemented.

Should The game should be easily usable, with instructions being intuitive.

Building usable software is something which is desirable, and therefore should be implemented if it doesn't jeopardise other more highly prioritised requirements.

Won't The game won’t be fully immersive and have all elements of fun seen in other platform games.

Due to time constraints, this feature will be very difficult to implement without compromising the ability to reach other goals.

Page � of �13 47

2) Non-Functional Requirements

Although the same MoSCoW prioritisation system was used for the software’s non-functional requirements, the primary tool used to establish these priorities were the project goals. This was chosen over the analysis of existing games as the commercial success of the game was not of high importance. These requirements are outlined in table 2.

TABLE 2. NON-FUNCTIONAL REQUIREMENTS

Page � of �14 47

These non-functional requirements were implemented as a result of the development of functional features, and by following the appropriate software design principles (which are discussed later in this section). To validate the presence of these requirements within the system, a collection of evaluation techniques were used. Details of this will be outlined in the appropriate evaluation section.

B. Game Design

To ensure the development of software which successfully met the project goals, considerations regarding the game’s design and features were necessary. These decisions were heavily influenced by the system requirements, and the analysis of existing games.

1) Game Objective

The end of a level in platform games is signified by an appropriate visual representation. Player interaction with this end-point immediately progresses the player to the following level, and is vital in creating a complete game. This feature was therefore implemented in the project, and the chosen representation for this was a portal. When the player interacts with this portal, they are sent to the level selection screen, and the consecutive level is unlocked.

Whilst more advanced games include an ongoing storyline which influences many aspect of gameplay, it was decided that this narrative would not be implemented due to the time constraints that this project presents.

2) Player

A protagonist is intrinsic to a platform game, and the chosen design for the character, named Mawi, is illustrated in figure 3. As outlined in the requirements, the main character features the ability to jump, run and shoot projectiles - for use in enemy combat.

FIGURE 3. Player Design. The collection of sprites that were used for modelling the player and creating the appropriate animations.

For the logistics that controlled the jumping mechanism, the impulse and aerial acceleration features previously discussed were both implemented. Gravity was also developed to create a parabolic path when jumping, and enable the game world to be modelled with familiarity. Beyond this, the option to only allow Mawi to jump when she was on a solid surface was also made. As a

Page � of �15 47

result, features like a double jump were not implemented, and the game stayed true to some elements of real-life physics.

For the running logistics, an infinite-acceleration mechanism was developed. This meant that the player is able to reach the top speed almost instantly; and is also able to come to a complete stop as soon as the appropriate button is released. Infinite-acceleration was chosen over alternate methods to ensure that the user would find it easier to control Mawi throughout the game; by removing any ‘slippery’ motion when a movement button is released. This same infinite-acceleration mechanism was also chosen for the projectiles, with the difference that the projectiles would constantly be travelling at their associated top speed. This is the case as the projectile’s speed is not controlled by user input.

3) Enemies

Enemies have an important role to play in both the implementation of the combat system, which is inherent in all platform games, and the development of key technical skills regarding game development. Therefore, suitable effort was given to the technical and design considerations necessary for the implementation of enemies. In particular, it was decided that the architecture for the enemy classes would be broken into a set of three subclasses. Each class represented an enemy with clear and distinct differences, and utilising this software design principle ultimately allowed for extensible software. This class structure is illustrated in figure 4, and the class descriptions are outlined below:

• Movers - Representing enemies that implement infinite-acceleration, but do not shoot projectiles.

• Shooters - Representing enemies that are stationary and shoot projectiles. • Movers and shooters - Representing enemies that implement infinite-acceleration and

shoot projectiles.

ShootersMovers

Enemy

Movers and shooters

FIGURE 4. Enemy Class Design. The class structure which was used to model the different types of enemies.

Page � of �16 47

Given that the majority of the logistics necessary for implementing the Shooters class was similar to that concerning the player’s projectiles, the priority for implementation was given to the Movers class. This decision was made to ensure that I was able to develop and explore collision detection concerning both the player and the level map. The design created for this type of enemy is illustrated in figure 5.

FIGURE 5. Mover Sprite Design. The sprites that were used for modelling the mover, and creating the appropriate animations.

4) Health System and Collectables

A health system is essential in providing a fair combat system, whereby a mistake during gameplay does not necessarily result in the immediate death of the player. Using the previously analysed games as inspiration, a coin-based approach was developed. This allowed the development of key skills in regards to collision detection and combat, and also represented scalable elements of fun by being easily extensible to the development of a scoring system.

The logistics of the implemented health system involve a counter to keep track of any collected coin. In the event of an interaction with an enemy that harms the player, this count is queried. If zero, the player’s death is appropriately handled. If not, a fraction of these coins are displayed and modelled next to the player. The player’s coin counter is then set to zero, and the player can begin collecting the modelled coins. By only outputting a fraction of the player’s coins, the maximum potential coin count reduces on each consecutive interaction with an enemy, meaning the same coins cannot be used indefinitely. In the implementation, the player is made invincible for a limited time immediately after any such collision with an enemy - further enforcing a fair combat system.

In order to allow extensibility and incorporate elements of fun, the choice was made to represent these coins both as part of the static level-map, and within item boxes - both of which are illustrated in figure 6. These item boxes follow similar logistics to those found in Super Mario, in which hitting the box from below will output a collectable item with an infinite-acceleration, which when collected has an effect on the player. In the project, the only implemented collectable were coins. However, the ability to extend these logistics was enforced by assigning integer ID’s to collectable items, which describe its key characteristics and can therefore easily be altered to model different collectables.

Page � of �17 47

FIGURE 6. Collectable and Item Box Design. The images that were created and used for modelling the item boxes and coin collectables used in the players health system.

5) Level Representation

Forming an efficient link between the 2D space and the current level map is an essential part of modelling the game-world efficiently. This is due to its relevance in governing features of game development like collision detection, and the application of physics.

The spatial enumeration technique that was used to create this link was the tile-engine [11]. This technique works by dividing the game screen into a number of equal sized squares which together create the level map. Each of these equal sized squares are populated by tile images; examples of which are shown in figure 7. Within the code, this level map is represented as a integer 2D array, whose values represent tile ID’s which are used to define the tile type. This technique also aids in saving RAM and increasing real-time rendering performance by allowing larger graphics to be built from the re-use of smaller tiles. Given the O(1) look-up complexity for this method, this was a suitable and efficient solution for map representation which aided in the reaching the project’s goals.

FIGURE 7. Tile Design. The images that were created and used for modelling the tiles that constitute the level art.

The size of the tiles was important to consider given the map’s direct relevance to the size of other game objects. This decision also had a direct effect on the number of tiles visible at any one time on the game screen, and is therefore important. In order to have a constant number of tiles shown on devices of all sizes, the game screen for my project was modelled as 832 x 512px. This was then appropriately scaled during deployment to match the dimensions of the device the application is running on. These specific dimensions were chosen as they represent a mid-point in the various Android phone screen resolutions [13].

The number of tiles required to cover the game screen was used as the deciding factor for the tile size. The option was made to use 64x64 px tiles, which required 104 tiles to cover the game screen. This was preferred over 32x32 px tiles, in which case 416 tiles created the screen graphic - a level of detail that was deemed too high. The tile size also had an effect in determining the player’s size; which was chosen as 128x64 px. This created a level of coherence between the

Page � of �18 47

player and the tiles, which would be useful when developing the appropriate collision detection algorithms. The same is true for the enemies, which were chosen to be 64x64 px.

C. Technology Used

To progress with development, it was necessary to make choices regarding different technology that had to be utilised. These decisions refer to the operating system to develop the project for, and whether a game framework should be utilised to aid in the early stages of development. These decisions, and their rationale, are discussed below.

1) Operating System

There were a number of factors influencing the choice of mobile operating system to utilise. The first of these factors was the reachability of the operating system to potential users. Despite the commercial success of this application not being a priority throughout development, this was regarded as a governing factor due to the future work which could ensue as a result of this project. Figure 8 demonstrates the market share of each mobile operating systems in the US, for the year 2015.

FIGURE 8. Top Smartphone Platforms. Statistics representing the market share of mobile operating systems for the US in 2015 [14].

A cursory look at the market share demonstrates that the Apple and Android operating systems were the only plausible systems to develop for. Given the focus of this project on the growth of key skills regarding game development, the next deciding factor was the learning curve associated with development on these operating systems. Java is Android’s primary language [15], and is a programming language that I am comfortable in using. Therefore, apart from an unfamiliarity with the Android API, the learning curve that would be associated with this development is minimal.

On the other hand, development on iOS utilises Swift as the primary language [16], a variant of Objective-C. Due to having no experience with Objective-C or Swift, the learning curve that would be necessary for development for iOS would be considerably more involved that than of its Android counter part. Therefore, despite iOS applications generating more revenue and having a more structured release cycle [17], the decision to develop on the Android operating system was made due to its compatibility with my project goals.

Page � of �19 47

2) Game Framework

Whilst the use of a game engine would prove detrimental to reaching my project goals; utilising an aid for the preliminary stages of development was deemed necessary. This was due to having no previous significant experience in game development; meaning that the exploration of industry standard techniques and infrastructure was vital to begin progress.

The use of an abstracted game framework which provides the bare logistics needed for Android game development was decided as an appropriate means to perform this exploration. More specifically, the framework provided in ’The Beginner's Guide to Android Game Development’ was used [18]. This decision was made due to the comprehensive explanation the book provides about the associated framework. Given the basic nature of this framework, the abstractions it provides are not directly concerned with the more advanced game code that was implemented. As such, the use of this framework did not deter me greatly from my end goals.

The features that the framework provides are ones that constitute the infrastructure which is necessary in Android games of all genres. These are outlined below:

• Game classes - These classes provide the logistics for the game loop, which is the central code of the application. The classes also initialise and deal with the logistics necessary for the input handler; allowing the manipulation of touch events.

• State classes - An abstracted class which models the game states is provided in this framework. The logistics to transition between different game states are also provided.

• Rendering classes - The framework implements a helper class which is used for Rendering. This provides the scaling logistics necessary for resizing images and other assets to suitably match the deployment device.

• Animation classes - The logistics needed to model frames, and perform the necessary animation are also provided.

• Loading classes - These classes provide the logistics to load ‘.png’ images as well as any sounds which will be necessary for my game

This framework was therefore considered as fitting for my project, and was appropriately utilised throughout development.

D. Planning

To be able to effectively progress with development, a planning method had to be deployed to ensure I would be able to deliver usable software in the given time-scale. This had to encompass the entire software development process, and ascertain the fulfilment of my goals.

1) Agile Methodology

The agile software development methodology was chosen as the most appropriate for my project. This was due to its ability to produce valuable software throughout all stages development, and provide a methodology where the timeline is fixed, but the scope is flexible. Employing the agile methodology also meant that I was able to divide the tasks that constitute

Page � of �20 47

the development of my project into meaningful releases. Therefore guaranteeing the development of key skills which exercise the whole system, even if I was not able to completely fulfil the project brief.

To utilise these benefits, a number of Agile practices were employed. These are discussed below.

a. Short Incremental iterations

The use of incremental iterations is an important practice in the Agile development methodology as it facilitates the delivery of valuable software at the end of each iteration. This is done by dividing the system into parts that are themselves complete, but only represent part of the systems full requirements. By iterating this development process an appropriate number of times, a software artefact which completely fulfils the requirements is created.

For my project, iterations of one month in length were used. This was due to the triviality of customer feedback - which is one of the main driving forces in employing short iterations [19]. A month was therefore chosen as a suitable trade-off, which allowed appropriate time to be devoted to development whilst still gaining the benefits of shorter iterations. This meant that a total of 5 iterations made up the entire development process. The technique used to model requirements and group them into suitable iterations is discussed below.

b. User Stories

User stories provide a brief description of functionality which can be written at different levels of abstraction [20]. This was important as it allowed for a just in time approach to planning, whereby only user stories that are to be implemented in the near future are described in a fine-grained manner.

To group stories into meaningful release, a set of highly abstracted user stories which described the entire system were first created. These were modelled as thin end-to-end slices of functionality which exercised the whole system. A brief outline of the functionality necessary for each iteration was then created. This was done by constructing a high level picture of what the overall project must develop, and simultaneously seeking to implement the most valuable features.

At the beginning of each iteration, the group of abstracted user stories which described the iteration’s outlined functionality was identified. These stories were then refined into a collection of more detailed user stories. To prioritise effectively during an iteration, value points were assigned to each story. Only relative priorities between stories in iterations were assigned to simplify this process.

These finely-grained user stories were then broken down into their corresponding tasks by utilising a physical task board. This process is described in the sub-section below.

c. Physical Task Board

The task board is an agile practice which provides a visualisation of the tasks that need to be completed within an iteration, as well as their respective progress. This is done by decomposing a

Page � of �21 47

user story into a series of tasks, and placing them in the corresponding task board column to represent their current state.

For my project, I identified that user stories could be broken down into a collection of ‘Create X’, ‘Design X’, ‘Test X’ and ‘Implement X’ task cards. Each user story was therefore translated into a collection of these tasks, ensuring that upon completion the original user story's functionality was implemented. These tasks were then created and moved between task board columns during development to demonstrate their progress. Figure 9 illustrates the task board that was used during development.

FIGURE 9. Physical Task Board Mid-iteration. The task board that was used during development, demonstrating columns and materials used.

Using a task board aided the development progress by providing a visual cue of the tasks that needed to be implemented. This enhanced the ability to prioritise by being able to quickly determine the tasks in an iteration, and their respective process. In addition, the nature of the task board made it extremely adaptable and flexible. This helped by being able to add task cards for overlooked/missing tasks, as well as being able to represent issues discovered during development on-the-fly; i.e bugs.

E. Software Design

The design of software plays a direct role in determining its extensibility and manageability [21]. This ensures that adding features does not require extensive corrective action, and therefore incorporating good software design was significant to reaching project goals.

1) General Responsibility Assignment Software Patterns (GRASP)

This collection of design patterns define guidelines for the assignment of responsibility between classes and objects [22]. These principles attempt to create re-usable software which exhibits high cohesion and low coupling; ultimately aiding in developing extensible software. The patterns that were implemented are outlined below.

Page � of �22 47

a. Factory Pattern

A factory is a class whose sole purpose is to return ‘objects of a varying prototype or class’ [23]. Appropriate use of this pattern can therefore ensure the creation of the correct object, and provide a great deal of convenience by making the coding process more efficient and straightforward.

The creation of the level-map was established as a process which would benefit from this pattern. This was due to its varying prototype, the important role it played within the applications lifecycle, and its frequent use and creation. A TileMapFactory class was therefore created which would perform the logistics which are necessary to parse a given ‘.txt’ level file into the appropriate 2D array.

b. Indirection Pattern

Indirection is the process whereby an object delegates its responsibilities or tasks to a helper class. This process is abstracted from the calling code, and provides a simplification of the necessary logistics - improving the manageability of the software [23].

Given the varying logistics necessary for rendering, and the importance of this operation, an appropriate TileMapRenderer class was developed. This class implements a range of methods to aid in the rendering process, and uses indirection to delegate its responsibilities to different classes - all at a level of abstraction from the calling code. These include invoking the rendering helper class provided by the game framework, as well as querying the appropriate Tile or game object.

c. Information Hiding Pattern

By enforcing this design pattern, certain characteristics of a class or component are hidden from its clients [24]. Applying this principle to elements that are susceptible to change protects the program from extensive reparative action, if any such change happens.

This was incorporated throughout development by utilising the necessary segregation techniques. Examples of this include using the private and protected identifiers, and implementing getters and setter to hide or restrict direct access to variables. This protected the integrity of these components by restricting users from forcing it into a inconsistent state. Beyond this, use of final variables and abstract classes also aided in encapsulating and bundling the necessary logistics to the methods that require them; making them more resilient to change.

c. Polymorphism Pattern

This design principle refers to the use of inheritance to model classes with a common superclass [24]. The use of this pattern is necessary in modelling a clear ‘is-a-kind-of’ relationship between super and sub classes. By creating a set of subclasses that are different in some nontrivial way, we are able to easily extend the software. Employing this technique correctly also allows similar characteristics between subclasses to be shared in the superclass; removing repetitive code.

An example of the implementation of this technique in this project is highlighted in the previously discussed enemy class design.

Page � of �23 47

2) High-level Description of System Architecture

To specify and describe the overall architecture of the system, two UML diagrams were used. The combination of these enabled requirements to be realised into a coherent system structure - aiding development and ultimately assisting in reaching the project goals.

a. Class Diagram

Class diagrams play a vital role in demonstrating the static structure of the system by illustrating the individual role of classes, as well as their inter-class associations. This structural consideration of classes and their interactions can aid greatly in developing a more robust application [25], which is important given the scale and goals of the system.

In an attempt to increase the system’s cohesion and reduce the coupling exhibited, the structure was tweaked several times throughout the design phase. Figure 10 demonstrates the final class diagram, which represents closely the final architecture of the system. For the sake of clarity, some attributes and methods (mainly getters and setters) that are not being pivotal to the understanding of the system are omitted from the class details.

As illustrated in the diagram, the GameView class initialises the system and contains the game loop. This has the main responsibility of updating the system’s current game state; which in turn updates and renders the classes that model the game world. These game object classes employ the logistics necessary in effectively modelling the game world, such as physic and collision detection, and are evoked within their respective update methods. These classes are also passed the value ‘delta’, which represents the time an iteration of the game loop has taken. This allows frame-independent movement to be implemented, and is discussed in more detail in the implementation section.

As highlighted in the class architecture, there is no layer of abstraction which distinguishes the game code from the underlying game engine. This decision was made in an attempt to speed up the development process by not focusing on implementing such an abstraction. Furthermore, with no abstraction the ability to adapt code to model the different needs of game objects is made more straight forward.

b. Activity Diagram

Modelling the dynamic behaviour of the system was also necessary to further realise the project requirements, and establish a complete view of the system. By considering the workflow of the system, the activity diagram provides an important technique to evaluate and improve the system before implementation [25].

Throughout the design process, this diagram was tweaked to improve different aspects of the systems workflow. Figure 11 illustrates the final activity diagram. The behaviour which is necessary in each of the distinct game states, as well as the type of state transitions that can be made are demonstrated in the diagram. Beyond this, decision points, and the input which controls these decisions is also illustrated. This aided in reaching the project goals by highlighting clearly the behaviour that is necessary to implement.

Page � of �24 47

FIGURE 10. Class Diagram. The class diagram which models a static view of the systems architecture at a class level. Blue represents classes that were created entirely by me, white represents classes provided by the framework which were not tweaked, whilst pink represents classes provided that were tweaked.

Page � of �25 47

FIGURE 11. Activity Diagram. The activity diagram which provides a graphical representation of the system’s workflow. This is done by defining the different states of the system, and the series of actions it performs.

Page � of �26 47

VI. IMPLEMENTATION

HIS chapter outlines the implementation of the software, and how the previously stated design considerations were incorporated into the system. This chapter is broken down by focusing on the more complex states of the game, and describing the implementation of features which are intrinsic to each of these states.

T

A. Play State

The Play State represents the state the application is in when the user is playing one of the game’s levels. This state is concerned with dynamically modelling the game world, and is therefore central to the application. Many of the game features which were previously outlined are implemented and exercised within this game state.

1) Physics

To effectively model the movement of game objects, a suitable implementation of physics is necessary. The level of complexity for the implemented physics vary greatly between the different models; primarily owing to their respective move-set and characteristics. These implementations are therefore grouped to reflect this.

a. Enemy and Collectables

With both of these game objects enforcing an infinite-acceleration that is not controlled by user input, they share logistics which govern their movement. As such, both can be grouped and discussed simultaneously - without the loss of implementation detail.

This type of infinite movement is modelled by each relevant game object having an associated velocity value for the X and Y direction. With enemies and collectables moving constantly in the X direction, a predetermined X velocity value is added to their respective X co-ordinate on each iteration of the game loop. This has the effect of moving the object by a set amount of pixels in the desired direction - effectively modelling movement. The velocity value is multiplied by the delta value previously discussed before being added to the X co-ordinate - creating persistent movement irrespective of the frame-rate. The direction of travel is determined exclusively by interactions with the level map; with any suitable collision negating the velocity value, and consequently reversing the associated direction.

To model the game world successfully, movement in the Y direction is solely determined by the tiles that are underneath the objects. When any such object has no solid tiles underneath it, an abstracted implementation of gravity is implemented which alters the object’s associated Y velocity. The logistics which enforce this type of movement is demonstrated in figure 12. This creates a accelerated downward movement which continues until the object falls onto a ‘solid’ tile - in which case the Y velocity of the object is set to zero, and movement in the Y direction stops.

Page � of �27 47

If object is not grounded { if (yVelocity is not greater than a pre-determined maximum) { yVelocity += (gravity_constant * delta); } // if

else (yVelocity is greater than pre-determined maximum) { yVelocity = pre-determined maximum; } // else

y += (yVelocity * delta);

} //end

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13:

_____________________________________________________________________________

__________________________________________________FIGURE 12. Gravity Pseudocode. This code is used in the implementation of gravity; moving the game object downwards. This is done by continually increasing the y velocity of the object to a pre-determined maximum. This is then added onto the y value - modelling downward movement whose speed is increased on each iteration of the game loop.

b. Projectiles

Whilst projectiles also enforce an infinite acceleration which is not controlled by user input, their trajectory differs to that of enemies and collectables. The distinguishing factor of this movement is the projectile’s continuous movement in the Y direction - which is made to create a bouncing motion. Movement in the X axis however is identical to the implementation for other infinite acceleration objects, and will therefore not be discussed.

Throughout a projectile’s lifetime, the implementation of gravity (figure 12) alters its associated Y velocity. This is made to create a bouncing path by allowing collisions with the level map to dictate the object’s direction. By inverting the projectile’s path when a suitable collision is registered, the projectile has a initial speed boost in the appropriate direction, which is then subsequently affected by gravity. This creates a parabolic path, and when the correct values and restrictions for velocity are used, a bouncing path is effectively modelled within the game. A visual representation is provided in figure 13.

Page � of �28 47

1. VelY = 0

2. VelY = 50

3. VelY = 100 5. VelY = -100

6. VelY = -50

7. VelY = 0

4. COLLISION

FIGURE 13. Projectile’s Path. This figure illustrates a simplified projectile path, broken down into 7 different steps, with the Y velocity values described at each step. This demonstrates how the implementation of gravity, in combination with collision detection, allows a bouncing path to be modelled.

c. Player

With the player’s move-set being dictated entirely by user input, a number of different considerations are needed to effectively model this movement. Like other game objects, the player also has associated velocity values which are used as the primary tool to create movement.

To control the player on the X axis, two buttons are used to represent left and right movement. When one of these pressed, this has the effect of setting the velocity to a predetermined starting value which is then multiple by the delta value, before being added the players X co-ordinate. While the user is holding the respective button down, this velocity is incremented on each iteration of the game loop until a maximum velocity is reached - effectively acting as acceleration. Releasing the respective button brings Mawi to a complete stop, by making the velocity zero and halting manipulating of the X co-ordinate.

On the Y axis, the player is controlled by either the use of the jump button, or by detecting that the player is not grounded. The latter is performed by using the same gravity method discussed previously. Extending these logistics to jumping was done by setting the player’s Y velocity to a pre-determined value once the jump button was pressed. This value is then manipulated by the gravity and the delta value - creating a parabolic path which effectively models jumping.

2) Collision Detection and Optimisations

As previously discussed, detecting collisions with objects and the level map is essential to modelling the game world effectively. As this is a feature that is performed on each iteration of the game loop, appropriately optimising these methods will aid in being able to reach the target frame rate. This was verified by removing the implemented optimisations, which demonstrated that these techniques have the effect of increasing the frame rate by approximately 5FPS. As the algorithms and optimisations developed vary for the different sizes and responsibilities of the game objects, they will be divided into suitable subsections to reflect this.

Page � of �29 47

a. Player

Given the dynamic nature of the player, implementing robust collision detection algorithms was pivotal to reaching the project goals. Beyond the previously mentioned uses, these algorithms also allow suitable restrictions to be placed on players movement; ensuring consistency within the game world.

To detect collisions with the level map, scan-lines are used to describe positions where any such collisions could occur. Figure 14 and 15 illustrate the positions of these scan-lines for movement along the different axes. These positions were chosen as they create query spots that are tightly correlated with the level map. For example, when moving along the X axis, two equally displaced scan lines on the player’s Y axis are necessary due to the size difference of the tile and Mawi. This arrangement of scan-lines ensured that any suitable detections were registered and appropriately handled. In the Y direction, the chosen scan-lines allow us to verify whether Mawi is completely on or off a tile.

X

X

X

X

X X

X XFIGURE 14. Player Scan Lines for X movement. This shows the placement of the scan lines that were used to establish collision with the level map when moving along the X axis. The green Xs signify the positions queried for collisions.

FIGURE 15. Player Scan Lines for Y movement. This shows the placement of the scan lines that were used to establish collision with the level map when moving along the Y axis. The green Xs signify the positions queried for collisions.

When a collision is detected, the co-ordinates of the intersection is converted into the corresponding level map index, which is then queried to determine the type of tile. This information is used to dictate the action to perform; which extends from releasing collectables from item boxes, to registering end of level tiles and allowing the player to progress within the game.

As this algorithm is constantly utilised throughout the play-state, it needed to be appropriately tailored to prevent any redundant queries. Information about the player’s movement was the primary tool for this. These optimisations ranged from not performing detection checks when the

Axis Current Movement

Preliminary Check

Meaning Secondary Check Meaning

Y Rising (TopY % TileHeight) >= 58

At least one tile of interest

Moving right && (RightX % TileWidth >= 62) OR Moving left && (LeftX % TileWidth <= 2)

Two tiles of interest

Y Falling (BottomY % TileHeight) <= 6

At least one tile of interest

Moving right && (RightX % TileWidth >= 62) OR Moving left && (LeftX % TileWidth <= 2)

Two tiles of interest

Axis

Page � of �30 47

player is stationary, to only checking the relevant intersections points during movement. Information about the previously checked tiles was also used to remove any unnecessary repetitive checks, and data which made checks redundant was also appropriately exploited.

b. Enemies and Collectables

The same general techniques and optimisations discussed above were also implemented for enemies and collectables. These algorithms had to be suitably tailored to the object’s features, which included appropriately altering the scan lines and utilising the infinite acceleration that these object exhibit.

With the interactions between these objects and the player also being vital for features like a combat system, a different type of collision detection method was required. This is because dynamic objects cannot be modelled as part of the static level map, and therefore the current detection system cannot be altered to aid in this process. Instead, axis aligned bounding boxes (AABB) [26] were used. This method works by creating a rectangle object which surrounds an entire object sprite, and is used to determine any collision with other AABB. My implementation utilised the Rect class provided in the Android API [27] to model these AABB, and query any intersections. Preliminary checks of objects visibility were done before any intersection queries with the player’s AABB were performed.

c. Projectiles

The projectile’s sprite size was chosen to be 16x16 px due to the nature and purpose of these objects. This size difference between level tiles and projectiles consequently meant that the current logistics needed to be altered.

To create an efficient process in which collisions were only queried when the projectile was close enough to a tile boundary, a number of preliminary checks were developed which used the modulus operator. Details of these checks, and their meanings are discussed in table 3. Following this, similar methods to those previously described were used to query the appropriate map index, and perform the necessary action. Despite the smaller size, the same AABB logistics were still applicable for detecting collision with the projectiles and game objects.

TABLE 3. PROJECTILE PRELIMINARY CHECKS

X Right (RightX % TileWidth) >= 58

At least one tile of interest

Moving up && (TopY % TileHeight >= 62) OR Moving down && (BottomY % TileHeight <= 2)

Two tiles of interest

X Left (LeftX % TileWidth) <= 6

At least one tile of interest

Moving up && (TopY % TileHeight >= 62) OR Moving down && (BottomY % TileHeight <= 2)

Two tiles of interest

Current Movement

Preliminary Check

Meaning Secondary Check MeaningAxis

Page � of �31 47

3) Health System

In the final project, there were two potential causes of player death. The first of these cases was the player falling off the level map. This type of event only occurs on the Y axis, and is identified when the character’s Y co-ordinate is greater than the maximum Y for the associated level. This results in the immediate death of the player, and is signified by an appropriate animation.

Player collision with enemies represents the second case of potential death. Figure 16 illustrates the logistics used to determine the effect of any interaction with the enemy and the player. The health system which was discussed within the design chapter was fully realised and implemented within the game. In regards to the combat system, a player’s projectile interacting with an enemy results in the immediate death of the enemy, and is established by AABB intersections.

ENEMY HARMED PLAYER

HARMED PLAYER HARMED

FIGURE 16. Effect of Collision with Enemies. The dotted line represents the position the player must be above to have an effect on the enemy. More specifically, the bottom of the player’s AABB must greater than the top of the enemy AABB minus a pre-determined value.

Page � of �32 47

4) Camera

With the level maps being considerably larger than the game screen, the development of a camera was necessary to enable the user to freely explore the entirety of the level map. This was implemented by creating a camera class which was updated on each iteration of the game loop. This queries Mawi’s position against pre-determined thresholds to determine the camera offset in the X and Y axis.

The positions of these thresholds are illustrated in figure 17. The logistics used to update the camera offset variable in the case of right movement is described in pseudocode in figure 18. These basic logistics were then extended and suitably altered for movement along different axes. Restrictions were also suitably implemented which queried the current camera offset to ensure that only viable conditions were checked. These offset variables are then used during rendering and collision detection to establish the position of Mawi in reference to the level map, and render the appropriate section of the level.

FIGURE 17. Camera Threshold Positions. This diagram illustrates the positions used for the camera thresholds in the X and Y direction. The distance between respective thresholds was created to implement a dead-zone. This provides the player freedom to move within this band without triggering camera motion - preventing the camera from being too active.

X AXIS Y AXIS

If player is moving right && cameraOffsetX != maxOffsetX {

if (playerCentreX is greater than xThresholdRight) { overRun = playerCentreX - xThresholdRight; } // if

cameraOffsetX = cameraOffsetX + overRun; lock the players X value to the xThresholdRight value;

} //end

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11:

_____________________________________________________________________________

_______________________________________________________________________FIGURE 18. Camera Pseudocode for Movement in X.This code is used in updating of the camera offset variable when the player is moving right. This is done by querying the players mid-point against a pre-determined xThreshold. If the player has overrun the threshold, then this overrun value is added to the current camera offset value and the player is locked to the threshold.

Page � of �33 47

5) Rendering and Optimisations

Rendering plays an important role in achieving the target frame-rate. This was signified during development, where rendering the entire game screen on each iteration of the game loop resulted in a significant reduction of the frame rate. Beyond just enforcing common optimisation techniques like view culling [28], and only rendering when movement is detected; enforcing techniques to prevent constantly rendering the entire game screen was pivotal to the project’s success.

The only situations which require the entire game screen to be rendered are the start of a level, or when the player causes camera movement. In the case where no camera motion is detected but object movement is, only rendering the updated sprite positions causes an undesirable overlay due to previous sprites remaining on screen. Therefore to effectively model movement, algorithms were developed to prevent this type of overlapping.

The TileMapRenderer class implements a range of these clearing algorithms and is central to performing these optimisations. These methods use information about the size of the game object, the direction of travel and current position to clear a minimal area around the current sprite. This then allows the updated sprite to be rendered without any overlay - successfully creating the illusion of movement. Experiments during development showed that this increased the frame rate from approximately 25 FPS, to 40 FPS.

B. Level Editor State

This is the state where the user is able to interactively create and edit a level map. This state incorporates the logistics to draw and erase tiles, as well as the ability to move around the level. The state also allows the user to switch seamlessly between editing and playing the level map. The appropriate details of these logistics are discussed below.

1) Editing Toolkit

Given the touch-centric nature of the application, an intuitive and methodological approach to handling tool selection was necessary. This implementation also needed to ensure that it did not have a restrictive effect on the user’s ability to edit the level. Figure 19 illustrates the toolkit implemented and its different states.

Upon selection of a tool, the user is able to perform the associated action on the editable level. To create an unrestrictive environment, any touch event which is outside of the toolkit’s area of interest immediately causes the toolkit to minimise. To increase the intuitiveness of the state, an appropriate reminder of the tool selected is display against the toolkit icon.

Page � of �34 47

FIGURE 19. Level Editor Toolkit States. The black boxes represents touch events, which create the effect shown in the following picture. This illustrates the compact nature which was enforced to ensure that the toolkit did not obstruct design this band without triggering camera motion - preventing the camera from being too active.

1:

2:

3:

4:

2) Editing Tools and Camera

The placement and deletion of tiles was implemented by converting a registered touch event into the corresponding level map index. The integer value inside this map index is then appropriately altered, and this edited tile is then suitably rendered to illustrate the change. Being able to switch between drawing different tiles during tile placement was pivotal, and the graphical implementation of this in the toolkit can be seen in figure 19 (picture 3). This causes the corresponding tile ID to change, which is appropriately utilised when editing the level map.

Camera movement is controlled using the same general logistics as those utilised in the play state. More specifically, this implementation also has respective offsetX and offsetY variables which are utilised by the rendering pipeline. With touch input controlling the camera however, no thresholds are used, and some necessary differences and precautions had to be taken. The most important of these was the ability to lock the camera movement to a single touch pointer ID. This ensured that in the case of multiple touch movements being registered, only one would cause the camera to move - preventing jittering movements when pointers are released.

3) Level Size

Being able to create levels of different size was necessary to develop a level editor that was truly useful in streamlining the level design process. The was approached by initialising this state with a 100x100 tile sized level. Throughout editing, the value of the furthest tiles in the X and Y axis are updated. When the player selects to either save or play the level, these values are then used to appropriately trim the level map. When transitioning from playing an edited level map back to the level editor, this trimmed map is converted back to the 100x100 format. Allowing the user to further edit the map, and size, if necessary.

Page � of �35 47

4) Saving and Using Edited Levels

Of Android’s storage options for persistent data [29], internal storage was the most applicable for the purpose of saving and utilising these edited levels. However, any stored data of this type is removed when the application is uninstalled, and is completely private to the running application - meaning the user and developer is unable to access these files. This consequently meant that these files could not be stored to the applications assets folder, and be permanently utilised as a level in the game.

Therefore, as well as saving files onto internal storage to allow editing of previously saved levels, the logistics to print the level map in the format used by the TileMapFactory was implemented. This was then manually turned into the corresponding ‘.txt’ file, which was then placed in the assets directory and coded into the level selection state appropriately.

5) Plating Edited Levels

A LevelEditorPlayState class was developed to allow the user to play, and essentially test, the edited level. Given the similarities to the PlayState, the LevelEditorPlayState class duplicated the majority of the logistics implemented in the PlayState; with some crucial differences. The most important of these was the constructor, which expected a 2D array which represented the edited level. This consequently enabled the transition between playing and editing without it being necessary to save the level map - streamlining the level creation process considerably.

Page � of �36 47

VII. EVAULATION

HIS chapter covers the evaluation methods that were used throughout the course of implementation. These verified the software, and helped judge its effectiveness in reaching the project requirements and goals. The first subsection discusses the software testing methods used. This is followed by an explanation of the external testing that took place, and the results and findings of this testing.

T

A. Software Testing

Ensuring that data structures and algorithms operated correctly was the main motivation for utilising software testing [30]. These tests were conducted in a number of different ways; ranging from utilising the interactive and graphical nature of the application, to more formal JUnit tests for individual methods and components. This process took place both during and after implementation, and when paired with the Android Studio Debugger, allowed immediate corrective action to take place.

1) Manual Testing

As part of the task board which was utilised throughout implementation, test cards were designed to corresponded to each development task. These test cards defined a series of test cases which were created using equivalence partitioning and boundary analysis techniques [31]. Integrating testing into the task board ensured that continuous, and therefore extensive [32] testing was performed throughout implementation. These test cards also acted as an objective measure of completeness for the corresponding development tasks.

In the early stages of development, these test cases were exercised by temporarily hardcoding values which forced the case described. The outcome was then verified by utilising the Log class provided in the Android API [33]. As the application became more graphical and interactive, I was able to exercise some of these test cases by utilising the developed features within the application, and examining the graphical output in combination with the Log output. This was particularly true for testing rendering operations and collision detection.

If any test cards failed, then an appropriate ‘fix bug X’ card would be created and modelled on the task board. This was only considered done when the previously failed test card passed. Whilst this type of testing was sufficient as a preliminary means of validation, the need for more in-depth testing was necessary to develop a fully robust system.

2) Unit Testing

Unit testing was used to incorporate a formal testing method which ‘verifies functions and classes by ensuring their correct operation’ [34]. In order to only test the methods and classes of interest to the associated unit test, the Mockito API was used [35]. This allowed java objects and Android API which code was dependant on to be adequately mocked and controlled - eliminating redundant test code and providing a great deal of flexibility.

Page � of �37 47

These unit tests were created with the fundamental aim of covering all methods which I had developed. My understanding of the code, and its interactions, was used to create a priority system of the classes, and establish which functions to test more thoroughly. The necessary test methods were then designed by using the same equivalence partitioning and boundary analysis techniques used in manual testing. Any failure in tests were appropriately handled and debugged.

The code coverage statics which were reached in the final submission are demonstrated in figure 20. Whilst the entirety of the code was not tested, the degree of validation was deemed satisfactory, especially when considered with the prioritisation system that was used. Consequently, this demonstrates a considerably well tested and robust software system.

FIGURE 20. Final Unit Test Coverage Statistics. Data signifying the total coverage of unit tests of classes in the entire project. This is broken down into the respective program packages; and describes statistics for classes, methods and lines covered by unit tests.

3) Performance Testing

Determining the system’s responsiveness when faced with a ranging workload was the main purpose for utilising performance testing [36]. The frame-rate was the key testable criteria for the system. By implementing the frame-rate counter in the game loop, all of the system’s game states could be appropriately tested and examined. States of interest were determined as ones where the user was interactively controlling some aspects of the game, and where a drop in frame-rate could produce a detrimental effect to overall experience.

In order to get a representative value for a state’s frame-rate, the imagined use of the state was tested in combination with the worst case scenarios. This data was then used to determine the average and minimum frame rate. The results of this, together with an explanation of the methods used to test the worst-case scenario, is shown in table 4.

State Average frame-rate (FPS)

Worst frame-rate (FPS)

Worst-case method

PlayState 47 38• Constant firing of projectiles • Erratic player movements that does not follow

the intuitive level path • Allowing game objects the longest life possible

LevelEditorState 52 46 • Erratic placement and deletion of tiles • Erratic and non-intituive camera movement

LevelEditorPlayState 45 32• Creating levels with several item boxes and

releasing the collectables quickly • Erratic and non-intuitive player movement • Constant firing of projectiles

LevelSelectionState 53 50 • Erratic player movements

Page � of �38 47

TABLE 4. FRAME-RATE TESTS

As is evident, the target frame rate was successfully achieved - even in the worst case scenarios. This can be seen to be a combination of the optimisations and restrictions enforced. These restrictions include only allowing a maximum of 10 projectiles, and enforcing a lifetime on all game objects to ensure that they are not updated infinitely.

B. External Testing

Whilst the commercial success of the software was not a primary concern, it was important to gather data regarding the system from external users. This ensured that opinions on important aspects of the application could be examined.

This type of testing was conducted by gathering a group of eight participants, who were asked to play through the five levels which make up the game. In order to test the usability and intuitiveness of the application, explicit instructions were not provided. Once completed, a questionnaire which utilised the Likert scale [37], and had an open comments section, was given to each participant to gauge their opinions regarding important aspects of the game. The full questionnaire is provided in Appendix A. The results from the Likert scale questions are illustrated in figure 21.

The results below signify an overall agreement of the various statements presented. This demonstrates the usability of the software, and its success in modelling the game world and the features that exist within it.

The next section of the questionnaire asked respondents for a qualitative response regarding any improvements to the game which would make it more immersive and fun. The most common response, with seven participants suggesting this type of improvement, was to add more features. These features included powers-ups, more enemies, and a larger variety of interactive game objects. Given the scalability considerations made throughout implementation, these are features that could be implemented within the game with minimal effort. The process that would be involved in adding these features is discussed in the following section.

Page � of �39 47

The aim and controls of the game are clear

The game was reactive, and responded quickly to

actions performed

I was able to fully control the player as desired

The game world reacted as expected

25% 50% 75% 100%

12.5%

12.5%

37.5%

37.5%

25.0%

87.5%

50.0%

62.5%

75.0%

Strongly agree Agree Don't knowDisagree Strongly disagree

FIGURE 21. Statistics Illustrating Responses to Questionnaire. Data signifying the responses of the various statements used in the questionnaire for external testing of the project.

Page � of �40 47

VIII. REFLECTIONS AND CONCLUSIONS

HIS chapter details the conclusions that can be drawn about the project. This type of evaluation was performed by comparing the features in the system against the project goals and requirements. The lessons that were learned during the course of implementation, and the skills developed are also reviewed. The future of the project, and a final summary provide the conclusion to this chapter, and the report.

T

A. Objective Reflection

The first tool which was used to quantify the project’s completeness was whether the goals were achieved. This provides an analysis of the project’s focus, and highlights any potential areas of concern.

The evaluation techniques described in the previous chapter provide an objective measure of completeness for the first two goals. More specifically, the analysis of the frame rate and external testing demonstrate a responsive game which meets the target frame-rate and models the game world successfully and intuitively. Utilising the agile methodology during development meant that tasks were grouped and tackled in a fashion which ensured the entire game development pipeline was continually exercised. As such, the development of key technical skills regarding both game and software development can be seen to have followed as a natural consequence of the development effort.

The external testing also provides evidence for the implementation of the basic features necessary for a fun and immersive game. However, a more detailed analysis of the features implemented is required to be able to fully quantity the achievability of this goal. This is discussed in the following subsection.

B. Feature Reflection

The functional requirements which were prioritised with a ‘must’ priority in the design chapter were all successfully implemented in the developed software. This then allowed some of the ‘should’ requirements to also be implemented, and demonstrates the project’s success in terms of feature functionality.

Of the non-functional requirements prioritised as a ‘must’, the extensibility of the software is the only requirement which hasn’t been explicitly quantified in this report. Therefore, to determine the degree of scalability demonstrated in the software, the process that would be required to implement the improvements specified in the external testing sub-section were examined. This is described below:

• Power ups: Collectables have an assigned integer ID which represent the object’s associated characteristics - including the image and size. This ID is queried by the player class when a collision with any such object is registered, and determines the action to perform. Therefore extending these logistics to include a power-up would involve creating the respective ID and image, and implementing the logistics which govern the power up’s effect. This is not a heavily involved procedure, and demonstrates part of the software’s manageability and extensibility.

Page � of �41 47

• Enemies: Given the way that the enemy classes were structured, adding different enemies would simply involve creating the suitable subclass and implementing the necessary logistics. This would then have to be initialised and updated in the appropriate state class to add the feature to the game - a relatively straight forward and manageable process.

• Game objects: Static game objects could be incorporated into the level map by extending the logistics in the tile class. This would be done by creating the appropriate image, a distinct integer ID to represent this new tile, then creating an appropriate ‘.txt’ level map to utilise this new tile. Adding dynamic game objects however would involve more extensive efforts. This process would require creating the new class and logistics, and then appropriately updating the classes where interaction with these objects is of interest.

As outlined, real efforts were made when possible to ensure that the software was extensible, and features could easily be added without extensive reparative efforts. Therefore, the conclusion that all the non functional were successfully implemented can sensibly be reached, and lends support to success of the overall project.

C. Lessons Learnt

During the course of the project I was able to develop a more advanced understanding of the processes and effort involved in creating software. The change of project goals stresses the need to set goals that are realistic and attainable in the given time frame. Doing so prevents a rushed approach during implementation, and ultimately allows better software to be developed by devoting sufficient time to consider important design aspects.

Effective time management and planning was also stressed as being of great importance during development. The agile software methodology aided this planning process by providing a great deal of flexibility during development, and ensuring that valuable software would be delivered. As such, I would recommend this methodology to other students in an effort to ensure they are able to utilise the provided time effectively.

The importance of architectural and design consideration were also highlighted during the development of a such a large project. This type of rigorous pre-planning is absolutely necessary to develop complex software which is manageable. Utilising these techniques ultimately speeds up development, and is something I should have focused more attention to. More meticulous scrutiny of the project’s architecture would have allowed me to further highlight areas of improvement. This could have been achieved by utilising more behavioural UML diagrams, and considering more carefully class responsibilities. From this, repetitive code which could have benefited from being grouped together and represented in a single class would have more readily been identified; for example a collision detection class.

A further improvement would have been to utilise more agile practices - in particular Automatic test driven development (ATDD). This would have further validated the system, and ensured that development adhered strictly to the requirements; preventing any unnecessary functionality from being implemented.

Page � of �42 47

D. Future Work

As highlighted in the evaluation section, adding more features would be an interesting advancement for the software. This would allow me to further explore and develop skills required in game development, whilst simultaneously adding more commercial value to the software. By creating a more immersive and feature-rich game, this could then also be deployed to the Google play market [38].

Developing a new project which utilises 3D graphic would allow me to explore and develop skills that have not been explored within this project. With no time constraints, I would also be able to develop my own game engine, and gather an in-depth understanding of the techniques and features necessary. This would prove beneficial for future career prospects, both in and out of a game development respect.

E. Final Summary

In conclusion, by placing sufficient effort on the planning and design considerations that were necessary, I was able to approach development in a structured fashion. Although these efforts could have been improved, they allowed me to create well designed software that successfully fulfilled the aims and requirements of the project. Whilst there is a clear scope for more features to be added, the effort required to implement these is minimised due to the software’s design. As such, the change in project goals was a sensible decision which proved beneficial to the software’s architecture, and overall design.

Page � of �43 47

IX. REFERENCES

[1] [2] [3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

Cho, J. (2014). Beginners Guide to Android Game Development. Dublin: Glasnevin Publishing. Adams, E. (2006). Fundamentals of Game Design. 2nd ed. Berkley: New Riders. Angybirds.com, (2016). Angry Birds official Website. [online] Available at: https://www.angrybirds.com/games/ [Accessed 27 Apr. 2016]. CandyCrushSaga.com, (2016). Candy Crush Saga Official Website. [online] Available at: http://candycrushsaga.com/ [Accessed 27 Apr. 2016]. Robinson, E. (2016). Characteristics of Good Puzzle Games. [online] Available at: http://www.7128.com/articles/resourcesarticle080731.html [Accessed 27 Apr. 2016]. iTunes.com, (2016). Temple Run. [online] Available at: https://itunes.apple.com/gb/app/temple-run/id420009108?mt=8 [Accessed 27 Apr. 2016]. Purchese, R. (2013). Temple Run 2 is the fastest-spreading mobile game ever. [online] Available at: http://www.eurogamer.net/articles/2013-02-01-temple-run-2-is-the-fastest-selling-mobile-game-ever [Accessed 27 Apr. 2016]. Platform Game (n.d). In: Oxford Dictionaries [online]. Oxford University Press. Available at: http://www.oxforddictionaries.com/definition/english/platform-game [Accessed 27 Apr. 2016]. GameCubicle.com, (n.d). Super Mario Sales. [online] Available at: http://www.gamecubicle.com/features-mario-units_sold_sales.htm [Accessed 27 Apr. 2016]. Infogr.am (2016). Sales of Sonic Games. [online] Available at: https://infogr.am/sales_of_sonic_games [Accessed 27 Apr. 2016]. Wolf, M. (2012). Before the Crash; Early Video Game History. Michigan: Wayne State University Press, pp. 151-189. Clegg, D. and Berker R. (1994). Case Method Fast Track: A Rad Approach. Boston: Addison-Wesley Longman Publishing Co. GravityLab (2014). What are the common Android screen resolutions? + the android screen sizes + list of screen resolutions. [online] Available at: http://www.gravlab.com/2013/11/21/common-android-screen-resolutions-video/ [Accessed 27 Apr. 2016]. ComScore. (2016). ComScore Reports November 2015 U.S. Smartphone Subscriber Market Share. [online] Available at: https://www.comscore.com/Insights/Rankings/comScore-Reports-November-2015-US-Smartphone-Subscriber-Market-Share [Accessed 27 Apr. 2016]. Developer.Android.com. (2016). Introduction to Android. [online] Available at: http://developer.android.com/guide/index.html. [Accessed 27 Apr. 2016]. Developer.Apple.com. (2016). Swift. A modern programming language that is safe, fast, and interactive. [online] Available at: https://developer.apple.com/swift/. [Accessed 27 Apr. 2016]. Yarmosh, K. (2015). Android vs iOS: Which platform to build for first? [online] Available at: http://savvyapps.com/blog/android-vs-ios-which-platform-to-build-for-first [Accessed 27 Apr. 2016]. Cho, J. (2015). James Cho’s Sandbox - Downloads. [online] Available at: http://jamescho7.com/book/downloads [Accessed 28 Apr. 2016]. Nicolette, D. (2008). A Case For Short Iterations. [online] Available at: http://www.infoq.com/articles/short-iterations-argument [Accessed 28 Apr. 2016]. Ambler, S. (n.d). User Stories: An Agile Introduction. [online] Available at: http://www.agilemodeling.com/artifacts/userStory.htm [Accessed 28 Apr. 2016]. Johansson, N. and Löfgren A. (2009). Designing for extensibility: An action research study of maximising extensibility by means of design principles. [online] Available at: https://gupea.ub.gu.se/bitstream/2077/20561/1/gupea_2077_20561_1.pdf [Accessed 28 Apr. 2016]

Page � of �44 47

[22]

[23] [24]

[25]

[26]

[27]

[28]

[29]

[30]

[31] [32]

[33]

[34]

[35]

[36]

[37]

[38]

Larman, C. (2005). Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). New Jersey: Prentice Hall, pp. 105. Gamme, E. (1994). Design Patterns. Boston: Addison-Wesley, pp.18-19, 129. Grady, B. (2007). Object-Oriented Analysis and Design with Applications. Boston: Addison-Wesley, pp. 51-52, 69. Folwer, M. (1997). UML Distilled: A Brief Guide to the Standard Object Modelling Language. 3rd ed. Boston: Addison-Wesley, pp.40-49. GameFromScratch.com. (2012). Gamedev math recipes: Collision Detection using an Axis-Aligned Bounding Box. [online] Available: http://www.gamefromscratch.com/post/2012/11/26/GameDev-math-recipes-Collision-detection-using-an-axis-aligned-bounding-box.aspx. [Accessed 28 Apr. 2016]. Developer.android.com. (2016). Rect | Android API. [online] Available at: http://developer.android.com/reference/android/graphics/Rect.html. [Accessed 28 Apr. 2016]. Bertoline, G. and Wiebe E. (2002). Fundamentals of Graphics Communication (3rd ed.). New York: McGraw-Hill. Developer.android.com. (2016). Storage Options. [online] Available at: http://developer.android.com/guide/topics/data/data-storage.html. [Accessed 28 Apr. 2016]. Perry, W. (2006). Effective Methods for Software Testing (3rd ed.). Indianapolis: Wiley: pp.63-103. Burnstein, L. (2003). Practice Software Testing. New York: Springer-Verlag, pp. 501, 623. Whittaker, J. (2009). Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to guide Test Design. Boston: Addison-Wesley, pp. 122-125. Developer.android.com. (2016). Log | Android API. [online] Available at: http://developer.android.com/reference/android/util/Log.html. [Accessed 28 Apr. 2016] Koskela, L. (2013). Effective Unit Testing: A Guide for Java Developers. Connecticut: Manning Publications, pp. 32. Mockito. (2016). Mockito - Mocking Framework for Unit Tests in Java. [online] Available at: http://mockito.org/. [Accessed 28 Apr. 2016]. Microsoft. (2007). Chapter 1 – Fundamentals of Web Application Performance Testing. [online] Available at: https://msdn.microsoft.com/en-us/library/bb924356.aspx. [Accessed 28 Apr. 2016]. Trochim, W. and Donnelly, J. (2006). Research Methods Knowledge Base (2nd ed.). Ohio: Atomic Dog, pp.54-57. Play.Google.com. (2016). Google Play Store. [online] Available at: https://play.google.com/store. [Accessed 28 Apr. 2016].

Page � of �45 47

X. GLOSSARY

Term Meaning

Axis Alligned Bounding Box (AABB)

A closed rectangle volume that completely contains the object or model in question; used to determine collisions and interactions.

Cohesion The degree to which the elements of a class belong together.

Coupling The degree to which different classes rely on each other.

End-to-end slices A piece of functionality which exercises all features of the system in its implementation.

Frame Independent Movement

The technique of ensuring that movement is consistent with time, instead of the frame rate of the system.

Frame-Rate The number of times a full iteration of the game loop is completed per a time unit, usually seconds.

Game Engine The underlying software which provides the full functionality necessary for a video game.

Game Framework The underlying software which provides the basic functionality necessary for a video game.

Game Loop The central code of the game, which handles initialising the system, updating the game and drawing the objects and sprites.

Infinite Acceleration A type of movement in which the object reaches top speed almost instantly, and comes to a complete stop when the appropriate button is released.

Level Editor Software that is used to design levels interactively and graphically.

Parabolic A motion of movement which creates an arc shape, normally due to gravity.

Pointer A term that signifies a finger on a touch screen that is being registered as a touch event.

Power Ups A game object that instantly benefits the player by adding extra abilities or changing the player’s current state.

Spatial Enumeration Techniques which aim to provide an efficient link between data structures used to model objects, and the data structures used to draw a scene.

Sprites A computer graphic which represents an object, and can be moved on-screen or manipulated otherwise.

Tile Map The technique of splitting a screen into a series of equal-sized squares which are populated by the appropriate graphics.

Tiles Term used to describe the object type which populate the tile map.

View Culling The technique of only rendering only the region of a scene that is visible to the user.

TABLE 5. GLOSSARY

Strongly Disagree

Disagree Don’t Know Agree Strongly Agree

1. The aims and controls of the game were clear

2. The game was reactive, and responded quickly to actions performed

3. I was able to fully control the player as desired

4. The game world reacted as expected

Page � of �46 47

XI. APPENDIX

A. Questionnaire

TABLE 6. LIKERT-SCALE QUESTIONS

What do you think could be added to make the gameplay more immersive and fun? If possible, please give examples.

FIGURE 22. Qualitative Section of the Questionnaire. Figure demonstrating the method used to gauge opinions on how to make the game more fun and immersive.

Page � of �47 47