Utvecklingsverktyg För Spelmotor Kandidatuppsats

Utvecklingsverktyg för spelmotor Kandidatuppsats

15 juni 2014 Sammanfattning

Detta arbete utvärderar huruvida Netbeans RCP är en lämplig plattform att bygga en kampanjredigerare för en spelmotor på. Arbetet är en del av ett större projekt där en spelmotor för Androidtelefoner skapas. Kampanjredigeraren ska kunna skapa och redigera filer i XML-format som spelmotorn använder. Den ska även kunna skapa nytt material till spelmotorn utifrån bilder. Allt detta ska fungera på flera operativsystem. Valet att använda en plattform istället för att implementera allt manuellt skedde för att påskynda utvecklingen och höja kvaliteten på programmet. Utöver Netbeans RCP gjordes en översiktsgranskning av andra plattformar och program för att se om dessa också hade kunnat vara lämpliga. Netbeans RCP visade sig vara lämpligt för att skapa kampanjredigeraren på då den tillhandahöll funktioner relevanta för kampanjredigeraren som gick att använda på flera operativsystem och programmets implementerade funktionalitet fungerade på alla testade operativsystem.

Nyckelord: Netbeans RCP, Java, kartredigerare, kampanjredigerare, kartredigerare, tile, campaign editor, map editor, level editor Abstract

This paper examines if Netbeans RCP is a suitable platform for creating a campaign editor for a game engine on. The work is part of a larger project where a game engine for Android phones is being developed. The campaign editor must be able to modify and create ﬁles in an XML-format that the engine will then use. It must also be able to create new material for the engine from images. All of this functionality must be usable on multiple operating systems. The decision to use a platform rather than implement everything manually was made to speed up the development and increase the quality of the campaign editor. Other platforms and programs were also brieﬂy examined to see if these could have been suitable as well. Netbeans RCP was determined to be a suitable platform for creating a campaign editor because it provides functions relevant to the campaign editor that are usable on multiple operating systems, and the functionality implemented in the program was usable on every tested operating system.

Keywords: Netbeans RCP, Java, tile, campaign editor, map editor, level editor Förord

Tack till Erik Björnerhag och Daniel Warsén för deras förslag, kritik, synpunkter och hjälp med utvärderingen. Tack till Leif Lindbäck och Fredrik Lundevall för kritik, förslag och handledning.

1 Innehåll

1 Terminologi 3

2 Introduktion 4 2.1 Övergripande syfte ...... 4 2.2 Problembeskrivning ...... 5 2.3 Konkreta krav ...... 5 2.4 Avgränsningar ...... 6 2.5 Rapportstruktur ...... 6

3 Tidigare arbeten 8 3.1 Utvärdering av plattformar för tunga Java-klienter ...... 8

4 Teori 9 4.1 Resultat av litteraturstudien ...... 9 4.2 Plattformar och liknande verktyg till spel ...... 9 4.2.1 The battle for Wesnoth ...... 9 4.2.2 Wesnoth UMC Development IDE ...... 10 4.2.3 Eclipse RCP ...... 10 4.2.4 Netbeans RCP ...... 10 4.2.5 Spring RCP ...... 10 4.3 Val av plattform ...... 10 4.4 Begrepp ...... 11 4.5 Programmets funktionalitet ...... 11

5 Metod 13

6 Konstruktion 15

7 Resultat 19

8 Slutsats 22 8.1 Diskussion ...... 22 8.2 Konsekvensanalys ...... 24 8.3 Framtida arbete ...... 24

2 Kapitel 1

Terminologi

Netbeans RCP En Java-baserad plattform som bland annat tillhandahåller funktioner och abstraktioner för graﬁska komponenter.[1] Ubuntu En Linuxdistribution. GUI Graphical User Interface, graﬁskt användargränssnitt. XML Extensible Markup Language, ett uppmärkningsspråk för strukturerad textdata.[2] RCP Rich Client Platform, en plattform som tillhandahåller funktioner och abstraktioner för utveckling och körning av program på en lokal dator.

3 Kapitel 2

Introduktion

Arbetet är en del av större projekt där en spelmotor utvecklas, denna ska kunna köra olika spel på mobiltelefoner med operativsystemet Android. Tanken är att användare ska kunna skapa eget material (egna spel) som spelmotorn sedan kör på telefonen. Spelmotorn är för närvarande under utveckling, arbetet är en del av utvecklingen av denna och ska utvärdera huruvida en plattform som har föreslagits är lämplig för att skapa en kartredigerare. Materialet (spelen) som skapas till spelmotorn är turordningsbaserade tak- tikstridsspel. Spelaren går igenom en serie med scenarier där denne ska övervinna en eller flera motståndare för att ta sig nästa scenario. Spelplanen är uppbyggd av flera kvadrater som är placerade bredvid varandra, dessa kvadrater ses rakt ovanifrån. Spelmotorn läser filer i XML-format (Extensible Markup Language, ett uppmärkningsspråk för strukturerad textdata.[2]) och skapar sedan spelet utifrån dessa.

2.1 Övergripande syfte

Syftet är att utröna huruvida Netbeans RCP1[3] är en lämplig plattform att utveckla ett verktyg som låter användare skapa sitt eget material till spelmotorn, en så kallad kampanjredigerare eller ”campaign editor”. Utöver detta ska övriga utvecklare kunna använda kampanjredigeraren för att skapa exempeldata för att testa om spelmotorn uppför sig som förväntat. Jag hoppas även att kampanjredigeraren ska utvecklas i takt med att spelmotorn utvecklas och får nya funktioner, kanske även av andra utvecklare i framtiden. Slutligen hoppas jag att kampanjredigeraren blir lyckat och låter användare skapa eget material utan större svårigheter, och att det i och med detta bidrar till att göra spelmotorn populär och lyckad.

