1. IMPERIAL COLLEGE LONDON
Software Engineering Practice
Group Project
cZeus Fantasy and Adventure World Game
(The Mathematical Games Company Ltd (TMGCL))
Group 10
Liqun Wu, Phumin Phuangjaisri
Ziyu Wang, Yifan Zhai, Diyi Ma, Xidi Chen
Supervisor: Anandha Gopalan
January 10, 2016

2. Contents
1 Executive summary 2
2 Introduction 3
2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Design and Implementation 6
3.1 Interface design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 Loading interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2 Map interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 Tutorial interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4 Game board interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Overall game architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Game scene development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 Game scene logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 Common game scene component . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Game map system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 World map and chapter map . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.2 Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 External puzzle data parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1 Puzzle data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.2 CSV parser integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 In-game implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.1 Gameboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.2 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.3 Timer and score calculation . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.7 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Test and Evaluation 23
4.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Function testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 System testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.3 generate testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Product evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2 Overall evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Conclusion and Future Extensions 25
5.1 Team achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Future Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Project Management 26
6.1 Stakeholders and Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Agile Methodologies and Practices . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.1 Methodology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2.2 Agile Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3 Team Structure and Task Allocation . . . . . . . . . . . . . . . . . . . . . 28
6.3 Project Planning and Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.1 Sprint Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.2 Estimation and Progress Tracking . . . . . . . . . . . . . . . . . . . . . . 29
6.4 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4.1 Game development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.4.2 Project Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4.3 Communication tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1

3. 1 Executive summary
Nowadays, due to the increasing use of calculators and computer, the numeracy skills of adults
throughout Europe and the western world is getting worse. According to UKs National Nu-
meracy charity, this already starts to have a significant influence on economy and the workforce
of the country. Since solving pure mathematical formulas is usually boring, an interesting and
practical way needs to be created to make people willing to practice more.
cZeus Fantasy Adventure World is a grid-based puzzle game that provides players with a way to
practice numeracy skills, memory and attention skills. The game is based on four simple rules
which do not need any prior knowledge for players of any age to get started. There are different
levels in the game. At its easiest level, cZeus is an alternative way of practising times table, but
it quickly gets harder at higher levels where deductive reasoning and use of elimination process
are required. Playing each level of game only cost a few minutes which encourages players to
engage in their free time. The Greek mythology theme of user interface design can bring some
mystical and entertaining aspects to the game. The deployment of storylines between characters
can also lead to an increase in the curiosity for future levels.
cZeus can help players gain confidence in using numbers while having fun with the stories and
characters in the game. Besides, it has potential to take the players further along the path to a
deeper appreciation and enjoyment of mathematics.
The project is proposed by The Mathematical Games Company Limited (TMGCL). The current
game is available for IOS platforms which contains the major features and several working game
levels. The game built in this project will be the pilot version of the cZeus Fantasy Adventure
World Game.
2

4. 2 Introduction
2.1 Background
Numeracy is, increasingly, a major challenge throughout Europe and the western world. Accord-
ing to economists from the Audit Office, commissioned by National Numeracy and led by Pro
Bono Economics (PBE), there are roughly 4 in 5 adults in UK having a low level of numeracy
with significant impacts on the economy. They estimate the cost of outcomes associated with
low levels of adult numeracy at around 20.2 billion per year, or about 1.3 per cent of the UK’s
GDP. The estimation ignores costs to the health service and criminal justice system which are
difficult to be quantified, and may therefore underestimate the real cost of poor numeracy.[1]
Evidence shows us that a positive attitude to maths is key to being numerate - having the
confidence and competence to use numbers and think mathematically in everyday life. However,
30% people wrongly assume that maths is a skill you are born with, rather than a skill that can
be learnt. At school, children are often not prepared for using maths in everyday life according
to the report from National Numercacy.[2]
Among those aged more than 24 numeracy skills decline with age but too few people take
steps to improve their numeracy.[2] Older people with poor numeracy skills could be at greater
risk of financial exploitation according to the study by researchers from Plymouth University
and Scripps College. With millions of older adults experiencing financial exploitation, it is vital
to gain a better understanding of what protects them from it, explained the authors of the study
Stacey Wood, Liu Pi-Ju and Dr Yaniv Hanoch. Our data reveal that numeracy plays a key role,
with high numeracy found to be a significant predictor of decreased risk after controlling for
other demographic variables.[3]
2.2 Motivation
From the previous analysis we find improving numeracy of people of all ages is necessary and
quite urgent as numeracy skills have got worse, not better according to the result of GCSE
test.[2] Negative attitudes are at the root of our numeracy crisis, rather than a lack of innate
talent. Maths is often thought difficult and boring. Thus, in order to improve numeracy, we need
not only to focus on effective methodology but also how to motivate people’s interest towards
numeracy.
The Mathematical Games Company Limited (TMGCL), the proposer of our project, has devel-
oped an interesting mobile puzzle game called cZeus that allows practising maths, memory and
attention skills, without using the conventional complex mathematical notations and approaches.
This game aims to improve numeracy and confidence in using numbers, among teenagers and
adults, from school to old age. TMGCL believes gamification is the way forward for changing
public attitude towards unpopular subjects such as numeracy.
cZeus is a grid-based puzzle game with four simple rules that indirectly integrates elements
of algebra and factorisation, without the need of prior knowledge of these subjects.
For children, cZeus at its easiest level is an alternative way of practising times table. Chil-
dren can gain better basic numeracy skills by playing this mobile game. They might get a sense
of achievement after passing each level of this game. Gamification makes practise numeracy
more interesting.
For adults, the game quickly gets harder at higher levels where deductive reasoning and use
of elimination process are required which may help them improve logical thinking ability and
complicated numeracy. Especially for old people, it may help them decrease the possibility of
financial exploitation by improving numeracy skills. Keeping thinking logically and improving
short-time memory may also help them avoid Senile dementia.
Playing a game like this is a useful way for people of all ages to improve their numeracy in
a less boring way. It is effective and not time-consuming as a single level of game only costs
3

