Problemformulering 4. Specifikation 5. Struktur 6. Patterns 7 Facade 7. Anvendelse af patterns 8. Valg av klasser 10. Element-klyngen 10 Statics 10

Transkript

1 Innledning 4 Problemformulering 4 Specifikation 5 Struktur 6 Design 7 Patterns 7 Facade 7 Model-View-Controller 8 Anvendelse af patterns 8 Valg av klasser 10 Element-klyngen 10 Statics 10 Character 10 PickUp 11 GameController-klyngen 11 Heltens bevegelser 11 Fiendenes bevegelser 11 Kollisjoner kan være dødelige, men er nødvendige 12 GUI en 12 Controller 13 Globals 13 Pakkestruktur 13 Anvendelse af datastrukturer 13 Posistionering og koordinatsystem 15 Banedesign 15 Implementering 18 Fra UML til kode 18 1 / 43

2 Levelparser 18 GUI 19 Grafikken 20 Implementering af billeder 21 ID er 21 Animation 22 GamePanel 22 Double Buffering 23 paintcomponent 23 AlphabetRun og HighScoreWindow 24 Control 26 My Comfort Zone 26 GameController 26 HeroMoveHandler 28 Gravity 30 HeroCollisionHandler 30 EnemyMoveHandler 31 Lynsjekk av fiender 31 Om walkers algoritme 31 Om shooters algoritme 32 Keeping them in place 32 Forflytning av Projectile 33 Events 33 Picking up a PickUp 33 Loosing it again 34 Synchronized 34 Extra features 35 2 / 43

3 Splash-screen 35 Lyde 35 HighScore 36 Test 37 Diskussion 39 Arbeidsmetoden 39 Brug af JUnit tests 39 Mulige utvidelser 40 Arbejdsproces 41 CVS 41 Weblog 41 Filerepository 42 Sommerhus 42 Konklusion 43 3 / 43

4 Innledning Med all verdens gode spill fra barndommen vagt i minnet ble valget av eksamensoppgaven lettere enn vi på forhånd hadde trodd. Etter to katastrofale Resident Evil-filmer og en sterk aversjon mot -lister på toppen var det en selvfølge å velge oppgave en, altså å lage et spill. Det som derimot var litt vanskelig var å velge hvilken type spill vi skulle lage. Det er mange sjangere å velge mellom og gode muligeter for å velge en umulig oppgave. Egentlig hadde vi bestemt oss for å lage et førstepersjons skytespill i vill 3Dgrafikk, men følte litt at Quake 4 og Doom 3 med flere hadde uttømt sjangeren. Derfor valgte vi i stedet å gå for en av de første sjangerene som ble utviklet, nemlig plattformspillet. Det er viktig for oss å ikke ta på oss oppgaver vi ikke kan løse, samtidig er det viktig å ikke springe over der gjerdet er lavest. En eksamensoppgave skal jo helst være litt utfordrende og lærerik. Ved siden av å sørge for at vi får en god prosjektperiode vil vi gjerne lage et spill som kan gi andre nostalgikere mange timer med utfordringer og glede. Det vil faktisk ikke være å ta for hardt i å si at ønsket om å gi andre likesinnede gode opplevelser er en viktig drivkraft i prosjektet. Donkey Kong var et av de første kjente plattformspillene. Senere har italienske håndværkerbrødre, hyperaktive pinnsvin og strålende menn med løse kroppsdeler fulgt på rekke i denne sjangeren. Men noen av oss, vi som er opptil 3 år eldre enn de andre, kan huske en tid før Donkey Kong. Den gangen heltene ikke figurerte på reklameplakater. Da grafikken var i maksimalt 8 farger og lyden, hvis man kan kalle det det, ble tvunget ut gjennom en sliten systemhøyttaler uten noe hensyn til sarte sjeler eller andre tilstedeværende. Den gangen diskettene var litt over 5 tommer brede og virusbeskyttelsen var et sett med rustne dartpiler. Det var da ethvert spill kunne revolusjonere bransjen og tilby noe helt nytt, aldri tidligere sett. Da historiene var tynne og det å kunne flytte en samling pixels rundt på skjermen var et under i seg selv. Disse spillene er det vi vil minnes og hjelpe andre med å minnes. Problemformulering Vores opgave består i at skabe et spil, bestående i en hvilken som helst verden, som vi selv skal definere og afgrænse. Samtidig skal man styre en figur, eller en såkaldt helt rundt i denne verden. Passe på minimum 3 forskellige fjender, som på en eller anden måde kan være farlige for helten, og sidst men ikke mindst skal helten kunne samle minimum 3 slags genstande op, som på en eller anden måde skal kunne påvirke ham. Samtidig skal han bevæge sig igennem minimum 3 baner af stigende sværhedsgrad, og på en måde have et klart mål for hver bane. Det er denne opgave vi med vores spil har bestræbt os på at løse, og her er vores specifikation på hvordan resultatet skal være. 4 / 43

5 Specifikation Med rødder i klassiske spil som Donkey Kong, Super Mario Bros. og Rick Dangerous, ville vi fremstille et spil, der ikke bare krævede en masse tryk på nogle tilfældige knapper, men samtidig også timing og tankevirksomhed. Dette spil blev Ricky s Adventure. Plottet i spillet skulle være tyndt og selvforklarende, og bestå i at man som helten Ricky skal finde den gyldne nøgle, hvorved døren åbner sig og man kan avancere til næste bane. Banerne består af flere større og mindre platforme forbundet af stiger. Dette er for at give spillet et puzzle-feel, i forhold til hvis Ricky kunne bevæge sig frit omkring på banen og f.eks. hoppe som en anden kendt blikkenslagerhelt. Altså er det nødvendigt at finde den rigtige vej til nøglen og tilbage igen, og samtidig time sin færden i forhold til Ricky s fjender. For Ricky er ikke alene, banerne er befolket af adskillige forhindringer, farligheder og fjender som vil gøre alt for at stoppe Ricky: En fjende der ustandseligt patruljerer en platform for at slå Ricky ihjel hvis han møder ham, og en fjende der konstant skyder foran sig i håb om at ramme hvad der nu kommer i vejen for hans projektiler. Ricky skal samtidig passe på hvor han går, for i stedet for jord kan han træde på livsfarlige pigge, og som en hyldest til Donkey Kong skal han passe på ikke at få en af de faldende tønder i hovedet. Men Ricky får også hjælp til at klare skærene og på banerne ligger også adskillige mystiske genstande som han kan samle op. Han ved dog ikke hvad de er, før han har samlet dem op, så disse kan være både positive eller negative. De positive effekter er: Udødelighed i et kort stykke tid, frysning af fjender, et ekstra liv eller at Ricky bevæger sig hurtigere. De negative effekter er at Ricky bevæger sig langsommere eller bevæger sig modsat spillerens input. 5 / 43

