Optimization of Graphical Performance in a Motion- Based Web Game – Improving Design and Implementation of a Game Mea- Sured by Frame Rate

Linköping University | Department of Computer Science Master thesis, 30 ECTS | Datateknik 2017 | LIU-IDA/LITH-EX-A--17/036--SE

Optimization of graphical performance in a motion- based web game – Improving design and implementation of a game measured by frame rate

Oskar Therén

Supervisor : Aseel Berglund Examiner : Henrik Eriksson

Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se 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 ﬁnns lösningar av teknisk och admin- istrativ 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 sam- manhang som är kränkande för upphovsmannenslitterä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/.

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 circum- stances. 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 con- sent 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 Uni- versity 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/.

c Oskar Therén Abstract

This thesis uses Chrome Timeline tool, Firefox Canvas Debugger and an FPS module to evaluate performance issues in a motion-based web game built with the framework Phaser. For each issue an explanation of how it is found and a proposed solution is given. The game that is the basis of this work, gains input through a WebGL-based camera module that uses shaders to interpret the data. Some solutions might be speciﬁc for this particular project and some may be more generally applicable. A few pointers are given to what can be graphically demanding when developing in JavaScript. The game has different themes and features that are further developed which is done from a performance point of view, there are in total eight different improvements that are discussed. The used tools and metrics are further evaluated e.g. the Timeline tool is considered a useful tool for web developers though it has some drawbacks related to WebGL. Acknowledgments

I would like to thank Aseel and Erik Berglund for their help during this thesis work. I would also like to thank my family, classmates, the people I have worked with and all the wonderful friends i have met during these ﬁve years. Thanks for all the support, without you I would not have ﬁnished this program!

iv Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

List of Tables 1

1 Introduction 2 1.1 Motivation ...... 2 1.2 Aim...... 2 1.3 Research question ...... 3 1.4 Delimitations ...... 3

2 Background 4 2.1 Themes ...... 4 2.2 Earlier work ...... 6 2.3 Frameworks ...... 7

3 Theory 9 3.1 Related work ...... 9 3.2 Designing motion based games ...... 9 3.3 Frustration without performance ...... 10 3.4 Frame rate ...... 11 3.5 Improving JavaScript ...... 11 3.6 Memory management ...... 12 3.7 Anti-aliasing ...... 12

4 Method 13 4.1 Finding and measuring ...... 13 4.2 Skipping pixels in collision detection ...... 15 4.3 Improving camera usage ...... 15 4.4 Draw calls ...... 16 4.5 Anti-aliasing ...... 16 4.6 Themes ...... 16 4.7 New features ...... 19

5 Results 20 5.1 Skipping pixels in collision detection ...... 20 5.2 Improving camera usage ...... 20 5.3 Draw calls ...... 22

v 5.4 Anti-aliasing ...... 22 5.5 Themes ...... 22 5.6 New features ...... 23

6 Discussion 24 6.1 Results ...... 24 6.2 Method ...... 26 6.3 The work in a wider context ...... 27

7 Conclusion 29 7.1 Future work ...... 29

Bibliography 30 List of Figures

2.1 The Bug game - A screenshot taken while playing the Bug game at its state before this thesis, the white silhouette is the hands and body of the person that is currently moving...... 5 2.2 The Night Theme - A screenshot taken while playing the Night Theme at its state before this thesis ...... 5 2.3 The Winter Theme - A screenshot taken while playing the Winter Theme at its state before this thesis ...... 6

4.1 Screenshots of the two different Night themes...... 18

5.1 Three frames with different spawn rates of bugs and pixSkip values...... 21 5.2 A frame when using camera shaders in phaser, the frame takes 50 ms (mostly GPU-time) that gives and FPS of approximately 20...... 21

6.1 Timeline Tool - A screenshot of the timeline zoomed in on two typical frames . . . 27

vii List of Tables

5.1 FPS dependent on pixSkip values with ten times higher bug spawn rate than usual...... 20 5.2 FPS dependent on how the camera is handled. ThreeJS was the original implementation...... 22 5.3 Amount of draw calls and FPS before and after the remake of the user interface. . . 22 5.4 FPS with and without anti-aliasing...... 22 5.5 FPS dependent on the themes...... 22 5.6 FPS dependent on the themes...... 23 5.7 FPS dependent on pixSkip values during explosion mode and without as a reference...... 23 5.8 FPS during and outside of mushroom rush...... 23

1 1 Introduction

The purpose of the web has during its existence been rapidly changing. Web pages have in a few years gone from being limited to basically being formatted text to being able to render advanced 3D animations. When developing a web application there is no need to take into account the operating system. The user will be able to access the application on any device connected to the Internet without the need to install anything. The hardware on modern devices have gone so far that even though the performance is worse than a native application the beneﬁts are in many cases worth it and the the performance difference does not even matter. One kind of application that might be one of the furthermost from being replaced by a web application is games. A reason for this is that in many games the graphical performance is a too important aspect, lag in a game can both make the player loose focus of the current task in the game and reduce the overall experience of the game. This is where this thesis comes in, it is an attempt to get good performance from a web game, let the user get the beneﬁts from a web game while reducing the drawbacks.

1.1 Motivation

When joining in on an existing software development project it is important to be able to quickly evaluate and get familiarized with the code relevant to the acquired assignment. In the case of this thesis a game that is developed by several programmers with different expe- riences and purposes may be lacking in some aspects. The developers have had quite narrow perspectives because of time limitations when doing a thesis work. This is reﬂected in the performance at the current state of the game. This thesis will not only be useful for people working on an existing project. It also contains good knowledge from someone before starting on a new project, to know what loop- holes to avoid and in extension creating a better code base from the start.

1.2 Aim

This thesis will attempt to improve the performance of a game, while reworking existing and introducing new features to a existing motion-based web game. More speciﬁcally the

2 1.3. Research question main focus will be to improve frames per seconds by remaking certain features. As well as introducing new features that should have as low performance impact as possible.

1.3 Research question

• What is a better design and implementation of a motion-based web game in respect of frames per second?

1.4 Delimitations

The work will be done on an existing game that is created in the framework Phaser (section 2.3.2) and the WebGL library ThreeJS (section 2.3.1). It is not in the scope of this thesis to switch framework or programing language. Measurements will be with done code written by me and with freeware, mainly Chrome DevTools (section 4.1.1.1). The performance tests will be hardware limited to a “HP EliteDesk 800 G2 DM 35W” system with an “Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz” and 8 GB RAM.

3 2 Background