1En Java-baserad plattform som bland annat tillhandahåller funktioner och abstraktioner för graﬁska komponenter.

4 2.2 Problembeskrivning

Spelmotorn är för tillfället tidigt i utvecklingsstadiet, men till dess lansering behövs ett verktyg som kan skapa material som motorn kör för att skapa ett spel, en kampanjredigerare. Användare av spelmotorn antas inte ha kunskap eller vilja att manuellt redigera datafiler eller använda kommandoradsverktyg för att skapa materialet, därför behövs kampanjredigeraren. Kampanjredigeraren ska erbjuda ett grafiskt gränssnitt som tillåter användare skapa och redigera alla aspekter som material tillåts innehålla. Tanken är även att kampanjredigeraren ska användas av övriga utvecklare av spelmotorn för att få fram exempeldata, som de kan använda för att verifiera att motorn fungerar korrekt. För att påskynda utvecklingen och öka kvaliteten av kampanjredigeraren kommer existerande plattformar och verktyg som antingen tillhandahåller all eller delar av funktionaliteten som krävs, eller plattformar som underlättar utvecklingen av grafiska gränssnitt, exempelvis GUI-komponenter, att användas. Netbeans RCP hittades som en möjlig plattform att bygga kampanjredigeraren på, därför ska det utvärderas huruvida denna är en lämplig plattform att bygga kampanjredigeraren på. Det kan även finnas andra lämpliga plattformar eller program, dessa ska undersöaks för att se utifall någon av dem verkar erbjuda bättre funktionalitet än Netbeans RCP, i så fall bör denna plattform eller program utvärderas istället.

2.3 Konkreta krav

För att plattformen (Netbeans RCP) ska anses lämplig krävs följande: Plattformen ska erbjuda abstraktioner och funktioner för grafiska gränssnitt, exempelvis grafiska komponenter Av egen erfarenhet tenderar GUI2-kod att kräva väldigt mycket tid och arbete för att producera ett bra och enhetligt resultat. Genom att använda en plattform som förenklar detta hoppas jag att kunna minska mängden arbete som krävs, höja kvaliteten på gränssnittet och påskynda utvecklingen. Programmet ska kunna redigera alla aspekter av materialet spelmotorn kan spela upp En användare ska inte behöva manuellt redigera datafiler för att producera fungerande material, går inte detta att uppnå är plattformen otillräcklig. Alla funktioner ska fungera på både Windows 7 och Ubuntu3 Linux En funktion anses fungera om den producerar avsett resultat. Målet är att användare ska kunna skapa material även om de inte använder Windows. Programmet ska erbjuda en grafisk vy för att redigera spelmotorns datafiler på Windows 7 och Ubuntu Linux Alla funktioner som implementeras grafiskt ska kunna användas grafiskt oavsett operativsystem, potentiella användare förutsätts inte ha kunskaper eller intresse av att använda kommandoradsverktyg.

2Graphical User Interface, graﬁskt användargränssnitt.

5 Programmet ska kunna känna igen en mapp med ett visst filin- nehåll som ett projekt Detta för att användare enkelt ska kunna hitta och känna igen spelmotorns datafiler på hårddisken via programmet. Programmet ska kunna läsa in grafiskt material från bilder och skapa nya resurser utifrån dessa Användare måste kunna skapa nya grafiska resurser som sedan kan använ- das till materialet denne skapar eftersom själva spelmotorn inte nödvän- digtvis innehåller allt grafiskt material som en användare vill ha. Programmet ska kunna spara det som användaren har skapat med programmet Filerna som sparas måste följa strukturen som spelmotorn använder. Programmet ska kunna öppna tidigare skapat material Användare måste kunna vidareutveckla befintligt material.

2.4 Avgränsningar

Programmet ska inte redigera bilder, video eller ljud Det ﬁnns redan program som gör detta, sådan funktionalitet överlåts till dessa. Windows 7 och Ubuntu Linux är de operativsystem som programmet ska testas på Jag har tillgång och erfarenhet av dessa operativsystem. Det skulle vara en fördel att testa på ﬂer plattformar, men jag har inte tillgång till alla olika operativsystem och detta riskerar att ta för lång tid. Detta utesluter inte att programmet testas på andra operativsystem av andra personer. Ingen hänsyn tas till huruvida programmet fungerar på Windows XP Microsoft har upphört att ge support för detta operativsystem[4]. Ingen hänsyn tas till användarvänlighet Det är inte syftet med det här arbetet att skapa och utvärdera ett använ- dargränssnitt.

2.5 Rapportstruktur

Avsnitt ”2 Introduktion” går igenom varför arbetet utfördes, vad för krav som ställdes på arbetet och vad för avgränsningar som gjordes. Avsnitt ”3 Tidigare arbeten” går igenom tidigare arbeten relevanta för detta arbete. Avsnitt ”4 Teori” tar upp resultatet av tidigare arbeten, visar alternativa plattformar och program som skulle kunnat användas. Det förklarar valet av plattform och tydliggör begrepp som används i arbetet samt förtydligar vad som förväntas av programmet. Avsnitt ”5 Metod” beskriver och motiverar hur arbetet har utförts, vilka metoder som har använts för att få fram ett resultat. Avsnitt ”6 Konstruktion” visar hur programmet är upbbyggt och vilka kod- ningsstandarder som har använts.

