Commit 4d646f5c authored by Anna Maria Eilertsen's avatar Anna Maria Eilertsen
Browse files

fin task descr inkluding how to deliver

parent f24c6f3c
......@@ -3,11 +3,9 @@
* **README**
* [Oppgavetekst](SEM-2.md)
* [Tips for å komme i gang](Tips.md)
**Innleveringsfrist:**
* Hele oppgaven skal være ferdig til **X Y. april kl. 2359** ([AoE](https://www.timeanddate.com/worldclock/fixedtime.html?msg=4&iso=20180427T2359&p1=3399))
* [TODO:LINK Ekstra tips til innlevering](https://retting.ii.uib.no/inf101/inf101.v18/wikis/innlevering)
**Innleveringsfrist:** Hele oppgaven skal være ferdig og levert via din private gitlab-repositorie til **Fredag 24. april kl. 2359** ([AoE](https://www.timeanddate.com/worldclock/fixedtime.html?msg=4&iso=20180427T2359&p1=3399)).
# Fyll inn egne svar/beskrivelse/kommentarer til prosjektet under
* Levert av: *NAVN* (*BRUKERNAVN*)
......
......@@ -42,6 +42,19 @@ Vi aksepterer program som spilles via terminalen ved hjelp av tekst-input og pro
**Programmet ditt må ligge i prosjektet du har fått utdelt av oss.** For at vi skal kunne enkelt kjøre og teste koden din har vi gitt deg et tomt Java prosjekt. Du må levere progreammet ved hjelp av dette prosjektet: program-koden skal ligge i `main` og test-kode i `test`. Resurser som bilder og liknende legges i `resources`. *Alle kodefiler, resurser og dokumentasjon må være levert til ditt online GitLab repositorie for at vi skal rette det.*
### Innlevering
Du finner koden din i repositoriet med URIen:
https://retting.ii.uib.no/<brukernavn>/inf101.v20.sem1.git
Oppgaven leveres inn ved å pushe til retting.ii.uib.no, [slik du har gjort med alle tidligere INF101-oppgaver](https://retting.ii.uib.no/inf101/inf101.v20/wikis/hente-levere-oppgaver). Husk å få med eventuelle nye filer du har opprettet.
**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**.
### 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.***
......
## Tips og triks
* [README](README.md) – for utfyllingface
* [Oppgavetekst](SEM-2.md)
* **Tips for å komme i gang**
*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.
### Tips for å komme i gang
## Hvordan komme i gang
Vi har to forslag til hvordan du kan angripe oppgaven.
**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.
**Start med å designe en model.**
Hvis du liker å tenke abstrakt, kan det være du vil foretrekke å starte med å *modellere* problemet. Tenke over hva som er essensielle egenskaper ved de to spillene, og hvordan du kan representere dem abstrakt. Tenk på hvordan du kan gjenbruke kode mellom dem. Du kan finne ut hvilke interfaces og klasser du tror du trenger, hvilke metoder og feltvariabler, og kanskje skrive tester for disse.
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.
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.
Du kan også gjøre en miks av disse to tilnærmingene.
Du kan også gjøre en miks av disse to tilnærmingene. 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.
......@@ -23,7 +27,7 @@ Du kan også gjøre en miks av disse to tilnærmingene.
## 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, og å fortelle spillerne hvem sin tur det er og om noen har vunnet.
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.
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.
......@@ -31,13 +35,12 @@ Hvis du vil sjekke om du har klart å skille koden for brukergrensesnittet klart
*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.*
### Tips til brukergrensesnitt
### Forslag til brukergrensesnitt
Du kan f.eks.
* ...bruke konsoll-I/O slik som i INF100, med `Scanner` og `System.out.println()`.
* ...kopiere grafikkbiblioteket vi har brukt i INF101, f.eks. fra [Semesteroppgave 1](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/tree/master/src/inf101/v18/gfx). Grafikken kan tegnes som tekst (slik som i semesteroppgaven, og liknende til `System.out`), eller med skilpaddegrafikk eller shapes – se f.eks. hvordan endene er tegnet i [Lab 6](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.lab6/blob/master/src/inf101/v18/pond/Duck.java). Se på [Main-klassen](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.sem1/blob/master/src/inf101/v18/rogue101/Main.java) for oppsett (kan gjøres mye enklere enn i Sem1), og for å se hvordan du kan motta tastetrykk.
* ...kopiere den klikkbare grid-GUIen fra [ekstraoppgaven om lyttere](https://retting.ii.uib.no/inf101.v18.oppgaver/inf101.v18.xtra.listeners); denne har vært brukt på tidligere INF101-obliger også.
* ...bruke [Swing](https://docs.oracle.com/javase/tutorial/uiswing/components/index.html) eller [JavaFX](https://docs.oracle.com/javase/8/javafx/get-started-tutorial/jfx-overview.htm) til å lage brukergrensesnitt (kan ta litt tid å sette seg inn i). Se f.eks. [JavaFX 8 GUI Tutorial](https://code.makery.ch/library/javafx-8-tutorial/)
* ...bruke konsoll-I/O med `Scanner` og `System.out.println()`.
* ...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).
## Code Review / Feedback på hverandres kode
......@@ -51,61 +54,7 @@ Det er veldig nyttig å måtte [forklare](https://en.wikipedia.org/wiki/Rubber_d
* Det burde passe greit å gjøre dette en gang i løpet av den første uken, og så en gang til noen dager før innlevering.
* Det er et eget punkt i [README-filen](README.md) som dere kan krysse av hvis dere prøver dere på en eller annen variant av “code review” – skrive gjerne også noen setninger om hva dere gjorde og hvordan det fungerte (lærte du noe? forbedret du noe?)
-----
TODO: end up up to date for this year.
## Regler
Regler for Fire På Rad:
* Spillere har hver sine brikker (f.eks. med forskjellige farger eller symboler)
* Spillere har hver sin tur til å legge ned brikker
* På sin tur skal spilleren velge en kolonne å slippe sin brikke ned i.
* (Implisitt regel: en brikke som slippes ned i en kolonne faller til den lander enten oppå en annen brikke eller på bunnen av brettet. Dette er ikke beskrevet i Fire på Rad-spillregler, men er en konsekvens av designet på brettet. Dere velger selv om dere vil vise det grafisk eller ikke, men det er viktig at ikke brikken blir liggende på toppen av kolonnen som er valgt, eller at spilleren får velge x og y-koordinater å legge brikken sin på.)
* Spillet stopper når en spiller vinner, ved å få *fire brikker ligger på rad, enten vannrett, loddrett eller diagonalt*. Dette kravet kalles ofte en [win condition](SEM-2.md#win-condition) eller "victory condition": denne betingelsen må være oppfylt for at spillet skal være vunnet.
### Spillere
En ekte spiller (f.eks. du eller gruppelederen din) trenger en intern representasjon i programmet. Dette er abstraksjon av den ekte spilleren, så tenk over hva som har betydning å ha med. La deg gjerne inspirere av Player-klassen fra oblig 1.
I tillegg til en vanlig spiller, må du kunne lage AI-spillere. Bruk gjerne et Spiller-interface som begge disse typene implementerer, og kanskje en felles superklasse dersom de ser ut til å dele oppførsel. Eventuelt kan AI-spiller arve fra Spiller. Vurder selv hvordan du vil gjøre det, og begrunn valget ditt.
### Win Conditions
Du vinner spillet ved å ha fire brikker på rad: vannrett (-), loddrett (|) eller diabonalt(/ \).
Man kan tenke seg at en annen versjon av spillet der man velger andre regler. Derfor ønsker vi å ha reglene innkapslet i en egen klasse; f.eks. ved at den har en metode som ser på et brett og avgjør om noen har vunnet. Dette gjør programmet mer modulært, og gjør at vi enklere kan gjenbruke resten av programmet til å lage spillet Fem på Rad, kun ved å bytte ut én objekt-type. Du trenger ikke lage Fem på Rad (enda), men du må lage en egen klasse for reglene slik at vi lettere kan utvide spillet dersom vi ønsker det.
## Ekstra tips
### Tips for kjerne-programmet
Det er ofte forvirrende at vi må tenke på Spill som en abstraksjon av Fire på Rad og Tripp-trapp-tresko (med brett, brikker og spillere), og på main-metoden i et program. Da kan det være nyttig å bruke to forskjellige klasser til det, feks en Main-klasse som starter programmet og initialiserer et Spill-objekt, og en Spill-klasse som er abstrakt og logisk og ikke har noen main-metode.
Dersom Main og Spill er hver sine klasser, og du ønsker å implementere runder i en løkke, kan det være vanskelig å finne ut hva som skal skje hvor. For å hjelpe deg videre her, kan det være nyttig å sette seg med penn og papir og skrive ned:
* nøyaktig hva skjer i løpet av en runde?
* hva har alle runder til felles?
* hva er annerledes under en AI-runde i forhold til en menneske-runde?
* hva skjer når spillet starter, men ikke hver runde?
Siden alle runder (hver spiller sin) likner på hverandre, og alle hele spill (fra start til slutt) likner på hverandre, er det typisk at man lager en løkke for hver, og legger dem inni hverandre:
```java
main(){
loop until program should stop {
gjør ting som har med initialisering av spill-objekter;
loop per single game {
gjør ting som trengs for å starte spillet;
loop per round {
gjør ting som trengs per runde;
}
}
}
```
Vi skriver loop og mener en eller annen form for løkke (for, while, do-while): hvordan du vil skrive det finner du ut av selv (eller spør gruppelederen din). Dette er et godt sted å bruke Iteratorer.
### Forslag til bruk av INF101-konsepter
## Forslag til bruk av INF101-konsepter
***Dette er ikke en sjekkliste du må oppfylle, og den er ikke komplett.*** Dette er en liste av INF101-konsepter som kan være nyttige og tips til hvordan å bruke dem. Du må sikkert bruke ting som ikke står på listen, og du kan gjerne la være å bruke ting fra listen dersom det ikke passer i koden din.
* **Interfaces**. Det er naturlig at du bruker interface til å definere oppførselen til klassene dine. Der du kan bør du bruke interface-typen i stedet for klasse-typen. *Det gjør programmet ditt mer modulært og enklere å bytte ut kode.*
......@@ -148,4 +97,6 @@ Eventuelt kan dere bli enige om et felles interface, en *standard*, og følge de
Dersom du samarbeider med noen for å få dette til, skriv i README-filen hvem og hvordan.
### Bedre AI
AI-spilleren kan gjøres smartere på mange måter. Du kan finne på dine egene strategier, f.eks. ved å ha en egen klasse for Strategi, og la AI-spillere spille mot hverandre. Hvis du gjør modul-delen over kan du la din AI-spiller konkurrere mot andres.
\ No newline at end of file
AI-spillerene kan gjøres smartere på mange måter. Du kan finne på dine egene strategier, f.eks. ved å ha en egen klasse for Strategi, og la AI-spillere velge hvilken de skal bruke, eller til og med bytte underveis. Begge spillene lar seg 'løse': Det vil si at det går an å lage en perfekt AI-spiller.
Hvis du gjør modul-delen over kan du la din AI-spiller konkurrere mot andres.
\ No newline at end of file
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