1

University of Manchester

School of Computer Science

Project Report 2016

Universalum the Universal Game

Author: A. Prohhorov

Supervisor: Dr. V. Pavlidis

2

Abstract

Author: Andrei Prohhorov

The aim of the project is to produce a game for Android that can will have modifiable

parameters, such as graphics, difficulty, length etc. These parameters will be selected by players

prior to playing to fit the game to their needs and preferences. Unity will be used as the game

engine for the project.

Supervisor: Vasilis Pavlidis

3

Acknowledgements

I would like to thank my supervisor Vasilis Pavlidis for all the support provided throughout the

making of this project.

I would also like to thank friends who provided moral support while making the project.

4

Contents

Table of Contents 1 Introduction ............................................................................................................................................... 5

1.1 Motivation ........................................................................................................................................... 5

1.2 Aims and Objectives ............................................................................................................................ 5

2 Background ................................................................................................................................................ 8

2.1 Selecting a development platform ...................................................................................................... 8

2.2 Selecting game engine ........................................................................................................................ 9

3 Design ...................................................................................................................................................... 12

3.1 Requirements gathering ................................................................................................................... 12

3.2 Gameplay design ............................................................................................................................... 14

3.2.1 Gameplay ................................................................................................................................... 14

3.2.2 Customization system design .................................................................................................... 15

3.2.3 Mini games ................................................................................................................................. 16

3.2.3.1 Platformer mini game design ......................................................................................... 16

3.2.3.2 Tower defense mini game design ................................................................................... 16

3.2.3.3 Logical mini game design ................................................................................................ 17

3.3 Methodology ..................................................................................................................................... 17

3.4 Planning ............................................................................................................................................. 18

3.5 UI design ............................................................................................................................................ 18

3.6 Designing the plot ............................................................................................................................. 18

4 Implementation ....................................................................................................................................... 20

4.1 Scenes ............................................................................................................................................... 18

4.2 Customization system ....................................................................................................................... 21

4.3 Platformer game ............................................................................................................................... 22

4.3.1 Player movement ....................................................................................................................... 22

4.3.2 Enemy movement ...................................................................................................................... 23

4.3.3 Animation controller .................................................................................................................. 24

4.4 Tower defense game ......................................................................................................................... 25

4.4.1 Turrets ........................................................................................................................................ 25

5

4.4.2 Enemies ...................................................................................................................................... 26

4.4.3 Enemy waves ............................................................................................................................. 26

4.4.4 Player health .............................................................................................................................. 27

4.4.5 Turret-enemy interaction .......................................................................................................... 27

5 Testing ...................................................................................................................................................... 28

5.1 Unit testing ........................................................................................................................................ 28

5.2 Other testing ..................................................................................................................................... 28

6 Results ...................................................................................................................................................... 29

7 Evaluation ................................................................................................................................................ 33

7.1 Aim evaluation .................................................................................................................................. 33

7.2 Feature evaluation ............................................................................................................................ 33

7.3 Future development ......................................................................................................................... 35

7.4 Conclusion ......................................................................................................................................... 35

6

List of figures

2.1 Worldwide Smartphone OS Market Share ....................................................................................... 8

3.1 Preferred graphics................................................................................................................... 11

3.2 Preferred game genres ........................................................................................................... 12

3.3 Screen transition chart ............................................................................................................ 13

3.4 Initial menu design .................................................................................................................. 16

4.1 Method for swiching scenes ................................................................................................... 20

4.2 Example of a scene ................................................................................................................. 21

4.3 Updating the graphics value ................................................................................................... 22

4.4 Linecast demonstration .......................................................................................................... 23

4.5 Character walk animation ....................................................................................................... 24

4.6 Conditions for walking animation ........................................................................................... 24

4.7 Transmissions between animations ....................................................................................... 25

6.1 Main menu .............................................................................................................................. 29

6.2 Customization screen .............................................................................................................. 29

6.3 Story screen ............................................................................................................................ 30

6.4 Platformer with fancy graphics ............................................................................................... 30

6.5 Platformer with minimalistic graphics .................................................................................... 31

6.6 Tower defence game .............................................................................................................. 31

Appendix 1 .................................................................................................................................... 35

Appendix 2 .................................................................................................................................... 35

7

8

Chapter 1

Introduction

