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: [ ] 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.

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.

Del C

Oversikt over designvalg og hva du har gjort

• Oversikt over taster: WASD og piltaster kan brukes til bevegelse. Q for å legge ned ting. E for å plukke opp ting. 1-5 for å velge hvilke ting du ønsker å legge ned eller plukke opp.
• 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.

Tredjepartsfiler

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