TIṬAL – Asynchronous multiplayer shooter with procedurally generated maps

Entertainment Computing xxx (2016) xxx–xxx

Contents lists available at ScienceDirect

Entertainment Computing

journal homepage: ees .e lsevier .com/entcom

TIṬAL – Asynchronous multiplayer shooter with procedurally generatedmapsq

http://dx.doi.org/10.1016/j.entcom.2016.02.0021875-9521/� 2016 Elsevier B.V. All rights reserved.

q This paper has been recommended for acceptance by Nikitas Marinos Sgouros.⇑ Corresponding author.

E-mail addresses: [email protected] (A. Bhojan), [email protected](H.W. Wong).

URL: http://www.comp.nus.edu.sg/~bhojan (A. Bhojan).

Please cite this article in press as: A. Bhojan, H.W. Wong, TIṬAL – Asynchronous multiplayer shooter with procedurally generated maps, Entertainmput. (2016), http://dx.doi.org/10.1016/j.entcom.2016.02.002

Bhojan Anand ⇑, Wong Hong WeiSchool of Computing, National University of Singapore, Singapore

a r t i c l e i n f o a b s t r a c t

Article history:Received 1 March 2015Revised 21 January 2016Accepted 19 February 2016Available online xxxx

Keywords:GameTIṬALProdecural content generationGame map generationBotsArtificial intelligence

Would it be possible to bring the promise of unlimited re-playability typically reserved for Roguelikegames to competitive multiplayer shooters? This paper tries to address this issue by proposing a novelmethod to dynamically generate maps at run-time almost as soon as players press the Play button, whileensuring the features what players would expect from the genre. The procedures are simple and practi-cally feasible to be employed in actual computer games. In addition, the work experiments the possibilityof incorporating asynchronous game-play element into a multiplayer shooter with human imitating botswhere the players can let their bot/avatar replace them when they are not around. The algorithms areimplemented and evaluated with a playable game. The evaluations prove that playable 3D dynamic mapscan be generated in order of seconds using game context data to initialise the parameters of the algo-rithm. The paper also shows that asynchronous game-play element is a possible feature for considerationin next generation multiplayer shooters.

� 2016 Elsevier B.V. All rights reserved.

1. Introduction

This paper demonstrates a novel method for procedurally gen-erating dynamic maps at run-time at the click of the ‘Play’ buttonusing game context data and experiments the feasibility of bring-ing asynchronous game-play element in next generation multi-player shooters. We have created an experimental game entitledTIṬAL, a Multiplayer Shooter in the form of a First-Person Shooter(FPS) with novel approaches in the design of procedural mapsand human-imitating bots.

We limit our scope to the game mode Capture and Hold, pop-ularised in games like Killzone [1]. Every player belongs to one of 2teams. Littered around the map are flags that are captured by plac-ing players in close proximity. A captured flag (can be recaptured)lowers the team points for the opposing team continuously. A teampoint of 0 signals the victory of the opposing team. To win, teamshave to actively defend and pursue flags.

1.1. Procedural content generation

Procedural Content Generation (PCG) is the use of algorithmicmeans to create content [2,3] dynamically during run-time. Insteadof trekking the same grounds which gets stale with time, PCG pro-mises a more novel experience every playthrough. PCG was uti-lised in games as early as 1978. A notable example is Rogue [4,5]which spawns a new genre known as Roguelikes. Core featuresinclude randomly generated levels, item locations and so on. PCG’sinfluence extends to racing games like Gran Turismo 5, which pro-cedurally generates its tracks [6]. First Person Shooter (FPS) Border-lands series procedurally generates weapons [7].

1.2. Multiplayer shooter

We believe that an exception to PCG lies with environments/maps for multiplayer shooters such as Battlefield [8], whichremains one of the most popular genres to date [9].

The reader should note the difference between a multiplayerand a standard shooter, which often follows an approximately lin-ear path. The competitive nature of multiplayer shooters bringsadditional challenge of ensuring fairness through the positioningof strategic points. Moreover, players typically have more freedomto move around the map. It is for these reasons the designers oftentake a different approach to craft multiplayer maps.

. Com-

http://dx.doi.org/10.1016/j.entcom.2016.02.002

mailto:[email protected]

mailto:[email protected]


http://www.sciencedirect.com/science/journal/18759521

http://ees.elsevier.com/entcom


2 A. Bhojan, H.W. Wong / Entertainment Computing xxx (2016) xxx–xxx

In this paper, we present a novel method that uses carefullyselected game context data to generate dynamic maps almost assoon as the player press the ‘Play’ button, without compromisingthe expected features of a good multiplayer shooter environment.The method is simple, practically feasible and we have imple-mented and evaluated it with the test game. We call our methodas ‘game context aware dynamic map generation’ method.

1.3. Human imitating bot

Recently, we are exposed to the concept of asynchronous multi-player. Unlike games which demands players to play simultane-ously, asynchronous multiplayer games can be played at anytime. In Draw Something [10], the other player does not need torespond instantly in every round.

TIṬAL experiments with the possibility of incorporating such anelement into a multiplayer shooter. To allow this, the player canplay against a bot that imitates the behaviour of a teammate, sim-ilar to Forza Motorstorm [11].

We also present a method for creating bots that take after thebehaviour of a player. In contrast to previous methods that recordshuge data containing movement and action patterns to mimic thebehaviour, we learn and store only the key parameters that aremeaningful for the given game genre to mimic the behaviours inkey decision points of the game. By using such game context awarelearning, the storage and computation requirements are signifi-cantly reduced while producing human like behaviour. Like inPCG, the method is practically feasible and has been implementedin a multiplayer shooter and evaluated with a group of users.

1.4. Overview

In the rest of this paper, we first discuss the motivations for thiswork in Section 2 and then related works in Section 3. In Section 4we state the design goals of our map generation method beforedescribing how it is achieved in Section 5. We then explain thedesign of the human imitating bots in Section 6. Implementation,results and evaluations are described in Sections 7–9 respectively.Finally, we discuss the limitations and future works in Section 10before concluding with Section 11.

2. Motivation

In this work, we are attempting to automatically create play-able, balanced (fair) and interesting maps for multiplayer shooters,with a novel approach built using Search-based PCG [2]. While PCGis used by some multiplayer shooter game designers, who wouldprocedurally generate maps and thenmanually tweak them to shipwith the final product, our goal is to remove the human interven-tion completely. This means that the generation should be com-pleted within a span of seconds, or else the patience of theplayer could wear thin. If we are successful, the development timeand cost needed to create maps for similar games could be drasti-cally reduced. The result would be increased longevity that stemsfrom the near limitless amount of maps for players to play in.

We also aim to create Human Imitating Bots to incorporateasynchronous gameplay to a new genre. Unlike most works whichaims to create human-like behaviours using a huge repository ofplayer’s play throughs, we hope to imitate the behaviour of a singleplayer and apply it to any map. Its success could bring about some-thing fresh, allowing players to create a ‘doppelganger’ of them-selves and watching it climb the ranks as it compete with others.It also reduces the time commitment players required for suchgames.

Please cite this article in press as: A. Bhojan, H.W. Wong, TIṬAL – Asynchronousput. (2016), http://dx.doi.org/10.1016/j.entcom.2016.02.002

3. Related work

3.1. Procedural generation of map

Güttler and Johansson [11] identified basic spatial properties ofmultiplayer FPSes and proposes heuristics for better level design.In addition, the insights provided by industry leaders on designof multiplayer games [12–14] assist the formulation of our designgoals.

