Fiasko/Deliverables/Oblig4.md

Team Fiasko

Deloppgave 1

Rollefordeling

Rollefordelingen i teamet fungerer fint slik som vi har det.

Erfaringer

• Vi burde kommunisert med gruppeleder på et tidligere tidspunkt for å klarere hvilket krav som faktisk skal møtes til innlevering.

• Vi skulle passet mer på i starten å ikke lage isfjell ved oppdeling av arbeidsoppgaver.

• Det er viktig å alltid lage brukerhistorier før implementering.

Retrospektiv

Plan

Det vi planla var å ha tre digitale møter per korte sprint (en uke) for parprogrammering, 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. 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 (nesten) alle har vært tilstede på alle møter vi har hatt.

Forbedringspunkter

Vi ville kommunisert med gruppeleder på et tidligere tidspunkt for å klarere hvilke krav som faktisk skal møtes til innlevering, i tillegg til å sjekke retteskjemet. Vi har lært det er viktig å 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 ifra 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 hadde fysisk møter, så 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

Systemkrav denne sprinten

MVP Krav

• En spiller taper når de mister alle liv.

• En spiller må kunne vinne.

• Runder (Består av 5 faser. Du får nye kort, reparasjon, powerdown etc.).

• Faser (Ett kort fra hver spiller blir brukt, og objekter på brettet interagerer. Registrering av flagg skjer etter hver fase).

• Kunne spille med andre spillere over lan/internett.

• Spillere beveger seg hver fase og kort bestemmer hvem som går først.

• Velge kort i starten av runden.

• Kunne velge powerdown etter alle har låst kortene sine.

• Ved slutten av runden mister roboten en i skade hvis de står på en reparasjonsbrikke eller flagg.

• Hvis en spiller er i powerdown blir spilleren spurt (i starten av nye runden) om han vil bli i powerdown eller ikke.

• Samle inn kort i slutten av en runde.

• Ikke samle sammen kort som er låst.

Nye implementerte NTH (Nice to have)

• Kunne velge hvilket brett man vil spille på

• Flere funksjonelle tiles (partalls pushere og oddetalls pushere)

• Bedre grafikk for bedre brukeropplevelse (informasjon som liv, skade etc.)

• Automatisk scanning av LAN

• Kunne velge hvilken port man vil

• Host kan se antall spillere koblet til spillet før start

• En spiller har valget mellom å se på spillet eller disconnecte etter han/hun har tapt.

• Vise låste kort

Brukerhistorier for en runde

Brukerhistorie 1

• 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 2

• Som spiller trenger jeg å få tildelt programmeringskort for å kunne lage et program.

Akseptansekrav

• Del ut programmeringskort fra spillet sin kortstokk 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 3

• 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 4

• 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 5

• 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 6

• 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 7

• 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 8

• Som spiller må roboten min kunne bli respawnet for å kunne ta del i spillet videre, gitt at den 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 9

• 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 registre blir ikke samlet inn og kan ikke endres.

Arbeidsoppgaver

• Legg til en funksjon for å låse registre.

Brukerhistorier for GUI/Nettverk

Brukerhistorie 10

• Som spiller må jeg kunne velge kort for å programmere roboten min.

Akseptansekrav

• Det finnes et grafisk grensesnitt for å velge kort.

Arbeidsoppgaver

• Lage et grafisk grensesnitt som lar en bruker velge kort.

Brukerhistorie 11

• 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.
• Få spillet til å ikke fortsette til neste runde, men bytte til vinneskjermen i stedet

Brukerhistorie 12

• Som spiller må en person også være en server som kan dele ut informasjon til alle klienter for å ha et sentralt distribusjons-senter for informasjon.

Akseptansekrav

• Det finnes en funksjon som lar deg velge å bli en server.

Arbeidsoppgaver

• Legge til en grafisk knapp som lar spilleren starte en serever
• Legge til funksjonalitet som starter en server dersom brukeren velger å starte som server.

Brukerhistorie 13

• 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 sende det til serveren.
• Serveren må forvente å motta navnet fra spilleren.

Arbeidsoppgaver

• Serveren må forvente å motta navn fra spillere og må bruke det navnet til å lage en spiller.
• Lage et grafisk grensesnitt som lar en klient koble seg til en server.

Brukerhistorie 14

• 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 hører til hvilken spiller.

Arbeidsoppgaver

• Lage et grafisk grensesnitt som lar deg se navn på alle spillere og hvilken robot som tilhører hver spiller.

Brukerhistorie 15

• Som server må jeg kunne sende brettnavn og en spillerliste med alle spillerne for at spillet skal bli synkronisert.

Akseptansekrav

• Serveren må sende brettnavnet og en liste med alle spillerne til alle klientene.
• Klientene må forvente å mota brettnavnet og en liste med alle spillerne.

Arbeidsoppgaver

• Serveren må kunne sende spillerlisten og brettnavnet til alle klientene, og alle klientene må forvente å motta dette objektet.

Brukerhistorie 16

• Som klient må jeg kunne sende informasjon om jeg skal i powerdown og programmet mitt inn til serveren for at spillet skal bli synkronisert.

Akseptansekrav

• Klienten må kunne sende powerdown og programmet mitt inn til serveren.
• Serven må forvente å motta informasjon om powerdown og programmet til klienten.

Arbeidsoppgaver

• Alle klienter må kunne sende inn informasjon om de skal i powerdown og programmet spilleren har programmert.

Brukerhistorie 17

• 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 å motta 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 18

• 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 hovedkortstokken hvis denne instansen av spillet er en host.

Brukerhistorie 19

• 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 å motta denne informasjonen.

Brukerhistorie 20

• 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 å motta 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 21

• 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ød og blir frakoblet og som ikke er host.

Brukerhistorie 22

• 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 23

• Som spiller må jeg ha et grensesnitt for å bestemme hvilken server jeg skal koble til.

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 24

• 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 25

• 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.

Deloppgave 3

• For dokumentasjon om bygging, testing og kjøring, se README.md.