5. about one minute.
In project cZeus Fantasy Adventure World, the team will develop an advanced game based
on cZeus with better user interface.
2.3 Objectives
The aim of this project is to build a pilot version of cZeus Fantasy Adventure World which is an
IOS game with the similar idea with cZeus but based on a different storyline. This new version
mainly focuses on designing a better user interface for multiple players. After discussion with
our supervisor Anandha Gopalan and the TMGCLs founder Shohreh Blank, the team made a
decision on features to be implemented in this game:
· User-friendly interface with clear workflow of the software. Improve UI usability including
redesign toolbar and game board of each game.
· Design a new storyline for the game. It should include new characters and new scenes.
· Design and implement a clear and simple tutorial and merge it into first few levels.
· A suitable game hints system giving users limited numbers of clues in each level.
· The flexibility of time limitation with different game levels.
· Design easier entry level and various difficulties among different levels.
· A magical world map and chapter map with appropriate control for level access.
· A music and sound system including background music and sound effects in the game.
· Add animations to some scenes and the character.
· Keep records of game performance for each level.
· Implement an appropriate puzzle data structure and a CSV parser to handle data files.
· Design the ways of game input and output for each operation.
· Optimize currency system including redesign the ad representation.
· APIs to social medias such as Facebook and Twitter for sharing the records of game.
2.4 Contributions
· Built an IOS interface for the game software. Allowing players to make every operation
smoothly.
· Added a new storyline, smart characters and basic scenes for the game.
· Added tutorial allowing users to understand the rules of solving puzzles in an interactive
way of dialogs between the character and the tutorial bird.
· Allowed players to change the settings of background music and sound effects.
· Users can check their game records for each game level they have played.
· Added a world map and chapter maps to improve user interface. The size of gameboard
varies from different chapters.
4

6. · Implemented a bug-free and playable in-game system which handles CSV data files appro-
priately.
· Randomly choosing puzzles among all puzzle data for the related difficulty of each level.
· Handled the right or wrong input of players in related ways.
· Built the working timer and calculator for score, errors and hint used.
5

7. 3 Design and Implementation
In this chapter, we will cover the design and implementation of the graphical user interface and
the modelling of each in-game scene. Each component used in the game will also be explained.
We will also discuss the technical difficulties met during the development.
3.1 Interface design
3.1.1 Loading interface
In the landing page show as Figure 3.1, we implement it with some necessary elements, game
logo, hero and three buttons. The game logo and play button are in the loop of scaling between
the original size and 1.2 times of the original size. The hero is responsive to touch action from
the player. The design described above is based on our target user. This game is designed and
developed for people of all ages and our main target users are children and students. Therefore,
we want the UI elements to be dynamic and appealing to the player but also having enough
usability.
Figure 3.1: Loading interface
3.1.2 Map interface
As the project required, the level map should be designed and implemented in order to increase
the playability of this game. We decide to split the game into 10 chapters and each chapter has
multiple levels. Each chapter is represented by a greek state patron god, for example the first
chapter being available to the player in world map is Olimpia, shown as Figure 3.2. The locked
chapter is shown as a folded scroll.
Each chapter has its own story, shown as Figure 3.2. The player will start the game from
level 1 initially. Each open level is represented by a stick and each locked level is represented
by a lock. The level which has hero beside it is the latest level of the chapter. The player has
to pass the current level to unlock the next level. When the player finishes all the levels on the
current chapter, then the next chapter will be automatically unlocked. The player can go back
to world map by pressing the button on the bottom left of the screen. We also animate the hero
in order to make the interface more interactive.
6

8. Figure 3.2: World map & chapter map scene
3.1.3 Tutorial interface
For tutorial interface, we get rid of the original way which showing the tutorial by giving a link
of tutorial scene on the landing interface. In case of some player will ignore the separate tutorial,
we mix the tutorial with game level together as the first five levels, as show in the Figure 3.3.
In this way, the player will have a smoother experience during the first time playing. Besides,
in order to make these levels look like tutorial, we use the dialog boxes mode to introduce the
rules and guidance to the player under the game board, shown as Figure 3.3.
Figure 3.3: Story line & tutorial interface
7

9. 3.1.4 Game board interface
The game board interface consist of three parts which are top toolbar, game board and button
number bar and we use the same theme asset to all three parts. For making the interface shown
not to be completed, so compare with the original prototype, we change the way of showing
choice number from dynamic into static and shown on the bottom. For the toolbar, we use a
more concise way to design it which has the error counting, hint counting and timer functions.
Compare the Figure 3.4, when the mystery number board been selected, the number bar shows
the ? instead of the 0, because the rule that for mystery number board, only 1 to 9 can be filled
in, but it can be the double-digit in pair clue board, so we have 0 in the number bar. And the
hint will be suitable just for mystery number board. We design 7 different game boards for all
levels which are one pair clue, two pair clues, three pair clues, 2x2, 2x3, 3x3 shape and 3x3 game
board mode, the Figure 3.4 shows the 3x3 mode.
Figure 3.4: Mystery number & 3x3 pair clue board pressed
3.2 Overall game architecture
The game consists of two map systems and a number of reusable gameboard prefabs. The puzzle
data is stored externally in multiple CSV files and each game presents a predesigned puzzle. As
Figure 3.5, we divided the game development into two parts, the blue components related to the
UI development, and the red components related to the data reading part. The green component
is the bridge of linking the two parts together to make the game completed.
Figure 3.5: Overall game architecture
8

