Modeller!

Domænemodel

Vi har fået præciseret vores domænemodel på baggrund af vores nylige overvejelser (se bilag). Modellen viser de overordnede bestanddele i spillet og sammenhængen mellem disse. Den viser, at både ’Monster’ og ’Player’ er characters og at det hele bliver samlet i en overordnet ’World’. I world er der levels, som består af tiles, hvoraf nogle er specialiserede tiles, som ikke kan passeres af characters. På udvalgte tiles ligger der ’Items’, som player skal samle op. I de første tre levels er der en gate, som ligeledes er placeret på et tile.

Domænemodellens primære funktion er at tydeliggøre de respektive elementer i spillet, hvorfor vi ikke vil uddybe nærmere her. I følgende klassediagram vil vi udspecificere og forklare de enkelte klasser.

Designmodel

Klassediagrammet har udviklet sig fra iteration til iteration og dette illustreres vha. farverne blå, grøn og rød, hvor rød viser processen i første iteration, grøn viser anden iteration og blå viser tredje iteration. Det skal dog tilføjes, at vi har ændret i klasserne efterhånden som der har været behov for det.

Tredje iteration - a work in progress

Denne iteration har vi endnu ikke overstået. MVC strukturen har gjort det forholdsvis simpelt at implementere en AI, dvs. Fjender. MoveableModel er forsåvidt ligeglad med, hvilken controller kalder dens metoder, og derfor kan vi nøjedes med at konstruere en ny controller klasse som kan interface med modellen. I stedet for at have en tastaturstyret controller, brugte vi timere som gennem hvert andet frame vurderede fjendens næste træk. Først handlede det blot om at give fjenden mulighed for at bevæge sig tilfældigt rundt. Derefter gjorde vi controlleren opmærksom på spillerens position, og udbyggede dens egenskaber til at kunne forfølge spilleren. Dette krævede implementeringen af path-finding som gør AI’en i stand til at finde rundt om forhindringer. I et forsøg på tydeliggøre ansvarsområder valgte vi at placere pathfinding funktionaliteten i en seperat klasse. Derudover måtte den enkelte pathfinding klasse danne sig et selvstændigt billede af kortet, for at sikre at flere monstre på samme tid kan benytte sig af pathfinding (det nytter ikke noget at flere monstre redigerer i de samme variabler i forbindelse med algoritmens udførsel). Vores use-cases beskrev yderligere at fjender skal kunne spotte spilleren. Dette blev løst ved at beregne afstanden fra det enkelte monster til spilleren, og på baggrund af retningen monstret vender i forhold til spilleren, vurdere om spilleren er spottet. Er dette tilfælde ophøre fjendens tilfældige spanguleren rundt på kortet, og pathfinding funktionaliteten tages i brug.
Det næste skridt i denne iteration, bliver at spiller og monster mulighed for at angribe hinanden, hvilket vil kræve nye modeller for player og monster, som naturligvis kan benytte funktionaliteten i MoveableModel. Derudover bliver monstre placeret tilfældigt på scenen på nuværende tidspunkt, hvorfor de altså også kan blive placeret midt i et træ – giver lidt sjove fejl, men dette er kun midlertidigt for at teste vores AI.

Anden iteration

Ved at bruge MVC fra starten har vi sikret at koden er let at udbygge og ansvarsområder for de enkelte klasser er tydeligt definerede. For at begynde at skabe en egentlig tilebaseret verden lavede vi en level klasse som kunne håndtere flere statiske tiles, hvis funktion er at styre hvorvidt de kan betrædes, og derudover hvilken type de er (græs/sten/træ osv). Derudover ønskede vi at sikre at det var let at lave nye levels uden at ændre direkte i koden, ved at loade dem fra en xml-fil. MoveableModel klassen måtte derfor udbygges således at man ikke kan bevæge sig hen på en tile som ikke kan betrædes.
Tilslut tilføjede vi View klasser som kunne vise vores kort således som det var defineret i et Level objekt, og lavede en klasse som kan vise vores nye MoveableModel. Dermed havde vi nu et simpelt grafisk interface, hvor vi kunne følge vores bevægelige objekt idet vi interagerede med det gennem tastaturet.
Til næste iteration besluttede vi at det nu var på tide at få fjender på banen, og evt. et begyndende kampsystem.