6 Avsnitt ”7 Resultat” listar vilka resultat som har framkommit när metoden har applicerats på arbetet. Avsnittet ”8 Slutsats” diskuterar resultaten som framkommit under arbetet och ger förslag på vad för arbete som kan utföras i framtiden.

7 Kapitel 3

Tidigare arbeten

Endast ett relevant arbete har hittats. Flertalet arbeten nämner Netbeans RCP eller andra ramverk i förbigående, men ingen djupare analys eller jämförelse mot något annat sker. Inga relevanta arbeten som handlade om utveckling av kart- eller kampanjredigerare hittades. Arbeten har sökts med hjälp av DIVA, Google Scholar och webbaserade sökmotorer.

3.1 Utvärdering av plattformar för tunga Java- klienter

Arbetet ”Utvärdering av plattformar för tunga Java-klienter” jämförs två ramverk, Eclipse RCP och Spring RCP.[5] Arbetet har andra krav än detta arbete, men det tar upp en del GUI-funktioner (sida 25-28). Även hur menyer hanteras i respektive plattform gås igenom och jämförs (sida 31-37). Arbetet jämför GUI- abstraktionerna Swing med SWT och JFace, och går in i viss detalj om hur man använder dessa abstraktioner på respektive plattform. Arbetet kommer fram till att utifrån dess krav är Spring RCP det bättre ramverket. Eftersom kraven som ställs i det arbetet skiljer sig från kraven i detta arbete krävs ytterligare under- sökning av plattformarna.

8 Kapitel 4

Teori

Nedan presenteras resultatet av litteraturstudien samt genomgången av liknande program och plattformar. Utöver detta kommer vissa begrepp att förklaras, vad för funktioner programmet behöver ha, samt en kort förklaring av hur plattformen som används fungerar.

4.1 Resultat av litteraturstudien

I arbetet ”Utvärdering av plattformar för tunga Java-klienter” beskrivs två plattformar med GUI- och menyfunktioner, Spring RCP och Eclipse RCP. Även om mina krav skiljer sig ifrån de som listas i det arbetet anser jag det lämpligt att undersöka dessa ramverk närmare, för att se om dessa har funktionalitet som är intressant för även detta arbete.

4.2 Plattformar och liknande verktyg till spel

Jag har undersökt vilka andra spelverktyg och plattformar som gör ungefär vad jag efterfrågar och som kan vara lämpliga som alternativ till Netbeans RCP. Plattformarna har hittats genom att studera tidigare arbeten och att använda webbaserade sökmotorer. Om någon av plattformarna eller programmen som hittas här bedöms ha starka fördelar gentemot Netbeans RCP kommer den plattformen eller programmet att utvärderas istället.

4.2.1 The battle for Wesnoth Spelet The battle for Wesnoth, hädanefter förkortat Wesnoth, liknar spelmotorn i flera avseenden. Wesnoth är turordningsbaserat och låter spelaren spela igenom olika scenarier i en kampanj där spelaren strider mot en eller flera motståndare. Wesnoths källkod finns att tillgå under öppen källkod-licens.[6] Wesnoth tillåter spelare att skapa eget material och spela detta. Spelet har en inbyggd kartredigerare, men denna är begränsad till att redigera själva spelplanen och viss övrig data, inte övrig logik som krävs för att skapa en kampanj.[7][8] Wesnoth fungerar på de plattformar som min kampanjredigerare är tänkt att köras på (och fler).

9 Wesnoth lagrar inte sin data i XML, istället används ett format som kal- las för Wesnoth Markup Language (WML).[9] Wesnoth och dess kartredigerare använder sig av hexagoner istället för kvadrater som spelmotorn som utvecklas gör, om Wesnoths kartredigerare skulle användas kräver detta att den görs om så att den använder kvadrater. Wesnoth är skrivet i C++, detta är en nack- del då spelmotorn skrivs i Java, om spelmotorn och verktygen kring denna är skrivna i samma språk kan kod delas mellan dessa.

4.2.2 Wesnoth UMC Development IDE The Battle for Wesnoth erbjuder även ett separat verktyg vid namn ”The Battle for Wesnoth UMC Development IDE”. Detta påstås ha fler funktioner för att redigera fler aspekter av Wesnoths dataformat.[10] Jag kan inte hitta något sätt att få tag på källkoden under en licens som tillåter modifikation, jag har därför inte gjort någon närmare undersökning av programmet.

4.2.3 Eclipse RCP Eclipse RCP (Rich Client Platform) är en plattform för att skapa nya program ovanpå.[11] Eclipse RCP innehåller biblioteket JFace som tillhandahåller vissa GUI- komponenter som utvecklare kan använda.[12] JFace är baserat på Standard Widget Toolkit[13] (SWT), ett abstraktionslager för underliggande operativsy- stemets GUI-funktionalitet.[14]

4.2.4 Netbeans RCP Netbeans RCP är likt Eclipse RCP en plattform som program kan skapas ovanpå[15]. Netbeans RCP använder Swing.[16]

4.2.5 Spring RCP Jag kan inte hitta någon tillförlitlig information om detta ramverk.

4.3 Val av plattform

