Mazekeeper A Real Time Strategy Browser Game

Miguel Francisco Alegra Rebocho de Oliveira

Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering

Supervisor(s): Prof. Pedro Alexandre Simões dos Santos

Examination Committee

Chairperson: Prof. Alberto Manuel Rodrigues da Silva Supervisor: Prof. Pedro Alexandre Simões dos Santos Member of the Committee: Prof. António Manuel Ferreira Rito da Silva

August and 2017 ii Acknowledgments

I want to thank, my family for their patience, support and participation in this project.

Pedro Santos, for his guidence and advice during the entire project, for his participation, and most important, for his exigency.

Joao˜ Dias, for his participation and advice during the project development. the group Logoff for developing the music for the last prototype. and all my friends that participated during the testing phase, for their feedback and their enthusiasm.

iii iv Resumo

Este documento apresenta uma analise´ do desenvolvimento de um conceito de jogo bem como o sistema desenvolvido para suportar esse conceito. E´ feita uma contextualizac¸ao˜ que permite perceber qual as caracter´ısticas, a plataforma, a tecnologia e os jogadores alvo do jogo desenvolvido. Foram desenvolvidos varios´ prototipos´ iniciais do jogos que permitiram tirar conclusoes˜ sobre o conceito, usabilidade e viabilidade do projeto em questao.˜ Apos´ apresentados inqueritos´ e apos´ a participac¸ao˜ em reunioes˜ com um grupo de jogadores, foram extra´ıdas informac¸oes˜ sobre as diversas areas´ do projeto. Uma vez que o jogo apresenta uma componente multi-jogador, sao˜ apresentados os requisitos bem como uma soluc¸ao˜ arquitetural para a implementac¸ao˜ do sistema. Tambem´ e´ feita uma analise´ mais exaustiva a` informac¸ao˜ gerada pelo sistema desenvolvido bem como a opiniao˜ dos jogadores acerca das varias´ versoes˜ do prototipo´ final apresentadas. Tal informac¸ao˜ permitiu a refactorizac¸ao˜ de conceitos e de partes do sistema.

Palavras-chave: Jogo Virtual, Jogos de Estrategia,´ Tower Defense, Conceito de jogo, Sys- tema de Jogo, Desenvolvimento de um jogo

v vi Abstract

This document presents an analysis of the development of a game concept, as well as the system developed to support that concept. It is made a contextualization that allows us to understand what are the characteristics, platforms, technology, and target players of the developed game. Several initial prototypes were developed, which allowed drawing conclusions about the concept’s usability and the viability of the project. After some surveys and after participating in some meetings with the game focus group, there was extracted information about the different components of the project. The game presents a multi-player component, it is also presented what are the requisites as well as the architectural solution to the system implementation. This way, a more exaustive analysis of the information generated by the developed system was made, as well as the users’ opinions about the prototype presented. Such information allowed the redesign of parts of the system.

Keywords: Virtual Game, RTS Game, Tower Defense Game, Game Concept, Game System, Game Development.

vii viii Contents

Acknowledgments...... iii Resumo...... v Abstract...... vii Nomenclature...... 1 Glossary...... 1

1 Introduction 1 1.1 Motivation...... 1 1.2 Goals...... 2 1.3 Outline...... 2

2 Related Work 3 2.1 Real Time Strategy Games...... 3 2.1.1 Concept...... 3 2.1.2 History...... 4 2.2 Tower Defense Games...... 7 2.2.1 Concept...... 7 2.2.2 History...... 7 2.3 Browser and Mobile Games...... 10 2.3.1 Browser...... 10 2.3.2 Mobile...... 12 2.4 Target Players...... 14 2.5 Technology...... 15 2.5.1 Networking...... 17 2.5.2 Game Engine (Unity)...... 19

3 Game Concept 21 3.1 Player City...... 22 3.2 Player Lane...... 22 3.3 Map...... 23 3.4 Other Game Features...... 23 3.4.1 NPC Villages...... 23

ix 3.4.2 Heroes...... 24 3.4.3 Events...... 24

4 Architecture of the Solution 25 4.1 Quality Attributes...... 25 4.2 Project Structure...... 26 4.2.1 Front End (Web Page)...... 27 4.2.2 Game Application...... 27 4.2.3 Back End (Game Server)...... 28

5 The First Iteration of the Implementation 31 5.1 Implementation of the Prototypes...... 31 5.2 User Testing...... 33 5.2.1 Testing Results...... 34

6 Second Iteration of the Implementation 41 6.1 City gameplay development...... 42 6.2 Lane gameplay development...... 43 6.2.1 Battle System...... 44 6.3 Map gameplay development...... 45 6.4 Good Programing Practices...... 48 6.5 Analytics System...... 48 6.5.1 Second Prototype Analytics...... 48 6.6 Final Prototype Survey...... 56

7 Conclusions and Future Work 61 7.1 Conclusions...... 61 7.2 Future Work...... 62

Bibliography 66

x Chapter 1

Introduction

Games have been a constant preference throughout Human history, from the table games still played today to the virtual games that appeared with the personal computer and consoles. The World Wide Web is no exception. Since the early stages more and more complex web and browser games have been developed transforming the game paradigm that existed. Single player games or limited multi- player games, that required a physical presence, started to be put aside when massive online games came into play. The interaction between different players in a game brought about a new way of fun, turning games into social experiences N. Ducheneaut, N. Yee, E. Nickell, and R. Moore[2006]. This project presents a concept that provides new and creative ways of exploring old features. Based on old games, it is intended that Mazekeeper will provide the old fun in modern ways.

1.1 Motivation

Strategy browser games are appreciated by a large community of players. Due to their casual game style, simplicity or even their easy access, this type of game has proven to have a loyal player base. However, having a large player community that plays a game genre in a certain platform is not enough to ensure the success of any project. There are certain aspects that present a good motivation to enrol in such a project. Playing has became more of a social activity. Games with a good concept and good game me- chanics have a wider community than ever before. People seek not only the game experience but also the social activity Vanhatupa[2010]. Recently, there has been a gaming boom. More and more games are published every year for the most diverse platforms. As more and more people start playing, more games are created to explore their profitable side. One of the reasons for this might be the game availability that exists D. Williams , N. Martins , M. Consalvo , and J. Ivory[2009]. The existence of a wider range of platforms that support virtual games makes them more acces- sible than ever. With the increase of deployment of platforms that have high computational power, such as current smart phones, more complex games can be developed. The availability of new and more powerful game engines has made game development easier.

1 With less implementations required to develop a more complex game concept, more conplex games have appeared on the market.

1.2 Goals

The main goals for this project are the following:

1. To create a fun and solid game concept that is compatible with the game genre and game platform indicated in the thesis proposal.

2. Present new features not seen in the same game genre for the target platform. Innovation is a key factor that leads to project success, and, thus, presenting new appealing features will be a highlight of the developed project.

3. Having a fully-functional and tested prototype of Mazekeeper. The system should be able to pro- vide the desired gameplay to all players that decide to enrol in this adventure. It should also present new characteristics from the existing trending games.

4. Being able to extract analytics about user activities in order to analyse possible game improve- ments and to be able to balance different aspects of the game.

1.3 Outline

This theses is organized as follows: Section 2, Related Work: This section puts into context the work that has been developed. It will focus on previous game concepts that have been published and brought new successful features and mechanics. It also presents a briefly description of the players and the technology available to develop this work; Section 3, Concept: This section describes the game concept that was achieved, as well as the features and mechanics created to reach the achieved game concept; Section 4, Architecture: This section describes how the system was planned and what were the main concerns about its quality attributes. It will also explain the interaction between different parts of the developed system and how each one of them plays its role; Section 5, Implementation and User Tests of the First Iteration: This section explains the implementation details as well as the development process of the first low fidelity prototypes. It also presents the information extracted from the first tests with users; Section 6, Implementation, Tests and Analytics of the Second Iteration: This section explains the implementation details as well as the development process of the final prototype. Also, all analytics and user tests are assessed in this section; Section 7, Conclusion and Future Work: The conclusions of the work done will be pointed out, as well as possible future implementations and ideas that will improve not only the game play but the game concept.

2 Chapter 2

Related Work

This chapter will start contextualizing the RTS (Real Time Strategy) games industry and a specific sub-genre of Tower Defense games. The following factors of those themes will be analyses, as will the trends in the current market, a detailed characterization of the target players and the web technology available to fulfill the game requirements.

2.1 Real Time Strategy Games

2.1.1 Concept

Typically, the gameplay of a game in this genre consists in providing the management of a “nation” to a players group. RTS represents what is known as the 4x: eXplore, eXpand, eXploit and eXterminate. These components create the foundations for what is nowadays perceived as an RTS. The ability to explore, expand, exploit and exterminate, are represented in the RTS genre game loop presented in Figure 2.1.

Figure 2.1: Generic RTS game loop.

3 Players are provided with simple options that will enable them to choose their strategy from a set of interactions. There are RTS games that give more freedom to players and thus provide them with extra options such as, upgrades, Npcs (Nonplayer Characters) or extra objectives.

2.1.2 History

The RTS industry started in the early 80s, with a set of concepts adopted from various games. A chronology of the games and features that brought this genre to life will be provided.

[1982] Cytron Masters developed by Ozark Softscape: In this game, it was given the player a spaceship fleet that he could control individually in order to defeat enemy fleets. This kind of game action was more like a turn based game. However, it is important to point out that this game-play feature, was due to the fact that, processors from that age, were slow (Figure 2.2).

Figure 2.2: Cytron Masters game interface.

[1982] Legionnaire developed by Chris Crawford: This game offered a completely real time strategy game play. The game started with a map view of the terrain, where the player could see where his, and his enemies, troops were positioned. The player could select each unit by clicking on it and then, give an order by clicking on the place to go, or by clicking on an enemy unit the player wished to attack. However, this game lacked on resource collection and economy concepts.

[1984] The Ancient Art of War developed by Evryware’s: The Ancient Art of War present a similar gameplay to Legionnaire, however with some small differences, like the player could choose the which enemy he would like to face (like a mission system) (Figure 2.3).

[1988] First Queen developed by Culture Brain and Kure Software Koubou: First Queen is more like a strategy RPG (Role Playing Games) where the player control a character and recruit soldiers which could help the player during his game play time.

[1989] Herzog Zwei by Technosoft: Herzog Zwei also brought unique game play ideas to the genre in analysis. In this game the player controls an airship and specific areas by dropping units on the planned locations. This game also inspired one of the game icons of the RTS genre, Dune II.

4 Figure 2.3: The Ancient Of War game interface.

[1992] Dune II: The Building of a Dynasty developed by Westwood Studios: The game develops its action in a sci-fi scenario. In this scene, players start the game with a primary base building, and some troops to explore the map. Initially, only the place where the player’s base is located is revealed on the map. But, as the player moves it’s units across the map terrain, vision of that area is displayed on his map. The player can choose between a set of predefined buildings, by selecting which building he wants to build in the city base, accordingly to the player’s strategy. There are buildings that gathered resources, buildings that deployed troops, and buildings needed to improve some technologies. New buildings would be unlocked, if the player completed higher missions that unlock new technologies and improvements. Troops are controlled by selecting them with the mouse and clicking on the map where the player wished the troops to be moved or to attack. Each level represented a new challenge for the player, by presenting him harder enemies or specific strategies that the player had to follow (Figure 2.4).

Figure 2.4: Dune II game interface.

[1994] Warcraft: Orcs and Humans developed by Blizzard Entertainment: Warcraft have the same game play mechanics as Dune II, however it offered new concepts and a new game style. By doing so, Blizzard Entertainment was able to implement more content into the game, like monsters with

5 special abilities and new buildings as farms. Those new buildings implemented approximated the game of a complete fictional society, not only in armies (Figure 2.5).

Figure 2.5: Warcraft I game interface.

[1997] Age of Empires by Ensemble Studios: This game brought new mechanics in terms of tech- nologies and improvements that the player could use to get new buildings or improved units. It also explored innovative concepts, like the relics gold revenue that gave the game extra bonus objectives that the player could explore (Figure 2.6).

Figure 2.6: Age of Empires I game interface.

In order to provide an overview of the innovations presented in each game refered above, it is displayed a comparison table bellow.

6 Year Name Company/Developer Innovations 1982 Cytron Masters Ozark Softscape Strategic view of a battle. Battle orders to individual units. 1982 Legionnaire Chris Crawford Map overview. 1984 The Ancient Art of War Evryware’s Allowed players to choose be- tween enemies. 1988 First Queen Evryware’s, Culture Brain and Mission system. Kure Software Koubou 1989 Herzog Zwei Sega and Technosoft Unit deployment system. 1992 Dune II: The Building of a Dynasty Westwood Studios Building deployment system. Technology improvements. Economy system. 1994 Warcraft: Orcs and Humans Blizzard Entertainment Units used has resource. 1997 Age of Empires Ensemble Studios Extra bonus objectives.

2.2 Tower Defense Games

2.2.1 Concept

Although Tower Defense games are considered a sub-genre of RTS games, they present different characteristics. As such, it presents a different game loop, such as the one displayed in Figure 2.7.

Figure 2.7: Generic Tower Defense game loop.

This representation shows the generic game loop of a Tower Defense. Other types of Tower Defense games might present differences in their game loops. Despite that, all of them share the main game concept, where it is expected that players don’t let any monster reach the end of the path, or, in the case of a reversed Tower Defense, allow them all to reach it.

2.2.2 History

Despite being a sub-genre of RTS, Tower Defense as a genre is older than RTS. This genre appeared in the 80’s during the golden age of the arcade video-games. Games like Space Invaders released in 1978, had concepts that were the beginning of what we call today a tower defense. Some examples will

7 be presented that helped to shape what is called a Tower Defense and explain why they made important contributions.

[1980] Missile Command developed by Atari: Missile Command introduced new mechanics that were used in other games of this genre. This game consists in defending a set of cities that are attacked by incoming missiles. The player had a set of missiles that could use to destroy the incoming ones. The player would control the shooting, using a pointer and when he clicked in any place, one of the defensive missiles was launched. When this missile reached the clicked position, it would explode and the explosion would destroy the attacking missile if it passed that position while the exploding cloud was on (Figure 2.8).

Figure 2.8: Missile Command game interface.

[1981] Defender: In Defender the player controls a spaceship and he has to obliterate aliens, in order to save humanoids that are strategically positioned on the map. Defender also incorporated a new feature. This was the first game incorporating a mini-map where the player could see where enemies and humanoids were positioned (Figure 2.9).

Figure 2.9: Defender game interface.

[1982] Choplifter: Choplifter, have a better graphical design than Defender but the mechanics were very similar to it which gave the game a weaker impact.

8 [1984] Pedro released by Imagine Software’s: This was one of the first games that incorporated together the strategic components of Missile Command with the extra objectives presented by Defender and Choplifter. The player had to help Pedro, also the character name, to defend his farm from animals that try to eat the crops (Figure 2.10).

Figure 2.10: Pedro game interface.

[1990] Rampart: This game brought new concepts as, waves of enemies, construct time and repair time. Rampart has 3 phases that continually alternate in a cycle creating the game loop. The player started by choosing the primary castle position. This phase is the same as the repair phase, however as it is the first round it gives the player his first region. This phase was followed by the positioning of the cannon defenses. Here, the player had to position cannons inside his territory (as more territory he had, more defenses could be added, but harder would be to defend everything). Then the attacking phase started. Here, a wave of ships started to shoot the player castle walls (that delimit the player area), which after lead to the repairment phase, where the player had 20 seconds to rebuild new walls (in a tetris style). Rampart also had a multiplayer mode where players fought against each other to have more territory, earning more points depending on the territory owned and damage done. This characteristics made the game extremely fun to play single or multiplayer (Figure 2.11).

Even after all these games were published, it was only in 2002, after Warcraft III: Reign of Chaos release by Blizzard Entertainment, that tower defenses started to be a phenomenon. Warcraft III brought a bunch of new games due to the mod (modification) creation module that the game incorporated. This way, players could make their own games and publish them inside the costume game section of the game. With this concept, a lot of new games appeared, making Warcraft III one of the most played games of that time. Mods like Element Tower Defense, Gem Tower Defense and Winter Maul started to be popular inside costume games, and brought new game concepts, for what we call today a Tower Defense. The great background provided by Warcraft III made possible a big boom of Tower Defense games during 2007 and 2008. This boom came about also due to the rise of Adobe Flash independent developers and due to mobile phones’ operating systems, which made games easier and

9 Figure 2.11: Rampart game interface. more accessible to mobile devices. Since then, lots of games of this genre have appeared, and Tower Defense has become a standard game genre of games played nowadays. Games such as Plants versus Zombies brought this genre to mass consumption. Part of its suc- cess has to do with, the exploitation of a new platform mobile gaming. However, what really led the game to success, was its game concept. Plants versus Zombies presents lots of features imported from “Warcraft III” custom games. By applying to new gaming platforms the mechanics that had proven their success in the past, some implementation risks were suppressed. Other games like Desktop Tower Defense and Dungeon Defenders also provided the market with small game concept changes, giving players now emotions. In order to provide an overview of the innovations presented in each game refered above, it is displayed a comparison table bellow.

Year Name Company/Developer Innovations 1980 Missile Command Atari Shooting at incoming targets. 1981 Defender Williams Electronics and Atari Mini-map. 1982 Choplifter Sega, Atari - 1984 Pedro Imagine Software’s Defending objectives. 1990 Rampart Atari Games Incorporated Player phases.

2.3 Browser and Mobile Games

Browser and mobile games also play an important role in the contextualization of the project de- veloped, since these are the platforms this project will enrol on. Therefore, it is important to explore the differences between them, and what are the main success features of each game within different platforms.

2.3.1 Browser

Ogame: Ogame is a simple text based web browser RTS game where players manage their planets. In their planets players are allowed to construct buildings, such as mines to gather resources,

10 improve the planet defenses, build a space fleet or make various upgrades. The game wins by its simplicity and strong social aspects, since players can form alliances to fight other groups of players. Ogame was not the only game that followed this trend, Tribal Wars is another good example of such concept, however this has a more medieval style then Ogame (Figure 2.12).

Figure 2.12: Ogame game interface.

Ikariam: Ikariam is not very different from the games mentioned above. The strong aspect of this game is the complex resource management that imitates a fictional society. Here, players have cities that they are responsible for and so the human resources are limited to the city population. Also, a tax collection system provides the player city with the gold necessary to pay for its army.

Travian: Following concepts like Tribal Wars, Travian brought an innovation to this game genres. In Travian, each game server has seasons. Unlike Tribal Wars, where each game server have an endless game, Travian came with a different approach. From time to time, the Travian server resets all player cities and rewards the best players of each season. This makes players play for each season in order to be adequately rewarded.

Forge of Empires: This more recent game came with new innovations that should be referred. First of all, Forge of Empires came with a new combat system. Instead of having a text battle report, generated by a server simulation, Forge of Empires presented players with a chess like battle system. Here, attacking troops and defending troops would be placed in a tileset where players choose each unit movement and attack. Secondly, this game give more freedom for players to build their cities. The dynamic building placement system, makes each player city unique and therefore, a city personalization that other games don’t provide (Figure 2.13).

Desktop Tower Defense: Even though this game is not a multiplayer game, Desktop Tower Defense presents a similar content to the thesis project in analysis. Here, player’s position the towers among a square with 4 entrances. Monsters will spawn in waves after the player gives an order. As more monsters the towers kill, more resources the player will have to spend in new towers for next round. If 20 monsters reach the exit opposite where they spawn to, the player loses (Figure 2.14).

11 Figure 2.13: Forge of Empires game interface.

Figure 2.14: Desktop Tower Defense game interface.

2.3.2 Mobile

Clash of Clans: Despite being a mobile game, this game’s concept resembles the main concept of Mazekeeper. In Clash of Clans players have to manage a city. By positioning their buildings where they most please, as in Forge of Empires, players organize their cities and their defenses at the same time. This happens because battles occur in the defending player’s city. As the attacker is presented with the opponent’s city, it can deploy units on the edge of the city being attacked. Then the units AI (Artificial Intelligence) within a simulation will decide the result of the battle (Figure 2.15).

Figure 2.15: Clash of Clans game interface.

12 Clash Royal: This game is a success phenomenon being a best seller on the top of the most profitable games for Android and IOS, with an estimated profit of over $930 million in 2015 Poladian[2016]. Clash Royal is a simple game and presents a RTS genre while containing caracteristics of a Tower Defense and a card game. Players have to make their decks based on the cards they have. When a player starts a battle against other player, both are presented with a two lane map that has two towers and one keep for each player. As time elapses, players win mana (a game resource that limits the player’s actions), used to play the cards that they have in their hand. When a player plays a card, it can be deployed in specific parts of the field. After that, the agent’s AI will be in charge of the unit’s behaviour (Figure 2.16).

Figure 2.16: Clash Royal game interface.

Plants Versus Zombies: Plants versus zombies follows the standard style of tower defense for mo- bile. Here, the player cultivates plants that have special powers and that are used to fight against incoming zombies. In each round, the player can place more plants or simply order the next wave to come. The more zombies the plants kill, the more money the player will be awarded (Figure 2.17).

13 Figure 2.17: Plants versus Zombies game interface.

In conclusion, features that were similar to the ones in the “Mazekeeper” concept have repre- sented a success for their companies. Even the games mentioned above, such as Ikariam and Ogame, among others, are still online after 15 years, showing that they provide the necessary sustainability, and therefore have an active game community.

2.4 Target Players

It is important to analyse the characteristics of the target players, to understand the implications of the game concepts for the users. In order to explore the feelings induced by games in the player types defined by the BrainHex model, L. Nacke , C. Bateman, and R. Mandryk[2011] are considered. Ac- cording to this model, it is expected that Mazekeeper will have a strong appeal to players who that are characterized as Conquerors, Masterminders, or Achievers.

Figure 2.18: Brainhex symbol correspondent to each player archtype. Fisrt image Conqueror, second Masterminder and third Achiever.

• The conqueror: The conqueror type of player, seek to fight against strong enemies, both mon- sters or other players. They pursuit the desire to achieve victory and thus experience fiero, the italian word used for pride. This kind of emotions felt by the player are caused by natural human reactions. ”When mammals face difficult situations, their body produces epinephrine (adrenalin) and norepinephrine, the former producing arousal and excitement and the latter being associated with anger and combative tendencies. Anger serves to motivate opposition and hence to encour- age persistence in the face of challenge, and testosterone may also have an important role in this behavior (irrespective of gender).” quoted from “BrainHex: A neurobiological gamer typology survey”, (Lennart E. Nacke, Chris Bateman, Regan L. Mandryk). Mazekeeper induce this feeling through both its components, Player versus Player and Player versus Environment. The desire to beat opponent Players is provided by the income gained by defeating other Players.

14 • Master minders: Master minders will find their interest in the puzzle that the lane system creates. The strategy involved in solving puzzles is what leads this archetype to the fiero state. The thrill of this mind challenges can be explained by the rewarding sensation felt by players when they overcome a puzzle by making the most efficient decisions. The strategy needed to organize an attack will also have an important role to captivate this kind of players.

• Achievers: This archetype likes to overcome challenges in order to complete achievements. The pursuit of completing goals, gives to this type of players the reward satisfaction they are looking for. This feeling is created by the release of dopamine, hormone segregated by the brain in order to induce pleasure. This archetype also likes to be rewarded by their successes and for that Mazekeeper will reward players accordingly to their achievements in each round, making possible the usage of those rewards in the next round.

2.5 Technology

Developing a game doesn’t require only the search for the best concept, but also the best way to ma- terialize the concept. To do so, it is important to seek for the best tools that fit the concept requirements. Choosing the best developing platform is of the essence to have an effective and efficient solution. When talking about game engines, it is possible to develop a game without the use of any of these tools. However, this increases the development time, because more components have to be programmed by the game developer that otherwise would be provided by the game engine. This is the case where a system is built using javascript and graphical javascript api’s. Nevertheless, this option makes devel- opers use lower level tools, giving them more flexibility in possible implementations of solutions. Some options were taken into consideration when planning the development of this project. It is presented be- low a comparison between the chosen platforms, and they were analysed in the following dimensions: Modifiability, the capacity of modifying a program after its deployment; Performance; and Deployability.

• Javascript with PIXI api: As the project has as target the web, some popular web technologies were taken into consideration. This framework can only be applyed to web browser applications, presenting a low deployability. Despite of all background work that would need to be done, to de- velop a game with this tools, the game detail and performance achieved would be much greater. It is also known, that opting for low level development tools, makes the system much less modifiable, and there for mantainable. Also, the work required to build game mechanics and graphics would be much greater, Goodboy Digital[2017].

• Unity: Unity is a game engine capable of exporting the game project to a large range of platforms from the same source code. This tool is also an high level development tool which brings some of the game physics and mechanics already built in. This engine also makes the development of any UI easier once it combines the scripting mechanisms that provide behaviour to the game with the game art and design. For this reason, Unity provides a good level of mantainability and

15 modifiability. A downside of this engine is that every development is build on a pre made layer of game mechanics that limits the developers power, Unity Technologies[2017].

• Unreal Engine: Unreal is also a high level game engine that enable programmers to develop their games using a high level language such as C++. In the case of Unity the language used is C#. Like Unity, developers are also able to export their projects to a set of platforms available. As the set of platforms available is more limited than the previous engine described, it isn’t possible to export a web player version. The upside of the Unreal system is the graphics and animations. However, this engine was not made to develop 2D games, thus to develop games using it that have a 2D perspective might lead to performance issues, Epic Games[2017].

It can be seen that each technology has its pros and cons. In order to compare such information, a comparison table of the different technologies proposed for this project is presented below.

Modifiability Performance Deployability Javascript with PIXI Low High Low Unity Medium Medium High Unreal Medium Low Medium

By examining this, we can see that the most adequate choice was Unity, and therefore it was the chosen development tool. As a multiplayer game system, Mazekeeper also needs to be able to store information. To do so, two different types of databases were taken into consideration, relational databases (SQL) and a non-relational database (MongoDB). Among the relational databases available, SQL (Structured Query Language) is the most commonly used. SQL organizes information in tables that can be related through relational algebra, Springer[2002]. Although these operations are extremely efficient, the format of storing and relating the information is not the most appropriate for this project. MongoDB, on the other hand, is the most well known non-relational database. This database model stores information in a widely used format; JSON. JSON Objects allows the storage of the information of a runtime object in persistent memory as well as in a format that can be understood by other software parties, J. Kurose, and K. Ross[2013]. The use of such a protocol to store the information simplifies all the processes of formatting this information, and thus improves the project’s modifiability. Despite presenting less performance when querying with some parameters Z. Parker , S. Poe , and S. Vrbsky[2013], its efficiency can be compared with SQL in many other aspects. Even with less performance in some query types, the non-relational database Mongodb was chosen due to its easy implementation and usage. Plus the data model developed for this project best fits with its usage of storing objects, once there was used an OO (Objected Oriented) programming language, C#. To recapitulate the previous comparison, the conclusions are presented in the table below.

Storage Format Performance Compatible SQL Tables High Yes MongoDB JSON Objects Medium/High Yes

16 Networking was also one of the main concerns. Due to the level of detail that will be required to understand some concerns that will be presented later, it was decided to crate a Network subsection.

2.5.1 Networking

As the main way of communication there was chosen the use of sockets, using a TCP connection. This makes the communication trustworthy and performs at acceptable levels. However, since we are developing a Web application, sockets are not directly supported. A Web application runs under the http protocol, which resides in the network application layer. This raises some concerns when designing the network abilities of the proposed system. Once it is not intended to transfer Web pages (or groups of files associated with the http protocol), but simply command strings, a better solution was found. Websockets is a technology developed to work under http protocol, providing all functionalities delivered by the usage of sockets. Websockets doesn’t really use http protocol for the communicating between two parties, but rather the underlying tcp protocol, J. Kurose, and K. Ross[2013]. To establish communication between a client and a server a WebSocket handshake is necessary to provide the communication upgrade required. To do so the client starts to send an http request, with the following info:

GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Version: 13

As can be seen, the package has the hostname, the type of upgrade desired, type of connection, and other information required to establish a websocket connection. The key field is a sequence of random bytes which disable the possibility of re-establishing an old connection via a caching proxy. The following websocket fields are optional. However, the first defines the subprotocol chosen for this connection, and the second the protocol version used. Upon receiving this package from the client, if the server accepts the connection, it will trigger the following response:

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=

Sec-WebSocket-Protocol: chat

The server response is generated to inform the client that a successful upgrade has been estab- lished. After receiving the server handshake package, the client can now send the desired information to the server. Despite being able to send the desired data, the package has to contain a specific header. All the following messages should agree with the frame anatomy displayed in Figure 2.21

17 Figure 2.19: The format of a web socket package.

The first bit of the message (FIN) should be set to 0 if it isn’t the last incoming message. The following three (RSV1, RSV2, RSV3) are reserved bits for protocol update, therefore should be set to 0. The opcode specifies the type of data being sent, for example, 0x01 indicates that the type of data is UTF-8 text data, 0x02 that the frame has binary data, among others. The mask bit is used to indicate whether the following frame is masked. The payload length bytes are used to set the length of the payload being sent.

As the client is using an Unity asset to establish websocket connections, it doesn’t need the imple- mentation of the following frame, once it is already implemented by the websocket unity plugin. However, it had to be implemented by the server side. Besides the first bits which are basically the same for every package, except for FIN, the payload length required some extra implementation. Since the maximum size of the payload length is 128 bytes, the maximum number that can be represented with 7 bits, and since server side replies can have more than 128 bytes, an automated way to define the frame size had to be developed. Using the fields Extended Payload Length allows us to send packages with more than 128 bytes. However, it might not be necessary to do so. In order to send the correct frame size, a way of formatting the packages sent depending on their size, was implemented. By doing so, only the max- imum required space is described in the frame header, sparing network traffic and therefore improving the game’s performance.

As mentioned above, all frames sent by the client provides the server with a command, which is going to be processed, generating an answer which is sent to the player. The advantages of using such a system reside in the fact that less info has to be sent to the server, sending only the required information to identify the action being ordered and the player that has ordered it. Since the information that is necessary for performing the required task is on the server, only identifiers should be sent by the

18 client, improving performance on both sides.

2.5.2 Game Engine (Unity)

This choice of game engine makes it necessary to give a brief explanation of the supported archi- tecture and engine behaviour. Unity organizes game components per scene. Each scene groups all game components required for the playability of that scene. As in the movies, a scene corresponds to an ambience that contains a scenario where the game is taking place. The architectural requirements of each scene should be planned by the game developer as well as how many scenes the game will need and what components each scene will require. As each game part can occur in different game scenes, sometimes it is necessary to send information from one scene to another. Unity doesn’t allow direct communication between different scenes. Each scene contains an instance of the state that the players are currently in. If a new level is reached or if the game has to change scene, the state of the player cannot be directly passed from the first scene to the second. To do so, it is necessary to create a pipeline to transmit the desired information. One way of creating a pipeline is to create a game object that isn’t destroyed on load. Scripts can be programmed not to be destroyed when a scene is changed, allowing developers to keep alive game objects that will also have a role in the next scene, such as the player’s character. Every object that is present in a scene is a game object, and so, contains specific parameters and behaviours that only exist in game objects. Every game object contains a set of components that are added by the developer. Each component give special attributes to the game object they belong to. For example, if we desire to have a game object that behaves like a physical thing we could add a rigidbody component to the target game object. Components can also be developed by programmers by writing scripts. A scripting component can give the game object the behaviour desired by the developer, as well as data structures that characterise that kind of game object. An example of a game object containing multiple components can be found in Figure 2.20.

The Unity architecture is extremely flexible regarding game implementation. A game object can have an animation simply by adding a new animation component to the desired game object. Also, scripting components can instantiate new game objects into the game scene just by containing the game object prefab in one of its variables. Prefabs work as game objects that aren’t present in the scene yet, and they are developed and attributed, simply by drag and drop, during the development of the corresponding scene. These characteristics make Unity very user friendly, giving the developer more power than previous game engines. However, its specific architecture makes regular Object Oriented architectures difficult to implement as planned. For example, a game object type will share the state of their variables with all game objects that share the same prefab. To keep the variables independent, it is necessary to create an object that can be held inside the game object, containing the object state. As can be seen, such an

19 Figure 2.20: A game object cube containing several components. implementation might not be planned before knowing the constraint and therefore the achieved architec- ture might have to be redefined. All the information about Unity presented above can be confirmed in Unity Technologies[2017].

20 Chapter 3

Game Concept

The concept of Mazekeeper was inspired by standard web RTS and in some standard tower defenses. It follows the concept of cyclic seasons, where players are encouraged to start all over again to be awarded by their position. In this was, a combination of both gameplays were taken into consideration. There is presented below a simple game loop.

Figure 3.1: Mazekeeper Game Loop.

In order to make the game concept clear, the different game concepts will be focussed on one at a time.

21 3.1 Player City

As mentioned before, each player starts with their own city. The city scene allows players to build new buildings, improve old ones, recruit units and visualise possible attacks that they have suffered or that they have made. Three types of resources are given to the players, which are displayed in every game scene: gold, construction materials, and magica. Each resource has its own production rate and was designed to be spent on specific game components. There are three types of buildings presented to the players:

• Resource Gathering Buildings: Buildings such as the Mine, Lumber Mill and Magic Tower were designed to provide, from time to time, resources to the player. Improving such buildings will increase the amount of resources produced by the player, and therefore, increase his development rate.

• Recruitment Buildings: This is the case of the Barracks and Hero Shrine. Those two buildings allow the player to recruit units or special units. Those units are used to attack other players or NPC villages (concept that will be explored later), both in order to steal resources from other players or to increase their resources production rate.

• Progression Buildings: Progression buildings give players access to extra mechanism. The City Hall, despite of being already built when the player starts, allows players to keep some resources in case of other player attack. It also increases the amount of resources a player can store. Other progression building is the Hero Shire. Even being a recruitment building it is also a progression building, once it enables the NPC villages mechanism.

It is part of the player’s strategy which buildings he will prioritize. An aggressive player might start by building Recruitment buildings in order to steal resources from other players or increase his resource gathering by conquering NPC villages. On the other hand a defensive player might prefer to invest in resource gathering buildings while improving his defense, protecting himself from other players attacks.

3.2 Player Lane

Like the city, each player has a city entrance, that is presented in a different scene. Even though each lane is personal, every player can check the other players lanes, and therefore decide if it is worth attacking or not. The lane is also the battle scenario where troops have to reach the end of the path. Every lane is composed by three entrance points and one exit point. Attacking troops should be distributed among the entrances and it is the attacker’s objective to follow the best strategy to allow the most units to reach the end of the opponent’s maze. It is important to point out that attacking units, during attacks, will not destroy any building deployed by the defender. For each unit reaching the end, the attacking player will receive resources according to the unit’s looting capacity. However, to make the attacker’s job difficult, the defending player will have a pre-battle maze built with towers and barricades.

22 Each player is able to improve its defence at any time of the game and is able to condition the path that the attacking units will have to follow to reach the end. Also, to increase the strategic depth, players have a set of towers from which they can choose and which have different effects. As an example, the magic tower will slow the enemies that get shot. For the same reason, attacking players will also have to choose what kind of troops they will be sending, as there are different types. Some are faster but weaker while others are slow but strong. The multiple combinations of attacks and defenses give the players the possibility of following different strategies.

3.3 Map

The map is the only game scene that is common to every player. Here, players can check other players progression and territory, and can also access other players’ lanes to check whether an attack would be worthwhile or not. The map contains the city of every player that is playing in the current season, as well as every NPC village. This gives players a territorial view that encourages them to expand their territory and compare their power with the power of the other competitors. Once this mechanism allows any player to attack any other player, some balancing systems had to be developed. As such, a player protection was implemented based on the player’s points and progression. No player can attack another player that has less than half his points. This constraint makes attacking new users harder to exploit. New users would normally leave the game if their progression was stalled by the stronger ones. This mechanism was developed to avoid problems originating from when no matchmaking system is developed. In this way, a player is still able to choose his opponent, but the new users are protected as well from the older ones.

3.4 Other Game Features

3.4.1 NPC Villages

The majority of the browser RTS games provide players with the option of attacking enemies other than players. Mazekeeper no exception. It also has NPCs, despite their presenting a different mechanism. While in the trending browser games, players attack NPCs to get extra resources from units’ looting, in Mazekeeper, these villages only provide resources after being captured by the player. In order to conquer a NPC village, the player should attack it to receive influence. No extra resources are provided by these attacks, meaning that until the player conquers the city, he will only have losses. Each unit provides a certain amount of influence in that city, which in the case of the available pre-alpha is 4% per unit independent of the type. After the player gets above 50% influence, the city will start generating influence, until it reaches 100%. The influence status is individual, meaning that only one player can be the owner of a NPC village at a time. However, other players can try to steal the village from its owner. When a city is above 50% the owner can now start to have profit from that city. Players can choose to invest in three features of each city: gold gathering, material gathering or village defense. While the first

23 two increase the amount of resources generated for the player by that city, the last changes the village defense to make it harder for other players to conquer it. Three sets of different mazes were designed for each level of defense, being set randomly after the player makes the upgrade. If a player manages to steal a village from another player, the village defense will be set to 0, while the other levels will be kept. Also, to avoid creating positive feedback, which happened during tests, the range of the NPC villages that a player can attack is limited by the Hero Shrine level. And even with such a limitation an additional measure had to be added, which decreases the speed of a unit the further the village is from the player’s city.

3.4.2 Heroes

Heroes are special units that provide boosts to the units in battle. They can be recruited at the Hero Shrine building. The heroes mechanism also presents a strategic option for the attacker, delivering a wider spectrum of possibilities. Since each hero has different abilities, which affect different units, depending on their positioning, they are better used against certain types of defenses. Although not implemented, it is intended to use heroes as rewards to encourage players to start again in a new season and check the new acquisition effect.

3.4.3 Events

The season events were also designed to appeal to the players, giving them different constraints each season. Every season a new event is implemented in the Mazekeeper battle scenes. All of them try to present features that will make players change their defense or attack strategy. With such a mechanism, players have to adapt their strategies to what the event brings. Also, as all events bring attack and defense constraints, the players have to build their defenses and order their attacks bearing in mind the effect of the event in each case. This mechanism makes the game different each time a new season starts and thus refreshes the players, who will want to start again and adapt their gameplay to the new mysterious event.

24 Chapter 4

Architecture of the Solution

4.1 Quality Attributes

Architecture plays a major role in the project, by assuring that the most important quality attributes are achieved. Quality attributes like availability, modifiability and performance were considered a priority during all the development process. All information presented bellow can be corroborated by reference P. Clements et al.[2010].

• Availability is the proportion of time a system is in a functioning condition. This is a critical attribute for games in general. Online games should be available at any time. Users will log in at any time of the day, and if the service is not available for big amounts of time or various times along the week, players will start being frustrated for not being able to do what they want to do. This leads players to quit playing and to look for alternatives to a game that they enjoy but is never available.

• Modifiability is, as the name suggests, the cost of being modified. In complex systems, such as the one that is being described, the condition of being able to do alterations or additions with- out spending too much resources on such alterations is crucial. Mazekeeper requires constants updates to its content. In this way, the time consumption of such updates is of the essence and therefore this project’s architecture was designed to suppress that need. It will be explained below, how the conception of the architecture helped to improve modifiability.

• Performance was another important quality attribute focused during the planning and develop- ment of this project. The need for performance in games is a key factor. Problems such as, big loading times, FPS (frames per second) drops, high latency are associated with performance overestimation. In order to keep performance in an acceptable level, some approaches have to be considered in the conception and software tools chosen, to held the desired feature. It is also known that some optimizations are limited by the development technology chosen. However, extra care might be taken to prevent performance problems. Those measures are explained in more detail below, in the description of the project architecture.

25 4.2 Project Structure

The system under scope was designed to have 3 major components. The front-end web page, game application and back-end server. The system interaction is presented in the following diagram:

Figure 4.1: Mazekeeper System Interaction.

In order to understand the interaction between all parties, it is necessary to describe the different interactions listed below.

1. Web Page Request: Like in every web system the user starts by requesting the desired web page to the hosting server. All the process underlying this request, like DNS (Domain Name Service) lookup and http protocol will not be explored once it is out of the scope of this project.

2. Web Page Response: Upon receiving a request the tecnico sigma server, which holds the game webpage in the student web section, sends the web page components to the client. Among the web page components is also sent the game application that resides in one of the requested web pages.

3. Game Requests: Once the user browser loads all web page components, the user can access the game application by accessing the corresponding web page. If the player does so, the game application will send all its requests to the game back-end server until the player closes the web page or logs out from the game.

4. Game Back-End Response: Every request made by a game application will be answered by the Mazekeeper back-end server. It will provide the game application with all information needed so it can display the game state to the user.

After the interaction between all components as been described it is possible to go into more detail about each one of them.

26 4.2.1 Front End (Web Page)

Mazekeeper web page, or front end, is the simplest module from all three. It is intended that the web page presents all the necessary links for players. The game homepage displays the game news, a link to the forum, where the community shares their concerns and ideas, and the link to the game application. It may also hold future information that will help the player understand the game or to encourage players to participate more.

4.2.2 Game Application

The game was developed with Unity engine. This provides a fast and intuitive way of developing games with their basic mechanics already provided by the engine itself. The usage of such development tool conditions the game application architecture due to implementation constraints reffered in the related work section. All objects identified below correspond to unity game objects. The information about the behaviour and characteristics of game objects is out of the scope of this project and therefore will not be explored. The following diagram describes the usage of modules developed and their interactions.

Figure 4.2: Game Application components use style.

From the diagram it can be seen that the game application is divided into four modules and a manager root object that is in charge of the user authentication and cross cut features. Each one of the three base modules is responsible for managing the correspondent scene. As it can be seen, each one also contains a manager and a displayer. The manager is responsible for holding all data structures that are sent by the server and received through the websocket plugin. The functionality of the websocket module was conceived by a third party developer and it is available at unity’s asset store. Its functionality was already explored in the technology section. So as we can see, all the information necessary to populate the game objects is held in the correspondent manager. For example, if a user logs in and

27 requests the information of his city, all the information that will arrive from the server will be parsed and stored inside the Game Manager game object. The manager then uses the functionality available on the displayer to display those informations, as requested, in the game scene. This happens for all the three modules with some possible slight differences between them. The game manager, as mentioned before, has a special behaviour. Besides the authentication process, similar to processes made by other managers, it holds information that is required when the game needs to change scene. As it was explored before, Unity’s architecture provide scenes. Each scene contains the game objects required to make the playability desired. However, those scenes cannot exchange information directly. Once one scene is loaded other scene is unloaded, being a hard task to send the state of the old scene to the new one. To do so, the Game Manager game object was given a property that keeps the object alive even if a scene is changed. This way it is possible to use the Game Manager as a pipeline to send information across scenes. All the modularization of the client application was designed to improve modifiability. As so, to add new content to Mazekeeper client, few alterations are needed and therefore less time is spent implementing new features. This agile architecture allows the easy scaling of the game content. As an example, if we would like to release a new hero we only have to create the interface components, such as the hero gameobject, and link him to lists implemented on the script responsible for the scene task. Other example could be adding a new building to the game. To do so, we only have to create the interface components, the desired behaviour of such building and add them to the scene. Such implementation reduces the time of developing new content and therefore the resources needed to do so. Another pro of developing a modular architecture is that, if any module have to be refactored it won’t affect any other module.

4.2.3 Back End (Game Server)

In order to develop a server able to fulfill the game requirements, some architectural measures were taken. Since the server had to be stateful, it was opted for developing a console application capable of answering requests from the client application. The server was designed to follow a layered structure. All its components have been developed using C# and C# api’s to connect the different components, such as the MongoDB. No framework was used. In this type of architecture, layers above are allowed to use any layer below, however the opposite is not true. The Figure 4.3 presents the architecture of the server, showing the relations between its different components. The core component is the main component of the server. Here are the main server functions. The core is in charge of deploying the Web Listener, on a new thread of execution, which will wait for client connections. It also performs updates every minute to the cache, running services designed to be performed every time interval defined. One example of such a service is the resource update, which is executed every minute. The Web Listener component is responsible for listening to any incoming request. When a client

28 Figure 4.3: Back End architecture, represented as a Layer View.

connects to the server, the Web Listener will use the service dispatcher, located on the Web Services component, to dispatch the incoming request to the desired Web Service. Web Services contain all pos- sible services requested by the player. In fact, the service receives a certain number of parameters sent by the client application, processes them, applies changes to the cache or to the database, and replies with the computational result of that service. This implementation improves the server’s modifiability. This comes with the fact that if it is planned to add any new service, it is only required to add the desired Web Service and create a link from the Service Dispatcher to the implemented Web Service.

The Cache component was designed to improve server performance. Once it is known that Database accesses require the operating system to make a kernel call, which is resource expensive, it is considered good programming practice to reduce those accesses as much as possible. To do so, a cache system was developed where players are added according to their login. Any alteration made by the player will affect the cache object and not directly the database object. In order to keep consis- tency, every minute the updating system implemented by the core, and saves the cached players in the database. This way if the server crashes it will only be lost the information that was received beetween the last database update and the crash, that will never be bigger than 2 minutes. This solution might in- volve some problems like duplicate logged-in players and players stuck on cache if they don’t log out. To solve these problems a simple approach has been designed. Preventing the same player from logging in twice was implemented by verifying whether the requested logon player was already on cache. If so, an error is sent to the player informing him that his account is already logged in. Despite not being the

29 best possible solution this solves the problem of object inconsistency, and prevents others. However, this solution aggravates the second problem mentioned. If a player is not removed from the cache, that player will not be able to login again. Assuming that every player will logout every time they access the game is a bad practice. Players usually close the web browser when they wish to close a certain appli- cation. Notwithstanding if the player simply closes the browser, the server has no way of knowing if the player is still using the game or not. To solve this issue a client call was used. It is made every minute, to know whether the client’s browser is still running the application. The update resources request is made by the client every minute, so if a player doesn’t make any call after two minutes, the player is removed from the cache and saved on the database, being able to login again. The two-minute interval was designed to suppress any network delay on arriving packages. Therefore, no user is expected to stay stuck on cache and consistency is kept with constant player backups in the database. The last layer, which contains two components, DBObjects and DBContext, is responsible for the database management. DBContext implements functions that access the different database collections and performs actions like verification, saves, and accesses to different documents in the database. On the other hand, DBObjects implement the documents which are saved in the database. Thus, DBObjects are used and held in the server as runtime objects. Finally, the server works as an independent system. If it is intended to replicate the server, it could be deployed on another machine and access a new database or the same database as the first one. This allows to address replication in two possible ways. One way enables the creation of multiple servers holding different players, in other words creating several worlds. The other allows deploying multiple servers, distributing the computational power over all servers. This last solution would require the development of a load balancer. Thereby, the implementation of such a component would have an easy integration with the system that has been developed.

30 Chapter 5

The First Iteration of the Implementation

The process of implementation of the game was done iteratively. In order to start the implementation process, a game concept had to be elaborated and documented. Once elaborated, it was necessary to test the conceptualization of the game. To do so, low fidelity prototypes were made and tested with a group of users called the focus group. However, in the implementation of the Mazekeeper project, these prototypes were quite limited in terms of being used to test the existing game concept. The need for real time action and automated action became a barrier to developing low level prototypes. Hence, for the first iteration of the implementation, three high level prototypes were designed, corresponding to three different gameplays.

5.1 Implementation of the Prototypes

• Defensive Prototype:

The first type of gameplay tries to simulate the defensive part of Mazekeeper. As was explained in the “Game Concept” section, each player has to defend his city from the other player’s attacks. Defending a city consists in building several towers in a path that leads to the entrance of the city. Players can build in their own way, by placing towers in different patterns to make their strategy more suitable for some kinds of attacks. The first prototype simulated this entire mechanism, sending waves of monsters, each wave stronger, to test the player’s defense mechanism. If the player’s tower’s killed enemies, the player would be rewarded with the cost of those units. Resources given by killed units are used to build more towers or walls in the path. However, if one monster reached the end of the path, no reward was given to the player, and one of the player’s ten lives were taken. If the player had no more lives, the player lost and the game would restart. All monster path’s were calculated by an A* algorithm which had as heuristic the shortest route between two points, and therefore was ideal for the required mechanism. Due to the previous success of this concept, as shown in previously published games,, it was not

31 only intended to test the viability of the concept but also its usability. The defense prototype was developed using javascript and the api PIXI for graphical purposes. Because of the low level of the graphical component, which allows having better control of how things are made, much time was required to develop even the simplest game components. For that reason, the next two prototypes were developed using Unity as the game engine.

Figure 5.1: The first Mazekeeper prototype, defense.

• Attack Prototype:

The second prototype was developed to test the opposite feature of the component developed in first prototype. The Mazekeeper combat system ensures that every player can take part in both offensive and defensive gameplay. Therefore, it is necessary to make sure that players enjoy both sides “of the same coin”. The offensive prototype presented the same features as the defensive one, but this time the player was asked to buy units and send them through predefined mazes. Each level had an increased number of towers and obstacles in the path that the player’s monster’s have to travel through. This time, the player was rewarded if his monsters reached the end of the path, in contrast to the first prototype, where if they reached the end, the player had no reward. Making sure that players enjoy this game mechanism is crucial for this game concept. In accordance with the information given, this prototype was developed using the Unity game engine and javascript as programing language. This led to a faster development, reaching a playable version after only two weeks of development with no previous knowledge of the Unity engine. With this prototype it was also intended to test its usability more than the concept itself, as the concept had already been applied in other games.

• Management Prototype:

32 Figure 5.2: The attack prototype fame interface.

The third prototype tried to simulate the actions that players are able to do in their city and in other players’ cities. Here, players have to choose how they manage their buildings and what NPC villages they should attack first. This prototype also tried to test the PvE (player versus environment) concept designed for Mazekeeper. Here, when players attack any NPC village, they increase their influence on it. When the influence reaches more than 50%, the village starts generating resources for the player’s city, based on the investments made by the player. Hence, upon reaching 50% influence by attacking an NPC village, the player is asked to improve that city in one of four aspects: gold generation, material generation, magica generation and village defense. Depending on the player’s decision, the NPC village gives him different bonuses with the exception of the defense investment, which increases the strength of the village’s defense. This last option makes it harder for other players to steal the influence of this NPC village, and therefore harder to steal that player’s bonuses. Despite the fact that, the mechanism of city management has been implemented in several RTS browser games, none of them implements a PvE content such as the one presented here. In this way, testing this game concept, in addition to testing the usability of the components, became an important subject of the project development. The management prototype also implemented a battle simulation system similar to the one that had to be implemented in the second prototype’s back-end system. An independent battle simulation system was developed, not relying on the engine that was supporting the javascript scripts executed. None of the scripts developed to perform this task had any dependency on the Unity engine’s behaviour. This way it was possible to test the consistency of the results between the client animation and the server simulation in the attack prototype implementation.

5.2 User Testing

Since the main objective of developing the prototypes was to refine the concepts and playability, it was necessary to gather a group of people to discuss the whole concept. Therefore, two groups were assigned, the focus group and a testing group. The focus group consisted of a small number, 6, of people who would be present during the development of the whole project. All people that belong to the focus group are active hardcore players

33 Figure 5.3: The prototype that shows the management part of Mazekeeper. and some have knowledge of game developing. Despite not having any requirements to belong to the focus group, such characteristics helped the game conception to be more pleasant to a wider gaming community. It was intended that the focus group discuss the concepts and game mechanism. Therefore, meetings were encouraged with all members or a partial group when important decisions had to be made. The testing group consisted of a wider community. Also, the testing group contained the focus group, meaning that tests made by the testing group were also applied by the focus group. This group contains more types of players, being likelier to represent better the gaming community overall. With this strategy, it could be prevented that some content that could be appealing to the hardcore players might lead to the disinterest of casual players. This first testing phase started with collecting the prototype features that were considered the most important to analyse. By presenting three prototypes, the features of all of them were taken into consideration apart from each other. All of the case study aspects were compiled into a inquiry and presented to the testing group. Before being presented with the quiz, the testing group was asked to explore the three prototypes developed as much as they wanted. It was important to ensure that every member of the testing group tested the prototypes alone, to ensure that no member influenced another by sharing ideas or concerns. By doing so, the results of the inquires better represented the target gaming community. In order to extract more detailed information about the game feature concerns, the tests with the focus group were done in person. Here, too, all members performed the desired actions individually, to influencing upon the active tester. After every member had tested and answered the inquiry, group discussions were encouraged. All results will be presented and analysed in the next section.

5.2.1 Testing Results

The first iteration testing group consisted of 18 players. This way, it was possible to analyse 18 inquiry answers that provided useful information about doubtful features and interface components. The quiz developed consisted of four sections. The first section was designed to understand the composition and preferences of the testing group.

34 The testing group consisted of 17 male participants and 1 female participant, with ages between 12 and 50, with the following distribution:

Figure 5.4: Players’ Sex Distribution Figure 5.5: Players’ Age Distribution

Despite the homogeneity of the age and sex distributions, a more heterogeneous group with regard to the members playtime was assembled. As is shown in the graphic displayed below, two-thirds of the testing group plays more than one hour per day. Even so, it is not possible to consider there players necessarily as hardcore players, because what characterizes hardcore players is something that goes beyond playtime C. Martinho, P. Santos, and R. Prada[2014], but these can be considered frequent players.

Figure 5.6: Users play time.

Other questions related to members game preferences were asked, in order to understand what games they most enjoyed playing. There questions make sense when analysing some contextualized questions about each prototype, but not much information can be extracted when studying those results with no contextualization. The next three sections of the questionaire are related with each one of the three prototypes de- veloped. The first one was conceived to answer some concerns with regard to the Defensive Prototype.

35 One decisive question had to do with the path mechanism. The majority of web browsers tower de- fenses published in the market don’t provide the flexibility of changing the path traveled by monsters. The Mazekeeper concept tries to provide such flexibility, it being important to understand why the pub- lished games don’t provide such a mechanism. This might have to do with two factors. One, despite the previous success of such a mechanism, such as in Warcraft III for PC standalone, it is not as attractive on other web browser games. Or the new mechanisms that have appeared are more appealing for players. In order to test whether such flexibility is still preferred by players the following question was asked:

Figure 5.7: Users’ preferences for lane mechanism.

By analysing such results, it can be seen that such feature still have a great acceptance by the overall community. As such, this mechanism has a low risk associated with its implementation. Another question had to do with the size of the matrix where the players position their defenses, was sufficient. Although 94.4% were satisfied with the 10x14 size presented, a smaller matrix was implemented in the second prototype developed. Some development constraints when using the Unity engine led to this decision. The size 10x14 had a good acceptance level, however, that doesn’t mean that other matrix sizes are not good enough. In the Attack prototype section, some concerns with the troops’ deployability and available paths were explored. One big concern with this gameplay mode was the way of deploying units to the defensive path. In the presented prototype, players were confronted with a planning matrix, where they could manage where and when a unit would be deployed. This solution also innovated on the number of places where units can be deployed. Some games only present one entry point while others present more than one. In this way, a preference for the number of entries available becomes a key factor for the strategic game component. To test these concepts, the following questions were made to the testing group: As can be seen in the statistics made from the questions presented, some mechanism imple-

36 Figure 5.9: The number of entries in the lane pre- Figure 5.8: Players’ Attack System Preferences. ferred by players.

Figure 5.10: Users’ opinions about the attack planning menu presented. mented in the Attacking prototype didn’t have the acceptance level desired. Hence, some alternatives had to be found. The first question provided an option for the deploying mechanism presented by the attack prototype. With a 61.1% preference for the “Clash of Clans” deploy system, this seemed a viable option. Also, the testing group clearly had a preference for a lane with three entries instead of one, with 89.9% of the players choosing this. In order to align things with players’ interests, a solution that pro- vided a different unit deployment system with more than one entry point had to be found. A good starting point was trying to incorporate features of the “Clash of Clans” deployment system in Mazekeeper’s bat- tle component. Despite the difficulty of implementing such a mechanism (due to the difference in the game concept), once the game concept is different, a similar option was found. In the second iteration prototype, players are able to deploy units on one of the three possible entries, by clicking on the desired lane. In this way, players can choose their strategy while watching the opponent’s defenses. Lastly, the third section provided answers to the concerns about the game concepts and interface design of the management prototype. Starting with some interface concerns, two main concerns were tested: First, the flexibility of deploying city buildings in different positions on the scene. Games like

37 “Forge of Empires” enables players to position buildings where they most want. However, such a flexibil- ity comes with a price. Such a mechanism requires the implementation of extra game content, therefore requiring extra coding hours. Nonetheless, a question that aims at collecting user preferences about such a feature was asked.

Figure 5.11: Players’ preferences for building deployment system.

With 12 up votes for the dynamic position system, it clearly seems that players have more en- joyment playing games which give them more freedom. But, as also said before, such freedom brings about an increase in the needed resources. Despite the results of the inquiry, it was chosen to develop a static positioning system in the final prototype, to fulfil the project delivery deadline. The second concern that was treated was the implementation of the desired menus. In the prototype presented, some menus were full screen and others side ones. This was done so as to understand the display preference. As such, the following results were obtained: This time, as no extra effort was necessary, the preferred characteristic was implemented in the second iteration. Lastly, the testing group was asked what was their satisfaction with the new NPC mechanism. As it had not been seen in other browser RTS games, it was considered crucial to test this mechanism. After analysing the graph above we can conclude that, out of 18 answers, 17 are equal to or above 3 in satisfaction level, making an average level of satisfaction of 3.78. This gave us the information needed to support the decision to implement an influence feature.

38 Figure 5.12: Players’ preferences for the type of menus presented.

Figure 5.13: Players opinion about the new NPC mechanism presented.

39 40 Chapter 6

Second Iteration of the Implementation

In order to start developing a better version of the concept, it was necessary to compile the information extracted during the previous cycle and refine the game concept in development. The refining process consisted on applying the ideas most appreciated in previous prototypes to this new one. After doing so, it was required to extract the requirements of the system that would support the game. Some requirements had to do with the game concept itself, like the battle report system, the map system, and even the authentication system. Others were related to architectural concerns, like choosing quality attributes that would be more adequate for the scope of this project. Those have already been explored in Section 3.2, where it was explained why some quality attributes were more important than others. With the first architectural sketch done, it was possible to create a working schedule appropriate for this development. Working on an individual project does not require team coordination; however, a good development methodology has to be followed in order to deliver the project in good working con- dition. Hence, a feature based development, was opted for, consisting of creating one feature at a time and carrying out tests before starting the development of the next feature. Although this methodology is good for agile development, some content had to be developed before implementing certain game characteristics. The server back-end, server database and client application were the necessary com- ponents, in order to follow a feature based development methodology. On the back-end side, it was necessary to build the basic architectural structure. All functionality associated with Database deploy- ment, the cache manager, and the web dispatcher, were structural needs of this part of the system. The database deployment system is in charge of all alterations made to database objects. Also, if any document collection is not created yet, this module will be responsible for deploying the required collec- tion of documents. It is also important to point out that the player’s database collection and the player’s city collection were kept apart to support the season game concept. This way the city collection can be erased without losing any information regarding the players. The cache manager subsystem updates cached objects by running some parallel services such as the updating resources. The last, the web dispatcher, is responsible for distinguishing different users’ requests and ordering the execution of the

41 corresponding web service. With this basic implementation it is possible to start developing features on the server side, but some interface is also required to order those server commands. Thus, a basic client interface was also developed before the implementation of any feature. With the basic setup ready to start a feature based implementation, this methodology was imme- diatly started. Developing a register and an authentication system was the first priority, because the game requires users to register and authenticate, and therefore user states must be saved. In Chapter 3 it was explained briefly how the dispatch system works. The web listener components listen for any user connections. Upon receiving a connection an instance of the web dispatcher is created and the command sent by the client is then processed by the web dispatcher. If the web dispatcher identifies the message received as a registration command, the registration web service is created and executed, being able to perform every registration procedure required for user registration. The same happens with the authentication service, where all the game information required is provided to the client if a successful login takes place. The summary of the implementation will be divided according to the different scenes, as was done previously when exploring the game concept. But first we will start by presenting some implementation concerns that are considered good programming practice.

6.1 City gameplay development

Being now able to register and login different users, some other game features could be implemented. In the game application, the development started with the main scene, the city scene. After a player logs in, an init service is executed, asking for all information of the player city. If the player is logging in for the first time this season, all basic components are set up in the server. In this scene, players should be able to order building construction, recruit units, watch their battle reports and navigate to the desired game scenes. The client application should also send an update message to the server every minute so it can update the player’s resources and verify which players are still logged in. Although this last functionality is present in all three game scenes, it was the first to be implemented. On the server side, there was implemented, correspondingly, the update service which updates the resources of all cached players. Non-cached players will see their resources updated after they log in. This was designed to require less resources from the server, only making the calculations when they are needed. The construction order command was right next on the development list. Ordering the construction of buildings in the city was easily implemented by sending the desired command to the server and developing the corresponding web service. This is able to detect when the call was made, calculate the time required for the upgrade and send it back to the client. By receiving the time remaining, the client application starts a countdown. When it reaches zero, a new message is sent to the server asking how much time remains to have an upgraded building. If the server time for deploying the requested building is zero or less, a completion message is sent back to the client. However, if the time is still not over, the remaining time is sent back, making the client update the time left on the interface display. Recruiting troops was another feature necessary for this scene. By making sure that the player can only use this feature by accessing the

42 barracks building, it was not necessary to check if such building is available, if it doesn’t appear on the client interface. Clicking on the barracks building, displays a menu that allows players to recruit units. Each time a unit is recruited a recruitment command is sent to the server. All resource verifications are made on the server side, making sure no interface problems or game exploits interfere with the player’s state consistency. The battle report system will be explained in more detail when covering the lane scene. Changing scenes does not require any permission from the server. However, the information about the desired scene has to be provided. So, each time the player changes scene a new request is made by the client. The init request was designed so that the client application could be fed with the information required for displaying the desired scene. As each scene depends on the player’s state, this service had to be provided by the server.

Figure 6.1: The Mazekeeper City interface.

6.2 Lane gameplay development

The lane scene was by far the most challenging. Besides the necessity of providing a canvas UI with all possible actions on this scene, it was also required to support animations and most important to distinguish between player lane states. The player lane state makes possible distinguishing between three types of user requests: simulations, attacks, and reports, which will be explored later on. Each lane contains a 9x11 matrix with 99 slots used to deploy defensive buildings. Players can order the construction of a defensive tower by clicking on an UI button, selecting the tower type and clicking on one of the 99 slots used to do so. When the player perform such an action a build request is sent to the server. Upon receiving this type of message, the server starts to see if the lane spot is already

43 occupied by other defensive building. If so an error message is sent back to the client. Otherwise, extra verifications have to be made before making sure the request is possible. As a game rule, every lane existing in the game world has to have at least one path from every one of the three existing entries. To fulfil this requirement the server executes an A* path finding subsystem on the defensive player’s lane three times, one for each lane entry. If no exception is caugth, all three paths are clear, and therefore building deployment is available. When available, a confirmation message is sent to the client, making it perform all interface adjustments required to display the new tower. In addition, all data structures are updated to contain the new game object. Resources are also updated according to the content in the arrived message. As the lane scene incorporates the battle system, it is of the highest importance to explain this implementation.

Figure 6.2: The Mazekeeper Lane and Battle interface.

6.2.1 Battle System

The Mazekeeper battle system was designed to have the least possible impact on game’s perfor- mance. Once the game was developed as a distributed system, two types of battles were taken into consideration: synchronous and asynchronous. Since the synchronous battle system requires that both participants run the game session at the same time the asynchronous system was chosen. This is also the most used system in web browser games and therefore seemed the most appropriate for this game genre. An asynchronous battle system requires a battle simulation that can later be consulted by both parties. As it was desired that both players could replay the battle some constraints had to be analysed and some decisions made. In order to replay a game battle, three options were taken into consideration.

44 • Simulation with battle player: This option consists on presenting a server simulation that would generate logs for every frame, containing the information required to replay the battle frame by frame. This option bring great consistency, once every action performed by the game agents would be logged and then replayed.

• A battle video: Having the server running an interface that would play user battles and use tools to record the animation played.

• Two independent simulations: Presenting 2 independent simulations, one on the server side and other on the client side. In order to assure consistency only the random factors would have to be sent from the server to the client.

All options presented have their pros and cons when evaluating their impact on the quality at- tributes considered. The first option would present great consistency. However, performance would be drastically affected. By creating an average of 3000 logs per battle, each one containing 23 bytes of information, we would be sending through the network payloads of about 67 Kbytes. This would re- quire about 67 websocket frames to transfer all the required data. This would affect the waiting times to visualize any battle that the user requests, and could lead to frustration on the part of the players. The second option presented would require api’s and frameworks that would allow such a proce- dure. Also, the back-end server would have to be modified to incorporate an Unity module responsible for applying the same physics and timing that could be recorded into a video file. Furthermore, the per- formance of such a system wouldn’t be great as video files are heavy in terms of memory and network usage. The last option is the one which presents the best performance. With the damage dealt by towers being the only random aspect of the battle simulation, those are the only logs required to perform the animation. Hence, a battle that would require 67 Kbytes of information if using the first solution, would only require that 460 bytes be sent across the network if using this system. This represents a 93% improvement in the network performance. Consistency is clearly the downside of this approach. When using different technologies to make the same simulation, both have to be analysed and studied in order to replay the same event that was calculated by the server. Modifiability is also affected since both simulations have to be changed in order to keep consistent battles. Even though the last option seems to have some downsides at the development stage it was the option chosen to implement the battle system. Performance was the driving factor supporting this option.

6.3 Map gameplay development

The map was the third scene to be developed. Here, some concerns existed on how to display the players. Players should be displayed evenly in the map. Since the background sprite consists of a rectangle, the most even way to distribute players would be spiraling from the center to the edges. This constituted an implementation challenge, as the algorithm design to perform this action had yet to be

45 developed. There are algorithms that go through a matrix in a spiral form. However, they go from the outside to the inside, an opposite behaviour from the one desired.

Figure 6.3: The image on the left represents a spiral search from the outside to the inside. The image on the right shows the actual implementation, from the inside to the outside.

Also, in order to perform a spiral search from the outside to the inside we have to have a square matrix. With only the number of cities generated in the current season, as a value to perform the calculation, an algorithm for the city position had to be found. In this way, it would be possible to know what is the corresponding edge number of the square at each time. To do so, a calculation of the square root of the number of existing cities will provide how many cities each edge supports. The only special case is when the square root of the number of cities is 1. Besides that, we can see that if the square root of the total size of the matrix is odd, then the city will be placed on the right or lower edge. Otherwise, if the square root is even, then it should be placed on the left upper matrix part. To demonstrate why, let’s take a look at the next image:

Figure 6.4: The algorithm constraints and patterns.

By analysing the picture we can see some patterns that we can use to locate the desired place for the new city. Knowing that every top right corner will correspond to an odd square root, and that every

46 bottom left corner corresponds to an even square root, will help to locate the new position. Despite that information’s being enough for locating the next available spot, it can be optimized even more. As is also shown in the picture, the top left corner and the right bottom corner also can be mapped by adding both of the coordinates of the last placed city. Hence, between having an odd square root of the number of total cities and the sum of the coordinates more than 0 it is known that the desired location is on the right side of the matrix. By combining these two variables, it is possible to locate the desired position spending far fewer resources than to iterate through all of them. With this, it was possible to design a function that provided the desired behaviour with an optimized performance.

NPC villages were also a concern of this implementation. To present NPC villages evenly across the map, a sub-matrix was designed for each player. Instead of presenting each player with a matrix slot, it is presented as a sub-matrix. This new square matrix is a 3 by 3 matrix where the NPCs are spawned randomly inside. At first, it was desired to provide some randomness in the number of the NPC villages assigned to each player, from one village to three villages. When this was done, it became clear that such an implementation would create a game imbalance. Players with more villages had an advantage over those with only one village. This way, to assure the even distribution of NPCs, two of them are assigned to each player, so no player starts with the advantage of having more NPCs in his zone than others.

Figure 6.5: Mazekeeper Map interface.

47 6.4 Good Programing Practices

During the entire development phase, some practices were taken into consideration in order to keep the code clean and maintainable. Some practices diminish the code scattering and tangling. All along the code in the back-end and game application, functions have been created to reduce the code tangling and cross cut features implemented on higher class levels to reduce code scattering. As an example of code scattering reduction, there is the analytics system explained in the next subsection. By applying this implementation to a higher class, it is unnecessary to implement the desired functionality across the several classes that will be used. As to code tangling, many functions were created, to avoid spreading the same functionality across the different classes. Design Patterns also help to keep the code clean and easy to understand and modify. As an example of a design pattern used, we can explane the unit’s implementation. Once units can be from two types, regular units and heroes, a composite design pattern was used. Both types implement the same basic behaviour and therefore one can be considered a special case of the other. Also, both have to be stored in the same data structure, an array list, and so a composite design pattern was the most appropriate implementation. Keeping in focus the units, another design pattern can be offered. Once in the battle scene, units might change behaviour during the simulation. And so a state design pattern was designed to fulfil this functionality. By changing the state of units, new behaviours can be added without adding tons of code to the class. Other patterns were used, such as the null object and command, across many other parts of the project.

6.5 Analytics System

In order to extract information about the player’s activity, an analytics system had to be implemented. The easiest way to do so is to create a log for every user request. Once the back-end server contains the web dispatcher, which distributes all requests among the web services, this was the best place to implement this functionality. And so, every time an user makes a request to the server, his request will be saved in a separate database collection, along with some other request details (IP, Username, Date, Action, Result). This information can be used to monitor the player’s actions, detect exploits, or analyse the player’s progression and possible game faults. An analysis made using this system will be explained in the next subsection.

6.5.1 Second Prototype Analytics

The analytics section will be divided into two parts. The first part will analyse the player’s actions before and after each major update. There were two major updates that implemented new features in the game. The first update introduced the NPC villages, which happened in the 4th season, while the second one added Heroes and events in the 7th season. The second part of this section will analyse the game progression after the game updates. This helps to maintain the balance of the game and helps

48 understand where the game can be improved in the future. In order to understand the game progress a time line is presented below.

Figure 6.6: Seasons overview displaying actions players number during seasons.

NPC Villages Update Analytics

In order to draw valid conclusions about the game updates, it is necessary to compare two game seasons, at least one before the game update, and another after it. Two seasons were chosen for the comparison: season 3 and season 4. The number of logs generated during those seasons are, 2726 and 5649, respectively made by 9 players that participated in the first of these seasons, and 10 players that participated in the other one. Just from this data we can conclude that this update almost doubled each user’s activity, with an average of 303 actions per player before the update and 565 actions per player after the update. However this information is not enough to understand the impact that the update had on the game. To do so, a set of questions were made so it would be possible to understand the impact of the update on several game areas. The first question has to do with the player’s activity just mentioned. While it can be noted that the number of actions per player almost doubled it is important to understand its distribution. The best way to do this is to select some players and analyse their activity distribution during the season. Hence, the most active 5 players of each season were selected and their activity tracked, with the following result. As can be seen the result is not quite what was expected. Even though the the average activity per player almost doubled, the majority of the actions cames from one single player. Also, other players’ activity diminished, showing that this new update was creating a positive feedback that rewards the player that gets stronger first while punishing all the all other players that could not keep the same pace. In order to understand what happened to the players’ pregression, an analysis of their attack behaviour was made. Before, there were no NPCs, so it was to be expected to see more attacks in the season after the update. However, is important to see the attack distribution of the players, and so the following

49 Figure 6.7: Comparison between actions per player during the third season, on the left, and the fourth season, on the right. graphics were produced.

Figure 6.8: Attack distribution during season 3 and season 4.

After analysing these graphics it can be concluded that more attacks were made. The average attacks per player increased from 8.889 to 18.9. Surprisingly, the big increase in the total number of attacks was not due to attacks on NPCs but due to attacks on players. The attacks on NPCs only represent a small fraction of all attacks made, about 18% of all attacks, while player attacks saw a 198% increase. This result lead us to the conclusion that player one got an enormous advantage by looting the other players. Once there was no longer any player protection, Player 1 started looting every other player, accumulating resources from every player’s city. This made the others players frustrated, which can be checked by the activity graph. The dominant player then started conquering every NPC village creating a big disparity between the casual players and the hardcore one. The third question had to do precisely with the distribution of the NPC villages. It is important to know how much each player spent and earned for having NPC villages, so it can be seen if this mechanism is balanced. For this question, two graphs of the same season were developed: the total resources spent by player on NPC villages and the total resources earned by player on NPC villages. As expected, all NPC villages were dominated by Player 1 which generated far more resources and points than any other player. To achieve the update balance some measures were applied in the following seasons. The first measure was to implement a building that would limit the access of NPC villages per building level. To do so, the hero shrine was implemented and each level allows the player to conquer NPC villages

50 Figure 6.9: The resources used in NPC upgrades, and the resources earned in NPC villages, during season 4. one radius unit further. This measure makes players spend more resources in order to have access to more NPCs before they can conquer them, thus improving the game’s balance. Since that update wasn’t enough to avoid players conquering other players NPC villages and gaining a great advantage, other measures were taken some seasons later. Those measures also have to do with the NPC village distance. To avoid an easy conquering of all Villages by one player, a slow effect is granted to units when they are ordered to attack NPCs that are far from the player city. A 10% debuff is given for every 1 slot distance from the player’s city. This effect has a 50% slow cap so players can still be able to conquer really far away villages.

Heroes and Events Update Analytics

The second update implemented Heroes and Events. In order to understand whether the measures implemented to solve the previous problems, brought about by the NPC villages, were corrected, another season with NPCs and without Heroes was chosen to compare with the first season that incorporated those new mechanisms. Season 6 and 7, presented in the first timeline, were compared. The first of these seasons presented 7144 logs divided among 17 players, an average of 420 logs per player, while the second presented 6816 logs among 17 players, with an average of 401 logs per player. From the data presented we can see that after the update there was a slight decrease in the players’ actions. However, it is not possible to conclude just from this that those results happened because of the implementation of the new mechanisms. As was done with the previous comparison, it is better to understand the behaviour of some players along the season. Once again, the 5 most active players were selected. Before comparing both seasons, we can see that the last season without Heroes and Events presents a far more homogeneous activity than the season after the implementation of NPC villages. This factor makes us conclude that the measures taken had a positive effect on the players’ interactions. Besides that, when comparing both seasons activity, not much can be concluded. A spike of activity from player 2 at the 15th of July can be seen. However that might be due to the fact that player 2 wanted to catch up with the other players that had started the season before, and therefore spent more time on the game.

51 Figure 6.10: Comparison between actions per player during the sixth season, on the left, and the seventh season, on the right.

In this case it is also important to analyse the number of attacks made in each season. During the first of these seasons, there were 120 attacks: 37 of them on players and the rest on NPCs. In the second season, there were 183 attacks: 103 on players and 80 on NPCs. These have the following distribution:

Figure 6.11: Attack distributions during seasons 6 and 7.

Once again, neither the total attacks nor the attack distributions give us sufficient information to say that the update had a significant impact. However, we can see a shift of the targets chosen by the players. During the first of these seasons, players chose to attack more NPC villages than in the later season. This might be due to the implementation of Events. Since events affect the way that players have to plan an attack, player mazes could be appealing to players that the predefined NPC mazes which led to a change of target from the players. Even though that is a possibility, with this data it is not possible to conclude that this was a factor in the change of behaviour of the players. Other information that can help us understand the impact of the update on the gameplay is the number of units recruited before and after the update. Once heroes provide regular units with buffs, those can be unbalanced and make units far stronger than they were before. if this happened, it is to be expected that during the later season, far fewer units would units have been recruited than in the earlier one. To see this, the following table provide the number of units recruited each season as well as their type.

52 Season 6 Season 7 Scouts Recruited 562 285 Warriors Recruited 404 220 Bruisers Recruited 218 320 Total Units Recruited 1184 835

From the information obtained, it can be seen that there was a decrease in the recruitments made. Since the recruitments decreased by 30% some hero nerfs could be considered. However, it is important to state that a decrease was always to be expected, and therefore only small adjustments should be made to achieve a better game balance. The heroes implementation brought two new units, Wiseguy and Arthur, both heroes. Players can only recruit one of them at a time. Since this constraint exists, it is important to understand which hero players prefered. Since the recruitment rate of Wiseguy was 100% it can be concluded that some major changes had to be applied in order to balance the distribution of heroes. Hence, the hero power of Wiseguy was nerfed for the next season, while the hero power of Arthur was buffed.

Game Balancing Analytics

When developing a game, there are some concerns that have to be analysed. The balance of a game is something that has to be refined, over and over again, in order to achieve player satisfaction. It is not easy to provide a game that is fair to all users in the same way. To do so, it is necessary to analyse the different game components and refine the concepts and values in such a way that they will be adequate for every user, independently of their progression. In order to make such adjustments, some parameters have to be analysed. Monitoring the player’s progression is the best way to do so. This way we can compare the most varied parameters among all users and identify possible game flaws. Taking in consideration the first season after the updates, season 7, the following analytics have been extracted: daily build requests, resources spent on city upgrades, city resources earnings, re- sources spent on NPC villages and resources earned in NPC villages. By analysing this information, it can be checked whether production rates versus player expenses are balanced, what are the pre- dominant player actions, and how balanced are the different game components that share the same concerns. With this information, the diferent game components can be refactored and enhanced. Start- ing with the daily build requests, they follow the distribution presented in Figure 6.12. It was expected that players started by ordering the construction of more city buildings than towers in the beginning of the season. This didn’t happen. One reason for that might have been that players already knew, from previous seasons, that if they didn’t build any towers, other more aggressive players would attack them at the first opportunity. To better understand the players’ behaviour it is better to analyse other information that might explain the progression shown above. Attack statistics should help us comprehend some of the spikes that happened in the trower build requests, Figure 6.13. From the analysis of the previous graph, it can be seen that the construction spikes happened one day after the had more attacks on players. This led us to conclude that the action of attacking players

53 Figure 6.12: Building actions distribution.

Figure 6.13: Attack distribution during season 7. instigated players to react and build more defenses. This conclusion explains the strange result obtained from the building requests. Now that is known that there are no major problems with building requests, other game metrics should be analysed. To summarize the extracted information, the 5 most active players were selected for an examination of their resource progression.

Figure 6.14: Right: Resources spent by players on city buildings. Laft: Resources earned by players from city buildings.

54 When only taking into account the city production and expenses, the average gold spent on cities is 20,955.94 and the average materials spent is 21,466.88, while the average gold earnings are 51,444 and the average earnings are 37,600. With these values we can see that the difference between re- sources spent is about 2%, meaning that players spend on average 2% more materials than gold. When comparing such a difference with the difference in resources earned, which is about 27% more gold than materials, it is possible to see that some adjustments might be required. Trying not to take precip- itate conclusions, as this information only regards city production and city earning, some other aspects should be analysed before applying balancing measures. And so, information about the production and spending of resources on NPC villages was also taken into consideration.

Figure 6.15: The resources used in NPC upgrades, and the resources earned in NPC villages, during season 7.

From this we can see that the average gold expenses were about 30% less than the expenses of materials. Also, the average gold earnings were about 38% greater than the materials earnings. As these values suffer from the same discrepancy as the city statistics, we can see that the players suffer from a shortage of materials. Even if expenses with units and towers present the opposite discrepancy, which is true for units but not for towers, it won’t be enough to counteract the trend. Now it can be pointed out that some changes in building costs and resource production are necessary. And so, the season that followed the analysed one had the production rates balanced as well as some changes in building costs. The next season had an increase in the materials generation from 60 to 90 per level per hour. Also, some buildings got their costs balanced, such as the barracks that cost 1200 gold and 1200 materials, which were changed to 1100 gold and 900 materials. With such modifications, it was expected that production rates versus expenses would come closer. To see if such alterations had the desired impact the same statistics were once again extracted from the season that happened after, namely season 8. Making the same resource analysis we can see that the average of gold expenses on a player’s city is about 39,117 while the average materials expenses is 41,142, which gives us a difference of around 5% more materials spent. Despite the controversial result regarding the player’s expenses, we can see that there was a decrease in the difference in resource generation inside cities, which decreased from 27% to 16.7%. In NPC villages, the results were also better, presenting a 9% difference in resource expenses, representing a decrease of 21%, and 36% in resource production, a 3% decrease. It is interesting to see that this update, of costs and resource generation, had an impact on the choices

55 Figure 6.16: City Resources Management Season 8.

Figure 6.17: NPC Resources Management Season 8. made by players. These percentages would be far greater if players didn’t compensate for the increase in the production of materials by leveling more their mines than they did in previous seasons. In the first of these seasons the average city mine level was 5.4 and the NPCs’ average mine level was 1.3, while in the second of these seasons, the average city mine level was 6.2 and the NPCs’ average mine level was 2.6. From the information presented above it can be concluded that such alterations had a good impact on the players’ progression, improving their resource collection and management.

6.6 Final Prototype Survey

Even with the implementation of an analytic system that enabled us to extract information as presented above, this is not enough to understand some interaction concerns and the users opinions about the project developed. Hence, in this section there will be analysed a survey that the players were asked to answer in the project’s stage. A total of 16 answers were collected, that provide answers to interface issues, resource balance, attack balance, and generic questions about what they most liked about the game and what they didn’t like. The analytics presented information to balance the game, hence the survey answers about game balancing will be less explored in this section. However, questions about the usability will receive a special focus as no information could be extracted about this concern from with the analytics system

56 implemented.

in addition to all the information produced by the analytics system, the extraction of information about the usability of the user interface is of the essence. In order to understand whether the interface presented is concordant with and appropriate for the game, a set of questions were prepared and pre- sented to the players so their opinions could be received. The first question had to do precisely with how adequate was the game interface for the platform and the game style. Below are presented the question and the users’ answers.

Figure 6.18:

The average answers are situated between 3 and 4, which indicates that the user interface is good for the game presented. But such an average result might also indicate that some minor adjustments can be made to improve the game interface. The last three questions of the survey tried to obtain opinions about improvements that could be made to each one of the game scenes.

Another concern was about the player information. In most RTS games, user information is often displayed on the top of the game screen. Following this trend, Mazekeeper also opted for displaying this information on the top of the screen. To evaluate the user’s satisfaction with this decision, the following question was presented in the survey.

Figure 6.19:

57 Not disappointingly, the users’ answers followed the game trend. As the resources bar had been classified as satisfactory by the players, other UI components were assessed. The scene navigation was also a main concern. Users should be able to access the different game scenes as quickly as is possible. The navigation implemented in the game was designed to provide this flexibility. However, some redirections of interfaces, for example the redirect after watching a battle simulation, might not been very satisfactory. To evaluate the game navigation, the following question was put.

Figure 6.20:

As expected the results are good but not the ones desired. To improve the user usability, some refactoring of the game navigation might be considered. In what regards the game’s economy, all the questions asked could also be analysed by the analyt- ics provided before. Questions about building expenses and production, troops expenses and respective loots and NPC resource management, were asked, but since these questions were already treated be- fore, not much analysis will be made here. However, in order to corroborate the information presented in the previous section, some graphics are compiled in Figure 6.21.

Figure 6.21: Survey results related with game balancing measures.

As presented in Figure 6.21, it can be seen that the alterations made during previous updates

58 had a positive impact on the players’ opinions. All of the questions asked had more than 80% positive answers, meaning that the players were satisfied with the resource production and resource expenses. Despite the analysis provided earlier regarding the combat system, some questions are important to present. The first question tried to collect the user’s opinion about the battle simulation. As was explained previously, the battle system was a choice made from three options. Since the option chosen could present problems in the battle consistency, it was necessary to assess the user’s opinion about its consistency.

Figure 6.22:

By the answers collected we can see that 87.5% of the players didn’t find or didn’t notice any problem in the simulation. However, since 12.5% of the answers were negative we can conclude that those players saw animations that did not correspond to what happened in the server. Since there are some negative answers to this question, it is important to note that some improvement of the battle system should be made. But by obtaining 87.5% positive answers, and since consistency was the major problem with this system implementation, it can be said that the option chosen was a good choice. There was another concern that was hard to assess by the game analytics. The events, introduced in the last patch, don’t provide a direct way of compiling information about user preferences. So, this survey also tried to assess wether this update had a positive impact on the game. To understand this, the players were asked whether they thought the event system dynamised the defence and the attack strategy. With these answers, it can be concluded that both aspects of the game benefited by this update.

59 Figure 6.23:

60 Chapter 7

Conclusions and Future Work

The development of a system, like a web game requires paying attention to multiple aspects. There are multiple conclusions that can be drawn from a project such as the one described and analysed in this thesis, and much more things that could be added. In this chapter we will start by compiling some conclusions taken from the development of this system and then present possible future implementations that might improve the game developed.

7.1 Conclusions

A web browser game is a much more complex system than might appear at first glance. Developing a computer game is much more than developing other computer program. Games have to give players the will to play and to keep playing. Hence, interesting mechanisms have to be developed, nice art work has to be incorporated, and good information must be extracted so that the game can become appealing to as many users as possible. Beyond that, a computer game must also have the best characteristics associated with a software program. Considering the project presented and delivered, it can be said that all of those things were taken into consideration, as well as analysed. But even so, it did not instigate the interest that it was thought it would. One of the reasons might be the low quality of the art work used. All interface components were developed using primary tools or downloaded from opensource communities. With such components players are not graphically attracted to the game, and this might lead to quitting. Another possible reason is the small community that was engaged in playing. Players nowadays like big communities in the games they play N. Ducheneaut, N. Yee, E. Nickell, and R. Moore [2006], because more competition is available or just because they have more friends playing it. It is also important to refer to the extent of the areas that a computer game has to master. Such a complex system has to be acceptable in terms of the most varied areas, such as graphics, processing performance, network, and even database management. With such requirements, the search for the best technologies that enable game designers to develop the desired game is a key factor. Documen- tation and planning will also help to keep the project organized and endowed with the best architecture that fulfils all the game requirements. In addition, a computer game must also fulfil the psychological

61 requirements that make something a game. From this project it was learned that creating a game starts with creating a good game concept. Having carried out good background research can help to have better ideas. Developing low fidelity prototypes will help to understand whether the developed game concept is fun. It is also important to make as many iterations as possible, so that game concept corrections can be made or small details can be polished. Having a group of people that is interested in participating is also a key factor, because the game designer can see whether they are motivated and whether they have suggestions for the work presented. Players information can be extracted in several ways, and the best way should be appropriate to the solution that the game developer is seeking. Balancing a game is also a very complex process: even minor alterations can have large impacts on the players’ game play. Developers should have a way of constructing metrics for the different game parameters so they can compare different components and thus understand whether they are balanced. Developing a web game system, was a challenging and fun project. Much has been learned. However, after understanding the complexity of such a project, it was realised that much more is still to be learned.

7.2 Future Work

There are still some ideas for the Mazekeeper concept that have not been implemented. Talents were one of these features. In order to give players more personalization of their cities, there was designed a system that would provide a set of choices that players would have to choose between. As in other games, talents make the player’s character, city, or whatever they are in charge of, more different from the others’. In this way, a talent system was also designed to Mazekeeper with some differences that would help make this system unique within the set of existing ones. unlike other talent systems that are presented in talent trees, the Mazekeeper talent system would consist in a graph, such as the one implemented by Final Fantasy XX or Path of the Exile. Those talent systems provide a better customization to the player. In Mazekeeper, the nodes that would start the graph would correspond to the four elements, and thus give different effects to units and towers, depending on the path chosen by the player. Another feature that was designed but not implemented was that of guild systems. Guilds would allow players to join together and organize attacks, promoting more the social component that exists in such games. No special system was considered in this case. However an implementation of a different guild system would entice players to try it and could be another player hooking factor. Given the circumstances of the platforms and technologies available, the reimplementation of the game client to mobile seems more contextualized. Nowadays, people use their mobile devices not only to call and text people but also to play during ther dead time. Providing a game as such, for a browser, is a little decontextualized. Players have changed the habit of having browser games that they can access while working on their computer, or other circumstances that they were in front of the computer, to that of accessing their games on their mobile phones. Some time ago, that wasn’t possible, due to the capacity

62 of the mobile machines, but nowadays those constraints no longer exist. Hence, mobile games have taken the place of browser games and therefore changing the target platform could please more players and could make the current players more active, once they could access it more easily.

63 64 Bibliography

MongoDB Documentation. https://docs.mongodb.com/. Documentation last consulted 17th of August 2017.

Retail principles for free-to-play games. GameSparks, 2016.

M. Azevedo. Teses, Relatorios´ e trabalhos escolares. Universidade Catolica´ Editora, 2004.

C. Izurieta , N. Nurseitov, M. Paulson, and R. Reynolds. Comparison of json and xml data interchange formats: A case study. Department of Computer Science, 2009.

C. Martinho, P. Santos, and R. Prada. Design e Desenvolvimento de Jogos. FCA, 2014.

D. Williams , N. Martins , M. Consalvo , and J. Ivory . The virtual census: representations of gender, race and age in video games. ACM Conference on Human Factors in Computing Systems, 2009.

Epic Games. Unreal engine documentation, 2017. Documentation last consulted 10th of August 2017.

Goodboy Digital. Pixijs — the html5 creation engine documentation, 2017.

J. James Garrett. Ajax: A new approach to web applications. semanticscholar, 2005.

J. Kurose, and K. Ross. Computer Networking - A top-Down Approach. Pearson, 2013.

L. Nacke , C. Bateman, and R. Mandryk. Brainhex: Preliminary results from a neurobiological gamer typology survey. Saskatoon, SK, Canada, 2011.

M. Buro. Real-time strategy games: A new ai research challenge. Department of Computing Science, University of Alberta, Edmonton, 2003.

N. Ducheneaut, N. Yee, E. Nickell, and R. Moore. “alone together?” exploring the social dynamics of massively multiplayer online games. ACM Conference on Human Factors in Computing Systems, 2006.

P. Avery, J. Togelius, E. Alistar, and R. Pieter van Leeuwen. Computational intelligence and tower defence games. Center for Computer Games Research IT University of Copenhagen, 2011.

P. Clements et al. Documenting Software Architectures - Views and Beyond. Addison-Wesley, 2010.

C. Poladian. ‘clash of clans’ maker supercell posts $2.3b in revenue, $930m in profit for 2015 as growth slows, March 2016.

65 Springer, editor. Relational Algebra and SQL. In: Introduction to Constraint Databases. Springer, New York, NY, 2002.

Unity Technologies. Unity documentation, 2017. Documentation last consulted 10th of August 2017.

J.-M. Vanhatupa. Browser games for online communities. tampere. Finland: Department of Software Systems, Tampere University of Technology, 2010.

Z. Parker , S. Poe , and S. Vrbsky . Comparing nosql mongodb to an sql db. Proceedings of the 51st ACM Southeast Conference Article, 2013.

66