Første iteration

I denne iteration implementerede vi den grundlæggende struktur i spillet. Vi tog udgangspunkt i MVC mønstret og startede med at lave grundlæggende klasser som understøttede MVC strukturen. BaseModel, BaseView og BaseController er således abstrakte klasser som udelukkende er til for at facilitere de grundlæggende egenskaber ved MVC mønstret. Dernæst konstruerede vi klasser som understøttede den tile-baserede struktur vi ønskede spillet skulle have. TileModel klassen har således et meget afgrænset ansvarsområder, nemlig at holde styr på en tiles placering på kortet (det grid af tiles som tilsammen udgør det level som spilleren kan bevæge sig på), og dens faktiske placering på scenen i pixels. Det skal med det samme nævnes at TileModel ikke udtrykker et statisk ”felt” som enkelte felter på et skakbræt, men blot et objekt som placerer sig i et grid som ikke nødvendigvis svarer til pixels på en scene.
Vi gjorde os det klart fra starten at målet med denne iteration ikke var at få noget grafisk, men blot en grundstruktur og muligheden for at ændre placering på banen med tastaturet. View-delen i MVC strukturen blev derfor udbygget med egentlig grafik, men tracede blot væsentlige attributter i modellerne.
Vi ønskede at tilføre vores model en mulighed for at flytte placering på vores grid. Ved at nedarve fra TileModel fik vi den grundlæggende funktionalitet til at holde styr på vores færden i en tile-baseret verden. Klassen fik fra start kun få metoder som gjorde os i stand til at ændre placering på baggrund af en retning som var statisk definerede strings (”up”, ”down”, ”left”, ”right”). Dernæst oprettede vi en controller klasse som kunne modtage tastetryk og fortolke disse til instruktioner til modellen om at ændre placering i en bestemt retning. Tilslut ønskede vi at vise ændringer i placering ved at forbinde en Viewklasse til vores MoveableModel som kunne trace ændringer når vores model ændrer placering.
Med denne grundlæggende funktionalitet havde vi nu overstået en væsentlig del af spillets grundstruktur. Vi havde eksekverbar kode som uden videre ville kunne viderebygges til at understøtte grafisk elementer på en scene. Vi havde imidlertid ikke noget kort at bevæge os rundt på endnu og derfor ingen mulighed for at begrænse spilleren (og eventuelle fjender) i at bevæge sig på. Dette, og en simpel grafisk repræsentation, vurderede vi var de vigtigste elementer at få med i næste iteration.

Usecases

Usecase 1 – At vinde spillet

For at vinde spillet skal player på de første tre levels samle en nøgle op, som er adgangsgivende til næste level. Når spilleren når til 4. level, skal den kæmpe mod et monster og dræbe dette for at vinde spillet.

Usecase 2 – At komme videre til næste level

Spilleren navigerer hen til nøglen og idet den bliver samlet op, skifter farven på gaten, som indikerer at det er muligt for spilleren at komme videre til næste level. Spilleren går hen til gaten og kommer videre til næste level.

Usecase 3 – Kampsituation

Spilleren når op ved siden af monstret og angriber monstret hvorved den påfører monstret skade. Spilleren angriber igen indtil monstret har mistet alle sine HP. Monstret er nu dræbt og forvinder fra banen.

Glossary

Vi har udformet en beskrivelse i vores glossary, med en kortfattet forklaring af elementerne i vores spil.

World: Denne samler de nedenstående elementer.

