Semesteroppgave 1: “Rogue One oh one”

• README
• Oversikt – Praktisk informasjon 5%
• Del A: Bakgrunn, modellering og utforskning 15%
• Del B: Fullfør basisimplementasjonen 40%
• Del C: Videreutvikling 40%

Dette prosjektet inneholder Semesteroppgave 1. Du kan også lese oppgaven online (kan evt. ha små oppdateringer i oppgaveteksten som ikke er med i din private kopi).

Innleveringsfrist:

• Del A + minst to deloppgaver av Del B skal være ferdig til fredag 9. mars kl. 2359.
• Hele oppgaven skal være ferdig til fredag 16. mars kl. 2359 (AoE)
• Ekstra tips til innlevering

(Kryss av under her, i README.md, så kan vi følge med på om du anser deg som ferdig med ting eller ikke. Hvis du er helt ferdig til den første fristen, eller før den andre fristen, kan du si fra til gruppeleder slik at de kan begynne å rette.)

Utsettelse: Hvis du trenger forlenget frist er det mulig å be om det (spør gruppeleder – evt. foreleser/assistenter hvis det er en spesiell situasjon). Hvis du ber om utsettelse bør du helst være i gang (ha gjort litt ting, og pushet) innen den første fristen.

• Noen dagers utsettelse går helt fint uten begrunnelse, siden oppgaven er litt forsinket.
• Hvis du jobber med labbene fremdeles, si ifra om det, og så kan du få litt ekstra tid til å gjøre ferdig labbene før du går i gang med semesteroppgaven. Det er veldig greit om du er ferdig med Lab 4 først.
• Om det er spesielle grunner til at du vil trenge lengre tid, så er det bare å ta kontakt, så kan vi avtale noe. Ta også kontakt om du trenger annen tilrettelegging.

Fyll inn egne svar/beskrivelse/kommentarer til prosjektet under

• Levert av: Kristian Knarvik (kkn015)
• Del A: [x] helt ferdig, [ ] delvis ferdig
• Del B: [x] helt ferdig, [x] delvis ferdig
• Del C: [ ] helt ferdig, [X] delvis ferdig
• hele semesteroppgaven er ferdig og klar til retting!

Del A

Svar på spørsmål

a)

• IGame trenger et game map (IMapView) der ting kan plasseres. Den trenger også en referanse til brukergrensesnittet for å endre tekst og grafikk. Den trenger en TurtlePainter for å tegne grafikk. Den trenger en referanse til et Printer objekt til å (antagelig) printe fancy tekst.
• IMapView må ha en referanse til et objekt som implementerer IArea.
• Et IItem må ha et navn, en int som representerer hp, en annen int som representerer maksimal hp, en int som representerer størrelsen, og en int som representerer forsvar. Den må også ha et symbol som representerer en ting når den blir tegnet.
• En IActor er lik et IItem, men har i tillegg to int som representerer angrepsstyrke mot et IItem og en IIactor. Den kunne lagret en posisjon, men om det er en fordel spørs på implementasjonen av utførelsen av en tur.
• En INonPlayer ser ut til å være lik en IActor, men kan flytte seg selv.
• En IPlayer ser ut til å være lik en IActor, men kan gjøre mye rart ut ifra hvilken tast spilleren trykker.

b)

• IGame ser ut til å være på toppen, og behandler IMapView. IMapView holder styr på områder IArea. Hvert IArea holder styr på alle IItem (som også inneholder alt som utvider IItem). Noen typer IItem er av type IActor. Alle IActor er enten av type IPlayer eller INonPlayer. IPlayer og INonPlayer kan forsåvidt direkte manipulere IGame, så alt går egentlig litt i ring.

c)

• Jeg tror splittingen av IGameMap og IMapView er for å lettere kunne lage tester. IGameMap trenger en TurtlePainter, og da også en GUI. GUI er ikke særlig kompetibelt med tester. Den eneste andre logiske grunnen vil være for å kunne bruke IMapView til andre formål. For eksempel å simulere et kart med bare INonPlayer, gi dem lov til å drepe hverandre, og se hva som skjer etter 10000 steg.

d)

• Jeg tror INonPlayer og IPlayer er forskjellige for å ikke blande dem når en skal sjekke om hvem som kan flyttes hvor, og hvem som kan angripe hvem. De kunne alltids hatt en boolean player (dersom fiender ikke skal begynne å angripe hverandre) og en metode som tok inn game, og en annen som tok inn game og keypress. Det er litt teit å ha en boolean som er lik for alle objekter bortsett fra en. En fordel med å splitte dem opp, er at jeg enkelt kan lage en IImmovablePlayer som kan overskrive metoden som angriper den til at han/hun åpner butikken sin, eller gir meg et quest.

e)

