Spelet i sig är inte avancerat men projektet ställer en del krav på implementationen bland annat:

Transkript

1 Problemspecifikation Anti Tower Defence är ett spel som till motsats från klassikern Tower Defence går ut på att förflytta trupper från start till mål utan att bli skjutna och dödade av torn. Tornen placeras och styrs av motståndaren(datorn). Projektet går ut på att designa och implementera ett sådant spel. Spelet innehåller vanligtvis olika typer av trupper och flera banor, vilket också ska gälla i detta fall. Ett krav på spelet innefattar att en trupptyp kan kunna placera ut portaler som teleporterar andar trupper som går på portalen. Olika typer av teräng ska kunna manipulera trupper när de går på terrängen. Vanliga funktioner som pause/resume, restart och highscore ska också erbjudas. Syftet med projektet är fördjupning inom applikationsutveckling i Java, övning på att följa designmönster (t.ex Model View Controller) samt implementering för Java Swing, Java Reflections och trådsäkerhet. Spelet i sig är inte avancerat men projektet ställer en del krav på implementationen bland annat: Utnyttja flera trådar (och garanterad trådsäkerhet) Spelets uppdateringsfrekvens ska bero på tid och ej på datorns beräkningshastighet GUI ska implementeras med Java Swing och flimmer ska undvikas Olika banor ska designas med en eller flera xml filer som följer och valideras enligt ett xml schema En egen xml fil ska kunna anges som argument vid körning av programmet En central highscore databas ska finnas tillgänglig Olika typer av terräng skall implementeras med egna klasser. Dessa ska kunna implementera ett interface med en metod som heter landon. Denna metod skall anropas när trupper går på terrängen. Denna metod och dessa klasser skall läsas in m.h.a Java Reflection.

2 Användarhandledning Spelet ligger som en körbar.jar fil på studentservern i följande kataloger: ~id10abk/edu/apjava/projekt/antitd.jar ~id10aod/edu/apjava/projekt/antitd.jar ~id10pbn/edu/apjava/projekt/antitd.jar ~tm08jsn/edu/apjava/projekt/antitd.jar Programmet startas genom att ange följande i terminalen: Java AntiTD.jar För att läsa in en egen xml fil med egna kartor anges sökvägen som argument. Exempelvis: Java AntiTD.jar min kartfil.xml Efter att ett nytt spel har startats kan spelaren köpa trupper, manipulera T korsningars vägväxlar och eventuellt placera ut portaler (på banor som innehåller Teleporter trupper). Varje bana startas med ett antal krediter som används för att köpa trupper. När en trupp enhet köps, startar den sin vandring omgående. Tornen ändrar slumpmässigt position under spelets gång och skjuter på trupper som befinner sig inom räckvidd. Spelaren får både poäng och krediter om en enhet lyckas nå målet. När poängen överskrider banans vinstpoäng har spelaren klarat banan och kan antingen spela den igen eller gå vidare till nästa karta. Om krediterna tar slut innan spelet har vunnits vinner datorn.

3 Systemdesign För att underlätta implementationsfasen har stort fokus i projektet har legat på den inledande designfasen. Det resulterade i en tydlig, strukturerad och välformulerad dokumentation över ingående komponenter, klasser och metoder. Designfasen inleddes med att identifiera spelets komponenter och klasser. Sedan specificerades klassernas ansvarsområden och beroenden. Scenarion användes för att testa och förbättra designen. När designen var färdigställd sammanställdes den i ett klassdiagram (FIGUR REF KLASSDIAGRAM LÄNGE NER) som användes vid implementationen av systemet. Designmönster Model-View-Controller Spelet följer designmönstret MVC och är uppdelat genom att alla beräkningar och logik ligger i bakomliggande lager (modeller). En kontroller svarar mot spelarens interaktion med vyn och förmedlar information mellan vy och modeller. Vyn presenterar informationen som hämtas från modellerna. Designmönstret används främst av följande anledningar: Lätt att bygga ut spelet med nya modeller Möjliggör utbyte av vy Koden blir återanvändbar Observer Interaktionen mellan användare och GUI sker med hjälp av att de olika klickbara elementen i spelet har lyssnare som registrerar händelser för respektive element. Template Units(trupper) och Terrain(terräng) är två paket med superklasser som fungerar som mallar för dess subklasser vilket innebär minskad risk för duplicerad kod. Mediator Model lagret innehåller en klass som fungerar som spelmotor. Kontrollerna hämtar all information från denna klass och den förmedlar all information mellan övriga modeller. Kodkonvention Koden har försökt följa de standarder som anges i Java Code Conventions (Sun, 1997).

4 Systembeskrivning Paket Systemet består av totalt 5 paket. Paketen är uppdelade efter de ingående klassernas ansvarsområden och är döpta efter namnkonventionen com.jaap.antitowerdefence. paketnamn. Paketen är följande: FIGURTEXT!