Tiles: Vores interface er opbygget ud fra tiles. Man kan forestille sig tiles, som et enkelt felt på et skakbræt. Denne kan indeholde genstande, som kan være i vejen for playerens bevægelse og kampmuligheder, i form af sten, træer etc.

Level: Man når til næste level, ved at nå fra den ene ende af banen til den anden. Undervejs, skal man nå at dræbe alle fjenderne. Om dette er den eneste forudsætning er dog endnu ikke helt afgjort.

Player: Vores player går rundt i banen, og skal angribe de monstre som den møder på sin vej. Under kamp, har playeren et våben, til at kæmpe med. I kamp, kan playeren tage skade, og miste hit-points. Over tid, vil disse dog blive genvundet, hvis man undgår skade.

Monster: Monstrene er ude på at skade playeren, hvis de kommer i kontakt med ham. Vi udformer AI på monstrene, så de i form af path-finding har mulighed for, at finde den korteste vej hen til playeren, så de kan angribe ham.

AI: AI er en forkortelse for artificial intelligens og kan oversættes til kunstig intelligens. I spillet får monstrene kunstige intelligens, som giver dem mulighed for, at vide hvor og hvordan de hurtigst og bedst muligt kan angribe playeren.

Weapon: Playeren har et våben, som giver mulighed for at angribe og forsvare sig.

Ranged: Skyder man med sit våben, bliver det varmere, hvilket former en begrænsning af skydemulighederne. Bliver det for varmt er man altså nødsaget til, at vente på at våbnet lader op, med nye skud.

Melee: Playeren besidder også et slagvåben til brug i nærkampsituationer. Om dette våben giver mere skade end et ranged våben er endnu ikke afgjort.

Iteration Plan

I elaboration fasen begynder vi at nærme os mere præcise requirements (vores vision for spillet) - det vil sige en fortsættelse af arbejdet i inception fasen.

- Detaljerede use-cases

- Mere detaljeret domæne model

- Begyndende design model

- Vurdering af høj-risiko elementer og dermed hvilke elementer vi skal tackle først

- Begyndende kode af grundstruktur

Som Larman skriver, så er elaboration ikke en designfase, og vi skal altså ikke have færdige klasse diagrammer klar til kodning. Målet bliver i første

omgang at danne et indtryk af projektets omfang og så tidlig kodning som muligt.

Use-case

Angreb på monstre (ranged)

Spilfiguren peger i retning af et monster og affyrer sit våben. Monstret mister livpoint i dette tilfælde da spilfigurens angreb er succesfuldt og inden

for monstrets rækkevidde.

Monstret bevæger sig mod spilleren for at initiere et angreb. Det når hen til spilfiguren som tager skade efter monstrets

succesfulde angreb. Spilleren angriber igen ind til monstret er slået ihjel. Spilleren hviler ind til hans livpoint er genopbygget.

Adgang til næste level

Spilleren har slået alle monstre ihjel. Han bevæger sig til højre ende af kortet hvorefter han træder ind til venstre på et nyt kort.

Domænemodel

For at overskueliggøre vores overvejelser i forbindelse med spil- programmeringsprojektet, har vi lavet en domænemodel, som - helt overordnet - illustrerer de forskellige elementer, der kommer til at blive en del af vores spil.

Vi viser her modellen:

Denne model viser de overordnede bestandele i spillet, og viser sammenhængen mellem disse. Den viser, at både "Monster" og "Player" nedarver fra "Character", og det hele bliver samlet i en overordnet "World".

Elementet "Weapon", som er vigtig i et "tile-baseret action-spil" som vores, har to underelementer: "Ranged" og "Melee", der udtrykker de to forskellige angrebsmuligheder, som bliver stillet til rådighed for spillets Player. Begge elementer er udtryk for våben, og nedarver derfor fra "Weapon".

Man kunne sagtens udlede mere fra modellen, men da dens primære funktion er at tydeliggøre de respektive elementer i spillet, vil vi ikke komme nærmere ind på det her.