The following report will describe the process of developing a mobile game application and all

the experience related to it. The report shows how the project was designed and implemented

together with any research that was done in order to achieve success. The purpose of it is to gain

sufficient experience in developing games and in particular mobile games.

1.1. Motivation

Most of the smartphone owners nowadays play mobile games to some extent. And the Google

Play market is being flooded with tens of thousands of new apps monthly. There are also a big

number of clone games on the market, which mimic one another with small differences.

With all those games to choose from we sometimes wish to download one game and tell it

exactly what you want it to be. That is what I tried to create in this project, a “universal game”.

You tell it what it needs to be, it shapes itself according to your needs. It is quite obvious that it

is impossible to satisfy every single user’s preferences, but nonetheless it is worth a try.

1.2. Aims and objectives

The main aim of the project is to implement a working mobile game with an extensive

modification system, consisting of multiple popular mini-games and supporting different playing

styles. With that I aim to gain a better understanding of game development process, practice

developing a mobile app and to gain experience in working on long-term software development

projects. I also aim to get experience in working on a large-scale project using an existing

engine, as opposed to spending time on writing a game engine from scratch.

Breaking it down into objectives, I can identify three of them:

1. To implement in the most efficient way the customization system that will ask a player

for all select an option for each modifiable parameter and combine them all together in a

personalized game.

9

2. To implement a minimum of three mini-games together with all the possible

customization options that can be added to them.

3. Write a plot for a game and put the mini-games and the customization system together

into a game.

10

Chapter 2

Background

Prior to the design and development processes there was a need to perform some research on

developing mobile apps and related areas. Some crucial fundamental decisions had to be taken as

well. This chapter provides a short summary of that.

2.1. Selecting a development platform

As I have decided to make a mobile app and there exist multiple widely used mobile platforms, a

decision on what platform to choose had to be done.

Figure 2.1: Worldwide Smartphone OS Market Share

My preferred phone OS is Android, as I have used it for multiple years now and am quite

familiar with it. Android is also the most widely spread phone platform in the world. As shown

11

in figure 2.1, Its market share exceeded the 80% mark in 2015, whereas it’s next competitor, IOS

has less than 20% of market share.

Android is also a very convenient OS in terms of development as there are multiple popular

engines that support it and the documentation is easily accessible. Testing would also be more

easy for me as most of the people that surround me use Android phones, so there is always a

wide range of devices to perform tests on.

Considering all these factors, I have selected Android as the platform for my game.

2.2. Selecting a game engine

Because Universalum is supposed to be a large game consisting of multiple mini game that

differ in the implementation and a big number of different customizations it was decided to use

an existing game engine, as opposed to writing one. The aim of the project

When it comes to choosing a game engine, there are multiple choices available today. A set of

criteria needed to be created to select the most suitable one.

In order of decreasing importance:

1. Price – I needed the engine to be free, because I couldn’t afford paying for it.

2. Documentation availability

3. Active community

Marmalade – a good and widely used game engine with cross platform development and a 2D

development kit available. Had a free version with apps showing up on the screen and limited

extensions.

Construct 2, LibGDX – game engines available for free, had a wide selection of tools offered for

2D development with decent amount of documentation and forums available for questions.

Unity – perhaps, one of the most popular game engines in the world with a big amount of

features, very big and active community and 2D development tools available. Used to be

proprietary before, but became free some time ago.

These are the best options that were considered, but in the end, Unity engine was selected for the

project due to the very good 2D development support and big amount of available

documentation.

12

Chapter 3

Design

This chapter describes the process of designing each particular feature of the game. Starting from

gathering requirements and preferences from different people to decide on which features to

implement and ending with designing the features of mini games and creating a plot for the

game.

3.1. Requirements gathering

Before starting the design I decided to make a questionnaire to see what different people's

perception of a perfect mobile game is. This was needed to identify the possible modification

parameters for the game and then split each parameter into a list of different options.

The questionnaire was completed in total by 20 people and provided a satisfactory result. The

results made it possible to see that it is in principle very hard to satisfy the needs of all people at

the same time. This is due to the fact that opinions and preferences split into a wide range of

answers for every question.

For example, figure 1.1 shows the percentage of people preferring fancy or simplistic graphics

in games. In this case we don't have to take a decision on what to implement and what not to

