Commit f17e3526 authored by Anna Maria Eilertsen's avatar Anna Maria Eilertsen
Browse files

improved text

parent 5cddc8a9
......@@ -11,7 +11,7 @@
## Intro
Denne oppgaven går ut på å lage et program som lar en og to spillere spille [Fire på rad](https://en.wikipedia.org/wiki/Connect_Four) og [Tripp-trapp-tresko](https://en.wikipedia.org/wiki/Tic-tac-toe). To spillere skal kunne spille mot hverandre, og én spiller skal kunne spille mot en AI.
Denne oppgaven går ut på å lage et program for å spille [Fire på rad](https://en.wikipedia.org/wiki/Connect_Four) og [Tripp-trapp-tresko](https://en.wikipedia.org/wiki/Tic-tac-toe).
**Fire på Rad** spilles tradisjonelt ved at to personer slipper brikker av forskjellige farger ned i en tom, stående plastramme. Adskilte kolonner gjør at brikkene legger seg oppå hverandre og fargene danner rader loddrett, vannrett og diagonalt. Den første spilleren som klarer å få få fire på rad av sin egen farge vinner spillet.
......@@ -21,20 +21,21 @@ Denne oppgaven går ut på å lage et program som lar en og to spillere spille [
![](img/TicTacToe.gif)
## Krav til programmet
*Her beskriver vi funksjonelle krav til programmet og essensielle krav for å bestå.*
**Ditt program** skal støtte begge spillene. To spillere skal kunne spille mot hverandre, og én spiller skal kunne spille mot en AI.
## Krav til programmet
***Her beskriver vi funksjonelle krav til programmet og essensielle krav for å bestå.***
**Du må utvikle koden din selv.**
Du får kun utlevert et tomt Java-prosjekt og må lage klasser, pakker og tester selv. Løsningen blir vurdert på funksjonalitet, kodekvalitet, dokumentasjon og testing og at den viser forståelse av INF101-konsepter.
**Programmet må støtte både Tripp-trapp-tresko og Fire på rad.**
For eksempel kan man ved oppstart bli spurt om hvilket spill man ønsker å spille. Begge spillene skal oppføre seg i henhold til sine regler.
For eksempel kan man ved oppstart bli spurt om hvilket spill man ønsker å spille. *Begge spillene skal oppføre seg i henhold til sine regler.*
**Programmet må støtte både én og to spillere.** To spillere må kunne spille mot hverandre på samme maskin, for eksempel ved å ha hver sin tur til å gi input. Én spiller må kunne spille mot datamaskinen: du må altså implementere en eller annen form for AI for begge spillene.
**Programmet må støtte både én og to spillere.** To spillere må kunne spille mot hverandre på samme maskin, for eksempel ved å ha hver sin tur til å gi input. Én spiller må kunne spille mot datamaskinen: du må altså implementere en enkel AI for begge spillene. *Du kan få maks uttelling selv om AIen din gjør dumme valg.* Du kan få ekstrapoeng for smart AI.
**Programmet må ha brukergrensesnitt.**
Vi aksepterer program som spilles via terminalen ved hjelp av tekst-input og program som spilles med grafisk, klikk-bart grensesnitt. Du kan få maks uttelling selv om du har tekst-basert grensesnitt. *Du trenger kun implementere én av delene.*
Vi aksepterer program som spilles via terminalen ved hjelp av tekst-input og program som spilles med grafisk, klikkbart grensesnitt. Du kan få maks uttelling selv om du har tekst-basert grensesnitt. *Du trenger kun implementere én av delene.*
**Programmet må være velskrevet, forståelig, testet og dokumentert i henhold til INF101-pensum.** Et program som kjører perfekt, men som mangler tester, dokumentasjon, objekt-orientert design og [README.md](README.md) risikerer stryk.
......@@ -52,8 +53,7 @@ Oppgaven leveres inn ved å pushe til retting.ii.uib.no, [slik du har gjort med
**VIKTIG:** *Sjekk kvitteringssiden som kommer opp når du pusher, i tilfelle det skjer feil!*
Vi anbefaler at du gjør commit hver dag, eller hver gang du er ferdig med en
deloppgave, i tilfelle du mister det du jobber med på din egen maskin. Du kan levere inn så mye og ofte du vil. Versjonen som teller er den **siste du
pushet før innleveringsfristen**.
deloppgave, i tilfelle du mister det du jobber med på din egen maskin. Du kan levere inn så mye og ofte du vil. Versjonen som teller er den **siste du pushet før innleveringsfristen**.
### Poeng/karakter
Hvor mange poeng du får på oppgaven kommer an på hvor god løsningen din er. Både Fire på rad og Tripp-trapp-tresko er relativt enkele spill å implementere, og *kan* skrives i én fil uten klasser og metoder (i INF100-stil). ***Et program skrevet på denne måten vil score cirka 0 poeng selv om det støtter all funksjonalitet.***
......@@ -70,5 +70,7 @@ Dersom du har mangler eller bugs, eller dårlig organisert kode, vil du få trek
Du må gjerne diskutere oppgaven med andre, men dere må skrive individuell kode. Dersom du samarbeider tett med noen så beskriv det i README.md-filen. Se også om code review i [Tips og Triks](Tips.md#code-review-feedback-p%C3%A5-hverandres-kode)
**Ekstrapoeng.** Som på forige oppgave kan du få ekstrapoeng ved å implementere ekstra funksjonalitet. Forslag til dette ligger i [Tips og Triks](Tips.md).
**Ekstrapoeng.** Som på forige oppgave kan du få ekstrapoeng ved å implementere ekstra funksjonalitet. Dette kan inkludere fancy grafikk, super-smart AI, Facebook-integrasjon eller flere varianter av spillene. Flere forslag finner du i [Tips og Triks](Tips.md).
**Hjelp - hvor starter jeg?** Se [Tips og Triks](Tips.md).
......@@ -7,32 +7,46 @@
*Her ligger noen tips til oppgaven. Hvis du sitter fast kan denne lista hjelpe deg i gang.*
**Spør om hjelp og tips underveis.** Gruppelederne hjelper deg gjerne om du lurer på noe, er usikker på om det du har gjort er lurt, eller om du blir stående fast.
**NB: Spør gruppeleerne om hjelp og tips underveis.** Gruppelederne hjelper deg gjerne om du lurer på noe, er usikker på om det du har gjort er lurt, eller om du blir stående fast.
Sjekk timeplanen for interaktive grupper på [Mattermost](https://mattermost.ii.uib.no/inf101v20/) eller ta kontakt med din gruppeleder på epost.
## Hvordan komme i gang
Vi har to forslag til hvordan du kan angripe oppgaven.
Vi har to forslag til hvordan du kan angripe oppgaven. Du kan også gjøre en miks av disse to tilnærmingene.
**1. Start med å skrive et program som "funker".** Det kan være vanskelig å forutsi hvilket design koden din må ha. Du kan starte med å lage et program som *funker*, men som ikke oppfyller krav for design. Etter hvert som du når mål for funksjonalitet, kan du begynne å dele programmet opp i flere klasser og pakker.
For å jobbe på denne måten kan du velge *low-hanging fruit* - hva er den aller enkleste funksjonaliteten du kan tenke deg at programmet ditt har - og implementere det. Kanskje vil du kunne opprette, og skrive ut, et brett? I denne approachen trenger du ikke tenke på kompliserte ting som regler, grafikk og win-conditions enda: bare implementer den ene tingen. Deretter velger du neste *low-hanging fruit* og implementerer det.
**Start med å skrive et program som funker.** Det kan være vanskelig å forutsi hvilket design koden din må ha. Du kan starte med å lage et program som *funker*, men som ikke oppfyller krav for design. Etter hvert som du når mål for funksjonalitet, kan du begynne å dele programmet opp i flere klasser og pakker.
Etter hvert som kodebasen din blir større og mer unhåndterlig kan du *refaktorere* den til klasser, metoder og interface.
**Start med å designe en model.**
Hvis du liker å tenke abstrakt, kan det være du vil foretrekke å starte med å *modellere* problemet. Tenk over hva som er essensielle egenskaper ved de to spillene, hvordan du kan representere dem abstrakt og hvordan abstrakt funksjonalitet kan deles mellom dem. Beskriv hvilke interfaces og klasser du tror du trenger, hvilke metoder og feltvariabler de må ha, og start å tenke på hvordan du vil skrive tester for dem. Deretter kan du implementere abstraksjonen ("modellen") din. Se [modellerings-delen](https://retting.ii.uib.no/inf101.v20.oppgaver/inf101.v20.sem1/-/blob/master/information/modellering.md) av Sem1 for et eksempel til hvordan du kan gjøre og beskrive dette.
**2. Start med å designe en model.**
Hvis du liker å tenke abstrakt, kan det være du vil foretrekke å starte med å *modellere* problemet. Tenk over hva som er essensielle egenskaper ved de to spillene, hvordan du kan representere dem abstrakt og hvordan funksjonalitet kan deles mellom dem.
Du kan også gjøre en miks av disse to tilnærmingene. Andre nyttige teknikker du kan bruke er:
For eksempel kan du tegne opp et diagram av interfaces og klasser du tror du trenger, hvilke metoder og feltvariabler du tror de må ha. Tenk på hvordan du vil skrive tester for dem.
Deretter kan du implementere abstraksjonen ("modellen") din. Se [modellerings-delen](https://retting.ii.uib.no/inf101.v20.oppgaver/inf101.v20.sem1/-/blob/master/information/modellering.md) av Sem1 for et eksempel til hvordan du kan gjøre og beskrive dette.
**Andre nyttige teknikker du kan bruke er:**
**TDD.** Test Driven Development er et prinsipp for å utvikle kode der du *først* skriver testene, *deretter* koden. Fordelen med dette er at for å skrive tester må du tenke gjennom hvordan koden skal oppføre seg, og du får dermed sjansen til å skrive den riktig første gangen.
**TDD + Refactoring = <3.** Hvis du utvikler solide tester, så kan du skrive koden din i sykler: Deklarer en type; lag tester som beskriver funksjonaliteten du vil ha; implementer funksjonaliteten så testene passerer; forbedre koden slik at den oppfyller godt OO-design; len deg tilbake og nyt følelsen av å jobbe organisert.
**TDD + Refactoring = <3.** Hvis du utvikler solide tester, så kan du skrive koden din i sykler:
**Penn og papir.** Bruk egne diagrammer flittig: hvis det blir mye å holde styr på, tegn opp klassene og hvordan de kaller hverandre. Diagrammer er også en god plass å starte utviklingen: tegn opp typene du tror du vil trenge, og hvordan du tror de vil interagere. Utvid og endre på diagrammet etter hvert. Hvis du tror vi vil ha nytte av det til slutt så legg det gjerne ved innleveringen.
1. Deklarer en type (et interface eller klasse)
2. lag tester som beskriver funksjonaliteten du vil ha
3. implementer funksjonaliteten så testene passerer
4. forbedre koden slik at den oppfyller godt OO-design
5. len deg tilbake og nyt følelsen av å jobbe organisert.
## Brukergrensesnitt
Brukergrensesnittet er den delen av programmet som tar imot input fra "ekte" spillere (f.eks. du og gruppelederen din) og viser et output fra programmet. Typiske input er klikk-events eller streng-kommandoer; typiske output er å tegne brettet på i et grafikk-vindu eller ved hjelp av tegn og bokstaver i en terminal. Programmet må typisk outputte status på spillet og fortelle spillerne hvem sin tur det er og om noen har vunnet eller spillet er over.
**Penn og papir.** Bruk egne diagrammer flittig: hvis det blir mye å holde styr på, tegn opp klassene og hvordan de kaller hverandre. Utvid og endre på diagrammet etter hvert. Hvis du tror vi vil ha nytte av det til slutt så legg det gjerne ved innleveringen.
Du trenger ikke å lage et grafisk brukergrensesnitt, det holder med tekst-interaksjon. Det viktige er at denne delen av koden din er klart skilt ut fra resten og godt dokumentert.
**Rubberduck debugging.** Et klassisk programmerer-triks når du sitter fast er å forklare koden din. En gruppeleder er alltid et godt valg, men du kan også forklare den til samboeren din, bestemor, naboens hund, en potteplante eller gummiand. For mer info og en virtuell gummiand, sjekk ut [https://rubberduckdebugging.com/](https://rubberduckdebugging.com/).
Hvis du vil sjekke om du har klart å skille koden for brukergrensesnittet klart fra resten (vi kaller det "modulær" kode) så kan du prøve å bytte ut brukergrensesnittet ditt med noen annens: dersom du har et fornuftig API til resten av programmet ditt bør det være relativt enkelt å koble noen andres brukergrensesnitt til resten av koden din, og på den måten endre én del av programmet uten å måtte endre kode som ikke har med input/output å gjøre. Du kan nok ikke bytte ut klassene direkte, men det bør gå an med litt jobb, og hvis dere blir enig om en lur måte å skrive interfacene på som dere har felles, kan dere bytte moduler uten å endre øvrig kode.
## Brukergrensesnitt
Brukergrensesnittet er den delen av programmet som tar imot input fra "ekte" spillere (f.eks. du og gruppelederen din) og viser et output fra programmet. Typiske input er klikk-events eller streng-kommandoer; typiske output er å tegne brettet på i et grafikk-vindu eller ved hjelp av tegn og bokstaver i en terminal. Programmet må typisk kommunisere status på spillet, fortelle spillerne hvem sin tur det er og om noen har vunnet eller spillet er over.
*Det er ikke et krav for oppgaven å bytte kode med andre studenter, men hvis du får det til uten særlig mye arbeid ligger du sannsynligvis godt an.*
**Du trenger ikke å lage et grafisk brukergrensesnitt, det holder med tekst-interaksjon. Det viktige er at denne delen av koden din er klart skilt ut fra resten og godt dokumentert.**
### Forslag til brukergrensesnitt
Du kan f.eks.
......@@ -41,6 +55,10 @@ Du kan f.eks.
* ...kopiere grafikkbiblioteket vi har brukt i INF101, f.eks. fra [Semesteroppgave 1](https://retting.ii.uib.no/inf101.v20.oppgaver/inf101.v20.sem1/-/tree/master/src%2Fmain%2Fjava%2Finf101%2Fv20%2Fgfx).
* ...kopiere grid-GUIen fra [lab 3/4](https://retting.ii.uib.no/inf101.v20.oppgaver/inf101.v20.lab4.losning).
### Grafikk-modul
Hvis du vil sjekke om du har klart å skille koden for brukergrensesnittet klart fra resten (vi kaller det "modulær" kode) så kan du prøve å bytte ut brukergrensesnittet ditt med noen annens: dersom du har et fornuftig API til resten av programmet ditt bør det være relativt enkelt å koble noen andres brukergrensesnitt til resten av koden din, og på den måten endre én del av programmet uten å måtte endre kode som ikke har med input/output å gjøre. Du kan nok ikke bytte ut klassene direkte, men det bør gå an med litt jobb, og hvis dere blir enig om en lur måte å skrive interfacene på som dere har felles, kan dere bytte moduler uten å endre øvrig kode.
*Det er ikke et krav for oppgaven å bytte kode med andre studenter, men hvis du får det til uten særlig mye arbeid ligger du sannsynligvis godt an.*
## Code Review / Feedback på hverandres kode
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment