TDDE71 Programmering och datastrukturer

Projekt veckobrev

Veckobrev 1 (Onsdag 5/11)

Projektgrupper är bildade och av schemapasset var ni i full gång kläcka spelidéer och skriva kravspecar! Här kommer ett veckobrev där jag tar upp förväntningar på er, saker ni måste tänka på och tips på andra saker att tänka på. Allt i avsikt att projektet ska gå så bra som möjligt.

Arbetsuppgifter

Arbetsuppgifter som ska utföras första veckan:

• Tänk igenom er målsättning när och hur ofta ni ska arbeta med projektet - mer om detta under rubrik nedan
• Kom igång med Git - mer om detta under rubrik nedan
• Kravspecifikation - se delmoment
• Objektorienterad analys - se delmoment
  Sikta på att ha ett utkast att diskutera under seminariet den 11:e

Andra uppgifter vettiga att lägga tanke och tid på:

• Gör en Lo-Fi-prototyp - mer om detta under rubrik nedan
• Förstå hur er SFML spelmotor ska fungera - mer om detta under rubrik nedan
• Projektorganisation - lämnas helt till er:
  • Projektplan / Prioriteringar / Milstolpar
  • Ansvarsområden och roller (se föreläsningsslides för förslag)
  • Vill ni har fasta roller eller turas om ha olika ansvar?
  • Hur ska ni kommunicera effektivt?
  • Hur tilldelas/fördelas arbetsuppgifter?
  • Hur prioriteras arbetsuppgifter?
  • Hur loggas utfört arbete?
  • Hur införs nya uppgifter som ska lösas?
  • Hur redovisas vad som gjorts så alla vet vad som finns klart?
  • Hur ska ni samarbeta? När jobbar ni enskilt, när sitter ni tillsammans, när parprogrammerar ni? Vad är effektivast? Vad ger högst kvalité?
  • När och var ska var och en jobba? Delat schema för att lättare nå varandra och jobba tillsammans.
  • Projektdagbok - loggbok med vad var och en gjort, var resultatet finns, hur det används, kända problem, nya uppgifter att utföra
  • Scrumboard
  • Gruppkontrakt

Tid i projektet och arbetstidsmål per vecka

Onsdag 5/11 räknas som starten på den första projektveckan. Därpå har vi exakt 6 veckor fram till Onsdag den 17/12 då era spel redovisas. Dessa 6 veckor är värda 3hp per person, dvs 80 arbetstimmar eller två veckor heltidsarbete. Hur ni fördelar den tiden per vecka är upp till er - det viktiga är att var och en har en plan som fungerar både för sig själv och för gruppen. Några förslag för att illustrera:

• Jämn spridning 1: Jobba 2h projekt per dag 6 dagar i veckan, ledigt söndag. En fördel är att det då inte blir någon arbetstopp, men en nackdel att det blir mycket overhead. Att komma igång med vad som ska göras och avrunda kommer äta tid varje dag. Det är ibland lättare att fokusera på en uppgift lite längre tid utan avbrott och bli klar. Detta lämnar inte heller mycket tid mot slutet då det oftast är mest att göra, men förhoppningen är förstås att med mer jobb i början gör att projektet är nästan klar mycket tidigare utan arbetstopp på slutet.
• Jämn spridning 2: Jobba 4h per dag tre dagar i veckan, t.ex. mån, ons, fre. Detta ger lite mer tid att fokusera varje pass. Overhead med att komma igång blir ni 3ggr/vecka istf 6ggr. Detta är nog ganska rimligt som målsättning, men kanske ta det lite lugnare i början och köra på mer när ni har klarhet i exakt vad ni ska göra.
• En heldag och en halvdag per vecka. Bra för den som gillar att fokusera på en sak i taget. Kan vara svårt fylla tiden i början, och det kan gå lite väl många dagar mellan passen. Det blir aldrig någon riktig rutin jobba regelbundet med projektet.
• Göra minimum i början för att uppfylla kurskraven och sätta igång på allvar när dokument är godkända. Nackdelar med detta är att ni kommer upptäcka alla former av problem och utmaningar mycket längre in i projektet med mycket mindre kalendertid att reda ut det. Sparar ni t.ex. 3/4 av arbetet till de sista 3 veckorna blir veckoarbetstiden 20h per vecka de sista veckorna och det känns inte hållbart.
• Prokrastinera max: Jobba dygnet runt de sista 3 dagarna 14-16 dec. Ett massivt arbetspass på 3 dygn klockar in 72h. Eventuella nackdelar och skäl att aldrig göra det igen redovisas med fördel i erfarenhetsrapporten.

