designing and implementing a mobile web-based …1113913/fulltext01.pdfhenrik eriksson ii...
TRANSCRIPT
Linköping University | Department of Computer Science Master Thesis, 30hp | Computer Science and Engineering
Spring term 2017 | LIU-IDA/LITH-EX-A--17/035--SE
Designing and Implementing a Mobile Web-based Math Game with Good and Stable Performance
Christoffer Nilsson
Aseel Berglund Henrik Eriksson
ii
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
© Christoffer Nilsson
iii
Abstract
Designing games, especially for mobile devices, requires that developers think through their design of
content, both logically and visually. The user interaction tools differs a lot between desktop and mobiles,
and does often need to be considered during the development. When the game is also meant to be played
through a web browser in some way, advantages and limitations by having that layer, should be taken
into account as well, as it restricts access to file system, but at same time provides its own storage
functionality.
As game development in general is rather complex, this thesis focus is to give an example of a
mobile web game, which could be extended and adjusted regarding some specific topics. It also shows
that game development frameworks like Phaser, are very useful.
The game is developed in Javascript, with the aforementioned Phaser framework. Some results
found, shows that Canvas is still superior to WebGL for mobile devices. Atlases do help even for smaller
amount of images, although not by very much, and that choosing an appropriate game level generation
algorithm as well as its implementation can greatly affect performance, but that there might be trade-off
between speed and functionality.
iv
Acknowledgements
First I would like to thank Aseel and Erik Berglund for the opportunity to do the thesis work with them.
Their support and guidance have been very helpful, and I could not have done this thesis without them.
Lastly, thanks to friends and family for encouraging and understanding me during this process.
v
Table of Contents
Chapter 1 Introduction .......................................................................................................................... 7
Chapter 2 Background ........................................................................................................................... 9
2.1 Previous work ..................................................................................................................................... 10
Chapter 3 Theory ................................................................................................................................. 11
3.1 Mathematics and Computer Games ................................................................................................... 11
3.2 Games ................................................................................................................................................. 11 3.2.1 Game design ............................................................................................................................. 12 3.2.2 Mobile game design .................................................................................................................. 12 3.2.3 Learning games ......................................................................................................................... 12
3.2.3.1 Matching content to media ............................................................................................. 13 3.2.3.2 Integrating content with game ........................................................................................ 13 3.2.3.3 Fitting content together .................................................................................................. 13 3.2.3.4 Motivation ....................................................................................................................... 13 3.2.3.5 Gamification .................................................................................................................... 14 3.2.3.6 Feedback ......................................................................................................................... 14
3.2.4 Performance ............................................................................................................................. 14
3.3 Web development .............................................................................................................................. 15 3.3.1 Performance in Web applications ............................................................................................. 15 3.3.2 Mobiles and the web ................................................................................................................ 16
3.4 Phaser framework .............................................................................................................................. 16
3.5 Texture compression ........................................................................................................................... 16
Chapter 4 Method ............................................................................................................................... 17
4.1 Pre-study ............................................................................................................................................. 17 4.1.1 Using Phaser.............................................................................................................................. 17 4.1.2 Competitor analysis .................................................................................................................. 18
4.2 Implementation .................................................................................................................................. 18 4.2.1 Environment and Measuring .................................................................................................... 19
4.2.1.1 Measuring tools ............................................................................................................... 19 4.2.1.2 Measuring performance .................................................................................................. 19 4.2.1.3 Code readability and quality ............................................................................................ 21
4.2.2 Level generation........................................................................................................................ 22 4.2.3 Menu pages............................................................................................................................... 22 4.2.4 Atlas packing ............................................................................................................................. 23 4.2.5 Texture compression ................................................................................................................ 24 4.2.6 Pack file loading ........................................................................................................................ 24 4.2.7 WebGL or Canvas ...................................................................................................................... 25 4.2.8 Medals....................................................................................................................................... 25 4.2.9 Winning badge and medal ........................................................................................................ 25 4.2.10 Runtime image swirling ........................................................................................................ 26 4.2.11 Player statistics ..................................................................................................................... 26 4.2.12 Menu UI improvements ....................................................................................................... 26 4.2.13 Missions................................................................................................................................ 26 4.2.14 Creating episodes ................................................................................................................. 27
4.3 Evaluating results ............................................................................................................................... 27
vi
Chapter 5 Results ................................................................................................................................ 28
5.1 Performance measurements .............................................................................................................. 28 5.1.1 Level layout generation ............................................................................................................ 28 5.1.2 Atlases and images .................................................................................................................... 30
5.2 Improved features .............................................................................................................................. 32 5.2.1 Episode progression .................................................................................................................. 32 5.2.2 Badge swirling ........................................................................................................................... 32 5.2.3 Creating episodes and game modes ......................................................................................... 33 5.2.4 Asset loading ............................................................................................................................. 33
5.3 New features ...................................................................................................................................... 33 5.3.1 Atlases ....................................................................................................................................... 33 5.3.2 Medals....................................................................................................................................... 34 5.3.3 Menu pages............................................................................................................................... 34 5.3.4 Statistics .................................................................................................................................... 35 5.3.5 Missions .................................................................................................................................... 36
Chapter 6 Discussion ........................................................................................................................... 38
6.1 Performance, feature and code improvements .................................................................................. 38 6.1.1 Level generation........................................................................................................................ 38 6.1.2 Atlases ....................................................................................................................................... 38 6.1.3 Badge swirling ........................................................................................................................... 39 6.1.4 Game modes ............................................................................................................................. 39 6.1.5 UI changes ................................................................................................................................. 40
6.2 New features and their impact ........................................................................................................... 40 6.2.1 Menu pages............................................................................................................................... 41 6.2.2 Statistics .................................................................................................................................... 41 6.2.3 Missions .................................................................................................................................... 41
6.3 Future work ........................................................................................................................................ 41
6.4 Work in wider context ........................................................................................................................ 42
Chapter 7 Conclusions ......................................................................................................................... 43
References ................................................................................................................................................. 44
7
Chapter 1 Introduction
As technology evolves and improves, in particular within the area of computer science, it can be utilized
in an ever increasing extent. Nowadays computers exist everywhere, in vehicles, washing machines,
watches, etc. Also advanced software is produced, for example telecommunication networks, large
artificial intelligent systems and computer games. What makes computer games of special interest, is
because it’s easy to visually see the difference between games from different generations, due to
technology improvements within the field of computer graphics.
Another area which uses new technology to perhaps less extent, is teaching, especially in Primary
school. Some technology is used, but they’re mostly improved versions of an old original, for example
calculators and projectors. Regular computers are typically used for reading and writing documents.
An interesting cross-field combination that have emerged during last decade, is just between
computer games and teaching. Due to new technology and a slight change in opinion about computer
games in general, have made it possible to use games to some extent as part of education. This opens up
new possible ways of teaching, and it can also be easier to keep children focused and active in their
learning process. The fact that this is a relatively new field, with moderate interest, it haven’t been
extensively studied, which means there’s likely much more to be discovered and determined.
To think of this in a practical sense, there are some challenges left to overcome, when attempting to
use games for learning. Firstly, one must develop a game specifically designed with teaching in mind, or
certain essential components will be left out or insufficient for learning purposes, since games in general
aims to be an entertainment resource. Secondly, the game must still feel interesting enough to keep
people playing, and especially younger children prefer more visual feedbacks rather than text when
playing. Finally, these types of games are typically limited in sense of hardware, due to often needing
mobile devices, possibly even being played through a web application.
This puts demand on the application structure and performance, since frame rate drops and long
loading times can make the player somewhat frustrated and lose focus and interest in the game. As there
is a direct contradiction between more graphics and effects, and game performance, some trade-off must
be made. To reduce impact of the trade-off, optimizing and using techniques to improve performance
can be done. This thesis will attempt to partly answer this particular question, as applied to a specific
subset of components.
How to design and implement a mobile web-based math game with good and stable
performance?
As good and stable performance is the key goal, the work will focus on investigating various
techniques that would seemingly allow more effects and graphics into the application, but still be
effective enough to not impact performance measures too much. This work will focus upon technical
measurements of performance, for example frame rate during certain events and resource usage.
There are no specific hard limits or requirements for this either, as it is up to the player to determine
if it feels smooth and enjoyable or not. This makes it a lot harder to know when certain requirements are
8
fulfilled or not, as different players will probably feel differently about the game in various aspects and
times. Since that it’s a very complex problem, a general guideline for user experience in this matter will
be used instead. Based on numbers and results from the guidelines, some minimum performance
requirements can be determined. What is important to remember, is that this performance should be
achieved on the device with lowest hardware capabilities, that will be supported by the game. Testing on
best possible configurations, leads to false conclusions about performance measurements in come
scenarios, unless game effect quality and quantity can be customized by the user or detected by the
application itself.
Since this work is about improving an existing system, rather than building a new one, understanding
how it works is an important aspect. A possible problem is that it’s easy to get locked to use parts of
existing solution, when it actually would be better to replace it. Thus it’s important to keep in mind that
this can affect the results. An appropriate method needs to be applied to minimize these kind of
situations.
9
Chapter 2 Background
This thesis is done within an existing project developing a web application, specifically a math game
called ‘Entanglement’ for younger children, primarily for primary and middle school. The goal of the
game is to select matching cards from a board. Each card needs to be flipped up to see them, and also
each card is attached to another card which is flipped up with the first one, but not revealing its number.
Each game session have a particular sum, so the player can that way know what the sum of each card
and its paired one sums up to together. The goal is then to select cards with equal numbers, which can be
done by calculating the hidden numbers.
Figure 1 Example of a game session
10
The current state is that the performance limitations causes a hinder for adding desired effects to the
scene. The goal of the thesis then to address this issue, and find a solution which will improve
performance enough to not make it an obstacle for adding new game content and features.
The current framework used is Phaser, which is an extension of regular Javascript and HTML5 [1].
2.1 Previous work
There have been several other previous works that have looked into various aspects of this project. For
example, a performance evaluation was made by J. Bäck to find what functions and part of code that
took a lot of time to perform, and why they used that much time. A major concern found was that
loading large assets, such as high-resolution images, took quite long time. A possible solution was to
scale down images as it proved a dramatic reduction in loading time, however, sometimes high-
resolution images might be preferred to be used. [2]
The initial implementation of this project was made by J. Alm, based on an idea by E. Berglund. That
work investigated if Phaser made development of a web-based game easier overall, even if learning
Phaser would be needed. Also advantages and disadvantages by using Phaser or any framework were
tested, compared to regular Javascript and HTML5. As Phaser is rather large, and the selected game
prototype were a puzzle game, certain features could not be tested, such as physics and real-time
updating. Based on the experienced results while developing said prototype, the conclusion was that it
was not that hard to learn Phaser due to being well documented. Given the granted functionality Phaser
offered, it seemed well worth the effort to learn how to use it to create a game. [3]
Another work related to the project is one done by F. Öhrström, who investigated different effects for
their contribution to immersion for players. The types of effects were animations and tweens, that is
gradual changes to an object over time. As Phaser have good support for tweens, it was easy to make for
example movement or fade-in effects using its API. Results were gathered using a survey where
participants were asked what they thought of certain effects and how immersed they felt while playing. It
showed that the game had some attraction, but could use more development to make it more interesting.
[4]
11
Chapter 3 Theory
3.1 Mathematics and Computer Games
Teaching students and make them understand have always been a challenging task. They may have
difficulties to comprehend the content, or simply too bored or don’t care trying to learn. One common
technique to make the theory learned easier to grasp, is to give examples of its use or adding some
additional context around it. This can be helpful for understanding better, but if a student deem the
subject boring, an example will not make much difference. Trying to find a way to get them more
interested, a combination of an entertainment technology with the subject in question could provide a
new way of learning it.
In a fairly recent article by Ke F. [5], a study was conducted that tested if computer games with math
problems inside the game was helpful for middle-school students. The test subjects went on several
occasions to a computer lab, where they played a math game, while also having tutors to aid them if
necessary.
The results of this showed that the games may have had some influence, but it was not significant
enough to prove the games made a real difference. Also, tutors had an active role in teaching the students
as well, both in gameplay mechanics as well as the underlying math itself. It also showed that if the
student and tutor engaged and had more collaborative relationship, instead of teacher-student-relation,
the student were more likely to express their thoughts and ideas.
Incorporating games as a part of teaching is possible, and can be used in mathematics as well as other
subjects, such as history, geography, physics and more. It is still a quite young research field and current
ideas of how school teaching is done may cause hinders for this to become a common part of education.
As M. Fisch points out, giving constructive feedback and hints to players, and also clearly integrating the
subject into the game, are important for this teaching form to work [6]. It is also possible to think of new
VR technology to be a possible future for learning as well, but it is likely quite far into the future for it to
be efficient enough.
3.2 Games
Games exist in many forms, and when it comes to video games, there are a large number of genres,
variations and types of games to choose from. When creating a game such as Entanglement, there are
some main topics that should be addressed for its development. Since it is a learning game for mobiles,
both design and content should be tailored with that in mind, to receive best outcome. And as mobiles
generally have lower performance capabilities than desktop environments, this becomes an important
topic as well.
12
3.2.1 Game design
Designing games is not an easy task. It involves many parts and thought must be given to every aspect to
achieve a final polished product, that keeps players entertained and keeping them playing. There are
many different game genres, which all require a specific design to work properly. C. Clanton outlines
three main steps or levels for game design to look out for [7]. User Interface (UI), is the first step and
challenge for new players; one must know the controls to be able to play. It should be introduced in a
good way that is relatively simple and where players can have a chance to learn how to use them. Later
on, when some progress is made, more features and tricks can be added, which is then part of game
mechanics. This is next part, once the controls are established, it should be matched to what action they
perform in-game. Often it can be done simultaneously as learning controls, but can depend on game.
If those steps are achieved, it is time to do something, progressing and interacting, that is playing the
game. Here it is good to introduce players to some near or distant goal, and a current task to do right
away to get started. It should not be too hard as players are rather fresh, so starting slowly to
incrementally increase difficulty to always keep players challenged. Letting players tune their desired
difficulty themselves can be a nice option as well.
Once players have gotten into game a bit, you need to keep them and not losing them to boredom or
frustration. Helping stuck players and allowing some trial-and-error can be good or bad, depending on
type of game. Having to restart the entire game for example due to an unforeseen consequence or slight
misplay is not fun if you do not know what the stakes are.
3.2.2 Mobile game design
Designing games for mobiles versus desktop or consoles, is a bit different in some aspects, but yet
similar in other. The main differences are device inputs, typical playing environment and purpose, and to
some extent screen size. Creating a game with touch interaction in mind is quite different from keyboard
and mouse. When it comes to playing environment and why the user is playing, desktops are located at
home and there is a clear intent to play game instead of doing other things. Mobile games can be played
virtually anywhere, among other things during travelling, on a bus for example, or while waiting for a
friend to show up. This facilitates that game should preferably be rather quick to start and get into a
game, and be able to quit rapidly without losing too much progress. It is also more important to handle
shorter interruptions and pauses. These things are brought up as key factors for mobile games, when
making a heuristic model for measuring playability aspects of games, by H. Korhonen and E. Koivisto
[8]. For most other aspects, general game design principles still apply.
3.2.3 Learning games
When designing a game made for educational purposes, some special considerations needs to be made.
Creating games that successfully teaches players something while will being enjoyable enough to keep
players playing, can be a challenge. If the game is too close to regular textbook activity, for example
reading a math book and use pen-and-paper to solve the exercises, then the children could just have done
that in the first place. On the other hand, if it is too much of a game with not much learning content, it
will not be very effective procedure either.
Apart from balancing learning and game content to each other well and meaningfully, there are other
things to take into account to create a good game for learning. Some more important things are outlined
by Shalom M. Fisch, and include matching content to the media playing on, integrating the learning
content well into the game, and ensuring different content elements fit together smoothly [6].
Furthermore, Fisch notes that giving constructive and helpful feedback, often with some hint, would
improve learning capabilities of the game.
13
3.2.3.1 Matching content to media
To match a game with its play media, one must first think of the situation where the game is most likely
will be played in. If it is a game for pure entertainment, it might be most common to be at home at a
computer for example, while if it is a learning game, might be more likely to be played in a classroom.
Related to this is to consider what devices that may be available given a certain situation. As for the
classroom example, a tablet or other mobile device is likely better target than a desktop, since they are
easy to move and does not require a specific computer lab to play the game.
Another thing to take into account is what type of media that would suit the game best. This is
especially important when it comes to learning games where players are supposed to learn a real-world
skill. Fisch gives an example about a balance game where players had to balance building blocks in a
tower so that two characters could use that as a bridge to get to each other. It may seem like a good idea,
but due to lack of tactile sensing, or not realistic enough, that can be made with a mobile device, the
response to players did not compose wanted feedback. It would likely been more effective to have the
players play with real wooden blocks and such instead. [6]
What can be seen is that device play media should be considered before making the game, and also
make a game that can teach a subject effectively using available media in a particular situation.
3.2.3.2 Integrating content with game
There are many possible ways one can think of how to present a math problem, for instance to a
player. The most straightforward is simply to display the equation or task, and having a way to
determine if given answer is correct or not. Doing it this way, it is not much different from regular books
and paper. As M. Fisch also points out, “In fact, from a long-term perspective, this sort of approach
could even inadvertently promote negative attitudes toward the educational content […]” [6]. How well
the subject to learn corresponds to a skill learned in the game is likely the most important part when
making an learning game. If the integration is good, practicing in-game skills would then give
knowledge about the subject for which the game was built around. What should also not be forgotten, is
that getting players immersed in the game would likely yield best effect, but to accomplish that, the
game need to have content that fits together well.
3.2.3.3 Fitting content together
Apart from having content that works well with the game and is adequate for teaching the subject to the
player, it is also important to have different parts of the content flow together seamlessly. For example if
the player is playing a shooter game and then suddenly needs to solve a mathematical equation to open a
door, it could interrupt the flow, which would be bad for the player experience of the game. As described
by J. Chen, feeling flow in a game is a good factor that makes players feel entertained and enjoyed [9]. It
is therefore important to have the content fit somewhat naturally to each other, to keep players interested
in the activity.
3.2.3.4 Motivation
To get players wanting to play a game, they need to feel motivated to do so. There are theories and
models about motivation and what makes things in general as well as games interesting. One theory is
the Self-determination theory (SDT), which focuses mostly on intrinsic motivation, which is likely the
most relevant type of motivation for computer games. Motivation can be rather complex to define, as
well as measure. One way to help this a bit is to divide it into smaller components. SDT names three
basic ones that seem to relate to motivation, autonomy, competence and relatedness. [10]
Here autonomy correlates to activities where the player have some freedom of choice, and things that
interest them or give them something. If the player feel too controlled or locked into following a given
path, the perceived autonomy may decrease.
Competence is about players needing some challenges in a game to get a motivational boost, since if
it is too easy, they will not feel like they accomplished anything. On the other hand, if it too hard, they
may just give up and try another game. Thus game balance as well as feedback of success becomes
14
important motivational factors. A thing that may not seem that important for games, but that actually
makes notable difference for motivation, are how easy the game controls are to learn and use. If they are
intuitive and easy to remember, it becomes easier for players to focus on the game, rather than trying to
hit the right buttons.
Lastly, relatedness represents relations and connections to game elements or characters, and real
players in multiplayer games. For multiplayer games, social interactions and a need to show off
achievements may become significant factors for some players that pushes their motivation to continue
playing, and also try to get better at the game. This is also something that can be used outside of games,
by introducing gamification elements to the subject.
3.2.3.5 Gamification
The concept of introducing games or game-related elements into other activities, have been around for
more than a century, for example the Boy Scouts of America used merit badges already in 1911. Today
the use of gamification is spread across multiple areas, in particular via web content. Examples could be
education, task management and sustainability. [11]
This phenomena is described by S. Deterding in his article Gamification [11]. He describes that
gamification must be used correctly, otherwise it will make the business worse than before adding a
gamified element to the system. One must understand the users and their goals and intentions while
using service, to know where to target and balance rewards for them. After all, the virtual rewards
received is only to display some sort of status, to show for other users. The hope is that new users will
then strive to get some achievements too, in other words, introduce some competitive or social grouping
kind of motivation.
As noted in both F. Ke and S. Deterding, gamifying education in some ways can help keep
motivation about learning up, especially for younger kids, as they tend to have less patience and
persistence about learning. [5,11]
3.2.3.6 Feedback
Providing feedback for wrong actions in a game is very important, whether or not it is a learning game,
for players to understand that their action did not work as intended. For learning games, it is also good to
try to explain why it did not work, thus attempting to teach the player. Giving some hints to guide the
player in the right direction may be good addition as well, although helping too much could instead
make players lazy and just seek the help without trying themselves. It should be triggered by actually
trying but failing. If the level of hints starts low and increases when player still does not understand, it is
likely to provide more encouragement to keep trying, rather than just telling the answer is wrong or keep
giving same hint over again. [6]
3.2.4 Performance
There are several factors to why performance might be important in a game, one of them is the players
feelings about the game. If the player don’t like the game, he/she won’t play it. And the point about
games is that they should be played. How the player feel about the game, is affected by several main
components. One is the players attitude to games in general; if he/she barely like any game, it becomes
unlikely this game will be liked either. Furthermore, it may simply be a type of game that is not
appealing to the players preferences. Lastly, if the player experiences negative feelings while playing the
game, it may seem natural that they would stop playing. A common negative feeling is frustration, and if
it is caused by performance problems in the game, repeatedly, it is very likely to cause increased
frustration level among the players [12].
This phenomena has been studied by Taylor et al. in [12], where they made an experiment with 24
people, where they would play a game while wearing sensors to measure heartrate, skin temperature,
ECG values, etc. The goal was to find out how much system response delays affected frustration level of
15
the players. Previous work had focused mostly upon a binary classification, that is if a player is
frustrated or not. Here they used five levels instead, since it will likely better reflect the actual state of
the player, as well as more possibilities to find a connection between lag delays and frustration levels.
The selected game was Breakout, which is a game where you are supposed to use a paddle to bounce
off a ball, and hit bricks on the other side. The authors modified the game to have two modes and two
difficulties. These modes were firstly that the ball moved faster. Secondly one where the paddle was
smaller. The key here is that easy difficulty in both modes are identical, which makes the game
effectively have three types of gameplay. What was also added, was a randomized faked lag component,
which ranged between 0 to 400ms delay. The game was played on a tablet, so this is an extra delay, apart
from regular hardware/OS computations, from that user presses screen to an action is taken by the game.
The players conducted twelve playing sessions, which consisted of six levels of lag at both
difficulties, presented in random order. After the session, the player would answer six questions from
NASA-TLX (NASA Task Load Index, subjective questionnaire), among them a subjective assessment of
their current frustration level, from Very Low to Very High.
The data was then analyzed in several different ways, mainly by creating various features and feeding
them to a machine learning algorithm that was built as well. The answer they were seeking was which
level of frustration the algorithm thought it would be, based on the sensor data. Since the data samples
was rather low, they used all but one data point as training data, and the last for verification outcome.
This was done for all data samples separately, and then averaged together to achieve a result.
What their results were was that they managed to get around 80% accuracy to guess on a five level
scale how frustrated the subject in question was, in near real-time. [12]
This makes a clear connection between how a game can affect emotions and feelings of the player, in
a negative way, and in extreme situations and/or if lasting for longer durations, could make the player
stop playing the game. It’s also possible to see that similar scenario can make the player bored playing a
slow and unresponsive game, with same outcome. Thus it’s important to keep performance on
sufficiently high level to not cause too large disturbances for the player, which can be hard due to large
differences between different players and their preferences and patience.
3.3 Web development
Developing programs for the web, whether it is a regular web-page for a website, a standalone webserver
or more inline content such as a game, some challenges needs to be overcome. You need a domain for
the website, location for server and content that the server can send to the viewer. Today many tools and
frameworks are available to assist a developer to create a website, as well as servers. Services to hold the
server content exist too. But ultimately, it is up to the developer to decide what content to be put into the
website.
Here the focus will be towards games for web, and to get performance while playing to give players
an enjoyable time. As it also targets mobile devices, this will be important aspect to take into account as
well.
3.3.1 Performance in Web applications
Performance is a rather wide term, and can mean a lot of different things. In general, it means that a
system should perform a specified task in a certain amount of time. If a system can manage to complete
a task in shorter time window than another, it has higher performance. When it comes to web
applications and games, there are a few specific aspects that are of particular interest. These are frame
time and loading time, which from a user point of view needs to be good to get a smooth experience of
the application. The loading time can affect the users differently, depending on what and when it is done.
For example, loading a web page should be fast, but when loading a game, the user more often expect it
to take some time. And for frame time or fps in game or web page content, it becomes very important to
16
maintain a good baseline, because frame drops and low frame updating gives negative feelings towards
the application. As noted by F. Nah, for regular web page loading times, a period of 2 seconds is often a
limit from where users lose interest and may abort loading [13]. For loading a game, it can most likely
be acceptable with longer time than that. But in a mobile game, this could give a hint of what an upper
threshold for loading new game instances or levels and such, might be acceptable without disturbing
player experience significantly. Regarding fps, it follows same reasons why it should not be too low, as
described in 3.2.4, since it is qualified as a game in this sense, and not affected by the fact it is played in
a web browser.
3.3.2 Mobiles and the web
With the introduction of HTML5 and its Canvas element, creating games for the web has become a
lot easier, as it does not require an extra plugin or application to run. Also thanks to that Canvas can take
advantage of graphics hardware acceleration, it can achieve good performance despite being relatively
complex. An alternative drawing form is SVG (Scalable Vector Graphics) can also be used, which uses
vector graphics for drawing and can be scaled for different resolutions without losing quality. This also
affects mobiles, and with newer technologies in them, they can also benefit from these features. [14]
3.4 Phaser framework
Phaser is a Javascript framework designed for game creation for the web. It is fairly simple to
integrate and use, as it does not require any specific setup to work, at least to do the common parts. The
main target is mobiles, and have lot of functionality to deal with resources on them. It is currently
developed and maintained by Photon Storm Ltd.
Some of the main features it provides include rich sprite handling controls and animating them.
Physics engines are available as well, depending on how advanced it needs to be, both small and simple
as well as larger and more feature filled ones can be integrated. Other functionality that is granted are
cross-platform input handling, sound management, game world camera and more. It also supports a
plugin system where users can create their own additions to the framework for more specific features. It
currently also have a large community that have answers and tutorials on a lot of subjects. [1]
3.5 Texture compression
There are several different big texture compression techniques and standards today, that can be part of
OpenGL ES 2.0, such as PVRTC, ETC, ASTC, ATITC and S3TC/DXTC. These mostly require
hardware support in the GPU, and are not always available on all platforms. The choice of compression
format to test for this work is PVRTC.
PVRTC is a texture compression techniques developed by Imagination Technologies, and as part of
their PowerVR chipsets, which are used within GPUs of other manufacturers. It works by sampling and
scaling down the image into two smaller ones, in slightly different ways. Along with this, some
modulation data is saved. When it should be uncompressed, the two images are blended together, using
the modulation data for the interpolations done in the blending to add sufficient extra information to
retrieve a result quite close to the original image. [15]
17
Chapter 4 Method
In this section, the procedure used to obtain the results is described. It is divided into three main sections,
a pre-study phase, where previous work and relevant theory is studied, while possibly adjusting
subsequent methodology to the knowledge gained from this phase. Next is the core part, where the actual
work is described, including what data should be collected as well as further details about
implementation. If relevant, limitations to tests and data collection can be added, for example if practical
limitations of a tool makes it impossible to measure a certain metric. Lastly, a description of how results
will be evaluated, in order to find an answer to the research question, and a generalization approach if
deemed applicable for the found results.
4.1 Pre-study
The pre-study phase for this thesis, started by familiarizing with the current version of the game, as the
game had already been developed for some time previously. Also the existing code base needed to be
checked through a bit, to see how it was built and what styles and techniques were used, in order to try to
keep my work in line with existing code.
The stakeholders who have some insight in the work, could explain certain elements and point to
various useful resources, such as Phaser web site, as the game uses the Phaser framework for a lot of
game controlling behavior.
After knowing the game and code a bit better, an initial discussion about what parts that need
improvements and what planned new features took place. After implementing some feature or improving
something, stakeholders could give feedback on that and a new discussions about fixing issues or going
forward were held.
Along with this, to help structuring and remembering what were discussed and what progress was made
on a certain task, a project management tool was used. In this case, Trello [16] was used, as it offers easy
to use interface and clear structuring of tasks, in form of cards that can be moved around and labelled.
By adding all tasks to a To-Do list, it was easy to see what next task was going to be, and a more
detailed description could be added, along with a checklist, to get a good grip and splitting it up in sub-
tasks.
4.1.1 Using Phaser
As described earlier, Phaser is a Javascript framework for game development for the web. Learning how
it works and what it can do is, like any framework, somewhat of a challenge. Looking a tutorials and
especially examples of usages is a good approach to get see how the creators intended the framework to
be used. Phaser is open-source, which allows to see exactly how a function is implemented is it would
seem necessary to find out, and most importantly, it has a web-site containing a lot of tutorials and
18
examples [1]. Lastly, reading the project code itself may add some understanding of usage of available
mechanisms.
4.1.2 Competitor analysis
Along with learning Phaser and familiarizing with existing code base, some small evaluations were done
as well. These examined specific game elements and how those interact, in already existing games. The
games are quite successful within their genre and scope, so they should give a good overview how some
elements fit into each other. As the mini evaluations focus on specific elements within the games, it is
worth noting that some adjustments would likely be needed, and should be done, to fit the design in
Entanglement.
The games examined were Nomp, Farm Heroes Saga and Candy Crush Soda, and more details about
them and how they were used can be seen in Table 1.
Table 1 Games evaluated for competion analysis
About game Downloads1 Element evaluated Nomp It is a math game, with increasingly
difficult tasks, targeting lower
school as well as upper school and
between. All usual calculation
operators such as addition and
division are included. It also have
more advanced subjects such as
units and arithmetic’s.
10k-50k2 Medals and statistics.
How are collected medals shown?
How do you get a medal? How
does progression statistics
displayed in a user friendly way?
Farm Heroes Saga
It is a puzzle game where player
should form lines of items (plants)
in a grid, by swapping place of two
nearby cells. Goal is to collect
certain amounts of plants of
different types to win that level.
Matching many plants in longer
lines and such gives extra score.
100M-500M Missions.
What kind of missions do they
have? How hard/long time do they
take to complete? How are
missions presented? How do you
get new missions? What reward do
you get for finishing a mission?
Candy Crush Soda Saga
It is similar game play as Farm
Heroes Saga, but using candy
instead of plants and a little
different setup. The goal is to
collect certain candy types.
Matching many candies at same
time gives bonuses.
100M-500M Menu, menu options.
How are things like settings, about
game or similar non-playing
elements placed? If there are many
types of options or views available
to visit, but not all fit in screen,
how can you show them
temporarily?
4.2 Implementation
This is the main part describing what and how the work was done, and what data was collected to be
analyzed. An attempt to carefully describe the process is made, as an unclear description can reduce
replicability and thus usability for later studies in this research area.
1 Based on data from Google Play, 01-06-2017. These games are also available on other platforms, so numbers are only an
indicator of how successful they are. 2 Nomp also have a web site where you can play, so some portion players have probably not downloaded the app
19
4.2.1 Environment and Measuring
The equipment used for testing, was a desktop computer, with specs “HP EliteDesk 800 G2 DM 35W”
system with a “Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz” and 8 GB RAM.. What should be noted
though, is that the exact hardware used does not really matter, as the tests done compare with other tests
made on same hardware. Thus only a relative measure is obtained, which is also what is needed to be
able to make a comparison to determine which alternative is better.
As for software environment, operating system is Linux Mint 17.3 Cinnamon 64-bit, Cinnamon
version 2.8.8, and browser is Google Chrome v52.0-56.0 (version varies between different tests, but is
same for a certain scenario, which is what is relevant).
Performance measurements will focus partly on frames per second (fps), during a specified time
window. This should be stable, as randomly dropping frames can cause the game to stutter, and is not
pleasant for the player. The other main performance measurement is about loading times for certain
events, such as loading a new episode game or creating a menu page.
The cause of temporary fps instability, may be due to some hardware resource being busy doing
something else at the given time. The software that issues hardware requests can come from the
operating system (OS) itself, or from an application running, such as the game of interest. If the OS is
responsible, then it is not much to do, other than building around that fact. If the application issued the
request however, this can be changed, and optimized. The tricky part is to determine what resource is
busy, and where it is used by the application.
Regarding loading time measuring, it is typically a certain function that is called from which most
initialization is done, and that will be where time measurements will be taken from, which is collected
by the CPU profiler tool in Chrome.
4.2.1.1 Measuring tools
As manual data collection is not possible in this case, some kind of tool is required to measure and
collect the data, from which relevant information can be extracted for final comparisons and analyzes.
Here are the main tools used to collect data for this thesis.
Chrome DevTools – Here mainly the Profilers. Those are a collection of tools that collects
data over a time period. The CPU profiler collects function calls and their execution time,
and some more related information. Memory/Heap profiler collects data about memory
allocation on the heap done by the page, and classifies it in a way. There are some more tools
that may become useful.
Firefox Canvas Debugger – Is a tool for inspecting draw calls3 done by application. Is
useful to detect if any unnecessary operations are done, and if suspiciously many draw calls
are needed to draw a frame. This may be important as draw calls can be relatively expensive
in some cases.
Chrome Task Manager – Is a task manager for viewing resources used by tabs in the
browser. Can see things like CPU usage, memory allocated, GPU memory used and more.
This will be useful when comparing GPU memory needed, for example when testing atlas
packing.
4.2.1.2 Measuring performance
As noted above, the tools collects data, typically more than needed for a specific analysis. The
relevant data is extracted and noted in a separate document, which makes comparisons and conclusions
easier to make later.
3 A draw call is made when one or multiple objects are drawn onto the canvas. Most applications use several per frame to
draw entire scene. Can be expensive if done too many times.
20
Regarding measuring process, it depends on context and what is being measured. A general rule used
is to make several test runs (at least three, often more), so not one result is far off and makes incorrect
conclusions. Moreover, wherever applicable, tests were made with supposedly similar circumstances.
Also, typically at least one instance of the test were made without counting it, to remove possible first-
time initialization procedures. This means that based on a clean page reload, a certain sequence of action
were followed for each consecutive test, to minimize risk of other unrelated issues impacted the test
results.
The timeline view in Chrome were used to look for approximately when performance dips, in fps, or
conversely, peaks of CPU usage. A certain area of interest can then be focused on and examined closer,
to see which part that used a lot of time. Also, the bottom-up view can give a view of usage for the full
recording, and sum up the total time spent on that function. As those long functions are normally a
consequence of added new web content, it can often be quite isolated what the cause was. In same way,
it is therefore easy to tell when those functions are used, so recording its use only once, or a set number
of times, is quite feasible. This ability to know how many times a certain function is used, is how most
time measurements were made during this work. An example of how the bottom-up aggregated time
measuring looks like is shown in Figure 3.
Figure 2 Example of Chrome timeline view
Figure 3 Example of Bottom-up time view
21
Memory usage was measured in two slightly different views in Chrome profilers, the first is the Heap
snapshot, second is Allocation timeline. A third view is also available, Allocation profile, but was not
used in this thesis for the collected data. The Heap snapshot is a single time collection of how memory is
spread out to different parts of web site, as well as what type of things the memory is used for. For
example, the snapshot shows how much array structures use, compiled code, strings, objects, and more.
It also shows the content of each item that were classified to be contained in one of these categories,
although it is often not very human readable and/or searchable in a manual way. The interesting part if to
look if any specific items seem to used vastly more memory than other, and then try to focus on
determining what that item actually contains. The main approach used for in this thesis, is to look on
total memory consumption at specific point, or within certain time window, and then compare it with a
similar measurement after some changes. From there, are relative difference can be seen, even if it is
harder to say any absolute values.
Allocation timeline, is easiest seen as taking several Heap snapshots per second, and showing a
simple chart, that displays bars of currently active/used memory, and greyed out bars of recycled
memory. It has similar view to see total usage of different memory types and their sizes. A main
advantage with this is that it is possible to select a time window, where you know a certain event
happened that is of interest, and can therefore only look at total usage within that area, thus ignoring
other parts that are irrelevant. It can also be used to check memory usage over several instances of
running a function, although that was not done in this work.
The Allocation profile, shares a lot of similarities with the performance timeline, regarding usage and
presentation of data collected. It shows how memory allocations were made over time, in similar fashion
as CPU usage, with higher peaks the more was allocated since last measuring frame. It also has similar
function breakdown as shown in Figure 2, and also the bottom-up view to see total usage on specific
function during whole recording.
4.2.1.3 Code readability and quality
Aside from performance metrics, the readability of the code is an important factor as well. If the code is
easier to understand, it will be easier to debug and understand for possible future developers. Therefore
has the quality of produced code been given thought during implementation, and also attempting to make
it extendable or reusable where applicable.
No extensive measurements was made regarding code quality, due to a lot of new functionality
introduced, thus lacking some comparison reference. One thing that was measured was lines of code, at
few times. It was measured using the program [17], which is a simple line counter that calculates total
number of lines, comment lines and code lines. This could give information about how much spacing
and comments per code lines the code contains, and can compare how much code a certain functionality
uses in comparison to a previous implementation. In this case it has primarily been used to see how the
tested level generation algorithms look regarding code volume.
Figure 4 Example of Allocation timeline
22
4.2.2 Level generation
When this thesis started, there existed a method to create levels layouts. It should be noted that the
created layouts do not yet contain actual cards with numbers; it is more like a grid which have filled and
unfilled spots. This functionality needed a refactor as it had grown too large when more episodes were
added, as each grid configuration were made manually, in order to avoid unwanted layouts. One rule that
stakeholders wanted was that all card spots were connected to another, at least via a corner. Furthermore,
it should be easier to add more layouts, and also easily view how a layout in the code corresponds to a
layout in the game. The current system has fairly simple view how the resulting layout would be, but due
to code structure, it was not that easy to add another layout, also it contained a lot of code duplication.
To address these issues, a new system with clearer separation between code and layout data was
made, by using a separate file for storing layout information, and a code part to read this and provide
interface to get an appropriately sized layout.
In order to get a better comparison and have more variety in options, as the mentioned system still
resembles a lot of similarities with the original implementation, a third system was created. This is more
based off generating layouts on demand, and does so randomly, thus not being locked to selecting a
random one from a predefined set, which both previous ones does.
All three algorithms were then measured, with respect to execution time, memory consumption and
code quantity. Notes on readability was also taken. Performance measurements were done according to
section 4.2.1.2, using Chrome DevTools, and code as 4.2.1.3.
4.2.3 Menu pages
There was a plan to add more episodes to the game than currently existing. As the screen can only hold
at most nine episodes at a time, without reworking that structure, something needed to be added to fit in
the new episodes. There were some ideas how to solve this, but none evaluated nor thought through. The
goal was to be able to show more episodes without changing the structure too much or scaling the
images down. Eventually a solution resembling similarities with many mobile devices operating systems
was chosen, partly just because it shares many similarities; it would make a natural and already familiar
interaction for players.
There are some options and decisions to make regarding implementation of this, for example whether
or not neighbor pages should be loaded when changing to then, or pre-loading them and store in
memory. Some measurements comparing such things were made, to see which way would be the overall
best option.
23
The measurements were taken regarding loading times needed to load in/out pages, and how much
memory pages needed when loaded, which can be compared to find whether it is better to load in/out
pages or keep them in memory. The memory measuring tool best suited for this task were the heap
snapshots, as the goal was to measure memory in a static environment, not measuring the highly
temporary fluctuations happening when changing page. A reason why memory usage peaks were not
measured, is because that can vary a lot between different tests, as it is not possible to predict when the
garbage collector will be invoked to clean up the resources and components making the old page. It is
also not possible to determine exactly when memory will be allocated and given to application to hold
the content of new page either. Therefore, it is likely for pages to co-exist for a short duration, but cannot
be certain of it. It can also happen that parts of them co-exist, but not complete pages, and so on. The
importance of knowing peak memory usage would rarely be of interest, as it would take some very
special circumstances for the device to run out of memory.
4.2.4 Atlas packing
Having a lot of images for a game or any graphical program, is very common. What is also worth noting
is that changing textures on the GPU often, takes a lot more time than loading a single larger texture.
That still needs to be changed from time to time, but in general significantly less than single textures.
This is what atlases are made for, they are a larger image with a collection of smaller images puzzled in,
together with a data file containing information about the images positions, sizes, names and more.
Figure 5 Example of menu page
24
Phaser supports parsing and interpreting these atlases in a convenient way, as long as the developer
knows which image belongs to which atlas file. However, if the atlas is not known, it would require to
get all atlases and try to retrieve the desired image from each, until it is found, which would clearly be
inefficient for most cases.
The goal of using atlases, are several things. First, it is to pack images so they can be loaded into
GPU memory simultaneously so they can be drawn in same draw call. Secondly, if atlases can be
compressed in some way, for example to PVRTC format, it could potentially speed up loading on
supported devices notably, while using less memory. Lastly, it is desirable that adding new images to the
collection would be a simple as possible. This would mean that recreating atlases and the data file would
need to be somewhat automatable, but most challenging would be to find a way to dynamically load
atlases, since if new images are added, eventually it will not fit within a set amount of atlases, and
therefore would need to be added manually. Investigating in what options Phaser provides in its API, and
what could be done regarding atlases using some external tools, would be needed.
4.2.5 Texture compression
As noted earlier, GPU memory on mobile devices can be somewhat limited at times, and another
technique to reduce that is to compress images into a different format. Since iPads and such may be a
large market for this game, and they natively support PVRTC format, it seemed like a good idea to try
this. “All iOS devices support the the PowerVR Texture Compression (PVRTC) format […]”, this
comes from Apples best practices guide when working with textures, which shows they support PVRTC
on all iOS devices [18].
To compress images to this format, a special formatting software is needed. The creators,
Imagination Technologies Limited, of the compression format also have a tool which can do the
compression, called PVRTexTool [19]. In this case, the command line version was used, by making
another script to simplify the usage of the tool.
This was later abandoned, because the game needs to run in WebGL mode to use this technique,
which was not viable, see section 4.2.7 below.
4.2.6 Pack file loading
While atlas packing is a good idea, not knowing exactly how many images to load in the program is an
issue. There are solutions to this, but giving that we are dealing with a web site basically, such things as
Figure 6 Atlas example and atlas data code snippet
{
"meta": {
"image": "atlas1-1.png",
"size": {"w":2048,"h":2048},
"scale": "1"
},
"frames": {
"progress_back": {
"frame":
{"x":1979,"y":1899, "w":20,"h":8},
"rotated": false,
"trimmed": false,
"spriteSourceSize": {"x":0,
"y":0,"w":20,"h":8},
"sourceSize":
{"w":20,"h":8}
},
"check": {
"frame": {"x":1825,"y":1,
"w":194,"h":150},
25
checking file system in runtime is not possible. However, another approach is available through Phasers
loading functionality. It has support for reading a json file, structured in a specific way, which defines
assets to be added to loading queue. This removes the need to manually add known assets by name
within the game, thus making the process easier to adjust to dynamically changing number of assets. As
the pack file can be recreated whenever the asset collection changes, it is a suitable option for the atlas
problem.
The way it was used here, was to create yet another script, which finds the atlases with accompanying
data files, and building the json file with this data. It is named appropriately, so the game loading can
always find the pack file without changing.
4.2.7 WebGL or Canvas
Phaser games can use different rendering modes for their games. The two basic versions are WebGL and
Canvas. WebGL is a version of OpenGL ES made for the web, using HTML5 Canvas element [20]. It
has support for GLSL shaders, and works at fairly low-level to produce graphics for the GPU.
Canvas mode is instead drawing directly to the HTML canvas element, thus putting more load on the
CPU to make certain calculations. Both of these versions were tested on the desktop environment, and a
mobile device. It quickly became clear that WebGL did not work well on the mobile, as the fps were
significantly worse compared to Canvas. So later decisions bases off that Canvas mode is used, which
removes potential benefits from shader based manipulations.
4.2.8 Medals
When a player have won an episode, it changed into highscore mode, where the player should get as
many correct answers in a row to increase score. To extend the experience and provide some more
options to gameplay, some additional mode would be needed between unlocking episode and starting
highscore mode. Ideas about introducing some kind of medals or colored badges, to collect, was thought
of. Eventually a medal approach was chosen for implementation test, where player would play progress
towards first medal in similar way as towards unswirling (see following chapter) episode image, except
removing the unswirling animation.
4.2.9 Winning badge and medal
The goal when playing an episode, is firstly to recover the original image. The image starts in a swirled,
or twisted phase, see Figure 7, and is gradually unswirled. This effect already existed when this thesis
started, but has been reworked since. See Runtime image swirling about these changes. Additionally,
when the badge is fully completed, after the unswirling, the badge bounces towards the center while
scaling, to further enhance the visual cues of finishing something.
Winning a medal is somewhat similar to badges, a window is pulled down with an empty spot for a
Figure 7 Swirled (left) and unswirled (right) episode badge
26
medal. The medal is then moved and scaled in to fit the spot, thereafter a small sparking fireworks effect
in the medal color is shown.
4.2.10 Runtime image swirling
As mentioned above, episode badges starts in an swirled state, to later be unswirled as the player
progresses through the episode. To do this effect, an image of each badge in multiple degrees of
swirliness were saved. Originally each badge had 25 images for this purpose, later decided not quite as
many were needed and reduced to them 11, as the difference between two were generally quite small.
As this uses a lot of memory still, a different approach do solve this was investigated. If there would
be a way to perform this swirling effect live, it would remove the need to storing multiple copies of same
base image.
4.2.11 Player statistics
To give players a greater feeling of them making progress and achieving something, and sometimes just
as interesting data, showing statistics of the playing can be used. For Entanglement, this could mean win
amount or xp, time played and what episodes are completed or how many medals that have been
collected. A prototype implementing this was made, with some inspiration from Nomp, as noted earlier.
4.2.12 Menu UI improvements
Along other features and additions made, some changes and improvements have also been made to the
UI of the menu. The menu options have been placed on an extendable slider, instead of being thrown out
loose on the screen when activated. This should make it clearer to find and see.
A small animation loop was added to albert and his text, to make the menu feel a little more alive.
Also makes it somewhat clearer that they actually are buttons and not just decorations.
The text and progress bars on episodes have also been tweaked a bit in size. The progress bars also
use two scaled images now instead of drawing the bar using graphics.
Various other small tweaks have been made as well, partly due to needing to fit in xp text.
4.2.13 Missions
A new feature that involves progress outside of a particular episode was a notable addition that were
thought to give the game an extra element of interest, that would help players stay interested and keep
Figure 8 Menu options slider, during rolling out (left) and when done (right)
27
playing the game. Many other games have similar things, sometimes as achievements that can be
fulfilled once, and other have quests or missions that can reoccur, possibly harder or longer than last
time. An implementation for the last approach was made, to see if this kind of feature would make the
game better.
4.2.14 Creating episodes
When this thesis started, episode settings were made using a json data file. There things like number
intervals and score needed to win the badge can be set. Also the game mode of the episode is set there,
which can be used to gain variations in game rules for an episode. One problem with this way, is that
every time the game could vary depending on game mode, one need to check which option to use, or
how to act. And since these things are spread out on many places, adding new game modes can be a bit
tedious and easy to miss something. Also if too many modes are made, it may become hard to read the
code. What else should be noted, is that the old solution was fixed on the fact that players always get one
point per victory per game. It also had no way of having mode specific interactions to run when certain
things happen, for example when player selects a card or wins a game. A desire to remake this into a
more flexible system, that allows easier and more customizable game modes, came up.
4.3 Evaluating results
Since this thesis has partly focused on improving performance and/or flexibility of a system, and
partly developing new features, the type of results varies. For performance improvements, measurements
will be analyzed and if necessary weighted between each other if comparisons favors different
implementations depending on what aspect is looked at. In general, readability of the code has large
influence, although frame rate needs to have some minimum threshold, as that is more important for
players in the end.
28
Chapter 5 Results
5.1 Performance measurements
A part of this thesis involves improving performance of existing systems and implementations, and to
find out whether or not that has been achieved, measurements were taken before and after changes. In
the following chapters, results and measurements of different implementations are presented.
5.1.1 Level layout generation
As noted, the old level generation algorithm, called create_random_grid hereafter, was a bit hard to add
more layouts to, so some improvements to this aspect were needed. To do this, a new system which was
based on similar idea, was implemented.
The new system used a algorithmic part and a data part. The algorithm reads the data, and depending
on parameters from episode settings, it selects appropriate layout, randomly if several layouts fits in.
This was also how create_random_grid behaved, but now done in a more generic way. The data can be
compactly formatted and just as easy to read as before, also order of layouts added does not matter,
which it did before. This system will be called gridGenerator hereafter.
The third solution mentioned before, removes the hardcoded layout data altogether and generates
layouts randomly. A condition on layouts was that all cards should be connected to each other, at least
via a corner, which was easily fulfilled when manually creating layouts. In order to not break this
condition, a simple pathfinding algorithm was used to check generated layouts so they were valid. By
generating layouts like this, the number of layout variations increases vastly, but is likely to take more
time to compute than just selecting a preconfigured combination. This was called
randomLevelGenerator.
The game boards are generated in a few steps. The first step is to create a layout, or grid, with slots to
put cards into. This is done using one of the above described layout generation algorithms, which
randomly selects or creates one, possibly with some parameters. The different versions of generation
algorithms were measured, as said previously, both in terms of performance (time to create a layout
based off given parameters) and code quality (how many lines of code, and if possible layouts were easy
to see). Here follows comparison tables of the different implementations.
Table 2 Layout generation methods information
create_random_grid gridGenerator randomLevelGenerator
Maximum grid size
24 24 30
29
Approximate maximum number of
possible layouts
240 320 More than 100000
How layouts are created and
additional notes
Original solution to
create layouts. Selects a
layout randomly among a
set of predefined layouts.
Contained a lot of code
duplication which made it
a bit hard to understand.
Reworked version of the
original, uses a separate
file to store hardcoded
layout variations, for
easier changing
(add/remove/modify).
Uses only a small logic
file to read those layouts
and select one. This takes
~16 ms to setup, once
during game loading. It
can then much faster be
accessed later on.
Randomizes size of the
grid. Then it tries to fill it
with appropriately many
card slots, depending on
size, at random positions. It
checks if the filled grid
contains separated parts or
not, and retries if it does,
due to requirements made
on the algorithm.
How to view layouts
Can be seen easily how a
certain layout looks like,
but not that
straightforward to see
when it can be selected.
Also hard to see overview
of available layouts.
Can be seen easily how a
certain layout looks like,
a little easier to see how it
can be selected, but
harder to find all possible
variants at this size and
card count. Much easier
to get an overview.
Cannot view layouts, but
not needed as all are
included.
How to add layout
Copy relevant code part
and change relevant parts
to get a new variant.
Depending on if a similar
layout already exist or
not, is varying it becomes
varyingly easy to add the
desired layout. Then add
layout definition (or base
it off existing one).
Add the layout definition
(or copy another one and
change it).
Cannot add specific layout
as all valid can already be
randomly selected. Can
easily change maximum
grid size though.
Table 3 Layout generation methods, measured execution time of 10000 consecutive executions of the
function
Approximate
longest total time for one call (ms)*
Accumulated total time (ms)
Average total time (ms)
Times faster/slower
relative to original
create_random_grid 7.4 52.5 0.0053 1
gridGenerator 1** 3.1 0.0003 16.9
randomLevelGenerator 10 369.7 0.037 0.14
* This is measured by looking at timeline view and checking largest block and the time noted there. Is
generally rare, but runs that uses significantly more time than the average does happen
** Chrome profiler does not seem very accurate sometimes at very short timings, so this may be slightly
lower or higher
30
Table 4 Layout generation methods, measured heap memory usage during 3 tests
Average approximate heap memory
allocation (MB) Percentage of memory used
relative to original
create_random_grid 1.27 100%
gridGenerator 1.47 116%
randomLevelGenerator 1.4 110%
In addition to performance measurements of these methods, the text or code amount for each method
was also calculated. It is important to note that the majority of lines in the first two methods are from
layout descriptions, and not actual code logic. Those also written to be easier to read for humans and
therefore takes up extra lines from that.
Table 5 Layout generation methods, code lines of the methods
Blank lines
Comment lines
Code lines
Total Notes
create_random_grid 125 138 2044 2307 A lot of the code lines are layout
definitions, but mixed up within code.
gridGenerator 27 19 2209 2255 Here 2122 code lines comes from
layouts definition file.
randomLevelGenerator 33 26 110 169
5.1.2 Atlases and images
Loading the menu or game instance takes some time due to resources need to be changed and UI
needs to be created and such. As packing images into atlases instead of using loose images is supposedly
better most of the time, that was implemented, because it originally used loose images and some
spritesheets. Spritesheets are just a specially formatted atlas, so likely not that much difference from that
part, but here the overall loading performance is measured.
What is measured is firstly the time that the custom loading function is running, excluding things that
happens within Phaser framework, browser related actions and similar. It was measured using Chrome
Profiler tools for CPU. The transitions measured were the following:
Changing page in the menu – Each test was done by swiping to last page (2 swipes), then
back to first. This was done three times in a row, with a total of 12 pages changes. This is
because a page change will possibly load off a page and/or create new. In this test, it will
alternate between create and destroy, as pages that are neighbors are created, and when they are
not neighbors anymore, they are destroyed. Creating menu – It was measured when returning to the menu from a game session, not from
game start, although should be equivalent. This is because of easier repeatability. Each test did
10 menu creations.
Creating game – Similar to menu creation, each test was done 10 times, from the menu screen.
It should be noted that this may vary depending on size of generated game board, but the sample
size should be large enough to average this out. By checking Table 3, it can be seen that
generating layout is only small part of loading a game.
The different setups measured, with respect to the above mentioned loading, were as follows:
Individual sprites and spritesheets, neighbor pages drawn offscreen – Drawn offscreen
means that if a menu page has been loaded once, it is never destroyed (but new ones will
not be created as the existing will be reused instead).
Atlases, with extra generated spritesheets, offscreen draw – All loose images are packed into atlases. Extra spritesheets mean that the spritesheet is also packed into an atlas, but
during loading is extracted and saved as separate image in memory, to enable built-in use of
31
spritesheet mechanisms for animations. This means that the spritesheets are effectively
doubled in terms of memory.
Atlases, extra generated spritesheets, no offscreen draw – Same as previous, except that
pages that are not neighbors are destroyed, and when becoming neighbor again, they are
rescreated.
Atlases, not extra spritesheets, no offscreen draw – Same as previous, except that the
extra spritesheets are replaced by functionality to use the images directly from the atlas,
thus not needing to duplicate them.
Table 6 Atlases and images, loading time
Average execution/loading time (ms)
Setup Individual sprites and spritesheets,
with offscreen draw
Atlases, with extra
spritesheets, offscreen draw
Atlases, with extra
spritesheets, no offscreen draw
Atlases, no extra spritesheets, no offscreen draw
Change page 4.6 5.8 5.4 5.7
Create menu 14.8 14.7 14.4 13.7
Create game 12.6 13.4 12.3 13.4
To further test the differences between the setups, memory usage during certain states were measured.
To measure GPU memory, Chromes Task Manager was used, checking the GPU memory stat.
Both menu and game while idling was measured, as well as the starting sequence before final load at
menu, and a full menu page creation (that is a page with nine episodes).
Table 7 Atlases and images, memory usage
Average memory usage (MB)
Setup Individual sprites and spritesheets,
with offscreen draw
Atlases, with extra
spritesheets, offscreen draw
Atlases, with extra
spritesheets, no offscreen draw
Atlases, no extra spritesheets, no offscreen draw
Idle menu 14.2 36.5 38.0 14.6
Idle game 15.2 38.2 39.7 15.7
Idle menu (GPU
memory) 64.0 92.1 92.7 105.6*
Idle game (GPU
memory) 68.4 91.9 92.0 106.1*
Start sequence
7.0 6.1 7.0 6.5
Full page creation
0.5 0.5 0.5 0.3
* Browser version was updated before this test were made, which may have contributed to increased
GPU memory usage. When remaking a previous test with atlases, an equivalent increase can also be
seen.
32
What is also important factor for speed, is how many draw calls are needed to draw the final frame. It is
not a definitive measure, but a good indication of improvement if it reduces, as the environment is the
same.
Table 8 Atlases and images, draw calls
Draw calls
Setup Individual sprites and spritesheets,
with offscreen draw
Atlases, with extra
spritesheets, offscreen draw
Atlases, with extra
spritesheets, no offscreen draw
Atlases, no extra spritesheets, no offscreen draw
Idle menu, full page
76 77 46 40
Idle game, full 4x5 grid
16 12 12 12
5.2 Improved features
In addition to measuring performance on improved systems, some other reworks have also been made,
but not measured for various reasons, mostly due to not being relevant aspect of it.
5.2.1 Episode progression
The resulting implementation of progression rewards for winning games in episodes is, as mentioned
earlier, firstly to unswirl the episode badge. When that is done, the player can continue playing the
episode to earn medals, bronze, silver and gold. The player also receives general experience points (xp)
when winning games, which is used to unlock menu pages, see 4.2.3 and 5.3.2 for more. The medals can
both be seen per episode while playing a game of that episode, or looking beneath the episode badge in
the menu. A total summary of medals collected can be seen in the statistics page, see 4.2.11 and 5.3.4.
5.2.2 Badge swirling
Originally, when this thesis started, badges were swirled offline using a tool, and saved as images. As
noted, this did of course use a lot of memory, even if each badge image was not very large (230x230
pixels). The idea of performing the swirling in runtime, was possible since Phaser supports pixel-based
image manipulation. The main issue is then that the CPU gets a lot more workload when this is done.
However, the implementation done to swirl the badges, did not seem to affect performance in any severe
way. An extra bonus from doing the swirling programmatically, is that it can be more easily customized
and altered for different scenarios.
The way it works is by running an algorithm that twists the image a bit, first at an unswirled version
of a badge. The result replaces the current image instance, and the algorithm is applied again after a short
delay. This way an animation is created, that is similar to the pre-generated set. The algorithm could be
made more or less complex, in this case, in short, it takes a pixel, rotates it an angle depending on
distance from center of image, and writes to a new image buffer. When completed, the new buffer
replaces the old one, and Phaser engine will take care of the rest to show it.
33
5.2.3 Creating episodes and game modes
A rework of the game mode system was made, which now allows game modes to define custom rules for
the game, and be able to store progress done on the episode in its own way. It still saves the previous
scores and number played and such, for xp and statistics purpose. But the game mode can override how
progress is measured, and whether or not to trigger events when player selects/deselects a card,
loses/wins a game and such. A default implementation was also created, which has some flexibility in it,
enough to allow re-creating the existing game modes with minimal effort. Extending the default
implementation, and thus adding more possibilities to all game modes, is made to be relatively simple.
Transferring an existing implementation from one or several places to be part of default game mode,
would likely be harder than adding the function itself.
The new system resulted in a more complex yet flexible way of making specialized behaviors. By
overriding the default functionality, it is possible to make quite complex game modes. Although its full
potential has not been used yet, enough parts have been tested to see it should function as intended.
The main part left that may need further developing, is the UI customization. The current solution is
to allow game modes to control the two progress texts, which is sufficient for most modes.
5.2.4 Asset loading
The asset loading was made as outlined in sections 4.2.4 and 4.2.6. Together with the scripts made to
make use of these, it was possible to make it very quick and easy to add a new image to the game, once a
slightly user-specific script was setup (it is user specific because it needs to know where user install the
texture packer and where the project repository is located). It runs the general scripts using the
parameters needed, which are the ones actually performing the tasks.
Put the image somewhere inside the assets folder (excluding atlas folder), invoke the above
mentioned script and wait for it to finish. Then one can start using it, by referring to the name of the file,
without file extension. Having this process very small and easy, have been very useful during the
project, as it allows to quickly add new images and make small modifications of existing ones.
5.3 New features
In the following sections a series of new features implemented are presented.
5.3.1 Atlases
There are several different tools to create atlases from images, but for Entanglement, the image assets
were packed using the Gamefroot Texture Packer [21]. The reason why this was chosen, was because it
had packing options which were needed for both the compression algorithm, and some that were needed
for simplifying build process and usage in application. The important options were the following:
Guaranteed power-of-two atlas size
Guaranteed square atlas
Setting max width and height of atlas
Naming the atlas file and output path
Custom format of atlas data file, in this case a slight variation of the default json version.
This tool will create the needed amount of atlases, depending on images to be included. The
command line version of the tool were used, to make it usable from a script and easier to set the options
noted above. The images were given as arguments, in form of file paths, to the tool. It should be noted
that texture compression had not been tested at this point, but if it would have been known that
compression would not be used, the solution approach might have been done differently.
Using atlases resulted in a faster application due to lower loading times. But adding new images is
not quite as straightforward, as expected. Every time a new image should be added, all or some atlases
34
need to be recreated, and since every image path need to be added to the texture packer command, this
quickly becomes a tedious manual process. To avoid the need to manually recreate the atlases all the
time, a script was made. It can take a given directory and some parameters and create atlases for all
images found.
At this stage it required five atlases at size 2048x2048 to hold all images (with a slightly smaller last
atlas). It should be noted that the number of offline generated images had already been reduced from 25
to 11 per episode. From these five atlases, the first two held miscellaneous game images, and the last
three episode swirl images.
Later on, this process was extended to be able to group certain images together into one (or more, if
needed) atlas(es). This was due to episode images ended up mixed in the atlases, so when doing a
swirling animation, the texture was needed to be changed often, because the swirled images were not
grouped into same atlas. A similar issue was also noted in the menu, the images used for episodes and
other elements, often ended up in different atlases, making them less effective than intended. Therefore,
another script was made to handle image grouping for the atlases. Due to how the previous script was
implemented, that ran the texture packer on all images within a specific directory, the grouping script
made subdirectories of atlases needing to be grouped. It can then create atlases for each subdirectory. By
then controlling the name of created atlases, it can make atlases with unique names, that would
guaranteed contained images that should be put in same atlas.
A final note on this approach, is that after doing runtime swirling, only two atlases were needed for
holding all images. The gains of having atlases are usually greater for larger quantities of images, but
such things as draw calls are still notable effect. But other performance benefits are less notable.
5.3.2 Medals
The resulting medal system consists of three medal types, bronze, silver and gold, and require increasing
effort to achieve, with bronze being easiest and gold hardest. Currently, the actual gameplay difficulty is
unchanged. They are also achieved in the same order, and it is the amount of wins between each medal
that increases, so in fact gold required more than double total win count compared to bronze, on a
specific episode.
Which medals that have been achieved for each episode, is shown by hanging the medals over the
progress bar, both in menu screen and in game. This also groups progress indicators closely together
visually, which may make them easier to understand.
5.3.3 Menu pages
For the system for navigating in the menu to reveal more episodes, the initial idea was to have a scroll
functionality, where you scroll up/down to view more. This seemed nice at first, but when thinking of
how the game would scale with a lot more episodes to be added, it became clear that it would be rather
inconvenient to find a particular episode you wanted to play. Another aspect was that episode assets,
images and text and such, would need to load for everyone available, or the scrolling would either seem
to lag while new assets are loaded, or would be a longer loading at the beginning. It would also need to
store all assets in memory, which may become impossible for low-end mobiles and tablets to cope with.
After a discussion with stakeholders, a solution to make a page based system was implemented. The
player uses swiping to change page left and right, which resembles similarities to mobile platforms, thus
likely making the interface easier to learn. Also, if made appropriately it would allow to skip pages that
you know does not contain the wanted episode, and would also enable to load only needed pages, and
recycle when done with them.
To not have too high impact on memory, especially the graphics memory, a system to be able to load
in and out pages was integrated, so only the currently visible page and its neighbors were loaded at the
same time. When player changes page, the new neighbor is loaded in, and one of the old is loaded out.
35
What should be noted about this system, is that due to later changes and features, the impact of this
will not be noticeable until a larger set of episodes are added. This is because the episode images are
grouped into an atlas, thus making it possible to draw all episodes in same draw call. The removal of
pre-swirled images is also a significant factor when combined with the atlas.
5.3.4 Statistics
As the player progresses through the game, some statistics are collected, like playtime per week, xp
gained, medals collected and what numbers have been played. These can then be viewed in the statistics
page, which is meant to give a more overall picture of total progress made. Bar charts are used to get a
more visual feedback of some statistics, as too much numbers can be harder to understand, especially for
children, which are the target group of this game.
One thing that was lacking when this thesis started, was the ability to view your progress in a
summarized way. Also there were no information stored about time played. The implementation done
now shows a summary view over played time and xp earned during this week, and amount of total xp
earned so far. In addition to the summary view, two specialized views are available, where the first
shows a bar chart of played time for each week. The second view shows what sum numbers the player
have won games in, which is not affected by episode selected, see Figure 9 above for example. The data
is stored among rest of player information in the web browsers local storage.
Figure 9 Example of a bar chart from statistics
36
5.3.5 Missions
The mission implementation mentioned in section , works as follows. The player receives missons up to
certain cap (currently 3), and when a mission is collected, a new mission is added randomly from a pool
of available mission types. In the menu screen, there is a button to click to drag down the mission screen,
which shows active missions. It is also here the player can collect finished missions by clicking on the
star to the right. If the mission is not finished yet, a progress indicator will show instead of the star, so
player can see how far they have left to complete that mission. The stars collected here, adds up to a total
that can be viewed in statistics view later.
Examples of mission types implemented include collecting odd/even or specific numbers, winning
time episode within a shorter time limit and collecting a number of medals of certain type.
Creating more mission types is relatively easy, once learning how the system is built up. It supports
activating custom event triggers when certain things happen, like selecting/unselecting card,
winning/losing game and more. By also having a default implementation, the mission creator only need
to make functions that differ from the default version. There are also other functions that can or should
be overridden, like getting custom texts for description and progression.
Figure 10 Statistics page, summary
view
37
The mission system does also have a simple way of saving custom data needed for that specific
mission. By assigning a variable to the mission instance, it will be found during save process, and saved
along with rest of mission information. Minor note to this, is that it is up to creator to make sure that the
data can be converted to a string in a reasonable way, without becoming too long or other issues.
Figure 11 Example of mission screen
38
Chapter 6 Discussion
6.1 Performance, feature and code improvements
A part of this thesis has focused on improving performance and overall code quality, and also extend or
rework existing systems. Some of these changes has been measured, while other are more code based
changes or reworks and thus not eligible for any performance measurements and such. In this section
this work will be discussed and what solution the game ended up using, as well as why it was selected.
6.1.1 Level generation
The difference between the original solution that existed when this thesis started, and compared to
current used solution, is quite significant in several ways, as mentioned in previous sections. Completely
randomizing the layout opens up vastly more possible formations than one ever could write down by
hand. And making a program that generates all these variations would result in such large collection, it
would likely not be better than generating the solution in runtime. Giving the fact that this generation is
done during a loading sequence, means that it never affects performance in a significant matter. By
looking at the tables, a maximum of 10 ms (on the test machine), indicates that this process is almost
insignificant compared to all other things that is done when changing to a game instance. This results in
that the randomized version gives more possible layouts at no cost.
To further add to this, the amount of code needed to do respective generation method, is very notable.
Even though the gridGenerator is a tiny bit shorter than randomLevelGenerator, when adding the layout
definition file it falls short, because it inherently suffers from same issues as the original
create_random_grid.
When assessing the memory and execution time, it is clear that separating layouts from code and pre-
loading the layouts in another structure for faster accessing, as in gridGenerator, it is significantly better.
Both longest call and average is many times better than create_random_grid, and still having a few more
layouts available. The cost is memory consumption, which increased a bit, but not that much overall,
compared to speed improvements. For randomLevelGenerator, it is several times slower than original
solution on average, but the time for longest call is still reasonably close, although notably worse. In
terms of memory, it also uses a bit more than create_random_grid, but again, not substantially different.
As said above, randomLevelGenerator was selected in the end because it offers a lot more layout
combinations, while being fast enough to do the task in reasonable time window. It is also easier
minimum and maximum generated layout size, as well as approximate ratio between number of cards
and size of board, that is how likely gaps are in the resulting layout.
6.1.2 Atlases
As mentioned earlier, the later versions of the game only needs two atlases to fit all images, with some
room left to spare in the second atlas. And since no texture compression can be used, because it needs to
run in canvas mode, the benefits of grouping the images into atlases diminishes slightly. A major
39
advantage with this way currently, is through the utility used around them, to insert image to the game.
When using the scripts made, they will, as said previously, generate an asset pack file for atlases and
their data file. When named correctly, it results in that the code for loading all images, existing and new
ones, will never need to change. With code that maps image names to their containing atlas and other
help functionality, it is possible to mimic the look of using images quite well compared to using loose
images. So if utilizing made scripts and such, it becomes easier to alter and add/remove images from
asset pool. A downside if of course that atlases need an atlas packing tool to install. Overall, this atlas
version is more convenient in the long run, but takes a little time to setup, compared to using loose
images and adding them manually.
Regarding performance differences, the results show that it is largely the same as individual images,
for memory and loading times, even worse in some cases. The notable benefits are draw calls, which
could be reduced by almost half in menu, and 25% in game. This is because images taken from the same
atlas can be drawn in the same draw call, as opposed to individual images which always requires one
draw call each. On the test machine however, it should be noted that both versions runs are full frame
rate, so it does not make difference there, it may be more notable on other devices though.
Since one of the reasons to convert image loading to use atlases was performance, but the current
state of the game does not benefit significantly from it, it can be discussed if it is worth using still instead
of loose images. As noted previously though, there are other benefits from using the atlas system, apart
from just performance. And if the game grows notably, it will provide a more scalable platform.
Returning to the theory, improving performance of the game to a good enough level, can provide
opportunities to change or add other things, such as how badges are swirled.
6.1.3 Badge swirling
There are several differences between the old pre-swirled badge setup, and new runtime swirled version.
The most obvious is that only one image is required for each badge, thus reducing amount of stored data
significantly. This results in a smaller app size in the, which for most cases is good.
Another factor that benefits runtime swirling, is that it could be totally adjustable for different needs
and scenarios. A consequence is that the swirling can be modified for each episode or other parameters,
if that would be wanted. For these reasons, this is the method to be used in the game forward.
This feature have not been formally tested, but on test machine mentioned in section 4.2.1, it runs at
same frame rate as pre-swirled version. Also when testing on a quite high-end mobile, it runs smoothly.
It is hard to tell if low-end mobiles may have issues with this, as it is a bit CPU intensive, but is likely to
be good enough.
It may seem counterintuitive at first to put more stress on CPU compared to memory, but as noted in
performance chapters in the Theory section, it makes little difference in changes to frame rate and such,
when it is below certain threshold. It would need more testing on lower end devices to see if this swirling
strategy works there too. It should be noted that lower end devices typically have low memory
boundaries as well, so it may be issues doing the other way as well on them.
6.1.4 Game modes
As mentioned earlier, the new game mode system opens up for lot more flexibility and opportunities
when creating new episodes. However, the UI flexibility is limited due to being more complex to handle
in a simple way. And main problem with it, is that allowing full control of game UI can easily open up
for mistakes, thus destroying the designed look or worse. Currently there is no plan to address this
further, but for best experience, having some unique visual elements for each type of game mode would
probably be a good idea. As noted by Fisch earlier, having a good integration between components, are
important for learning games and its teaching content.
One possible flaw noted afterwards with the implementation, is that the code might look confusing at
first, for someone who have not seen it. Although that is hard to tell from my perspective.
40
6.1.5 UI changes
The UI changes made, for most part in the menu, are intended to make the scene feel more alive and
interactive. Small movement help draw attention and could show that they are clickable objects, as noted
by Franconeri and Simons; “Moving objects capture attention because transient activity is given a heavy
activation weight in the central priority map.” [22]. It also makes the game feel less static overall if
adding small animations and effects here and there.
Furthermore, text sizes, button positions and more have been changed to accommodate for new
elements and fit design better. Some of the changes made may have only small impact on its own, but
when adding many together, it makes the game feel more complete and well done, which in the end may
make the game more successful. An important purpose why these changes would be effective and good
to make, is because details in UI are noticeable. And as noted in 3.2.1, having an easy to understand and
learn UI, along with controls that feels natural within the context, are important measures for keeping
players playing.
6.2 New features and their impact
It may seem like it is always a good idea to add new features to an application, but one must consider
various other aspects while doing so. Firstly, it will likely make it more complex and longer time to
learn, as there are more things to learn, also possibly more advanced features and ways of achieving their
intended goal. Secondly, performance must be assessed, if the application becomes very slow due to so
many things that happens, it will lose attention and annoy users, which obviously is not good.
Figure 12 Menu page before (left) and after (right) changes
41
The implementations of features added to this game are intended to not affect performance in any
notable way, and try to use intuitive and common patterns for UI elements and such. It should also
clearly show relevant information to the players.
6.2.1 Menu pages
In order to get more episodes to play in the game, more buttons are needed to click on to load that
episode. There are several possibilities to do this. The first would be to simply scale everything down so
each uses less space, but eventually it will become unplayable, if it is too small. Other approaches
involve view only a portion of them at the same time, and somehow be able to change the view. As
mentioned in section 5.3.2, a scrolling mechanism was planned at first. But as said, that would likely
suffer from performance issues if substantially more episodes are added. Thus a solution where assets
can be temporarily loaded into memory and then discarded is the way to go. And as this game is meant
to be played on mobiles and tablets, it becomes natural to use a similar system as most of them do in the
menu; that is a page based system with a set number of items per page.
This feature has not been tested on users yet, but due to having similar interactions and structure as
they are used to on their device, it is likely to be picked up and understood quickly.
Adding more episodes to the game and making them appear correctly in the menu, is also done
automatically, as the system just reads what episodes are defined and places them in order, adding more
pages if needed.
6.2.2 Statistics
Saving data about playing behavior and such, should be done carefully to not disturb players, and more
importantly, not saving such data that can make players uncomfortable when view it. The data saved
here, is as said, played time, victories per episode and what sums the player has won with. The xp is just
the total numbers of wins, and medals are dependent on wins for a specific episode. By collecting and
presenting these statistics to the player, they can easily view their progress, and could also show off to
their friends if they like to. The play time could also be used by for example parents to see how much
time they put into the game. Maybe they want their kid to play the game for an hour a week to train their
mathematics skills, or maybe to see if they play it too much.
The bar chart over sums won, could be used to see if any sums may be harder or easier to win, it
could also be that some of them are rarer to occur, as they need to be randomized to appear.
6.2.3 Missions
As no tests or user studies has been done using missions, it is hard to tell if they convey a more positive
experience for the player, or is just confusing distraction. Since the game primarily targets children in
lower school (around age 6-9), the game should not be too complex. However, it is believed that adding
this makes an extra fun layer and makes the game feel more entertaining overall. It would need to be
tested to see how it turns out.
6.3 Future work
How this work can be used in future research and development, could be through various ways. As this
thesis have had a few different focuses, it is however less likely to be usable as a whole, and more using
parts of it. The measurement results can be used to show correlations between for example using atlases
versus regular images, when the image count is relatively low. The new features added, show that fairly
complex additions to the game, may still be done efficiently enough to not impact performance in a
notable way.
42
If this work will yield new insights around any subjects around this, is unclear, however as this study
merely uses existing techniques in a specific context, it more confirms how theories and other previous
works have shown.
6.4 Work in wider context
As Entanglement is a game designed for younger children, with aim to teach them some mathematic
principles, it seems positive from many aspects. But the fact that playing mobile games too much is not
healthy, some thought and care should be taken. You want the children to come back to the game and
like to play it, but not unreasonably much, to not impair their health nor social wellbeing. Giving
positive and constructive feedback on playing needs to be designed in an easy to understand way,
considering the targeted age of players.
Furthermore, when adding new content and features, one must realize that it may not always become
a better game, and that it will likely be received differently by different players. So even if developers
and some testers believes the game is more fun or better in some way, it does not mean the average
player thinks the same. So listening on feedback from users would be a good idea to get some hints if a
certain design needs a change or not.
43
Chapter 7 Conclusions
There is a lot of things to think about when designing and implementing a mobile game. The UI is an
important part, to design and create content and layout elements with touch interaction and relatively
smaller screen sizes in mind. Just as important, if not even more, is to have efficient code structures and
lightweight functions that altogether does not require very powerful hardware capabilities to run
smoothly. Even if mobiles are advancing rapidly nowadays in speed and graphics performance, they are
still behind most everyday desktop environments. And many people still use older phones and tablets, so
performance needs to be considered when creating this type of mobile games.
Here we have seen that certain choices and implementations are better than others, but often at
different areas. One might be overall faster, but require more memory or more complex code, or limited
functionality in some other way. Using different rendering modes, such as WebGL or Canvas, also bring
their own advantages, which needs to be compared to choose the overall best option.
It has also been shown that new major features can be added, without impacting performance
notably. Also that refactoring existing solutions is sometimes necessary to be able to expand certain
features, as shown with game modes and to certain extent also medals.
44
References
1. Phaser [Internet]. [cited 2017 Jan 6]. Available from: https://phaser.io/
2. Bäck J. Utveckling och optimering av 2D spel i Javascript med ramverket Phaser.io.
Linköping University; 2016.
3. Alm J. Utveckling av 2D matematikpusselspel med Phaser.io. Linköping University; 2016.
4. Öhrström F. The Indie Developer ’ s guide to immersive tweens and animation What you
need to know as a programmer to animate. Linköping University; 2016.
5. Ke F. Computer-game-based tutoring of mathematics. Comput Educ. 2013;60(1):448–57.
6. Fisch SM. Making Educational Computer Games “Educational.” In: Proceedings of the 2005
conference on Interaction design and children. New York: ACM; 2005. p. 56–61.
7. Clanton C. An Interpreted Demonstration of Computer Game Design. In: CHI 98
Conference Summary on Human Factors in Computing Systems. Los Angeles, California,
USA: ACM, New York, USA; 1998. p. 7–8.
8. Korhonen H, Koivisto EMI. Playability Heuristics for Mobile Games. In: Proceedings of the
8th conference on Human-computer interaction with mobile devices and services. Helsinki,
Finland: ACM, New York, USA; 2006. p. 9–16.
9. Chen J. Flow in Games ( and Everything Else ). Commun ACM. 2007;50(4):31–4.
10. Ryan RM, Rigby CS, Przybylski A. The Motivational Pull of Video Games : A Self-
Determination Theory Approach. Motiv Emot. 2006;30(4):344–60.
11. Deterding S. Gamification. Interactions. 2012;19(4):14.
12. Taylor B, Dey A, Siewiorek D, Smailagic A. Using physiological sensors to detect levels of
user frustration induced by system delays. UbiComp ’15 Proc 2015 ACM Int Jt Conf
Pervasive Ubiquitous Comput. 2015;517–28.
13. Nah FF-H. A study on tolerable waiting time : how long are Web users willing to wait ?
Behav Inf Technol. 2004;23(3):153–63.
14. Curran K, George C. The Future of Web and Mobile Game Development. Int J Cloud
Comput Serv Sci. 2012;1(1):25–34.
15. PVRTC: the most efficient texture compression standard for the mobile graphics world
[Internet]. [cited 2017 May 22]. Available from: https://www.imgtec.com/blog/pvrtc-the-
most-efficient-texture-compression-standard-for-the-mobile-graphics-world/
16. Trello [Internet]. Available from: https://trello.com/
17. Count Lines of Code [Internet]. [cited 2017 May 12]. Available from:
https://github.com/AlDanial/cloc
18. Best Practices for Working with Texture Data [Internet]. [cited 2017 May 22]. Available
from:
https://developer.apple.com/library/content/documentation/3DDrawing/Conceptual/OpenGL
ES_ProgrammingGuide/TechniquesForWorkingWithTextureData/TechniquesForWorkingW
45
ithTextureData.html
19. PVRTexTool [Internet]. [cited 2017 May 2]. Available from:
https://community.imgtec.com/developers/powervr/tools/pvrtextool/
20. Khronos WebGL [Internet]. [cited 2017 May 4]. Available from:
https://www.khronos.org/webgl/
21. Gamefroot Texturepacker [Internet]. [cited 2017 May 2]. Available from:
https://github.com/Gamefroot/Gamefroot-Texture-Packer
22. Franconeri SL, Simons DJ. Moving and looming stimuli capture attention. Percept
Psychophys. 2003;65(7):999–1010.