Search-based PCG (SBPCG), an approach to PCG, was introducedby Togelius et al. [2]. We will be employing a similar approach inour solution.

Togelius et al. also manages to procedurally generate tracks fora racer [15] and maps for Starcraft [16]. In both cases, SBPCG isused with a simulation-based fitness function. Kerssemakerset al. [17] introduces a procedural PCG generator to generalisePCG with the use of a simulation-based fitness function. However,the use of simulation-based fitness function is not suitable for ourgoals, due to the time it takes to create a map is long and it is notsuitable for practical implementations due to the strict real timerequirements imposed by the games and game players.

Yeh et al. [18] presents the Markov chain Monte Carlo (MCMC)algorithm to create open world areas which are relatively easy tocreate when compared to complex closed area maps which basi-cally represent big buildings. Michael et al. [19] proposes a methodof tiling entitledWang Tiles for image and texture generation. Mer-rell et al. [20] identifies furniture design guidelines for indoor areasand proposes ways to suggest layouts that fit those guidelines.Similarly, a method for constructing concrete-based buildings isintroduced by Liu et al. [21]. However, their focus is only on gener-ating components for the game map, but not the entire map.

Work done by Cardamone et al. [22] to evolve interesting mapsfor a FPS leveraging on SBPCG is a great starting point. However,work needs to be done to ensure that the map can be generatedwithin seconds. Moreover, the maps that are generated are seem-ingly low on navigability and aesthetics, which are basic features ofany good multiplayer game. In contrast, navigability and aestheticsare part of our design goals.

3.2. Human imitating bot

The work by Ortega et al. [23] introduces us to imitating humanplay styles in Super Mario Bros.

Thurauet al. [24] createdanAI Bot that captures themovementofa human player in a FPS. It relies heavily on how players move andthen replicating it in the same map. For our game, we also aims tocreatemaps dynamically Therefore,wewant to bring this behaviourto any maps even if part of the accuracy has to be sacrificed. More-over, it relies on massive existing player data to craft them, whichdiffers from our goal of obtaining a good model of a single player.

Verweij [25] shows us techniques in implementing multiplayerbots which drives the design of our AI. The paper by Waveren [26]details the Quake III Arena Bot which is mostly state-based andtherefore may lack the nuance needed for mimicking humanbehaviour.

Schrum et al. [27,28] introduces us to the UT2 bot for UnrealTournament 2004, which maintains life-likeness after evolvingwith a set of human play traces but is not exclusive to a singlehuman player.

4. Map design goals

We describe what we want to achieve by identifying elementsof interesting maps (of multiplayer shooters) so that they can beincorporated into our design.

multiplayer shooter with procedurally generated maps, Entertainm. Com-


A. Bhojan, H.W. Wong / Entertainment Computing xxx (2016) xxx–xxx 3

Fast Generation – We wish to generate the maps in real-time.In other words, the final map has to be generated within a spanof seconds to minimise player frustration.Collision Points – Güttler and Johansson [11] defines collisionpoints as areas that see the most clashes and where most tacti-cal choices are made. Tactical choices begin with preparations(route to take and so on), and ends with a confrontation. Thedesigner should be aware of them to give more opportunityfor tactical choices [14]. In contrast, a map with no clear ortoo many such points are likely to see players stumping ontoopponents unexpectedly.Flow – The designers in [13] emphasise on flow, an ‘‘invisibleflow (that is) continually impelling the player onwards”. As thisis too abstract, we deconstruct it into measurable components –Navigability and Pacing.– Navigability – players should be able to recognise where

they are and where they should go.– Pacing – confrontation should last enough to be fun but

should be accompanied by some respite, but not to theextent of inducing boredom [11]. Also, the map should nothave disruptive dead ends.

Even though they may not fully encompass it, we have observedthat they provide reasonably good flow and serve as good start-ing point for future research.Fairness – Each team should have same chance of victory [11],which is related to flags. A team with flags closer to its spawnpoint has a higher chance of capturing them.Aesthetics – The design must have the potential to meet aes-thetics demand of players. There is a rich set of taxonomy thatcollectively define aesthetic [29]. For instance, a map cannotconstitute entirely of blocks. Instead, it should contain trees,vehicles and so on to create more natural challenges. In addi-tion, having diverse items improve navigability, as players canuse them to get their bearings. We seek to give some degreeof control for alteration of the map’s appearance.

5. Game context aware map generator design

In this section we describe our algorithm to generate interestingmaps for multiplayer shooters, which makes use of the popularSearch-Based Procedural Content Generation (SBPCG) [2]method. We employ generate-and-test approach as illustrated inFig. 1.

We first present how a map blueprint is created by our initial-isation algorithm in Section 5.1. Then, we detail how it evolves

Fig. 1. Illustration of a SBPCG process. Only acce


with a fitness function to produce the final map blueprint andhow it is mapped to the actual game environment in Section 5.2.

5.1. Initialisation algorithm

Our initialisation algorithm consists of several phases. We firstpopulate the blueprint piece by piece before determining where toplace strategic points and computing its fitness. Carefully selectedgame context data is used in the initialisation algorithm, which isthe key idea in our approach to get high fitness value at the begin-ning of the evolution. By starting evolution algorithmwith high fit-ness value, we reduced the number of evolution rounds required(to converge) by several order.

5.1.1. PHASE I: Populating game tilesEach game tile comprises of four smaller cells, which belong to

either an indoor area (inside a building), outdoor area or inaccessiblearea as shown in Fig. 2a. A game tile can be placed in a locationadjacent to another game tile only if the neighbouring cells match(Fig. 2b). We call this adjacency requirement as Rule of AdjacentGame Tiles.

The map uses a grid layout, with each ‘square’ occupied by agame tile. The grid is first enclosed by a layer of fully inaccessiblegame tiles. This ensures players cannot move outside the map.Next, game tiles of random types are placed in unoccupied‘squares’, constrained by the rule of adjacency (Fig. 2b). This isrepeated until it is fully filled. An example of the generated mapcan be seen in Figs. 3 and 4.

5.1.2. PHASE II: Cleaning upWe notice several artifacts like overly small buildings or pro-

truding parts of buildings’ remains. We scan the map blueprintboth vertically and horizontally, removing single cells which aresurrounded by cells of different types as depicted in Fig. 2c. Thisis necessary to give the map a ‘cleaner’ look with more regularlyshaped buildings which would otherwise hurt its navigability.

5.1.3. PHASE III: Identifying regionsTo analyse the map, the algorithm requires an understanding of

its layout. We first identify regions of the map, which are eitherindoor or outdoor. Region detection is done by applying a Flood Fillalgorithm to the cells, stopping when it reaches its maximum sizeor when no cells are left. This is repeated until all accessible cellsbelong to a region. The maximum size is proportional to the map’ssize and can be tweaked. Note that cells of different types cannot

pted maps are used in the next population.



Fig. 2. (a) Types of game tiles (not complete), (b) rule of adjacent game tiles, and (c) removing artifacts horizontally.

Fig. 3. Initialisation algorithm PHASE I–III. Each colour represents a region, and the brown icon is a door. (For interpretation of the references to colour in this figure legend,the reader is referred to the web version of this article.)

Fig. 4. Initialisation algorithm PHASE IV. Each colour represents a region, and thebrown icon is a door. (For interpretation of the references to colour in this figurelegend, the reader is referred to the web version of this article.)


share the same region; Indoor region contains only indoor cells andoutdoor region contains only outdoor cells.