Efter att ha studerat programmen och plattformarna ovan har jag valt att fort- sätta undersökningen av Netbeans RCP. Det finns flera anledningar till detta, Wesnoth valdes bort eftersom den inbyggda kartredigeraren är inte komplett och skulle behöva utökas och anpassas för att passa våra behov, dataformatet är för olikt för att snabbt kunna skapa konverteringsverktyg. Därtill skulle ett användande av Wesnoths verktyg tvinga oss att inför varje ny version av dessa kontrollera att deras ändringar inte är inkompatibla med våra förändringar, alternativt underhålla en egen separat version av deras verktyg. Wesnoth UMC Development IDE valdes bort eftersom jag inte kan hitta något sätt att få tag i källkoden under en licens som tillåter modifiering. Således kan inte produkten utvecklas om våra behov ändras. Eclipse RCP valdes bort eftersom jag och andra i projektet har tidigare erfarenhet av Netbeans, detta underlättar användandet av plattformens verktyg. Netbeans innehåller även en GUI-byggare som standard[17] som jag har viss

10 erfarenhet av, till Eclipse ﬁnns det en separat GUI-byggare att hämta från deras webbplats[18], men den har jag ingen erfarenhet av. Spring RCP valdes bort då jag inte kan hitta någon tillförlitlig information eller dokumentation om ramverket.

4.4 Begrepp

Nedan förklaras begrepp som används i samband med programmet och spelmotorn.

Tile En tile är en kvadrat med ett grafiskt innehåll med ett namn. Dessa utgör terrängen, eller spelplanen, som visas för spelaren när spelmotorn spelar upp en kampanj. Exempel på tiles är en gräsplätt eller en stig. Det grafiska innehållet i en tile hämtas från ett visst område på en bild. Tilesheet Ett tilesheet är en samling med tiles med ett namn. Dessa används för att dela upp tiles i logiska samlingar, så att spelmotorn inte behöver läsa in varenda tile som finns tillgänglig, enbart de tilesheets som har deklarerats som nödvändiga. Levelmap En levelmap är en representation av kartan som visas i spelmotorn, vilka dimensioner den har, vilka koordinater tiles ligger på, vilka startpositioner som finns och vilka områden som spelkaraktärer inte kan beträda. Scenario Ett scenario representerar ett uppsättning med mål en spelare måste uppfylla för att gå vidare i spelen som skapas till spelmotorn. Kampanj En kampanj är en samling med scenarion. Den innehåller även extrainfor- mation som vem som skapat kampanjen och en beskrivning om vad den handlar om. En kampanj är synonymt med ett spel skapat för spelmotorn.

4.5 Programmets funktionalitet

Nedan presenteras funktioner som programmet behöver uppfylla för att bli an- vändbart, dessa ingår i kravet om att alla aspekter av en kampanj ska kunna redigeras. Det är inte en komplett uppräkning av allt som går att förändra i en kampanj, tanken är att ge en bild av det som behöver finnas med för att programmet över huvud taget ska vara användbart och ge en grund varifrån det går att förutspå om övrig ej listad funktionalitet går att implementera på plattformen. Programmet kommer att behöva visualisera flera aspekter av spelmotorns datafiler på ett lämpligt sätt. Spelen som skapas till spelmotorn innehåller en kampanj som består av ett eller flera scenarion, ett scenario innehåller en karta med specifika mål. Kartor visas som ett bräde bestående av kvadrater med mönster när spelmotorn spelar upp en karta. Programmet ska visa kartorna

11 på samma sätt, så en spelutvecklare direkt inifrån programmet kan se hur det skulle se ut när scenariot spelas upp. Andra aspekter som inte är synliga när spelet körs måste visualiseras i programmet, så utvecklaren kan redigera dessa. Exempel på dessa aspekter är områden som spelarkaraktärer inte kan beträda. Detta ska presenteras som en bild som programanvändaren kan interagera med. Användaren ska kunna välja vilken typ av tile denne vill placera, och sedan placera denna på kartan. Den inbyggda kartredigeraren till Wesnoth fungerar på ett liknande sätt. Användaren måste även kunna skapa nytt material som denne kan använda, exempelvis nya kartor och nya tilesheets, även detta måste kunna ske grafiskt, gärna på ett sätt där användaren kan se resultatet ändras medan denne använder programmet. Allt detta kräver att plattformen har möjlighet att definiera egna grafiska komponenter, om lämpliga inte redan existerar.

12 Kapitel 5

Metod

Viktiga funktioner som programmet måste klara av implementeras. Detta ger en fingervisning om huruvida plattformen är lämplig eftersom dessa funktioner är de som krävs för att programmet över huvud taget ska vara användbart. Går inte dessa att implementera och sedan använda är plattformen inte lämplig. Funktionerna är de som presenteras i avsnittet ”2.3 konkreta krav”. När programmet är färdigt kommer det att testas enligt nedan, om alla delar av programmet inte har hunnit bli klara kommer det som hittills blivit implementerat att testas. Programmet startas och körs av en användare med hjälp av en checklista på de plattformar som ska testas. Checklistan beskriver steg för steg var man ska klicka i programmet och vad för resultat som förväntas efter att detta har skett. När checklistan är genomgången ska det ha skapats ett par filer på användarens hårddisk, dessa jämförs sedan med verifierade filer. Om filernas innehåll stämmer överens och användaren inte upptäckte några funktioner som inte fungerade så anses programmet fungera korrekt. Oförutsedda felmeddelanden räknas som programdefekter, undantaget fel och meddelanden som inte programmet rår på, exempelvis ingen skrivrättighet till hårddisken. Listan designas så att ett urval av programmets funktionalitet och sätt att använda det genomgås, det skulle ta allt för lång tid att testa varje permutation av klickordningar och funktioner. Lista med steg används av två skäl, för det första kommer en del testande att utföras av utvecklarna som skriver spelmotorn. Med denna teknik behöver dessa inte installera tredjepartsprogram för att kunna testa mjukvaran, de be- höver bara ett program som kan visa en textfil. De behöver dessutom inget extra stöd för att få igång någon testmjukvara. Mänskliga testare kan även bidra med annan användbar information, exempelvis att en viss funktion tar längre tid än vad användaren anser är rimligt. Sammantaget möjliggör detta testande på fler operativsystem och konfigurationer än jag har tillgång till. För det andra hittade jag inget ramverk som verkade klara av att testa grafiska gränssnitt på både Windows och Ubuntu Linux och som samtidigt kunde notera eventuella felmeddelanden. Listmetoden är dessutom snabb att utveckla och förändra, inget nytt ramverk behöver läras, uppdaterade instruktioner kan enkelt skickas till testare eftersom det är vanlig text. Nackdelen med denna manuella testmetod är att det kräver en människa som navigerar i programmet, och att en testomgång tar förhållandevis lång tid

