Vi kører med INDIVIDUEL aflevering. Du skal sørge for at der på dit studieweb er en side med adgang til rapport og produkt samt evt. øvrig dokumentation og præsentation af arbejdet i forløbet.
Link til produkt lægges også i rapport (gerne på forsiden)
Opret link til siden og sæt det ind i et dokument, som du lægger på Lectio som aflevering
Vi er tæt på afslutningen af forløbet.
Få lavet det sidste trim i sprintplan/backlog, så planen holder. Her skal det prioriteres, at I når at få testet/evalueret og dokumenteret resultaterne.
Det kan på dette tidspunkt være en rigtig god idé at tage et nyt kig på de indledende mål med projektet. Det er med henblik på at kunne samle op og konkludere på det overordnede niveau (der skal også konkluderes på de specifikke sprints)
Brug også tid på at få strukturen på plads i rapporten, så der er overensstemmelse med indholdet der og de faktiske aktiviteter, I har været gennem - herunder kronologi og argumentation.
Der er 4 moduler tilbage inden deadline for aflevering - inklusiv dagens dobbeltmodul,
Dobbeltmodulet i dag bruges til at komme godt i bund med produktionen - d.v.s. blive klar med en prototype, der kan demonstreres.
I løbet det andet af vores 2 moduler (den sidste del) skal I fremvise hvad I har klar af produkt og meget gerne i en version, der kan afprøves af en udefrakommende bruger.
Til højre er opsat 2 "testmiljøer" bestående af 2 og 3 projektgrupper.
Her demonstrerer man på skift sin prototype - eller hvad man end har klar af produkt - optimalt med afprøvning som del af det.
Der skal være dialog om projekterne hvor I som minimum kommer ind på:
Hvad skal der til for at have et game loop kørende, der lever op til krav for et MVP?
Hvad skal der til for at mekanikkerne fungerer og giver den fornødne værdi til spillet og spiloplevelsen? (er der mulighed for en god spildynamik?)
Hvilke typer af motivation (sammenhæng mellem spillertype og mekanik) er der arbejdet med og hvor vellykket vurderes det foreløbige resultat - hvad skal evt. udvikles?
Kan der siges noget om Game Feel?
Malthe, Lucas, Mikkel
Maja, Silke, Vaidas & Valdemar
Aksel, Basharat
Younes, Cecil
Victor, Yasin, Bastian, Lucca
Repetér hvad der forstås ved Minimum Viable Product og diskuter i projektgruppen, hvordan det kan blive brugbart for jeres arbejde.
Foretag en analyse, hvor I kommer frem til bud på, hvad der skal til, for at I står med et MVP samt hvordan det kan give information til jer om den næste iteration/sprint.
Et typisk mål for tidlige sprints vil være et "Proof of concept".
Genbesøg begrebet (vi har jo været der før) og se om ikke I kan indarbejde det i jeres måde at afklare "done" på. Det kræver, at I kan definere hvad konceptet består i samt hvordan I kan dokumentere det eftervist - typisk i form af kvantitative tests.
Det er også muligt, at der allerede nu er brugerkrav, der skal opfyldes - f.eks. til konkret aflæsning eller oplevelse af prototypen. Det kræver en kvalitativ afprøvning - en brugertest.
Overvej hvad målene konkret er for jeres forskellige versioner samt hvordan I forestiller jer at afprøve dem - eller mere konkret:
design jeres tests med omhu
gennemfør dem
dokumenter det!
Jeres analyser og de valg, I foretager under udviklingen af jeres løsninger, skal være kvalificerede.
Det betyder, at der skal fagligt belæg for de påstande, jeres løsninger tager udgangspunkt i. Belægget kan bl.a. findes via empiri eller i faglitteraturen. Vi har bl.a. andet været inde forbi MDA-framworket og begreber som affordance og (core) gameplay loop.
Det skal I sikre bliver aflæseligt i jeres dokumentation og formidling af projektet.
-> Joss Querné: Types of gameplay loops you should know
-> Maksym Kysil: What Is a Gameplay Loop? Types of Core Loops Explained
Sprints er ved at være på plads i planlægningen - ellers skal det prioriteres nu, så der er et overblik i forhold til tidsressourcerne.
Vær opmærksomme på at få eftervist og dokumenteret jeres krav til de forskellige stories eller backlog-items og hvorvidt de indfries i de sprint-loopet. Med andre ord: forklar hvordan "done" er defineret og hvordan det testes.
Vis hvordan I håndterer review eller efterprøvningen frem til der, hvor I beslutter et "done".
Se om ikke også det kan afspejles struktureret i jeres rapport.
Der skal arbejdes med at få den gode backlog på plads. Det er udgangspunktet for den gode projektstyring og at der kommer kvalitet ind i løsningen.
Den gode backlog kræver, at man kan begrunde de elementer, man har lagt ind. Man begrunder og argumenterer for spilelementerne gennem faglig research og analyser. Det er en del af forundersøgelsen i projektet.
Med afsæt i jeres - gode - backlog lægges sprintplanerne, hvor man ser de forskellige versioneringer for sig og hvordan de forskellige sprint mål beskriver en gradvis udvikling hen mod en "release" der opfylder det I har defineret som udgangspunkt
Det blev sidt bemærket, at man undervejs har mulighed for at "trimme" sin backlog efterhånden som processen gør en klogere på, hvad der fungerer og hvad der kan nås.
I trimningnen og prioriteringen af elementerne i backloggen kan men hjælpe sig selv med f.eks. MoSCoW- modellen
Projektgrupperne er på plads og nu handler det om at få startet projektet op.
Her er det vigtigt at få etableret den gode projektstyring. Der er lagt op til at man tager udgangspunkt i Scrum. Et "benspænd" er - jf. oplægget -at udarbejde en kvalificeret backlog, og at der ud fra det skal tilrettelægges realistiske sprints.
Sørg derfor for at få gang i relevante værktøjer til at dele jeres projektdokumenter og løbende ajourføre jeres plan og progression for arbejdet. Trello, Miro, HacknPlan eksempler på anvendelige planlægningsværktøjer.
Bemærk at fokus denne gang er spillets mekanikker og at der grafiske features som udgangspunkt skal nedprioriteres.