10. 3.3 Game scene development
We choose Unity3d engine as it is a cross-platform development tool. We started with designing
the basic game flow and then implemented the basic UI for each game scene. In this section, we
will introduce the game scene logic and how we implemented the components that frequently
used in each game scene.
3.3.1 Game scene logic
In order to build the game structure, firstly based on game logic, we design the interface we
need to have of this game, and then we create related empty scenes as the game interfaces in the
cZeus project then link together as the initial game structure. The structure shown as Figure
3.6.
Figure 3.6: Overall game interface architecture
3.3.2 Common game scene component
We created 3 components which are the common components of each scene with Bg, Canvas
and UI operator respectively. Besides, the new scene will be created together with a component
named Main camera. The Bg component aim for setting the background of the scene by chang-
ing the sprite attribute of a sprite render, show as Figure 3.7.
Figure 3.7: Background setting window
The Canvas is a game object which contains all the functional button and logo images of the
scene. It contains a canvas render which has image (script) and button (script) attributes,
the image (script) is for changing the button background and logo images by source image
9

11. attribute. In order to make the button work, we can add the onClick() event of the button
(script) attributes, show as Figure 3.8.
Figure 3.8: Button image and script window
The UI operator contains all the script files needed. Once we create the scripts, we use the
mono java developer tool of the unity to edit the script. And then we drag the script into the
onClick() event, and choose the function of the each button. Each time we click the button, it
will respond to the corresponding function.
The main camera is a basically necessary gameobject of each scene, as we can see from the
Figure 3.9, the main camera is behind the character, we can change the distance between the
camera and the interface. There is also a small window on the bottom right, it is convenient for
developer to preview the effect of the scene. In the top right, there has a 3D object which con-
tains axis x, y and z. The three axis give the developer different point of view during the design
stage. And also we need to use the main camera to allocated the location of the components.
10

12. Figure 3.9: Camera view
3.4 Game map system
3.4.1 World map and chapter map
Unlike the original cZeus puzzle game, the very unique features of cZeus fantasy world are world
map and chapter map. A unity asset named Smart 2D levels map[4] was found being able to
implement level map features in a relatively short time. The asset was purchased by the pro-
poser in the very early stage. However, we notice that it is not capable for this project when we
finished the first prototype. The level map asset is not designed to be extendable and does not
support pinch zoom and multiple maps. In order to have more control and flexibility, we decide
to build our own map system.
World map and chapter map represent two very similar concepts. World map was designed
and implemented first then chapter map was extended from it. For the world map, it has a
world map manager managing the interaction in the world map, shown as Figure 3.10. It has a
gameobject array that stores the ten chapter nodes in the world map. The world map manager
also has a reference to the main camera as it makes the main camera move to the position of
pressed chapter node. Similarly, each chapter map has chapter map manager, shown as Figure
3.11. The difference of design between world map manager and chapter map manager is chap-
ter map manager not only has an array storing all the levels but having the references to all
the gameobjects in the conversation window. Having the reference to these gameobject is very
necessary because they are constantly accessed during game play.
11

13. Figure 3.10: World map manager
Figure 3.11: Chapter map manager
For the chapter node in world map, is customised using the world map node prefab, shown as
Figure 3.12. It has box collider which allows the node to detect the action from the player. It
also has a chapter script component attached to it. The component has three attributes, chapter
Id, chapter scene Id and isLocked. The chapter Id is an integer that indicating the order of the
chapter in the world map. The chapter scene id is an integer that indicating the corresponding
chapter scene in the build setting. IsLocked is an boolean that shows if the chapter is locked
or not. The chapter node gameobject has two children that are used to represent the locked
chapter node and unlocked chapter node. Basically, they are multiple overlaid 2D sprites.
For the level node in chapter node, is customised using the chapter map node prefab, shown as
Figure 3.13. Similarly, it has a collider and a level script component. The level script compo-
nent has a few attributes to support the chapter map manager, conversation window and hero
12

14. movement. It has six attributes, level Id, level scene Id, isLocked, stars, dialog and ptsToNxtLv.
The level Id is an integer that indicating the order of the level in the chapter map. The level
scene Id is an integer that indicating the corresponding level scene in the build setting. IsLocked
is an boolean that shows if the level is locked or not. The stars attribute is an integer recording
the the highest number of stars obtained from the level. The dialog is a string array that stores
the conversations for each level. The ptsToNxtLv attribute is a gameobject array that stores
the path points to next level node.
Figure 3.12: World map node
Figure 3.13: Chapter map node
3.4.2 Tutorial
In the tutorial part, we need to mainly illustrate pair clue, square clue as well as four basic rules
for the game.
13

15. Figure 3.14: Pair clue
For example, in the figure 3.14 we need to find out two numbers whose sum is 10 and product
is 24 and input them into the empty mystery number squares. Thats a pair clue.
Figure 3.15: Square clue
In the figure 3.15, we need to find out four cornering numbers whose sum is 13 and product is
18. Thats a square clue. There are also four important rules for the game:
· Mystery numbers range only from 1 to 9 and these numbers can be used many times.
· Each mystery pair can only occur once in a game. A mystery pair is two numbers in the
same pair clue.
· cZeus square is an exception. A cZeus square has 4 cornering identical mystery numbers
which is allowed in the game.
· One game only has one solution.
We built a separate tutorial at first. But we found that users tend to enter the game directly
when opening a mobile game without paying attention to the tutorial. After discussing with the
company, we decided to merge the tutorial into the first 5 levels of game which made users play
and learn.
In level 1 we only have a pair clue and users are guided to input two numbers respectively
in the empty squares. When they click the square we only give them two options of correct
answer which decrease the difficulty. In level 2 we still have one pair clue but we make the num-
bers more complicated. We believe that it is helpful to remember the basic and most important
rule by doing one more practice. In level 3 we have two pair clues and users have to input three
numbers which means one number is shared by both clues. We also illustrate that sometimes a
pair clue might be empty. In level 4 we have 3 pair clues and the game looks harder. We tell
users that they should solve the whole game starting from an easier pair clue and we insert the
rule that each game only has one solution. In level 5 the last tutorial level, we have four pair
clues and together they form a square clue. We ask users to input numbers which satisfy both
14