Feasible pathfinder - prototype, as in non-production ready code

Da vi igår nat stykkede en pathfinding funktion sammen, var det uden at overveje dens effektivitet. Spillet bliver imidlertid yderst afhængig af at monstre bliver i stand til at finde vej uden at skulle stå og tænke sig om i længere tid af gangen. Ved at bruge getTimer() funktionen i ActionScript har vi fået optimeret spillet således at det sjældent tager mere end et par millisekunder at finde vej fra den ene side af kortet til det andet - en situation som oftest ikke en gang bliver relevant.

For at teste algoritmen autogenerede vi et tilfældigt kort (dog med et på faste vægge) og placerede et start- og slutpunkt tilfældige steder på kortet. Derefter målte vi, hvor lang tid det tog for computeren at finde vej. For at få en bedre idé om hastigheden lod vi computeren lave 20 kort, for derefter at finde vej i dem. Tiden for disse 20 kort blev lagt sammen. Denne proces blev gentaget 20 gange for at finde en gennemsnitlig beregningstid på de 20 kort.

Resultatet blev at computeren kunne finde vej på 20 kort i løbet af omkring 25 millisekunder.

Dette resultat er nået uden voldsom optimering - faktisk vidste vores forsøg at optimering på den kortstørrelse vi opererede med, betød en væsentligt længere beregningstid! Den endelige implementering blev en forsimplet udgave af Dijkstra's algoritme.

Path found!

Overstående tegn forestiller et kort i samme størrelsesorden som vi forestiller os spillets map bliver.

Vi har nu lavet en simpel pathfinding funktion alene som proof-of-concept. Funktionen var så afgørende for gameplayet at vi nødvendigvis måtte undersøge, hvorvidt det var muligt. Det er en ganske ineffektiv algoritme, men da omfanget ind til videre ikke er tænkt at blive større end overstående er det tilstrækkeligt.

Og ja, computeren fandt vej:

Skrevet med udgangspunkt i http://www.policyalmanac.org/games/aStarTutorial.htm

En sen opdatering

Aftenen er indtil videre gået med arbejde på Path-finding funktionen, som i forbindelse med spillets fjenders kunstige intelligens skal kunne finde den letteste passage fra ét punkt til et andet.
Situationen er på nuværende tidspunkt rimeligt uklar: Det ønskede resultat er opnået én enkelt gang, men succesen har ikke været mulig at gentage. Konklusionen må dog være, at målsætningen er inden for rækkevidde.

Et udkast til en fjendetype har også set dagens lys. Det gruopvækkende monster har vel hentet sin inspiration i noget, som kunne ligne et spøgelse. Om væsenets angreb består i brug af det farlige "deadlight" fra IT eller om det bare er ild, er ikke afgjort.

Hér kommer animationen af det skrækkelige uhyre.
Først monstret i en fredelig tilstand:

Dernæst i attack-mode:

Interface og sprites

Billedet er en interface prototype som bestemt ikke er en endelig specifikation på hvordan spillet skal se ud. Det viser nogle af de idéer vi er kommet på til gameplayet, bl.a. temperaturmåleren på spillerens "ranged weapon" og spillerens liv.

Bemærk at det grid som synliggør de enkelte tiles ikke vil være at finde i nogen endelig implementation.

Sprites i billedet stammer fra Gameboy Color spillet LegendOfZelda - Oracle Of Seasons. Vi leger i øjeblikket med forskellige "hues" og farvemætheden for at ændre spillets "feel".

Vi har endnu ikke produceret nogle solide idéer til, hvordan spillets monstre og spilleren selv skal fremstilles visuelt.

Overstående figur tager udgangspunkt i Metal Slug hovedpersonen, men vi har endnu ikke taget stilling til om vi skal arbejde videre med ham.