5 com.jaap.antitowerdefence.antitowerdefence Innehåller spelmotor, mainfil, gui, kontroller och klasser som används av flera andra paket exempelvis Position och HighScoreDB.

6

7 FIGURTEXT! (Huvudpaketet (antitowerdefence))

8 com.jaap.antitowerdefence.unit Innehåller en superklass Unit som innehåller metoder och attribut som är gemensamma för alla typer av trupper, exempelvis move som är en metod för att gå framåt. Det finns just nu tre stycken subklasser till Unit, som representerar de olika enheterna. Av dessa är det egentligen bara TeleporterUnit(Wizard) som har speciella metoder. Genom att lägga till subklasser kan spelet byggas ut med fler trupptyper. FIGURTEXT (unit klass dia)

9 com.jaap.antitowerdefence.terrain Innehåller alla typer av terräng som finns i spelet. Liknar Unit paketet på det sättet att paketet innehåller en superklass Terrain där varje subklass motsvarar en terrängtyp, exempelvis Grass och Road. De olika terrängtyperna har olika egenskaper och de subklasser som implementerar interfacet LandOnInterface innehåller metoden landon. Denna metod används för att manipulera de enheter som kliver på terängen. Exempelvis är portal en terräng vars LandOn ändrar position för truppenheten.

10 FIGURTEXT (klassdia Terrain)

11 com.jaap.antitowerdefence.level Innehåller klasser för att läsa levels från xml filen (en xml läsare), hålla koll på nuvarande bana och statistik för banan. FIGURTEXT (levelpaketet klassdia) com.jaap.antitowerdefence.test Innehåller alla testklasser.

12 Algoritmbeskrivningar Spelets består i huvudsak av två loopar som körs parallelt med varandra. Den ena uppdaterar spelets back end, dvs modellerna. Denna hanterar statistik, trupprörelser, hur torn skjuter och flyttar sig. Den andra loopen uppdaterar gui:t. Back-end algoritm 1. Om det är dags för torn att flytta sig: a. Skapa en ny lista av torn b. Skapa nya torn på slumpmässiga positioner c. Ersätt den gamla torn listan 2. För varje torn: a. Om tornet har ett laddat vapen : i. Om det finns en enhet inom räckhåll 1. Avfyra 2. Sänk enhetens hälsa 3. För varje truppenhet: a. Hämta nästa position och riktning b. Om det är dags att flytta sig: i. Gå till nästa position c. Om enheten gick i mål eller om enheten dog: i. Uppdatera statistik ii. Ta bort enheten ur enhetslistan Front-end algoritm (huvud loopen, inte de asynkrona delarna) 4. Om banan är förlorad: a. Visa förlustpanel med val för att starta om eller avsluta spelet b. Om highscore uppnåddes: i. Visa fönster för att lägga in nytt highscore c. Annars: i. Visa nuvarande highscore 5. Om banan är vunnen: a. Om det var sista banan: i. Kör samma procedur som vid förlust (1) b. Annars: i. Visa vinstpanel med val för att starta om banan eller gå vidare till nästa 6. Annars: a. Låt Back end algoritmen köra ett steg b. Aktivera/deaktivera unit knappar beroende på kostnad, krediter och annat

13 c. Om det finns errors i Back end: i. Visa errorpanel med val för att starta om eller avsluta spelet ii. Visa fönster med error meddelande

14 Trådar Spelet körs i två trådar i taget (exklusive timer trådarna), The Event Dispatch Thread (EDT) och dess Swingworker(s) (en i taget)/main tråden (i början). EDT är ansvarig för att rita ut GUI t, med grafik, och köra alla knapplyssnare vid behov. I vissa knapplyssnare (restart osv.) startas en Swingworker för att köra Front end loopen, som i sin tur kallar Back end loopen. Trådsäkerheten uppfylls bland annat genom användning av Swingworkers och invokelater/invokeandwait (i SwingUtilities ) i kontrollern för att styra vilken tråd som kör vad. De centrala arrayerna, som hanteras och ändras i Back end, men behöver kunna läsas i Front end, har implementeras som CopyOnWriteArrayList s, för att de ska vara trådsäkra. Ett specialfall är torn arrayen som sätts ny vid varje omplacering av tornen. Den nya referensen måste således skickas upp till GameForeground objektet, för att kunna ritas ut på skärmen. Detta löstes med en PropertyChangeListener som meddelar när tornen flyttas, så kontrollern kan skicka den nya arrayen till GameForeground objektet. Internt i GameForeground objektet används semaforer för att sköta synkroniseringen av tilldelning respektive utritning av tornen. En semafor används även för synkronisering av användandet av time variabeln, som används för utritning av åtgången tid, i GameForeground objektet.

15 GUI Spelet startar pausat och användaren får själv sätta igång spelet(figur REFERENS). Möjligheten finns också att avsluta spelet och bläddra i menyerna. Ungefär samma vy visas också när användaren väljer att pausa spelet. Knapparna ersätts i detta fall med en Resume Game knapp, och rubriken sätts till Paused.