16. pair clues and square clue and each combination of numbers can only appear once in a game
regardless of their order. For example, they are not allowed to use 2 and 6 twice in any order.
However, the four cornering identical numbers case is an exception. Here we replace the concept
mystery pairs because the goal we want to introduce this is to avoid repetition of number pairs.
By merging tutorial the in-game part, we make it easier and more convenient to learn how
to play this game. Users do not have to watch a separate tutorial without living example.
Instead, they can play the game directly while the game is at entry level with guidance. We
believed that this interactive way might have better user experience and save time to learn a
tutorial which is often considered to be boring.
Figure 3.16 shows two tutorial pages of the original version. In the new version the content
of tutorial are merged into the dialogs between the character and the tutorial bird.
Figure 3.16: Two pages of old tutorial
3.5 External puzzle data parsing
3.5.1 Puzzle data structure
Database will be used in our product, since this project is for a real company. They want
us to use database to create data rather than complex algorithms and the form of database
must be CSV files. Thus, there has been some kinds of different data structures. In addition, for
each kind of data structure, there will be many different entries and they have the same structure.
Level 1 to level 5 are used to teach users how to play the game, those 5 levels are the sim-
plest levels. They will have different impressions on the screen, we employ a simple way to
handle those different impressions. From level 1 to level 5, our basic elements are square which
contains numbers used to calculate, rectangles that contains operators and results, different pos-
sible answers for filling the square. For each different level, we put rectangle and squares besides
it one by one, and then put every possible answers behind them one by one. Figure 3.17 and
figure 3.18 show what the level 1 and level 4 like, other three levels are the same organization
with little differences.
15

17. Figure 3.17: Level 1
Figure 3.18: Level 3
The level 6 to level 17 are combined by three kind of components, their are size of 2*2, 2*3 and
3*3. As the figure 3.19 show, the basic components are always the rectangle and little squares
which the same with level 1 to level 5. The only different place is the big square. Inside it,
the upper number is the sum of the numbers in the four little square around it and the lower
number is the multiply of the numbers in the four little square around it. Thus, any size of the
game board can be designed as the combinations of those three kinds of basic components.
Figure 3.19: Basic components
3.5.2 CSV parser integration
Our project data files are CSV files which contain input data to use in cZeus game application.
The CSV files are provided by owner and separated for each level in one CSV file. Also, CSV file
reader program is developed to import the data into the game application. During the algorithm
implementation, we did as follow.
Firstly, our product receive a level number from users by clicking the mobile screen and use
16

18. that level number to choose the CSV file that need to be read. Then, we read that csv file and
count the number of rows in that csv file and use random function to generate a number used
to choose which row we need to read, since each csv file contains many different data that can
be applied in game, thus we need to use random number to choose one of them to utilized in
game. After that, we will create different size of table to contain and show the data according
to the different level in game, thats why we read the number of rows and columns. Finally, we
return the data to the in-game program which is a part of our code used to create and process
initial data.
3.6 In-game implementation
3.6.1 Gameboard
There are three game boards in this game shown as figure 3.20.
Mystery number board contains a mystery number.
Pair clue board contains the sum and the multiplication of the two mystery numbers on the
left and right (or above and below) which is called pair clue. There are two kinds of pair clue
board in this game, horizontal pair clue board and vertical pair clue board. The sum and mul-
tiplication is pair clue may not be given in some puzzle, if that is the case, you still can input
number as a guide to help you solve the puzzle.
Square clue board has the same structure like pair clue board, but the positions of sum and
multiplication are different.
Figure 3.20: Three types of game board
We designed and implemented four gameboard prefabs, mystery number board prefab, horizon-
tal pair clue board prefab, vertical pair clue board prefab and square clue board prefab, shown
as Figure 3.21. Prefab is useful because the gameboard gameobjects are frequently used and
existed in the in-game scenes. Apart from that, making changes to a prefab also apply to all the
instantiated gameobjects in the game world.[5]
17

19. Figure 3.21: Board prefabs
For each board prefab, it has a board background implemented using sprite renderer compo-
nent. Board prefab has a board script component, shown as Figure 3.22. It has a boolean
attribute isPressed indicating if the board is focused. Apart from the background, we toggle the
mathematical symbols for different situations in the pair clue board and square clue board And
it is handled by the board script component. Specifically, the board script will check if tt has
addition content and product content assigned, if it has then it will display the mathematical
symbol for corresponding content. For example, it will display the plus sign icon when it addi-
tion content is inputted. Moreover, board prefab has various number of content prefabs as child.
We specify content prefab into three types that are mystery number content, addition content
and product content shown as Figure 3.23. Mystery number content records the input for the
mystery number board. Addition content and product content record the input for addition and
product in pair clue and square clue. These content prefabs are are under the control of content
script component. It has three attributes. A string called answer that represents the answer of
the board. A string called content that records the current input of the board. A boolean called
isAnswered shows if the board has been answered.
Figure 3.22: Board prefab
18

