Commit db9c71a8 authored by mva021's avatar mva021
Browse files

Updated readme with documentation of the process

parent c41c81cc
......@@ -23,52 +23,99 @@ deloppgave, i tilfelle du mister det du jobber med på din egen maskin. Du kan l
Denne oppgaven teller på din endelige vurdering i faget. Maks poeng er 100. Du kan få opp til 120 totalt, inkludert ekstrapoeng.
# Fyll inn egne svar/beskrivelse/kommentarer til prosjektet under
* Levert av: *NAVN* (*BRUKERNAVN*)
* [ ] hele semesteroppgaven er ferdig og klar til retting!
* Levert av: Martin vatshelle (mva021)
* [X] hele semesteroppgaven er ferdig og klar til retting!
* Code review:
* [ ] jeg har fått tilbakemelding underveis fra @brukernavn, ...
* [ ] jeg har gitt tilbakemelding underveis til @brukernavn, ...
* [X] jeg har gitt tilbakemelding underveis til @Lang liste av studenter, ...
* 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.)
* [ ] Fornuftige navn på klasser, interfaces, metoder og variabler
* [ ] Fornuftige abstraksjoner og innkapsling (bruk av klasser, interface, metoder, etc.)
* [X] Kjørbart Fire på Rad-spill
* [X] Funksjonelt spill
* [X] Fungerende user interface
* [X] Støtter AI
* [X] Kjørbart Tripp-trapp-tresko-spill
* [X] Funksjonelt spill
* [X] Fungerende user interface
* [X] Støtter AI
* [X] Forklart designvalg, hvordan koden er organisert, abstraksjon, og andre ting
* [X] Tester
* [X] Dokumentasjon (JavaDoc, kommentarer, diagrammer, README, etc.)
* [X] Fornuftige navn på klasser, interfaces, metoder og variabler
* [X] Fornuftige abstraksjoner og innkapsling (bruk av klasser, interface, metoder, etc.)
## Oversikt
*(oversikt over koden din og det du har gjort)*
Denne Koden er et Løsningsforslag til Semesteroppgave 2 i INF 101 våren 2020.
Løsningsforslaget gjør litt mer enn det som er spurt etter i oppgaveteksten og mer enn det som krves for å få 100%.
Noen av dere har laget en løsning med input fra terminal mens andre har laget en løsning med GUI. Dette løsningsforslaget har laget begge deler. En ekstra fordel med denne løsningen er at 2 AI spillere kan spille mot hverandre noe som gjør at man får testet AI mye bedre enn ellers.
En klassediagram over klassene i dette løsningsforslaget finner dere på Mitt UiB, her er en kort liste
Grid, Location, GridDirection og GridLocationIterator
- er en litt annen versjon av Grid enn den som ble delt ut med oppgaveteksten. Men den er basert på det som ble brukt i Semesteroppgave 1.
GameBoard
- er en klasse som arver fra Grid<Player>. Hovedformålet med denne klassen er å holde styr på hvor de forskjellige spillerene har plasert, skrive ut brettet til skjemen og telle hvor mange på rad spillerene har oppnådd.
Player, AbstractPlayer, GuiPlayer, ConsolePlayer, MiniMaxPlayer og RandomPlayer
- er klasser for forskjellige typer Player. Player er et Interface og AbstractPlayer er en klasse som har det som er felles for alle de andre Player typene. GuiPlayer og ConsolePlayer er klasser for å personer som spiller ved å gi input. MiniMaxPlayer og RandomPlayer er 2 AIer av forskjellig "intelligens". Alle disse Spillerene kan brukes på begge spillene (og potensielt flere spill i fremtiden).
PlayerList
- er en enkel klasse som holder styr på 2 spillere, hvem som starter spillet, hvem sin tur det er nå og hvem sin tur det er neste gang.
Denne er laget såpass generell at den kan takle flere enn 2 spillere og at den kan fjerne spillere underveis. Man trenger ikke lage denne klassen så generell.
IGame, AbstractGame, TicTacToe og ConnectFour
- er klasser som holder styr på reglene i spillet og driver spillet fremover. Spillet drives fremover ved en løkke som kaller Player sin getMove() metode. Untaket er GuiPlayer der spillet stoppes og det ventes på innput fra GUIen før spillet startes opp igjen.
Hovedmetodene i disse klassene er isWinner(Player p) of canPlace(Location loc, Player p).
GamePanel, ClickableGrid, MNKGameGUI og GameGUI
- er klasser for å håndtere GUI interfacet. Jeg har gjort en del endringer i forhold til den eksempel GUI koden som ble gitt ut med oppgaven, men mye er det samme fortsatt.
### Bruk
For å starte programmet kjør: `fyll.inn.her`
(...for å legge ut en brikke må du...)
(...når du vinner skjer...)
(...etc...)
For å starte programmet kjør:
Spillet kan enten startes ved å kjøre main metoden i TerminalMenu hvis du vil spille den text baserte versjonen, eller main metoden i GameGUI hvis du vil spille den GUI baserte versjonen.
## Designvalg
*(hvordan du har valgt å løse oppgaven)*
Klassen AbstractGame har blitt en sentral klasse i spillet som har en game loop som driver spillet fremover.
Jeg har valgt å Bruke samme GameLoop til å drive spillet uansett om det er GUI eller Terminal som brukes til input, dette gjorde at AbstractGame og IGame ble noe større enn de hadde trengt å være, skulle gjerne delt opp AbstractGame i 2 klasser.
En av de viktigste valgene jeg gjorde var at Player fikk metoden getMove(IGame game). Dette la føringer på mye av designet som jeg endte opp med. Alle Player klassene er dermed i stand til å spille begge spillene.
Spillbrettet modelerte jeg som Grid<Player> og ungikk dermed noe av problematikken med forskjellige typer brikker, hvis dette spillet skulle utvides til noe mer generellt f.eks. Sjakk så måtte jeg ha hatt en egen klasse for Player,Piece kombinasjoner
### Bruk av abstraksjon
*(hvordan du har valgt objekter/klasser for å representere ting i spillet)*
Jeg har delt spillet opp i 3 deler, Spillere, Spillbrett og regler.
- 4 typer spillere implementerer et felles Interface Player.
- Spillbrettet er representert ved GameBoard
- Reglene som er felles for de to spillene er implementert i AbstractGame. De reglene som er forskjellig fanges opp av metodene canPlace() og isWinner() som er implementert forskjellig i TicTacToe or ConnectFour
### Erfaring – hvilke valg viste seg å være gode / dårlige?
*(designerfaringer – er det noe du ville gjort annerledes?)*
Å ha getMove() som returnerer en Location har vært et godt valg.
Var veldig fornøyd med at samme MiniMax player kan spille begge spillene.
Det var Praktisk å modellere GameBoard som Grid<Player> men jeg ser at dette begrenser litt hvordan jeg kan utvide spillet i fremtiden.
Jeg måtte lage en metode stop() i AbstractGame for å stoppe spillet å vente på input fra en GUI player. Jeg ville ikke lage denne metoden public for da kunne andre spillere stoppe spillet før det var slutt så inne i GameLoopen må jeg sjekke for instanceOf GuiPlayer som ikke føltes som fin kode.
Klassen ClickableGrid ble veldig bra, virket som en grei måte å gjøre om fra museklikk til til Location
## Testing
*(hvordan du har testet ting)*
Jeg har skrevet JUnit tester for spill logikken. GUI klassene og Terminal klassene er ikke testet.
Det er totalt 65 tester.
Måten jeg har laget spillet på gjør at 2 AI spillere kan spille mot hverandre. Det gjorde at jeg f.eks. kunne lage tester som verifiserte at AI spilleren var smartere enn en RandomPlayer.
Jeg oppdaget flere bugs mens jeg laget spillet, da skrev jeg tester for å se at jeg hadde laget tester som failet for denne bugen og så fikset jeg bugen og så at testen passerte, jeg tror denne måten å jobbe på førte til ganske god dekning på testene.
## Funksjonalitet, bugs
*(hva virker / virker ikke)*
Så vidt jeg vet fungerer spillet som det skal.
Når spillet er over og man trykker på en av knappene så starter spillet på nytt, men det tar ikke vare på brukervalgene fra forrige spill.
Så du må skrive inn navn på nytt. Men man får den fordelen at man kan bytte fra AI til Multiplayer mellom spillene. Dette er en feature jeg kunne forbedret
## Evt. erfaring fra code review
*(lærte du noe av å gå gjennom din eller andres kode?)*
Jeg ble inspirert av at flere studenter har prøvd seg på å implementere en MiniMax algoritme for AIen. Dette passer nok bedre inn i INF102 pensum men jeg legger likevel med en AI inspirert av disse MiniMax implementasjonene i denne løsningen.
## Annet
*(er det noe du ville gjort annerledes?)*
Jeg begynte å implementere en enkel løsning først før jeg tok meg tid til å tegne klassediagrammet. Jeg burde nok tegnet klassediagrammet tidligere.
\ No newline at end of file
......@@ -98,8 +98,8 @@ public abstract class AbstractGame implements IGame {
//Only in GUI mode this is needed.
if(gui != null) {
gui.updateUI();
showMessage(getCurrentPlayer() +" it is your turn.");
}
showMessage(getCurrentPlayer() +" it is your turn.");
}
private boolean currentIsGuiPlayer(){
......
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