13 gentemot datorstyrda tester. Det är även viktigt att tydligt beskriva vad testaren ska se och var denne ska klicka i programmet, så att denne inte missförstår något. Testerna kan inte heller göras hur långa som helst, då en människa inte kan jobba oändligt länge. Programmets basklasser, de som representerar datafilerna som spelmotorn använder, testas under programmets utveckling för att tillse att dessa fungerar korrekt. Att dessa fungerar korrekt är viktigt då programmets grafiska gränssnitt använder dessa basklasser. Dessa basklasser testas med hjälp av testramverket JUnit. JUnit används eftersom det har integrering med Netbeans-editorn, dessutom går det att installera detta ramverk automatiskt under installationen av Netbeans. Inga andra testramverk har undersökts eller övervägts. Om någon funktion inte fungerar som avsett kommer dokumentation och tredjepartsresurser att konsulteras för att se om det beror på handhavandefel snarare än problem med eller begränsningar hos plattformen. Beror det på handhavandefel rättas felet och testerna körs igen. Beror felet på plattformen undersöks det om det finns ett alternativt sätt att implementera funktionen, om detta finns implementeras funktionen på detta sätt och testningen körs igen. Om problemet inte är lösbart eller en eventuell alternativ lösning inte är accepta- bel anses plattformen inte lämplig. En alternativ lösning anses vara oacceptabel om den innebär något av följande: tar för lång tid att utveckla, komplicerar programkonstruktionen väsentligt, försämrar prestandan väsentligt, medför en säkerhetsrisk. Tredjepartsresurser avses bloggar, forum och liknande som handlar om plattformen. Om alla funktioner som beskrivs i avsnittet ”2.3 konkreta krav” inte har hunnit blivit implementerade kommer jag att subjektivt bedöma huruvida icke implementerade funktioner kommer att kunna implementeras baserat på hur utvecklingen av de implementerade funktionerna har gått. För utveckling av programmet kommer Java 8 från Oracle och Netbeans 8 med tillhörande plattformsbibliotek att användas.

14 Kapitel 6

Konstruktion

Programmet är uppdelat i flera moduler. Två av dessa är tänkta att använ- das av andra moduler, en modul som innehåller representationer av datafilerna (basklasser) som spelmotorn använder och en modul som tillhandahåller en pro- jektvy som visas i programmet. Dessa två moduler publicerar API:er som andra moduler sedan använder. Modulen med basklasserna tillåter övriga moduler att skapa och modifiera representationer av datafilerna som spelmotorn använder. Ovanpå dessa byggs sedan grafiska komponenter i andra moduler. Projektvyn i programmet innehåller en trädvy med ikoner, se figur 6.1. Des- sa ikoner agerar gränssnitt åt de olika datafilerna som är implementerade. På dessa kan åtgärder sedan utföras, exempelvis skapa en ny datafil av det aktuella slaget. Nya ikoner och funktioner tillhandahålls av andra moduler, dessa moduler deklarerar med hjälp av Java-annoteringar att de tillhandahåller ikoner för en viss projekttyp.

15 Figur 6.1: Programmets gränssnitt. Till höger syns projektvyn med ett öppet projekt som har ett tilesheet och en levelmap. I mitten redigeras levelmapen. Till höger visas alla tillgängliga tiles från tilesheetet.

Dessa ikoner kan visa en meny med funktioner som kan utföras på dem. Nya funktioner kan läggas till av andra moduler, dessa moduler behöver då bara registrera en så kallad action på en viss plats i Netbeans RCP:s virtuella filsystem. Noderna läser vid skapandet in alla actions som finns definierade där och lägger till dem i sin meny. En action är en bit med kod som körs när användaren utför en viss åtgärd, exempelvis klickar på ett alternativ i en meny. Med hjälp av Java-annoteringar kan klasser markeras som actions och därigenom läggas till i programmets me- nysystem. Figur 6.2 visar ett tillägg i Netbeans standardmenyer.

16 Figur 6.2: Ett alternativ tillagt i Netbeans standardmeny.

Projektmodulen agerar som en central lagringsplats för datafilerna som programmet använder, så för att en ny filtyp ska kunna hanteras måste både projektmodulen ha stöd för att lagra denna, och en modul måste tillhandahålla den faktiska funktionaliteten. Detta möjliggör att en viss funktionalitetsmodul kan ersättas i framtiden, eftersom projektmodulen enbart har hand om lagringen av dessa. För närvarande finns det två moduler som hanterar redigering av två filtyper, TileSheetSupport som hanterar tilesheets, och LevelMapSupport som hanterar levelmaps. Modulen SaveSupport sköter sparning av datafilerna programmets användare har skapat. Figur 6.3 visar hur modulerna är sammankopplade. Pi- larna visar ett beroende på modulens API. Endast moduler skapade för detta arbete visas.