20. Figure 3.23: Content prefab
If the addition and product content of pair clue or square clue are not given, the corresponding
mathematical symbol is disabled. If the player pressed the related area, the content element is
enabled and player can input numbers as a reminder for themselves. For example, if the player
presses the addition content area in a pair clue board, then the player is able to enter number
to and the plus icon will also appear. If the addition or product content is given by the puzzle,
it will have corresponding number sprite gameobject as child. The number sprite gameobject
is instantiated from the number prefab that contains ten sprites from zero to nine, shown as
Figure 3.24. For content smaller than ten is represented by a single number gameobject, and we
use multiple number gameobjects to represent the number that is larger than ten.
Figure 3.24: Number prefab
In order to make the board clickable, we need a collider for each gameboard to detect the action
from players. We can attach a collider to either the board prefab or the content prefab, both
will do the job. However, we believe putting the collider on content prefab will simplify the
implementation as pair/square clue board has two contents. So the board prefab will have two
colliders if we attach the collider to it. It will make collision check inaccurate. This design also
help us to have a consistent structure as each content prefab is controlled one collider.
3.6.2 Input
There are two major parts namely board press handler and input number bar handler, the board
and input number bar are shown in figure 3.25. The board press handler manages events that
19

21. player presses the board (mystery number board, pair clue and square clue board). When the
player press the board, this board are highlighted and input number bar appears. The player
can deselect the board by pressing the same board. if the player presses the different board, the
previous selected board will automatic deselect. The input number bar handler is responsible to
send input to the board and store the wrong answer. In sending input to the board for pair clue
and square clue, the selected input is appended and sent to the board however the data that send
to the board is cleared first if the data meet the maximum length. For mystery number board,
the selected number will present on the board when player selects a correct answer. Moreover, if
player selects a wrong answer, the input number will be disable this input and mask the wrong
number in the input number bar for this mystery board only. In addition, the input number bar
contains a hit button for mystery number board. When the player presses the hit, the mystery
board will update the correct answer. Also the player can use the hit only twice for each game
level.
Figure 3.25: The board and input number bar
3.6.3 Timer and score calculation
Timer functions are implemented by using C# library. the timer function are designed and built
into the initial timer, start timer, stop timer and pause timer. For the initial timer function, it
requires the initTimerValue parameter which use to countdown time in second. Also start, stop
and pause timer functions use to control this timer. Moreover this timer will clear and close
itself when time is finish or before the timer is called initial again. These functions are used in
game manager.
Star and score calculation are provided the information by the company. This calculation use
the error counts and the level of the game to product the star and score result. This method
executes by looking up the figure 3.26 and 3.27.
20

22. Figure 3.26: Specifications of pass or 1-5 stars scores for a set for all levels
Figure 3.27: Numerical scores of stars for level 1 to 14
3.7 Animation
The animation is implemented in two types. There are a record character movement and using
the plugin code (LeanTween[10]) into script, for both method we decide to use them in conve-
nient way. The record character movement (it is shown in figure 3.28) is a unity function it seems
recording a video and store it into library function in a state machine method (it is shown in
figure 3.29). Moreover we use a plugin code (SimpleCCD[11]) which control the pivot character
joint (head, hand or leg). This plugin code can use for make movement of character and record
it. For using the plugin code (LeanTween), This method use in script to create movement of
objects for example scaling objects to be dynamic, move objects from left to right. Both method
are provided ability to make the game has move motivation.
21

23. Figure 3.28: The record character movement
Figure 3.29: The character state machine method
22

24. 4 Test and Evaluation
4.1 Testing
4.1.1 Function testing
We use Unity to develop our software, so we cannot directly test the results of functions as
before with the breakpoints which can show us the value of different variables in different steps.
Each time when we need to test, we add code debug.log() to print out the value of variables on
console, it was inconvenient. Therefore, we built another window-based application to test each
function of the game software, especially for those functions in CSV files parser. The window-
based application can clearly show us the values of different variables in different steps, and we
can also use triggering conditions for testing together and automatically.
4.1.2 System testing
For UI development branch, system testing is testing whether the switch between scenes is cor-
rect or not. Firstly, changing the game into play mode. Then tester clicking each function
button and back button randomly, and see whether the linked scene related to that button is
functioning correctly or not.
For In-Game branch, system testing is used to see whether the data show on game board is
same with CSV file or not. Firstly, changing the game into play mode in order to load data from
CSV file. Then we can see the changes of game board. To see the correctness by comparing the
data show on console with game board.
System testing helps to test the game is working correctly or not by detecting the link er-
rors and loading CSV data file errors. And it can also help the team specify how the game
should behave.
4.1.3 generate testing
After we have finished our coding work in the project, we also asked our group members to test
it by playing the game, since our product is a kind of mobile phone game.
Firstly, we tested the world map part of the game. Everyone checked whether the product
can jump to the correct chapter maps after we click the corresponding buttons, and then check
whether the screens can show us the components we had set.
Secondly, we tested the chapter map part of the game. Each of our group member had to
do the same things we did at the part of world map. We examined whether the game screen can
turn to the correct level map and show us the correct components.
Thirdly, we tested the most important part of the game which is the In-game part. This part
contains many places that need to be tested. After click the button in level map, we check
whether the correct game board can be shown to us, and then we played the game to inspect
the work of timer, error counter, calculation and score counter.
The four steps above are our internal testing, we will get feedbacks from each group mem-
bers and solve those problems one by one. After further review, we sent our product to the
company for their testing, since they are our employers. Then, we made changes according to
their feedbacks and tested again by internal test. After that, the same thing will happen. From
their final reply, we can see that we have met the requirements they gave us at the beginning.
4.2 Evaluation
4.2.1 Product evaluation
We have considered several ways for evaluating our software, and we divided our evaluation into
two parts. Firstly, we evaluate our product in the level of code. We need to make sure that our
23

