Upplägg

Projektets syfte är att ge en erfarenhet att arbeta med en större projekt i programmering och att ge en möjlighet att få använda det ni lärt er under kursens gång. Studenter från tidigare år har upplevt projektet som det mest lärorika och roligaste momentet i kursen.

Projektet utförs i grupper om 5-6 personer och ni ska tillsammans skapa en applikation eller ett spel. Vanligtvis brukar alla grupper göra spel, och det är något vi rekommenderar. Ett spel hamnar ofta på en rimlig nivå så att det både fyller upp kursens krav och går att genomföra inom perioden. Det är dessutom kul att implementera och visa upp när det är klart!

Projektförslag

Ett lämpligt projekt (till omfattning och innehåll), med kursens laborationer och teori som grund, är att göra ett klassiskt arkadspel. Du kanske kommer ihåg sådana höga montrar med en TV-inuti, de brukade (kanske fortfarande?) stå på fritidsgårdar och i bowlinghallar. Vanligtvis behövde spelaren lägga i mynt för att få spela. Därpå kör spelet i gång och målet är att försöka ta sig så långt som möjligt. Vanligtvis har spelaren ett antal liv och när liven är slut så är spelet likaså och det är dags att lägga i nya mynt, om man nu har råd och/eller tid med det.

Många klassiska arkadspel har revitaliserats många gånger sedan de först släpptes efter som de är så älskade - inte minst i denna kursen! För att se exempel på spel som gjorts i denna kursen, och andra kurser med slutprojekt, finns exempel i korridoren utanför SU17/18 och på väggarna i vissa av salarna. Det är inte ovanligt att grupper gör kombinationer av klassiska spel eller tar inspiration från mer moderna mobil-/webspel. Möjligheterna är oändliga!

Kommunikation

En stor del i projekt handlar om kommunikation. Kommunikation är svårt, för när jag säger något är det långt ifrån säkert att mottagaren uppfattar samma sak som jag faktiskt menar. Olika personer har olika bakgrund, olika personlighet, och olika bra dagar och tar saker på vitt skilda sätt. Det är värt tänka på både som den som pratar och den som lyssnar. God kommunikation kan skapa förtroende för varandra och är en förutsättning för att kunna samarbeta. Försök vara tydliga med vad ni menar när ni pratar, och ställ kontrollfrågor för att se att ni förstår rätt när ni lyssnar. Ge varandra beröm för bra idéer och låt varandra komma till tals. Försök inkludera alla, fråga "vad tycker du"? Försök få en positiv stämning i gruppen. Om du observerar någon typ av problem i samspelet mellan gruppmedlemmar (dig inkluderad), ta upp det omgående. Om något inte känns bra så är det inte bra och då måste vi reda ut varför! Om du, gruppen eller assistenten inte inom ett par dagar visat att problemet är löst, vänd er till kursledaren.

Frånvarande gruppmedlem

Ett vanligt problem som brukar uppstå i minst en grupp varje år är att en gruppmedlem inte bidrar i den utsträckning ni kommit överens om. Medlemmen dyker inte alltid upp på gruppmöten och blir inte klar med sin uppgift, men lovar att den är klar om ett par dagar. Ett par dagar senare behöver medlemmen ytterligare lite tid. Och så vidare. Tills projekttiden är slut. Vid det laget har ingen av er roligt, ni har massor kvar att göra på ingen tid, och assistenten undrar varför ni inte märkte något tidigare. En sådan situation måste ni upptäcka och ta tag i direkt. Försök lägga upp arbetet så ni sitter tillsammans även när ni arbetar enskilt, och prata ofta om hur det går, hur långt ni kommit och om du hellre vill jobba med en annan del som passar dig bättre. Och redan andra gången en medlem missar att komma eller höra av sig hissar ni röd flagg.

Vi rekommendera att ni tänker igenom hur ni vill samarbeta och kommer överens om vad som gäller. Gruppkontrakt är ett verktyg för det. Vi ger er här en mall vi försökt hålla kort och samtidigt få med det viktigaste att tänka på.

