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

update text after meeting

parent a787ee4a
## Advanced
* [README](README.md) – for utfyllingface
* [Oppgavetekst](SEM-2.md)
* [Tips for å komme i gang](Tips.md)
* **Advanced**
## Hvordan oppnå ekstrapoeng
*Her gir vi noen forslag til hvordan du kan oppnå ekstrapoeng. Du kan også finne på egne ideer: bare beskriv dem klart i README-filen.*
## GUI
Grafisk brukergrensesnitt gir ekstrapoeng. Vi vet at det er vanskelig å skrive GUI, så vi har inkludert litt eksempelkode. **Du trenger ikke bruke eksempel-koden.**
Syns du det ble veldig 90-talls? Gjør det bedre da vel! Hvis du klarer å gi gruppelederen som retter en behagelig brukeropplevelse så motiverer det desto mer til ekstrapoeng. *Bribe the DM*, as we say in DnD.
Hvis du trenger hjelp til å komme i gang med GUI kan du kikke på:
* ...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).
* Web-integrasjon? Kanskje litt beyond INF101, men vi blir veldig imponert hvis du får det til.
### 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
*Dette er frivillig, men kan være både lærerikt og hjelpe deg til å forbedre innleveringen din.*
Det er veldig nyttig å måtte [forklare](https://en.wikipedia.org/wiki/Rubber_duck_debugging) hvordan man selv har tenkt og hvordan ens egen kode virker, og det er også veldig nyttig å prøve å sette seg inn i hvordan andre har tenkt når de har programmert. Vi anbefaler derfor at du finner går sammen med noen andre studenter (f.eks. i grupper på 2–4 personer) og gjør litt [lightweight](http://codingsight.com/lightweight-code-review/) [code reviews](https://en.wikipedia.org/wiki/Software_peer_review) av hverandres kode:
* Det er praktisk å gå gjennom ting muntlig: sitt rundt samme datamaskin, og forklar din egen kode til de andre (eller prøv å forstå og forklare noen andres kode!) – dere kan diskutere gode og dårlige løsninger, ideer til ting som kan gjøres annerledes eller forbedres osv.
* **Viktig:** poenget med dette er *å lære*, og *å forbedre* innleveringene – for at det skal funke er det viktig å være *positiv og konstruktiv* når du gir tilbakemeldinger eller kommentarer (ellers er det ingen som tør å vise deg koden sin neste gang!)
* 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?)
## Andre Ekstra utfordringer
Dette er ikke krav til innleveringen, men forslag til videreutvikling.
### Random Events
To mix things up a litte, the implementation can support the functionality of random events: These events are executed in each round with a certain probability and change the state of the game. Examples are the following (but it can be anything fun, be creative!):
- Throwing 'blocker' tokens into a random column that keep both players to throw their tokens there.
- Looking at each token in the board and switching its owner with a certain probability. (I.e. some of the blue tokens become red and vice versa.)
- Switching the owners of tokens in a random (small) area of the board.
- Rotating the board.
- ...
### Modulært
Dersom du skriver programmet ditt modulært, er det lett å koble dine moduler sammen med andres og på den måten f.eks. bytte ut ditt brukergrensesnitt med noen andre sitt, eller koble noen andre sin AI til ditt spill. For å få dette til må du ha god enkapsulering, fornuftig navngiving og forståelig dokumentasjon. Husk at tester er en del av dokumentasjonen.
For å få programmet modulært må det bestå av flere komponenter eller deler, der hver del implementeres separat fra kjerneprogrammet. Dette betyr ikke at dere trenger forskjellige prosjekter, men at kode-komponenter er klart adskilte (funksjonalitet for AI skal være begrenset til AI-modulen og ikke "lekke" inn i I/O-modulen. Spillets funksjonalitet og regler må ikke påvirkes av at man bytter ut modulen for I/O, osv.
Siden vi ikke har gitt dere noen interface eller API å følge, er det usannsynlig at du har nøyaktig samme APIer som andre studenter. Derfor må dere nok jobbe litt for å koble modulene deres sammen. En måte å gjøre det på, er å skrive en "koblings-klasse" som oversetter mellom interfacene deres. Den må dere gjerne skrive sammen. Dette blir altså en ny klasse, som ikke finnes i noen av programmene fra før, og som har som jobb å "oversette" mellom forskjellige APIer. Det gjør at dere slipper å endre deres egen kode.
Eventuelt kan dere bli enige om et felles interface, en *standard*, og følge denne begge to.
Dersom du samarbeider med noen for å få dette til, skriv i README-filen hvem og hvordan.
### Bedre AI
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
......@@ -4,6 +4,7 @@
* **README**
* [Oppgavetekst](SEM-2.md)
* [Tips for å komme i gang](Tips.md)
* [Advanced](Advanced.md)
**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)).
......@@ -15,7 +16,13 @@
* [ ] jeg har gitt tilbakemelding underveis til @brukernavn, ...
* Sjekkliste:
* [ ] Kjørbart Fire på Rad-spill
* [ ] Funksjonelt spill
* [ ] Fungerende user interface
* [ ] Støtter AI
* [ ] Kjørbart Tripp-trapp-tresko-spill
* [ ] Funksjonelt spill
* [ ] Fungerende user interface
* [ ] Støtter AI
* [ ] Forklart designvalg, hvordan koden er organisert, abstraksjon, og andre ting
* [ ] Tester
* [ ] Dokumentasjon (JavaDoc, kommentarer, diagrammer, README, etc.)
......
......@@ -3,12 +3,26 @@
* [README](README.md) – for utfylling
* **Oppgavetekst**
* [Tips for å komme i gang](Tips.md)
* [Advanced](Advanced.md)
## Læringsmål
- Utvikle objekt-orienterte program fra scratch
- Spesifisere, implementere og teste ditt eget design
- Dokumentere og motivere egne designvalg
### 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**.
Denne oppgaven teller på din endelige vurdering i faget. Maks poeng er 100. Du kan få opp til 120 totalt, inkludert ekstrapoeng.
## Intro
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).
......@@ -43,20 +57,8 @@ 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 programmet 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.***
### Poeng og vurdering
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 tilsvarer stryk selv om det støtter all funksjonalitet.***
Vi forventer så klart at programmet oppfører seg cirka som det skal, men for å få god uttelling må du i tilegg vise at du kan bruke objekt-orientering på en god måte, og at du kan teste og dokumentere koden din.
......@@ -70,7 +72,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. 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).
**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 dokumentet [Advanced](Advanced.md)
**Hjelp - hvor starter jeg?** Se [Tips og Triks](Tips.md).
......@@ -3,6 +3,7 @@
* [README](README.md) – for utfyllingface
* [Oppgavetekst](SEM-2.md)
* **Tips for å komme i gang**
* [Advanced](Advanced.md)
*Her ligger noen tips til oppgaven. Hvis du sitter fast kan denne lista hjelpe deg i gang.*
......@@ -14,22 +15,31 @@ Sjekk timeplanen for interaktive grupper på [Mattermost](https://mattermost.ii.
## Hvordan komme i gang
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.
#### 1. Bottom-up: Start med å skrive et program som "funker".
Du kan starte med å lage et minimalt program som *funker*, men som ikke oppfyller krav for design og funksjonalitet. 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.
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? Kanskje du kan ha som mål å skrive ut et 3x3 brett med x-er og o-er til terminalen?
I denne tilnærmingen trenger du ikke tenke på kompliserte ting som regler, grafikk og win-conditions enda: bare implementer den ene tingen du valgte.
Deretter velger du neste *low-hanging fruit* og implementerer det. Hvis du kan skrive ut et brett, hva med å ta imot input og fylle inn x-er og o-er basert på koordinater? Deretter kan du kanskje prøve å utvide programmet til å støtte forskjellige grids av forskjellige størelser.
Etter hvert som kodebasen din blir større og mer unhåndterlig kan du *refaktorere* den til klasser, metoder og interface.
**2. Start med å designe en model.**
#### 2. Top-down: 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.
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.
([Hint](https://en.wikipedia.org/wiki/M,n,k-game))
Med denne tilnærmingen trenger du ikke tenke på detaljer som regler og win-conditions enda, men du vil kanskje ha nytte av å se på koden til forige oblig. Hvordan var spillet abstrahert der?
For eksempel kan du tegne opp et diagram av interfaces og klasser du tror du trenger. Tenk på hvilke metoder og feltvariabler 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/rogue.md) av Sem1 for et eksempel til hvordan du kan gjøre og beskrive dette.
**Andre nyttige teknikker du kan bruke er:**
### Andre nyttige teknikker:
**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.** 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. Når du deretter gjør selve implementasjonen kan testene hjelpe deg med å finne feil.
**TDD + Refactoring = <3.** Hvis du utvikler solide tester, så kan du skrive koden din i sykler:
......@@ -43,33 +53,15 @@ Deretter kan du implementere abstraksjonen ("modellen") din. Se [modellerings-de
**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/).
## Brukergrensesnitt
## Hva menes med 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.
**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.
* ...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).
### 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.
Et tekstbasert brukergrensesnitt bruker konsoll-I/O med `Scanner` og `System.out.println()`, slik du så i Lab1.
*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
*Dette er frivillig, men kan være både lærerikt og hjelpe deg til å forbedre innleveringen din.*
Det er veldig nyttig å måtte [forklare](https://en.wikipedia.org/wiki/Rubber_duck_debugging) hvordan man selv har tenkt og hvordan ens egen kode virker, og det er også veldig nyttig å prøve å sette seg inn i hvordan andre har tenkt når de har programmert. Vi anbefaler derfor at du finner går sammen med noen andre studenter (f.eks. i grupper på 2–4 personer) og gjør litt [lightweight](http://codingsight.com/lightweight-code-review/) [code reviews](https://en.wikipedia.org/wiki/Software_peer_review) av hverandres kode:
* Det er praktisk å gå gjennom ting muntlig: sitt rundt samme datamaskin, og forklar din egen kode til de andre (eller prøv å forstå og forklare noen andres kode!) – dere kan diskutere gode og dårlige løsninger, ideer til ting som kan gjøres annerledes eller forbedres osv.
* **Viktig:** poenget med dette er *å lære*, og *å forbedre* innleveringene – for at det skal funke er det viktig å være *positiv og konstruktiv* når du gir tilbakemeldinger eller kommentarer (ellers er det ingen som tør å vise deg koden sin neste gang!)
* 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?)
## Hva gjør jeg med den utleverte koden?
Du har fått utlevert eksempelkode. **Du står fritt til å bruke eller slette koden du har fått utlevert.** Hvis du vil lage GUI kan du bruke denne koden, eller skrive din egen.
## 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.
......@@ -82,38 +74,8 @@ Det er veldig nyttig å måtte [forklare](https://en.wikipedia.org/wiki/Rubber_d
* **Datainvariant**. Legg gjerne inn datainvariant (sjekk på at feltvariablene har en gyldig kombinasjon av verdier) i klassene dine der du kan. Det vil hjelpe deg med debugging og regnes som en del av dokumentasjonen.
* **Datastrukturer**. Se Grid fra tidligere oppgaver.
* **Generisk type**. Datastrukturen din bør være generisk, og kanskje andre deler av programmet.
* **Iterator**. Du kan bruke iteratorer på mange måter her: du kan iterere over spillerne i runde-løkken; du kan iterere over brikker på brettet for å sjekke om noen har vunnet (det kan være litt vanskelig å implementere sånn); du kan du kan lagre tidligere spill og iterere over dem for å produsere en total poengsum; osv.
* **Iterator**. Hvis du trenger å gå gjennom alle objeektene i en struktur (f.eks. en grid) kan det være nyttig å bruke iterator.
* **Enum?** Det er ikke sikkert du trenger enums, men de kan ofte være hendige (kanskje for brikker?)
* **Klassediagram**. Tegn gjerne et diagram over koden din. Det er veldig nyttig for din egen del, og gjerne også for gruppelederne.
* ***Abstraksjon***. Se seksjonen for Spill-abstraksjon.
* ***Abstraksjon***. Selv om koden fungerer er det nyttig å bruke abstraksjon til å gjøre koden din intuitiv for andre mennesker.
* ***Innkapsling*** eller encapsulation. Pass på at du bruker private modifiers der du kan, og at du gjemmer vekk så mye som mulig av den indre tilstanden til klassene (feltvariabler, nøyaktig implementasjon). Det er nyttig å bruke interfaces til dette.
## Ekstra utfordringer
Dette er ikke krav til innleveringen, men forslag til videreutvikling.
### Random Events
To mix things up a litte, the implementation can support the functionality of random events: These events are executed in each round with a certain probability and change the state of the game. Examples are the following (but it can be anything fun, be creative!):
- Throwing 'blocker' tokens into a random column that keep both players to throw their tokens there.
- Looking at each token in the board and switching its owner with a certain probability. (I.e. some of the blue tokens become red and vice versa.)
- Switching the owners of tokens in a random (small) area of the board.
- Rotating the board.
- ...
### Modulært
Dersom du skriver programmet ditt modulært, er det lett å koble dine moduler sammen med andres og på den måten f.eks. bytte ut ditt brukergrensesnitt med noen andre sitt, eller koble noen andre sin AI til ditt spill. For å få dette til må du ha god enkapsulering, fornuftig navngiving og forståelig dokumentasjon. Husk at tester er en del av dokumentasjonen.
For å få programmet modulært må det bestå av flere komponenter eller deler, der hver del implementeres separat fra kjerneprogrammet. Dette betyr ikke at dere trenger forskjellige prosjekter, men at kode-komponenter er klart adskilte (funksjonalitet for AI skal være begrenset til AI-modulen og ikke "lekke" inn i I/O-modulen. Spillets funksjonalitet og regler må ikke påvirkes av at man bytter ut modulen for I/O, osv.
Siden vi ikke har gitt dere noen interface eller API å følge, er det usannsynlig at du har nøyaktig samme APIer som andre studenter. Derfor må dere nok jobbe litt for å koble modulene deres sammen. En måte å gjøre det på, er å skrive en "koblings-klasse" som oversetter mellom interfacene deres. Den må dere gjerne skrive sammen. Dette blir altså en ny klasse, som ikke finnes i noen av programmene fra før, og som har som jobb å "oversette" mellom forskjellige APIer. Det gjør at dere slipper å endre deres egen kode.
Eventuelt kan dere bli enige om et felles interface, en *standard*, og følge denne begge to.
Dersom du samarbeider med noen for å få dette til, skriv i README-filen hvem og hvordan.
### Bedre AI
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