25. product can correctly deploy and operate without any errors. Meanwhile, later expansion is also
important as well, since the new versions of our product will appear one by one, which means
our code should be concise and scalable. Secondly, we evaluating our product in the level of
performance. In this part, we mainly use the methods in questionnaires and background code.
The questionnaire will help us to directly know the ideas and opinions from the users, at the
same time, background code can help us to eliminate false data which means some respondents
sometimes will not give us the truth, such as the number of times you played this period of time.
4.2.1.1 Performance evaluation
We have decided to evaluate our product performance in terms of correctness and scalability.
For correctness, we focus on whether our product can deployed and operated correctly with-
out crash. After the functions and systems testing described as above, we have testing all parts
of our software that may interact with clients and make sure there will be no errors when clients
are playing our game.
For scalability, this section has been considered in the beginning of the project, since our project
is a phone game, thus it will regularly introduce some new versions, we need to be ready for the
subsequent updates. Therefore, we divide our codes into many small portions and structures,
meanwhile, every features is implemented by many different functions. Then, we just need to
modify those old structures and functions when we need to update our product without rewriting
the code.
4.2.1.2 Usability evaluation
The use interface is an important part in usability, since UI will occupy most of time in the
interaction between clients and product. Our product has the following characteristics.
Firstly, it has simple user interfaces. During the implementation of our product, we tend to
reduce the number of buttons and UIs. This will let all of the people can use our product,
including kids or elder people who are not familiar with modern technology. Secondly, it has
fascinating UIs. Our project is a business project, so we need to consider the attraction of our
product. We used a lot of cartoon elements and animations to make our game more attractive.
In addition to that, many kind of music are also used.
Thirdly, it has unambiguous UIs. We need to make sure that clients can quickly and accu-
rately understand how to play the game, thus we designed different kind of tutorials for different
levels in the game, and those tutorial will be showed before playing the game. In this way, clients
will be easier to understand the gameplay.
4.2.1.3 Usefulness evaluation
As mentioned above, our product is a mobile game and its purpose is helping people to improve
their mathematical abilities. After the questionnaire, we can see that the answer speed and
accuracy of clients have a slow upward trend, but because the limitation of the test time,
the trend is not steep enough. In conclusion, we achieved our original target of improving
mathematical abilities of people.
4.2.2 Overall evaluation
Overall, our group feel that our product have achieved those targets we set in the beginning of
the project. It can help people to increase their numeracy skills. At the same time, we should
recognize that our products have further room for improvement, such as UI design, game level
and business applications.
24

26. 5 Conclusion and Future Extensions
5.1 Team achievements
In the stage of forming group, all of our group members hoped to develop a game and we chose
this project which looked interesting. However, it was the first time for us to cooperate with
a company and we had to pay attention to both technology level and teamwork skills. After
discussion, we decided to use choose Scrum as the major agile method for project management.
Using this agile method, we were able to divide each sub-problem and design a solution for it
and it was really helpful to team working management. As a group, we learned how to manage
a project and work together effectively even though everyone were very busy and unable to meet
as a whole group very often. Throughout the development process, we had frequent discussion
with our project supervisor Anandha Gopalan and TMGCL who was the proposer of cZeus
project. Anandha Gopalan helped us make a good plan for the whole project and how to face
change in demand. TMGCL assigned a designer to work with us and provided us some graphical
resources. Our individual communication and planning skills have improved considerably and
will definitely help us in the future collaborative projects.
Our main development tool is Unity and almost all the developments are based on this soft-
ware. However, only one person in our group had prior technical experience with Unity and at
the beginning we even did not know how to allocate developing jobs. We asked everyone in our
group to spend one week to learn how Unity work to build a game by studying a tutorial on the
Unity official website. For every sprint, we allocated specific works to everyone including features
needed to be implemented. After more than two months’ development, we are extremely pleased
to build the whole game successfully from nothing to meet the requirements of the company.
We experienced some changes in demand of company which means we might have implemented
some features for many times.
We have gained lots of practical technical skills through working on this project and it was
indeed a very good experience for us - to build a product especially a game as the client required
from nothing. We learned how to come up with a new idea and evaluate its feasibility together
and how to manage the team efficiently to accomplish everything in time. We learned how to
cooperate with our teammates as well as clients and improve our communication skills. Most
importantly, we found a way to conquer difficult problems which we had totally no ideas at first.
5.2 Future Improvements
· A monetisation system suited for public and schools. Users can pay for more chances to make
mistakes and unlock the levels difficult to pass with some restrictions.
· Deal with the inbuilt ads in an appropriate way. We should do some surveys to find a way to
confirm ads click-through rate and also it is very important to consider user experience.
· Build a records comparing and sharing system on some platforms such as facebook using
network communication. Add a scene to represent ranking list of every level among users and
their friends.
· Design a multiple users game board to allow more than one player play the same game(same
numbers) at the same time. We need to implement real-time interaction among users which is
considered to be difficult on the mobile platform. It is also necessary to look for a mechanism
for display opponents’ real-time information in a small screen.
· Design more beautiful art assets. Gameplay and graphics are both significant for a good
game. Make the game more interesting and make users feel like that they are not doing numer-
acy but playing game.
· Build an evaluation system of numeracy including initial ability evaluation and improvements
after playing games. It might be useful to consider the standards from National Numeracy
website.
25

