Redogörelse för utvecklingsprocessen av spelet The Legend of Chalmers

Redogörelse för utvecklingsprocessen av spelet The Legend of Chalmers Ett projekt i kursen TDA367 Objektorienterat programmeringsprojekt och LSP310 Kommunikation och ingenjörskompetens Maxim Goretskyy Kevin Hoogendijk Alexander Håkansson Alexander Karlsson

SAMMANDRAG Underhållning är en stor del av dagens samhälle och ett spel har i många fall uppfyllt människors behov av just underhållning. Detta spel har skapats utifrån ett sådant behov och rapporten redogör för utvecklingen av ett sådant spel. Olika utvecklingsmetoder, verktyg och ramverk har använts genom projektet för att skapa ett så bra spel och kodstruktur som möjligt. Resultatet är ett tvådimensionellt spel där spelaren vandrar omkring på Chalmers campus Johanneberg och gör olika aktiviteter. En del slutsatser dras kring utvecklingsprocessen och om dem ramverk som använts - hur de fungerat tillsammans och med olika utvecklingsmetoder.

INNEHÅLLSFÖRTECKNING 1 INLEDNING... 1 1.1 Bakgrund... 1 1.2 Mål... 1 1.3 Syfte... 1 2 TEORI... 2 2.1 Agil utveckling... 2 2.2 Designmönstret Model-View-Controller... 2 2.2.1 Aktiv MVC... 2 2.2.2 Passiv MVC... 2 2.3 Designmönstret Observer... 2 3 UTVECKLINGSVERKTYG... 3 3.1 Spelramverket libgdx... 3 3.2 Kartverktyget Tiled... 3 3.3 Testningsramverket JUnit... 3 4 METOD... 4 5 RESULTAT... 5 5.1 Spelets beståndsdelar... 5 5.1.1 Campus... 5 5.1.2 Karaktärer... 5 5.1.3 Föremål... 6 5.1.4 Minispel... 6 5.2 Kodstruktur... 7 5.2.1 Passiv MVC... 7 5.2.2 Enkel utvidgning av spelet... 7 5.2.3 Byte mellan minispel och huvudspel... 7 6 DISKUSSION... 8 7 SLUTSATS... 9 KÄLLFÖRTECKNING... 10 APPENDIX... 11 1 Figurer... 11

1 INLEDNING I dagens samhälle finns otroligt många sätt att hitta underhållning. Detta både i den fysiska världen men numera även digitalt. På Chalmers tekniska högskola är underhållningen knappast bristfällig, det finns alltid en fest eller sittning att gå på, föreningsaktiviteter att delta i eller föreläsningar att lyssna på. Det som det däremot finns en tydlig brist på är den digitala underhållningen - något som måste ses som underligt med tanke på Chalmers status som tekniskt universitet. Att göra något åt denna uppenbara brist känns därmed lockande. Spel är idag en populär form av underhållning, att skapa ett spel verkar därmed som ett vinnande koncept. 1.1 Bakgrund Utbudet av datorspel är idag mycket stort och för att kunna skilja sig från mängden krävs en unik produkt. Ett koncept i den hårda konkurrensen är att blanda tidigare beprövade spelmekanismer i en miljö där spelaren känner igen sig. För detta krävs en nischad publik som spelet kan anpassas efter. Chalmers studenter har länge saknat ett spel där de kan identifiera sig med spelets karaktärer, händelser och värld. The Legend of Chalmers skapas för att fylla detta hål i chalmersstudenternas spelbibliotek. Med autentiska miljöer, ljud och aktiviteter kommer varje student såväl som alumn känna sig som hemma på spelets digitala campus. 1.2 Mål Målet med spelet var att skapa ett spel som chalmerister skulle kunna relatera till. Detta mål skulle uppnås genom att skapa en autentisk miljö där spelaren fritt skulle kunna gå omkring på campus Johanneberg. Det skulle även vara möjligt att interagera med olika föremål och personer på campus samt kunna delta i olika minispel där karaktäristiska chalmeristaktiviteter återskapas. 1.3 Syfte Rapporten redogör för utvecklingsprocessen av spelet The Legend of Chalmers samt resultatet av denna process. Problem i samband med design och implementation som förekommit tas upp och diskuteras. Lösningarna som används för dessa problem redogörs för och motiveras. 1