5.1.4. PHASE IV: Connecting regionsBy identifying regions, we can construct an undirected graph

with each node located approximately at the region’s centre. Nodesare connected by an edge if players can move directly from one tothe other without passing through a third one. At this stage, noedges exist between indoor and outdoor regions. For every indoorregion, edges are created to connect to an neighbouring outdoor


region. This adds a door between them and improves the connec-tivity of the map. The same applies to all indoor regions of biggerbuildings with multiple regions. It is therefore natural to have mul-tiple doors at different points within it. Otherwise, moving deeperinto a large building always result in a dead end. Most parts of thegenerated map is connected after this phase. However, there areexceptions where regions are fully surrounded by inaccessiblecells.

5.1.5. PHASE V: Positioning of strategic pointsSpawn Points, position of Flags, Collision Points and Covers are

strategic elements which are depicted in Fig. 5. Two Spawn Pointsare required for ‘Capture and Hold’ games, one for each team. Theyare positioned by identifying the two nodes of the graph that arethe furthest away from each other geographically. Four Flags (teamflags) are planned for the map. Each team is assigned a flag (cap-tured) at the beginning of the play. They are positioned at thenodes closest to the teams’ spawn points. The two remaining flagsare neutral (not captured). A straight line is first ‘drawn’ betweenspawn points. Each side of the line will contain a neutral flag. Theybound to a node with the minimum difference in travelling dis-tance (using the Dijkstra algorithm) from both spawn points to pre-serve fairness. Collision Points are identified by the degree of thenode. A high degree node most likely belongs to a region that play-ers are prone to meet as many different routes will lead to it. Weobserved that a degree of five and above makes a good conditionfor a collision point. Covers are placed approximately at the meet-ing point of regions that have an edge to the collision points. Thishelps with promoting tactical choices as it provides more optionsto players who are more likely to meet at collision points. Coversare also placed at nodes which have not been assigned anything.Since these nodes are usually at region centres, the covers act asgood places to hide if a firefight is to break out at that region. With-out it, there may be too many open areas.



Fig. 5. Map blueprint after PHASE V. The shields are the spawn points. The flagicons show the position of the flags. The shield and sword icon near the centrerepresents a collision point. The thicker lines are covers.


5.2. Evolution

5.2.1. Fitness computationA fitness is assigned for the evolutionary algorithm to tell how

good the map is. There are 3 approaches [2]. Interactive FitnessFunction grades it based on interaction with a player. As this isphysically impossible, this approach is not considered.Simulation-Based Fitness Function uses AI (Artificial Intelligence)agents to play through a portion of the game for evaluation. Manyresearch works [15,17,22] used simulation-based fitness functions.However, its weakness lies in the time required to compute it.Therefore, we have employed Direct Fitness Function, where a con-tent is judged by retrieving a list of features. In our solution, the fit-ness is computed by simply summing up the normalised (in therange 0.0–1.0) values for all of the following features which arederived based on the design goals presented at the beginning ofthis Section.

1. Connectivity – Returns 1 if the graph is connected (as detectedin PHASE IV). Otherwise, returns 0. All regions are reachable in aconnected map.

2. Forced Collision Points – Returns 1 if there are one or two col-lision points. Returns 0 if there are zero or more than two col-lision points (no clear collision points). Ideal number ofcollision points depends on the map size.

Fig. 6. Various forms of app


3. Flag Fairness – Difference in the distance travelled to own teamflag. This is measured by finding the travelling distance fromthe spawn points to the corresponding team flag. The returnedvalue is normalised to 0–1, with 0 being maximum distanceapart and 1 being approximately the same distance apart.

4. Overall Flag Fairness – Similar to Flag Fairness, but returns thedifference in distance travelled to all flags from the spawnpoints instead.

5.2.2. Evolution and mappingThe first population consists of three map blueprints generated

with the initialisation algorithm. They are then mutated threetimes each, producing nine more blueprints. Each mutationremoves a random segment of the map and repopulate it withthe initialisation algorithm. With that, the population is completewith twelve map blueprints. Three of the best maps (based on theirfitness values) are picked and mutated three times to form the sec-ond population. This continues until the fitness value stabilises oruser configurable maximum time limit is reached. For example, ina sample run shown in Section 8.1.1, the fitness stabilises after 26populations (depicted in Fig. 11). As time is a concern for practicalreal-time application, the algorithm stops when the maximumtime limit (which is less than 10 s for Intel Core i7 based systems)is reached, and the blueprint with the highest fitness is selected.There will be a trade-off between quality of the map and process-ing speed. For Intel Core i7 machines, it produces high quality play-able maps within 10 s.

The final map blueprint obtained after the evolution is thenused to create the actual environment. Doing so is a direct mappingof each abstract game tile (in blueprint) to one of the many varia-tions of concrete and matching game tiles seen by the player.When the game creates the map, it randomly picks one of thematching game tiles and puts it into the game world, as shownin Fig. 6. By doing this, we allow some freedom for the artist to dec-orate the tile. They can, for instance, park a truck next to a wall orhave slanted walls drawn with graffiti.

6. Human imitating bot design

In this section, we will be describing the design of our humanimitating bot. This is separated into 2 areas – the AI System forcontrolling the behaviour of the bots and the Learning Mechanismto get them to imitate the player. State-of-the-Art AI bots in com-mercial games and research works are based on large amount ofplayer movement and action data. The bots simply follows the pat-terns in these data. In contrast, our method considers learninggame context based key parameters which define the player’s per-ception and thought process at various points in the game. The

earance of a game tile.




storage and processing requirements are significantly reduced bystoring only the key parameters that are meaningful for the givengame genre. Though the bot may not follow the player’s move-ments step-by-step, it will behave like the player in key decisionpoints such as deciding whether to take first branch or secondbranch when a road is split into two branches.

6.1. AI system

The AI System controls the overall behaviour of the bots. To imi-tate a player, the design of the bot attempts to mimic a player’sperception and thought process when playing.

Similar to our PCG design, the entire battlefield (after mapping)is split into cells but are much smaller than PCG’s cells. It can bemarked as inaccessible, meaning that there is obstruction withinthe cell which blocks the bot’s path and view. Note that smaller cellsize yields accuracy at the expense of performance.

The system uses parameters to represent each aspect of thebot’s behaviour. Each parameter is assigned numeric value withina range assigned manually by careful study and testing. Theparameters stated for the rest of the paper is its normalised form(0 indicates the minimum of its range and 1 is its maximum).

6.1.1. Overview

Cell Expiry – Accessible cells are either known or unknown. Onevery update, multiple ‘rays’ are casted from the bots’ view,stopping at an inaccessible cell. Every cell that is within its pathis known and given an expiry value of Cell Expiry Parameter.Expiry decrements with each update. When it reaches 0, the cellbecomes unknown. This models perception and spatial memoryof players.Opponent Hold Expiry –When the bot no longer ‘sees’ a target,last known target position is recorded. The bot may pursue thelast known position like a valid target, but eventually assumesthat the target has left. This behaviour uses Opponent HoldExpiry, which starts dropping from a value of Opponent HoldExpiry Parameter when the target is not in view. When itreaches 0, the target is assumed to be gone.Interest – Each known cell stores a Move Interest and ViewInterest. Move Interest (Section 6.1.2) indicates how interestedthe bot is in moving to it. View Interest (Section 6.1.3) showshow interested the bot is in looking in its direction. Both areindependent of each other.

6.1.2. MovementWe now describe the features that alters Move Interest. At

every update, a path is computed to move the bot to the cell with