The game that this thesis evolves around, called the Bug game, is a motion based web game that takes input from a camera. Two university lecturers that works at Department of Com- puter and Information Science at Linköping University, have for some years led this student driven game development project. The goal of the Bug game is to prevent bugs from destroying a tree by letting the users move their arms and body and removing the bugs by touching them. There are also water buckets that the user should let pass so they can water the tree. By using the camera data the Bug game creates a white silhouette (see Figure 2.1) that is used for collision detection through some different simple graphical computations, that does not include techniques such as skeleton tracing or gesture recognition. Some of the development has added features without taking into account the performance impacts. Some parts of the Bug game in its current state is not enjoyable according to the stakeholders and that is why this thesis is needed, to remove existing lag and introduce some further extensions.

2.1 Themes

There exists two themes that are extensions of the main game “Night Theme” and “Winter Theme”. A theme is able to:

• Change graphical components such as bug model and background.

• Set the size and speed of the bugs and introduce new bugs

• Add new mechanics to the Bug game

2.1.1 Night Theme As the users is playing this theme the game gets darker with time but there is light in front of the bugs and in a circle around buckets and the tree. So the difference from the main game is that the users must memorize the roads to know where the entities are headed (see ﬁgure 2.2).

4 2.1. Themes

Figure 2.1: The Bug game - A screenshot taken while playing the Bug game at its state before this thesis, the white silhouette is the hands and body of the person that is currently moving.

Figure 2.2: The Night Theme - A screenshot taken while playing the Night Theme at its state before this thesis

5 2.2. Earlier work

Figure 2.3: The Winter Theme - A screenshot taken while playing the Winter Theme at its state before this thesis

2.1.2 Winter Theme In this theme there is a constant snowfall over the screen, the purpose of the snow is to cover the screen so it is harder for the user to see the game. This theme is not yet ﬁnished but currently the snow is using collision to collide with each other and some invisible plateaus so they are distributed over the screen. The plateaus are not a requirement for the theme, their purpose is to block the roads (see ﬁgure 2.3).

2.2 Earlier work

This section contains a summary of four theses written in the spring of 2016 all revolving around developing and improving the same game as this thesis.

2.2.1 Procedural Content Generation for a Web-Based Motion Game to Increase the Variation and Progression of the Game Dennis Persson created a Procedural Content Generation algorithm to make the existing game move variating and provide progression to the Bug game. He conducted a case study over three iterations and successfully created and implemented an algorithm that is used to generate the paths that the bugs take to the tree. [21]

2.2.2 Gränssnittsdesign för användbara rörelsestyrda spel “Interface Design for usable motion controlled games” (my English translation of the title). Johanna Gripenstam created a user interface for the Bug game through three user evaluated iterations. Before her work there was no interface at all so she introduced inter alia instruc- tions and a menu. [11]

6 2.3. Frameworks

2.2.3 Implementing Object and Feature Detection Without Compromising the Performance Jonas Gerling improved the motion capture detection system by implementing existing techniques and analyzing his result. He both improved the existing system so it is more accurate and moved some calculations to GPU that might have improved performance. [8]

2.2.4 Performance and architecture optimization in an HTML5-based web game Corentin Bras worked on improving the performance and code architecture on a quite high level. Introduced several design patterns and used some techniques to improve the frame rate. My thesis will continue to improve the performance with more techniques that he did not attempt to implement. [5]

2.3 Frameworks

The game is built with WebGL and Phaser, these frameworks are explained in this section.

2.3.1 WebGL WebGL is developed by the non-proﬁt organization Khronos, it is a royalty-free JavaScript API for 3D graphics. Shader code is written in GLSL and is called via JavaScript via the API. It is based on OpenGL ES 2.0 and is semantically close to it, OpenGL ES 2.0 is developed for embedded systems and was released 2007. A ten year old version brings some disadvantages, but to date this is the existing option for using OpenGL in browsers. Khronos have since 2013 been working on WebGL 2.0 that is based on OpenGL ES 3.0 but there will probably be years until it is released and widely used. [16]

2.3.2 Phaser Since the Bug game already exist the choice of main framework is already made. The Bug game is made with Phaser[17] that is an open source framework that uses WebGL and Canvas based on a custom build of the rendering engine Pixi.js. It has plenty of features such as a physics engine, preloader, input handler, device scaling, sprite grouping and much more. Games based on Phaser have according to their own website millions of plays each month. The current stable release is 2.6.2 and is the version that will be used, new versions have formerly been released quite frequently but since august 2016 focus have been shifted to development of version 3.0.0 that does not today have a release date. If the new version gets released in the start of this thesis, it might be possible to use new features from it, but since no release date is yet set it is not possible to know. Some useful unique features explained bellow: • Sprite - uses a texture and has a coordinate on the screen, it also has several additional features that can be useful for several kinds of games.

• Bitmap - that contains a Canvas object that can be drawn to as normal, it is used to dynamically create textures at run-time.

• RenderTexture - is a special type of texture that lets the user render any Phaser dis- playObject to it and there by generating textures at run-time.

• BlendModes - determine how two layers blend into each other. Currently there are seventeen modes implemented in phaser when using Canvas, but only four using We- bGL as in the Bug game, the modes are explained below:

– NORMAL - renders the ﬁrst layer and not the second.

7 2.3. Frameworks

– ADD - adds the values of each pixel of both layers. – MULTIPLY - multiplies the values of each pixel of both layers. – SCREEN - inverts, multiplies then inverts the values again for each pixel of both layers (yields the opposite effect as multiply).

8 3 Theory

This chapter contains motivation for this thesis and prior research that is used in the method. There is a scarce amount of scientiﬁc papers relevant to improvement performance improvement of WebGL based web applications, my theory is that due to the fact that it is such a new and fast moving area. Regardless of this there is a lot of information, but mostly in the form of articles, websites or blog posts. The information from such sources must not be bad, but of course must their purposes and opinions be questioned.

3.1 Related work

There exists a great number of reports where people try to measure and/or improve performance of websites or games, I have listed some in this section. Paul Barford and Mark Crovella wanted to figure out a way to measure why users often experienced delays, in their case when retrieving documents, in 1999 [2]. This would be much easier to measure today also the problem is minuscule with modern browsers and Internet connections. To get relevant information on how to improve a modern web game there was a need to retrieve newer information. The fact that WebGL that Phaser uses had its first stable release in 2013 gives perspective of how modern this area is. Rama C. Hoetzlein compared flash, canvas, WebGL and OpenGL. His results when trying different techniques tells me that I should use WebGL when developing for desktop. One of his conclusions where that “WebGL is the fastest online renderer owing to GPU acceleration.” [15] When searching for web development in general it is easy to find works about how to conduct measurement and analysis. An example is Velmurugan and Maluk Mohammeds report about Web Services [26].

3.2 Designing motion based games

One of the purposes of the Bug game is to make the players move their body and become physically active while playing a computer game. It is therefore important to know how to design to increase movement.

9 3.3. Frustration without performance