2 TEORI I spelutveckling är det av stor vikt att skriva bra kod - det vill säga kod som är effektiv, enkel att förstå och enkel att underhålla. För att skriva bra kod används därför utarbetade och väl testade metoder. Det har även använts i det här projektet. 2.1 Agil utveckling Agil utveckling är ett begrepp och en modell för hur utvecklingen av mjukvaruprojekt ska gå till. I agil utveckling ligger fokusen på små iterationer av utveckling (von Hacht, 2015). Ett användningsområde designas och implementeras fullständigt innan utvecklarna går vidare till nästa. Fördelen med den utvecklingsmodellen är att det snabbt går att utvärdera hur bra ett användningsområde är implementerat på så sätt att det enkelt går att göra om (von Hacht, 2015). Det iterativa tänket är det som skiljer sig störst från andra utvecklingsmodeller (von Hacht, 2015). 2.2 Designmönstret Model-View-Controller MVC (Model-View-Controller) är ett designmönster inom systemutveckling. Huvudsyftet med designmönstret är att designa applikationen i tre huvuddelar: modell, vy och controller. Modellen är den modul som innehåller all logik, vyn är den grafiska representationen av modellen och controller-modulen kan bäst beskrivas som den komponent som dirigerar information mellan vyn och modellen (Skrien, 2009). Målet med MVC är att dessa tre moduler ska vara så oberoende av varandra som möjligt (Skrien, 2009). Detta för att lätt kunna byta ut en del mot en annan utan att behöva ändra i de övriga modulerna. MVC kan delas upp i två olika typer av implementation: aktiv och passiv (Burbeck, 1992). 2.2.1 Aktiv MVC I aktiv MVC har modellen mer betydande och aktiv roll för flödet av information. Programmets flöde (Se figur 2.1) består av att controller-modulen uppdaterar modellen när exempelvis användaren ger direktiv till programmet och att modellen själv notifierar vyn om att den har uppdaterats. Vyn hämtar då informationen från modellen och uppdaterar sig själv och skickar sedan förfrågningar till controller-modulen (Burbeck, 1992). 2.2.2 Passiv MVC I passiv MVC är modellen inte betydande för informationsflödet. Det fungerar nästan på samma sätt som aktiv MVC, men skillnaden är att modellen inte säger till vyn när den har uppdaterats (Se figur 2.2). Istället är det controller-modulens jobb att notifiera vyn att den har uppdaterat modellen. Bara då hämtar vyn informationen från modellen, uppdaterar sig själv och skickar förfrågningar till controller-modulen (Burbeck, 1992). 2.3 Designmönstret Observer Syftet med designmönstret observer är att möjliggöra kommunikation dynamiskt mellan flera parter. Att det ska ske dynamiskt syftar på att mottagaren inte ska behöva fråga efter information, utan informationen kommer skickas när den är tillgänglig. Designmönstret implementeras vanligen i Java med hjälp av ett lyssnar-gränssnitt som fungerar som mottagare och en avsändare som har en referens till lyssnaren (Skrien, 2009). 2

3 UTVECKLINGSVERKTYG Vid utvecklingen av spelet användes flertalet utvecklingsverktyg för att förenkla och förbättra både arbetsflödet och kvaliteten på slutprodukten. Dessa utvecklingsverktyg har spelat en avgörande roll för The Legend of Chalmers då mycket av grundfunktionaliteten möjliggörs genom exempelvis ramverket libgdx. 3.1 Spelramverket libgdx libgdx är ett visualiseringsramverk som är skrivet i Java. libgdx har stöd för flera plattformar, bland annat Windows, OS X, ios, Linux, Android och HTML5 (libgdx, 2015a). libgdx är byggt på ramverket LWJGL som använder grafikgränssnittet OpenGL ES 2.0 (libgdx, 2015a). En applikation som använder libgdx har alltid universala klasser som utgör själva programmet men med särskilda huvudklasser som anpassas för olika plattformar. Huvudklassen tar in en klass som implementerar libgdx-gränssnittet ApplicationListener. I denna klass finns bl.a. tre viktiga metoder för skapning, utritning samt rensning. Figur 3.1 beskriver applikationens livscykel vid användning av libgdx. I korta drag så skapar skapningsmetoden spelet och laddar in libgdx-biblioteket, medan utritningsmetoden repeteras efter skapningsmetoden så ofta den behöver för att rita ut grafiken till spelet. Rensningsmetoden används för att rensa minne och körs en gång när programmet stängs av. 3.2 Kartverktyget Tiled Kartverktyget Tiled Map Editor är ett verktyg för att skapa kartor till spel (Tiled, 2015). Spelramverket libgdx har inbyggt stöd för Tiled vilket gör det enkelt att ladda in en karta och rita ut den i spelet. Kartan bygger på ett antal lager som i sin tur bygger på ett antal rutor. Varje ruta har en textur/animation samt egenskaper som kan sättas och läsas. Egenskaper kan hämtas i libgdx och användas i spelet (libgdx, 2015b). 3.3 Testningsramverket JUnit JUnit är ett ramverk med öppen källkod för enhetstestning i Java. Ramverket baseras på automatiserade tester för varje enhet av koden (JUnit, 2014). Med välskrivna testklasser går det att längre fram i tiden snabbt göra ändringar och direkt upptäcka eventuella fel och hur dessa påverkar andra delar av koden. JUnit är det vanligaste verktyget för testdriven utveckling i Java (Weiss, 2013). 3