implement as there are only two options. If we add these two types of graphics we will already

satisfy all the players.

13

Figure 3.1: Preferred graphics

The situation becomes more complicated in case of a question with a larger number of choices.

A good example of that is a question about the preferred game genre. The answers to these

questions are shown on the figure 1.2. When it comes to genres, most of the people actually don't

have one favorite. And because the number of games I can implement is limited by the time

boundaries, I selected three most popular choices. These happened to be strategy (8 votes),

logical (8 votes) and action (6 votes). Other popular votes, such as Educational (5 votes) and

Puzzle (5 votes) were considered as features that might get added later on.

14

Figure 3.2: Preferred game genres

3.2. Game design

3.2.1. Gameplay

The gameplay consists of playing multiple mini-games that act as tasks or obstacles in a big

story. In the beginning the player selects his desired preferences (game length, graphics, setting),

after that he is being presented with an introduction to the story, after which the player has to

complete a mini-game. After successful completion he is being shown the continuation of the

story. After that he needs to complete another mini-game and so on until the end of the game.

15

Figure 3.3: Screen transition chart

3.2.2. Customization system design

Before the actual gameplay starts the user must complete the customization process. It begins

immediately after the user presses the start button. First he is being asked to select a setting,

which is basically the world or the environment that the game events will be happening in. There

are four option provided:

Sci-Fi - futuristic world after humanity colonized space

Fantasy - an imaginary universe similar to the universe of Hobbit

Noir - a world in a style of old detective fiction

Historic - medieval world

After the selection is done, the user confirms the choice and proceeds to the next screen to select

the preferred graphics. The choices are:

Minimalistic - Simple 2-color graphics, objects have minimum details and no animation

Fancy - multicolor graphics with complex animation, high level of details

16-bit - retro graphics style, similar to Nintendo or Sega

Textual - absence of graphics, events happening are described by text

The next screen similarly has 4 choices of story length. The length of the story changes

depending on how many time will the game cycle through a series of 3 mini games. The options

on this screen are:

16

Shorter - Each mini game is played once

Full - Each mini game is played twice

Long - Each mini game is played 3 times

No storyline - Mini games come one after another with no story screens in between until

the player decides to quit playing

After the third screen the story starts and after that the player appears in a world that he has

chosen, with his preferred graphics and story length.

The customization process is organized in steps to achieve maximum straightforwardness for the

user. The initial design of a customization screen is shown below in figure 3.4

3.2.3. Mini games

3.2.3.1. Platformer mini game design

A typical platformer game is a game which involves guiding an avatar to jump between

suspended platforms and obstacles to advance the game. The features may change from game to

game, but in our case the mini game has elements of stealth game (a game where a player uses

different techniques to avoid antagonists), because the player can't destroy the enemies he

encounters, so he must avoid them.

The objective of the game is to safely reach the end of the level which is indicated by a door,

portal or other object, depending on the plot. The platforms that the player moves on are

"hanging" in the air, so if he falls off any of them, he will immediately die. Similarly, if the

player touches an enemy once he starts flashing. After touching an enemy for the second time he

dies and is put at the beginning of the level.

3.2.3.2. Tower defense mini game design

Tower defense is a type of strategy video games where the goal is to defend a player's territories

by obstructing enemy attackers by placing defensive structures on or alongside their path.

Universalum utilizes a classical tower defense game, with waves of enemies coming towards

player's base.

Player has to place turrets along the path that enemies follow.The towers can also be upgraded

with the money received from killing enemies. As a tower progresses, it gets longer shooting

range, faster and stronger bullets. Player has health points as well and whenever an enemy

reaches player's base these points are deducted. When there are no health points left, the player

dies and has to redo the level.

17

3.2.3.3. Logical mini game design

Sokoban is a logical game, in which the player pushes boxes or crates around in a warehouse,

trying to get them to storage locations. The mini game designed for Universalum utilizes the idea

of the classical Sokoban game, with the difference in the environment. Instead of the warehouse

the action might be happening in open space and there might be satellites instead of boxes.

In this game all the marked cells must be occupied by boxes, if they are - the level is completed.

The boxes can be pushed around by the avatar controlled by the player. An obstacle in

successfully completing the level is the fact that the boxes can get stuck. For example if the