6 Samtidig tjener spilleren point ved at lede Ricky igennem banerne og samle ting op. Man får 500 point for at gennemføre en bane plus en tidsbonus, som udregnes på følgende måde: Bonusen starter på 4000 point og tæller derefter ned over tid, og hvis man ikke gennemfører banen indenfor 2 min. får man et negativt antal point som straf for at have brugt for lang tid. Man får samtidig 500 point for at samle nøglen op, og 250 point for at samle de mystiske genstande op. Altså er man sikret 1000 point for at gå igennem en bane. Ricky har fra starten 3 liv og har han ikke flere liv tilbage, stopper spillet, og spilleren kan indtaste sit navn, hvis han har fået nok point til at komme på highscoren. Samtidig er det muligt at tilgå highscore listen gennem menuen uden at spille spillet. Selve måden man styrer på er ved hjælp af pil-tasterne på tastaturet, samt et enkelt tryk på enter for at starte spillet. Dette er som i de gamle dage hvor styringen normalt foregik med et joystick med en enkelt knap, eller et joypad med meget få knapper. Struktur Vi vil starte med å beskrive vårt design og vår designprosess. Her vil vi ta for oss UMLdiagrammene og beskrive klassenes funksjon. Samtidig vil noen overveielser, som ligger til grunn for våre valg komme fram. Det vil også bli diskutert endringer som er gjort i designet underveis. Deretter vil vi se på implementeringen av designet. Vi vil vise interessante kodeeksempler og forklare nærmere hva som skjer i de forskjellige klassene. Vi vil også begrunne vår kode og komme med alternative muligheter der det er aktuelt. Det vil også være et avsnitt som besktiver deler av spillet som ikke direkte har noe med spillbarheten å gjøre. Til sist i denne delen vil vi fortelle noe om hvordan vi har testet spillets funksjon og spillbarhet. I den siste delen vil vi diskutere arbeidsmetoden, bruk av arbeidsverktøyer og hvordan arbeidsprosessen har forløpt. Vi vil også se på mulige utvidelser og deres grad av relevans for spillet. Helt til sist vil vi i konklusjonen se på i hvilken grad det har lykkes oss å oppfylle kravene i oppgaven og kravspesifikasjonen og om metodene og værktøyene vi har brukt har vært adekvate. 6 / 43

7 Design I dette afsnit gennemgår vi ideerne og filosofien bag vores modellering af designet, altså, hvilke patterns vi har set det fornuftige i at modellere omkring, hvordan vi har modelleret systemet, hvilke tanker vi har gjort os omkring spillets funktionalitet og opbygning, og om hvordan spilleren skal opleve det. Patterns Vi har i vores system bestræbt os på at anvende design patterns til at gøre vores system og kode mere overskuelig, fleksibelt og mindre kompleks. Vi har brugt Facade og et Observer-pattern. Facade Facade pattern betyder at én klasse fungerer som facade for et helt subsystem, som vist på diagrammet herved. Facade klassen kan ses som interface til subsystemet, og medhjælper til at gøre systemet nemmere at bruge. Facade klassen kender til hele subsystemet, og ved hvilke klasser der gør hvad, mens ingen af klasserne i subsystemet har ingen kendskab til Facade klassen. Facade klassen udfører ingen udregning selv, men uddelegerer opgaverne til de subklasser som kan udføre dem. I subklasserne ligger hele funktionaliten, og de opgaver som Facaden stiller løses her. 1 1 Bilag 3: pr. 24. Maj / 43

8 Model-View-Controller Model-View-Controller-pattern et (herefter MVC) bruges til at strukturere hele grafiske applikationer over. Pattern et opdeler systemet i 3 dele: Model -delen med de centrale funktioner, dataudveksling og datahåndtering. View som viser information baseret på modellen til brugeren, samt Controller som styrer input fra brugeren og er ansvarlig for hvordan modellen og view et skal opføre sig og hvad de skal gøre. De sidste to dele udgør tilsammen GUI en. 2 Begge nedarver fra Observer interfacet for at kunne give besked til modellen om ændringer. Brugen af MVC skulle gerne, hvis implementeret rigtigt, gøre systemet mere fleksibelt og lettere at håndtere, da det adskiller GUI fra modellen. Dette kan anvendes til at gøre det lettere at lave større ændringer i GUI ens opbygning uden at det påvirker modellen, og derfor undgås store fejl og komplikationer nemmere. Anvendelse af patterns Vi har valgt at anvende patterns i relativt lille målestok, og disse er kun strukturelle patterns. Vi havde allerede fra starten besluttet os for at modellere vores system over et MVC/Observer pattern, inspireret af tidligere opgaver og Rabbithunt-konkurrencen, samt for at gøre det lettere at strukturere systemet. Facade var ikke med i vores overvejelser fra starten af, men som vi fik implementeret GameController klassen, og denne voksede sig til en ca. 600 liniers klasse, begyndte vi at lede efter et optimalt mønster at anvende og Facade var dette. I stedet for at have alle funktioner liggende i én stor klasse, besluttede vi os for at lægge dem ud i nogle mere logiske underklasser. Derved opstod EnemyMoveHandler, Hero- CollisionHandler og HeroMoveHandler. Facade mønstret var helt perfekt at bruge i denne sammehæng, da GameController stadig kunne sørge for at få alt input, og så bare sende det videre til de klasser som nu kunne bearbejde det. Med brugen af dette pattern kunne vi så afskærme et helt undersystem via. GameController og få et overblik over GameController klassen og de un- 2 Forelæsning d. 23. Marts / 43

