A PPLICERING AV EN 2D DUNGEON ALGORITM I EN 3D RYMD
Hur bra presterar TinyKeeps dungeon algoritm i tre dimensioner?
A PPLICATION OF A 2D DUNGEON ALGORITHM IN 3D SPACE
How well does TinyKeep’s dungeon algorithm perform in three dimensions?
Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng
Vårtermin 2021 Emil Birgersson
Handledare: Andreas Jonasson Examinator: Sanny Syberfeldt
Sammanfattning
Procedural content generation inom spel refererar till algoritmiskt, procedurellt skapande av digitalt innehåll i syfte att automatisera och minska mängden arbete för designers och grafiker. Ett område procedural content generation används för inom spel är dungeon generering. Målet för detta arbete var att utforska en 2D algoritm som används i spelet TinyKeep för just generering av dungeons och se hur den algoritmen kunde prestera om den modifierades för generering i en 3D rymd. Den modifierade algoritmen utvärderades baserat på attributen variation, justerbarhet, pålitlighet samt tidseffektivitet. Resultatet visade visade att det är möjligt att använda algoritmen i spelet TinyKeep i en 3D-rymd med godtagbart prestationsresultat. Som värst visade den modifierade algoritmen på en viss svaghet angående genereringstid vid en större tom rymd med större antal rum hos en dungeon. För framtida arbete vore det intressant att dela upp av delar av den modifierade algoritmen på separata trådar.
Nyckelord: procedural content generation, delaunay triangulation, dungeon generation
Innehållsförteckning
1 Introduktion 1
2 Bakgrund 2
2.1 Procedural content generation 2
2.1.1 Online vs offline 3
2.1.2 Constructive vs generate-and-test 3
2.1.3 Necessary vs optional 3
2.1.4 Seed vs parameter 4
2.1.5 Stochastic vs deterministic 4
2.2 Dungeons 4
2.3 Minimum spanning tree 5
2.4 Delaunay triangulation 7
2.5 Delaunay triangulation och TinyKeep 13
2.6 A* Pathfinding 17
2.7 Egenskaper och evaluering 22
3 Problemformulering 25
3.1 Syfte 25
3.2 Metodbeskrivning 26
3.2.1 Experiment 26
3.2.2 Utvärderingsmetoder 27
4 Implementation 29
4.1 Experimentmiljö 29
4.2 3D TinyKeep dungeon 30
4.2.1 Skapande och placerande av rum 30
4.2.2 Överlappning 34
4.2.3 Utväljande av rum 35
4.2.4 Delaunay triangulation 36
4.2.5 Prims MST 39
4.2.6 Återintroducering av cykler 40
4.2.7 Infogande av icke utvalda rum 41
4.2.8 Val av start och mål rum 46
4.2.9 Byggande av korridorer 47
4.3 Implementation av utvärderingar 51
4.3.1 Korridorkomplexitet 51
4.3.2 Använda rum 51
4.3.3 Längd från start till mål 52
4.3.4 Storlek och densitet 52
4.3.5 Höjd-variation 52
4.3.6 Tidseffektivitet 52
4.4 Pilotstudie 53
5 Utvärdering 57
5.1 Presentation av undersökning 57
5.2 Resultat 58
5.2.1 Korridorkomplexitet 58
5.2.2 Andel använda rum 63
5.2.3 Längd från start till mål 67
5.2.4 Storlek 71
5.2.5 Densitet 75
5.2.6 Höjd-variation 79
5.2.7 Tidseffektivitet 83
5.3 Analys 87
5.3.1 Korridorkomplexitet 87
5.3.2 Andel använda rum 88
5.3.3 Längd från start till mål 90
5.3.4 Storlek 91
5.3.5 Densitet 93
5.3.6 Höjd-variation 94
5.3.7 Tidseffektivitet 96
5.4 Slutsatser 97
6 Avslutande diskussion 100
6.1 Sammanfattning 100
6.2 Diskussion 101
6.2.1 Trovärdighet 101
6.2.2 Samhälleliga och etiska aspekter 102
6.3 Framtida arbete 103
Referenser 104
1
1 Introduktion
Procedural Content Generation (PCG) syftar på procedurell generering av olika typer av digitalt innehåll på algoritmisk väg. Ett specifikt användningsområde för procedurell generering är inom spelutveckling, där procedurell generering används till att generera en mångfald av digitalt innehåll. Exempel på sådant innehåll är texturer, landskap, byggnader och banor (Yannakakis, 2012; Dahlskog, Björk & Togelius, 2015).
Ett mer brett område inom procedurell generering för spelutveckling är dungeon generering.
Det finns ett antal algoritmer och metoder inom procedurell generering vilka har möjligheten att generera många olika varianter av dungeons (Van der Linden, Lopes & Bidarra, 2014;
Kozlova, Alexander Brown & Reading, 2015). I spelet TinyKeep (PhiGames, 2014) är Delaunay Triangulation basen för en algoritm som utvecklaren av TinyKeep (Phi Dinh, 2013) utvecklat.
Algoritmen i TinyKeep är en algoritm som strukturellt sett genererar en dungeon utmed två koordinataxlar. Detta arbete utforskade möjligheten samt eventuella effekter av att lägga till en tredje koordinataxel till TinyKeeps algoritm. En artefakt i form av en dungeon generator som använde en modifierad version av TinyKeeps algoritm skapades därför för att kunna utföra generering utmed tre koordinataxlar.
Utvärdering av artefakten har skett utifrån evaluering av ett mindre antal attribut som ansågs relevanta för att på ett numeriskt- eller rankmässigt sätt ge så objektiva data som möjligt.
Evaluering av dessa attribut har skett utifrån följande PCG egenskaper: tidseffektivitet, pålitlighet, variation och justerbarhet.
2
2 Bakgrund
Detta kapitel börjar med att översiktligt förklara området procedural content generation (PCG) inom datorspel. Efter detta beskrivs konceptet av en dungeon i relation till PCG och den generella användningen av konceptet i datorspel. Slutligen beskrivs metoden Delaunay Triangulation, hur metoden fungerar och hur den kan användas i relation till PCG och dungeons.
2.1 Procedural content generation
Termen procedural content generation (PCG) refererar översiktligt till ett område som digitalt sett har att göra med algoritmiskt, procedurellt skapande av olika typer av digitalt innehåll beroende på användningsområde (Van der Linden, Lopes & Bidarra, 2014). Inom dataspelsutveckling kan PCG användas till procedurell generering av bland annat landskap, texturer, modeller, banor, byggnader och uppdrag. (Yannakakis och Togelius, 2015).
PCG används främst för att automatisera, generalisera och snabba upp samt möjliggöra enkel, snabb och exakt justering av det digitala innehåll som algoritmiskt genereras. Detta är en viktig del av vad som gör PCG attraktivt för användning inom dataspelsutveckling, eftersom det medför att artister inom olika inriktningar som t.ex. 2D- och 3D-grafik samt design kan få mer arbete gjort inom ett mindre tidsspann med mindre möda (Van der Linden, Lopes &
Bidarra, 2014).
Förutom texturer, landskap och byggnader kan PCG användas för att skapa hela världar inom spel. Ett exempel på detta är hur en värld genereras i spelet Minecraft (Mojang, 2011). I Minecraft genereras landskap, biomer, träd, hus, mindre bosättningar bland annat via användning av PCG, se Figur 1. Ett ytterligare användningsområde för PCG i spel är det algoritmiska skapandet av banor i form av vad som kallas en dungeon (Togelius, Yannakakis, Stanley & Browne, 2011; Van der Linden, Lopes & Bidarra, 2014; Kozlova, Alexander Brown
& Reading, 2015; Gellel & Sweetser, 2020).
Figur 1: En skärmdump tagen i spelet Minecraft (Mojang, 2011), version 1.16.5
3 2.1.1 Online vs offline
Termen online refererar till procedurell generering av digitalt innehåll i realtid. Procedurella generatorer som arbetar online är designade för att kunna arbeta och utföra generering av digitalt innehåll under tiden som ett program körs, vilket ställer kravet på att generatorn och algoritmen som den använder måste vara snabb och kunna generera digitalt innehåll utan att introducera någon typ av fel med innehållet som den producerar (Gellel & Sweetser, 2020).
För procedurell generering som körs online är kraven alltså höga och strikta eftersom det är otroligt betydande att generatorn och algoritmen som körs inte introducerar fel som stör exekveringen av ett program (ibid.).
Termen offline refererar då till procedurell generering av digitalt innehåll utanför exekveringstid av ett program. Procedurella generatorer som arbetar offline är då designade för att arbeta och utföra generering av digitalt innehåll innan exekveringen av ett program börjat. En offline generator har då inte lika höga krav för procedurell generering ställt på sig som en online generator har (Gellel & Sweetser, 2020). Detta medför att fokus på både effektivitet och avsaknad av fel i genereringen ofta kan överses eftersom offline generering generellt sett kan användas för att generera basinnehåll som en designer eller grafiker sen kan arbeta vidare på och justera (ibid.).
2.1.2 Constructive vs generate-and-test
Termen constructive refererar till procedurell generering där genereringen av digitalt innehåll sker från start till stopp i en enda kontinuerlig sekvens. Med constructive procedurell generering sker då ingen automatisk testning som upprepar delar av algoritm-sekvensen som sköter genereringen, vilket medför att en constructive algoritm behöver kunna garantera att det digitala innehåll som genereras håller en viss funktionell standard under genereringsprocessen (Togelius, Yannakakis, Stanley & Browne, 2011).
En generate-and-test metod, refererar då till procedurell generering av digitalt innehåll där algoritmen som genererar innehållet utför automatisk testning av det innehåll som genererats av algoritmen. Detta test utförs antingen efter att hela eller delar av genereringsprocessen är klar. Om testningen skulle upptäcka ett fel med innehållet som genererats slängs den felaktiga delen bort och genereras åter av algoritmen tills felet inte kvarstår eller kan anses som tillräckligt godtagbart för ändamålet (Togelius, Yannakakis, Stanley & Browne, 2011).
2.1.3 Necessary vs optional
Innehåll som kan klassas som necessary syftar på innehåll som måste finnas med för att fylla funktioner av olika slag, exempelvis att en spelare behöver ta sig igenom en dungeon för att ta sig vidare i ett spel eller att det finns monster som en spelare måste besegra för något ändamål (Togelius, Yannakakis, Stanley & Browne, 2011). Vad som utmärker innehåll som kan klassas som necessary är att sådant innehåll måste vara felfritt, det får inte finnas en dungeon som en spelare inte kan ta sig igenom eller ett monster som en spelare inte kan besegra (ibid.).
Innehåll som klassas som necessary får alltså inte ha möjligheten att förhindra att en spelare tar sig vidare genom ett spel (ibid.).
Innehåll som klassas som optional syftar däremot på innehåll som kan finnas med för att erbjuda variation och val. Exempel på innehåll som kan klassas som optional är vapen i spelet Borderlands 2 (Gearbox Software, 2012), vilka kan plockas upp och bytas ut när som helst under en spelsession utan att det påverkar spelarens möjlighet att fortsätta spela igenom spelet (Togelius, Yannakakis, Stanley & Browne, 2011). Innehåll som kan klassas som optional
4
behöver då inte vara felfritt till skillnad från innehåll som klassas som necessary, det enda kravet i fallet för innehåll som klassas som optional är att det måste finnas annat innehåll som möjliggör vidare progression i ett spel (ibid.). Necessary och optional är dock termer som är mer subjektiva i sin natur och avgörandet av vad för innehåll som kan klassas som necessary och optional är beroende på i vilken kontext innehållet används (ibid.).
2.1.4 Seed vs parameter
Seed och parameter är termer som är mer betydande för algoritmen som genererar digitalt innehåll än för innehållet. Seed och parameter syftar i detta fall på hur enkelt och exakt en algoritm kan justeras och kontrolleras, vilket gör att seed och parameter kan ses som två sidor av samma extrem (Togelius, Yannakakis, Stanley & Browne, 2011). Å ena sidan kan en algoritm ta in och arbeta baserat på bara ett seed-värde vilket exempelvis kan vara en sekvens av olika nummer och bokstäver (ibid.). Användningen av ett seed-värde för generering gör det snabbt och simpelt att komma igång med generering av digitalt innehåll, men det innebär även att genereringen är ytterst slumpmässig och utan kontroll (ibid.).
Å andra sidan kan en algoritm ta in och arbeta baserat på en eller flera parametrar vilket exempelvis kan vara en multidimensionell vektor av nummer som specificerar storlek eller antal av rum i en dungeon (Togelius, Yannakakis, Stanley & Browne, 2011). Användningen av en eller flera parametrar för generering gör det mer komplicerat att komma igång med generering av digitalt innehåll, men det innebär även att genereringen är enklare att justera till en mer specifik vision (ibid.).
2.1.5 Stochastic vs deterministic
Stochastic och deterministic är termer som, förenklat, har att göra med graden av slumpmässighet hos procedural content generation. Mer exakt syftar dessa termer ungefär på graden av datakomprimering och likhet hos innehållet som genereras av en algoritm givet en specifik sekvens eller kombination av värden för parametrar (Gellel & Sweetser, 2020;
Togelius, Yannakakis, Stanley & Browne, 2011).
En algoritm som ses som deterministic syftar då på en algoritm som genererar exakt samma innehåll varje gång som genereringen körs givet att algoritmen arbetar baserat på exakt samma sekvens eller kombination av värden för parametrar varje gång (Gellel & Sweetser, 2020; Togelius, Yannakakis, Stanley & Browne, 2011). En algoritm som ses som deterministic kan då användas för en form av datakomprimering eftersom innehåll som genereras av en sådan algoritm inte nödvändigtvis behöver sparas, utan kan genereras varje gång som innehållet behövs för att spara minne (ibid.).
En algoritm som ses som stochastic skulle då syfta på en algoritm som genererar innehåll som varierar mer eller mindre, oberoende av om algoritmen har fått exakt samma sekvens eller kombination av värden för parametrar varje gång som algoritmen körs eller inte (Gellel &
Sweetser, 2020).
2.2 Dungeons
En dungeon i detta fall refererar till en algoritmiskt, procedurellt skapad struktur som geometriskt sett generellt är bestående av ett mindre antal specifika attribut. Ett av dessa attribut syftar på skapandet av ett flertal rum som kan variera mer eller mindre i storlek och som placeras enligt något algoritmiskt mönster. (Van der Linden, Lopes & Bidarra, 2014).
5
Två andra av dessa attribut är lika i vad de syftar på. För det ena attributet innebär det skapandet av ett rum som en spelare startar utforskandet av en dungeon från. För det andra av dessa två snarlika attribut innebär det skapandet av ett rum som en spelare har som mål att försöka ta sig till (Van der Linden, Lopes & Bidarra, 2014).
Det sista attributet syftar på skapandet av ett varierande antal korridorer som kopplar alla skapade rum till varandra för att göra det möjligt att traversera och utforska en dungeon från start till mål (Van der Linden, Lopes & Bidarra, 2014). Med denna geometriskt generella strukturering finns det vissa kriterier som behöver uppfyllas för att en dungeon ska kunna anses som användbar (Kozlova, Alexander Brown & Reading, 2015). Några av dessa mer generella kriterier är som följer:
● En dungeon måste ha en ingång och en utgång
● Utgången i en dungeon måste kunna nås från ingången
● Alla rum som placerats ut måste kunna nås
● En spelare ska inte kunna nå utgången utan att behöva gå igenom en större del rum och korridorer först
Dessa mer generella kriterier för procedurell generering av en dungeon ser till att strukturen skapas med en garanti för algoritmiskt slumpmässig utforskning och progression. Dessa kriterier ser även till att en dungeon som genereras är genomförbar, vilket är ett kriterium som denna typ av algoritm behöver kunna uppfylla. Vidare finns även kriterier som är mer eller mindre betydande beroende på vilken typ av dungeon som ska genereras. Ett exempel på ett sådant mer typ-specifikt kriterium är att strukturen det inte får innehålla några cykler, där en cykel då syftar på en väg som leder tillbaka till en viss utgångspunkt utan att passera ett rum eller en korridor som redan passerats (Kozlova, Alexander Brown & Reading, 2015).
2.3 Minimum spanning tree
Ett minimum spanning tree (MST) är en datastruktur som används till lösning av kombinatoriska optimeringsproblem (Ayegba, Ayoola, Asani & Okeyinka, 2020). Ett exempel på ett användningsområde som behandlar dessa typer av problem är uppsättning av datornätverk som vanligtvis representeras med grafer, där en nod i en graf kan representera en dator medan en kant kan representera en kabel som kopplar en dator till ett nätverk. Se Figur 2 för exempel på en fullt kopplad graf. Ett spanning tree är en datastruktur som definieras som en sub-graf till en ursprunglig graf och används vanligtvis till att hitta en väg i en graf där alla noder är sammankopplade till varandra med kanter utan att bilda några cykler.
Ett MST är en variant av ett spanning tree som används i det fallet då en graf är viktad för att få ut ett spanning tree bestående av de kanter mellan alla noder i en graf som ger den minsta möjliga sammanlagda vikten utan att introducera cykler (ibid.), se Figur 3.
6
Figur 2: Ett exempel på visualisering av en graf. Röda cirklar representerar hörn, även kallade noder. Svarta linjer representerar kanter, även kallade kopplingar eller vägar
Figur 3: Ett exempel på visualisering av ett Minimum spanning tree, en variant av en sub- graf till en fullt kopplad graf. För exemplet är vikten för en kant definierad som längden
mellan de två noder som kanten är kopplad mellan.
7
Det finns flera olika varianter av algoritmer för att få fram ett MST från en graf. Två exempel på mer kända algoritmer är Prims och Kruskals algoritmer. Prims algoritm är definierad som en nod-baserad algoritm medan Kruskals algoritm är definierad som en linje-baserad algoritm (Ayegba, Ayoola, Asani & Okeyinka, 2020).
Kruskals algoritm utgår från skapandet av en mängd av kanter ordnade efter kanternas vikt och fortsätter med att gå igenom denna ordnade mängd för att lägga till en kant till ett MST en efter en, förutsatt att den kant som läggs till inte bildar en cykel i MST grafen. För varje iteration av Kruskals algoritm söks den ordnade mängden igenom efter kanten med den minsta vikten för att inkludera kanten i MST grafen (Ayegba, Ayoola, Asani & Okeyinka, 2020).
Prims algoritm utgår från en slumpmässigt vald nod i en graf och definierar denna nod som roten i ett träd. Prims fortsätter med att hitta kanten mellan alla noder direkt kopplade till roten med minst vikt, lägger till den kanten i ett MST och lägger noden som kanten leder till i trädet som innehåller roten. För varje iteration av Prims algoritm kollas sedan kanterna hos varje nod i trädet efter kanten med minst vikt som inte introducerar en cykel, lägger till kanten i MST grafen och lägger till noden som kanten leder till i trädet som innehåller de redan sökta noderna (Ayegba, Ayoola, Asani & Okeyinka, 2020).
2.4 Delaunay triangulation
Tekniken Delaunay triangulation (DT) är en av de mer essentiella teknikerna som finns för triangulering av uppsättningar av punkter (Guibas, Knuth & Sharir, 1992). Ett exempel på mer konventionell applicering av DT är interpolering av en delmängd bestående av tre positioner från en större uppsättning av positioner, för avgörande av nya positioner som inte är en del av den ursprungliga uppsättningen av positioner. Ett annat exempel på mer konventionell applicering av DT är upplösning av polygoner till konvexa uppsättningar av trianglar för användning i datorgrafik, där det då handlar om att kombinera en uppsättning av närliggande trianglar till en större konvex uppsättning (Lee & Schachter, 1980).
Ett kritiskt attribut som gör att DT är ett attraktivt val av metod som kan hantera triangulering av en uppsättning punkter, är att för en uppsättning av punkter som trianguleras med DT kommer ingen av trianglarna som blir som resultat att innehålla någon av dessa ursprungliga punkter. Punkterna i uppsättningen kommer endast vara en del av de hörn som utgör trianglarna som fås ut med DT. Med andra ord, givet en uppsättning av punkter kommer omkretsen av tre punkter från varje triangel efter triangulering inte innehålla någon av punkterna i den ursprungliga uppsättningen av punkter (Lee & Schachter, 1980), se Figur 4.
8
Figur 4: Visualisering av en komplett Delaunay triangulation där ingen av punkterna i en punkt uppsättning befinner sig innanför trianglarnas omkrets
Ett exempel på en implementation av DT som är lite enklare att förstå är en iterativ variant kallad Bowyer-Watson (Bowyer, 1981; Watson, 1981; Bourke, 1989; SCIco, 2020). Första steget i Bowyer-Watson algoritmen är att sprida ut en uppsättning av punkter utmed ett 2D plan. En enorm “supertriangel” (ibid.) skapas sedan som ska vara tillräckligt stor för att kunna inkapsla alla punkter innanför triangelns kanter (ibid.), se Figur 5 för exempel.
9
Figur 5: En uppsättning av punkter utspridda slumpmässigt innanför kanterna hos en enorm “supertriangel” (Bowyer, 1981; Watson, 1981; Bourke, 1989; SCIco, 2020), exempel
på första steget how Bowyer-Watson algoritmen för Delaunay triangulation
Från detta kan en slumpmässig punkt i uppsättningen väljas ut och utifrån den enorma
“supertriangeln”, kollas om denna slumpmässigt valda punkt befinner sig inom omkretsen som utgörs av de tre hörnen hos “supertriangeln” eller inte, vilket punkten vid detta stadie kommer göra (Bowyer, 1981; Watson, 1981; Bourke, 1989; SCIco, 2020). Eftersom punkten befinner sig inom “supertriangelns” omkrets går algoritmen vidare med att skapa nya kanter som går från den valda punkten ut till alla tre hörn som utgör “supertriangeln”, se Figur 6.
Med detta steg har en ny uppsättning trianglar skapats med utgång från “supertriangeln”
(ibid.).
10
Figur 6: En vald punkt innanför omkretsen av den enorma triangeln som kopplats samman till den enorma triangelns hörn med kanter för att bilda en ny uppsättning av trianglar Algoritmen fortsätter med att välja en ny punkt från uppsättningen av punkter. Eftersom det skapades en ny uppsättning av trianglar från föregående steg så kollas den valda punkten utifrån alla trianglar i denna nya uppsättning istället för att kollas från “supertriangeln”. Om den valda punkten befinner sig innanför omkretsen av hörnen hos en av trianglarna i triangel uppsättningen, skapas nya trianglar innanför triangeln som kollas genom att skapa kanter från triangelns hörn till den valda punkten, se Figur 7 samt Figur 8 (Bowyer, 1981; Watson, 1981;
Bourke, 1989; SCIco, 2020). Om den valda punkten befinner sig innanför omkretsen av hörnen hos mer än en triangel i triangel uppsättningen, hittas och raderas alla kanter som delas av de trianglar vars omkrets den valda punkten befinner sig inom, sedan skapas nya kanter från alla de trianglarnas hörn till den valda punkten (ibid.), se Figurer 9, 10 samt 11.
Figur 7: En vald punkt som verifierats att befinna sig innanför omkretsen av en mindre triangel från uppsättningen av trianglar
11
Figur 8: En vald punkt som kopplats samman till den mindre triangelns hörn med kanter vilket lägger till en ny uppsättning trianglar till uppsättningen av trianglar
Figur 9: En vald punkt som verifierats att befinna sig innanför omkretsen av flera mindre trianglar från triangel uppsättningen
Figur 10: Två delade kanter hos trianglar från triangel uppsättningen som raderats till följd av att den valda punkten låg innanför omkretsen hos närliggande trianglar från samma
uppsättning
12
Figur 11: Nya kanter som kopplats från alla hörn i triangel uppsättningen till den valda punkten, vilket lägger till en ny uppsättning trianglar till triangel uppsättningen, för att
sedan fortsätta med en ny slumpmässig punkt
Föregående steg upprepas tills dess att det inte finns någon punkt i uppsättningen av punkter som befinner sig inom omkretsen hos någon av trianglarna i triangel uppsättningen (Bowyer, 1981; Watson, 1981; Bourke, 1989; SCIco, 2020). När detta kriterium väl uppnåtts går algoritmen vidare med att radera alla punkter och kanter hos den ursprungliga
“supertriangeln”, samt alla kanter hos triangel uppsättningen som var kopplade direkt till
“supertriangelns” hörn. Efter detta steg är algoritmen klar och en fullständig Delaunay triangulation har producerats, se Figur 12 samt Figur 13 för exempel.
Figur 12: Exempel på en fullständig Delaunay triangulation innan borttagande av
“supertriangeln” (Bowyer, 1981; Watson, 1981; Bourke, 1989; SCIco, 2020) samt direkt kopplade hörn
Figur 13: Exempel på en fullständig Delaunay triangulation efter borttagande av
“supertriangeln” (Bowyer, 1981; Watson, 1981; Bourke, 1989; SCIco, 2020) samt direkt kopplade hörn
13
2.5 Delaunay triangulation och TinyKeep
Det finns många olika exempel på algoritmer och metoder som kan användas för procedurell generering av en dungeon, en av dessa är Delaunay triangulation (DT) metoden som beskrivits i kapitel 2.4. Phi Dinh (2013), utvecklaren av spelet TinyKeep (PhiGames, 2014), utgick från just DT vid skapandet av algoritmen som genererar en dungeon i TinyKeep. I spelet genereras en ny dungeon struktur när spelaren startar spelet första gången. För varje dungeon som spelaren sen tar sig igenom genererar spelets algoritm ännu en ny dungeon struktur som spelaren återigen måste ta sig igenom för att komma längre i spelet.
Som många andra algoritmer och metoder för generering av en dungeon arbetar algoritmen som används i TinyKeep i en 2D rymd, med vilket menas att genereringen strukturellt sker längs med två koordinataxlar (Gellel & Sweetser, 2020; PhiGames, 2014). Algoritmen börjar med att skapa och placera ut ett antal rektanglar som representerar möjliga rum i ett mindre centrerat område, detta antal styrs utifrån en justerbar parameter. Algoritmen ser även till att varje rektangel skapas med ett förhållande mellan bredd och höjd som gör att rektanglarna inte är för avlånga eller för kvadratiska (Phi Dinh, 2013).
Figur 14: Exempel på överlappande rektanglar som representerar möjliga rum från första steget av TinyKeeps dungeon algoritm
När algoritmen slutfört det första steget har representationerna för de rum som möjligen kommer användas för en dungeon skapats, se Figur 14, men de överlappar varandra för tillfället. För att åtgärda detta och sprida ut representationerna av rummen tills dess att det inte finns några överlappande rum längre, använder algoritmen sig av ett separationsstyrbeteende för att få alla rum att gradvis dra sig bort från varandra tills dess att ingen överlappning finns, se Figur 15. Användningen av ett sådant styrbeteende ser till att det inte finns någon överlappning samtidigt som alla rum ändå hålls tätt packade (Phi Dinh, 2013).
14
Figur 15: Exempel på andra steget från TinyKeeps dungeon algoritm, möjliga rum i form av rektanglar som flyttats tills de inte överlappar varandra längre
Härnäst börjar vad som beskrivs som “den roliga delen” (Phi Dinh, 2013) i algoritmen, att döma vilka av de tillgängliga rektanglarna som möter kriterium för att användas som ett rum.
Algoritmen använder här ett tröskelvärde för att avgöra vilka av rektanglarna som kommer att räknas som rum, se Figur 16. Detta tröskelvärde utvärderar en rektangel baserat på dess bredd och höjd. De rektanglar som inte räknas till rum används senare i algoritmen (Phi Dinh, 2013).
Figur 16: Exempel på tredje steget från TinyKeeps dungeon algoritm, rektanglar som valts ut att kunna användas som rum, markerade med röd färg
15
Vid detta steg kopplas de rektanglar som angivits vara rum ihop. Det är här som DT börjar bli mer betydande i algoritmen. DT används här för att ta fram en graf bestående av mittpunkterna hos varje rum samt alla kopplingar mellan varje rum, se Figur 17. Det som gör DT användbart för detta ändamål är att den metoden ser till att ingen kant mellan noderna i grafen överlappar en annan kant rent fysiskt (Phi Dinh, 2013), se Figur 18.
Figur 17: Exempel på fjärde steget från TinyKeeps algoritm, med representationer av mittpunkter hos alla röda rum markerade med blå punkter
Figur 18: Exempel på fjärde steget från TinyKeeps algoritm, en Delaunay triangulation graf markerad med blå linjer som visualiserar de möjliga sätt som algoritmen kan koppla
ihop alla röda rum
För nästa steg tar algoritmen bort en del kopplingar mellan noder i grafen som tagits fram från föregående steg, se Figur 19. Algoritmen gör detta eftersom det för en generell dungeon inte är attraktivt att ha korridorer mellan exakt varje rum, det skulle ge en överväldigande och
16
förvirrande geometrisk struktur. Algoritmen går således vidare genom att konstruera ett MST, vilket då garanterar att grafen av rum fortfarande går att ta sig igenom utan att ha ett överväldigande antal korridorer mellan rum (Phi Dinh, 2013).
Figur 19: Exempel på femte steget från TinyKeeps algoritm, en blåmarkerad MST graf konstruerad från en Delaunay triangulation graf vilken visualiserar den möjliga, slutliga
konfigurationen av kopplingar mellan de röda rummen
Vad algoritmen gör härnäst är att modifiera den resulterande grafen av rum som blev kvar efter ovan nämnda steg. Modifieringen sker genom att återintroducera ett visst procentuellt antal av de kopplingar i grafen som togs bort. Enligt Phi Dinh (2013) görs detta för att introducera några cykler för att göra en dungeon mer intressant strukturellt sett, se Figur 20.
Den slutliga resulterande grafen innefattar då alla de rektanglar som blivit klassificerade som rum, vilka alla är garanterade att kunna nås från minst ett annat rum, med några cykler som introducerar loopande segment av korridorer och rum för att ge lite variation (Phi Dinh, 2013).
Figur 20: Exempel på sjätte steget från TinyKeeps algoritm, en slutgiltig graf med återintroducerade linjer som resulterar i cykler markerade med grön färg, vilka nu
representerar de kopplingarna som ska skapas mellan alla röda rum
17
För att slutligen introducera korridorer mellan rummen i den slutliga grafen används raka linjer eller L-linje segment för att fylla kopplingarna i grafen mellan varje rum. För detta steg används de rektanglar som inte uppnådde kriterium för att användas som rum. Varje rektangel som överlappar med en rak linje eller L-linje segment mellan varje rum används istället som en korridor som då antingen kopplar mellan två eller flera rum eller ett rum och ett eller flera linjesegment. Om ett linjesegment inte överlappar något möjligt rum används linjesegmentet direkt som en korridor istället. Introduktionen av de resterande, överlappande rektanglarna som korridorer ger tvistande och oregelbunden variation till den slutliga dungeon som genererats (Phi Dinh, 2013), se Figur 21.
Figur 21: Exempel på en slutgiltig dungeon struktur som skulle kunna genereras av TinyKeeps dungeon algoritm, infogade korridorer markerade med svarta linjer, rum som
används som korridorer markerade med grått
2.6 A* Pathfinding
A* algoritmen är en sökalgoritm som används primärt för graf-traversering med positivt viktade grafer. Syftet med A* är oftast att hitta en “tillräckligt bra” väg från en startpunkt till en målpunkt där en “tillräckligt bra” väg oftast innebär den väg som ger en av de minsta möjliga kostnaderna från start till mål. Kostnaden definieras oftast som vikten mellan noder i en graf från start till mål. Ett lämpligt exempel på användning av A* algoritmen är navigering genom en labyrint eller runt olika typer av hinder med en Non-Player Character (NPC) (Fridenfalk, 2014; Hart, Nilsson & Raphael, 1968).
A* används mer generellt för pathfinding i en 2D rymd med vilket menas att algoritmen generellt används för att navigera igenom och hitta en “tillräckligt bra” väg mellan noder i ett 2D rutnät. För att kunna utföra pathfinding genom ett rutnät använder A* en heuristisk beräkning för att hitta en “tillräckligt bra” väg mellan två noder i en graf. Denna heuristiska beräkning består av tre olika heltalsvärden vid namn G, H och F (Fridenfalk, 2014; Hart, Nilsson & Raphael, 1968). För denna heuristiska beräkning kan G definieras som kostnaden från en startnod genom den hittills kortaste vägen till den nod som A* för tillfället kollar, H kan i sin tur definieras som distansen mellan en slutnod och den nod som A* för tillfället kollar
18
och F kan definieras som summan av G plus H (Fridenfalk, 2014; Hart, Nilsson & Raphael, 1968; Lague, 2014).
A* algoritmen har som nämnts ovan som syfte att hitta en “tillräckligt bra” väg mellan en startnod och en slutnod i en graf eller ett rutnät. Med ett 2D rutnät som exempel är första steget med A* att välja ut en startnod och en slutnod (Fridenfalk, 2014; Hart, Nilsson &
Raphael, 1968; Lague, 2014), se Figur 22.
Figur 22: Exempel på ett A* 2D rutnät med startruta markerad med grönt och målruta markerad med blått. Tillgängliga rutor markerade med vitt och blockerande rutor markerade
med svart
Startnoden läggs till vad som ofta definieras som en “öppen” samling där alla noder som ska kollas läggs för att sökas igenom en efter en, en “öppen” samling är ofta i form av en lista eller en kö. En loop itereras sedan igenom så länge som den “öppna” samlingen innehåller minst ett element. Inom denna loop hämtas sedan en nod från och tas bort från den “öppna”
samlingen för att läggas till vad som brukar definieras som en “stängd” samling vilket ofta är i form av en lista, denna “stängda” samling används för att hålla reda på de noder som redan kollats. Efter att den nuvarande noden lagts till i den “stängda” samlingen kollas om den nuvarande noden är slutnoden och om så är fallet avslutas loopen eftersom en optimal väg då har hittats (Fridenfalk, 2014; Hart, Nilsson & Raphael, 1968; Lague, 2014), se Figur 23.
19
Figur 23: Exempel på ett A* 2D rutnät där en “tillräckligt bra” väg från start till mål har hittats och blivit tvungen att gå runt blockerande rutor, rutorna som utgör vägen är
markerade med ljusblått
Om den nuvarande noden som kollas inte är slutnoden kollas alla grannar till den nuvarande noden, se Figur 24. Vid detta steg i loopen kollas först om en av grannarna till den nuvarande noden är traverseringbar eller om den inte finns i den “stängda” samlingen än. Om en granne till den nuvarande noden inte är traverseringbar eller om den redan finns i den “stängda”
samlingen skippas den grannen och nästa granne kollas istället förutsatt att det finns någon mer granne att kolla (Fridenfalk, 2014; Hart, Nilsson & Raphael, 1968; Lague, 2014), se Figur 25 samt Figur 26.
20
Figur 24: Exempel på ett A* 2D rutnät med den nuvarande noden som start noden markerad med grönt och alla möjliga grannoder som kan kollas markerade med grått
Figur 25: Exempel på ett A* 2D rutnät med den nuvarande noden som kollas markerad med orange, nästa grann-nod som ska kollas markerad med lila och blockerande grann-
noder markerade med röda kryss.
21
Figur 26: Exempel på ett A* 2D rutnät med den nuvarande noden som kollas markerad med orange, nästa grann-nod som ska kollas markerad med lila och blockerande grann- noder markerade med röda kryss. I detta exempel visas även en grann-nod som redan kollats
vilken är markerad med rött
Om en granne hittas som antingen är traverseringbar, inte finns i den “stängda” samlingen eller uppfyller båda av dessa kriterier utförs heuristik beräkningen för denna granne vars värde sedan kollas mot grannens förra heuristikvärde för att se om vägen till denna granne genom den nuvarande noden är kortare eller inte. I samband med verifieringen av heuristikvärdet kollas även om grannen redan finns i den “öppna” samlingen eller inte. Om det nya heuristikvärdet som beräknas för grannen är mindre än grannens förra heuristikvärde eller om grannen inte finns i den “öppna” samlingen kan grannens heuristikvärde uppdateras med det nyligen beräknade heuristikvärde och få markerat den nuvarande noden som dess väg till start noden (Fridenfalk, 2014; Hart, Nilsson & Raphael, 1968; Lague, 2014), se Figur 27.
22
Figur 27: Exempel på ett A* 2D rutnät med tidigare kollade noder markerade med rött, den nuvarande noden som verifierats att ge en kortare sträcka till målet markerad med lila och
den nod som markerats att vara vägen tillbaka till starten markerad med ljusblått Om det verifierades att grannen inte redan fanns i den “öppna” samlingen kan grannen vid detta steg läggas till samlingen eftersom det redan verifierats i tidigare steg att grannen inte finns med i den “stängda” samlingen vilket innebär att grannen inte sökts igenom tidigare och då kan sökas igenom vid ett senare tillfälle (Fridenfalk, 2014; Hart, Nilsson & Raphael, 1968;
Lague, 2014). Dessa steg upprepas tills den “öppna” samlingen är tom eller tills den nuvarande noden som kollas verifierats att vara samma som slutnoden.
2.7 Egenskaper och evaluering
Om man tänker på implementationer av olika PCG metoder som lösningar för olika problemområden inom PCG, finns det attribut som introducerar avvägningar att göra för varje lösning som beror helt på kontexten för en given lösning. Dessa attribut och i sin tur avvägningar kan i sig ses som konstanter som alltid behöver övervägas för implementationen av en PCG lösning (Shaker, Togelius & Nelson, 2016). Exempel på attribut som kan medföra nödvändiga avvägningar är hastighet gentemot kvalitet eller justerbarhet gentemot pålitlighet (ibid.). Några attribut som uppkommer frekvent för lösningar av problemområden inom PCG är som följer (ibid.):
● Hastighet, vilket kan variera oerhört beroende på online eller offline procedurell generering. Kravet för hastighet kan variera mellan allt från millisekunder om det handlar om online generering, till månader om det handlar om offline generering.
● Pålitlighet, vilket är mer eller mindre viktigt beroende på vad som genereras av en generator. Vissa generatorer kan klara sig med ett par fel i det innehåll som genererats medan andra måste kunna generera innehåll som är felfritt. För en generator som har
23
som uppgift att generera en dungeon så finns exempelvis kriterium att den dungeon som genereras måste ha en ingång och en utgång.
● Justerbarhet, vilket kan vara i fråga om justering av en generator från en människa eller från en separat algoritm. Det finns allt som oftast behov av att kunna justera det innehåll som genereras procedurellt till olika grader för att kunna matcha en vision mer eller mindre.
● Variation. Det finns ofta ett behov av att kunna procedurellt generera innehåll som varierar på olika sätt beroende på kontext. Detta behövs för att undvika överanvändning av samma form av innehåll. Variation är ett attribut som är särskilt icke-trivialt i sin natur. Från ett extrem kan variationen hos procedurellt genererat innehåll lida för att få innehåll av bra kvalité. Från ett annat extrem kan kvalitén hos innehållet lida för att få innehåll med bra variation.
● Trovärdighet. Även om utvecklare vet att verktyg genererat någon form av innehåll, är det oftast önskvärt att det innehåll som genererats med en procedurell generator ser ut att vara antingen naturligt eller gjort med en mänsklig hand för att bevara en illusion av verklighet.
Med implementering av en lösning för ett problemområde inom PCG, kommer behovet av att evaluera att dessa ovan nämnda attribut balanserats, lösts och implementerats till en funktionsduglig och tillfredsställande grad. Exempel på hur evaluering av dessa och andra attribut har utförts tidigare presenteras här från forskningsarbeten och tidigare examensarbeten som utfört arbeten liknande till detta arbete (Björklund, 2016; Johansson, 2017; Helge, 2018; Karlsson, 2019; Canossa & Smith, 2015; Kim & Crawfis, 2018).
Tidseffektivitet är ett attribut som evaluerats i ett flertal tidigare, liknande examensarbeten.
Detta attribut har evaluerats för att avgöra hur effektiv en algoritm är genom att mäta hur lång tid det tar för en given algoritm att slutföra genereringen av det angivna innehållet från tiden algoritmen startar genereringen. Hur data för evalueringen har tagits fram i tidigare arbeten är genom att mäta realtiden som gått när den valda algoritmen nått sitt slut, realtiden har mätts specifikt för att det är ett värde som anger hur mycket tid som förflutit oavsett om algoritmen skulle fastna en stund eller inte (Björklund, 2016; Johansson, 2017; Helge, 2018;
Karlsson, 2019). Tidseffektivitet har även undersökts av Zhao, Ge, Qu, Zhang & Sun (2017) som kom fram till att en acceptabel väntetid för applikationer kunde variera från ca 2 sekunder till ca 12 sekunder för ett online scenario, med omkring 30 sekunder som en övre gräns där frustrering över väntetid börjar sätta in för en användare.
Möjlighet att nå alla rum är ett attribut som i två tidigare examensarbeten har evaluerats som en säkerhetsåtgärd. Anledningen till att utföra denna evaluering som en säkerhetsåtgärd är för att möjligheten att nå alla rum ansågs i dessa tidigare examensarbeten att vara ett grundläggande krav för den valda algoritmen som evaluerades, eftersom en korrekt implementation inte skulle kunna skapa rum som inte går att nå (Johansson, 2017; Karlsson, 2019).
Attributet variation har i ett tidigare examensarbete evaluerats utifrån tre kategorier:
rumsdimensioner, genomsnittlig längd av korridorer och antalet återvändsgränder.
Mätningen av rumsdimensioner utfördes genom att den valda algoritmen skrev ut dimensionerna hos den dungeon som genererades av algoritmen för att sedan räkna hur många celler som blivit omvandlade till golv i den dungeon som genererades. Detta examensarbete utförde evalueringar på två algoritmer, varav den ena var Delaunay
24
triangulation. För mätning av antalet återvändsgränder noterades antalet grannar för varje rum utifrån en MST graf, om ett rum bara hade en granne räknades rummet som en återvändsgränd (Karlsson, 2019).
Attributet pålitlighet har i ett tidigare examensarbete evaluerats för att visa på korrekt implementation av den valda algoritmen. I det examensarbete där attributet pålitlighet utvärderades, mättes attributet i ett booleskt format som sant eller falskt då pålitlighet i det fallet innebar att det innehåll som genererades var fullt sammankopplat (Helge, 2018).
Attributet densitet har i ett tidigare examensarbete evaluerats baserat på procent utifrån innehållet som genererats av den valda algoritmen. Detta attribut mättes genom att undersöka hur stor del av det genererade innehållets utrymme som utgjordes av dungeon-element och hur stor del som lämnats tomt (Helge, 2018). I ett annat tidigare examensarbete har densitet mäts genom ett poängsystem där varje gångbar cell i en dungeon skulle ge poäng baserat på cellens avstånd till närmaste vägg. Detta poängsystem skulle innebära att en dungeon med högre poäng skulle ha mindre densitet till sin struktur medan en dungeon med mindre poäng skulle ha högre densitet till sin struktur (Björklund, 2016). Ett ytterligare examensarbete har utvärderat densitet på ett liknande sätt till ett poängsystem, där alla gångbara ytor har kontrollerats efter vad de omgivits av. Evalueringen har mäts utifrån hur många gångbara ytor som omgivits av väggar gentemot hur många gångbara ytor som omgivits av andra gångbara ytor (Johansson, 2017). Exempel för hur attributet densitet kan evalueras har även getts av Canossa & Smith (2015) där densitet i det fallet har mätts genom att evaluera hur stort utrymme av en vertikal del av en nivå är upptagen av exempelvis en plattforms-tile eller en fiende-tile. I detta fall skulle en vertikal del av en nivå ha låg densitet om den innehåller ett mindre antal plattforms- och fiende-tiles.
Ytterligare exempel på attribut som kan evalueras nämns av Canossa & Smith (2015) samt Kim & Crawfis (2018). Ett av dessa exempel är attributet Leniency vilket i detta fall syftar på en estimering av svårighetsgraden eller komplexiteten hos en given nivå i ett spel med fokus på de element som en given nivå i ett spel består av, som antal eller typ av fiender eller varierande navigations möjligheter i olika utrymmen (Canossa & Smith, 2015). Ett exempel som är likt Leniency är Verticality vilket beskrivs som en evaluering av medelvärdet av riktningarna mellan de positioner som utgör strukturen hos en traverserbar gång. Detta medelvärde av riktningar mellan positioner kan då evalueras för att avgöra komplexiteten eller svårighetsgraden hos en traverserbar gång i fråga om hur rak eller snårig gången är samt om gången går uppåt, nedåt eller i någon annan riktning (Canossa & Smith, 2015). Ett annat exempel är evaluering av förekomsten av återvändsgränder i en dungeon, vilket kan anses vara närbesläktat med evaluering av attributet pålitlighet (Kim & Crawfis, 2018).
25
3 Problemformulering
Procedurell generering av en dungeon är ett vanligt problemområde inom PCG för dataspelsutveckling. Det finns många olika varianter av algoritmer som kan användas för procedurell generering av en dungeon vilka kan ge varierande resultat beroende på behov.
Generellt sett används dessa algoritmer för procedurell generering av en dungeon i en 2D rymd med vilket menas att strukturen konstrueras utmed två koordinataxlar, oavsett om strukturen geometriskt sett är skapad i 2D eller 3D. Detta arbete har utforskat möjligheten samt eventuella effekter av att modifiera TinyKeeps dungeon algoritm för procedurell generering utmed tre koordinataxlar, arbetet har sedan utvärderats utifrån ett mindre antal attribut som ansågs relevanta i fråga om tidseffektivitet, pålitlighet, justerbarhet och variation.
Utvärderingen sker via experiment i form av simulering.
3.1 Syfte
Syftet med detta arbete var att utforska möjligheten för procedurell generering av en dungeon struktur i 3D, med vilket menas att utforska om själva strukturen för en dungeon kan genereras utmed tre koordinataxlar istället för det mer klassiska tillvägagångssättet med två koordinataxlar. Dessutom skulle arbetet utforska hur procedurell generering utmed tre koordinataxlar påverkar genereringen av en dungeon med hänsyn till skapande och placering av rum samt sammankoppling av rum med korridorer geometriskt sett. Frågeställningen som detta arbete då skulle besvara, lyder som följande.
“Hur presterar 2D dungeon algoritmen i spelet TinyKeep vid generering i en 3D rymd, i fråga om pålitlighet, tidseffektivitet, justerbarhet och variation?”
För att kunna ge svar på frågeställningen skulle 2D dungeon algoritmen som skapats för spelet TinyKeep (PhiGames, 2014) med bas i Delaunay triangulation förlängas till och testas utmed en tredje koordinataxel. Vad förlängning utmed en tredje koordinataxel var tänkt att bidra med är varierande positioner utmed höjden hos individuella rum i en dungeon likt till hur positioner hos individuella rum vanligtvis varierar utmed bredden och djupet i en 2D rymd. Ett rums position var då tänkt att kunna variera mer i bredd, djup och höjd i en 3D rymd. Denna algoritm har valts ut att basera artefakten på och besvara frågeställningen med för att en dungeon som genereras med algoritmen får en struktur till sig som kan anses ha en bra balans mellan kaotisk och strukturerad. Detta ansågs som en passande egenskap för arbetets syfte.
För utvärdering av artefakten har ett mindre antal attribut valts ut för att få fram relevant data. Dessa attribut har valts ut baserat på inspiration från de evalueringar som utförts i forskningsarbeten och tidigare, liknande examensarbeten (Björklund, 2016; Johansson, 2017; Helge, 2018; Karlsson, 2019; Canossa & Smith, 2015; Kim & Crawfis, 2018). De attribut som utvärderas är som följer:
● Mätning av komplexitet hos korridorer för utvärdering av variation
● Mätning av andelen rum som använts i relation till hur många rum som anges för generering, för utvärdering av justerbarhet och pålitlighet
● Mätning av den fysiska längden från start rummet till mål rummet för utvärdering av variation
● Mätning av storlek och densitet för utvärdering av variation
26
● Mätning av höjd-variation mellan alla skapade rum för utvärdering av variation och pålitlighet
● Mätning av tidseffektivitet
3.2 Metodbeskrivning
För att besvara frågeställningen har arbetet utvärderats via experiment i form av simulering (Zelkowitz och Wallace, 1998). En artefakt i form av en dungeon generator skapades för att kunna generera de dungeon strukturer som utvärderades för att besvara frågeställningen.
3.2.1 Experiment
Experiment i form av simulering valdes eftersom det utgör en utvärderingsmetod som utförs som en modell av verkligheten vilket innebär att specifika attribut och aspekter enklare kan väljas ut och evalueras specifikt för utvärdering i en mer kontrollerad miljö. Denna utvärderingsmetod medför även att aspekter och attribut som inte är intressanta för en utvärdering kan överses, vilket gör utvärdering snabbare och enklare att utföra gentemot att utföra ett fullskaligt experiment i en verklig situation. Att experiment i form av simulering kan räknas till en metod som är enklare att återskapa och upprepa är exempel på attribut som gjorde experiment i form av simulering attraktivt för utvärdering av artefakten, då en artefakt i form av en dungeon generator bör exekveras ett större antal gånger för att samla så täckande data som möjligt. Vidare gör experiment i form av simulering det enklare att få ut mer kvantitativ data, för att ge en objektiv utvärdering av artefakten (Zelkowitz och Wallace, 1998).
En nackdel som var med den utvalda utvärderingsmetoden är att det inte är enkelt att veta hur väl den simulerade testmiljön motsvarar den verkliga miljön som artefakten är tänkt att kunna arbeta i. Även om det är enklare att få fram mer kvantitativ data med simulerings experiment finns ingen garanti att den data som tas fram ger relevanta svar till de problem som artefakten avsett att lösa (Zelkowitz och Wallace, 1998).
Förutom experiment i form av simulering fanns statisk analys och dynamisk analys som exempel på möjliga alternativa utvärderingsmetoder som hade kunnat användas om simulerings experiment inte hade valts (Zelkowitz och Wallace, 1998).
Statisk analys är en utvärderingsmetod med syfte att hämta data från en slutgiltig produkt för att utvärdera specifika attribut hos produkten vilka exempelvis kan vara attribut som mjukvarukomplexitet eller dataflödesimplicitet. Nackdelen med statisk analys som utvärderingsmetod och anledningen till att statisk analys inte valdes var att den kvantitativa data som fås ofta är svår att knyta till de attribut som är menade att utvärderas med metoden.
Vidare är de attribut som utvärderas via denna metod ofta representativa för produkten själv, inte något eventuellt resultat som kommer av produkten. För detta examensarbete hade det exempelvis inneburit att utvärdera antalet for-loopar i artefaktens algoritm istället för att utvärdera ett attribut hos en dungeon som genererats vilket inte var passande för att besvara den frågeställning som ställts av detta examensarbete (Zelkowitz och Wallace, 1998).
Dynamisk analys är likt statisk analys en utvärderingsmetod med syfte att hämta data från en slutgiltig produkt för utvärdering. Vad som skiljer dynamisk analys från statisk analys är att de attribut som utvärderas med denna metod exempelvis skulle vara exekveringstiden hos en produkt. En fördel med dynamisk analys gentemot statisk analys är att attributen som utvärderas kan anpassas för att testas hos en mängd produkter med liknande funktionalitet, vilket är anledningen till att dynamisk analys ofta används för att testa en mängd produkter
27
mot varandra via benchmarking. En nackdel med denna metod är dock risken att en produkts beteende ändras eftersom dynamisk analys kräver att det läggs in nya instruktioner i ett befintligt program för mätning. Denna metod ansågs inte vara passande för utvärdering av detta examensarbete eftersom metoden förutsätter att en produkt testas i en mer verklighetstrogen miljö då den generellt används för benchmarking. Eftersom det inte fanns tillräckligt med tid eller resurser i denna kurs för att kunna utföra testning av detta examensarbete på en sådan skala valdes dynamisk analys bort som utvärderingsmetod (Zelkowitz och Wallace, 1998).
3.2.2 Utvärderingsmetoder
De attribut som utvärderades valdes för att en bedömning av dem täckte relevanta aspekter hos artefakten som simulerings experiment utfördes på, vilka skulle ge de relevanta data som behövdes för att kunna besvara den fråga som ställdes av detta arbete. Valet av dessa attribut har inspirerats av attribut och evalueringsmetoder som utförts i forskningsarbeten och tidigare, liknande examensarbeten (Björklund, 2016; Johansson, 2017; Helge, 2018; Karlsson, 2019; Canossa & Smith, 2015; Kim & Crawfis, 2018).
Komplexitet hos korridorer som genereras för att kunna traversera en dungeon utvärderades i variations syfte. Eftersom artefakten i detta arbete arbetat utmed tre koordinataxlar fanns det mer tomrum och med det mer utrymme att placera korridorer, dessutom medförde en tredje koordinataxel en större chans för att strukturer som trappor behövdes för att kunna traversera en dungeon utmed höjdled. Konceptet med korridorer uppbyggda med trappor som en del av sin struktur introducerade då en hel extra dimension av variation för korridorer i en dungeon. En korridor som då ändrar riktning ofta kunde anses ha en högre komplexitet i en tredimensionell rymd.
Den procentuella andelen av rum som använts i relation till det antal rum som angavs för generering utvärderades från ett kontrollperspektiv vilket gjorde att det blev i fråga om justerbarhet. Detta var för att se hur möjligt det är att ha mer exakt kontroll över en dungeon som genererats av artefakten, samt för att se om den procentuella andelen rum som faktiskt användes i en dungeon fluktuerade eller var relativt stadig vilket skulle påvisa graden av kontroll av procedurell generering som kunde fås av artefakten.
Den fysiska längden från start till mål utvärderades i fråga om variation för att se hur artefaktens algoritm varierade i fråga om procedurell generering utmed tre koordinataxlar, med vilket menas att se om en tredje koordinataxel medförde någon form av bias i fråga om fysisk placering och längd mellan start och mål rum.
Storlek och densitet utvärderades liknande attributet nämnt ovan i fråga om variation. Givet en tredje koordinataxel att arbeta utmed fanns det som nämnts ovan mer tomrum att arbeta med vilket kunde medföra större variation i fråga om storlek och densitet hos en dungeon.
Givetvis fanns även en möjlighet till någon form av bias för storlek och densitet, exempelvis kunde det kanske funnits en bias för en dungeon att vara tätt packad eller möjligen tvärtom så att en dungeon oftare skulle vara glest uppbyggd.
Höjd-variation mellan de skapade rummen utvärderades likt de tre attributen nämnda ovan i variations syfte för att se huruvida algoritmen utnyttjade den tredje koordinataxel som den hade tillgång till. Höjd-variation utvärderades även i fråga om pålitlighet för att avgöra om den tredje koordinataxel som fanns tillgänglig faktiskt användes, det hade inte precis varit någon större idé att introducera en tredje koordinataxel för användning om algoritmen ändå
28
påvisade en bias för att skapa en tvådimensionell dungeon strukturellt sett. Detta kopplar även en del till utvärderingen av korridor komplexitet, om skillnaden i höjd skulle vara stor mellan två rum skulle det medföra att en korridor hade behövt bestå av ett större antal trappor för att kunna traverseras vilket skulle innebära en korridor med högre komplexitet.
Tidseffektivitet utvärderades för att se hur procedurell generering utmed en tredje koordinataxel kunde påverka effektiviteten av genereringen. Oavsett vad en algoritm är skapad för att göra är det alltid bra att en algoritm är kostnadseffektiv, exempelvis kostnadseffektiv med tid. För en generell algoritm som har som uppgift att generera en dungeon ska man exempelvis inte behöva vänta en dag på att en dungeon struktur ska vara färdig för användning direkt i ett spel eller redo för vidare arbete av en designer.
Något som är viktigt att nämna är att de attribut som utvärderades i fråga om justerbarhet och variation var beroende av hur extensivt den modifierade versionen av algoritmen i TinyKeep (PhiGames, 2014) implementerades för att ge kontroll och frihet till dessa attribut. Detta medförde en risk att utvärderingen av attributen kunde påverkats till en varierande grad och gjort den data som togs fram med experimenten mindre valid i fråga om objektivitet.
29
4 Implementation
Detta kapitel går igenom och beskriver arbetets implementeringsprocess. Först går kapitlet igenom de problem som uppkom och designbeslut som togs under implementeringen av artefakten, sedan följer implementering och designbeslut för de attribut som evaluerades.
Slutligen beskrivs och visas en pilotstudie som testat artefaktens funktionalitet.
4.1 Experimentmiljö
Implementationen av artefakten har utförts i spelmotorn Unity (Unity Technologies, 2020a) med programmeringsspråket C#. Unity är en komponentbaserad spelmotor vilket innebär att kommunikation med och manipulering av objekt i spelmotorn sker genom diverse komponenter som kan appliceras till och tas bort från ett objekt i spelmotorn. Att artefakten implementerades i spelmotorn Unity medförde tillgång till hjälpsamma klasser, metoder och komponenter som underlättade implementationen av artefaktens algoritm.
En av dessa hjälpsamma metoder som kommer med Unity (ibid.) är att kunna sätta olika objekt i ett hierarkiskt barn-förälder förhållande till varandra vilket gör att objekt som blir markerade att vara barn till ett förälder-objekt automatiskt får sina positioner, rotationer och skalor transformerade till förälderns lokala rymd. Ytterligare hjälpsamma komponenter och metoder som användes i implementationen och är bra att känna till är följande:
● Collider (Unity Technologies, 2020d) vilket är basklassen för alla kollisionskomponenter i Unity. Collider klassen ger möjligheten för generalisering av flera kollisionsmetoder för fysikmotorn i Unity via arv och polymorfism.
● BoxCollider (Unity Technologies, 2020b) vilket är en specialiserad typ av Collider komponent som finns tillgänglig i Unity för att ge ett objekt möjligheten att interagera med andra objekt vid kollisioner via fysikmotorn i Unity.
● MonoBehaviour (Unity Technologies, 2020e) vilket är en basklass i Unity som ger en script-klass möjligheten att prata direkt med spelmotorn via arv.
● OverlapBox (Unity Technologies, 2020c) vilket är en kollisionsmetod som ges tillgång till via Physics klassen i Unity. Givet ett par parametrar som en position och en kubisk storlek med mera kan metoden OverlapBox avgöra om en Collider komponent överlappar det område som anges med den givna positionen plus den kubiska storleken eller inte.
● BoxCast (Unity Technologies, 2020g) vilket är en metod som ges tillgång till via Physics klassen i Unity och fungerar liknande till en raycast. Givet ett par parametrar som startposition och riktning med mera kan en lådformad stråle kolla efter kollisioner med andra Collider komponenter och ge information angående objektet som den lådformade strålen träffade.
● Coroutine (Unity Technologies, 2020f) vilket är ett objekt som tillhandages av Unity via bas-klassen MonoBehaviour och gör det möjligt att skapa metoder som kan utföra olika former av väntning genom att pausa exekvering av kod och returnera kontroll till resten av Unity, för att sedan fortsätta där objektet lämnade exekveringen av kod efter objektet har utfört det väntande som angavs.
● Vector3Int (Unity Technologies, 2020h) vilket är en struktur i Unity som primärt används för att representera en position i en tredimensionell rymd. Till skillnad från Vector3 strukturen kan en Vector3Int endast representera heltalspositioner vilket har sina fördelar om man arbetar i en tile-baserad miljö.
30
Eftersom algoritmen som används i TinyKeep (PhiGames, 2014) arbetar utifrån ett tvådimensionellt rutnätssystem för att garantera kompakthet utan överlappning har algoritmen i denna artefakt arbetat utifrån samma koncept fast med ett tredimensionellt rutnätssystem istället. Med ett rutnätssystem menas i detta sammanhang att positionerna hos alla objekt som skapas avrundas och arbetar utifrån närmaste heltal och heltals-vektorer för att göra beräkningar och skapandet av rum och korridorer enklare.
4.2 3D TinyKeep dungeon
För att ge viss kontroll över artefaktens algoritm och den dungeon som kan genereras gjordes ett mindre antal parametrar tillgängliga i justeringssyfte. Dessa parametrar har tagits fram eftersom de har störst påverkan på den genererade strukturen och utseendet hos en dungeon.
Parametrarna definierades som följer:
● “MaxRoomSpawningRange”, ett flyttal som anger den maximala radien från nollpunkten där ett rum kan placeras initialt i en 3D rymd.
● “AvailableRoomsToSpawn”, ett heltal som anger hur många möjliga dungeon rum som ska skapas när en dungeon genereras.
● “MaxCreatedRoomSize”, en tredimensionell vektor som anger den största möjliga storleken för ett möjligt rum som skapas.
● “MinCreatedRoomSize”, en tredimensionell vektor som anger den minsta möjliga storleken för ett möjligt rum som skapas.
● “MinimumAcceptableRoomSize”, en tredimensionell vektor som anger den minsta storleksmässiga gränsen för acceptabla rum.
4.2.1 Skapande och placerande av rum
För att skapa de rum som har möjlighet att användas i en slutgiltigt resulterande dungeon togs ett tidigt beslut att skapa tile-baserade tredimensionella rum för att underlätta kollisionsberäkningar och se till att ett skapat rum inte skulle råka överlappa ett annat rum när rummets position väl avrundats till närmsta heltalsvektor. Ett rums volym byggs då upp iterativt med 1 kubikmeters kuber utmed alla tre koordinataxlar för att det ska vara enklare att se den kompletta volymen av ett rum visuellt när rummet skapats, samt för att göra det enkelt att visuellt upptäcka om ett rum överlappar ett annat när rummens positioner väl avrundats till närmsta heltalsvektor, se Figur 28.
31
Figur 28: Exempel på ett rum som genererats av algoritmen i detta arbete. Markerat är en 1 kubikmeters kub som utgör en del av volymen hos alla rum
För att kunna skapa rum liknande till hur de skapas i TinyKeep (PhiGames, 2014) sker två separata processer sekventiellt baserade på instruktioner beskrivna av Phi Dinh (2013). Först beräknas initiala storlekar på X-, Y- och Z-axeln fram för att bestämma initial rumsstorlek och sedan kollas storleksförhållandet mellan X- och Z-axeln för att se till att storleksförhållandet varken ger en storlek som är för avlång eller för kvadratisk.
Beräkningen av de initiala storlekarna på X-, Y- och Z-axlarna har utgått från att först räkna fram ett medelvärde på rumsstorlek för att sedan ta den minsta storleken mellan medelvärdet och en slumpad rumsstorlek mellan den maximala och minimala storleken, med en mindre chans att utföra samma beräkning fast istället ta den maximala mellan dessa storlekar.
Ett medelvärde för rumsstorlek fås från en metod kallad “GetMeanRoomSize” vilken går igenom en for-loop lika många gånger som antalet rum som angetts att skapas. Varje iteration adderas en slumpad rumsstorlek till ett returvärde. Efter for-loopen itererats igenom delas detta returvärde med antalet rum som angetts att skapas för att få fram medelvärdet innan det slutligen returneras från metoden.
Beräkningen av storleksförhållandet har skett via procentuell beräkning mellan X- och Z-axeln för att se om längd förhållandet mellan X- och Z-axeln ger ett rum som är för avlångt eller för kvadratiskt. Beroende på vilken koordinataxel som är längre kollas om den andra axeln är inom en viss procentuell andel gentemot den ena axeln, om den inte är det ökas eller minskas längden på den axeln tills dess att den är inom den procentuella andelen gentemot den andra axeln för att rummets storlek ska kunna anses inte vara för avlångt eller för kvadratiskt på X- och Z-axlarna.
32
För att kunna göra lösningen av en mängd positionsrelaterade problem enklare i senare steg blev alla 1 kubikmeters kuber som ett rums volym består av markerade att agera som barn till ett förälder-objekt som representerar rummet självt, se Figur 29. Detta förälder-objekt blev i sin tur tilldelat en separat BoxCollider komponent som blev konfigurerad för att vara positionerad i det absoluta centrum av det skapade rummet och förstorad för att omsluta alla 1 kubikmeters kuber som rummets volym är uppbyggt av, se Figur 30.
Figur 29: Exempel på ett rum som genererats av algoritmen i detta arbete. Markerat är förälder-objektet som ger en visualisering av alla 1 kubikmeters kuber som angivits att vara
barn till förälder-objektet och utgör ett rums volym
33
Figur 30: Exempel på ett rum som genererats av algoritmen i detta arbete. Markerat är förälder-objektet som visualiserar BoxCollider komponenten som omsluter hela rummets volym. En större del av kuberna som utgör rummets volym har inaktiverats i detta exempel
för att enklare kunna visualisera BoxCollider komponenten
Den initiala placeringen av de möjliga rum som skapats har skett liknande till hur den initiala placeringen av möjliga skapade rum sker i TinyKeep (PhiGames, 2014) via slumpgenerering av position inom en viss maximal radie. För att påbörja den primära skillnaden med algoritmen i detta arbete slumpas en tredimensionell position fram istället för en tvådimensionell position genom användning av slump-parametern InsideUnitSphere (Unity Technologies, 2020i) från Random klassen i Unity. Denna parameter returnerar en slumpmässig tredimensionell positionsvektor inom eller på omkretsen av en sfär med radie 1 vilket är något som funkade utmärkt för att enkelt få fram en slumpmässig tredimensionell position. Positionen från InsideUnitSphere parametern multipliceras sedan med flyttals parametern “MaxRoomSpawningRange” vilket ger den initiala slumpmässiga tredimensionella positionen som ett skapat rum tilldelas, se Figur 31.