• Instruktion (pdf)
• Instruktion (Latex) och tillhörande Latex-mall
• Exempelsamling (pdf)

Det är till er assistent ni lämnar in dokument, kod och bonusuppgifter. Under projektets gång har ni även möjlighet att få handledning av er assistent. Detta kan vara för att ni vill ha hjälp att tackla något problem, att ni vill diskutera krav, eller annat releterat till ert projekt. Om assistenten inte kan hjälpa er över mail kan ett möte bokas in. All kommunikation assistenten måste följande format:

      To: [er assistent]
      CC: LiU-ID@student.liu.se för samtliga projektmedlemmar
      Subject: TDDC76-Grupp-XX: [Ärendet, exempelvis "Problem med ...", "Ändring av krav", "Inlämning av ...", osv.]
      Content:
      En tydlig beskrivning av ärendet. (Se riktlinjer nedan)
    

Tänk på följande:

• Dokument bifogas som pdf (se krav för godkänt gällande dokument)
• Om ni behöver hjälp ska ni skriva:
• Detaljerat vad ni har för problem.
• Vad ni har försökt att göra och varför det inte har fungerat.
• Vad ni förväntar er att assistenten ska kunna hjälpa till med.

Det är viktigt att tänka på att assistenten inte är där för att lösa era problem åt er, utan assistenten är där för att hjälpa er att komma fram till en lösning. Därför att det viktigt att ni är tydliga med hur assistenten kan hjälpa er på bästa sätt.

• Om ni vill diskutera krav eller plannering är det viktigt att ni ger en tydlig annledning till varför ni vill diskutera detta.
• Tänk på att assistenten har mer än en projektgrupp, detta innebär att det kan ta assisenten upp till och med ett dygn att svara på mail.
• Assistenten gör en bedömning om ett möte ska bokas och assistenten bokar sal för mötet.
• Misstänker ni att ett möte behövs är det bra om ni föreslår minst tre tider så kan assistenten hitta en tid som passar hen.
• Anledningen till att vi har dessa krav är att assistenten ska kunna ge er bästa möjliga hjälp och optimera både er tid och assistentens tid.

Dessa krav relaterar till hur arbetet med projektet utförs och krav i de dokument och den kod ni skriver. Utöver dessa krav ska alla obligatoriska moment genomföras för att gruppen ska få ett godkänt projekt.

Följande krav är utformade för spel. Kontakta kursledare och examinator ifall ni vill skapa en annan typ av applikation, så översätts kraven för ert specifika projekt.

Krav på projektet (Spelet/Applikationen)

• Hela projektet ska ha en objektorienterad design som visar att alla projektmedlemmar arbetat objektorienterat med C++. Det ska finnas minst 6 st. olika klasser som representerar saker i spelet:
  • Varav minst 5 st. ska kunna röra sig i spelet. (Exempelvis fiender/non-playable characters, spelaren, power-ups, projektiler)
  • Varav minst 1 st. ska vara statiska i spelet. (Exempelvis hinder, väggar)

  Examinatorns kommentar: Tänk dig att du ritar upp en karta över spelvärlden medan du spelar. Objekt som inte flyttar sig på kartan är fasta. Objekt som rör sig i förhållande till kartan är rörliga. Det spelar ingen roll hur "kameran" som visar en del av eller hela spelvärlden på skärmen rör sig.