27. 6 Project Management
6.1 Stakeholders and Requirements
In order to better address the important features for the game, the requirements of three main
stakeholders need to be clearly figured out. At the beginning of the project, a meeting was held
on campus with all team members, the supervisor and representatives from TMGCL.
· TMGCL
The Mathematical Games Company Limited (TMGCL) is the direct customer of the team as
well as the initial proposer of the cZeus project. As mentioned by Dr. Shohreh Blank, the
founder of TMGCL, the key objective is to have better user interface than the previous game
and achieve a pilot version of cZeus Fantasy Adventure World.
· Project Supervisor
Anandha Gopalan supervised the team for cZeus project. His responsibility is to ensure the final
game product meets the requirements of TMCGL as well as the team is progressing well during
the time. His requirements are roughly consistent with TMGCLs.
· Game Players
Another important and most obvious stakeholder for a game is players. The original objective
of cZeus game and TMGCL is to improve the numeracy ability of adults in all ages. The major
requirement of players is that the game can be attractive and can improve their numeracy ability
while having fun.
To build the product backlog and plan the project, major requirements of stakeholders above
needs to be specified and prioritised. The figure 6.1 shows the key requirements of stakeholders
(from the highest priority to the lowest):
Figure 6.1: Stakeholder requirements analysis
6.2 Agile Methodologies and Practices
6.2.1 Methodology Overview
Currently, there are three major agile methods in software engineering area, namely Scrum,
Extreme Programming (XP) and Kanban.
Scrum is an agile method which focuses more on the management part of a project. It has
no instructions on how to run the project specifically. There is no project manager controlling
the whole team and all team members can add user stories to the product backlog. A Scrum
team is composed by three important roles: the scrum master, the product owner and the self-
organising team.
26

28. The team decided to choose Scrum as the major agile method for project management since
we had more experience on it. According to the requirements of stakeholders mentioned in part
3.1, the tasks in the product backlog were divided into small iterative sprints in the sprint plan-
ning meeting. The sprint cycle was decided to be one week. During the process of each sprint,
the team had the daily scrum meetings for most days. Burndown chart was followed closely to
track the project progress by scrum master. At the end of each sprint, a scrum retrospective
meeting was held to review the work in this sprint and to discuss further improvements to be
made.
6.2.2 Agile Practices
Except for Scrum, the team adopted Pair programming, the most useful technique in XP, as
well as Kaizen and also some other agile practices.
· Pair programming of XP
Since the intensive school work, it is impossible to have many people work on the same part
of code at the same time. However, for larger or more complex problems, if only assign it to
one member, the risk of bugs and the time for testing will both increases. As a result, pair
programming is a perfect way to balance the previous problems.
Pair programming ensures that at least one person in charge of the task is available for each
meeting. Besides, it reduced the pressure on individual members, improved the quality of code
and encouraged discussion or new ideas as well. For cZeus project, the most difficult part is the
building of CSV parser and in-game polish since a lot of testing are required and details needed
to be worked on. Liqun Wu and Pumin performed pair programming for this part. A lot of
time was saved and they both felt that they cannot manage to do that well as individual in such
short period of time.
· Kaizen
Kaizen was used in retrospective meetings at the end of each sprint to evaluate the progress and
improve the practices implemented. During the meeting, scrum master together with the team
members will review and evaluate the process of that sprint. The team then tries to find out
some possibility to make improvement on efficiency or collaboration.
For example, in the retrospective meeting of the first sprint, the team analysed the reason
why some work was not completed on time and decided to add a clearer due date to each sub-
task to improve efficiency. As a result, the tasks in the second sprint were all completed on
time. In the third meeting, some member mentioned that the communication inside the team
get worse due to the heavy study. We then decided to assign a leader to each sub-part of the
team to make the partial work and the cooperation of whole team better. The team functions
smoother and more efficient in this way.
· Acceptance and Beta Test
The Skype meeting between our team and the TMGCL is held around every two weeks. During
the meeting, the latest development outcome was shared. In order to provide a relatively clear
understanding of the current version of game to the client, the in-game developers demonstrate
the incomplete game running on Unity and iPhone during the meeting. The instant feedback
on client acceptance was given after each meeting.
In addition, weekly beta version on Test Flight was released after the fourth sprint. Test Flight
is a service that allows you to share the mobile application with the selected IOS users. It is
more effective than sharing the screenshots of the application. By doing this, the client is able
to have a hand-on experience of the game before the final release of the game. It does not only
help us to determine the most necessary optimisation but also improve the trust between our
team and the TMGCL.
27

29. 6.2.3 Team Structure and Task Allocation
A Scrum team is formed by three parts: scrum master, product owner and the self-organsing
team. The team decided to keep the two specialised roles to ensure Scrum is closely followed.
Thus, Liqun Wu (team leader) was chosen as Scrum Master and Ziyu Wang as Product Owner.
However, we made some alterations due to the situation of our team. Since the team leader
was chosen as the scrum master, who is the only experienced person in game development, he
needed to contribute a lot to technical implementation. As a result, the responsibility of project
management was taken by both Liqun Wu (scrum master) and Ziyu Wang (product owner).
The rest of team members took the responsibilities of designing games, programming or testing.
All team members participated in report writing. A more detailed task allocation is shown below:
Ziyu Wang is the product owner who needs to design game features, prioritise user stories
in backlog and evaluate the features implemented. She is also responsible for managing the
project progress and facilitating communication between the team, the supervisor and TMGCL.
Yifan Zhai is responsible for UI development, which is to create the scenes to build the game
structure and design the interface. After the design, she change the asset of the scene, and create
the button and image logo to make the interface functionable.
Liqun Wu designed the overall architecture of the game and implemented the puzzle game-
board and map system. He modeled the in-game scenes and build a game manager component.
He implemented the gameboard press handler and input number bar handler.
Phumin Phuangjaisri designed the data structure for the external puzzle data and implemented
the CSV file parser. He implemented in-game timer and score calculation components. He cre-
ated the animation for the hero and bird using Unity build-in animation feature.
Xidi Chen designed the tutorial contents, implemented them and merged them into level1-5.
He designed the storyline and the dialogs between hero and bird. He implemented the music
and sound effect control system of the game.
Diyi Ma is responsible for the CSV files parser. He designed and implemented the CSV files
parser which was used to process those data in level 1 to level 5. After that, he also contributed
a portion of the code in subsequent level.
6.3 Project Planning and Estimation
6.3.1 Sprint Planning
After figured out the requirements of stakeholders, the team discussed about the plan which
shows six iterative sprints in total. The related task and date for each sprint was shown in
details by figure 6.2.
28