• Det var uforventa at nesten alle tilstandsverdier ble hardkodet i stedet for å lagres i en variabel. Det gir mening når alle objekter er helt identiske (til å begynne med). Fordelen er at ting kan ha ganske unike implementeringer, men det virker litt "skittent".

f)

• Rabbit finner ut hvor den er ved å bruke Game sin getLocation(). Rabbit finner ut hvilke andre ting som er på stedet ved å bruke game sin getLocalItems(). Rabbit finner ut hvor den har lov å gå ved å bruke game sin canGo() (senere kan getPossibleMoves() hjelpe til).

g)

• GetLocation blir brukt når Game utfører turns. Game henter hvert objekt IActor og henter med en gang posisjonen fra Gamemap sin getLocation som henter verdien fra en hashmap. Jeg har aldri vært borti hashmaps i java, men det virker ekvivalent med måten Arrays virker i php. For eksempel: $items = array(rabbit1 => pos1). Når en da henter $items[rabbit1], vil en få pos1.

Del B

Svar på spørsmål

a)

• Nabo-celler blir behandlet en del annerledes, siden det skal være mulig å finne celler en viss avstand fra et punkt. I tillegg til at alle celler som er utenfor skal ignoreres, og være sortert. Det blir håndtert med en tilsynelatende ganske "skitten" metode, men den fungerer fint. Måten å gjøre det på i Sem1 er mer praktisk, fordi det tillater å velge hvilket som helst størrelse på nabolaget.

b)

• De fleste spill-trekkene går igjennom game for å enkelt kunne utføre turen til alle objekter. Fordelene er at det er lett å få tak i all nødvendig informasjon, uten å måtte lage spesialiserte metoder, eller sende inn mange parametere. Ulempene er at alle IActors og IItem blir veldig sterkt knyttet til IGame. De kan ikke brukes uten å spesifikt opprette et objekt som implementerer IGame først, som forhinder dem i å bli brukt i hvilket som helst annet prosjekt.

c)

• Game.addItem burde strengt tatt sjekket at en IActor ikke blir plassert på en IActor. Det er ganske mye som ikke blir sjekket direkte, fordi en går ut ifra at brukeren vet hva den driver med. Dessverre er det ganske vanskelig å oppdage det sånn i forbifarten, med mindre det skaper en feilmelding.

d)

• Strukturen er definitivt mye mer kaotisk enn jeg først hadde trodd. Det er egentlig ganske vanskelig å finne det en er ute etter. I tillegg har jeg endret en del, som igjen endrer oppførselen til noen av de gamle klassene. Jeg har definitivt opplevd nye måter å gjøre ting på.

Del C

Oversikt over designvalg og hva du har gjort

• Oversikt over taster blir gitt til høyre for spillkartet.
• Main og Game har blitt endret til å tillate spilleren å selv velge når den har utført en tur. Dette har blitt gjort for å kunne ignorere uønskede tastetrykk, og for å tilby spilleren valg.
• Mye har blitt endret siden A og B, så noen ting kan ha blitt fjernet (automatiske gulrøtter har blitt kommentert ut).
• NPC inneholder hjelpemetoder som er felles for alle NPC, men oppfører seg svært ulikt basert på input.
• Spilleren kan bare se i et område rundt seg (området kan økes ved å bruke et IBuffItem). Spilleren kan se vegger bak en annen vegg. Dette er for å lettere observere strukturen av området (ikke en bug), og kan være til hjelp for å finne potensielle falske vegger.
• Spilleren og fiender som har noe i sekken sin, får endrede "stats" basert på våpen brukt, eller første IBuffItem. Dette gjør at spilleren må ta en del valg om hva som er mest viktig å ha med seg.
• Jeg har for det meste fokusert på implementering av grensesnitt som gjør det enkelt å legge til mange nye gjenstander (selv om jeg bare hadde fantasi og tid til å implementere noen få).
• Spillet har ganske få fiender, men jeg fokuserte mest på uforutsigbarhet rundt fiendetypen Girl.
• Grafisk er spillet blandet. Fonten fungerer relativt dårlig til gridet. I det minste er det bedre enn bokstaver, og lettere enn å bruke TurtlePainter.

Tredjepartsfiler

• Bow Fire Arrow (http://soundbible.com, Stephan Schutze, Noncommercial 3.0)
• Sword Swing (http://soundbible.com, Mike Koenig, Attribution 3.0)
• Large Fireball (http://soundbible.com, Mike Koenig, Attribution 3.0)
• Realistic Punch (http://soundbible.com, Mark DiAngelo, Attribution 3.0)
• Snow Ball Throw And Splat (http://soundbible.com, Mike Koenig, Attribution 3.0)
• Dying (http://soundbible.com, Mike Koenig, Attribution 3.0)
• 1 Person Cheering (http://soundbible.com, Jett Rifkin, Attribution 3.0)