• Det ska finnas klasser/kodmängd som gör troligt att var och en lagt ned 40 timmar (motsvarande 1.5hp) på objektorienterad programmering (resterande 1.5hp behövs till andra projektuppgifter). Med en god objektorienterad design finns troligen ingen enstaka klass som kräver så mycket arbete så det är lämpligt att var och en siktar på att ansvara för mer än en klass. Tänk på att ett spel består av mer än själva spelmekaniken. Förslag på andra delar som kan behöva objektorienteras och programmeras: tillståndsmaskin, menysystem, resurshanterare, topplista, spelinställningar, grafiskt gränssnitt(knappar och inmatningsfält), fuskkonsol. Utöver det går det spendera programmeringstid åt testning av klasser. Var noga med att du själv commitar ditt arbete i git.
• Det ska finnas minst 1 klasshierarki som innehåller minst 4 st. objekt.
• Minst 1 objekt i spelet ska styras av spelaren, antingen med tangenbord eller mus.
• Det ska finnas kollisionshantering, det vill säga, det ska hända olika saker när objekten möter varandra, de ska påverka varandra på något sätt. T.ex kan ett av objekten tas bort, eller så kan objekten förvandlas på något sätt, eller så kan ett nytt objekt skapas. (Ett exempel på att skapa/ta bort objekt är när man i Space Invaders trycker på skjuta-knappen, t.ex en musknapp, då avfyras ett laserskott och skottet blir då en ny figur som skapas och placeras i världen, på en position vid laserkanonens mynning. Skottet rör sig framåt (uppåt) och om det träffar ett fiendeskepp tas både skottet och skeppet bort, om skottet kommer utanför spelplanen, dvs det missar, tas det endast bort.)
• Spelet måste upplevas som ett sammanhängande spel som går att spela!

Krav på projekthantering

• Projektgruppen ska vara 5-6 personer. Registrera gruppen i webreg.
• Git ska användas aktivt och kontinuerligt av alla gruppmedlemmar för allt material.
• Projektgruppen ska visa förmåga att skapa och följa en egen planering som tar kursens krav och planering i beaktande.
• Projektgruppen ska delta på en halvtidsavstämning med sin assistent. Då ska någon grundläggande del fungera.
• Projektgruppen ska hantera problem som uppstår inom gruppen omgående. Om en medlem uteblir från avtalat möte ska denne kontaktas. Om en medlem inte hunnit lösa sin uppgift inom planerad tid ska gruppen ta ansvar för att medlemmen har en (ny) uppgift, en tidplan och det stöd hen behöver. Om gruppen inte löst problemet (fått kontakt med medlemmen eller fått medlemmen att bidra med arbete) inom 3 arbetsdagar ska assistenten rådfrågas.

Krav på dokument

• Dokument ska vara skrivna med något text- eller dokumentverktyg och lämnas in som digital pdf.
• Dokument ska vara väl formaterade och skrivna på korrekt svenska med klart och tydligt språkbruk.
• Figurer och diagram får ritas prydligt för hand och scannas in.
• Övriga krav för respektive obligatoriskt dokument ligger tillsammans med instruktionen för det dokumentet (nedan) och ska vara uppfyllda.

Krav på programkod

• C++-standardbibliotek (STL) ska användas.
• Minst ett externt programbibliotek ska användas. (Förslagsvis SFML.)
• Programmet ska bygga upp sitt tillstånd från en extern resurs [datafil,databas]. Ändringar och tillägg i den externa resursen ska upplevas i spelet utan att programmet kräver omkompilering. Detta kan vara inläsning av nya banor och/eller inläsning av antal och typ av fiender i spelet.

  Examinatorns kommentar: All data som avgör när objekt i spelet skapas, var de placeras, hur de rör sig och egenskaper de har ska lagras på fil. Ingen data får hårdkodas i programkoden. Om spelet helt saknar data som avgör detta, t.ex. genom att objekt slumpas fram, så ska åtminstone någon data lagras på fil. Dessutom ska slumptalsfrö gå att välja när spelet startar (det underlättar er egen felsökning eftersom det då går att upprepa samma slumpsekvens igen), och slumpen ska styras så att inte omöjliga situationer skapas för spelaren.

• Programmet ska genomgående använda objektorienterad design där målet med varje klass är att den enkelt ska kunna ändras eller byggas ut utan att relaterade klasser påverkas. Ansvarsfördelningen bör vara sådan att varje funktion är så kort att den kan läsas i sin helhet utan att scrolla. Kod utanför ramen av en klass bör inte förekomma i den klassen. Rådgör genast med assistenten om din kod inte tillhör en klass eller din funktion inte ryms på skärmen.
• Koden ska uppfylla de kodkonventioner som tas upp i labbedömningsprotokollet. Undantag från detta ska vara dokumenterade och godkända av assistenten.
• Koden ska vara dokumenterad, både genom väl valda namn på variabler, klasser och funktioner och vid behov genom kompletterande kommentarer.
• Minst en icke-trivial klass (som har medlemsfunktioner utöver getters och setters) ska ha ett separat testprogram. Sikta på att testa den logik som är mest avancerad.
• Kod som lånats från eller inspirerats av extern källa (kod ej helt skriven av gruppmedlem) ska helt eller delvis tillskrivas originalkälla i en kommentar med referens/länk till originalkälla. Det gäller även kod tillhandahållen inom kursen eller som vi tipsat om.