player eventually pushes a box into a corner he will not be able to push it out of it. In this case

the level must be restarted, which can be done by pushing the provided restart button.

3.3. Methodology

To organize the work on design and implementation, an agile practice of whiteboard was used. I

have. A whiteboard was created with 5 columns, each representing a current state of a task.

The columns are as follows:

1. Backlog – general ideas for the projects that might not be implemented. If after

evaluation an idea is being approved, it moves to the next column and becomes a

standing task.

2. To do – the column, containing a list of tasks (usually a task is a feature) that must be

implemented in future. If a task is chosen to be implemented next, it moves to the next

column.

3. In development – tasks that are currently being worked on. When a task is completed it

goes to the next column.

4. Testing – if a feature is tested and no bugs are found it moves to the next column. If a bug

is found it moves back to the development column.

5. Done – represents a list of all finished features ready for deployment.

A picture of the taskboard is provided in Appendix A.

3.4 Planning

18

A Gantt chart provided in appendix B was produced prior to the start of project work. The

purpose of this chart is to provide a basic plan for tackling different features of the application. I

was expecting to follow it quite closely, however very soon I noticed that it is very hard to

follow the plan. This is mostly due to the lack of previous experience in implementing large

projects like this. The time constraints for most of the tasks were too small, so in the end I used

the chart to see the order in which different parts of the system were to be implemented, without

following the time constraints.

3.5 UI design

Designing a good and easy to use user interface is very important for user satisfaction. It is very

important to be able to navigate through the game and menu screens easily and intuitively. A

game can be very interesting to play, but if the controls or navigation in the menu screen is

frustrating it can affect the impression from the game in a negative way.

For the sake of simplicity it was decided to put minimum buttons on the screen. The size of the

buttons also was planned to be variable, so that the most likely inputs stand out from the rest.

The main menu is the very first element of the game that players will encounter, so it was

important to make it aesthetically pleasing to give a person playing a good first impression of the

game. Figure 3.5 demonstrates the initial design of the main menu.

Figure 3.4: Initial menu design

Another important rule is to keep the UI elements consistent. To achieve that, the elements don’t

change their position on different screens. For example, the customization screens have the same

layout in terms of button placement and actions needed to be performed to proceed to the next

screen.

19

The consistency can also be noticed in the design of the UI elements, they all have the same

appearance throughout the game.

3.6 Designing the plot

For many games, the plot is one of the most important parameters. It can keep player motivated

to play, immerse a person into the world that the action takes place in and make the gameplay

more pleasant in general.

However, writing a good plot for a game is not an easy task, especially for a person with no

experience in writing. Because of that I stuck with a few popular time-tested ideas. These put the

user in a role of a person with all the good qualities, a “hero”, that has to overcome all the

challenges and obstacles that are presented to him to save the people around him. This kind of

plot is used very widely in computer games and movie industry. There were four different

scenarios designed, one for each setting. These include:

Sci-fi: The galaxy is in a state of war. Humanity has expanded its habitat far beyond our

Solar system and has eventually encountered different civilizations scattered throughout

the galaxy. Then a war struck, humans were fighting for the right to exist for centuries.

And in a critical moment a hero appears to change everything and save humanity.

Fantasy – a concept similar with Sci-fi. An evil and powerful wizard takes over the land

of our hero. Everybody lost the hope to ever be free again, the only person who is brave

enough to take any action is the player.

Noir – a detective is trying to catch a leader of a famous gang that has been terrorizing

the streets of New York for years. The enemies are strong and deceptive, but the hero is

Historic – the player takes the role of Julius Caesar, the legendary Roman statesman to

lead the Roman army against the galls.

20

Chapter 4

Implementation

This chapter describes the process of implementing of all the in-game features and explains all

the technical decisions made in this process. It also presents all the tools the tools used to create

the game.

As already mentioned before, the engine chosen for creating this game was Unity, because it

featured the widest range of features and tools, a very active community and a big amount of

documentation. The programming language used in Unity is C#.

Certain technical implementation ideas were taken from online tutorial websites provided in the

reference section, but these were added and implemented with understanding of underlying

mechanics.

4.1 Scenes

It was decided to organize different menu screens and mini game in different scenes. A scene in

unity contains a set of game objects. It can be considered a basic building block for the game.