Bianchi-Berthouze presented an extensive taxonomy of body movements that is combined with a model of game engagement. The data for the taxonomy is mainly gathered from earlier research and is evaluated and gathered into separate classes of movement. The background for her study are several studies on engagement in games which she tries to evaluate in com- bination with then modern motion controls like the Nintendo Wii. [3] The purpose is to create a system that can be used when designing motion based games so the designer achieves the desired experience and movements of the user. Bianchi-Berthouze explains that the way the controls and actions are designed has a big effect on how much the player move: “When the controllers do not require and do not afford natural body movements, we observe a complete lack of movement other than those necessary to facilitate the control of the game; on the other hand, when the controllers require and afford body movements that are unique to the game scenario, we observe movements that are related to role-play and enjoyment even though those movements may interfere with game performance.” [3] Similarly Hara and Ovanska analyzed 256 game reviews of motion based games on the site Metacritic. The purpose is to create a heuristic for designer to follow when designing motion based games. The list consists of thirteen heuristics that should be considered, some examples of heuristics are “Diversity - Design diverse motion paths and avoid repetitive movements.”, “No fatigue - Beware of requiring strenuous movement.” and “Challenge - Keep the game control simple but challenging enough.”. [14] Engagement increase the enjoyment of the player, and when it is achived the user will almost forget that a game is played. Lag and low performance can cause the the user to loose the ﬂow that the design strive for, section 3.3 discusses the frustration that can appear from low performance.

3.3 Frustration without performance

One reason why performance is of great importance to users of a game is that lag caused by bad performance in a game can frustrate the users. Schreider et al. did a study 2002 on frustrating users on purpose and created a model to evaluate a computer system. They deliberately rigged the mouse to not react to input at random intervals, in a time based game to see how this affects the user. The 36 test subjects had two different physiological sensors on their bodies to measure heart rate among other things. They was able to construct a model that shows a distinct connection of frustration and game performance. [24] Similarly Fiona Nah evaluated what the tolerable waiting time was for users entering a web page while purposefully browsing. The test subjects where not aware of the experiment and had been told that it was an ordinary university lab assignment. The study was an ex- ploratory experiment with seventy subjects, where they all used the same system but about half of them where provided with a loading symbol to indicate that the web page was down- loading. In their assignment they had to use ten different links to complete some tasks, where three of the links where not working. The result showed that the subjects waited more than double the time if they had feedback from the system, in this case the loading symbol. [18] Other conclusions that Nah was able to do was that the tolerable waiting time for information retrieval was approximately two seconds. This was in line with her background sources that had done similar research before the Internet era. E.g. Shneiderman [25] concluded that tolerable waiting time depends on the task but a delay of two seconds marks the point where short commands become intolerable for users. This gives a pointer to what to strive when developing a web page and why performance is important. [18]

10 3.4. Frame rate

3.4 Frame rate

The performance in a game might affect the overall experience of a game, it is most commonly measured by the metric frame rate. Frame rate is the frequency a screen displays consecutive image frames, it is expressed in the amount of frames per second (abbreviated FPS in this thesis). At a high enough rate the images will be perceived as continuous movement which is desired for games to prevent the player from loosing flow. A note is that frame rate is limited up to 60 FPS in web browsers at this moment. Apteker et al. conducted an experiment in 1995 on 60 undergraduate computer science students to determine video watchability at different frame rates, and concluded that 15 FPS might be just acceptable and at 30 FPS the video has high watchability [1]. Several games and consoles have limited the frame rate to 30 FPS. Rickard Hagström ex- amined if there is a point with higher frame rate. According to his studies there is a difference in games and video and some people might prefer lower frame rates in video but not games. His experiments, that where conducted on 11 young people who had previous gaming experience, showed that 60 FPS gave the test subjects a greater feeling of fluidness in the game. [13] Claypool et al. investigated both how frame rate and resolution affected users in their user study. They where mainly interested in knowing how it affected people playing first person shooting games, but I think their results can to some extent be applied to games where the user needs to react fast in general. They developed a test harness to let the test subjects test different frame rates and resolutions, send comments and feedback after matches and the harness also captured statistics of the deaths and kills for each match. The user study was conducted on 60 subjects and the result of the study was that the user performance was greatly improved with higher frame rate. Even though the performance increased slower with higher frame rate, there was still improvement between 30 and 60 fps. When analyzing the effect of frame rate on how the subjects perceived quality there was also an increase of quality with frame rate tough not as prominent. They say in the conclusion of their paper that this result is “The overall results are dramatically different than those obtained for previous research that assessed the effects of frame rate and frame resolution for streaming video” where they had looked at other researchers that had found that a frame rate of 7 fps was acceptable. [6] Regardless if a developer strives for 60 FPS or settles for lower, there is always a benefit of trying to have optimized code. Firstly better performance gives the ability to play the game on weaker hardware. Secondly if there is plans for further development of the game, the developer will be able to add more features.

3.5 Improving JavaScript

Addy Osmani working as Engineering manager at Google working on Chrome, wrote at the website Smashing Magazine about how to increase performance by “Writing Fast, Memory- Efﬁcient JavaScript”. Where he gives a lot of useful tips on how to think when coding, specif- ically for chromes JavaScript Engine, but most of it can be used in general. When talking about optimizing applications he gives recommends using time according to the following ratio

“‚ Measure it: Find the slow spots in your application ( 45%)

• Understand it: Find out what the actual problem is ( 45%)

• Fix it! ( 10%)”

He gives some good tips on tools to use and recommends among others Chrome DevTools (see section 4.1.1.1) and a benchmarking framework called Benchmark.js. [20].

11 3.6. Memory management

The web page www.html5rocks.com, that is a Google project, have a very useful sub- page about performance, they explain what to think about developing a web page and how to achieve higher fps [9]. One of the subpages there, a tutorial about “Improving HTML5 Canvas Performance” [10] Boris Smus gives several handy tips on what to think about when working with the Canvas, supported by test the reader can run themselves, a summarized list of some of the is presented below:

• Draw calls are expensive, batch them together if possible.

• Avoid changing states often, e.g. better to ﬁll all parts of a canvas with the same color ﬁrst than ordering by their placement.

• Avoid ﬂoating point coordinates if that is not wanted.

Another interesting source is Ashley Gullen that talks about how to “How to write low garbage real-time Javascript” in is blog post on Scirra, discussed among others in section 3.6 [12].

3.6 Memory management

The memory life cycle consists of these three steps according to Mozilla Developer Network:

“1. Allocate the memory you need

2. Use the allocated memory (read, write)

3. Release the allocated memory when it is not needed anymore”

Where the last step is implicit in high-level languages like JavaScript. [19] Wagner et al. claims that garbage collection, the last step in the memory life cycle, is a “[..] severe bottleneck within the browser and the JavaScript virtual machine [..]”. In their paper where they give a suggestion for improving how the browsers JavaScript virtual machines handles garbage collections and multiple tabs. [27] There are techniques to write code that creates less garbage. Ashley Gullen gives some concrete examples, such as re-cycling existing objects and not creating new functions in a game loop. [12]

3.7 Anti-aliasing

Spatial anti-aliasing (will be referred to as anti-aliasing) is a technique to minimize distortion that occurs when graphics are rendered to a screen that consists of discrete pixels. If the graphics might have higher resolution or non discrete data like a line from a point to another aliasing will occur. A common case of aliasing is the “staircase” shape of a digital line. There are several methods for anti-aliasing either way it always creates some sort of blur to make edges less visible. [23] Booth et al. conducted a two part experiment to investigate the effects of anti-aliasing. In the second part they investigated the task effectiveness dependent on image quality and concluded that aliasing artifacts does not reduce the users effectiveness unless the resolution is intermediate or low, which is comparable to what might be used for icons in a menu. [4]

12 4 Method

The result of this thesis will be a demonstration of the performance difference of the bug game this thesis assesses for each implemented feature or improvement. This chapter will explain the method that is used, some principals will give a generic pointer in how to develop for better frame rate performance in a web game. Section 4.1 explains the methods used to ﬁnd general problems with the Bug game and how to measure them. The then following sections are about each speciﬁc individual feature or improvement. Each section is divided into Pre-study, Implementation and Evaluation.

• The Pre-study explains why that improvement or feature is needed and also how the weak spot was found or the feature was thought of. • The Implementation explains how the code were written to create the improvement or feature. • The Evaluation explains how the result is interpreted and discusses if the improvement or feature had the expected result.

4.1 Finding and measuring

Since the code base is quite big it is simply to time inefficient to read through every file and try to analyze what might be taking more time than it is supposed to. This section will explain how to find and measure what should be improved.

4.1.1 Measurement This thesis will mainly use three tools to measure performance, they are explained bellow.

4.1.1.1 Chrome DevTools To assess what is using the frame rate I will use Chrome DevTools [7] that is a powerful set of tools that is integrated into the chrome and chromium browsers. The DevTools are recommended by among others Addy Osmani as mentioned in section 3.5. This thesis uses mainly the Timeline Tool, since it can show every event on interaction or page load, FPS, CPU, and network requests and has a visualization of the CPU stack trace.

13 4.1. Finding and measuring

Using the applications in different ways while recording in the DevTools gives a real life data of how demanding different actions are also where they origin from and when they occur. When having data from DevTools analysis of what happens each frame will be performed on some functions that are called. There will not be in depth analyze of each call, since Phaser and ThreeJS does many anonymous computations that are hard to understand without having good insight into the frameworks source code. But with the Bug games source code analysis of function calls will be performed to see if:

• They need to be called so often.

• If they take a lot of time.

• If they might allocate unnecessary amount of memory.

4.1.1.2 Canvas draw calls Firefox Developer Tools are similar to chromes, but it has one feature that chrome is lacking, the Canvas Debugger [22]. It will be used to asses if reduction of draw calls is possible and if an attempt is successful.

4.1.1.3 FPS module Chrome DevTools have a lot of useful features, but one feature it does not have is the ability to show average FPS over time which will be the main measurement of this thesis. An add-on to the Bug game that will gather that data has been implemented that makes use of Phasers fps property. To avoid causing performance impact it only updates once every second and saves that frames FPS. Every ten seconds print the average FPS so far and the average FPS the last ten seconds. An alternative to the module could have been using Benchmark.js recommended by Addy Osmani as mentioned in section 3.5. This seemed unnecessary when Phaser have support for measuring FPS which was the chosen metric for this thesis. The module will be active while the game runs as normal except that settings are changed so it is not possible to lose. The average FPS is printed in the console and when it has sta- bilized it will be recorded. This will be used in the result chapter 5 of this thesis for every improvement.

4.1.2 Design choices To ﬁnd different problems and ensure extendability the methods will not only be applied to the current Bug game play. Additional test modes will be developed that will help in analyzing edge cases e.g.: “What happens to performance when the bugs spawn 10 times as often?” All problems might not be solved by analyzing the data from DevTools. Other things to consider that will be assessed with help of source code are:

• There might be structural problems with overall design choices, see what type of design patterns are used and ﬁnd out if they are poorly implemented or if better alternatives exist.

• See what current release of phaser is used and read up on the new features that have been implemented since. And see if some functions used are deprecated.

• WebGL can be quite complicated, especially for someone who have not done low level programming. So I have to asses if there are inefﬁcient use of it or its abstraction through phaser

14 4.2. Skipping pixels in collision detection

4.2 Skipping pixels in collision detection

4.2.1 Pre-study When measuring FPS with ten times as high spawn rate there was a notable performance impact. Analyzing the timeline (see ﬁgure 5.1 (a) and (b)) it is clear that the function checkPixelCollison() in Game.js is taking much more time. This function is a pixelcollision function that is called for each object (bugs, water buckets and collectables) alive in game. It compares each pixel in the object with each pixel in the player silhouette. Every bug for example is 30x46 pixels which equals to 1380 loops for each bug.

4.2.2 Implementation In order to reduce the impact of the pixel-collision the size of the loops will be reduced by introducing a variable pixSkip that skips object-area/pixSkip2 pixels in the loops 4.1. pixSkip = 1 gives approximately the same performance as before.

1 function checkPixelCollision(object, camera, pixSkip){ 2 var t = 0; 3 for (var i = 0;i< object.width;i += pixSkip){ 4 for (var j = 0;j< object.height;j += pixSkip){ 5 // camera.data returns RBGA values, so skip 3/4 pixels 6 // if value is>0 then it contains the silhouette 7 if (camera.data[((object.x+i) + ((object.y+j) * camera.width)) * 4] > 0) 8 if (++t>(object.tolerance/(pixSkip * pixSkip))) return true; 9 } 10 } 11 return false; 12 } Listing 4.1: The collision handling after implementing the pixSkip variable.

4.2.3 Evaluation This made a great difference when a high amount of objects are used and has seemingly no drawback from initial testings. Though it might need a peer evaluation to see if players can notice any difference from skipping too many pixels.

4.3 Improving camera usage

4.3.1 Pre-study WebGLMotionCam is the name of a three.js and ThreeRTT.js module, developed by former master thesis students working at Department of Computer and Information Science, that is used in the Bug game for motion detection. It works through getting the webcam from the browser drawing it to a scene, applying a four fragment shaders to the scene, this scene then converted to a sprite in phaser and is displayed on the screen. WebGLMotionCam is also reading the pixels from a scene camera which are available for phaser and is used for collision detection. When analyzing the timeline, functions called from WebGLMotionCam stands for a big portion of the CPU-usage time. An attempt to implement this in phaser might remove overhead caused by three.js.

4.3.2 Implementation To implement the WebGLMotionCam in phaser the camera will be applied to two different sprites which have the shaders applied to them. One of them will be one frame behind for the

15 4.4. Draw calls shaders to be able to compare the frames. The shaders will be converted to phasers shader format.

4.3.3 Evaluation Converting three.js shaders to phaser where easy since they are handled quite similarly but after that there are some dissimilarities. In phaser a shader is applied to a sprite and is evaluated each frame. Early in the process a very low frame rate where discovered which lead to the entire implementation not even being ﬁnished.

4.4 Draw calls

4.4.1 Pre-study With the Canvas Debugger in Firefox it was clear that the Bug game were using and unnecessary amount of draw calls each frame. This is dependent on how the user interface is implemented, especially the clock. This should be remade so the user interface uses as few draw calls as possible.

4.4.2 Implementation Instead of drawing new components directly to the main canvas sprites are created that are batched together and drawn by phaser. The sprites have an alpha value that can be set to 0 if the sprite is not supposed to be shown.

4.4.3 Evaluation Draw calls where not a good indicator for performance issues in the Bug game since removal of more than 50% had no impact on FPS.

4.5 Anti-aliasing

4.5.1 Pre-study The Bug game is currently being redesigned in aspect of graphics and the new graphics will be in the form of pixel art. There is no point in using anti-aliasing if the Bug game is supposed to be pixelated so there for it will be removed.

4.5.2 Implementation In Phaser there is a boolean when the game is created that indicate if anti-aliasing will be used.

4.5.3 Evaluation The performance impact of anti-aliasing was huge.

4.6 Themes

There is some work that is needed to be done to each of the themes explained bellow.

16 4.6. Themes

4.6.1 Night Theme 4.6.1.1 Pre-study Currently this theme has much lower FPS than the main game, so the task here is to get the FPS as close as possible to the main game. The theme is basically adding one black Phaser Bitmap that covers the screen. Each frame the Bitmaps canvas is cleared and is redrawn with the correct alpha dependent on time then the theme loops over every object that is supposed to emit “light” and draws the correct shape at that locations with alpha 0 and in that way creates “light”.

4.6.1.2 Implementation Two themes are implemented, the reason for this is explained in the result 5.5.1. The new Night Theme is achieved with one big sprite with alpha zero and sprites for every light with a gradient alpha of one to zero. They are blended with the blend mode ADD (section 2.3.2) and then a shader is used to invert all alpha values is applied. The Lamp Theme is made similarly to the old Night Theme but is never redrawn, there is just some circles placed along the roads to simulate street lights. A texture is created before the game starts and is placed above the game. The two different themes are shown in ﬁgure 4.1.

4.6.1.3 Evaluation Both themes are great improvements from the old theme, but even the Lamp Theme is still not completely free from overhead. A small performance impact might be acceptable.

4.6.2 Winter Theme 4.6.2.1 Pre-study Currently this theme has a few FPS lower than the main game and that difference is increasing over time, since the screen becomes ﬁlled with snow. The task here is, similarly to the Night theme, to get the FPS as close as possible to the main game but also to replace the plateau system and implement the ability to for the user to remove snow from the screen. The theme is creating three Phaser Emitters that simply emits Phaser Sprites at a given interval, the theme also places 4 plateaus that are Phaser Sprites at random locations that the snow can collide with. Each frame the theme checks for collision between every “snowﬂake” and every plateau.

4.6.2.2 Implementation In order to remove all collision detection a random based system was instead introduced. Since the purpose of the theme is to block vision of the player, and the most important parts of the Bug game is the roads. The new version still has the snowemitters to give the feeling off snowing and at the same time there is a small random chance that each road tile will be covered by snow (unrelated to the emitted snow). The second part was to let the player remove snow from the screen. Since collision detection already were implemented it is easy to just reuse the existing function, and use the pixSkip introduced in section 4.2.

4.6.2.3 Evaluation The theme has better FPS than before even though new features are implemented. It is due to the old plateaus that had high impact. The reason that this themes is still some FPS from standard is probably due to the high amount of sprites being used.

17 4.6. Themes

(a) Night Theme

(b) Lamp theme

Figure 4.1: Screenshots of the two different Night themes.

18 4.7. New features

4.7 New features

To increase the amount of movement done by players of the Bug game, two new features were made up in discussion with the stakeholders. The purposes are to increase the movement of the players. The Explosion mode aims to beneﬁt fast movements to prevent the player from standing still. The Mushroom rush aims to increase the variety of movements for the user, the cloud should make the user raise their hands and the mushrooms beneﬁts moving all over the screen.

4.7.1 Explosion mode 4.7.1.1 Pre-study Feature: If the bug is struck with high enough movement the the bug shall explode killing nearby bugs. Since the Bug game is not using any method to analyze what the player is moving or in what direction, it will be to big of a job to try to understand what the player is doing. Instead it is possible to see how much the player is moving at each frame.

4.7.1.2 Implementation Just summarizing each pixel of the players silhouette returns the current movement that frame. A function for this already exists, it is the same as checking pixel collision with the entire screen. There is a problem though, this will introduce a loop over up to 360 ˚ 480 = 172800 pixels each frame. Though this can be dramatically decreased due to the pixSkip introduced in section 4.2. The explosion will consist of an added graphic to show the player how big the area was, a smaller rubble of the screen and a loop over all the bugs to see if they are in the radius of the explosion.

4.7.1.3 Evaluation With the right amount of pixSkip a performance drop of less than one FPS can be achieved.

4.7.2 Mushroom rush 4.7.2.1 Pre-study Feature: There spawns a cloud at a certain moment, if taken rain starts, mushrooms spawns and water buckets disappears for ten seconds.

4.7.2.2 Implementation The cloud sprite will move at the top of the screen and collision handled as the bugs. When taken, an emitter that produces the rain will start. And a mushroom will spawn at a random place on the screen every second.

4.7.2.3 Evaluation This feature where easily implemented just using existing functions, though the impact on frame rate is inevitable since it is Phasers emit function that causes the overhead. The alternative is to create an own alternative to the emitter that is less performance demanding.

19 5 Results

This chapter contains the results in form of performance difference before and after the improvement/feature is in place.

5.1 Skipping pixels in collision detection

The result of different test are presented in table 5.1. The difference is also be visualized in figure 5.1 where the light blue function call in the middle of figures (a) and (b) is the call to the pixel collision handler while it is no longer visible in figure (c). When using a pixSkip value of 6, collision is checked for at 40 pixels. This gave a 0.3 FPS overhead compared to no collision detection at all and is a 12% FPS improvement from not skipping pixels.

pixSkip 1 2 3 4 5 6 No collision detection Pixel amount 1380 345 160 96 60 40 0 Average FPS 29.8 30.1 31.1 31.9 32.9 33.4 33.7 Improvement percentage 1% 4% 7% 10% 12% (13%)

Table 5.1: FPS dependent on pixSkip values with ten times higher bug spawn rate than usual.

5.2 Improving camera usage

The shaders were applied to Phaser Render Textures which resulted in the frames taking longer time than before (see ﬁgure 5.2), where a high GPU-usage is noted. The frame rate resulted in 20.4 FPS which is 14.5 FPS lower than before which is a decrease of 42%. This is also demonstrated in table 5.2. This was without introducing collision handling, which were not implemented due to the attempt to improve the camera usage was aborted after the decreased performance was noticed.

20 5.2. Improving camera usage

(a) Frame with normal bugspawn

(b) Frame with 10 times as high bugspawn

Figure 5.1: Three frames with different spawn rates of bugs and pixSkip values.

Figure 5.2: A frame when using camera shaders in phaser, the frame takes 50 ms (mostly GPU-time) that gives and FPS of approximately 20.

21 5.3. Draw calls

Camera handling ThreeJS Phaser Average FPS 34.9 20.4 Improvement percentage -42%

Table 5.2: FPS dependent on how the camera is handled. ThreeJS was the original implementation.

5.3 Draw calls

The draw calls were reduced from 48 to 19. When measuring the FPS the remake had no impact at all. This is presented in table 5.3.

User interface version Old New Draw calls 48 19 improvement percentage 60% Average FPS 36.2 36.2 improvement percentage 0%

Table 5.3: Amount of draw calls and FPS before and after the remake of the user interface.

5.4 Anti-aliasing

The result from turning anti-aliasing off has an FPS increase of 7.5 FPS which is an improvement of 25% compared to before. This presented in table 5.4.

Anti-aliasing On Off Average FPS 29.9 37.4 Improvement percentage 25%

Table 5.4: FPS with and without anti-aliasing.

5.5 Themes

This section presents the different results of the improvements of the two themes.

5.5.1 Night Theme Attempts to improve the Night theme were successful but it was not possible to make it completely free from overhead. Therefore a discussion with the stakeholders led to a total rework of the theme, they wanted the new theme to ﬁll the same purpose as the old theme but have close to no overhead, then the Lamp Theme was created. The new Night Theme has an increase of 15.7 FPS which is an improvement of 111% compared to before, and is 8.5 FPS lower than the Standard Theme. The Lamp Theme has an increase of 5.4 FPS compared to the new Night Theme and is 3.1 FPS from the Standard Theme. This is presented in table 5.5, which compares old Night Theme, new Night Theme, Lamp Theme and the Standard Theme as reference.

Theme Old Night New Night Lamp Standard Average FPS 14.2 29.9 35.3 38.4 Improvement percentage 111% 149% (170%) Percentage of standard 37% 78% 92% 100%

Table 5.5: FPS dependent on the themes.

22 5.6. New features

5.5.2 Winter Theme The old Winter Theme had a start FPS of 30 (the emitter was not handled correctly which led to a steadily decrease of frame rate the FPS quickly dropped each second). The new Winter Theme has an FPS increase of 3.9 FPS which is an improvement of 13% compared to before. This is presented in table 5.6, with Standard Theme as reference.

Theme Old New Standard Average FPS 30 33.9 38.9 Improvement percentage 13% (30%) Percentage of standard 77% 87% 100%

Table 5.6: FPS dependent on the themes.

5.6 New features

This section presents the different results of the performance impact of the two new features.

5.6.1 Explosion mode The result of different test are presented in table 5.7. When using a pixSkip value of 6, collision is checked for at 8533 pixels. This gave a 0.9 FPS overhead compared to no explosion checks at all and is a 2% FPS impact compared to not using explosions.

pixSkip 1 2 3 4 5 6 No explosion Pixel amount 307200 76800 34133 19200 12288 8533 Average FPS 25 30.3 34.5 35.8 37 37.3 38.2 Improvement percentage 21% 38% 43% 48% 49% (53%) Percentage of standard 65% 79% 90% 94% 97% 98% 100%

Table 5.7: FPS dependent on pixSkip values during explosion mode and without as a reference.

5.6.2 Mushroom rush When the Mushroom rush is active the game runs at 1.9 less FPS compared to playing without the mode, this gives a 5% FPS impact to the game. This is presented in table 5.8

Theme Standard Mushroom rush Average FPS 38.7 36.8 Percentage of standard 95%

Table 5.8: FPS during and outside of mushroom rush.

23 6 Discussion

6.1 Results

6.1.1 Skipping pixels in collision detection This change did not affect the Bug game in any signiﬁcant way from the start, since the amount of bugs are not that high. It made a signiﬁcant difference later, since the check- PixelCollision function is reused both in the explosiveBugs function and in the Winter theme. There are plans for other modes in the future as well so this feature makes the game more future-proof.

6.1.2 Improving camera usage This was an attempt completely without basis. Researching shader usage in Phaser and its performance granted nothing useful, so the reason this attempt was basically to ﬁgure out if there was a possibility for phaser to utilize WebGL good enough. The result was not so surprising since Phaser is based on PIXI which is a 2D JavaScript renderer and has low focus on utilizing shaders for advanced computations as the camera module is doing.

6.1.3 Draw calls According to Boris Smus [10] as discussed in the theory draw calls are expensive actions and should be batched together. This made the results strange since removing more than half of the draw calls had no impact on frame rate at all. Some theories to why this had no effect are:

• The article is originally from 2011, this might have been improved since then. Either so browsers handle draw calls smarter or the hardware is more advanced so this is no longer a performance issue.

• 48 draw calls might not be a signiﬁcant amount in this context and the issue might only appear when the number is much higher.

24 6.1. Results

• Phaser way of handling the drawings might cause problems when they batch the draws that might have a performance impact that is equal to the time saved.

6.1.4 Anti-aliasing The result is as expected from the theory 3.7 since less graphical computations are needed. The signiﬁcance of the improvement to performance where interesting and gives a pointer on how demanding anti-aliasing is. The feature to deactivate this with a boolean when creating the game is very useful. A beneﬁt was also that removing anti-aliasing also removed unwanted artifacts from some of the textures. Also discussed in the theory were the experiments Booth et al. conducted. It could be of relevance to evaluate if the removal of anti-aliasing has a negative effect on this game, though as mentioned in the article the effect only had a negative performance impact on users if the objects affected of aliasing was quite low. Which is not the case here, one could say that it is rather the opposite since the removal of unwanted artifacts makes the objects clearer.

6.1.5 Themes 6.1.5.1 Night Theme The result of the ﬁrst attempt where quite surprising and gave further insights on what was the biggest bottleneck of the Bug game. The assumption that implementing a shader-based solution would make the theme very fast and have no impact on performance, was unfortu- nately misplaced. Especially when the shader is only doing one subtraction (1 ´ pixel_alpha). The use of an inverse alpha function might seem redundant, the reason this was necessary was to solve the fact that the SUBTRACT blend mode is not available in Phaser. Otherwise it would have been simple to SUBTRACT-blend the hole-sprites with a black sprite. Instead inverted holes are added to an empty sprite and then its alpha-value is inverted. With the knowledge that a shader based theme where not an option, no solution was apparent that would not require creating a new texture each frame. This created an interesting discussion with the stakeholders, where brainstorming led to a theme that would ﬁll the same purpose but with the main difference that it was presumed not have any performance impact, the result was the Lamp Theme. The only thing the Lamp Theme is doing is creating one sprite once which is placed sta- tionary on the screen, this was thought to have close to no impact. This was obviously dis- proved due to the 3.1 FPS difference between Standard and Lamp themes. This gives an interesting conclusion that big sprites can be quite expensive. This insight was very good when the game was further developed and a layered background structure was wanted. Then it was known that this would have an impact on performance and instead of having several sprites on top of each other one was created from several textures, which made a noticeable difference. Furthermore the resulting Lamp Theme brought a new level to the game, the old themes only uniqueness where that you could not see the roads. The bugs where always visible which did not seem to change the gameplay that much during tests, the new theme brought a totally new mechanic that could change the game play, for this further tests needs to be conducted.

6.1.5.2 Winter Theme This was not a perfect solution to this theme. The reason for the 5 FPS difference from standard is both that a phaser emitter has a 1-2 FPS impact and then the high amount of sprites that are added which obviously causes a performance issue. Some solutions though must

25 6.2. Method have some impact on the performance and this solution was appreciated by stakeholders so the impact was acceptable. The new mechanic where the user is able to clear the screen of snow with swipes beneﬁts big gestures which is positive from an exercise point of view.

6.1.6 New features For the new features it is even more important to also evaluate from two other perspectives, if they make the player move more and if they improve the game experience. This was not in the scope of this thesis to evaluate but during development they were tested by stakeholders and also in scientiﬁc tests with player evaluations. Though they could not be added to this work since they where not ﬁnished by the end of this thesis, but the early results gave great information on how to continue their development.

6.1.6.1 Explosion mode This addition had low performance impact and made a high impact on the gameplay.

6.1.6.2 Mushroom rush As discussed in section 6.1.5.2 there is an inevitable performance impact from using an emitter. Using an emitter also makes the rain look natural since it slightly randomizes the speed and angle of the drops. So using phaser built in functions saves a lot of time that made the small performance impact worth it.

6.2 Method

With the single focus on performance there can be drawbacks. A feature might be more appreciated by a user if it is designed in another way even though it has a 10 FPS impact. To have an expert on what is performance heavy in a framework could be very useful, but that the expert would together with the designers brainstorm and develop new mechanics and features for the game. In this thesis a similar method was applied when the new features where developed. But instead of a discussion with designers an active discussion where held during the development with stakeholders. They had several ideas as input which where evaluated in the aspect of how easy it would be to implement them with a low performance impact. It was a well working method since the stake holders had time to have several short meetings spontaneously every day and had ofﬁces nearby. It will not be the case for all projects that a close contact can be held between different parties and using this technique then could cause stagnation due to waiting times. The following sections discusses the tools used in this thesis.

6.2.1 Chrome DevTools Figure 6.1 is a screenshot of the timeline of two frames in game, the frames differ quite much especially the readPixels and drawImage calls. The functions common determiner is that they are both WebGL-based. As can be seen through looking at the green bar at the bottom of the timeline that indicates GPU-usage, the GPU is active most part of the frames. This leads to the assumption that the functions are not actively using the CPU all the time they indicate, they are instead idly waiting for the GPU to ﬁnish. Though since there is no stack trace for the GPU and both calls are advanced native WebGL functions it is hard to know exactly what is causing this behavior. This is one of the reasons the Chrome DevTools were not as reliable as initially assumed, which made the tools less useful for this thesis. Nevertheless the timeline was a very helpful

26 6.3. The work in a wider context

Figure 6.1: Timeline Tool - A screenshot of the timeline zoomed in on two typical frames tool that made it possible to ﬁnd problems with collision handling, the themes and some smaller things not mentioned in this thesis. The sources read about the tools, like Addi Osmani [20], where positive but not so in depth that it brought up drawbacks when working on a project like this. It would be useful if there was profound research about what tools to use and what their drawbacks are. This will probably not be the case though since web development is still such a fast moving area as mentioned in chapter 3. The assumption that can be drawn from this thesis is that a game developer will make the most use of the timeline tool while creating a fully Canvas-based game using no framework, or a smaller one that the developer have a great insight into.

6.2.2 Canvas draw calls Measuring draw calls was unproblematic but in this case useless as discussed in section 6.1.3. There might be a point in another framework or if a game is constructed in another way, but for this thesis it was pointless.

6.2.3 FPS module This tool was simple to create and achieves robustness from the fact that it is using Phasers Time object that is using the native JavaScript object Date. It is not totally accurate though since it only updates once per second so if the frames at every measurement is not represen- tative wrong data can be collected. To minimize this problem some measurements were done over a longer time and some where measured several times. If the FPS module has a performance impact, it should not matter, since it is used in all test. So the impact would be same on all tests. It is hard to know if there would be a beneﬁt from using another framework to serve the purpose of the FPS module as discussed in section 3.5. It would probably have taken longer time to get started with and since there was no interest to measure any thing else than FPS the other functions could have been pointless. Though one can argue that there is a chance other tools could have given a deeper insight into what caused certain behaviour.

6.3 The work in a wider context

Creating a game where the purpose is to make the user move while playing can have a positive societal impact since exercise is good for the body. Also getting training from playing a game might attract some people who ﬁnds other forms of exercise boring. In a global perspective there is a beneﬁt from optimizing performance of games, if the game is not using less of the CPU the computer will waste less electricity which will cause less pollution. Further if games requires less hardware, users will be able to use their computer

27 6.3. The work in a wider context for a longer time and will not be demanded to consume as much. Also the game will be accessible for more people and playing games will be less of a class issue.

28 7 Conclusion

The purpose was to increase the performance of a motion-based web game through ﬁnding performance issues and further develop some features with as low performance impact as possible. The use of the Timeline Tool was very useful but when it comes to analyzing GPU the tool can be confusing. The results achieved can be seen as some good insights into what is performance demanding when developing for the web. Below some important points from the results are comprised:

• Analyzing if big loops can be compressed in some way, e.g. skipping pixels in the Bug games collision handling had no initially noticeable performance impact.

• Compared to theory reduction of draw calls had no impact. But the use of many sprites had a big performance impact versus creating one sprite from many textures.

• Small shader computations can still have high performance impact.

7.1 Future work

The area that a continuation of this thesis should do a deep analysis of is if there is some way to reconstruct the camera management in some way, it is currently using more than half of the CPU-time. The Features and themes should also be further evaluated in the aspect of user experience, if the features are not enjoyable or has no impact then they are pointless for the game.

29 Bibliography

[1] R.T. Apteker, J.A. Fisher, V.S. Kisimov, and H. Neishlos. “Video acceptability and frame rate.” In: IEEE Multimedia 2.3 (1995), pp. 32–40. ISSN: 1070986X. [2] Paul Barford and Mark Crovella. “Measuring Web Performance in the Wide Area”. In: SIGMETRICS Perform. Eval. Rev. 27.2 (Sept. 1999), pp. 37–48. ISSN: 0163-5999. [3] Nadia Bianchi-Berthouze. “Understanding the Role of Body Movement in Player En- gagement”. In: Human–Computer Interaction 28.1 (2013), pp. 40–75. DOI: 10 . 1080 / 07370024.2012.688468. [4] Kellogg S. Booth, M. Philip Bryden, Wiliam B. Cowan, Michael F. Morgan, and Brian L. Plante. “On the Parameters of Human Visual Performance: An Investigation of the Beneﬁts of Antialiasing”. In: Proceedings of the SIGCHI/GI Conference on Human Factors in Computing Systems and Graphics Interface. CHI ’87. Toronto, Ontario, Canada: ACM, 1987, pp. 13–19. ISBN: 0-89791-213-6. DOI: 10.1145/29933.30854. URL: http:// doi.acm.org/10.1145/29933.30854. [5] Corentin Bras. “Performance and architecture optimization in an HTML5-based web game”. MA thesis. Linköping University, 2016. [6] Mark Claypool, Kajal Claypool, and Feissal Damaa. The effects of frame rate and resolution on users playing ﬁrst person shooter games. 2006. [7] Google Developers. Chrome DevTools. (accessed on 2016-12-14). URL: https : / / developers.google.com/web/tools/chrome-devtools/. [8] Jonas Gerling. “Implementing Object and Feature Detection Without Compromising the Performance”. MA thesis. Linköping University, Mar. 2016. [9] Google. HTML5 FEATURES PERFORMANCE. (accessed on 2016-12-14). URL: https: //www.html5rocks.com/en/features/performance. [10] Google. Improving HTML5 Canvas Performance. (accessed on 2017-04-10). URL: https: //www.html5rocks.com/en/tutorials/canvas/performance/. [11] Johanna Gripenstam. “Gränssnittsdesign för användbara rörelsestyrda spel”. MA thesis. Linköping University, Apr. 2016. [12] Ashley Gullen. How to write low garbage real-time Javascript. Blog. (accessed on 2016-12- 01). Mar. 2012. URL: https://www.scirra.com/blog/76/how-to-write-low- garbage-real-time-javascript.

30 Bibliography

[13] Rickard Hagström. “Frames That Matter - The Importance of Frames per Second in Games”. MA thesis. Uppsala University, Sept. 2015, p. 38. [14] Minna Hara and Saila Ovaska. “Heuristics for Motion-based Control in Games”. In: Proceedings of the 8th Nordic Conference on Human-Computer Interaction: Fun, Fast, Foun- dational. NordiCHI ’14. Helsinki, Finland: ACM, 2014, pp. 697–706. ISBN: 978-1-4503- 2542-4. DOI: 10 . 1145 / 2639189 . 2639246. URL: http : / / doi . acm . org / 10 . 1145/2639189.2639246. [15] R. C. Hoetzlein. “Graphics Performance in Rich Internet Applications”. In: IEEE Com- puter Graphics and Applications 32.5 (Sept. 2012), pp. 98–104. ISSN: 0272-1716. DOI: 10. 1109/MCG.2012.102. [16] Khronos. OpenGL ES 2.0 for the Web. (accessed on 2016-12-14). URL: https://www. khronos.org/webgl/. [17] Photon Storm Ltd. Phaser. (accessed on 2016-12-01). URL: https://phaser.io/. [18] Fiona Fui-Hoon Nah. “A study on tolerable waiting time: how long are web users will- ing to wait?” In: Behaviour & Information Technology 23.3 (2004), pp. 153–163. [19] Mozilla Developer Network and individual contributors. Memory Management. (accessed on 2016-12-01). URL: https://developer.mozilla.org/en-US/docs/ Web/JavaScript/Memory_Management. [20] Addy Osmani. “Writing Fast, Memory-Efﬁcient JavaScript”. In: Smashing Magazine (Nov. 2012). (accessed on 2016-12-14). URL: https : / / www . smashingmagazine . com/2012/11/writing-fast-memory-efficient-javascript/. [21] Dennis Persson. “Procedural Content Generation for a Web-Based Motion Game to In- crease the Variation and Progression of the Game”. MA thesis. Linköping University, Feb. 2016. [22] Victor Porof. Introducing the Canvas Debugger in Firefox Developer Tools. (accessed on 2017-04-10). URL: https : / / hacks . mozilla . org / 2014 / 03 / introducing - the-canvas-debugger-in-firefox-developer-tools/. [23] Ingemar Ragnemalm. “Polygons feel no pain”. In: Course book for TSBK07 Computer Graphics c Ingemar Ragnemalm 2016 (2008). [24] Jocelyn Scheirer, Raul Fernandez, Jonathan Klein, and Rosalind W Picard. “Frustrating the user on purpose: a step toward building an affective computer”. In: Interacting with computers 14.2 (2002), pp. 93–118. [25] Ben Shneiderman. “Response Time and Display Rate in Human Performance with Computers”. In: ACM Comput. Surv. 16.3 (Sept. 1984), pp. 265–285. ISSN: 0360-0300. DOI: 10.1145/2514.2517. URL: http://doi.acm.org/10.1145/2514.2517. [26] K. Velmurugan and M. A. M. Mohamed. “An Empirical Performance Metrics Measure- ment and Analysis of Software Platforms for Implementation of Web Services”. In: 2009 Eighth IEEE/ACIS International Conference on Computer and Information Science. June 2009, pp. 914–920. DOI: 10.1109/ICIS.2009.194. [27] Gregor Wagner, Andreas Gal, Christian Wimmer, Brendan Eich, and Michael Franz. “Compartmental Memory Management in a Modern Web Browser”. In: Proceedings of the International Symposium on Memory Management. ISMM ’11. San Jose, California, USA: ACM, 2011, pp. 119–128. ISBN: 978-1-4503-0263-0. DOI: 10 . 1145 / 1993478 . 1993496. URL: http://doi.acm.org.e.bibl.liu.se/10.1145/1993478. 1993496.