4 METOD Utvecklingen av spelet följde agil utveckling. I början av projektet gjordes en preliminär kravspecifikation där flera användningsområden specificerades. Dessa användningsområden kallas use cases i diskussion kring agil utveckling. Ett use case är funktionalitet som går att utveckla självständigt från början till slut. Varje användningsområde ges en prioritering relativt varandra. Förutom att prioritera olika use case gjordes även valet att helt fokusera på att göra klart modelldelen i MVC strukturen först. Varje use case skulle först implementeras rent logikoch datamässigt innan den grafiska representationen slutligen lades till. När initiala prioriteringar och beslut fanns påbörjades det iterativa arbetet med att implementera användningsområdena. Det som prioriterades högst och därför implementerades först var spelkartan som skulle innehålla all logik om vad som fanns var och vad som gick att göra i spelet. När spelkartan var färdigimplementerad innebar det även att självaste fundamentet för spelet var implementerat. Detta möjliggjorde för ett mer uppdelat arbete där flera användningsområden kunde utvecklas parallellt. Då modellen började bli färdig påbörjades arbetet med vyn och controller-modulen (sett ur ett MVC-perspektiv). För den grafiska representationen av spelet (vyn) gjordes designvalet att använda spelramverket libgdx. Användningen av libgdx innebar att en speciell design av koden krävdes för att skapa tydlig struktur. Precis som med utvecklingen av modellen skedde implementationen av controller-modulen och vyn iterativt. Då libgdx användes implementerades även controller-modulen med hjälp av libgdx-klasser. Vyn designades så att majoriteten av modell-klasserna hade en motsvarighet i vyn. Detta innebar att varje vy hade en referens till en modellmotsvarighet och använde den informationen kombinerat med grafiskt relaterade uppgifter för att självständigt rita ut det modellen representerade. Då projektet närmade sig sitt slut och alla viktiga användningsområden var implementerade skiftades fokus till att fixa till smådetaljer. Detta innebar till största del att åtgärda småfel och ändra av mindre detaljer. I mån av tid implementerades även fler minispel som spelet bygger kring. 4

5 RESULTAT The Legend of Chalmers är ett tvådimensionellt spel med Chalmersinspirerade miljöer och aktviteter. Spelet är skrivet i Java och följer grundläggande designmönster såsom Model- View-Controller. 5.1 Spelets beståndsdelar The Legend of Chalmers utspelar sig på Chalmers campus Johanneberg och spelarens mål är att ta examen genom att lyckas få 300 högskolepoäng. Högskolepoäng fås framförallt genom att spela olika minispel och använda föremål som finns utplacerade på campus. 5.1.1 Campus Campus utgör spelets kärna och det är härifrån spelaren navigerar och interagerar för att nå andra delar av spelet. Campus är designat för att i så hög grad som möjligt efterlikna Chalmers verkliga campus i Johanneberg, Göteborg. På campus finns karaktärer och föremål utspridda, som användaren kan utnyttja för att komma längre i spelet. Figur 5.1, Campus i The Legend of Chalmers 5.1.2 Karaktärer Spelet har ett flertal olika karaktärer som grovt kan delas upp i två typer av karaktärer, icke spelbara karaktärer och spelare. Dessa har många saker gemensamt och delar merparten av sin kod i en gemensam abstrakt Java klass. Huvudkaraktären i spelet är spelaren. Denna karaktär kontrolleras av användaren och har möjligheter att interagera med sin omgivning. Varje användare styr en spelare och då spelet idag bara har stöd för en användare har spelet endast en sådan karaktär, dock finns förutsättningar för vidareutveckling av spelet där flera användare kan interagera med varandra. 5