Monstre sprites vil muligvis tage udgangspunkt i sprites fundet i spillet Battle of Wesnoth som har meget detaljerede sprites som passer nogenlunde med den spilmekanik vi forestiller os. De skal dog tilpasses, og det endelige resultat vil højst sandsynligt afvige kraftigt fra originalerne.

Tidlige overvejelser

Vi har gjort os nogle overvejelser i forbindelse med spillets udformning og ydre apparition - forestillinger omkring, hvordan det endelige produkt kunne blive.

Interfacet skal bestå af tiles, der hver især er 32x32 pixels. Selve scenen måler 1034 pixels i bredden, hvilket svarer til 32 tiles, og 385 pixels i højden dvs. 12 tiles. Brugen af tiles gør bevægelsen, interaktionen og udformningen af spillemiljøet mere håndgribelige i en programmeringsproces.

Hele scenen er som udgangspunkt synlig, så vi har fravalgt brugen af scrolling.

Eksempel på ét tile:

Bevægelse i spillet foregår fra tile til tile, hvorpå playeren kan interagere med objekter og fjender. Fjenderne skal gå tilfældigt rundt på banen og desuden have ”line of sight”, samt et ”detection-area”, så det bliver muligt at lytte på, hvor de skal finde og følge playeren. De skal også have en logisk fornemmelse af, hvordan de lettest muligt kommer hen til playeren. Dette kaldes path-finding, som er en del af den nødvendige programmering af fjendernes AI.

Man skal stå stille for at kunne kæmpe, hvilket reducerer det store antal af animationer, som ellers havde været nødvendige. Kommer playeren indenfor fjendens line-of-sight, vil fjenden automatisk angribe.

Hvis playeren bliver angrebet og tager skade, vil dette blive visualiseret i form af en bar nederst på scenen. Ligeledes vil man kunne se en bar over, hvor mange skud man har tilbage. Over tid vil man reproducere de tabte hitpoints fra angrebet. Det eneste der til gengæld begrænser muligheden for at skyde, vil være en "cool down"-funktion, som resulterer i en påkrævet pause, efter endt skudsalve.

Vi har besluttet at benytte grafik fra tidlige Zelda-spil i vores projekt, da vi dermed får mulighed for at fokusere mere på udformningen af selve koden. Indtil videre har vi fundet animationer af Zelda-helten ”Link”, som vil lette en besværligt animationsproces. Det grafiske udtryk vil dog ikke blive en direkte kopi af Zelda universet, da vores mål er at sætte vores eget præg på det endelige resultat.

Tidlig artwork

Under inception har vi arbejdet på at nærme os et spilkoncept som skal danne grundlaget for den videre udformning af spillet.

Med skitser som denne prøver vi at nå til enighed om spillets stil.

Valg af opgave

Vores overvejelser i forhold til valg af eksamensprojekt, går først og fremmest på, hvad der umiddelbart inspirerer os. At valget skulle inspirere os, har været en vigtig forudsætning, da vi derved af egen interesse kommer til at dykke ned i arbejdet. Dette vil være en god forudsætning, for at opnå det bedst mulige resultat. Dernæst går overvejelserne på, om valget giver os mulighed for at udfolde os rent kodningsmæssig og lader os – så vidt muligt - vælge egen retning for projektet. Dette er ligeledes en vigtig betingelse, da det naturligvis er vigtigt for os at kunne forevise et vist modellerings-, design- og kodemæssigt niveau i projektet. Ydermere gør dette os i stand til at vise kreativitet i processen.
Med udgangspunkt i disse overvejelser kommer vores valg til at ligge på første emne: Computerspil. Vi føler, at dette valg reflekterer vores forudsætninger og tanker om projektet.

Mvh. Gruppen

Hurra for nyoprettet blog.

Velkommen til vores blog. Der er endnu ikke meget at se, da ikke engang emnet for opgaven endnu er besluttet.
Mere vil snart komme til:
- ideer
- kode
- grafik


Mvh.