Creation and optimization of motion-based platform game in Unity 3D : How variated levels in amotion based platform game affects performance

Linköping University | Department of Computer and Information Science

Master’s thesis, 30 ECTS | Information Technology

2019 | LIU-IDA/LITH-EX-A--19/075--SE

Creation and optimization of

motion-based platform game in

Unity 3D

–

How variated levels in a motion based platform game affects

performance

Skapande och optimering av röresleplattformsspel i Unity 3D

Per Gustavsson

Supervisor : Aseel Berglund Examiner : Arne Jönsson

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum 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. Över-fö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 till-gä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 än-dras 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 down-load, 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/.

Abstract

With computer games getting more and more advanced with every year, game developers need to get creative to attract an audience. Throughout the years, tries has been made by moving away from the traditional gaming controller to enrich the gaming experience and to create a more healthy view upon the gaming industry. Most of these has involved the need of additional equipment to play the game, but what if all you need is the hardware in the computer? This report made findings in how to create a game that easily can be scaled by adding additional levels with custom tools for creation and modification in Unity. While only using the built-in web camera in the computer, it made it an accessible motion-based platformer game. This report also investigates the performance of the game when using these tools and the camera, as well as what is needed for improvements, including rendering and lighting effects in the game.

Acknowledgments

I would like to thank my supervisor Aseel Berglund for the continuous support. Also, I would also like to thank Erik Berglund who gave some great insights about the game. And a thank you to the game development team as well, Hjalmar Wilander and Dennis Dufbäck, for some fun times developing the game together and great laughter at the coffee machine.

Contents

Abstract iii

Acknowledgments iv

Contents v

List of Figures vii

List of Tables viii

1 Introduction 1 1.1 Aim . . . 2 1.2 Research questions . . . 2 1.3 Delimitations . . . 2 1.4 Background . . . 2 1.4.1 Previous Work . . . 2 1.4.2 Unity . . . 3

1.4.2.1 Scriptable Render Pipeline . . . 3

1.4.2.2 Lightweight Render Pipeline . . . 4

2 Theory 5 2.1 Game Design . . . 5

2.1.1 Platformer Game Design . . . 8

2.2 Game Experience . . . 9 2.2.1 Graphics . . . 9 2.2.2 Performance . . . 10 2.2.2.1 Lighting . . . 10 2.3 Interaction . . . 11 3 Method 13 3.1 Pre-study . . . 13

3.2 The Development Process . . . 13

3.3 The Game . . . 14 3.3.1 Unity Tools . . . 14 3.3.1.1 Tilemap . . . 14 3.3.1.2 Editor Windows . . . 14 3.3.2 Level Creation . . . 15 3.3.2.1 Level Structure . . . 15 3.3.2.2 Level Modification . . . 15 3.3.3 Movement Detection . . . 15

3.4.2 Evaluating Draw Calls . . . 17

3.4.3 Evaluating Frame Drops and Memory . . . 17

4 Result 18 4.1 The Game . . . 18 4.1.1 Gameplay . . . 18 4.1.2 Game Design . . . 19 4.1.3 Game Controls . . . 19 4.1.4 Movement Detection . . . 19 4.2 Level Creation . . . 19

4.2.1 Tools for creation . . . 20

4.2.2 Tools for modification . . . 21

4.3 Lighting . . . 21

4.4 Rendering . . . 22

4.5 Evaluation . . . 22

4.5.1 Frame per Second . . . 22

4.5.2 CPU Usage . . . 23

4.5.3 Draw Calls . . . 23

5 Discussion 25 5.1 Results . . . 25

5.1.1 The Game . . . 25

5.1.2 The Level Creation Tools . . . 25

5.1.3 Frames Per Second . . . 26

5.1.4 Draw Calls . . . 26 5.1.5 Evaluation of Spikes . . . 26 5.2 Method . . . 27 6 Conclusion 28 6.1 Future Work . . . 28 Bibliography 29

List of Figures

1.1 Figures of previous work . . . 3

3.1 The Development process . . . 14

4.1 Figure of the game Explanation: Transparent overlay as movement panels and white pixels being de-tected movement by the player . . . 18

4.2 The Customized Grid Brush . . . 20

4.3 Figures showing the different states of the Level Creator . . . 21

4.4 The Level Randomizer Tool . . . 21

4.5 Figures showing the difference in lights . . . 22

4.6 Line graph showing the values from table 4.1 . . . 23

4.7 CPU usage over a longer time period for one test. All tests can seen in Appendix A 23 4.8 Usage on main thread of the CPU . . . 24

4.9 Line graph showing the values from table 4.2 . . . 24

A.1 CPU Usage Graph 1 . . . 31

A.2 CPU Usage Graph 2 . . . 31

A.3 CPU Usage Graph 3 . . . 31

A.4 CPU Usage Graph 4 . . . 31

A.5 CPU Usage Graph 5 . . . 32

A.6 CPU Usage Graph 6 . . . 32

A.7 CPU Usage Graph 7 . . . 32

A.8 CPU Usage Graph 8 . . . 32

A.9 CPU Usage Graph 9 . . . 32

List of Tables

2.1 Criterias specified for GameFlow from: GameFlow: A Model for Evaluating Player Enjoyment in Games by Sweetser et. al. p. 56 . . . 8 4.1 Frames per second for the different levels with Real time lighting vs Baked lighting 22 4.2 Measurements of the draw calls . . . 24

1

Introduction

With the cost of developing a game increasing each year1_{, the importance of keeping the cost}

of development low can be key in the possibility of survival for a game development studio. For a smaller indie studio, this is crucial since budget usually is tight and development times can be long. An example of this is the game Minecraft, first released in 2009 to the public, to the be in alpha/beta versions for the next 2.5 years before being fully released2. With an audience demanding a richer gaming experience, the need for easier creation of good looking games which also has effective performance, is essential for producers to lower the cost of a game without having to compromise. As a result of this, many companies are trying to streamline their development process with tools for game creation, such as physics engines. An example of this was made by EA, announcing that a majority of their AAA3 games, from sports to first person shooters, would use the physics engine called Frostbite4, which previously only would be used in the Battlefield series.

But cutting cost isn’t all to make a profit, expectations from audiences must be met for not falling behind the competition. Making it, not only to have a cost effective game but also a game having a good experience in terms of design, feel, and not at least performance. With the gaming industry being a fast changing industry, shifting between what’s best or cool when it comes to game design. With the audience expectation of design and performance it is more an requirement than something to be impressed about. Some tries has been done throughout the years to give the audience something new. Examples of companies trying to move away from the traditional controller in early versions like the DreamEye for the SEGA Dreamcast5, to the hit success of the Nintendo Wii6and the widely produced Kinect7. As these products now being discontinued or few replaced, as for example with the Playstation