16 Spelet ser ut enligt (FIGUR REFERENS) när det spelas. Vid detta tillfälle har en Wizard placerat ut två portaler efter vägen. Målet representeras av en flagga och starten av en hydda. Vid varje T korsning finns en pil som indikerar vilket håll trupperna skall gå. Dessa pilar är klickbara och vid klick snurrar pilen medsols. Längst uppe i det vänstra hörnet syns aktuell statistik för banan.

17 Menyer Den övre delen av gränssnittet består av tre menyer som alltid är tillgängliga. I Game menyn(figur REFERENS) finns alternativ som behandlar själva spelet. Om spelet är startat så är alternativen Restart level och Pause aktiva. I Help menyn (FIGUR REFERENS) kan spelaren ta reda på mer information om spelet och skaparna. Denna information dyker upp i dialogrutor vid klick. Highscore menyn (FUGUR REFERENS) erbjuder användaren att titta på nuvarande highscore lista.

18 Spelkontroller I den nedre delen av spelfönstret finns spelkontrollerna(figur REFERENS). Här finns möjligheten att köpa olika trupptyper och placera ut portaler. Respektive enhets knapp inaktiveras om spelaren inte har tillräckligt med credits för att köpa den och göms helt om kartan inte tillåter denna typ. Portal knappen aktiveras endast om det finns en Wizard (Teleporter enhet) vid liv. Javadoc Fullständig dokumentation och specifikation för alla ingående klasser finns på följande adress: LÄNK TILL JAVADOC HÄR!!!

19 Begränsningar Vi hade kunnat designa systemet för bättre utnyttjande av trådar. Ytterligare optimering var dock något vi inte hann med. Felhanteringen i spelet är inte komplett. Om något går snett och inte fungerar i vissa delar av spelets back end så säger spelet inte till och det kan ge upphov till problem. Möjligheterna för felhantering är skapad i modellen för spelmotorn, men utnyttjas inte till fullo. Detta på grund av tidsbrist. Tester Systemet har utvecklats enligt metodiken Test Driven Development vilket innebär att alla modell klasser har testats individuellt under utvecklingen. Testerna har gjorts med hjälp av JUnit4 och ligger i ett eget paket i projektet.

20 Diskussion Resultatet Spelet är framför allt fungerande. Vi är stolta över att ha gjort en spel som uppfyller kraven och dessutom är roligt att spela. Spelet är utmanade och utseendemässigt så är det fullt acceptabelt. Framtid Spelet består av olika paket och moduler vilket gör det lätt att bygga ut. Nya terrängtyper och trupptyper läggs snabbt till vilket kan ge spelet ytterligare funktion. Gui:t är dumt vilket innebär att det endast presenterar information som den får av kontrollern. På så sätt finns stora möjligheter att implementera ett annat gränssnitt om man skulle vilja. Många av modellerna (t.ex. Position och Direction) kommer att kunna användas i framtida projekt, vilket man alltid siktar på när man programmerar. Det hade varit klokt att implementera errorhantering innan vidare utveckling tog vid. Ytterligare banor och balansering av svårighetsgraden på de existerande banorna hade varit effektiva sätt att utöka spelet. Erfarenheter Designfasen var lyckad och gav oss nytta i implementationsfasen. Den slutgiltiga designen liknar den initiala designen väldigt mycket. Även om vi la ner mycket tid på designen hade vi nog igen det i slutskedet av projektet eftersom vi slapp designa och strukturera om systemet. Att använda sig av designmönster och följa kodkonventioner när man programmerar är också väldigt nyttigt. Eftersom MVC är något som används i majoriteten av dagens applikationer är det viktigt att lära sig och förstå. Detta är något vi kan ha med oss i arbetslivet! Vi skulle tänkt på trådsäkerheten och vilka trådproblem som kunde uppstå tidigare. Först i slutet av projektets gång insåg vi att vi hade synkroniserningsproblem vilket blir en viktig lärdom. En annan erfarenhet är hur viktigt det är med tydlig kommunikation inom gruppen, så alla deltagare uppfattar alla diskussioner, direktiv och bestämmelser på samma sätt. Sammanfattningsvis har det varit ett roligt projekt att genomföra. Vi är nöjda med resultatet men tycker nog att det tog mer tid än vad det borde ha gjort.

21 Bilagor Tidplan En sista uppdaterad version av dokumentet ska bifogas slutrapporten. Efterstudie Utöver dokumentationen av programmet så ska ni även lämna in en detaljerad beskrivning av vem som gjort vad i projektet (för att individuell betygsättnning ska kunna genomföras) och hur projektet har förflutit. Observera att det inte räcker med en mening där ni säger att ni alla varit inblandade i allt och gjort lika mycket (lite mer detaljnivå krävs). Källkod Denna del ska ges som en bilaga till slutrapporten.