2017InfC16

From rtgkomArkiv
Jump to: navigation, search

2018-03-19, mandag, 3. modul: Computerspil - User Stories, Kravspecifikation, Testspecifikation og aflevering af 1. prototype, Gkb 13:21, 19 March 2018 (CET)[edit]

Fortsat arbejde med implementeringen, men vi havde flere korte plenummøder hvor vi fokuserede på detaljer i den sproglige formulering af både krav og testprocedure og user stories.

Vi browsede følgende websider i fælleskab på projektoren:

2018-02-06, tirsdag, 1. modul: Computerspil - Systemudviklingsmetoder, Design, og første prototype, Gkb 09:52, 6 February 2018 (CET)[edit]

Vi startede modulet med en plenumdiskussion om systeudvikling. Vi startede med begrebet system og via en diskussion hvor vi blandt andet slog op på Amanda projektet, xxx, så kom vi frem til den konklusion at vi er nu ved at lave systemudvikling. Vores spil er eksempler på systemer og vi kan derfor godt tillade os at kalde os systemudviklere og at bruge dele af sproget fra de store systemudviklingsmetoder til at planlægge, gennemføre, dokumentere og præsentere vores computerspil.

Vi diskuterede kort følgende systemudviklingsmetoder:

  1. DSDM, https://www.agilebusiness.org/, https://en.wikipedia.org/wiki/Dynamic_systems_development_method

Præsenterde jeg MediaLab's egen systemudviklingsmetode, som ikke duer til rigtige systemudviklingsprojekter, men som fungerer godt til vores skoleprojekter. Jeg præsenterede de syv overordnede systemudviklingsaktiviteter og iteration og prototyper og test mm. Her er et link til beskrivelse af metoden:

I dag begynder vi registrering af arbejdsgrupperne i en tabel her i wiki'en og så skal vi arbejde med

  • Design af spillet. Vi skal beskrive hvordan vi vil at vores computerspil skal virke og se ud. Det kan være en god idé at skrive en liste over hvad spillet skal kunne. Man kalder sådan en liste for en kravspecifikation.
  • Første prototype. Vi skal bruge det valgte udviklingsmiljø, værktøj, til at lave en prototype til spillet. Denne første prototype behøver ikke kunne meget.

Kravspecifikation og design[edit]

Ofte deler man kravene op i grupper. Man prioriterer hvornår man vil at de inkluderes i spillet. Nogle krav skal måske inkluderes (opfyldes) straks i første prototype og andre senere. Det kan være at nogle af kravene er vigtigere end andre med hensyn til spillets funktion og det kan være at nogle krav er ikke helt nødvendige men interessant på nogen anden måde. Altså "gode at have" eller "nice to have".

Så skal vi beskrive hvordan vi vil designe opfyldelse af disse fem krav. Det gøres ofte før arbejdet med at lave spillet starter, men det kommer også ofte nye krav undervejs når udviklerne er begyndt at programmere eller bygge spillet med de programmer som de nu har valgt til opgaven.

2017-12-15, fredag, 2. modul: Systemudvikling og fortsat arbejde med visuel programmering med Snap, Gkb 10:03, 19 December 2017 (CET)[edit]

Vi brugte dette modul til at diskutere systemudvikling. Modeller mm.

2017-12-07, fredag i 4. modul, Visuel programmering med Snap, Gkb 12:06, 19 December 2017 (CET)[edit]

Vi begyndte at arbejde med Snap, som er et program som kan bruges til at programmere lidt mere visuelt end vi har gjort i SageMath.

Nogle af jer har arbejdet med Scratch og det er ok, de to systemer ligner nemlig hinanden meget, men det er nok bedst at vi alle snart arbejder med Snap.

Den vejledning som vi støtter os til her i begyndelsen hedder Snap!Reference Manual og den er her http://snap.berkeley.edu/SnapManual.pdf.

Når vi arbejder med Snap!Reference Manual, så er den foreløbige plan at læse det første kapitel og afprøve alle programeksemplerne som vises i kapitlet.

Når vi hver med vores egen tempo arbejder med manualen, så kan vi tænke på den opgave at prøve at implementere en enkel prototype til et spil med følgende funktionalitet.

  1. Der laves to sprites hvor den ene er cirkelformet og den anden kvadratisk. Størrelsen tilpasses spillets bane således at ingen af de to sprites fylder for meget af spillebanens areal. Evt. er en størrelse mellem 1% og 10% passende? Farver kan frit vælges af udvikleren.
  2. Den cirkelformede sprite skal kunne styres med piletasterne. Dens udgangspunkt skal vælges tilfældigt indenfor banen med mindst en diameters afstand til kvadraten. Hastigheden kan frit vælges af udvikleren.
  3. Hvis den går udenfor brugerfladens kanter, så skal den komme ind på spllebanen fra den modsatte side. Helt præcis hvordan dette sker kan frit vælges af udvikleren.
  4. Den kvadratformede sprites centrum skal placeres midt i spillets brugerflade. Nærmer detaljer, såsom om den roterer eller om størrelsen måske varierer som funktion af tiden, -det kan frit vælges af udvikleren.
  5. Der skal implementeres en test til at afgøre om de to sprites rører hinanden (Collision Detection).
  6. Der gives "-1" point ved hvert sammenstød.
  7. Points skal vises i øverste højre hjørne af spillets brugerflade.

2017-12-06, onsdag 2. modul, Bengt Petersen, Gkb 12:06, 19 December 2017 (CET)[edit]

Vi brugte modulet til at se og høre foredraget som Bent Petersen, http://www.dtu.dk/english/service/phonebook/person?id=21811&tab=1, holdt i salen om hans arbejde med at rede Anazonas.