Transitioning between scenes is performed by a simple method utilizing the Application class

that Unity provides to swap to a specified scene. The method is shown in figure 4.1.

Figure 4.1: Method for switching scenes

A scene has multiple elements to it. Figure 4.2 demonstrates a typical scene opened in the Unity

editor. Every object has 3 coordinates in the world space – x, y, z. As the scene is 2-dimensional,

usingUnityEngine;

usingSystem.Collections;

publicclassSwapToNextScene:MonoBehaviour

{

publicvoidswapToNextScene(inti)

{

Application.LoadLevel(i);

}

}

21

the z coordinate is used to position the objects in front or behind each other. The x and y

coordinates are used to actually position it on the screen.

Figure 4.2: Example of a scene

The main objects that are present in the scene are:

Main camera – device that captures and displays the world to the player. Is represented

by a white rectangle and decides what part of the world is visible to the viewer.

Canvas – the area that holds all the UI elements (buttons, labels, etc.)

Background – The background image.

UI elements – buttons, labels panels, sliders, etc.

Game objects – the actual objects that the game revolves around. Usually are sprites.

4.2 Customization system

The customization system uses multiple variables and conditions to combine all the player-

chosen settings. The variables are initialized in the class Main and can have values from 0 to 3.

Each of the numbers corresponds to a setting. For example, for the graphics variable 0 means

fancy graphics, 1 means minimalistic graphics, 2 means 16-bit graphics and so on. Figure 4.2

demonstrates the method for changing the graphics.

22

Figure 4.3: Updating the graphics value

The proceed buttons in the first two scenes simply load the next scene. However the same button

in the last screen calls a different script, which is a modification of the SwapToNextScene script.

This script contains if-else statements that load different scenes depending on the values that the

variables described previously have.

4.3 Platformer game

The platformer game utilizes three scripts that contain all the methods needed for a particular

part of the system to work. The movement of the player and the physics related to that is

managed by the PlayerController script (testMove), enemies are controlled by the

EnemyController script. Animations are handled by the AnimationController script.

4.3.1 Player movement

A player is represented on the screen by an empty object and a character sprite attached to it. The

character object is given a Rigidbody2D component, which gives places it under the control of

the physics engine.

As described in the design chapter, the character can walk and jump around on the platforms,

which he should not fall of. Here is a list of properties that the character has.

To ensure that the character always stays on top of the platforms, he is assigned a collider

element. There is a constant gravity force affecting the character. Because of that the platforms

are given colliders as well, so upon touching a platform the character will not fall through.

usingUnityEngine;

usingSystem.Collections;

publicclassMainUpdate:MonoBehaviour{

void start(){}

//

publicvoidmainUpdate(inti)

{

//Updating the value in the Main class

Main.graphics=i;

}

}

23

For any type of movement, be it going left, right or jumping, vectors are used. There are two

buttons on the left of the screen – left and right button. Whenever one of them is pressed, the

StartMoving method is called. In this method, the input variable (stands for horizontal input) is

assigned a value of 1 or -1if one of the buttons was pressed, and of 0 if a button was released.

Each frame the FixedUpdate method is called, which calls the Move method. The Move method

gets the velocity of the character object, and adds the speed value multiplied by the 1 or 0,

depending on the state of the buttons.

Jumping is performed in the Jump method, which checks if the character is touching the tag

ground element that the character is assigned. If it is touching the ground the character’s up

vector is summed with the jump velocity and the character moves up.

4.3.2 Enemy movement

The enemy movement is organized in a similar way to the character, but uses a different method

to see if it is grounded. The task was to set make the enemies move in one direction until they

reach the end, turn around and go into the other end and so on.

For that reason a method called linecast was used. Linecast is an imaginary line between two

points in world space. Any object making contact with the beam can be detected and reported.

The enemy has a constant speed and is moving horizontally in the same way that the player does

while casting a linecast, starting from the front of it and going vertically down towards the

ground. When a platform edge is reached, the linecast detects no ground and the enemy is rotated

180° around it’s y-axis and starts moving in the opposite direction. Figure 4.4 shows an enemy

with the linecast detecting the ground.

Figure 4.4: Linecast demonstration

24

4.3.3 Animation controller

Unity provides an animator tool for creating custom animations,setting up the transitions

between them, and specifying the conditions under which the animations are running.