Projektgruppsregistrering (Deadline: 2023-10-31 kl 12:00)

Kravspecifikation (Deadline: 2023-11-03 kl 17:00)

Objektorienterad analys (Deadline: 2023-11-08, 23:59)

Användning av Git (Deadline: Utförs kontinuerligt)

Halvtidsavstämmning (Bokas med assistent i v47)

Redovisning (Deadline: 2023-12-13, 13:00)

Kodinlämning (Deadline: 2023-12-13, 23:59)

      To: 
	CC: LiU-ID@student.liu.se för samtliga projektmedlemmar
	Subject: TDDC76-Grupp-XX: Kodinlämning
	Content:
	[Ska som minst innehålla en länk till ert projekt på Gitlab.]
    

Erfarenhetsrapport (Deadline: 2023-12-13, 23:59)

Totalt går det att samla ihop 16 bonuspoäng i projektet. (Bonuspoängräknare) Vissa av bonuspoängen är individuella och andra är till hela gruppen. Vissa bonusuppgifter kan bara utföras under en specifik period och andra ska utföras löpande under projektet. Det är därför viktigt att ni skapar er en överblick av uppgifterna så tidigt som möjligt. All information om bonusuppgifter går att hitta nedan i respektive länk med instruktioner. I instruktionerna står det, utöver vad som ska genomföras, hur uppgiften examineras. (Om något upplevs som otydligt i instruktionerna är det viktigt att du kontaktar kursledaren omgående.)

Om du har frågor om bonusuppgifterna ska dessa mailas till din assistent. (Se "Kontakt med assistent" ovan) Detta är för att kunna ge snabbare svar än att vänta tills nästa projektmöte och för att inte ta gruppens tid för en individuell bonusuppgift.

Länkar till bonusuppgifter:

• Leda ett projektmöte med assistent (2p)
• Bra användning av Git (4p)
• Grundstruktur i release v0.1 (4p)
• Veckolig statusrapport och uppföljning av plan (1-6p)

Följande är en samling av resurser relaterade till olika verktyg och tanken är att de kan vara en startpunkt i ert arbete med verktygen. Det finns, utöver detta, otroligt mycket information på nätet som går att söka sig till.

SFML

• SFMLs egna tutorial
• SFMLs dokumentation
• SFML exempel 1 (Endast som inspiration)
• SFML exempel 2 (Endast som inspiration)



• För att kompilera med SFML på idas system behöver ni, efter filerna, lägga till flaggorna:

  -lsfml-graphics -lsfml-window -lsfml-system

• För att använda Valgrind i kombination med SFML behöver ni köra följande:

  valgrind --suppressions=./suppressions.txt ./mitt-spel

  supperssions.txt är en fil som ni behöver ladda ner och lägga i mappen som ni kör valgrind ifrån.

Make

• Instruktioner för Makefile
• Kort introduktion till CMake
• CMakes egna tutorial

Git

• Kom igång med Gitlab
• Dokumentationen för Git
• Codecademys tutorial för Git (Relevanta delarna är Git Workflow för upg1 och Git Branching för upg2&3)
• Git Cheat Sheet

Alternativ till emacs

• VSCode
• CLion

Övriga resurser

• Socketar i ett nötskal
• Doxygen - dokumentationssystem för, bland annat, C++
• Draw.ioOnline verktyg för att skapa UML-diagram
• Valgrind - en kort guide
• TDD och Catch - en liten guide
• Frida Flodins (grymma) spelskellett med tillståndsmaskin (Endast som inspiration)