Icke spelbara karaktärer styrs av programmet och kan inte kontrolleras av användaren. Dessa karaktärer är användarens primära interaktionsmöjlighet. Samtliga icke spelbara karaktärer har dialoger, dessa dialoger initieras av användaren och kan i vissa fall avslutas med en möjlighet att starta ett minispel eller få ett föremål av karaktären. 5.1.3 Föremål Föremål finns utplacerade på campus och kan plockas upp av användaren genom att gå över detta föremål. Möjligheten att i koden skapa icke spelbara karaktärer med föremål som kan ges till en spelare finns, men används dock inte i den nuvarande versionen av spelet. Alla föremål som finns i nuvarande version ger spelaren högskolepoäng direkt då de plockas upp och utöver detta ändras ingenting men även här finns outnyttjade möjligheter i koden, stöd finns för föremål som kan plockas upp och sparas för senare användning och föremål kan modifiera i princip alla delar av spelet. 5.1.4 Minispel Minispel är mindre spel som kan startas antingen genom att användaren navigerar till en bestämd del av campus eller genom att starta en dialog med en icke spelbar karaktär som startar spelet. Minispelen är i princip helt fristående från övriga koden, varje minispel måste dock implementera ett gemensamt gränssnitt som kräver en vy- och kontrollklass som implementerar libgdx-anpassade gränssnitt för detta. Utöver detta krävs att huvudspelet meddelas när minispelet är slut och att ett betyg kan hämtas från det avslutade spelet, även detta specificeras i gränssnittet. Ett minispel kan således vara hur simpelt eller komplicerat som helst, under förutsättning att den uppfyller ovan beskrivna krav. De minispel som utvecklats till nuvarande version av spelet som kan ses i figur 5.2 är av varierande kodkomplexitet men har alla en liknande relativt simpel struktur som endast består av de av gränssnittet definierade klasserna, en modellklass och ibland enstaka hjälpklasser. Ett betyg (U, 3, 4, 5) beräknas beroende på användarens prestation i minispelet men hur dessa genereras sköts internt i varje minispel. Efter ett avslutat minispel omvandlas betyget till högskolepoäng där högre betyg innebär högre antal poäng. Användaren har möjlighet att förbättra sitt betyg i efterhand och få fler högskolepoäng, användaren får dock inte fler poäng om ett nytt betyg inte är bättre än ett tidigare I minispelet Øhlhäfv är målet att på kortast tid möjligt häva en flaska öl på traditionellt Chalmers vis. Betyget beror på tiden och är bättre ju kortare tid det tar för användaren att avsluta sitt häv. Minispelet Caps är en variant av det på Chalmers populära dryckesspelet Caps. Målet är att träffa ett glas öl med en kapsyl så många gånger som möjligt. Svårigheten ökar successivt ju längre användaren kommer i spelet. 6

I minispelet Cortège är det målet att samla så många poäng som möjligt på en viss tid genom att plocka fallande verktyg i en verktygslåda. Minuspoäng fås då föremål som inte är verktyg plockas. Figur 5.2, Minispel fr.v: Caps, Øhlhäfv, Cortège 5.2 Kodstruktur Projektets kod har utformats utifrån väl etablerade designmönster och programmeringspraxis. Detta för att så gott som möjligt garantera kvaliteten på projektet i form av flexibilitet och prestanda samt för att koden ska bli överskådlig och enkel att förstå. 5.2.1 Passiv MVC Koden använder sig av en passiv MVC modell. Det finns en toppvy som implementerar gränssnittet Screen från libgdx, alla klasser som implementerar detta gränssnitt har en metod för att rita ut texturer, denna metod kallas automatiskt flera gånger per sekund av ägaren till klassen vilket i detta fall är huvudklassen LocMain. Vyn meddelas aldrig när modellen uppdateras utan ritar kontinuerligt ut modellens nuvarande status. Se figur 5.3 för översikt av projektets kodstruktur. 5.2.2 Enkel utvidgning av spelet Som tidigare nämnt är spelet enkelt att bygga ut med ny funktionalitet. Vyerna bygger på ett gränssnitt vilket gör att alla vyer kan hanteras på samma sätt. Det finns även en del funktionella klasser som innehåller metoder vilka används i flera delar av projektet, till exempel vid inläsning av filer och representation av position. Detta innebär att det går att återanvända funktionalitet vid utvidgning av spelet. 5.2.3 Byte mellan minispel och huvudspel Alla minispelens vyer samt huvudspelets vy implementerar ett Java gränssnitt som gör det enkelt för libgdx ramverket att byta vilken vy som syns. För att i spelet byta från huvudspelet till ett minispel behöver därför något metodanrop ske upp till huvudklassen i spelet. Detta genomförs med hjälp av designmönstret Observer (Skrien, 2009). 7