9 derliggende klasser. Derved opnåede vi både større fleksibilitet, og meget høj samhørighed, da klassernes formål er meget entydig, i modsætning til at GameController varetager en masse forskellige funktioner. Samtidig er der indenfor klyngen lav kobling da det kun er GameController der kommunikerer med underklasserne. Som nævnt, var vi fra den spæde start opsat på at anvende et MVC pattern til at strukturere vores system over. På figuren kan man se hvordan vi har fortolket mønstret og hvordan vi har implementeret dette. Det første der springer i øjnene er måden hvorpå View og Control implementerer Observer. Disse gør det ikke hver for sig, men igennem GUIControlleren som repræsenterer hele GUI en. Dette ser vi stadig som at overholde MVC mønstret, da View og Control jo på den måde observerer vha. GUIController, og vi har på den måde fået samlet de opdateringsrelaterede funktioner i GUIControlleren, samt de mere klassespecifikke funktioner i deres respektive klasser. Altså har vi på den måde højnet samhørigheden i klasserne, da GUIControlleren bare gør det den skal, nemlig at kontroller og styre, mens de andre klasser gør udfører deres opgaver. Ser man på GUI-afdelingens dele, kender View jo Control delen og Model gennem GUIControlleren, og Control kender Modellen ved at GUIControlleren kender Control og får input derfra. Vi har gjort dette for at holde lav kobling mellem Model og GUI en, der skulle lette en evt. udvidelse eller omstrukturering i GUI en. Altså har vi anvendt MVC Pattern for at opnå de fordele dette giver ved lav kobling, og samtidig har vi fortolket lidt på det for at lette brugen af det i forhold til vores system. Ser man på GUI-delen igen, skulle man tro at det ville være fornuftigt at anvende et Facade pattern på denne del også, da GUIControlleren egentligt har noget af den samme funktion som GameController har en Model-delen. Dog ikke helt den samme, da GUIController ikke kun sender informationer videre til GUI en får den også information fra Control delen og sender disse videre til Model. 9 / 43

10 Man kan dog diskutere om man så ikke kunne programmere GUIControl om så den måske kunne fungere som ViewControl og derved ikke skulle have noget med Control delen at gøre. Dog valgte vi vores måde for ikke at højne programmets kompleksitet alt for meget. Valg av klasser Vi har valgt at modellere vores system efter 3 klynger af klasser: En elementklynge der indeholder de klasser der har med Elementklassen og dens underliggende klasser at gøre. GameController-klynge der indeholder GameControlleren og dens subklasser, samt GUIklyngen der indeholder de klasser der tilsammen udgør GUI en i forhold til et MVC pattern. Element-klyngen Alle objektene som inngår i spilleflaten nedarver Element 3. Vi har forsøkt å samle så mye informasjone og funksjonalitet så høyt oppe i strukturen som mulig. Dette for å utnytte likehetene i de forskjellige klassene. Samtidig blir det lettere å samle alle objektene i en ArrayList. Elementene blir senere castet når det er bruk for det. Alle objektene skal kjenne sin posisjon, kollisjonsfelt og type. Dette må de kunne for at vi skal kunne plassere dem og gi dem et bilde. Samtidig brukes kollisjonsfeltet for å bestemme hvordan objektene interagerer med hverandre. Statics Door, Ground og Ladder nedarver fra Static. De får ingen nye egenskaper, men har forskjellig størrelse på kollisjonsfeltet. For å gjøre det enklere å skrive koden har de fått hver sin klasse. Character Dette er kanskje den mest avanserte gruppen. Det er her vi finner alle de bevegelige elementene på spillebrettet. Alle Characters har en retning og en hastighet. Character nedarves av Enemy og Hero. Vi har valgt å samle alle fiender under Enemy for enklere å kunne teste om helten kolliderer med en fiende eller noe annet. Enemy nedarves av Walker, Shooter, Projectile og Still. Projectile og Still får ingen nye egenskaper, men Still får retning og hastighet satt til 0 i sin constructor. Walker har fått en metode som gjør at han kan skifte retning. Shooter har metoder for å sjekke om han kan skyte, en for å skyte og en for å lade. Hero nedarver også fra Character og tillegges forholdsvis mange egenskaper. Han får et begrenset antall liv og metoder for å administrere disse. I tillegg inneholder Hero informasjon om hvilke PickUps han har kollidert med. Dette påvirker bevegelsesmønsteret. Disse informasjonene nullstilles for hvert level. 3 se bilag Element-cluster 10 / 43

11 PickUp PickUp har en metode som heter hit og tar en Hero. Denne genererer et tilfeldig utfall for Hero. Altså settes tilfeldige verdier i Hero. Disse påvirker igjen bevegelsesmønsteret til Hero som å øke/senke hurtigheten, reversere retningen, gjøre udødelig, fryse fiendene og gi Hero et ekstra liv. PickUp nedarves av Key som overrider hit() og gir Hero nøkkelen. GameController-klyngen Denne klassen er den som styrer og koordinerer hele spillets back-end 4. Det er den som skal delegere oppgaver og levere informasjon til GUI. Det er ingen av de andre klassene i back-end som kjenner GameController, men den kjenner alle klassene. Enten direkte eller gjennom andre. Vi har brukt GameController som en Facade for alle de underliggende klasser for å forenkle eksekveringen av spillmotoren. GameController nedarver Observable for å gjøre det så enkelt som mulig å gi GUI informasjon om spillets gang uten å være avhengig av metoder i GUI en. GameController får all nødvendig informasjon gjennom egne metoder som blir kalt utenfra. Til å begynne med hadde vi alle bevegelsesmønstre og kollisjonstesting inne i GameController, men dette ga en veldig komplisert og uoverskuelig kode. Derfor har vi flyttet disse funksjonene ut i HeroMoveHandler, HeroCollisionHandler og EnenmyMoveHandler. Verden blir lettere å leve i fordi det er lettere å lese gjennom koden. Heltens bevegelser HeroMoveHandler sørger for heltens bevegelser. Helten styres av spilleren, men også av sin posisjon på spillebrettet. Altså kan, naturlig nok, ikke helten flyttes alle veier til enhver tid. Vi har forsøkt å innføre noen fysiske lover for at spillet skal bli mere realistisk. Når helten står på bakken kan han flyttes horisontalt, men når han står på en stige kan han flyttes alle veier. Men vi har innført begrensninger i området hvor stigen passerer gjennom bakken. Det skal være umulig å bevege seg inn i jorden bade undenifra og fra siden. Når spilleren beger helten utover kanten av bakken eller en stige vil helten falle ned. Hastigheten av fallet bestemmes av den hastigheten helten har. Under fallet vil det ikke være mulig å styre helten i noen retning. Vi har forsøkt å tillate horisontale bevegelser i fallet, men har kommet til at da blir spillet for lett. Fiendenes bevegelser I spillet er det tre typer fiender som beveger/endrer seg og en som står stille. Still står stille og er dødelig. Den har ingen retning eller hastighet, og dermed har den ikke evnenen til å flytte på seg. Den blir heller ikke behandlet i EnemyMoveHandler. Shooter vil med jevne mellomrom generere et Projectile-objekt, altså skyte, inntil den blir fjernet fra spillebrettet (når det skiftes level). Prosjektilet vil bevege seg i den retning den 4 se bilag Back-End 11 / 43