1_{https://kotaku.com/how-much-does-it-cost-to-make-a-big-video-game-1501413649} 2_{https://minecraft.gamepedia.com/Version_history}

3_{https://en.wikipedia.org/wiki/AAA_(video_game_industry)} 4_{https://en.wikipedia.org/wiki/Frostbite_(game_engine)}

1.1. Aim

Eye as a part of Sonys VR-investment8. However, according to Cooper at the site Gamerant, the reason for the downfall of the Kinect was not in the implementation but instead in mar-keting failures following the launch of the Xbox One, bundling the Kinect with the console, forcing it upon the consumers, putting a higher price tag on the console itself. Halting the sells of the Xbox One as a whole.9_{Raising the questions of what really made for all}

motion-based controller to fall of the market? And do we really need to use special hardware for playing a motion based game?

1.1

Aim

The aim of this project is to investigate the probabilities in how to create a 2D motion-based controlled platform game, utilizing the tools and editor provided by Unity. By developing a game while investigating what affects performance. And in the process create tool support for level creation, easing the further development of the game without running the risk effecting the performance of the game.

1.2

Research questions

How to develop a 2D motion-based platform game in Unity with tool support for level cre-ation; and maintain good performance with regards to:

• level creation • lights and rendering

Good performance is defined as 60 frames per second and because the game is motion based, the ability to use a web camera is needed, and therefore implies importance of rendering.

1.3

Delimitations

Since investigating how to develop a motion-based platform game in Unity, this report will center around the tool creation for creating new levels for the game without effecting the performance. Game elements such as content for the game will not be considered, nor will the design of game elements be a part of this report. Due to the game’s target platforms mostly are mobile devices, this report only will investigate the Lightweight Render Pipeline (more described in section 1.4.2.2).

The game will be a 2D game that utilizes 3D objects to align with other projects within LiU Active Lab.

The project will primarily be tested on a Lenovo IDEA-PC running a Intel(R) Core(TM) i7-3630QM CPU and a Nvidia Geforce GT 630m as the GPU.

1.4

Background

1.4.1

Previous Work

This work is based upon Niklas Erhard Olsson’s work in his master thesis [1], in which he investigates the creation of a motion-based controlled game by automating the process of generating levels. This was made in collaboration with LiU Active Lab, and their work with

8_{https://www.playstation.com/en-nz/explore/accessories/playstation-camera/} 9_{https://gamerant.com/why-microsoft-kinect-fail/}

1.4. Background

(a) Depicting the game produced by Niklas (b) Depicting the "Ghost view" of the player

Figure 1.1: Figures of previous work

movement engagement in gaming, creating different games in recent years with focus on a healthy gaming. Involving how games can be created and engage players to achieve an healthy amount of movement.

The report by Niklas resulted in a 2D game seen in Figure 1.1a, the game used standard assets provided in the old 2D Game Kit, created by Unity. Utilizing sprites as content in the game and an orthographic10 camera, making use of techniques such as parallaxing to create the illusion of depth. The game was created with the level generation in mind with the focus on player movement. Therefore, neither the graphics or the controls were a priority and thus were bare minimum. The player movement was recognized with the default web camera in the computer, and by displaying a "ghost view" of the player in the game, an example can be seen in Figure 1.1b. The game controls were implemented into the game as boundaries, rather than zones. Causing the games controller to only support being played in full screen, and with no connection with the visual aid given to the player by the UI, making for problems developing the game further.

1.4.2

Unity

Unity is an "All in one"-Editor for making digital content, which started out as a tool for cre-ating games in 3D. It has since, expanded to different markets and can now support 2D game making. The editor is available for a lot of different platforms, with compatibility for Win-dows, MacOS and Linux, with the support for building to more than 25 different platforms. Making it a good tool for the "build once, deploy anywhere"11 _{principle, creating software}

for multiple platforms without having to alter large parts of the code.12

1.4.2.1 Scriptable Render Pipeline

During 2018, Unity launched a preview of their new vision for how Unity would render the frames. Shifting from an old pipeline, being closed off from the users. To their new Scriptable Render Pipeline, giving the user more control to customize how the rendering should work for their specific game. To avoid having to force people to write their own render pipelines, Unity released two own versions; the High Defintion Render Pipeline (HDRP), made for AAA games or content in need of photorealism, and the Lightweight Render Pipeline (LWRP), created to support mobile game development as well as low end computers.

10_{Meaning all objects perspective will not be dependent upon depth}

11

https://www.enterprisemobilityexchange.com/apps/articles/behind-the-buzzword-build-once-deploy-anywhere

1.4. Background

1.4.2.2 Lightweight Render Pipeline

To ease the users adaption and aid them in the transition from the previously Built-in Render Pipeline to the new Scriptable Render Pipeline, the introduction of the Lightweight Render Pipeline was create (Out of an experimental phase as of Unity 2019.1). With focus on being lightweight, some features has been limited that is known to be performance heavy. This in-cludes limiting the use of Directional lights to only one, also limiting the number of lights that can be rendered in a scene. However with the new pipeline, improvements also was made as of how lights are calculated in the game. With the introduction of the pipeline, some new tools became available for users, including the tool Shader Graph, helping users create their custom shaders without having knowledge of shader programming. A new particle system Visual Effect Graph is also in a research phase, that will provide users to create effects with mil-lions of particles without impacting the performance negatively using the GPUs processing power instead of CPU.13

13

2

Theory

This section regards related work to this thesis, subjects touched is general principles of game design as well as specifics for when designing platform games. To get further understand-ing for the user, the topic of game experience will be explained in general concept and how graphics and performance effects the game experience. The subject of lighting in games will be shortly discussed as well as how ways of interactions can have effect on the user when playing.

2.1

Game Design

Clanton [2] clearly defines three components making up a game, Game Interface, Game Me-chanics and Game Play. With Game Interface, he describes it as everything that has something with the user to do, such as how the controls are defined or what’s displayed in front of the user. Game Mechanics is how the game behaves, such as physics or similar mechanics. And lastly, Game Play is described as the steps the player makes towards the goal of the game. Clanton also gives some key elements good games possess. The first one being to captivate the player, by for example Establish the quest and then letting the player progress at it’s own pace while also giving the new player an on-ramp learning experience. Afterwards, the game has to keep the player hooked on the game by minimizing the monotone gameplay as well as the dead ends, known to cause players to stop playing.

For determining what a great game does, Sweetser and Wyeth [3] adapts the term Flow for the gaming industry; creating the term GameFlow. They do a direct mapping from the re-quirements of flow to the game literature. Based on this, Sweetser et. al. created a new set of criteria in Table 2.1 for a game to achieve flow.

2.1. Game Design

Element Criteria

Concentration

Games should require concen-tration and the player should be able to con-centrate on the game

• games should provide a lot of stimuli from different sources • games must provide stimuli that are worth attending to

• games should quickly grab the players’ attention and maintain their focus throughout the game

• players shouldn’t be burdened with tasks that don’t feel important • games should have a high workload, while still being appropriate

for the players’ perceptual, cognitive, and memory limits

• players should not be distracted from tasks that they want or need to concentrate on

Challenge

Games should be sufficiently challenging and match the player’s skill level

• challenges in games must match the players’ skill levels

• games should provide different levels of challenge for different play-ers

• the level of challenge should increase as the player progresses through the game and increases their skill level

• games should provide new challenges at an appropriate pace

Player Skills

Games must sup-port player skill development and mastery

• players should be able to start playing the game without reading the manual

• learning the game should not be boring, but be part of the fun • games should include online help so players don’t need to exit the

game

• players should be taught to play the game through tutorials or initial levels that feel like playing the game

• games should increase the players’ skills at an appropriate pace as they progress through the game

• players should be rewarded appropriately for their effort and skill development

2.1. Game Design

Control

Players should feel a sense of control over their actions in the game

• players should feel a sense of control over their characters or units and their movements and interactions in the game world

• players should feel a sense of control over the game interface and input devices

• players should feel a sense of control over the game shell (starting, stopping, saving, etc.)

• players should not be able to make errors that are detrimental to the game and should be supported in recovering from errors

• players should feel a sense of control and impact onto the game world (like their actions matter and they are shaping the game world)

• players should feel a sense of control over the actions that they take and the strategies that they use and that they are free to play the game the way that they want (not simply discovering actions and strategies planned by the game developers)

Clear Goals

Games should provide the player with clear goals at appropriate times

• overriding goals should be clear and presented early

• intermediate goals should be clear and presented at appropriate times

Feedback

Players must re-ceive appropriate feedback at appro-priate times

• players should receive feedback on progress toward their goals • players should receive immediate feedback on their actions • players should always know their status or score

Immersion

Players should ex-perience deep but effortless involve-ment in the game

• players should become less aware of their surroundings

• players should become less self-aware and less worried about every-day life or self

• players should experience an altered sense of time • players should feel emotionally involved in the game • players should feel viscerally involved in the game

2.1. Game Design

Social Interaction

Games should

support and

create opportu-nities for social interaction

• games should support competition and cooperation between players • games should support social interaction between players (chat, etc.) • games should support social communities inside and outside the

game

Table 2.1: Criterias specified for GameFlow from: GameFlow: A Model for Evaluating Player Enjoyment in Games by Sweetser et. al. p. 56

With the help of their new concept, Sweetser and Wyath determine that by utilizing Game-Flow for analyzing games. The results yielded that a game which had been a popular game and was pre-defined as a great game in the study gained a GameFlow score of 93% as were the bad game only had a GameFlow score of 63%. Giving that a high GameFlow score will result in a better game for the player.

2.1.1

Platformer Game Design

In a detailed analysis made by Boutrus [4] posted at Gamasutra, Boutrus analyzes a large variety of games concluding in the similarities and differences in different platform games. Conclusions drawn is that all platform games has some form of collectable economy as well as the ability to jump over deadly zones. Also popular among these games were power ups, particularly those that meant an extra life or extra health points. . An insight of the most critically acclaimed games were the simplicity in the controls for the game. With the maximum required buttons for regular gameplay being three.

For making analysis of a platformer game, Smith et. al. [5] presents a way to distinguish the different elements of a level in a game and provide a way of combining them to create exciting levels. Smith et. al. presented six features conforming a platforming game, these being:

• Avatar - The character controlled by the player, such as Mario in the Super Mario game series.

• Platforms - Objects that the avatar are able to walk or run upon. These can have different abilities or serve multiple purposes e.g. item boxes. Platforms can also be time specific or only appear during certain events.

• Obstacles - A challenge in the game, such as moving enemies or static obstacles as for example spikes or other objects damaging the avatar. These objects can be destroyed once, multiple times or even indestructible. Upon an eventual destruction, a reward might be granted.

• Movements Aids - Objects helping the avatar to move throughout the level in a different way then running or jumping; an example of this can be a ladder.

• Collectible Items - Rewards during the game, either converted to points or changing the abilities of the avatar. The collectible items often also act as a guide for the player throughout the level.

2.2. Game Experience

• Triggers - Interactive objects that can alter the game in some way. Example is given such as the "blue P button" in Super Mario World, turning all the blocks into collectible coins.

Smith et. al. named a set of elements grouped together, defining them as Rhythm Groups and Cells and Portals. The rhythm groups are defined by the tempo in the game, comparisons are made towards musical pieces. Meaning that a rythm group could be fast paced or difficult resulting in a fast rhythm, followed by a slower rhythm group to let the player breath and be able to pause. The cells and portals are described as non-linearity in platformer levels, these provide the ability to change scenery in the level without overlap. An example of this is given as the pipe in Super Mario World, which allows the player to teleport to a new area. The cells also gives the player the ability to switch between different paths of the level (given that the level provides different paths of solution).

The conclusions given by Smith et. al. is that with the help of this framework, an analysis of a level can be made, assessing the difficulty of the level by determining the combination, length and tempo of the rhythm groups.

To further understand game design and what affect the difficulty of a game, Nicollet [6] states an easy guide for do’s and don’ts of game difficulty. Nicollet gave examples what makes for a difficult game but still intrigues the player to continue playing; like the feeling of "Almost there", dangling the possibility of a checkpoint in viewing distance after the completion of a difficult obstacle. Many of the rules provided in the article states the importance of time and occurrences as key aspects of difficulty. By shortening the time for a successful run as well as increasing the number of obstacles in a level will make the level more difficult, by combining these, the scaling possible of the difficulty is almost exponential.

2.2

Game Experience

Cavillo-Gomez et. al. [7] presents a model for how player experience can be measured. Core Elements of Gaming Experience (CEGE) is a model that considers two parts of the gaming ex-perience between the puppetry and the video game, together creating the total enjoyment of the video game experience. The puppetry can be seen as the right side of the experience, consisting of three parts; ownership, facilities and control. The control is based off the players sense of control of the game, meaning it’s goal and the controllers of the game. This together with the facilities, consisting of the aesthetics and previous experience. Created the sense of ownership, and how well the player felt it controlled the game and owned it’s purpose. The left side of the experience is the video game, made up by two parts. The gameplay experi-ence with the rules and goals of the game, and the aesthetics regarding graphics and sound. These two sides, the video game and the puppetry together made up the total experience, concluding that both are important for an overall good player experience.

2.2.1

Graphics

Johnson [8] analyzes the effect of 2D compared to 3D for a game in an article published at Gamasutra. In the article there is a discussion on how video games has gone from 2D graphics to 3D and the problems that have occurred in the process, but also how different game developers resolved these issues. The biggest problem with going from 2D to 3D is the camera view needs to be implemented, making some games restricting the camera movement as a result. Locking its position as in God of War to give a view in style of a cinematographer.

2.2. Game Experience

it clear that even though a game utilizes 3D graphics, it does not automatically make it into a 3D game. Examples of the difference is given with two Real Time Strategy-games (RTS): Homeworld and Sins of a Solar Empire which both utilizes 3D graphics. Homeworld being a true 3D-game, enabling the player to move its units in all direction, and Sins of a Solar Empire only allows for a movement in a single plane, were ships cannot pass each other by going above or below. Some other hybrid games are also mentioned in the article, such as Super Smash Brawl which utilizes 3D-graphics with gameplay only in a single vertical plane, but using the full extension of 3D graphics to make animations for a more alive background environment. As a whole, Johnson describes three categories to divide games into: Tile-Based, Plane and Real-World. As were Tile-Based is given examples such as Tetris; Single-Plane, Super Mario Bros. and Real World Portal. These categories names are an explanation and reflect the gameplay and not necessary the game as a whole and not literally. I.e. the game Portal has non-real-life elements but is enjoyed by players anyway with real life events of gravity and such.

2.2.2

Performance

Rushinek et. al. [9] wrote an article mapping users happiness, specifically what aspects that affects the users response to the system. They evaluated 179 computer systems with a ques-tionnaire in the Computer World Magazine about the different systems. The survey resulted in what the authors choose to call: user satisfaction inducers and reducers, in which conclusion good be drawn towards what affected the respondents experience. Their findings show that good response time was the most defined inducer in user experience, with the respondents being more satisfied when the system if it had a fast response time when doing the same task as the respondents with a slower response time. Other conclusion drawn from the results were the impact of user’s familiarity with computers, were findings showed that they had less disillusion and became less confused when they had knowledge about a computer and what it can do. The results also gave some unexpected results, as in the case of a negative effect from the use of mainframes. In consideration of previous dissatisfaction, for example from restricted access and poor customer support.

In an article by Claypool et. al. [10], they investigate how resolution affects the players in a first person shooter game. They conducted experiments in the game Quake 3 Arena, testing different maps with players and measuring their performance and experience. These tests varied in terms of resolution and frames per second rendered while the game was running, as well as for high and low contrast in the game. Their findings, concludes that in their experiment, the resolution of the game has no direct impact of the players performance in the game. Things such as high contrast mode, highlighting targets for the players had more impact than in a low contrast setting, making the target harder to identify. Their result also shows that it became simpler to play a low resolution game when stretched to full screen than in a windowed mode, creating a pixel to pixel ratio, because of the physical appearance on the screen became smaller for the player. Thus concluding that resolution only had impact when the objects became too small to see for the player. They also made comments that these findings is specifically for first person shooters which is and therefore these findings might not be applicable other genres, for example RTS-games that are dependent upon information to be given to the player in greater detail.

2.2.2.1 Lighting

In an article posted on Qubicle in 2016 discussing the differences in using realtime lighting versus baked lighting, it states that realtime lighting requires little to no process for setup but will be performance heavy due to extra drawings done by the GPU. This means that new

2.3. Interaction

computers handles this extra load but old computers will likely suffer with frame drops as a result.

To create the look of realtime lighting, the shadows and lighting can be pre-calculated using baked lighting. These calculations are stored in what’s called lightmaps, and can be seen as textures containing light information instead of usual color information (seen in regular textures). By doing this, the author estimates a performance cut of 40% for a simple wall, in comparison to only use realtime lighting.1

2.3

Interaction

Bianchi-Berthouze et. al. [11] present experiments on how engagement as well as immersion is effected by playing games in different ways. They conducted two experiments, the first being an experiment in body posture for different levels of immersion and the second in terms of engagement for players playing the same game but with different controllers. The first experiment testing immersion is done with a low-immersion "point-and-click" game and a high-immersion first-person-shooter game. The second experiment tested the engagement for users playing the game Guitar Hero with a guitar shaped controller in comparison to using the standard controller for Playstation.

In the experiment regarding immersion, the low-immersion game would result in the user shifting seating positions, alternating between a relaxed pose and a more focused, concen-trated one. In contrary to the first-person-shooter game, the user had less posture changes and seemed to be much more immersed in the game.

In the second experiment, players using the guitar-shaped controller would yield a higher engagement than the ones using the regular controller. The authors pointed out that the engagement and immersion cannot be compared with each other. Although, by having a higher engagement, the emotional level would be more easily recognized with a more clear body language showing disappointment or excitement. The experiment also showed that higher engagement was shown if the test were conducted standing up, allowing the user more freedom for expression.

Conclusions drawn by Bianchi-Berthouze et. al. is that an increased feelings of exporessions is enabled by full-body controls. Possibly giving the user a more engaged and improved experience.

In an article published by Lindley et. al. [12] they conducted experiments regarding differ-ent controllers for investigating a games social aspects as well as player engagemdiffer-ent. Their test is made by comparing a standard controller with the Donkey Konga bongo drums and investigating the levels of engagement achieved. The results presented in the article show that compared to the use of the standard controller, the use of the motion based controller, that utilizes natural movement positively increased the overall social behavior of the player. The results also show that the player engagement increased when the controllers supported natural movements. In line with previous research, making the motion based controllers to "go beyond being a clever marketing tool"2.

In a video, posted by the YouTube channel Extra Credits, they discuss the problems using motion-based controllers, in this particular case the Kinect. They based their theory upon that people generally see robots as cute or good as long as they look as a robot should. However, when they get too realistic or more humanoid-like, people tend to get freaked out because it’s

2.3. Interaction

too close to the real thing, which was their conclusion about the problems of motion-based controllers. Therefor, when controllers become to close to reality but not being the real thing, people tend to feel an unease and describe them as clunky.

In the video, they also discuss the phenomenon described as Kinesthetic Projection, which happens when the tool or controllers become an extension of the human body. It is described by examples given as when driving a car, as when a driver thinks "I’m gonna turn right", and not "I’m gonna turn the steering wheel and make the car turn right". The same goes for controllers as were the avatar becomes an extension of the player, as were the player won’t think "Pressing this button for the avatar to create this action", the player just does it; this is were the kinesthetic projection comes into play.

As a solution for this problem, they suggest changing the basic structure of how the con-trollers work, not having a functional controller layout, as with regular concon-trollers. Instead, when designing motion-based controllers, the goal is to make interactions that is fun to do with the body, and not only be functional. Thereby changing how we think about controllers, making the controllers fun and functional first and then creating a game with those in mind and not the other way around.3

3

Method

This section will touch upon the working process of this project, regarding the pre-study phase, the development process as well as the evaluation process.

3.1

Pre-study

Before the development process, a pre-study had to take place, this was created in a two step process. First step was to define a specification for the game, the idea and the requirements for the game. This step was made in the project group with a general discussion about what the requirements of the game should be and its general goal. The second step became a research phase, investigating the possibilities of the game idea, and what to make considering the different requirements.

3.2

The Development Process

To develop the game and the tools, an agile process was adapted within the project group, setting up smaller tasks to be completed each week, being combined with daily meetings to follow up. These tasks, produced during the meetings, were completed at a rating of importance for the project and co-dependence upon other tasks. Because of this process, some tasks could be left at the board for a longer period of time since more important tasks appeared during the time. The tasks were also completed by the one person who had the most understanding or the most interest in completing the task, causing some tasks to never be completed because of low interest or non essential for one of the persons individual project. Because the tasks were not divided by feature or some other common denominator, some tasks would create unexpected overlap with each other, causing merging problems later on. The development process as seen in Figure 3.1, show the different steps the game creation. Starting off with a design phase, deciding on how the feature should be designed, logically and/or aesthetically. This was followed by an implementation step, based upon the design

3.3. The Game

Design Implementation Test Analysis

Scrap

Save

Modify

Figure 3.1: The Development process

"scene view", creating an immediate test for visual effects, and a playable version of the game as well, allowing for fast tests regarding implementation requiring the game to be played. After the test phase, the tasks were to be analyzed to decide if the task were to be scrapped, saved or modified. A scrapped task meant that it was not worthwhile to explore anymore since it did not fit the purpose of the game as first intended. The saved state meant that the task was as finished as it could be for the moment and saved for later use. The modify state sent the task back to the design phase to be reworked.

3.3

The Game

The game developed is a 2D platform game following the more or less classic concept that can be seen in more famous games such as Super Mario. The controllers in the game available is running left and right as well as jumping. The goal of the game is to run from the starting point to the finish line in the shortest time possible. In the level, there is also different kinds of obstacles to pass towards the goal, varying from different kinds of enemies, to stationary objects, to non lethal obstacles.

3.3.1

Unity Tools

Since the game will be a 2D game built within the Unity Engine, tools provided by Unity such as Tilemap and Editor Windows will be used.

3.3.1.1 Tilemap

Tilemap allows the user to define an infinite grid and align objects within a 1x1 layout next to each other. Primarily a tool for creating 2D games using sprites, it can also be used to align 3D objects within a scene. Unity also introduced the Grid brush alongside its introduction of the Tilemap, making it an efficient way to paint new sprites upon the grid. Painting a large number of small sprites to give the illusion of a larger one. Unity also introduced a new type of object for calculating a collision called the composite collider, combining smaller colliders into one big, mimicking the same behavior as with the grid brush.

3.3.1.2 Editor Windows

Unity is enabling you out of box, to create your own customized tools for creating a more efficient workflow. These tools are built by scripts that can be attached to the Editor Window, creating a connection between the scripts you create and the game engine, making it possible to execute them on the fly with ease. By utilizing these types of Editor Windows, a new cus-tom tool can be built, giving you control over the game and then restrict or correct mistakes making it a more secure workflow counteracting many bugs that easily can occur otherwise.

3.3. The Game

By utilizing the customization abilities, the level creation will be aided by using a custom tool created in an Editor Window to help give the level creator more ability to quickly alter the structure of the level as well as keep the structure of the level intact.

3.3.2

Level Creation

This section will cover how a level is set up for the game and what methods has been used to create them.

3.3.2.1 Level Structure

Since the game is a 2D platform game, the movement is mainly horizontal. Due to this, the path of the player can be seen as running in a single plane, limiting the characters movement. The level can then be seen as a grid layout from a 2D perspective. By creating a second vertical grid, this act as a background for creating decoration close by. Then have a third grid to act as a horizon. Making it possible to place objects far away in the distance, giving the illusion of an endless world.

3.3.2.2 Level Modification

Because the use of the grid system the level can be painted with 3D-objects using a modified version of the grid brush, for easy creation and modification of the levels. The drawback of using this technique of painting objects, is that the number of objects will scale with the size of the level. Since one object is 1x1 in the grid, the size of the level will indirectly correspond to the number of objects in the scene; 100 square long level will equal to an approximate of at least 100 objects in the scene. A benefit to this though, is that, with an appropriate model, you can create varied objects acting as a larger one with ease, using it as a brick in a wall. Making it possible to create varied levels without having to create a new model for every specific scenario.

With the level structure, being the multiple object approach, it is a simple way for repeating an action is to make a tool for it. By combining scripts with an EditorWindow, actions can be bound to be carried out with a press of a button. Therefor, many of the custom built functions for the level creation will be within the same EditorWindow, making it more accessible for the user and minimizing the need of having multiple windows taking up screen space.

3.3.3

Movement Detection

To detect player movement, the view of a camera has to be processed to result in useful information of player movement. This can be described as a 2 step process, altering the picture from the web camera with two passes:

• Frame Difference: Compares the new frame image with the previously frame, by com-paring the difference, the movement can be extracted. Creating a white description of the movement made by the player.

• Compression: To use the data in a more efficient way, the image created by the Frame Difference Pass is then compressed into a much smaller image, utilizes a bilinear com-pression, decreasing the scale of the image horizontal and vertical size.

3.4. Evaluation

be used that has the compressed texture to be enable movement calculations to be carried out on fewer pixels. To measure movement, each pixel’s alpha level will be investigated to determine if a movement was created.

3.3.4

Lighting

This section will regard the setup for lighting in the game as well as the materials, but also regarding the post processing setup.

How to create good aesthetics for low poly graphics was inspired by an article at the blog Sunday Sundae [13]. In the article, they discuss some common mistakes occur when creating low poly graphics, and also some do and dont’s for the process and what makes the differ-ence. They also go more in depth on how to setup lighting, materials as well as post process to get the desired look of your game.

The lighting for the different levels will be created by two different lighting settings to be able to measure the differences light methods. The first is a real time scenario and the second a scenario with baked lighting. With the introduction of the Lightweight Render Pipeline mentioned in 1.4.2.2, some restrictions has to be made, for an example, the use of only one directional light.

The different scenarios will be created by using a standardized lighting, achieving the in-tended look, using a directional light acting as the sun, and then additional light will be the specific scene light provided by Unity. The scene light will be acting as the Skydome light, described in [13].

3.4

Evaluation

To evaluate this game, some metrics will be applied for the system. The most important being frames per second, which has been chosen as the metric for what good performance is. The second metric is the number of draw calls, this has a small correlation with FPS but not necessary. An evaluation for frame drops or spikes will also be considered as well as memory management.

The evaluation will be carried out upon three different levels:

• Minimal level: A level with only the barebone blocks for playability.

• Normal level: A level that is mimicking what a real level could be in the final game. • Maximum level: A level that has the a lot of blocks that is unnecessary for the game.

For these levels, a version will be made with real-time lighting as well as a version using baked lighting.

3.4.1

Evaluating Frames Per Second (FPS)

To evaluate the frames per second, there are many ways it can be achieved. For example you can use a third party software such as Fraps1_{or software built by graphics cards manufacturer}

3.4. Evaluation

like GeForce Experience2or script a customized implementation to foresee special needs. The formula for frames per second are non the less is the same:

f ps= # f rames

#seconds (3.1)

The problem though with using third party software is that the FPS is calculated at the mo-ment, making it difficult to get an average and depending on frame drops and spikes can give very different measurements.

To mitigate spikes or having too small sample size, a customized implementation has been chosen, counting the number of frames during a longer time period while playing the game, applying the formula for countering any sort of miscellaneous behavior by the game. To measure the FPS of the game, a timer will be started when entering a level in the game, to later be turned off when exiting the level. The FPS will then be calculated for the whole duration of the level.

For the evaluation of FPS, a pre-built version of the game is used to mitigate any problems generated from running the game in the editor.

3.4.2

Evaluating Draw Calls

To evaluate the number of draw calls in a scene, a tool called Frame Debugger provided by Unity will be used. This tool lets you freeze the game and investigate the specific draw calls that is called each frame, as well as look at the order of which objects are drawn and how many draw calls each process or object requires. To evaluate the number of draw calls, the counter provided in the Frame Debugger will be used, and thereafter measuring the differ-ences in the test scenarios.

3.4.3

Evaluating Frame Drops and Memory

To look for frame drops in the game as well as for the memory, the tool Profiler provided by Unity will be used, this allows for a time line to be seen over systems usage, for example the CPU usage over time or memory consumption which will be investigated in this case.

4

Result

This chapter will present the results from the projects. As well as go over the results regarding the game, the level creation with modification and frames per second.

4.1

The Game

Figure 4.1: Figure of the game

Explanation: Transparent overlay as movement panels and white pixels being detected move-ment by the player

4.1.1

Gameplay

The game produced for making the analysis did indeed become a 2D platform game as in-tended with a motion based controller. The goal of the game is to get to the finish point from

4.2. Level Creation

a starting position. To keep up replayability in the game, a level will also track time as well as display it to the player. This can be seen as a score for the the level but has no effect on game-play. To aid the gameplay, the player can collect flowers (i.e. coins) during a level. When enough flowers has been collected, a new life will be rewarded. The purpose of the flowers is to aid the player with difficult parts of the level, giving the player extra chances to complete a level without restarting. To aid the player further, other collectibles can also be collected, these are a shield as well as an extra life. The shield will grant protection from dying when a player takes damage for one time, up to three shields can be carried at the same time. If a fourth shield is collected, the player will become invulnerable against damage from enemies.

4.1.2

Game Design

The game is not a classical 2D game in the terms of graphics but in the terms of gameplay. By utilizing 3D-objects and the richness from a perspective camera, a decision was made to make the shift from 2D towards 3D. A difference from this being a 2D game utilizing 3D objects, in comparison to a 2.5D game (or pseudo 3D) is that 2.5D rely upon 2D graphics to make it look like a 3D game.

4.1.3

Game Controls

To make the game playable with movement, an overlay was created in the games UI, dis-playing the recognized movement of the player. To play the game, there is three interactions available in a level; going right, left or jump. To move right or left, the player must continu-ously create movement in either the right or the left zone. If the movement stops the character will slow down to a standing position and accelerate once the movement starts again. To gen-erate a jump, the player must create a large movement in the middle of the screen where the jump zone is, this zone has a higher threshold for interaction then the left or right zone to force the player to engage more for a jump and also mitigate the risk of accidental jumps.

4.1.4

Movement Detection

To detect movement in the game, the layout of the game was separated into zones as seen in Figure 4.1. These zones acted as interaction panels triggering a signal if a large enough movement was detected. The zones also make up the boundaries for the controls. Because of Unity’s UI structure, the UI for the zones has the same scale as the texture calculated for movement. Each pixel can be mapped to the following zone. As seen in Figure4.1, the colli-sion texture is a 32x24 pixel texture, a scale of 1/10 in comparison to the texture rendered to display the movement. By making this compression of the textures, the number of iterations go from 320 ¨ 249=76800 to 32 ¨ 24=768 which is a big difference in number of pixels.

4.2

Level Creation

One part of this project was how you can aid the user in making levels, this by making a tool for creating levels more simple. The reason for investigating this project specifically in Unity was because of its abilities to create a workflow with prefabs, making it possible to store and use previously created game objects. The level creation is separated into two parts that can be used individually, the first part is for creating new objects for the level, adding more content or altering the layout. The second part is modification, altering the existing objects in the scene to give a feeling of a more organic and natural world, an example is to randomize the rotation of all trees in the background.

4.2. Level Creation

4.2.1

Tools for creation

To create the level in an efficient way, a customized tool was created using the grid brush with the extension of a prefab brush to aid the user with creating levels. The purpose of this tool is to help the user isolate the different grids in a level to maintain the workflow and help the user to see more precisely the content in the separate grids.

The grid brush made up for a good base structure, but by customizing the settings, an im-proved version of the grid brush was created. Functionality added can be seen in Figure 4.2, a setting for creating larger chunks of blocks with the scaling of the X&Y-axis. As well as the possibility to choose which type of block you want, ranging from a grass block, a dirt block and a slope block (with the choice of left and right). Examples of the different types of blocks can be seen in game in Figure 4.1.

Figure 4.2: The Customized Grid Brush

The use of the prefab brush do make the creation of a level a fast task. With the ability to create for example an 10 units long platform, the user can paint a 10 units long platforms in a matter of seconds. The use of the grid system also allows for perfect alignment between objects (given that the objects has the correct size). To get a more organic feeling to the level, 5 different blocks were created to be used with the brush. Furthermore, because of a built-in randomizer in the tool, the game objects will be evenly spaced out to give the illusion of a more organic level.

To easier separate the different levels in a scene, the ability isolate the different levels is made in an Assistant tool, as seen in Figure 4.3. To ensure playability, the reset button will be red (Figure 4.3b) when a layer is hidden and green when everything is playable layer-wise.

4.3. Lighting

(a) The Level Creator (b) The Level Creator with problem

Figure 4.3: Figures showing the different states of the Level Creator

4.2.2

Tools for modification

To modify the existing level created with the brushes, another tool was created that can alter the level. This tool was divided into different sections, as it effected different parts of the level, to give the user experience more control. To conserve time, the tool acts in a mass action fashion, depending on which button is pressed.

As seen in Figure 4.4, the tool has two different actions, scale objects and rotate object. With both the scale and rotation, the user can choose how much difference they want with the scale and the rotation. This gives the ability to either have a big variation in the level or a smaller one, depending upon preference.

Figure 4.4: The Level Randomizer Tool

4.3

Lighting

The lighting in the game is clearly necessary as seen in Figure 4.5. Figure 4.5a is made without any additional lights or Post Processing. However, there is an environmental light in the level due to Unity restrictions. This light was set to a darker grey to be as neutral as possible. In Figure 4.5b, there is a directional light acting as a sun as well as an environmental light.

4.4. Rendering

pleasing look. In the figure, the game also has a fog to give the illusion of haze for the game, since it’s a reoccurring natural event and also blends well with the background.

(a) Game without any lights (b) Game with lights

Figure 4.5: Figures showing the difference in lights

4.4

Rendering

With the new SRP, and more specifically LWRP, the rendering has been improved for low lighting scenarios as well as for reflections. With the LWRP, you also get full access to making interruptions in the regular render pipeline, which can set some different effects to the looks of the game. This also give us the opportunity to create the Ghost player seen in Figure 4.1 without having to worry about effecting any other aesthetics of the game.

The restrictions given by utilizing the LWRP has not created any remarkable drawbacks for the project, but instead it has helped to gain control over the rendering pipeline. As well as creating opportunities to use new tools provided by Unity and unique effects usable in the future.

4.5

Evaluation

4.5.1

Frame per Second

This section regard the measurements of frames per second in the game.

Real time Baked

Test Minimum Normal Maximum Minimum Normal Maximum Movement

1 58.7 53.2 46.2 60.3 50.5 42.7 Normal 2 55.1 47.2 43.4 58.4 49.0 42.1 Normal 3 57.6 50.5 43.8 59.2 52.1 46.0 Normal 4 59.6 48.2 45.0 53.9 48.4 42.3 Normal 5 57.8 50.1 43.6 56.1 50.1 41.9 Normal 6 57.2 48.7 41.4 58.6 47.4 42.5 High 7 61.4 51.3 46.3 60.9 51.6 43.3 High 8 55.1 47.2 41.4 61.8 53.6 46.7 High 9 62.7 52.2 46.4 60.7 50.5 42.5 High 10 61.3 51.5 42.7 58.3 49.0 41.9 High

Table 4.1: Frames per second for the different levels with Real time lighting vs Baked lighting As seen in Figure 4.6 (for exact values, see Table 4.1), there is a loss in fps when the num-ber of objects in a scene are higher. Decreasing about 10 fps between the minimum level to normal, and then again comparing to maximum. However, there is almost no difference in performance between using real time lighting compared to using baked lighting.

4.5. Evaluation 40 45 50 55 60

65 Real time Minimum

Real time Normal Real time Maximum Baked Minimum Baked Normal Baked Maximum

Figure 4.6: Line graph showing the values from table 4.1

4.5.2

CPU Usage

Figure 4.7 shows a screenshot from the Profiler tool, where there is a spike in the beginning of the graph, but not later on. As seen in the figure, the CPU usage is not in so high demand, running at 5 ms (or 250 fps) according to the statistics provided with the Profiler tool. The spike however is crippling the system remarkably with 16 ms (or 60 fps). These values are to be considered a reference point instead of the actual values when cross referencing with the values seen in Section 4.5.1.

Figure 4.7: CPU usage over a longer time period for one test. All tests can seen in Appendix A

Figure 4.8 displays a screenshot of the different usages of function calls made upon the main thread of the CPU. The figure is read in the order of the main function at the top, to the sub-functions further down in the figure, in the order they’re called upon. The fig-ure shows that from the PlayerLoop is taking a total 19.28ms, in the bottom we see that the Semaphore.WaitForSignal is taking 17.34ms of the 19.28ms in total. This call is made from the Gfx.ReadbackImage, caused upon the need of transferring the web camera information from the GPU to the CPU.

4.5.3

Draw Calls

4.5. Evaluation

Figure 4.8: Usage on main thread of the CPU

systems due to these dynamic objects. There is almost double the amount of draw calls for the regular played version of the game, versus only looking at the draw calls in a level. This due to some extra dynamic objects needed to be drawn, examples of these are the main character needing 10 draw calls. An explanation of this being not optimized for the playable version but instead is still in development mode, allowing for easy modification.

Real time Baked

Mode Minimum Normal Maximum Minimum Normal Maximum

Playable level 66 67 68 72 65 74

Unplayable level 30 30 30 32 35 35

Table 4.2: Measurements of the draw calls

20 40 60

80 Playable Level with

Real time Playable Level with Baked

Unplayable Level with Real time

Unplayable Level with Baked

5

Discussion

This chapter discusses the results of this report as well as the method used to create them.

5.1

Results

This section will discuss the different results of this thesis. What the results of the actual game was, the performance and making of the level creation tools. This section will also talk about the results of the frames per second measurement as well as draw calls and the evaluation of spikes.

5.1.1

The Game

The game created by this project is very close to being a finished game, complete with many components that are not necessary to this thesis. This including parts involving more ad-vanced gameplay, such as the shields, that are an important part of the game before a possi-ble release. Other things to consider is the menu system, which is a nice touch, but was time consuming in terms of working hours for no difference in the gameplay. However, the game is a good presentable prototype ready for real game testing.

5.1.2

The Level Creation Tools

The tools for making level creation faster and more intuitive was an implementation made from existing tools from Unity. This made for a quick start with the customized implemen-tation of the tool, but also limiting in terms of trying to understand the fundamentals of the tool and how it could benefit this project. The implementation of this tool did however work very well after the modifications such as the multi-paint for the blocks, making it able to fill a base very quickly.

Because of the simplicity of the tool, and the abilities of multi-painting different elements. Enables the possibility to create and modify rhythm groups to scale the difficulty as you go.

5.1. Results

The drawbacks of this tool is when creating a level with many gameobjects, it quickly be-comes bloated and the hierarchy can be hard to get a grasp upon. Since the tool is made for creating a pure 2D-game with sprites, the performance when working with this does not suffer from multiple edits, due to the compression to one sprite. As opposed to this imple-mentation, since 3D objects is more performance heavy then working with sprites, and also does not have any compression into one object.

The performance issue of altering multiple gameobjects at the same time, was more promi-nent with the modification tool. When the number of gameobjects to be effected by the tool got bigger, a slight lag did occur when triggering an action. Although, in my opinion, the lag is tolerable since the use of the modification actions is not meant to be repeated in quick succession and executed multiple times during the creation phase of the level, but instead as a finishing touch.

5.1.3

Frames Per Second

The result from the measurement for frames per second was interesting in terms of showing no direct difference between running the game with real time lighting compared to baking the lighting beforehand. The difference is instead shown that the number of objects in a scene seems to have more impact upon the performance of the game rather than baking the lights in advance. In the games test maps, there is no visual difference between these two scenarios. Therefor, trying to bake the lights is an unnecessary step to do.

In terms of performance, it is not a satisfying result that the number of objects is causing the frames per second to drop when using the grid brush. A probable cause of this is that when using the grid brush, the number of objects needed to process becomes very large. Even due to batching together static objects, making it able to render simultaneously, the number of objects in a scene still has an impact on the performance.

5.1.4

Draw Calls

When investigating the number of draw calls, some questions can be raised towards why the baking of lights should be used. When running the game in a normal play mode, the number of draw calls is practically the same for the real time and the baked lighting scenarios. This due to the fact that dynamic objects, such as the main character, is casting shadows on the static objects causing the same number of draw calls for both the scenarios.

Another thing to take into consideration is the significant drop in the number of draw calls when only displaying the level without running the game as a whole. Dropping from around 68 draw calls down to around 32 draw calls, meaning many optimizations can be done in terms of the whole game when it comes to draw calls. For example the main character is in need of 10 draw calls instead of what could have been one. Making up for around 15% of the total number of draw calls in the game, which is huge!

As stated in 2.2.2.1, the number of draw calls should be almost doubled when using real time lighting in Unity, raising the question if the settings in these test were sub-optimal using the baked lighting. Or if Unity has made improvements with its real time lighting process since the article was published, as well as if improvements is made when using LWRP.

5.1.5

Evaluation of Spikes

The results of the investigations for miscellaneous spikes in the game did show an initial spike but in general did not show multiple spikes. For this particular investigation, no immediate

5.2. Method

conclusions can be drawn from the graph in Figure 4.7, more than that nothing in the game should cause any huge spikes or unnecessary delays in the game.

However, you see a clear spike in Figure 4.8 appearing on the main thread of the CPU. During closer investigation described in the 4.5.2, the spike is caused by the information transfer from GPU to the CPU. Creating a bottleneck of the system, independent of if the rest of the game is running smoothly.

5.2

Method

Since this project started out from an old thesis work, many of the underlying components where pre-installed. During this project though, there is little to nothing that has survived to the current version of the game. This has probably made for a slower work than if the project would have started from scratch. This due to that we tried to preserve as much of the old project to not "invent the wheel" but later had to toss it for another solution, slowing down the progression rather than speeding it up.

The chosen method for the project, with the daily project meetings and creating on the fly, was an easy way to start. But without having a clear goal or end product to work towards, the method became cluttered and hard to keep on track of what had to be done to move forward with the project. A method could instead have been to set up a clear goal, how the finished project would be, and then work with a requirement specification for the game. Separating essential tasks and what would be a nicer touch to the game, then stick to the plan without revisions, as long as not necessary for the project. This could have saved a lot of time when working on tasks, that later on got scrapped or reworked, making previous work unnecessary.

When working with Unity, there are often updates to improve or fix bugs with previous versions of the Editor. Since of using a liberal agile method in the project, the use of updates could be spontaneous and with a "try and error"-mentality. Causing many of the updates from Unity to not make larger differences for the project. However, bigger updates would break the project and render it not usable, causing a lot of problems that needed to be fixed that were not broken before the update. A smarter move would probably have been to lock the Unity version in the beginning of the project to the end, only allowing for updates if it was absolutely necessary. An example of problems occurring due to an update, is the upgrade towards using the LWRP during its experimental phase. This changed the previously used system calls, causing the web camera interaction to fail. The same problem then occurred when upgrading the Unity Editor to the 2019 version, bringing LWRP out of experimental and changing its complete structure. Causing many hours to be put down in order to fix something that was not previously broken. In retrospect, a locked Unity version would have given a lot less stress on the project. Especially because the large changes happening and with the new render pipeline being such a new feature, the scarce documentation available made the hours to adapt the project much longer than expected.

6

Conclusion

The task to create customized tools in Unity, has good support within the editor with well documented instructions, making the creation easier than other tasks. The tools to aid the level creation could shorten the time creating a level significantly and making for a more slimmed workflow. Furthermore, ensuring the consistency of distance is a great way of keep-ing the flow of the game intact.

With the use of this tool, when creating the game in hand, the number of objects needed became a bottleneck in the project when the scale of the level increased. The tool makes for an easy way of creation but will lack in performance later on. Due to the need of web camera, causing a stall in the CPU, the number of objects needed to be kept at a minimum for creating the smallest stall possible. Until another solution is given for the calculation of player movement, the stall will be the biggest bottleneck of this project.

6.1

Future Work

For future work, an investigation is needed into developing a new method to transfer the web camera information from the GPU to the CPU without causing the stall found in this report, in order to really find the true potential of these tools. To avoid having a bloated hierarchy caused by the brush tool, another potential future work could be on how to group the blocks together, effectively grouping them together creating bigger platforms that can be moved within the game.

Bibliography

[1] Niklas Erhard-Olsson. “Procedural Generation of 2D Levels for a Motion-based Plat-former Game in Unity with Large Amount of Movement”. MA thesis. Linköping Uni-versity, Human-Centered systems, 2018, p. 53.

[2] Chuck Clanton. “An Interpreted Demonstration of Computer Game Design”. In: CHI 98 Conference Summary on Human Factors in Computing Systems. CHI ’98. Los Angeles, California, USA: ACM, 1998, pp. 1–2.ISBN: 1-58113-028-7. DOI: 10.1145/286498. 286499.URL: http://doi.acm.org/10.1145/286498.286499.

[3] Penelope Sweetser and Peta Wyeth. “GameFlow: A Model for Evaluating Player En-joyment in Games”. In: Comput. Entertain. 3.3 (July 2005), pp. 3–3.ISSN: 1544-3574.DOI: 10.1145/1077246.1077253.URL: http://doi.acm.org/10.1145/1077246.

1077253.

[4] Daniel Boutrus. A Detailed Cross-Examination of Yesterday and Today’s Best-Selling Plat-form Games.URL: https://www.gamasutra.com/view/feature/130268/a_ detailed_crossexamination_of_.php.

[5] Whitehead Jim Smith Gillian Cha Mee. “A Framework for Analysis of 2D Platformer Levels”. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. ACM, 2008, pp. 75–80.URL: https://core.ac.uk/download/pdf/21748965. pdf.

[6] Victor Nicollet. Difficulty in Dexterity-Based Platform Games. URL: https : / / www . gamedev . net / articles / game - design / game - design - and - theory / difficulty-in-dexterity-based-platform-games-r2055/.

[7] Eduardo H. Calvillo-Gámez, Paul Cairns, and Anna L. Cox. “Assessing the Core Ele-ments of the Gaming Experience”. In: Game User Experience Evaluation. Ed. by Regina Bernhaupt. Cham: Springer International Publishing, 2015, pp. 37–62.ISBN: 978-3-319-15985-0.DOI: 10.1007/978- 3- 319- 15985- 0_3.URL: https://doi.org/10. 1007/978-3-319-15985-0_3.