17 Figur 6.3: Hur programmets olika moduler är sammankopplade. En pil indikerar ett beroende på modulens API. Endast moduler skapade för detta arbete visas.

Programmet har utvecklats stegvis, först har en funktionsprioritering skett, därefter undersöks vilka datafiler som behöver skapas eller modifieras för att utföra denna funktion, om datafilen inte redan har en implementation (basklass) har datafilen undersökts och en basklass blivit skapad utifrån denna. Basklassen har sedan testats för att tillse att den fungerar som beräknat. Sedan undersöks plattformens dokumentation, om nödvändigt för att implementera funktionen. Därefter implementeras funktionen i programmet, exempelvis en ny grafisk steg- för-steg guide. Under utvecklingen av programmet har flera av råden från ”Effective Java”[19] följts. När det har varit möjligt har objekt gjorts immutable (oföränderliga), detta gör så att objekten fritt kan delas med annan kod utan att kopieras, och objekten blir automatiskt trådsäkra.[20] På objekt som kan behöva många parametrar har buildermönstret används då detta reducerar antalet konstruktorer som krävs när det finns flera icke-obligatoriska parametrar.[21] På basklasserna har trådsäkerheten deklarerats, antingen att dokumentationen beskriver instanser som immutable eller klargör att instanserna inte är trådsäkra, så andra utvecklare inte behöver undersöka eller gissa huruvida objekten kan användas parallellt av flera trådar.[22]

18 Kapitel 7

Resultat

Följande krav har uppfyllts av programmet och plattformen. Plattformen ska erbjuda abstraktioner och funktioner för grafiska gränssnitt, exempelvis grafiska komponenter Netbeans har erbjuder grafiska abstraktioner. Klassen TopComponent kan användas för att skapa ett fönster inuti applikationen. Fönstret som skapas kan dockas som en flik i programmet, flyttas till ett separat fönster och förstoras och minimeras. Med hjälp av Java-annoteringar kan actions definieras som automatiskt läggs till i korrekta menyer. Noder och deras fabriker gör så att listor med ikoner som har namn och menyer kan skapas. Noder kan listas på olika sätt av plattformen, i programmet listas dem av plattformen som ett träd under projektet. Alla funktioner ska fungera på både Windows 7 och Ubuntu Linux Alla testade funktioner fungerar på både Windows 7 och Ubuntu. Programmet ska erbjuda en grafisk vy för att redigera spelmotorns datafiler på Windows 7 och Ubuntu Linux Alla testade grafiska vyer fungerar på både Windows 7 och Ubuntu. Programmet ska kunna känna igen en mapp med ett visst filin- nehåll som ett projekt Detta är implementerat och fungerar. Programmet ska kunna läsa in grafiskt material från bilder och skapa nya resurser utifrån dessa Detta är möjligt för de basklasser och funktioner som har blivit implementerade. Att implementera det för ytterligare komponenter är möjligt. Programmet ska kunna spara det som användaren har skapat med programmet Detta är möjligt för de basklasser och funktioner som har blivit implementerade. Att implementera det för ytterligare komponenter är möjligt. Följande krav är inte uppfyllda eller bara delvis uppfyllda.

19 Programmet ska kunna redigera alla aspekter av materialet spelmotorn kan spela upp Delvis uppfylld eftersom all funktionalitet inte har hunnit blivit imple- menterad än. Programmet ska kunna öppna tidigare skapat material Detta är ännu inte implementerat. Att implementera inläsning av filer vid inläsning av projekt är möjligt. En av programmets funktioner, ritandet av kartor, presterar sämre än vän- tat när kartstorleken på levelmaps ökas. Efter testande verkar det bero på att implementationen för att rita ut tiles är ineffektiv och ritar ut mer än vad som är nödvändigt. Denna defekt beror alltså inte på plattformen och bör kunna rättas utan större svårigheter. Programmet testades av tre personer. Efter att ha följt listan skulle två filer ha skapats på användarens hårddisk. Detta skedde på både Windows 7 och på Ubuntu. En av dessa filer var identisk för alla tester medan den andra skiljde sig från den verifierade filen. Skillnaden var att vissa XML-element låg i en annan ordning under en tag. Kodlistningarna 7.1 och 7.2 illustrerar skillnaden i elementordningen, test och test2 hamnar inte överst i Java 7. Spelmotorn ställer inga krav på ordningen av dessa element, således är detta ingen defekt. Figur 7.1: Sparad fil skapad av programmet på Java 7. assets/tilesheetexample .png < t i l e s>

Figur 7.2: Sparad ﬁl skapad av programmet på Java 8. assets/tilesheetexample .png < t i l e s> Även om det inte är en defekt undersöktes orsaken till denna skillnad, i fall att det kunde bero på något problem med plattformen. Skillnaden beror på

20 vilken version av Java som används när programmet körs, detta beror i sin tur på en förändring i hur hashvärdet på instanser av objektet String beräknas och används i en HashMap.[23] All testad programfunktionalitet fungerade som beräknat. Av de tester som utfördes upptäcktes inga defekter enligt deﬁnitionen som angavs i kapitlet ”6 Metod”. Basklasserna testades med JUnit på Windows 7 och Ubuntu. Inga fel som berodde på problem med plattformen upptäcktes. Alla upptäckta fel gick att åtgärda utan anmärkning. Testerna utfördes på en 32-bitars version av Ubuntu 14.04, 64-bitas version av Windows 7, 64-bitars version av Windows 8. På Windows 7 användes Java 7 och 8 från Oracle, på Windows 8 användes Java 7 från Oracle, på Ubuntu användes Java 8 från Oracle.