6 DISKUSSION Vid implementationen av spelet The Legend of Chamers uppstod flertalet frågeställningar och problem som behövde lösas. Majoriteten av dessa problem relaterar till faktumet att spelramverket libgdx använts. libgdx fungerar på så sätt att ramverket så ofta som möjligt försöker uppdatera och rita ut grafiken på skärmen. Detta innebär att libgdx utritningsmetod i Java körs väldigt ofta. Med det i åtanke är det obefogat att ha aktiv MVC i projektet. Varken prestandan eller utritningshastigheten skulle förbättras om modellen skulle notifiera vyn - det skulle endast bli överflödigt och onödigt komplext. Därför har passiv MVC valts i designen av spelet. I början av projektet beslutades att fokusera helt på implementation av modellen innan vyn blandades in. Beslutet grundar sig i det faktum att man skalar bort komplexiteten som medföljer vid programmering av grafiska gränssnitt - det i sin tur leder till ett ökat fokus på korrekthet och långsiktig bra design. Beslutet kan i efterhand ses som mycket lyckat då det blev väldigt enkelt att lägga på det grafiska i efterhand med en så komplett modell. Ytterligare en fördel med att ha stort fokus på att implementera modellen först är testningen. Då man implementerar modellen först går det att testa den helt innan utvecklingen går vidare till vyn. 8

7 SLUTSATS De slutsatser som direkt kan dras är bland annat att det bästa sättet att implementera MVC i en applikation baserad på libgdx är att följa principerna för passiv MVC. I övrigt kan projektet ses som lyckat då målet med spelet helt uppfyllts. 9

KÄLLFÖRTECKNING Burbeck S., (1992), Applications Programming in Smalltalk-80(TM): How to use Model- View-Controller (MVC), Hämtad från http://st-www.cs.illinois.edu/users/smarch/stdocs/mvc.html JUnit, (2014), Frequently Asked Questions, Hämtad 20 maj 2015 från JUnit, http://junit.org/faq.html libgdx, (2015a), Goals and Features, Hämtad från: http://libgdx.badlogicgames.com/features.html libgdx, (2015b), libgdx Wiki, Hämtad från: https://github.com/libgdx/libgdx/wiki Skrien D., (2009), Object-Oriented Design Using Java, McGraw-Hill, New York Tiled, (2015), Tiled map editor, Hämtad från: http://www.mapeditor.org/ Von Hacht J., (2015), Software Development Overview, Hämtad från http://www.cse.chalmers.se/edu/course/tda367/lect/1_se_development_overview.pdf Weiss T., (2013), We Analyzed 30,000 GitHub Projects: Here Are The Top 100 Libraries in Java, JS and Ruby, Hämtad 20 maj 2015 från Takipi, http://blog.takipi.com/we-analyzed- 30000-github-projects-here-are-the-top-100-libraries-in-java-js-and-ruby/ 10

APPENDIX 1 Figurer Figur 2.1, Aktiv MVC (Hämtad från CodeProject, (u.å), http://www.codeproject.com/articles/674959/mvc-patterns-active-and-passive-model-andits) Figur 2.2, Passiv MVC (Hämtad från CodeProject, (u.å), http://www.codeproject.com/articles/674959/mvc-patterns-active-and-passive-model-andits) 11

Figur 3.1, Spelramverket libgdx livscykel (Hämtad från GitHub, (2015), https://github.com/libgdx/libgdx/wiki/the-life-cycle) 12

Figur 5.3, Överblick av kodstrukturen i The Legend of Chalmers 13