Skriver Oblig4.md nesten ferdig

This commit is contained in:
torlunjen 2020-05-05 14:37:17 +02:00
parent 9e00df3a64
commit d3d698caae

View File

@ -12,23 +12,298 @@ Rollefordelingen i teamet fungerer fint slik som vi har det.
* Alltid lage brukerhistorier før implementering.
* Test alt som kan gå galt, gjør også manuelle tester.
* Tenk på funksjonalitet i forhold til lettvinthet ved implementasjon av ting som multiplayer.
### Retrospektiv
#### Plan
Det vi planlagte var å ha tre digitale møter per korte sprint (en uke) for parprogrammering,
planlegging og generell diskusjon rundt prosjektet.\
planlegging og generell diskusjon rundt prosjektet. Vi bruker oppsettet til scrum med parprogrammering lagt til.
Dette var metodikken vi planlagte å bruke fra starten av prosjektet og det har fortsatt å være dette oppsettet vi
har valgt bruke gjennom hele prosjektet.
Vi valgte å bruke scrum fordi oppsettet passer fint for tidsperiodene mellom obligene på prosjektet, der vi da kan ha
korte sprinter på en uke hver og lange sprinter i tidsrommet fra oblig til oblig.
Vi planla også å lage ferdig alle brukerhistoriene, akseptansekravene og
arbeidsoppgavene før vi begynte noe av kodearbeidet.\
arbeidsoppgavene før vi begynte noe av kodearbeidet.
Arbeidsoppgaver skulle settes opp som issues i prosjektet på GitHub med gode beskrivelser
for så å legges til prosjekttavlen. Når noen i teamet skal begynne på en ny arbeidsoppgave skulle de
legge seg til i oppgaven på prosjekttavlen for så å flytte oppgaven fra "To do" kolonnen til "In progress" kolonnen.
#### Gjennomførelse
Vi har gjennomført planen vår som planlagt.
Det vi syntes at vi har gjort bra er at alle har vært tilstede på alle møter vi har hatt.
#### Forbedringspunkter
Vi ville kommunisert med gruppeleder på et tidligere tidspunkt for å klarere hvilket krav som faktisk skal møtes
til innlevering. I tillegg til å sjekke retteskjema. Dele opp arbeidsoppgaver i passelige biter, for å unngå isfjell.
Alltid lag brukerhistorie før implementering, et problem vi hadde i starten.
Ha tester som automatisk sjekker at alt funker som det skal, og lag manuelle tester for det som ikke
kan testes automatisk. Tenk på funksjonalitet i forhold til lettvinthet ved implementasjon av ting som multiplayer.
Selv når vi kodet med multiplayer in mind, måtte vi endre en del for å støtte klient og server funksjonalitet.
Prosjektmetodikken vi har valgt ville vi også brukt hvis vi måtte begynt på nytt.
### Gruppedynamikk og kommunikasjon
Kommunikasjonen innad i teamet har i all hovedsak fungert fint.
Vi brukte allerede online møter før nedstenging, så da gikk vi fra to timer til 8 timer online møte i uken.
Vi jobber typisk først sammen for så å dele oss opp i flere samtaler ut fra hvem som jobber sammen.
Visualisering i form av tavle ble noe vanskeligere når vi måtte bruke skjermdeling av paint i stedet for
en fysisk tavle. Når vi ikke har fysisk møter, ser vi heller ikke gruppeleder, noe som førte til mindre kommunikasjon.
Når vi sitter i forskjellige samtaler er det også vanskeligere for teamleder å ha oversikt over hele gruppen.
Det tar lenger tid å få hjelp enn om vi satt i samme rom.
## Deloppgave 2
### Brukerhistorier runde
#### Brukerhistorie
* Som runde trenger jeg å kunne kjøre faser for å progresere spillet.
*Akseptansekrav*
* Runden kjører fem faser.
*Arbeidsoppgaver*
* Legg til en funksjon for å kjøre fem faser.
#### Brukerhistorie
* Som spiller trenger jeg å få tildelt programmeringskort for å kunne lage et program.
*Akseptansekrav*
* Del ut programmeringskort fra spillet sitt dekk til hver spiller.
* Spillere får antall programmeringskort ut ifra hvor mye skade de har blitt påført.
*Arbeidsoppgaver*
* Legg til funksjon for å tildele programmeringskort til alle spillere.
#### Brukerhistorie
* Som spiller trenger jeg å få mulighet til å annonsere powerdown for at roboten min vil kunne ta en powerdown.
*Akseptansekrav*
* Spiller må få spørsmål i starten av en runde om de vil gå i powerdown neste runde.
* Roboten til spilleren må gå i powerdown om spilleren annonserte det forrige runde.
*Arbeidsoppgaver*
* Serveren må kunne sende programmeringskortene, spiller listen og brett navnet til alle klientene og
alle klientene må forvente å mota dette objektet.
* Legg til en funksjon for å gi spiller en mulighet for å gå i powerdown.
#### Brukerhistorie
* Som robot trenger jeg å kunne gå i powerdown for å kunne kurere all skade.
*Akseptansekrav*
* Starten av runden settes skaden til roboter som skal i powerdown til null.
*Arbeidsoppgaver*
* Legg til funksjon for å gå i powerdown.
#### Brukerhistorie
* Som reperasjonstile trenger jeg å kunne fikse skade på roboter for å gjennomføre min funksjon.
*Akseptansekrav*
* Roboter som står på en reperasjonstile i slutten av en runde, får fjernet en skade.
* Reperasjonstiles er: Flagg, skiftenøkkel og skiftenøkkel + hammer.
*Arbeidsoppgaver*
* Legg til en funksjon som aktiverer alle reperasjonstiles og reparere roboter som står der.
#### Brukerhistorie
* Som spiller må jeg kunne levere inn mine gamle ulåste kort for å få nye kort.
*Akseptansekrav*
* Ulåste kort blir lagt tilbake i spillkortstokken etter runden er ferdig.
*Arbeidsoppgaver*
* Legg til funksjon for å samle inn kort som ikke er låst.
#### Brukerhistorie
* Som spiller må jeg få mulighet til å fortsette min powerdown for å kunne fikse eventuell ny skade.
*Akseptansekrav*
* Spillere som er i powerdown får mulighet i starten av runden om å fortsette powerdown eller ikke.
*Arbeidsoppgaver*
* Legg til funksjon for å gi spillere som er i powerdown mulighet for å fortsette i powerdown.
#### Brukerhistorie
* Som spiller må roboten min kunne bli respawnet for å kunne ta del i spillet videre, gitt jeg har flere liv.
*Akseptansekrav*
* En robot som dør får ett mindre liv.
* Hvis roboten er tom for liv, taper spilleren dens.
* Når en robot dør, gjennoppliver den på sin backup posisjon.
*Arbeidsoppgaver*
* Legg til en funksjon som gjennoppliver roboter som har flere liv.
#### Brukerhistorie
* Som spiller må registrene mine bli låst ut ifra hvor mye skade jeg har, for å representere en skadet robot.
*Akseptansekrav*
* Roboter med mer enn fire skade, får låst antall register over fire skade.
* Kort som står i låste register blir ikke samlet inn og kan ikke endres.
*Arbeidsoppgaver*
* Legg til en funksjon for å låse register.
### Brukerhistorier GUI/Nettverk
#### Brukerhistorie
* Som spiller må jeg kunne velge kort for å programmere roboten min.
*Akseptansekrav*
* Det finnes et grafisk grensesnitt som velger kort.
*Arbeidsoppgaver*
* Lage et grafisk grensesnitt som lar en bruker velge kort.
#### Brukerhistorie
* Som spiller når jeg treffer det siste flagget mitt skal/må spillet stoppe for at jeg skal kunne vinne.
*Akseptansekrav*
* Det blir vist en skjerm som sier hvem som vinner.
*Arbeidsoppgaver*
* Lage en libgdx skjerm som sier hvilken spiller som har vunnet.
#### Brukerhistorie
* Som spiller må en person også være en severe som kan dele ut informasjon til alle andre klienter for å ha et
sentralt distribusjons senter for informasjon.
*Akseptansekrav*
* Det finnes en funksjon som lar deg velge å bli en server.
*Arbeidsoppgaver*
* Legge til funksjonalitet som starter en server dersom brukeren velger å starte som server.
#### Brukerhistorie
* Som klient må jeg kunne sende inn spillernavnet mitt til serveren for å bli identifisert i spillet.
*Akseptansekrav*
* Det finnes et grafisk grensesnitt som lar klienten skrive inn navnet sitt og sender det til serveren.
* Serveren må forvente å mota navnet fra spilleren.
*Arbeidsoppgaver*
* Serveren må forvente å mota navn fra spillere å må bruke det navnet til å lage en spiller.
* Lage et grafisk grensesnitt som lar en klient koble seg til en server.
#### Brukerhistorie
* Som spiller må jeg kunne se hvilken robot som er min for at jeg skal kunne identifisere roboten min.
*Akseptansekrav*
* Brettet må kunne vise hvilken robot som passere med hvilken spiller.
*Arbeidsoppgaver*
* Lage et grafisk grensesnitt som lar deg se navn på alle spillere og hvilken robot som tilhører hver spiller.
#### Brukerhistorie
* Som server må jeg kunne sende programmerings kortene, brett navn og en player list med alle spillerne for at
spillet skal bli synkronisert.
*Akseptansekrav*
* Serveren må sende programmeringskort, brett navnet og en liste med alle spilleren til alle klientene.
* Klientene må forvente å mota programmeringskort, brett navnet og en liste med alle spilleren.
*Arbeidsoppgaver*
* Serveren må kunne sende programmeringskortene, spiller listen og brett navnet til alle klientene og
alle klientene må forvente å mota dette objektet.
#### Brukerhistorie
* Som klient må jeg kunne sende informasjon om jeg skal i powerdown, programmet mitt og de ubrukte
kortene mine inn til serveren for at spillet skal bli synkronisert.
*Akseptansekrav*
* Klienten må kunne sende powerdown, programmet mitt og de ubrukte kortene inn til serveren.
* Serven må forvente å mota informasjon om powerdown, programmet til klienten og de ubrukte kortene til klienten.
*Arbeidsoppgaver*
* Alle klienter må kunne sende inn informasjon om de skal i powerdown og programmet spilleren har programmert.
#### Brukerhistorie
* Som server må jeg kunne sende informasjon om alle som skal i powerdown og alle sine programmer for at
spillet skal bli synkronisert.
*Akseptansekrav*
* Serveren må kunne sende informasjon om alle som skal i powerdown til alle klientene.
* Klientene må forvente å mota informasjon om alle som skal i powerdown.
*Arbeidsoppgaver*
* Informasjon om powerdown og programmeringskort må sendes tilbake til alle klienter slik at
alle har samme informasjon.
* Klientene må forvente å mota denne informasjon.
#### Brukerhistorie
* Som Host må jeg kunne samle inn alle ulåste kort fra spillerne for at integriteten til kortstokken skal ivaretas.
*Akseptansekrav*
* Host må samle inn alle de ulåste kortene ut ifra programmene som blir mottatt fra serveren.
*Arbeidsoppgaver*
* Flytte ubrukte kort tilbake i hoved deck hvis denne instans av spillet inneholder en host.
#### Brukerhistorie
* Som klient må jeg få mulighet til å fortsette powerdown og sende den informasjonen inn til serveren for at ønsket om
powerdown skal bli vedlikeholdt mellom alle klientene.
*Akseptansekrav*
* Det finnes et grafisk grensesnitt som lar deg velge å fortsette powerdown.
* Valget av å fortsette powerdown må bli sent inn til serveren.
* Serveren må forvente å motta valget om å fortsette powerdown.
*Arbeidsoppgaver*
* Lage et grafisk grensesnitt som lar en bruker fortsette powerdown.
* Klienten må få mulighet til å fortsette powerdown og serveren må forvente å mota denne informasjonen.
#### Brukerhistorie
* Som server må jeg kunne sende informasjon om alle roboter i powerdown og sende nye programmerings kort til alle
klientene for at spillet skal bli synkronisert.
*Akseptansekrav*
* Serveren må kunne sende informasjon om alle roboter i powerdown og nye programmerings kort til alle klientene.
* Klientene må forvente å mota informasjon om powerdown og de nye programmeringskortene.
*Arbeidsoppgaver*
* Serveren må kunne sende informasjon om alle som fortsetter powerdown og nye programmeringskort.
* Klienten må forvente å motta denne informasjonen.
#### Brukerhistorie
* Som server må jeg kunne håndtere spillere som taper for at klienter som har tapt ikke skal bli spurt om input.
*Akseptansekrav*
* Serveren må kunne markere klienter den ikke skal ha input fra.
*Arbeidsoppgaver*
* Serveren makerer alle som har død og derfor ikke skal ha input fra.
* Serveren må håndtere en spiller som er dø og blir avkoblet og som ikke er host.
#### Brukerhistorie
* Som spiller må jeg ha et grensesnitt for å bestemme om jeg skal være server, klient eller avslutte.
*Akseptansekrav*
* Det finnes et grafisk grensesnitt for å kunne velge å være server, klient eller å avslutte.
*Arbeidsoppgaver*
* Lage et grafisk grensesnitt som lar brukeren velge å starte som server, koble til en server eller avslutte spillet.
#### Brukerhistorie
* Som spiller må jeg ha et grensesnitt for å bestemme om hvilken server jeg skal bli med.
*Akseptansekrav*
* Det finnes et grafisk grensesnitt for å kunne velge server.
*Arbeidsoppgaver*
* Lage en libgdx skjerm som viser servere som kjører på samme nettverk på default port.
* Skjermen må inneholde mulighet for å kunne spesifisere ip og port for en vilkårlig server.
#### Brukerhistorie
* Som spiller må jeg ha et grensesnitt for å kunne skrive inn spiller navnet mitt.
*Akseptansekrav*
* Det finnes et grafisk grensesnitt for å kunne skrive inn spiller navnet.
*Arbeidsoppgaver*
* Lage et grafisk grensesnitt som lar en klient skrive inn sitt spiller navn.
#### Brukerhistorie
* Som spiller må jeg ha et grensesnitt som viser at jeg venter på noe, for å ikke bli forvirret når ingenting skjer.
*Akseptansekrav*
* Det finnes et grafisk grensesnitt for å varsle om venting i spillet.
*Arbeidsoppgaver*
* Lage en libgdx skjerm som viser at spillet venter på noe.