Göm menyn

TDDE71 Programmering och datastrukturer

Projektkrav

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.

Sidansvarig: Eric Ekström
Senast uppdaterad: 2024-08-20