12 får tildelt etter at den genereres inntil den kommer utenfor spillebrettet. Da vil den fjernes fra spillebrettet. Retningen bestemmes av den retningen Shooter-objektet har. Den mest avanserte bevegelsen har Walker. I EnemyMoveHandler sjekkes det om det er en Ground foran Walker. Hvis den ikke kan finne noe foran seg i den retningen den beveger seg vil dens Turn()-metode bli kalt. Den endrer retningen til det motsatte og Walker beveger seg i motsatt retning. På den måten vil den fortsette å patruljere plattformen den beveger seg på. Kollisjoner kan være dødelige, men er nødvendige Hele heltens bevegelsesmønster er bygget opp rundt kollisjoner. Hvilken retning helten kan bevege seg i avhenger av hvilke elementer han kolliderer med. Kollisjoner med pickups, nøkler, dører og fiender vil også utløse hver sin tilhørende reaksjon. Alt dette blir håndtert av HeroCollisionHandler. Grunnen til at vi har valgt å teste om helten kolliderer i noe i stedet for å teste på om hvert objekt kolliderer med helten er at det kun er helten som er avhengig av kollisjoner. GUI en Første formål GUI en skal udfylde er at repræsentere selve spillet grafisk. 5 Derfor er de vigtigste klasser MainWindow, som bare er et vindue, og GamePanel som viser spillet samt KeyListener klassen for at styre brugeren input. Mest centralt findes så GUIControlleren som styrer al tilgang til selve GUI en. Dette passer overens med vores brug af Model-View-Controller-pattern. GUIController nedarver fra Observer klassen og ved brug af denne opdateres GUI en. Præcis som MVC mønstret foreskriver. Den primære funktion i GUIController er derfor update(), da det er denne der opdaterer ændringer i modellen, og derfor i spillet. Endvidere har GUIControlleren funktionen updategui() som ikke gør andet end bare at sende ordren videre til GamePanel som så udfører arbejdet med at opdatere selve spilområdet. GUIControlleren har mange funktioner den egentligt bare sender videre, det gælder funktionerne, newlevel(), showsplashscreen() m.fl som også bare maskerer henholdvis GamePanelet s drawlevel() og showsplashscreen() funktioner og flere. På samme måde fungerer updatescore() og updatelives() som i stedet maskerer Main- Windows funktioner ved samme navn. Ser man på UML klassediagrammet i bilaget, ser man at både GUIController og Main- Window har kendskab til GamePanel. Dette er pga. at MainWindow ikke kan foretage nogen ændringer i GamePanel, MainWindow fungerer kun som container for GamePanel. 5 Se bilag, GUI Struktur 12 / 43

13 Grunden til at GUIControlleren har direkte kendskab til GamePanel og ikke maskeres gennem MainWindow, er at GamePanel repræsenterer modellen mest direkte og det derfor virker logisk at forkorte vejen fra model til GamePanel. GUIControlleren er samtidig den eneste klasse der har kendskab til ImageCache klassen. Dette er for at nå mindre afhængighed klasserne imellem, mens at klasserne der kender GUIControlleren stadig har adgang til ImageCachen. ImageCache er en klasse som navnet siger, som holder styr på alle billed-objekterne i systemet. At alle informationer om hvilke billeder der skal bruges, holdes i en klasse for sig i GUI en i stedet for, som først overvejet i gruppen, at hvert Element havde information om hvilket billede der skulle bruges til at repræsentere sig, gør at det grafiske er udskilt af resten af modellen og derfor opnår GUI en større uafhængighed. Controller Controller delen eller mere specifikt KL (KeyListener) klassen, gemmer den aktive retning som spilleren trykker i en instans variabel og GameController kan så gennem GUIControlleren spørge til denne retning med getdirection() funktionen. KeyListener lytter kun på nogle bestemte taster, piletasterne og enter. Globals For å gjøre det litt lettere å bruke int for å identifisere karakterer har vi valgt å lage en klasse med en rekke final static int. Vi har også en rekke instillinger som også er beskrevet her. Ved å legge alt dette på et sted er det enklere å gjøre omfattende endringer i koden da vi refererer til de samme ints gjennom hele koden. Retninger er også på samme måte, men ligger i en egen klasse da den nok ikke skal endres i like ofte. Disse globals blir brukt både til å velge de rette bildene som skal vises og for å spille de rette lydene. Det gjør det også langt enklere å skrive koden da det er lettere å huske et navn enn et tall, og man kan få hjelp av content-assist i et IDE. Pakkestruktur Vi har valgt å legge klassene i forskjellige pakker etter logisk samhørighet. Målet er å skape en oversiktlig kode og gjøre det lettere å teste og ferdigstille de forskjellige delene av spillet. Det er også lettere for oss å samarbeide om koden når den er enkel å navigere i. Pakkene vi har brukt er control, gui, elements, IO og sound. Control inneholder alle controllerne og deres støtteklasser, elements inneholder alle elementene, gui inneholder klasser for å kontrollere og tegne gui en, IO inneholder filer som leser fra og skriver til filer på computeren og world inneholder informasjoner som brukes gjennom hele spillet. Anvendelse af datastrukturer I modelleringen af programmet har vi overvejet flere datastrukturer for at se hvilke der kunne nedsætte systemets kompleksitet og gøre det nemmere for os at udvikle dette. 13 / 43

