TDDE71 Programmering och datastrukturer

Projekt veckobrev

Veckobrev 3 (Onsdag 19/11 -- Onsdag 26/11)

Förväntad status: Objektorienterad analys är genomförd och ni har en god uppfattning om hur alla objekt i spelet ska reagera på indata, förfluten tid och kollisioner. Ni har även grundläggande uppfattning om hur klasserna ska hanteras/interagera "under huven", dvs hur spelmotorn ska fungera. Ni har god uppfattning om vilka spelscenarion som kräver lite extra av spelmotorn och behöver undersökas noggrannare. Ni har en basal grundversion av spelmotor ni kan lägga till nya klasser i. Ni har börjat råka ut för konflikter och problem i git.

Arbetsuppgifter

Arbetsuppgifter som ska utföras under veckan:

Planera veckan: när ska ni jobba, var ska ni jobba, vad ska var och en åstadkomma?
Målet bör vara minst 10h för var och en (se rubrik nedan).
Fortsätt förfiningen av er objektorienterade analys mot en objektorienterad design (se förra veckobrevet)
Koda klasser, framförallt de som behövs för arbete med andra klasser
Lämna in godkänd version av Kravspecifikation och Objektorienterad analys (28/11)
Krav: boka möte för halvtidsavstämning
Bonus: leda projektmöte, kombineras med fördel med halvtidsavstämning, måste föranmälas! (se detaljer i bonusuppgiften)
Bonus: statusrapport för 12:e - 19:e nov lämnas senast fredag den 21:e
Upprop: Har din grupp tips ni tror andra kan ha nytta? Har ni råkat ut för problem som även andra sitter med? Hör av er så har jag möjlighet att sprida information/tips om detta (klas.arvidsson@liu.se).

Tips om git

Git kan te sig som ett obegripligt monster när det du vill göra inte fungerar. Att bara göra så som git föreslår eller så som något internet-troll föreslår fungerar ibland, men oftare hjälper det mycket att sätta sig ned och försöka förstå de olika delar som finns i Git och hur gitkommandon påverkar dem. Den länkade artikeln visar de fyra lagringsytorna, hur kommandon flyttar filer mellan dem, och en kort sammanfattning av de vanligaste kommandona. Ni jobbar utöver de beskrivna lagringsytorna dessutom med en "remote" (gitlab.liu.se) och när du själv kan utöka figuren i artikeln med en ruta för "remote" och hur git push, git fetch och git pull påverkar repository och remote så har du goda förutsättningar lösa problem som uppstår.

I veckobrev 1 listas de viktigaste kommandon att använda i git, och om du får problem som bara verkar kunna lösas med andra kommandon eller extra flaggor vidhåller jag att det bästa är att be om hjälp eller noga läsa på innan användning. En sak du absolut bör undvika är att ta bort eller ändra commits. Det är bättre att göra en ny korrigerande commit. Detta är extra viktigt om en commit redan är pushad till remote. Om du rekommenderas använda flaggor "--hard" eller "--force" ska du vara extra vaksam, dessa tillåter att git skriver över saker vilket kan leda till dataförlust.

Ett vanligt misstag jag gör hela tiden är att jag glömmer skapa en ny branch för uppgiften som ska lösas och jobbar direkt i "main". Detta går normalt att fixa till så länge det inte är pushat. En branch är inte mer än ett "bokmärke" i commithistoriken (git log --oneline --graph --all) och genom att först committa (eller stasha) allt arbete och sedan flytta runt dessa bokmärken kan jag lösa problemet utan att flytta commits. Det är dock viktigt att först förstå exakt vilken situation jag har och vad jag behöver åstadkomma.

Ett annat vanligt misstag jag gör att glömma byta till den branch jag egentligen skulle arbeta i. Om inget är pushat så involverar lösningen på detta troligen git rebase". Exakt lösning kan variera beroende på situation som råder.

Ett vanligt irritationsmoment är att git envisas med att öppna en editor för commit-meddelande i flera situationer, vanligast vid merge. Vilken editor som väljs beror på skalets[1] standardinställning (echo $EDITOR) om du inte ställt in din favorit i gits egen config (git config --global core.editor emacs). Vanligen kommer det upp något obegripligt som "vim" eller "nano". Ta dig tiden att byta till en editor du känner till och som är rimligt snabb att starta ("emacs").

[1] Skalet är det program som kör i ditt terminalfönster och tar emot kommandon. Ett vanligt skal är "bash". När skalprogrammet startar läser det igenom en konfigurationsfil där du kan göra diverse inställningar. Vanliga inställningar är att definiera olika alias och variabler. Konfigurationsfilen för bash har sökvägen ~/.bashrc och intressanta variabler att justera är EDITOR (anger standard editor), PATH (anger mappar att leta kommandon(program) i) och PS1 (anger vad som visas i skalprompten). Läs dokumentationen först!

Definition av arbetsuppgifter

För att jobba effektivt behöver du veta vad du ska åstadkomma. Om du inte vet exakt vad du ska åstadkomma så kommer du inte heller veta när du är klar, om det blev bra, eller om det ens var rätt sak att göra. Detta leder till att uppgiften kan kännas oändlig, och du upplever osäkerhet och rädsla för att inte göra rätt. Då blir det inte roligt att arbeta, och svårt att ens sätta igång. Detta leder till dåligt samvete, stress och ännu större ovilja att ta tag i uppgiften. Jag tar hellre tag i andra saker som ändå måste göras, som tvätthögen, träningen eller den där matteuppgiften.

Andra problem med otydligt specificerade uppgifter är att de varken går att tidsuppskatta eller följa upp.

Exempel arbetsuppgift som är för löst specificerad:

Skriva klassen Player.

Problem:

Hur ska utföraren känna att framsteg har gjorts och delmål avklarats och kan visas upp?
Vet utföraren vad som ska utföras?
Har alla projektmedlemmar samma uppfattning om vad resultatet ska bli?
Hur lång tid kommer det att ta?
Hur vet utföraren att uppgiften är slutförd?
Hur testar vi att resultatet fungerar som det ska?
Kommer de funktionerna i Player som är viktigast för andra av projektets delar prioriteras?
Hur vet vi att delar som behövs för Player hinner slutföras först?

Exempel på samma uppgift mer konkret specificerad:

Implementera att Player syns som en rektangel och kan styras med piltangenterna
Förkrav: basal spelmotor
Implementera att Player syns med textur
Förkrav: databas för inläsning och cachning av texturer är implementerad
Implementera att Player rör sig med konstant hastighet framåt
Implementera att Player faller hela tiden nedåt om inget hindrar
Förkrav: plattform att stå på som hindrar fall är implementerad
Implementera att Player dör när objektet faller utanför bild
Implementera att Player kan hoppa
Förkrav: plattformsobjekt och gravitation fungerar

Hur många punkter som ska slutföras en viss vecka blir planerbart, prioritering blir möjlig, och varje punkt kan tidsuppskattas mycket enklare. Tidsuppskattning blir som regel enklare ju mindre en uppgift är och ju mer konkret uppgiften specificeras. Är en uppgift svår att tidsuppskatta, bryt isär den till mindre delar.

Ännu viktigare är kanske att delmålen går att bocka av, testa och visa upp. Detta stärker känslan att komma framåt för hela gruppen.

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