Fig. 7. Gray cells are unknown cells and black cells are inaccessible. As the cell withmove interest of 65 is the highest, the blue team bot will move there next. (Forinterpretation of the references to colour in this figure legend, the reader is referredto the web version of this article.)


the highest move interest. The pseudo-code is shown in Algorithm1 and illustrated in Fig. 7.

Algorithm 1. GetMovementPath

knownCells: list containing all unexpired known cells

for each knownCell in knownCells doset knownCell move interest to 0addFlagMoveInterest(knownCell)addTargetMoveInterest(knownCell)addFearMoveInterest(knownCell)addVisibilityMoveInterest(knownCell)addCombatLeftMoveInterest(knownCell)addCombatRightMoveInterest(knownCell)addRandomness(knownCell); // add a random value to moveinterest

end forbestCell: retrieve cell with highest move interestreturn pathTo(bestCell)

Flag Move Interest – In the beginning, Breadth-First Search(BFS) algorithm is applied with each flag as the source until all cellsare processed. With this, each cell stores the number of cells to tra-vel to each flag. As the interest to move to a flag is dependent onwhich team the flag belongs to and the points of the flag, eight FlagMove Parameters are defined for each (Owner, Points) pair asshown in Table 1.

(Note: A similar method is used for defining parameters of therest of features such as Target Move Interest, and Fear Move Interest.For brevity, the tables such as Table 1, will not be reproduced forothers).

Flag Move Interest for a known cell is calculated as follows:

FlagMove Interest¼ maxflag¼0!3

ðpfm;owner;points �ðmaxDist�distToFlagflagÞÞ

ð1Þwhere pfm;owner;points is the flag move parameter for the current flagbelonging and points, maxDist is the greatest distance in the mapand distToFlagflag is the distance from the cell to the flag

The parameters show the level of interest placed for moving tothe flag based on their distance apart, captured team and points ithas. Using Table 1, if the bot is of equal distance between two flags,the one captured by the opponent with low points will be selected.

Target Move Interest – This models movement when facing atarget. The Target Move Parameters specify the level of importancein wanting to move to some distance away from the target. Theyare specified for each (Ammo, HP) pair.

Exactly what distance from the target to move to is specifiedwith the Target Move Distance Parameters for each (Ammo, HP, Dis-tance). A player who can aim well may find a safe distance to takeout his target. Another player may like to be close. The overall Tar-get Move Interest for each known cell is computed as follows:

Target Move Interest ¼ ptm;ammo;hp � ptmd;ammo;hp;dist ð2Þ

Table 1Flag move interest example.

Owner/points Low Med Full

Opponent 0 1 0.732289Ally 0.050026 1 0.82964Neutral 0.912007 0.429298 Unused



Fig. 8. The left and right figures shows the view interest for known cells andpotential directions respectively. As the top-right view direction has the highestview interest, the bot turns left to look there.


where ptm;ammo;hp is the Target Move Parameter and ptmd;ammo;hp;dist isthe frequency of moving this distance apart for the current ammoand HP.

Fear Move Interest – Also part of combat behaviour is Fear,which places more importance to nearer and therefore, safer cells.Combining this with Target Move Interest creates interestingdynamics. Take a bot that imitates a player that frequently firesfrom afar. It stumbles on a target at short range. With high Fear,the bot attempts to take it out immediately. Otherwise, it willmove further before firing. Nine Fear Move Parameters are assignedfor each (Ammo, HP) pair. All known cells are assigned a Fear MoveInterest that is computed as follows:

Fear Move Interest ¼ �ðpfem;ammo;hp � distApartÞ ð3Þwhere pfem;ammo;hp is the fear move parameter for the current ammoand HP and distApart is the number of cells between this cell andthe target.

Visibility Move Interest – This feature alters move interestbased on the visibility of the target. It defines the interest of mov-ing to a cell which is not visible to its target (a cover). Nine VisibilityMove Parameters are defined for each (Ammo, HP) pair. For eachknown cell, a ray is casted from the bot to the target. If it can reachthe target without any obstruction, the cell’s move interest isadded the parameter.

Combat Move Interest – The last feature models the tendencyto strafe in combat. Combat Move Left and Right Parameters aredesigned for strafing left and right respectively. Known cellsdirectly at the side of the bot are added this parameter to its moveinterest in combat.

6.1.3. ViewingNext, we describe the features that alters View Interest. Similar

to move interest, each addition to view interest is based on fea-tures that we will be defining. The decision on which direction tolook at is decided in Algorithm 2 and illustrated in Fig. 8.

Algorithm 2. GetBestViewDirection

knownCells: list containing all unexpired known cellsviewDirections: list containing all 8 possible view directionsbestViewDir: best view direction to return

// retrieve exploration view interestfor each viewDir in viewDirections doset viewDir view interest to 0addFlagViewInterest(viewDir)addHitCheckViewInterest(viewDir)

end forbestViewDir = retrieve viewDir with highest view interest

// retrieve other view interest for all known cellsfor each knownCell in knownCells doset knownCell view interest to 0addFlagViewInterest(knownCell)addForwardViewInterest(knownCell)addTargetViewInterest(knownCell)

end forbestCell: retrieve cell with highest view interest

if bestCell.viewInterest > bestViewDir.viewInterest thenbestViewDir = (bestCell.position � currentPosition)

end ifreturn bestViewDir


Unlike move interest, view direction is decided by not only thebest cell, but also the best view direction.

Exploration View Interest – This is assigned to all potentialview directions (centred on the current view direction). Rays aresent from multiple angles within the bot’s Field of View (FOV) inthat direction. This models how interested the bot is in exploringunseen areas. This interest is affected by the number of unknowncells, known cells and their expiry value, and the Exploration ViewParameter within the FOV.

Exploration View Interest ¼ pe � uþXki¼0

0:5 � expiryi=expiryMax

!

ð4Þwhere pe is the exploration parameter, u and k are the number ofunknown cells and known cells that can be reached by the raysrespectively, expiryi is the expiry value of cell i, and expiryMax isthe maximum expiry value.

Hit Check View Interest – This interest is also assigned to adirection. It mimics player’s tendency to search for the assailantwhen hit. Since it is impossible to tell the exact position of the fir-ing position, it would be less accurate to assign it to a cell. Instead,the Hit Check View Parameter is directly added to the view interestof a direction that contains the firing position. The parameters aredefined for each (Ammo, HP) pair as a player with low HPmay sim-ply try to run away, while a player with high Ammo count may,instead, check for the attacker as he is ready for combat.

Flag View Interest – This interest is similar to its move interestcounterpart. It helps guides the bot to the flag which it is mostinterested in. The Flag View Parameters differ with the points andwho the flag belongs to. The Flag View Interest is 0 when it is inclose proximity to its interested flag. This prevents the bot fromlooking inwards when defending it. This interest is computed asfollows:

Flag View View Interest ¼ maxflag¼0! 3

ðpfv;belong;points � ðmaxDist

� distToFlagflagÞÞ ð5Þwhere pfv;belong;points is the flag view parameter for the current flagbelonging and points, maxDist is the greatest distance in the mapand distToFlagflag is the distance from the cell to the flag.

Target View Interest – This gives the interest of aiming at a tar-get. A low target view interest could mean that the bot likes toexplore its surrounding to look for more options instead of engag-ing the target directly. The Target View Parameter is specified foreach (Ammo, HP) pair and is added to the known cell’s view inter-est if it contains the target.