Figure 4.5 demonstrates the walking animation of the character, figure 4.6 demonstrates the

condition that needs to be satisfied to make a transition from idle to walking animation. Figure

4.7 shows the map of all possible transitions.

Figure 4.5: Character walk animation

Figure 4.6: Conditions for walking animation

25

Figure 4.7: Transitions between animations

The AnimationController class contains methods for rotating character during the movement as

well as triggering the blinking animation when player collides with an enemy.

4.4 Tower defense game

Tower defense is a simple game in terms of the playing process, but a more complex game in

terms of implementation. I will describe the key points about the game’s composition. The

concept of prefabs is mentioned below. Prefabs is in an essence a template for adding new

objects in a scene. If a prefab is modified, all of it’s instances are modified too.

4.4.1 Turrets

The OnMouseUp method provided by Unity is used to check if player has tapped one of the

platforms. If so, a new instance of the tower prefab is created at the location of the corresponding

platform.

26

If a turret is tapped on:

1. Check if there are levels to upgrade to.

2. Check if player has enough gold

3. If so – switch to the next tower sprite and upgrade tower’s features

4.4.2 Enemies

The path of enemies consists of multiple waypoints that are set throughout it. Enemy prefabs are

spawned on the very first waypoint, after which lerp is used to move them along the path.

Lerp is a Unity-provided function which is most commonly used to find a point some fraction of

the way along a line between two endpoints. We use it to interpolate the current position of the

enemy between the start and the end of the current segment.

It is also important to rotate the enemies in such a way that they always face forward the

direction that they are moving in. For that we subtract the current waypoint’s position from the

next waypoint’s position. Then we determine the angle that the enemy is pointing towards using

the Atan2 function that unity provides. Finally, we rotate the sprite along the z-axis by the

required angle.

4.4.3 Enemy waves

Enemies in a tower defense game must be grouped into waves. Here are the steps in which the

waves are organized:

1. Check the current wave’s index to check if it is not the last one.

2. If so, calculate how long ago was the last enemy spawned. There are two intervals – in-

wave (short) and between waves (long).

3. Spawn a new enemy by instantiating a copy of the enemy prefab and increase the count

of enemies spawned.

4. Check if there are enemies on the screen, spawn a new wave if there are none and the last

enemy was spawned for the previous wave. Give player 10% of all gold.

5. If the last wave was beaten – run the victory animation.

27

4.4.4 Player health

Player has health, which is shown on the screen alongside the enemy wave number and player’s

gold amount. If it reaches 0, the game is over and the game over animation is played. Each time

the health decreases, which happens when one of the enemies reaches player’s base, one of the

human sprites on the player’s base is destroyed to visualize the loss.

4.4.5 Turret-enemy interaction

The turret prefab has a circle collider assigned to it. Its radius decides the shooting distance

Delegates are special kind of classes that Unity provides. These are used when it is needed for a

game object to actively notify other game objects of changes. This is used to notify turrets of

killed enemies.

When an enemy touches a turret’s collider, it is added to the enemies in range list. If an enemy is

destroyed it is removed from that list. This is achieved with two methods, OntriggerEnter and

OnTriggerExit.

If there are multiple enemies in the range of a tower, it will shoot the one closest to the player’s

base. This is achieved by calculating the length of road not yet travelled by the enemy.

For turrets shooting the enemies, Lerp is used again. Bullets travel in a straight line between

turrets and enemies. A bullet has a set of parameters, which include speed and damage. The rate

of fire is also modifiable.

So the overall shooting process can be described with these steps:

1. Select the target. Iterate through enemies in range to find one closest to player’s base.

2. Call the Shoot method, determines the start and the end position of a bullet and

instantiates a new bullet.

3. Calculate the rotation angle between the turret and it’s target and set the turret’s rotation

to this angle so that it always faces the enemy.

28

Chapter 5

Testing

This chapter describes the testing process – what kind of tests were performed, what techniques

were used, what results were achieved.

5.1 Unit testing

Unit testing was conducted on all of the game’s features. Whenever a new feature was

implemented in the game it was tested to detect any possible bugs before developing any other

features.

No specific frameworks were used, the testing was performed manually. That is mostly due to

the specificity of the project – the game has to be played on a mobile device and interacted with