14 Nogle datastrukturer er blevet drøftet, andre er taget i brug og en enkelt er blevet kastet væk igen. Vi lagde nogle tanker i om man kunne bruge en binærtræstruktur til at udregne en Walkers bevægelse, hvor man kunne bygge træet op sådan, at det øverst punkt var det Ground Element Walkeren stod på, og hvert lag nedad i træet repræsenterede x-aksen i banen. Derved ville Walkeren egentligt kunne bevæge sig nedad i træet i den retning han går, og når der så ikke var flere muligheder at bevæge sig efter i træet, vender om og gå op og tilbage igen. Dog indså vi at denne struktur ville være mere omstændig at implementere, i forhold til den lille mængde af data som håndteres pr. Walker, da han kun skal forholde sig til en platform der er max 20 elementer lang. Vi arbejdede også i starten med ideen om at bruge en hjemmelavet datastruktur kaldet Level, som egentligt bare var en ArrayList med længden 400 (20 x 20), som implementerede interfacet for Iterator. Dette ville lette med overblik i systemet og give mulighed for at kunne udføre andre metoder på datastrukturen som ArrayList ikke understøttede. Men det gik op os at den datastruktur egentligt bare var overflødig da vi ikke havde brug for andre funktioner, samt vi ville håndtere baner og deres indhold på andre måder, så den blev skrottet. Det gør vi ved bruge ArrayLists med længde som antallet af elementer i banen i stedet. Altså en simpel datatype. Vi anvender samtidig en anden hjemmelavet og meget simpel datastruktur, Position. Denne indeholder ikke andet end variabler for x- og y-koordinater, samt funktioner for at hente og ændre disse. Denne datastruktur letter overskueligheden af modellen, samt giver en konformitet i navngivningen. Ydermere anvender vi i ImageCache og SoundCache klasserne Maps-datastrukturer i form af HashTables. HashTables holder 2 sammenkædede data, en key og en value. Hvor keyen refererer til value en og samtidig er hver key unik. 6 Man kan på den måde kalde en funktion hvor man sender keyen med og derved får value en tilbage. På denne måde kan vi holde styr på både billedfiler og lydfiler, når f.eks. et unikt billede har en unik key. Samtidig kan man iterere over en HashTable, men mere om dette i afsnittet omkring Implementationen af Billeder. 6 Forelæsning d. 22. marts / 43

15 Posistionering og koordinatsystem Vi stod over for valget imellem at lave spillet grid-baseret eller i 2D koordinatsystem. Fordelene ved et gridbaseret spil ville være vi vil kunne bruge vores erfaringer, programopbygning og kodeeksempler fra Rabbithunt konkurrencen. En konkurrence som denne læsegruppe var dybt engageret i og var repræsenteret både på 1. og 2. pladsen. Men ikke desto mindre stod det hurtigt klart for os at vi ikke ville vælge det nemmere løsning med et grid. Vi syntes det ville være en god udfordring og samtidig så vi mange flere fordele ved koordinatsystemet. Ved hjælp af et koordinatsystem ville vi kunne flytte figurerne pr. pixels og derved gøre spillets grafiske del mere flydende og have flere muligheder for at positionere elementerne. Samtidig åbner et koordinatsystem op for større variation i elementernes størrelse. Et af problemerne var nu at finde ud af hvordan man kunne undersøge hvorvidt to elementer krydsede hinanden. I et grid vil man kunne spørge hvert felt hvad det indeholder og derved finde ud af om 2 elementer er på samme plads. Dette er essentielt i et spil hvor man har brug for at finde ud af om helten eksempelvis står på en stige, bliver ramt af et projektil eller er i frit fald mod afgrunden. Løsningen på kollisionsproblemet blev et kollisionsfelt. Hvert element har en usynlig kasse med mål tilpasset til elementets funktionalitet og grafiske repræsentation. Banedesign Da vi designede systemet skulle vi tage stilling til hvordan baner til spillet skal gemmes og håndteres skulle det være muligt for brugeren at lave sine egne baner? Vi tænkte os hurtigt frem til at den letteste måde for os selv at overskue og lave baner, var ved i en helt almindelige.txt-fil at have en matrice på 20 x 20 tegn som vist på figuren nedenfor. Man kan på denne måde repræsentere hele spillefeltet, ved at hver mulige spil element har et tegn i matricen. Tegnene er lavet så de til dels er både logiske og betydningen ikke er for kryptisk. 15 / 43

16 Jord og platforme man kan gå på er repræsenteret ved -, da disse i forlængelse af hinanden nemt kan ligne en platform. Det samme gælder stiger som er repræsenteret med H da disse i forlængelse af hinanden ligner en stige. Andre tegn er som set overfor, D, X og K, hvor D og K er forkortelse for ordene dør og nøgle på engelsk. X er hvor helten starten.? repræsenterer mere grafisk hvordan en Pickup ser ud i spillet. Ydermere findes W som er en tilnærmelse af hvordan pigge ser ud i spillet. De sidste 3 mulige tegn er lidt mere specielle. M er en Walker fjende, og V er tønder der falder ned. Denne skal placeres på øverste række af matricen, og gør at der falder tønder ned over hele banen. Indsætter man flere V er flere der flere tønder på én gang, forskellige steder. d / b er de skydende fjender og disse indsættes hvor fjenden skal stå med buen på bogstavet pegende i den retning som han skal skyde. Indsættes et b skyder han altså mod højre. Med disse tegn og var det muligt for os at skabe baner uden at skulle vise dem i spillet for at se hvordan de ser ud. Bare ved at danne overblik over matricen kan man nemt lave en udfordrende og drilagtig bane. Det kan spilleren også! Alle de baner som oprindeligt ligger i spillet, ligger i mappen Levels ved spillets destinationsmappe, og her kan man gå ind og se matricerne for banerne og ændre i dem, eller oprette sine egne filer med baner. Samtidig ligger der i hver banefil en kort oversigt over hvad de forskellige tegn betyder. Vil man lave sin egen bane kopieres evt. en af de eksisterende banefiler og den nye navngives levelx.txt hvor X er banenummeret, som f.eks. level2.txt er banen set på figuren ovenfor, og så kan man kreere det banedesign man gerne vil have. Lægger man dem i forlængelse af de eksister- 16 / 43

17 ende baner, kan man nemt (næsten) skabe sit eget spil med baner til flere times sjov. Hvordan banerne så omsættes til en egentlig bane i spillet, står der mere om senere. 17 / 43

18 Implementering Fra UML til kode I dette afsnit gennemgår vi hvordan og hvorfor vi har implementeret systemet som vi har. Vi har fremhævet de meste interessante klasser og hvordan de fungerer. Vi gennemgår hvordan baner bliver omsat fra tekstfiler til baner i spillet, hvordan vi tegner spillet så spilleren kan se hvad han spiller, hvordan gameplayet styres og fungerer, hvordan vi har fundet fejl i vores kode og hvordan mindre vigtige features er implementeret. Levelparser Vi ville gjerne ha muligheten for å lage nye levels og gi spilleren muligheten til å lage sine egne levels. Derfor valgte vi å hente informasjonen vi har behov for ut fra en tekstfil hvor elementene representeres av tegn. På den måten kan det enkelt gjøres endringer uten å krype inn i koden. Til gjengjeld blir vi nødt til å lese tekstfilen inn i programmet. Dette gjør vi i Levelparser. Den leser tekstfilen inn og genererer objekter basert på tegnene i filen. Disse kan hentes i to forskjellige metoder som returnerer en ArrayList med objekter. get- Moveables returnerer alle objekter som skal bevege seg og getstatics returnerer alle objekter som står stille. Dette for å slippe å regne ut plasseringen til de statiske objektene hver gang et frame skal tegnes. // Hentet fra parsefile() i LevelParser while (in.available()!= 0 && lines < 20) { String line = in.readline(); char code; for (int i = 0; i < line.length(); i++) { Levelparseren leser bare de 20 første linjene så all tekst som står under vil bli ignorert. I tillegg vil bruk av feil tegn bli ignorert. Tegn utenfor de 20 tegn per linje vil bli tegnet utenfor spillets spilleflate så de vil ikke kunne sees. Dermed skal det endel til før Levelparseren genererer fatale feil. Men vi har ikke lagt store ressurser i å feilsikre klassen så det vil nok være mulig å innføre feil via tekstfilen med level. Objektene blir generert i en løkke hvor alle tegnene i tekstfilen blir løpt igjennom. Det er tegnet som avgjør hvilket objekt som blir generert og Element ets Position blir avgjort av tegnets plassering i linjen (x) og hvilken linje (y). Der hvor det er nødvendig blir det også satt en retning. code = line.charat(i); 18 / 43