Forward View Interest – This mimics the tendency of players tolook forward while moving. Without it, the bot would be strafingtoo frequently (looking sideways or backwards while moving for-ward). However, if the player to imitate is capable of memorisingwhat he sees in one glance and therefore, can move without look-ing forward, the bot can be assigned low forward view interest.This is done by assigning the view interest of all known cells inthe direction of movement the Forward View Interest Parameter,which is specified for every (Ammo, HP) pair.

6.2. Learning mechanism

We now describes how learning the parameters defined previ-ously is done. They are set to make the bot behave as closely tothe player as possible. Part of the learning takes place during game-play (Section 6.2.1) and the rest are done by running an evolution-ary algorithm after (Section 6.2.2).

6.2.1. During gameplayWhen playing, states are captured periodically. This excludes

static factors and includes the following:

1. Agents (Player and AIs) – Position, Orientation, Current HP,Current Ammo, Known cells and expiry, Known targets, Desig-nated target

2. Flags – Points, Captured team

The 189 Target Move Interest Parameters are also obtained dur-ing gameplay. This is done with Backpropagation, which, while lessaccurate, is much faster than evolutionary algorithms. As the opti-mal solution for the parameters are too massive to search withinreasonable time with an evolutionary algorithm, we use a combi-nation of both.

When a shot is made, the HP, Ammo and distance to the targetis retrieved. The parameter for the corresponding (Ammo, HP, Dis-tance (to target)) is incremented and later normalised across each(Ammo, HP) pair. By the end, a separate distribution for each pair isretrieved, as shown in Fig. 9.

6.2.2. After gameplayWhen the game is over, the rest of the parameters are obtained.

Similar to PCG, this is done by evolution.A set of parameters is first randomly assigned and merged with

the 189 parameters above which always remains fixed. This consti-tutes a single candidate. The first captured state is then ‘loaded’. Abot with the candidate parameters replaces the player during thatstate and are left to run until the next state begins. At this instance,the difference in the position, orientation, HP and Ammo of the bot andthe player in the beginning of the next state is retrieved. The nextstate is then loaded. This is repeated until all states have loaded.

Fig. 9. Sample of a Target Move Distance Distribution for a (Ammo, HP) pair.


The fitness for the candidate is then computed by the fitnessfunction, which simply sums up the differences. Our goal is to min-imise the summed difference. If it is 0, the bot can mimic the beha-viour of the human player perfectly in the captured states.

Similar to our PCG evolution, new candidates are constructedand assigned a fitness in the same way. When a generation is com-plete, the best candidates (lowest fitnesses) are chosen. They aremerged to form new candidates with parameters randomlyselected from one of its parents. The resulting candidate is thenmutated by adding a value of �0.2 to 0.2 to each non-fixedparameter.

7. Implementation

We implement our solution with a multiplayer FPS game usingUnity Game Engine (Version 4.3) [30] in C#. Being one of the lead-ing game engine, it lets us test if the solution is feasible for a com-mercial game. It comprises a community of developers who shareready-made scripts and assets which eases the game’s develop-ment, allowing us to focus on our solution. Video demonstrationof our algorithm and playable version of our game are availableat our project homepage [31].

A demonstration of the stages in generation of a map and a sin-gle play session with the human imitating bots (each imitating aninvited player) can be seen in both our demonstration videos (sub-mitted as additional material). Fig. 10 shows a sample screenshotof a generated map.

The main challenge in developing the AI System is its optimisa-tion. Designing strategic points for the bot is difficult due to theprocedural nature of the map. Hence, the bot has to be able to learnthe environment and adapt to new ones just as a player would. As aresult, a grid-based system is used. However, this results in heavycomputation. Several techniques were used to fix this problem.

Firstly, we optimise cell computation within the FOV. Severaltechniques were proposed [32] and ray casting is used. We castonly 30 rays from the FOV, and visited cells are skipped. As a result,some cells were missed as the rays were not compact enough.However, it has minimal impact as neighbouring cells are likelyto have similar interest. In fact, such inaccuracy increaseslifelike-ness as human perception is not perfect.

Next, we managed to optimise finding paths from the bots to allof the flags. Since flag positions are fixed, a bot can know the pathto any flag in constant time by storing the distance from every cellto any flag by applying BFS (Breadth First Search) from all flagswhen the map is generated.

8. Evaluation

We have conducted both objective analytical evaluation andsubjective user study to evaluate our evolutionary algorithm onproducing good maps that complies with the design goals andbehaviour of bots. The evaluations are carried out with the testgame, TIṬAL that we have developed [31].

8.1. Analytical evaluation

We will be conducting two experiments – one of which is toevaluate the effectiveness of the evolutionary algorithm on pro-ducing good maps, the other is to ascertain the ability of our solu-tion to satisfy our design goals.

8.1.1. Effectiveness of evolutionTo evaluate the effectiveness of evolution, we created 3 different

maps using our solution. We run the evolution algorithm for 55populations (approximately 10 s in a Intel Core i7 laptop) each



Fig. 10. Map seen from above and in first person.


time to generate the map. The average summed fitness is collectedfrom each generated population by considering only the mapswhich are to be mutated for the next population.The maximumaverage summed fitness is 4.0, as the fitness for each of the 4 fea-tures is normalised from 0.0 to 1.0.

For each of the 3 different maps, the average summed fitness ofthe processed population against the number of populations pro-cessed so far is plotted in Fig. 11. The positive gradient shows thatthe evolutionary methods does improve the quality of the map asmore population are generated and mutated. It also shows that thefitness stabilises after 26 populations (which takes about 5 s).

The fitness for each feature (with unnormalised values) of gen-erated maps are shown in Table 2. Based on the fitness functionthat we have defined, the maps are all connected (with Connectivityof value 1.0), meaning that no regions are blocked from the rest.The algorithm is also effective in constraining the number of colli-sion points (with Forced Collision Points of value 1.0, indicating thatthere are either 1 or 2 collision points). For both Flag Fairness andOverall Flag Fairness, we show the unnormalised values. These val-ues indicates the absolute difference in moving from the spawnpoints to own team flags for Flag Fairness, and the difference inmoving to all flags for Overall Flag Fairness. A value of 1.0 meanstheir distance are exactly one cell apart. Given our result, the val-ues are very low, with the highest being 1.03510, which is barelyone cell apart. To give a clearer perspective, one cell will take only

Fig. 11. Change in fitness when evolving.

Table 2Fitness values of generated maps (after 26 populations).

Map 1 Map 2 Map 3

Connectivity 1.0 1.0 1.0Forced Collision Points 1.0 1.0 1.0Flag Fairness (unnormalised) 0.324556 1.03510 0.480553Overall Flag Fairness (unnormalised) 0.0031086 0.310274 0.556820


approximately a second to travel. Henceforth, we can conclude thatthe flags are placed in positions that are largely fair for both teams.

8.1.2. Fast generationThe maps generated using our algorithm took about 10 s for 55

generations. For example, the 3 different maps described above took10.1, 9.9 and 11.5 s for a fixed 55 generations. However, the overallfitness almost reaches its maximum after 26 generations andtherefore, running 55 generations is higly conservative on quality.We feel that this loading time is reasonable for a commercial game.

In contrast to algorithms in previous works [22,15,16] whichtakes hours, our algorithm is relatively successful in real-time gen-eration. Previous works typically take a highly random approach ininitialising the candidate, and relies too heavily on evolution. Ourkey difference lies in our relatively complicated initialisation usinggame context data, which takes additional steps to improve fitnesswhich skip many evolutionary passes.

We now generate another map for the rest of the analysis,shown in Fig. 12.