through the touchscreen in order to test most of the functions.

The tests were designed and written down in the logbook, the results of each tests and any

actions taken related to testing were also described in the logbook. Figure 5.1 shows an example

of testing logs from the logbook.

Figure 5.1 here

5.2 Other

Some evaluation was done as well in an informal fashion. For that the prototypes of mini games

were given to different people to get feedback on playability, design and general impression.

This helped with refining some in-game features. It is important for a good evaluation to have

people who are not biased by relationship with the developer or any other factors. And though

not all the people could satisfy these conditions, I believe that most of the evaluation received

was reasonable and critical.

29

Chapter 6

Results

This is a demonstration chapter for the project, containing screenshots of the screenshots of some

of the game aspects, such as menu screens and mini games.

Figure 6.1: Main menu

Figure 6.2: Customization screen

30

Figure 6.3: Story screen

Figure 6.4: Platformer with fancy graphics

31

Figure 6.5: Platformer with minimalistic graphics

Figure 6.6: Tower defense game

32

Chapter 7

Evaluation

This chapter shows the evaluation of all the features that have been implemented. The evaluation

is made on the features that were planned to be implemented and the aims that were set.

7.1 Aim evaluation

Following the description of aims in the first chapter, following conclusion can be made.

1. Implement a working mobile game with an extensive modification system, consisting of

multiple popular mini-games and supporting different playing styles.

This aim is partially accomplished: a working mobile game is produced, but there are features

missing from it, that limit the gameplay substantially.

2. Gain a better understanding of game development process, practice developing mobile

apps.

This aim is reached, because considering that before I had almost no experience in game

development, I have learned many new concepts. Some of these include physics engine, UI

design, game design, sprites etc.

3. Gain experience working on a large-scale project.

This aim was reached as well, because the development period lasted for almost half a year, I

had to do planning, write tests, make changes to the project and experience other things related

with a long-term large scale project.

7.2 Feature evaluation

1. To implement in the most efficient way the customization system.

A method was developed to implement the customization system, however not all the

customization features were finished (not all graphics sets, settings, game lengths).

33

2. Implement a minimum of three mini-games together with all the possible customization

options that can be added to them.

Out of the three mini-games the two most complicated and time-demanding mini-games were

implemented. However the graphics sets and different settings were not fully implemented due to

the lack of time.

3. Write a plot for a game and put the mini-games and the customization system together

into a game.

4. The plot was designed for the game, however different scenarios for different settings

were not added into the game.

7.3 Future development

Because I still consider the project idea to be interesting, I will continue the development of

Universalism. It requires a substantial amount of implementation and refinement work to be done

before deploying it to the market.

7.4 Conclusion

In conclusion, The project was semi-successful. This is due to the fact that by far not all the

planned features were implemented and added to the game. Mostly, because of the mistakes

made in time-management and work organization.

But even though the desired result was not fully achieved, a good amount of experience was

acquired.

34

References

1. IDC: Smartphone OS Market Share. (n.d.). Retrieved April 26, 2016, from

http://www.idc.com/prodserv/smartphone-os-market-share.jsp

2. Shneiderman's Eight Golden Rules of Interface Design. (n.d.). Retrieved April 26, 2016,

from

http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRul

es.html

3. Unity Manual. (n.d.). Retrieved April 26, 2016, from

http://docs.unity3d.com/Manual/index.html

4. What's the most challenging part of making a successful mobile game? (n.d.). Retrieved

April 26, 2016, from https://www.quora.com/Whats-the-most-challenging-part-of-

making-a-successful-mobile-game

5. How to Create a Tower Defense Game in Unity – Part 1. (n.d.). Retrieved May 03, 2016,

from http://www.raywenderlich.com/107525/create-tower-defense-game-unity-part-1

6. Unit Testing. (n.d.). Retrieved April 26, 2016, from https://msdn.microsoft.com/en-

us/library/aa292197(v=vs.71).aspx

7. Devin Curry - Technical Artist. (n.d.). Retrieved May 03, 2016, from

http://www.devination.com/2015/01/unity-46-touch-input-platformer-tutorial.html

8. Building a Useful Task Board - Agile For All. (2011). Retrieved April 26, 2016, from

http://agileforall.com/building-a-useful-task-board/

35

Appendices

Appendix A

Appendix B

36