19 if (code == '0') { // luft else if (code == '-') { // ground statics.add(new Ground(new Position(i * Settings.PICWIDTH, lines *Settings.PICHEIGHT))); else if (code == H') { // ladder else if (code == 'D') { // door else if (code == 'K') { // key else if (code == '?') { // pickup else if (code == 'V') { // dropper Shooter dropper = new Shooter(new Position(i * Settings.PICWIDTH, lines * Settings.PICHEIGHT)); dropper.settype(settings.dropper); dropper.setdirection(direction.south); dropper.setspeed(1); moveables.add(dropper); else if (code == 'W') { // spikes else if (code == 'd') { // shooter-left else if (code == 'b') { // shooter-right else if (code == 'M') { // Walker, Texas Ranger else if (code == 'X') { // Helt else {// Noe annet lines++; Opprinnelig hadde vi designet og implementer Levelparser så den la tallkoden for alle elementene, også luft, inn i to lister. En som inneholdt alle statiske og en som inneholdt dynamiske. Posisjonen skulle da leses av fra plasseringen i listen. Denne løsningen fant vi ineffektiv og erstattet med en liste med objekter i, som ble dannet på samme måte som kan sees i koden over. Da vi besluttet oss for å bare sende de statiske objektene en gang fra GameController til GUIController endret vi dette til de to listene som kan sees over. Dette har fungert veldig godt og gir oss færre elementer å løpe gjennom for å beregne bevegelsene til helten og fiendene. GUI Den grafiske brugergrænseflade består af 10 klasser, hvor de 4 er visuelle klasser, altså vinduer, de 3 er Listener-klasser som holder styr på brugerens adfærd. De sidste 3 er noget mere specielle og vil derfor blive redegjort for herunder. Derudover er der en GUIController klasse som holder styr på GUI en og som er den klasse der bliver kaldt når der skal ske opdateringer i GUI en. Vi gennemgår her klasserne i den rækkefølge som spilleren oplever dem. Den første klasse er den visuelle MainWindow klasse, da det er den klasse som er spillets primære vindue, den holder både menuen, KeyListener for spillet, information om spillet, liv og score, samt den grafiske repræsentation 1: MainWindow classen 19 / 43

20 af spillet. Samtidig gør den at hvis det vindue lukkes, lukkes spillet. Information om spillet vises øverst vha. af 2 JLabels som hver især identificerer hvilken slags information det handler om, Lives eller Score som 2 andre JLabels, hvor det ene holder et ikonet af hovedperson samt antallet af liv, og det andet pointene spilleren har. Nedenunder vises selve spillet, som udgøres af det store synlige GamePanel, der på figuren ovenover vises med splashscreen, oven på GamePanel et ligger et mindre og usynligt JLabel, kaldet textonscreenlabel dette JLabel bruges til at vise informationer om hvilken slags genstand man har samlet op i spillet. Fælles for de 2, samt ikonet i toppen, er at de indeholder grafiske elementer. Alle grafiske elementer i spillet loades vha. vores ImageCache klasse. Grafikken Til spillet findes 48 forskellige unikke grafikfiler. Disse er gemt i folderen gfx/ i spilmappen og alle er af filformatet.png 7 med en gennemsigtig baggrund. Alle har en størrelse på 20x20 pixels for at passe til den måde vi positionerer på. Det relativt høje antal af filer består af nogle baggrunde, splashscreen grafikken, samt en masse små billeder passende til elementerne, såsom grafik for Ricky, grafik for en gående fjende osv. Man kunne have valgt at lave ét stort billede med alle grafik delene i, som man så loadede ind i systemet for så at mappe hver lille del med koordinater og størrelse. Den metode har i forhold til vores anvendte, den fordel at man kun har én grafikfil at jonglere med. Samtidig ville det dog betyde at man i brugen af billederne i systemet ville skulle angive koordinater for billederne, og på den måde gøre koden meget mere kompliceret at overskue. Med vores måde er det nemmere at overskue filerne da disse har sigende navne, såsom key.png og dooropen.png i stedet for et mere usigende koordinat. Samtidig er vores anvendte metode mere fleksibel overfor udvidelser da man bare kan oprette nye grafikfiler og så skal gøre systemet opmærksom på hvad de nye filer hedder. Med ét billede kunne man være nødt til undervejs at skulle ændre alle koordinater, hvis man skal have tilføjet et stykke grafik et specifikt sted i det store billede. 7 Portable Network Graphics 20 / 43

21 Implementering af billeder Implementering af billeder foretages af klassen ImageCache - man kan se ImageCache klassen som et bibliotek med billeder, samt tilhørende kartotek. ImageCache består primært af 2 HashTables: en med et integer (int) som et ID, samt en String for filnavnet på billedet, og en med det samme integer (int) som integer (int), samt det loadede billede et såkaldt BufferedImage. Idet ImageCachen instansieres fyldes den første HashTable, kaldet filenames med integers og strings, og derefter loades billederne ind i den anden HashTable, kaldet images. Dette gøres ved at iterere over filenames vha. af en Enumeration type. For hvert element i den første HashTable oprettes et tilsvarende BufferedImage objekt, som hentes fra den position angivet i strengen i filenames. BufferImage objekterne puttes så ind i den anden HashTable, og dette BufferedImage kan så refereres til via dets ID gennem Image- Cache s getimage() metode. Altså fungerer ImageCache som biblioteket, hvor man i kartoteket images kan spørge efter lige det stykke grafik man skal bruge. På den måde kan enhver klasse der kender Image- Cache anvender de indlæste billeder. Kigger man nærmere i ImageCache ser man, at nogle billedfiler er repræsenteret flere gange med forskellige ID. Dette er ingen fejl, men dette er for at passe overens med den element type der skal bruges grafik til. ID er ID erne for billederne i ImageCache er ikke tilfældigt valgt, og tager man et hurtigt overblik, danner der sig hurtigt et mønster: ID erne fra 0 til 6 henviser til statiske elementer, og døren, ID erne fra 10 til 18, henviser til alle billeder der viser Ricky i alle mulige positioner, ID erne i 20 erne henviser til Walkerfjenden osv. Her vises henvisningerne til grafikken for Walker, med navngivning. ID 24 har han fødderne plantet på jorden, altså bevægelse 1 mens han har retning mod venstre, som vist her på figuren, mens ID 29 er billedet hvor han har fødderne løftet altså bevægelse 2 mod venstre. filenames.put(24, new String("walker1-left.png")); filenames.put(29, new String("walker2-left.png")); filenames.put(22, new String("walker1-right.png")); filenames.put(27, new String("walker2-right.png")); 21 / 43

22 Dette er for det første igen for at gøre det nemmere at overskue, men også for at gøre det nemmere at animere. For Ricky findes 4 billeder for begge retninger, højre og venstre, 2 for både op og ned, samt 4 mere for begge retninger, højre og venstre, men denne gang lysende rød imens han er udødelig. Eksempler på disse kan ses her til højre. På denne måde ser det ud som, ved at skifte mellem billederne, at Ricky og Walker fjenden går, den skydende fjende skyder, det ser ud som Ricky kravler på en stige osv. Animation Vi har valgt at lave animationerne til vores figurer meget i stilens ånd, dvs. meget simple men stadig effektive. Da animationen kun består af 2 forskellige billeder, kan vi nøjes med periodiske at skifte frem og tilbage imellem. Måden animationen bliver implementeret ligger i Rickys og Walkers swapimage() methode. Denne methode bliver kaldt hver gang deres positioner bliver sat. SwapImage() tæller for hver gang den bliver kaldt, et tal (i) op. Når dette tal når 6, skiftes typen på Ricky eller Walker matchende til det andet billede i animationen i ImageCache. Som det ses i nedenstående eksempel ligger Walkers billede ID for bevægele 2, 5 numre over bevægelse 1. public void swapimage() { this.i++; if (i == 6) { i = 0; if (imageno == 0) { imageno += 5; else { imageno -= 5; super.type = Settings.WALKER + super.direction + imageno; GamePanel Når vi har konstrueret ImageCache kan vi bruge grafik i spillet. Dette gøres, som nævnt, primært i GamePanel klassen, som viser selve spillet når det kører, samt splashscreenen når det ikke gør. GamePanel klassen nedarver fra Swing komponenten JPanel, for at være mulig at tegne på. GamePanel bruger metoden paintcomponent(), som nedarves fra superklassen og overrides i GamePanel klassen, til at tegne med. GamePanel har fungeret i 2 versioner gennem udviklingen af spillet: Den første version nedarvede fra AWT komponenten Canvas, og den anden som omtalt JPanel. At få GamePanel til at tegne vha. superklassen Canvas var ikke det store problem, og det fungerede også helt udmærket. Grunden til at klassen blev stort set fuldstændigt omskrevet var at der var en del flimmer når man opdaterede skærmen. Efter en del research viste det sig at man på både Canvas og JPanel tegnede ved først at rydde komponentens grafik og så tegne direkte på det igen. Selve tegne-operationen går ikke hurtigt nok til at være hurtigere end computerskærmens op- 22 / 43

23 dateringsfrekvens, hvilket i sidste ende resulterer i at der forekommer flimmer på skærmen. Metoden til at rette dette problem var at bruge et komponent der anvender den såkaldte teknik double buffering såsom alle Swing komponenter, heriblandt JPanel. 8 Double Buffering Double buffering går ud på at når man tegner, tegner man ikke direkte på komponenten, men derimod på et off-screen -billede, som ikke ses af brugeren. Man udfører så først alle tegneoperationerne på det off-screen-billede, og til sidst overfører man så det hele store billede over på skærmen, da denne tegneoperation kun indebærer overførslen af ét billede, og det går hurtigere. Dette gøres i skærmens egen opdateringsinterval, og derved undgår man flimmer. paintcomponent GamePanelet har 2 primære public tegne metoder, drawlevel() og updategui(). Begge får en iterator med, drawlevel() får en iterator med statiske objekter, og updategui() får en iterator med de bevægelige objekter. drawlevel() kaldes én gang for hver bane der skal tegnes, og updategui kaldes konstant mens man spiller den bane, updategui() sørger for at komponenten bliver gentegnet. Når den gentegner kaldes metoden paintcomponent(), Selve tegnealgoritmen i paintcomponent(), sørger først for at tegne rammen omkring spillet. Dette kunne også være gjort i MainWindow klassen, men denne måde virkede mest tilgængelig. Hvis GamePanel skal tegne splashscreenen, gør den det, eller også tegner den billedet af banen samt baggrunden. int backindex = (int) (Math.random() * 2); level.drawimage(imgcache.getimage(backindex + 97), 0, 0, this); if (leveliterator!= null) { while (leveliterator.hasnext()) { el = leveliterator.next(); level.drawimage(imgcache.getimage(el.gettype()),el.getposition().getposx(), el.getposition().getposy(), this); Dette er algoritmen der tegner banen. Først tegnes baggrundsbilledet valgt mellem 2 tilfældige, som hentes via ImageCache klassen ind på et nyopettet billedobjekt, level. Derefter tegnes baneelementerne ovenpå baggrunden, ved at bruge en iterator med ele- 8 Bilag 1: pr. 23. Maj / 43

24 menterne. Hvert element tegnes med grafikken svarende til dets type og på den position specificeret i elementet. Ser man nærmere på selve drawimage() metoden, lægger man mærke til this som det sidste medsendte argument. Metoden kræver at man sender en ImageObserver med, og man sender så hele klassen med. Dette er fordi ImageObserver er en interface klasse som alle komponenten implementerer, der betyder at de kan holde øje med hvornår et billede bliver konstruktet. I vores tilfælde har det ikke den store betydning, men i andre grafiktunge applikationer kan man med ImageObserver holde mere præcis styr på flowet i grafik konstruktionen og på den måde have mere kontrol over flowet. Men da vores spil ikke har særlig tung grafik, bruger vi bare den anvendende klasse til at kontrollere flowet. 9 Algoritmen for at tegne de bevægelige elementer på GamePanel et, minder meget om den ovenstående. Her tegnes i stedet for baggrunden, oven på det nye billede med baneelementerne påtegnet, hvilket gør at paintcomponent(), når level er tegnet én gang, kun tegner de bevægelige elementer ind på deres nye positioner, så man opnår en flydende animation. Samtidig afviger algoritmen ved at være omsluttet af synchronized(it){[...] Dette er for at sikre at den ArrayList der tegnes ud fra, ikke bliver ændret mens man tegner. F.eks. at et element bliver slettet fra listen idet man er ved at tegne det selvsamme element. Dette vil selvfølgelig kaste en fejl af sig, dog ikke når man bruger synchronized, som sørger for at kun én klasse kan arbejde med det specificere objekt som refereres til i metodens medsendte argumenter. I det her tilfælde it som er en iterator med de bevægelige elementer. AlphabetRun og HighScoreWindow Når Ricky ikke har flere liv tilbage, og spillet er slut, og man har højt nok score til at komme på highscoren, vises HighScoreWindow-vinduet og hertil bruges klassen AlphabetRun. Vi ville lave en klasse der sammenkoblet med HighScore-klassen afspejlede de gode gamle highscore input skærme, hvor man kun kunne indtaste 3 bogstaver, og det ved hjælp af piltasterne på tastaturet. Samtidig skulle det aktive bogstave blinke, så man kan se hvilket der bliver ændret i. At det aktive bogstaver blinker er en ren visuel feature der foretages ved konstant at udskifte den streng der står i textfeltet med den samme streng, hvor det aktive bogstav er udskiftet med _ tegnet og så skifte det tilbage til den oprindelige streng igen. Såvidt vi 9 Bilag 2: pr. 23. Maj / 43

25 kunne finde ud af har Java ikke en indbygget funktion til at skifte dele af strenge ud, så vi skrev vores egen: private streng replace(streng s, int i, streng with){ char c; streng tempstreng =""; for (int j = 0; j < s.length(); j++) { if (j == i){ c = with.charat(0); else { c = s.charat(j); tempstreng = tempstreng + c; return tempstreng; Med ovenstående funktion kan man udskifte ét tegn i en streng med ét andet tegn i en streng på index et i. Det gøres ved at gennemløbe den streng hvori noget skal udskiftes, og lægger alle dens tegn i en ny streng, undtagen det tegn som skal udskiftes. Det nye tegn lægges i stedet i den nye streng og denne returneres. Bemærk, at denne funktion kun kan udskifte ét tegn i en streng, og den tager ikke højde for hvis man prøver at skifte flere. Funktionen skulle dog være mulig at omskrive til at kunne erstatte med længere strenge, men dette var ikke nødvendigt i vores henseende. HighScoreWindow har samtidig en KeyListener som anonym indre klasse, der gør det muligt for os at lytte på spillerens piltastetryk. Vi valgte at lave den som en anonym indre klasse, da dette lettede overskueligheden i gui-pakken, og denne KeyListener indeholder ikke nok funktioner til at den kan retfærdiggøre at have sin egen klasse. Det næste problem vi stod overfor var hvordan man skulle kunne gennemløbe alfabetet samt tallene fra 0-9 som enhver anden nostalgisk highscore. Dette gjorde vi ved at have en anden klasse kaldet AlphabetRun som indeholder en langt ArrayList med alle engelsk tegn, altså intet æøå, og de 10 tal. Ved at kalde AlphabetRun s changeindex metode kan man så at sige bladre alfabetet igennem. public String changeindex(char character, int direction) { String s = new String(""); s += character; int getindex = alphabet.indexof(s); if (direction == Direction.NORTH) { getindex = alphabet.indexof(s) + 1; if (getindex == alphabet.size()) { getindex = 0; [ ] return alphabet.get(getindex); 25 / 43

26 Først finder man index et af det valgte tegn, og lægger, hvis brugeren trykker op (NORTH), værdien 1 til index et, og til sidst returneres det tegn der har det nye index. Samtidig hvis man er ved det sidste index i alfabetet startes der forfra. På skrivende tidspunkt står det aktive tegn bare og blinker som omtalt ovenfor, og dette giver næsten den ønskede effekt. Dog fungerer det ikke helt som de gode gamle spils highscore, men det kan være at det ved rapportens aflevering er ændret en smule hvornår tegnet blinker det vil ikke have nogen påvirkning på ovenstående funktioner. Control Control delen i brugen af MVC patternet udgøres primært af KL klassen, lytter på hvad der foregår i MainWindow klassen og agerer derefter. My Comfort Zone For at kunne registrere hvornår et Element rammer et andet, bruger vi en såkaldt collisionbox. Hvert element har en collisionbox, en usynlig kasse med mål tilpasset til elementets funktionalitet og grafiske repræsentation. Når et Element skifter position i koordinatsystemet bliver den tilhørende collisionbox samtidig flyttet. public Element(Position pos) { this.position = pos; this.collisionbox = new Rectangle2D.Double( position.getposx() + offsetx, position.getposy() + offsety, width, height); Som det fremgår af ovenstående eksempel har hver Element et offsetx, OffsetY, width og Height. Som standard er de 4 variabler sat til at passe til et Element med målene 20x20 pixels som er størrelse på det meste af vores grafik. Variablerne bruges hvis collisionbox adskiller sig fra disse mål. Som det fremgår på figur 1 er stigens collisionbox mindre end selve billedet, derved kan helten først komme op af stigen når han nærmer sig midten og ikke allerede i udkandten af stigen. CollisionBox er af typen Rectangle2D. Da Rectangle2D har en indbygget metode til at se om to Rectangle2D kollidere er det nemt at tjekke om 2 Elements rammer hinanden. Det er ved hjælp af collisionbox at hovedparten af funktionaliteten i spillet fungerer. GameController GameControlleren er den klasse i spillet som bærer det største ansvar for hele gameplayet. For at gøre programmet mere overskuelig har vi valgt at dele GameControlleren op i tre dele. Derfor forbinder GameControlleren de tre klasser EnemyMoveHandler, Hero- MoveHandler og HeroCollisionHandler. Disse 3 klasser tager sig af hvert sit område i spillet. GameController sørger for at der startes en ny bane i spillet. try { this.levelparser = new Levelparser(System.getProperty("user.dir") + "/Levels/level" + levelno + ".txt"); 26 / 43