8.1.3. Collision pointsFrom observation, the collision points are defined well. When

the red team is trying to capture flags closer to the blue teamand vice versa, they are prone to meet in the map’s centre. The cov-ers surrounding it provides ample opportunities for tacticalchoices.

Fig. 12. Evaluated map blueprint.



Fig. 13. Indoor and outdoor areas with unique items.


Flow As the design is built around the notion of indoor and out-door areas, navigation is improved (Fig. 13). Furthermore, whilebuildings look similar at first, exploration brings up items like pos-ters and signs which helps with orientation. However, there is apossibility that another building has the same item, which can con-fuse players. This can be solved with greater variety of game tiles.Alternatively, a limit can be placed on certain variation.

Even with measures to prevent dead ends, they remain in somedifficult to detect areas. The buildings on the left and right are largebut do not have doors other than the ones that leads to the centre.Players may find themselves trying to find flags deeper into themonly to discover a dead end. This can be improved by tweakingthe maximum region size.

8.1.4. FairnessWe measure the time to navigate from both spawn points to all

four flags by playing through the map. It takes 58.88 s to movefrom the blue base and 60:21 s to move from the other. This smalldifference implies high fairness.

8.1.5. AestheticsThe look of the game is dependent on the artist, which we do

not have. However, what we can see from the map is that build-ings, trees and so on are placed naturally as shown in Fig. 14.

8.1.6. Behaviour of botsWe play the game for 5 times (each with a different map) and

let the learning mechanism take over. We waited 3 h each, whichtotalled to about 500 generations. For every session, we attempta different play style to masquerade as different players. Eachbot yielded replace one of the 5 default ones. Several more sessionswere done to observe them.

Fig. 14. Visual appearance of the game environment.


For the most part, the bots behave in a fairly lifelike manner.They take different paths and exhibits specialised behaviours suchas strafing to evade targets and moving to covers when low onhealth, while still able to capture flags. Extended play throughs,however, leads to some oddities. These include bots that are toogood at taking covers, and refuse to move out of them.

9. User study and analysis

9.1. Methodology, participants, and setup

A user study was conducted to test if the map generated fromour solution meets the design goals and whether the bots have suc-cessfully imitate the human players to the point that makes it hardfor a casual player to distinguish. The demographic of the respon-dents (Table 3) are collected to measure their familiarity with FPSand games in general.

9.1.1. User study methodologyThe game was ported to run in a browser environment. The URL

of the game with a starting page containing the introduction to thegame, game rules and mechanics were sent to all participants. Theusers were allowed to play the game multiple times before takingthe survey. A brand new map is generated with every playthrough.Users were informed that the game is a networked muti-player FPSgame (which is, in fact, an offline game fully occupied by bots). Tohide our intention (which could lower the integrity of the result),they were informed that they are playing against a mix of playersand bots. Also, they were not told that PCG is in place. The surveyquestions and analysis for map design and bots behaviours are dis-cussed below in separate subsections.

9.2. Result analysis

From the sample size of 53 and significance level of 0.05, the t-test critical value is approximately two. Depending on the ques-tion, we deem having a population mean of 3 and above or belowto be the passing score.

Table 3Respondents demographics.

Count 53Gender Female (5), Male (48)Proficiency Level

in GamesNever Played (1), Novice (10), Average (26), Expert (16)

Frequency ofPlaying Games

Never Played (2), Few Times a Month (14), Few Times aWeek (16), Almost Every Day (21)

Played any FPSgame before

Not sure about the game type (2), No (5), Yes (46)




9.2.1. Map designThe survey had 6 questions related to map design with Likert

scale of 1–5 for each question. The meanings for the Likert scaleare stated with the questions below as they are question depen-dent. Several questions about networking are also mixed into con-ceal the intention. The questions are listed below.

1. How fast is the loading process? [1 being unacceptably slowand 5 being very fast]

2. Did the combats took place all over the map or in few key loca-tions? [1 being only sparsely located and 5 being focused on afew areas]

3. Was it easy to navigate your way to your opponents and flags?[1 indicating very easy and 5 being very hard]

4. Did you run into many dead ends? [1 indicating none and 5indicating many]

5. Please rate the pacing of the game. [1 being too fast/slow pacedand 5 being very well-paced]

6. Did the placement of the flags give fair chances for both teams?[1 being very unfair and 5 being very fair]

The results for the above survey questions fall within acceptablerange as their t-value falls in the critical region at significance levelof 0.05, except for question 1 and 5. Given below are the detailedanalysis of individual questions and their significance.

Fast Generation (How fast is the loading process?) – As the t-value computed is 1.28, we are unable to reject the hypothesisthat the population mean is less than 3. However, the samplemean is 3.19 with a standard deviation of 1.08. This implies thatthe users are generally acceptable of the time taken to generatea map.Collision Points (Did the combats took place all around the mapor in few key locations?) – The t-value obtained is 3.52. We cantherefore reject the hypothesis that the population mean is lessthan 3. Moreover, the sample mean is 3.60 with standard devi-ation of 1.25. It is hence accurate to say that the design of col-lision points are effective in our solution as we havesuccessfully limit the points of confrontation.Flow (Was it easy to navigate your way to your opponents andflags?) – The sample mean is 2.43 with standard deviation of1.15. With a t-value of �3.58, we can reject the hypothesis thatthe population mean is more than 3 (difficult to navigate). Inaddition, related to navigability of the map, we had anotherquestion – ‘‘Did you run into many dead ends?”. The samplemean is 2.42 and has standard deviation of 1.12. We can againreject the hypothesis that the population mean is more than 3(more than a few dead ends) with a t-value of �3.81. With thesetwo questions, we can conclude that our maps generated hasfairly good navigability.Pacing (Please rate the pacing of the game.) – The pacing doesnot seem as well-paced as it should be. Elicit responses thatyielded a sample mean of 3.04, standard deviation of 1.12 andt-value of 0.03. We are therefore unable to reject the hypothesisthat the populationmean is less than 3 with significance level of0.05. While this is a cause of concern, we feel that the pacing ofthe game cannot be easily measured by the users by a singleplaythrough. Also, pacing is susceptible to many confoundingfactors, such as the speed of movement, rate of fire, speed ofreloading and so on, and is therefore not exclusively dependenton the map design.Fairness (Did the placement of the flags give fair chances for bothteams?) – This is the last question with regards to our PCG solu-tion. It produces a sample mean of 3.36, standard deviation of0.98 and t-value of 2.66. The hypothesis that the population


mean is less than 3 can be rejected. This implies that the place-ment of flags are largely fair for our users.Aesthetics – Unlike other design goals, we are unable to gaugethe overall aesthetics of our solution with the user study due toits highly subjective nature, and the fact it is highly dependenton the game artist. However, what we can see from the gener-ated map is that buildings have decent shapes and that objectssuch as trees and wagons are placed in a natural manner asshown in Fig. 14.

It should be noted that both question 1 and 5 are related andthe speed of the user’s machine and the browser have high influ-ence on the answers. Users who positively rated the loading speed,have also given good score for pacing. From the results, we can tellthat the map design has mostly fulfilled our design goals of havingcollision points, flow (in terms of navigability) and fairness.

9.2.2. Human imitating botThe analyse the behaviour of the bots we asked three questions,

which are listed below. Similarly each question had a Likert scale of1–5 and their meanings are stated with the questions as they arequestion dependent.

1. Were there moments where the behaviour of the AIs are erra-tic? [a score of 1 indicates that such moments are very rareand 5 means that erratic behaviours are very common]