21 Kapitel 8

Slutsats

Utifrån resultaten i avsnittet ”7 Resultat” och kraven i avsnittet ”2.3 Konkre- ta krav” konstaterar jag att Netbeans RCP är en lämplig plattform att bygga en kampanjredigerare på. Netbeans RCP erbjuder tillräckligt med graﬁska abstraktioner som fungerar på ﬂera plattformar för att underlätta utvecklingen av GUI:n. Alla funktioner som önskas har inte blivit klara, men utifrån det som har blivit klart drar jag slutsatsen att även resterande funktionalitet kan implementeras med hjälp av plattformen. De implementerade funktionerna fungerar som avsett och implementationen av dessa har gått överlag bra. Programmets funktioner fungerar på alla plattformar som har testats.

8.1 Diskussion

Programmet är i dagsläget användbart för testande av spelmotorn, något som bör underlätta för utvecklarna av denna. Eftersom programmet inte ännu är färdigt så är det ännu inte helt lämpligt för slutanvändare som enbart vill skapa nytt material utan att programmera eller redigera textfiler, eftersom alla filtyper inte är implementerade. Dessutom är inte funktionen för att läsa in filer imple- menterad ännu, vilket kräver att användaren skapar hela kampanjen utan att stänga av programmet. Prestandaproblemet vid redigering av levelmaps måste också korrigeras för att programmet ska bli lämpligt för slutanvändare. Jag anser att dokumentationen till plattformen överlag är bra, det finns guider på hemsidan som vägleder en igenom grundläggande användande av plattformens funktioner. Större delen av funktionerna som användes var väl dokumenterade med javadoc, vissa funktioners dokumentation var däremot kortfattad och nämnde inte allt man ville veta. Utöver detta finns det även en wiki där specifika frågor, bland annat om hur man gör för att implementera en viss funktion, besvaras, denna har varit användbar under utvecklingen av programmet då svaren därifrån har lett till en bättre implementation av vissa funktioner, exempelvis inläsningen av actions. En del GUI-funktioner har varit särskilt användbara, exempelvis steg-för- steg-guider och TopComponent. Med hjälp av GUI-redigeraren i Netbeans har skapandet av dessa varit enkelt och har bidragit till att öka utvecklingstakten. Dessa guider gör det möjligt att dela upp funktionalitet i mindre delar, exempelvis först hitta en bild att läsa in och i senare steg låta användaren använda den

22 inlästa bilden. Ett gränssnitt som hade allt på en enda sida när vissa funktioner kräver att en annan funktion används först skulle bli förvirrande i min mening. Figure 8.1 visar ett exempel på en sådan guide, först väljer man en bild, sedan vilka områden i bilden man vill använda, och i sista steget namnger man dessa områden. Programmets tabbar och fönster har utvecklats med hjälp av TopComponent som tillhandahålls av Netbeans RCP. Genom att utöka klassen TopComponent och annotera denna med speciella annoteringar skapas ett fönster som med standardfunktioner som erbjuds av Netbeans RCP. Exempelvis möjligheten att maximera och minimera fönstret eller låta fönstret bli en tab inuti programmet. Koden i 8.1 visar dessa annoteringar. Därefter redigeras klassen som en vanlig JFrame eller JPanel från Javas Swing-paket.

Figur 8.1: Annoteringar för att markera en klass som ett fönster. @TopComponent. Description ( preferredID = "LevelMapEditorTopComponent" , persistenceType = TopComponent .PERSISTENCE_NEVER) @TopComponent. Registration ( mode = "editor", openAtStartup = f a l s e )

Figur 8.1: Första steget i steg-för-steg-guiden att skapa ett nytt tilesheet.

En del funktioner var däremot mer komplicerade att använda än de i min mening borde vara. Exempelvis AbstractNode har ingen set-metod för dess

23 actions, vilket gör så att man måste utöka den enbart för att lägga till egna actions. Jag anser arbetet vara lyckat, det står nu klart att plattformen är lämplig för att vidareutveckla kampanjredigeraren på. Resultatet var någorlunda väntat, då kodredigeraren Netbeans, som är mer avancerad än detta program, är byggt med Netbeans RCP, och fungerar på ﬂera operativsystem.

8.2 Konsekvensanalys

Den omedelbara konsekvensen av programmets skapande är att utvecklarna av spelmotorn nu har ett verktyg som kan skapa exempeldata, vilket gör så att de inte behöver skapa material manuellt med textredigerare. Eftersom programmet är uppdelat i moduler bör det vara relativt enkelt för andra utvecklare att lägga till ny funktionalitet och ersätta gammal. Basklasserna och icke-graﬁska funktioner har blivit dokumenterade, detta i kombination med att råden från ”Eﬀective Java” som nämns i avsnittet ”6 Konstruktion” har följts bör även det underlätta underhållet och utvecklingen av programmet, även om andra utvecklare än jag själv fortsätter med programmet. Att programmet fungerar på mer än en plattform gör även så att personer som inte har tillgång till Windows kan använda programmet, på så sätt tvingas ingen till att installera ett nytt operativsystem för att använda programmet.

8.3 Framtida arbete