Tänk igenom hur ni spenderar er tid. Ur ett arbetslivsperspektiv, om vi antar att var och en är vid en punkt i karriären där ni har en månadslön på 50000kr/mån, så kan vi räkna ut hur mycket ett arbetsmöte med 6 personer faktiskt kostar. Med i snitt 21 arbetsdagar per månad kommer en person med angiven månadslön att kosta ca 300kr/h (50000kr/(21*8h). För en arbetsgivare tillkommer ungefär lika mycket i skatter, avgifter och andra fasta kostnader (kontor mm). Kostnaden blir då ca 600kr/h. Ett möte med 6 personer under 2 timmar kostar då ca 7200kr. Med det i bakhuvudet är det väl värt att fundera på om det finna effektivare sätt att få samma arbete utfört. Vilka aktiviteter måste verkligen utföras tillsammans och vilka utförs mer effektivt enskilt eller i par? Prova olika modeller!

Git

Vi har genererat projektkonton på gitlab.liu.se åt er. Det är dessa som ska användas i projektet. Ni behöver:

• Logga in på gitlab.liu.se om ni inte gjort det sedan tidigare. Första gången ni loggar in skapas ert konto. Först därefter kan vi lägga till er i ert repository. De som inte kan läggas till kommer få separat mail om detta.
• Sätt ert LiU-ID som användarnamn i git på samtliga datorer/konton ni avser använda under projektet. Detta behövs så att alla era commits görs som samma användare.
• Se till att var och en kan använda de mest grundläggande git-kommandona via terminalen:
  • git status
    Ta för vana att alltid kolla status innan ni gör något annat. Är ni på rätt branch? Är det rätt filer som kommer committas?
  • git add
  • git add -u
  • git commit -m "LiU-IDn... Beskrivande kommentar"
    Tagga era commits med LiU-ID på dem som gjort väsentliga bidrag till commiten.
  • git branch
  • git merge
  • git pull
  • git push
  Råkar ni ut för problem ni inte kan lösa med hjälp av ovan kommandon utan andra flaggor är rekommendationen att rådfråga någon eller noga läsa på konsekvensen av att använda andra kommandon.
  Användargränssnittet på webben används enbart för att justera inställningar och rättigheter, samt skapa merge-requests (om ni vill arbeta med sådana).
• Se till att var och en kommer igång och gör var sin inledande commit, t.ex. att ni i tur och ordning lägger in era namn i "credits.txt" (filen ni sedan fyller på med referenser till allt som bidragit till projektet)
• Skapa en gitignore och fyll på med de filtyper som inte ska commitas (filtyper som genereras utifrån andra filer eller med automatik ska inte sparas i git)
• Bygg en första grund till projektet komplett med Makefile för kompilering. Något ni sedan kan utöka steg för steg. Grunden behöver inte göra mer än att öppna ett fönster som går att stänga. Se till att alla förstår hur det fungerar och används.
• Tänk igenom hur ni vill organisera era filer i repositoryt. Det kommer att innehålla lite olika typer av filer: dokumentation (*.tex, *.pdf, *.png, *.doccx, ...), inkluderingsfiler (*.h), kodfiler (*.cc, speldata (*.txt, ...), texturer/bilder (*.png, *.jpg, ...) och kanske ljudfiler. Att dumpa allt i en mapp kn bli lite stökigt.
• Dokumentera hur git-repot är organiserat. På sikt bör ni även skriva ned regler/rutiner/tips för hur git ska användas så ni arbetar enligt en gemensam modell.

Lo-Fi-prototyp

Det är avsevärt mycket enklare att skriva en programvara om det är klart och tydligt hur den ska fungera. Varje otydlighet leder till osäkerhet, gissningar, missförstånd och behov av kommunikation för att reda ut strulet som uppstår. En Low-Fidelity-prototype kan hjälpa er som utvecklare att förstå exakt vad ni vill åstadkomma.

Att göra en Lo-Fi-prototyp innebär i princip att fundera igenom vad som ska hända - vad användaren ska se och kunna göra - när programmet kör. Skissa spelets huvudmeny på ett A4, och bestäm vad spelaren ska kunna göra. Gå sedan igenom varje alternativ användaren kan göra och rita på nytt A4 hur det ska se ut när användaren kommer dit. Placera alla A4 på ett bord för att få översikt på allt som ska finnas. Med detta kan ni även låta en person agera dator och en annan användare för att "testköra" programvaran. Datorpersonen lägger fram ett A4-arket spelets startskärm och ber användaren reagera på den. Användaren säger vilken mus- eller tangentbordsknapp hen trycker på och datorpersonen reagerar med att lägga fram det A4-ark som användaren ska komma till (ev. kompletterat med muntlig förklaring av saker som händer som är svåra att rita upp). Detta är ett utmärkt och billigt sätt att utvärdera hur en användare reagerar på ett menysystem och vilka menyer som behöver finnas. Det kan även vara användbart för att känna in hur valda spelsekvenser ska fungera.

Allt användaren gör när Lo-Fi-prototypen testkörs kan även användas som grund till så kallade användningsfall, där man utifrån användarens input tänker igenom vad som ska hända under huven för att nå önskat resultat.

SFML Spelmotor

Att tidigt bygga en förståelse för hur spelmotorn ska vidarebeordra användarinmatning, förfluten tid, sköta utritning, lägga till nya objekt och ta bort gamla är centralt för att förstå möjligheter och begränsningar med hur spelobjekt kan implementeras. Prata(epost) gärna med mig(Klas) om ni vill ha en genomgång. Seminariet den 11:e är också ett utmärkt tillfälle diskutera med er handledare.

Sidansvarig: Eric Ekström
Senast uppdaterad: 2025-11-06