30. Figure 6.2: CZeus project plan
The revision week and the exam week were excluded in the timetable. Some extra time in
the winter vacation can also be used for possible unexpected, delayed or extended tasks. This
gave us a better idea of the scope of the project and enabled us to progress at an acceptable
rate.
6.3.2 Estimation and Progress Tracking
Progress of the project is mainly tracked via the Burndown chart. At the beginning, the team
estimated the percentage of tasks finished in each sprint of the plan by their priorities. The
ideal line in figure 6.3 shows the initial estimation of work. During the project progress, in the
retrospect meetings at the end of each sprint, the team reviewed the work done and the work to
do. The actual line in figure 6.3 tracks the real progress of the team.
29

31. Figure 6.3: Burndown chart
From the figure 6.3, the progress from sprint 3 was a little bit behind schedule. The reason is
during the implementation of CSV parser, the team member found some mistakes in the CSV
data files given by TMGCL, work is delayed due to the communication between two sides and the
time for TMGCL to correct the data files. During Sprint 6, the team was given some new assets
and was asked to add some new animation by TMGCL, so some time in the winter vacation was
used to do that extended task.
6.4 Tools
6.4.1 Game development tools
· Unity
Unity[6] is the ultimate game development platform which can be used to develop games for
PC, consoles, mobile devices and websites. It is the main software used for game development
in this project. The team use Unity to create the main scenes, apply assets, and add elements
and animations.
· GitHub version control
GitHub[7] is an online service that hosts Git repositories on behalf of its users. The team created
a private repository called cZeus Fantasy and Adventure World for version control of the project.
GitHub allows the team to work in high productivity and without being worried about version
conflicts. The committed changes can be instantly reviewed and commented by the scrum mas-
ter once it gets pushed to the repository. Apart from source code control, it is straightforward
to monitor the project progress so we can have a reasonable estimation.
For cZeus project, the master branch is a default branch that initially containing an empty
Unity project. Four branches (UI development, CSV parser development, Map development and
In-game development) were created from the master branch related to the main parts of the
project. Each branch was then merged into master branch after being successfully implemented.
The overview of GitHub for the team is shown in Figure 6.4.
30

32. Figure 6.4: GitHub overview
6.4.2 Project Management Tools
· Trello
Trello[8] was used to manage the cZeus project. For each sprint, one board was created and the
tasks in the product backlog were added in details. Through those boards, the team can get the
idea of what each part of the team is doing and whether we are progressing in the right speed.
This tool also allows us to assign tasks to each member. Besides, the designer from the company
also needs to know the overall progress of the team, since he needs to design and provide related
assets for the game. A screenshot of details of the Trello board is shown by Figure 6.5.
Figure 6.5: Trello screenshot
· Basecamp
Although Trello is professional for project management, it is not very convenient to share and
manage documents. Thus, the team chose Basecamp to keep the notes and photos of whiteboards
for each scrum meeting. Figure 6.6 shows the meeting notes managed by Basecamp. Through
the notes and photos, the team can clearly know what they have achieved in the past and how
they improved. Those records also facilitated the final report writing a lot.
31

33. Figure 6.6: Basecamp meeting notes
6.4.3 Communication tools
· Team with TMGCL or supervisor
The skype meeting with TMGCL including the Founder, the CTO and the designer was held
at least once two weeks. One face-to-face meeting with representatives from TMGCL was held
at the beginning of the project. CSV files and assets were shared through Google Drive folders.
The communication between the team and supervisor is done by emails and face-to-face meetings.
· Within Team
The team set up a WeChat group for daily communication. We arrange team meetings and
share immediate ideas in that group. The team also uses Google docs to facilitate report writing
which is extremely useful for drafting the Software Engineering Practices coursework.
32

34. Appendix
Figure A1 and Figure A2 shows the screenshots of winning or losing the game as well as the
game record page.
Figure A1: Main gameboard & winning and score page
Figure A2: Gameover & game records page
33

35. Bibliography
[1]Cost of outcomes associated with low levels of adult numeracy in the UK (2014)
http://www.nationalnumeracy.org.uk/cost-outcomes-associated-low-levels-adult-numeracy-uk-2014
[2]National Numeracy – What is the issue?
http://www.nationalnumeracy.org.uk/what-issue
[3]Importance of Numeracy as a Risk Factor for Elder Financial Exploitation in a Community
Sample
http://psychsocgerontology.oxfordjournals.org/content/early/2015/07/28/geronb.gbv041.abstract
[4]Unity assets
https://www.assetstore.unity3d.com/en/#!/content/17250
[5]Performance of using prefabs in Unity
http://answers.unity3d.com/questions/523037/performance-benefits-of-using-prefabs.html
[6]Unity
http://unity3d.com/
[7]GitHub Repository for cZeus Fantasy Adventure World Project
https://github.com/leowu4ever/cZeus-Fantasy-and-Advanture-World/
[8]Trello boards of cZeus Fantasy Adventure World Project
https://trello.com/czeus
[9]Basecamp of cZeus Fantasy Adventure World Project
https://basecamp.com/3069716/projects/10792149/
[10] LeanTween
http://dentedpixel.com/LeanTweenDocumentation/classes/LeanTween.html
[11] SimpleCCD
http://learnunity2d.com/unite-2014-2d-best-practice-for-unity/
34