En möjlighet som inte undersöktes av detta arbete men som verkar intressant är integration mellan kampanjredigeraren och spelmotorn. Att dessa ska kunna kommunicera med varandra, exempelvis att kampanjredigeraren kan fjärrstyra en spelsession på telefonen och att det som händer på telefonen syns i kampanjredigeraren. Enbart Netbeans utvärderades i detta arbete, framtida arbeten skulle kunna utvärdera andra plattformar, som Eclipse RCP, och jämföra med Netbeans RCP om någon annan plattform är bättre lämpad för denna typ av applikation än andra.

24 Litteraturförteckning

[1] Oracle Corporation, ”NetBeans Platform Description”, https: //netbeans.org/features/platform/features.html, under rubriken ”Window System, Standardized UI Toolkit, and Advanced Data-Oriented Components”, hämtad 2014-04-10

[2] World Wide Web Consortium, ”XML Essentials”, http://www.w3.org/ standards/xml/core, under rubriken ”What is XML?”, hämtad 2014-04-10 [3] Oracle Corporation, ”NetBeans Platform Description”, https: //netbeans.org/features/platform/features.html, hämtad 2014- 06-03

[4] Microsoft, ”Supporten har upphört för Windows XP”, http://windows. microsoft.com/sv-se/windows/end-support-help, andra stycket under rubriken ”Vad innebär det att supporten upphör för Windows XP?” första meningen, hämtad 2014-04-08 [5] Björn Lindelöw, Utvärdering av plattformar för tunga Java-klienter, Lin- köpings universitet, Institutionen för datavetenskap

[6] The Battle for Wesnoth, ”Description - Wesnoth”, http://wiki.wesnoth. org/Description, under rubriken ”What is Battle for Wesnoth?”, publicerad 2014-01-12, hämtad 2014-04-10

[7] The Battle for Wesnoth, ”BuildingScenarios - Wesnoth”, http://wiki. wesnoth.org/BuildingScenarios#Scenarios_and_the_Map_Editor, under rubriken ”Scenarios and the Map Editor”, publicerad 2014-03-16, häm- tad 2014-04-10

[8] The Battle for Wesnoth, ”BuildingCampaigns - Wesnoth”, http://wiki. wesnoth.org/BuildingCampaigns#Setting_up_the_campaign, under rubriken ”Setting up the campaign”, publicerad 2014-03-18, hämtad 2014-04- 10

[9] The Battle for Wesnoth, ”ReferenceWML - Wesnoth”, http://wiki. wesnoth.org/ReferenceWML, under rubriken ”The Wesnoth Markup Lan- guage”, publicerad 2013-11-03, hämtad 2014-04-14

[10] The Battle for Wesnoth, ”User Made Content Development IDE - Battle for Wesnoth”, http://eclipse.wesnoth.org/, hämtad 2014-04-14

25 [11] Eclipse, ”Rich Client Platform/FAQ - Eclipsepedia”, http://wiki. eclipse.org/RCP_FAQ, under rubriken ”What is the Eclipse Rich Client Platform?”, publicerad 2013-02-08, hämtad 2014-04-17

[12] Eclipse, ”The Oﬃcial Eclipse FAQs - Eclipsepedia”, http://wiki. eclipse.org/The_Official_Eclipse_FAQs#JFace, under rubriken ”JFa- ce” andra meningen, publicerad 2013-04-07, hämtad 2014-04-17

[13] Eclipse, ”The Oﬃcial Eclipse FAQs - Eclipsepedia”, http://wiki. eclipse.org/The_Official_Eclipse_FAQs#JFace, under rubriken ”JFa- ce”, publicerad 2013-04-07, hämtad 2014-04-16

[14] Eclipse, ”Help - Eclipse Platform”, http://help.eclipse.org/indigo/ index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide% 2Fswt.htm, under rubriken ”The Standard Widget Toolkit”, hämtad 2014-04-18 [15] Oracle Corporation, ”NetBeans IDE - NetBeans Rich-Client Platform De- velopment (RCP)”, https://netbeans.org/features/platform/index. html, hämtad 2014-04-26 [16] Oracle Corporation, ”NetBeans Platform Description”, https: //netbeans.org/features/platform/features.html, under rubriken ”Window System, Standardized UI Toolkit, and Advanced Data-Oriented Components”, hämtad 2014-04-26

[17] Oracle Corporation, ”NetBeans Platform Description”, https: //netbeans.org/features/platform/features.html, under rubriken ”Miscellaneous Features, Documentation, and Tooling Support”, hämtad 2014-04-26

[18] Eclipse, ”The SWT FAQ”, http://www.eclipse.org/swt/faq.php# guibuilder, under rubriken ”Q: Is there a GUI Builder for SWT?”, hämtad 2014-04-26

[19] Joshua Bloch, Eﬀective Java Second Edition, 12:e upplagan maj 2013, Addison-Wesley, ISBN 978-0-321-35668-0 [20] Joshua Bloch, Eﬀective Java Second Edition, 12:e upplagan maj 2013, Addison-Wesley, ISBN 978-0-321-35668-0, sida 73-80

[21] Joshua Bloch, Eﬀective Java Second Edition, 12:e upplagan maj 2013, Addison-Wesley, ISBN 978-0-321-35668-0, sida 11-16 [22] Joshua Bloch, Eﬀective Java Second Edition, 12:e upplagan maj 2013, Addison-Wesley, ISBN 978-0-321-35668-0, sida 278-281 [23] Oracle Corporation, ”Collections Framework Enhancements in Java SE 8”, http://docs.oracle.com/javase/8/docs/technotes/guides/ collections/changes8.html, under rubriken ”Performance Improvement for HashMaps with Key Collisions”, hämtad 2014-05-26