2. Of those AI Bots, how lifelike do they appear to be? [1 beingvery unrealistic and 5 being very lifelike]

3. How many AI Bots were in the game you just played? [anynumber below 5 indicates that the player must have felt playingwith at least another one human player, which is actually a botmincing a human player]

With the exception of question 2, the results fall within accept-able range as their t-value falls in the critical region at significancelevel of 0.05.

This means that users do not fully feel that the bots behave likeactual human players. Interestingly, this contradicts the results ofthe third question. As mentioned, the game does not actually fea-ture any other players. Therefore, by answering any number below5 (3 AIs in the opposing team and 2 allies), the player must havefelt that they are playing with another human player. The resultsalso show us that the bot does not commonly exhibit unnaturalbehaviour.

Bot Intelligence (Were there moments in the game where thebehaviour of players/AIs are erratic?) – The question is used toascertain if there are any unnatural behaviours from the AI botsthat we have designed. It seems that respondents feel that erra-tic behaviour occur very occasionally, implying that theybehave rather sensibly. The sample has a mean of 2.11, standarddeviation of 1.14 and a t-value of �5.67. Hence, we can rejectthe hypothesis that the population mean is greater than 3.Human like behaviour (‘‘Of those AI Bots, how lifelike were theyappear to be?). It yielded a sample mean of 2.57 and standarddeviation of 1.18. A t-value of �2.67 also means that we failto reject the hypothesis that the population mean is less than3. This means that users feel that the bots do not behave likeactual human players. Interestingly, this contradicts the resultsof our third question ‘‘How many AI Bots were in the game youjust played?”. As stated in our methodology, the game doesnot actually feature any human players other than the playerhimself. Therefore, by answering any number below 5 (3 AIsin the opposing team and 2 allies), the player must have feltthat they are playing with another human player. Our results




give a mean of 3.08 and standard deviation of 1.38. The t valueis �10.12. We can therefore reject the hypothesis that the pop-ulation mean is greater than 5. What this could mean is thatplayers feel that the some of our bots have imitated otherhuman players to some extent.

Overall, the results of bots behaviours show that human imitat-ing bots are a viable solution for bringing in asynchronous game-play element into the multiplayer FPS genre.

10. Discussion and future work

10.1. Single floor

While the solution does a decent job of creating a goodgame environment for 3D multiplayer shooters, it is only ableto do so for a single floor with even ground level. Each gametile can have some slight variation in ground level, but havingmulti-storey buildings is not considered in the current version.Such elements enable a deeper layer of strategy, including theability to ‘camp’ on the roof of a building and taking out unsus-pecting players on the ground. Future work can include ways to‘stack’ game tiles, while still ensuring that the design goals aremet.

10.2. User study on human imitating bot

Our design for our human imitating bot aims to imitate thebehaviour of any human players, but is not simply trying to acthuman. What our user study has shown is that the human imitat-ing bot can deceive players from thinking that they are players, butmay not be adequate in showing that they behave like a certainplayer. What an adequate study entails are users who have playedalongside another human player for some time, and have experi-enced the traits exhibited by that player. This, however, is not prac-tical as it involves excessive commitment and time fromrespondents.

11. Conclusion

We first presented our findings of what constitutes a goodgame environment for multiplayer shooters, before designingan algorithm for the procedural generation of a map that cansatisfy all the criteria. Similarly, the design for our human imi-tating bot is described. We then explained our implementationand its challenges and discussed the results. Our objective andsubjective evaluations prove that with careful initialisation ofevolution algorithms with game context data, one can generate3D game maps procedurally for multiplayer shooters in less thanten seconds without compromising the common design require-ments (flow, positioning of collision points, fairness and aesthet-ics) of commercial multiplayer shooters. In contrast to previousworks, our novel game context aware map generation methodis practically feasible for run-time dynamic map generationand can be immediately used by game industry. Our large scaleuser studies show that the players were not able to distinguishbetween bots and human players. This ensures the feasibilityof asynchronous gameplay element in multiplayer shooters usinghuman imitating AI for the first time with a successfuldemonstration.

With the widespread of gaming on the move, as evidenced bythe massive number of users in various mobile shooters, and theleap in phone processing power, our game context aware humanimitating AI can make a substantial contribution in incorporatingasynchronous gameplay in mobile multiplayer shooters.


There is a huge hurdle involved in making multiplayer shootersfor mobile – they require a stable internet connection and massiveconsumption of data, which may not be available on the move.With our AI system, this popular genre can be brought to a newgeneration of gamers. Many mobile shooters in the market can cer-tainly adopt our technology to improve their game beyond theirsingle player campaigns – all without having to invest in expensiveservers to handle the game.

Coupled with our novel solution to procedural generation ofmultiplayer maps, the file-size of the game (which is essential inmobile development) can be kept to a minimum. There is no needto create many different maps for players to play in.

Acknowledgements

This work is supported in part by the Ministry of EducationACADEMIC RESEARCH FUND TIER 1 under the research grantT1251RES1506. Any opinions, findings, conclusions or recommen-dations expressed in this material are those of the authors and donot necessarily reflect the views of the granting agency or NationalUniversity of Singapore.

References

[1] Guerrilla, Killzone Home. <http://www.killzone.com/en_GB/killzone.html>(January retrieved 2014).

[2] J. Togelius, G.N. Yannakakis, K.O. Stanley, C. Browne, Search-based proceduralcontent generation, in: Proceedings of the 2010 International Conference onApplications of Evolutionary Computation – Volume Part I, EvoApplicatons’10,Springer-Verlag, Berlin, Heidelberg, 2010, pp. 141–150.

[3] B. Watson, P. Muller, P. Wonka, C. Sexton, O. Veryovka, A. Fuller, Proceduralurban modeling in practice, IEEE Comput. Graphics Appl. 28 (3) (2008) 18–26,http://dx.doi.org/10.1109/MCG.2008.58.

[4] B. Loguidice, M. Barton, Vintage Games: An Insider Look at the History of GrandTheft Auto, Super Mario, and the Most Influential Games of All Time, first ed.,Focal Press, 2009.

[5] Rogue 1984 – The Dos Game, the History, the Science. <http://science-fiction.fch.ir/rogue/doc/Rogue_1984-The_DOS_Game-The_History-The_Science.html>(March retrieved 2014).

[6] PolyphonyDigital, Gran turismo 5 Course Maker. <http://www.gran-turismo.com/us/products/gt5/coursemaker/> (January retrieved 2014).

[7] Gearbox, Borderlands 2 Information. <http://www.borderlands2.com/us/#info> (January retrieved 2014).

[8] DICE, Battlefield 4 Multiplayer. <http://www.battlefield.com/battlefield-4/gameplay/multiplayer> (January retrieved 2014).

[9] VGChartz, Global Yearly Chart 2013. <http://www.vgchartz.com/yearly/2013/Global/> (January retrieved 2014).

[10] Draw Something. <http://omgpop.com/drawsomething> (March retrieved2014).

[11] C. Güttler, T.D. Johansson, Spatial principles of level-design in multi-playerfirst-person shooters, in: Proceedings of the 2Nd Workshop on Network andSystem Support for Games, NetGames ’03, ACM, New York, NY, USA, 2003, pp.158–170, http://dx.doi.org/10.1145/963900.963915.

[12] D. Scimeca, How to Build the Best Multiplayer FPS Maps. <http://www.g4tv.com/thefeed/blog/post/719216/how-to-build-the-best-multiplayer-fps-maps-part-one> (January retrieved 2014).

