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 onsdag 14. mars kl. 2359

(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, [ ] delvis ferdig
• Del C: [ ] helt ferdig, [ ] 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

• ...

Del C

Oversikt over designvalg og hva du har gjort

• ... blah, blah, er implementert i klassen KurtMario, blah, blah ITurtleShell ...