[13] J. Holloway, Deathmatch Map Design: The Architecture of Flow. <http://www.gamasutra.com/view/feature/195069/deathmatch_map_design_the_.php>(January retrieved 2014).

[14] S. Hill, Game Design Theory: Multiplayer Level Design. <http://www.alteredgamer.com/game-development/60255-game-design-theory-multiplayer-level-design/> (January retrieved 2014).

[15] J. Togelius, R. De Nardi, S. Lucas, Towards automatic personalised contentcreation for racing games, in: IEEE Symposium on Computational Intelligenceand Games, 2007, CIG 2007, 2007, pp. 252–259. http://dx.doi.org/10.1109/CIG.2007.368106.

[16] J. Togelius, M. Preuss, N. Beume, S. Wessing, J. Hagelback, G. Yannakakis,Multiobjective exploration of the starcraft map space, in: 2010 IEEESymposium on Computational Intelligence and Games (CIG), 2010, pp. 265–272. http://dx.doi.org/10.1109/ITW.2010.5593346.

[17] M. Kerssemakers, J. Tuxen, J. Togelius, G. Yannakakis, A procedural procedurallevel generator generator, in: 2012 IEEE Conference on ComputationalIntelligence and Games (CIG), 2012, pp. 335–341. http://dx.doi.org/10.1109/CIG.2012.6374174.

[18] Y.-T. Yeh, L. Yang, M. Watson, N.D. Goodman, P. Hanrahan, Synthesizing openworlds with constraints using locally annealed reversible jump mcmc, ACMTrans. Graph. 31 (4) (2012) 56:1–56:11, http://dx.doi.org/10.1145/2185520.2185552.


http://www.killzone.com/en_GB/killzone.html

http://refhub.elsevier.com/S1875-9521(16)30002-7/h0010





http://dx.doi.org/10.1109/MCG.2008.58





http://science-fiction.fch.ir/rogue/doc/Rogue_1984-The_DOS_Game-The_History-The_Science.html

http://science-fiction.fch.ir/rogue/doc/Rogue_1984-The_DOS_Game-The_History-The_Science.html

http://www.gran-turismo.com/us/products/gt5/coursemaker/

http://www.gran-turismo.com/us/products/gt5/coursemaker/

http://www.borderlands2.com/us/#info

http://www.borderlands2.com/us/#info

http://www.battlefield.com/battlefield-4/gameplay/multiplayer

http://www.battlefield.com/battlefield-4/gameplay/multiplayer

http://www.vgchartz.com/yearly/2013/Global/

http://www.vgchartz.com/yearly/2013/Global/

http://omgpop.com/drawsomething

http://dx.doi.org/10.1145/963900.963915

http://www.g4tv.com/thefeed/blog/post/719216/how-to-build-the-best-multiplayer-fps-maps-part-one



http://www.gamasutra.com/view/feature/195069/deathmatch_map_design_the_.php

http://www.gamasutra.com/view/feature/195069/deathmatch_map_design_the_.php

http://www.alteredgamer.com/game-development/60255-game-design-theory-multiplayer-level-design/



http://dx.doi.org/10.1109/CIG.2007.368106


http://dx.doi.org/10.1109/ITW.2010.5593346



http://dx.doi.org/10.1145/2185520.2185552

http://dx.doi.org/10.1145/2185520.2185552



[19] M.F. Cohen, J. Shade, S. Hiller, O. Deussen, Wang tiles for image and texturegeneration (2003).

[20] P. Merrell, E. Schkufza, Z. Li, M. Agrawala, V. Koltun, Interactive furniturelayout using interior design guidelines, in: ACM SIGGRAPH 2011 Papers,SIGGRAPH ’11, ACM, New York, NY, USA, 2011, pp. 87:1–87:10, http://dx.doi.org/10.1145/2185520.2185552.

[21] H. Liu, Y.-L. Yang, S. AlHalawani, N.J. Mitra, Constraint-aware interior layoutexploration for precast concrete-based buildings, Visual Computer (CGI SpecialIssue).

[22] L. Cardamone, G.N. Yannakakis, J. Togelius, P.L. Lanzi, Evolving interestingmaps for a first person shooter, in: Proceedings of the 2011 InternationalConference on Applications of Evolutionary Computation – Volume Part I,EvoApplications’11, Springer-Verlag, Berlin, Heidelberg, 2011, pp. 63–72.

[23] J. Ortega, N. Shaker, J. Togelius, G.N. Yannakakis, Imitating human playingstyles in super mario bros, Entertain. Comput. 4 (2) (2013) 93–104, http://dx.doi.org/10.1016/j.entcom.2012.10.001. <http://www.sciencedirect.com/science/article/pii/S1875952112000183>.

[24] C. Thurau, C. Bauckhage, G. Sagerer, Learning human-like movement behaviorfor computer games, in: Proc. 8th Int. Conf. on the Simulation of AdaptiveBehavior (SAB’04), 2004.


[25] T. Verweij, A hierarchically-layered multiplayer bot system for a first-personshooter, 2007, 59. <http://www.guerrilla-games.com/presentations/VUA07_Verweij_Hierarchically-Layered-MP-Bot_System.pdf>.

[26] J.P.V. Waveren, The quakeiii arena bot, in: <http://www.kbs.twi.tudelft.nl/docs/MSc/2001/Waveren_Jean-Paul_van/thesis.pdf>, University of TechnologyDelft, Faculty of ITS, 2001.

[27] J. Schrum, I.V. Karpov, R. Miikkulainen, Ut2: Human-Like Behavior ViaNeuroevolution of Combat Behavior and Replay of Human Traces.

[28] J. Schrum, I.V. Karpov, R. Miikkulainen, Humanlike combat behavior viamultiobjective neuroevolution, in: Believable Bots, Springer, 2011.

[29] R. Hunicke, M. LeBlanc, R. Zubek, MDA: a formal approach to game design andgame research, in: Proceedings of the AAAI-04 Workshop on Challenges inGame AI, 2004, pp. 1–5.

[30] Unity3D, Unity3d Game Engine. <http://unity3d.com/> (January retrieved2014).

[31] Bhojan Anand, Wong Hong Wei, ARENA-Procedural Map and MusicGeneration for Multiplayer Shooters (PROJECT PAGE). <http://www.comp.nus.edu.sg/~bhojan/arena>.

[32] Field of vision. <http://www.roguebasin.com/index.php?title=FOV> (Marchretrieved 2014).


http://dx.doi.org/10.1145/2185520.2185552

http://dx.doi.org/10.1145/2185520.2185552








http://www.sciencedirect.com/science/article/pii/S1875952112000183

http://www.sciencedirect.com/science/article/pii/S1875952112000183

http://www.guerrilla-games.com/presentations/VUA07_Verweij_Hierarchically-Layered-MP-Bot_System.pdf

http://www.guerrilla-games.com/presentations/VUA07_Verweij_Hierarchically-Layered-MP-Bot_System.pdf

http://www.kbs.twi.tudelft.nl/docs/MSc/2001/Waveren_Jean-Paul_van/thesis.pdf

http://www.kbs.twi.tudelft.nl/docs/MSc/2001/Waveren_Jean-Paul_van/thesis.pdf




http://unity3d.com/

http://www.comp.nus.edu.sg/<ucode type=

http://www.comp.nus.edu.sg/<ucode type=

http://www.roguebasin.com/index.php?title=FOV


Software

TIṬAL – Asynchronous multiplayer shooter with procedurally generated maps