Göm menyn

TDP005 Projekt: Objektorienterat system

Projektbeskrivning


Uppgiften går ut på att designa och implementera ett 2-dimensionellt dataspel (en typ av arkadspel) som är en simulering av en värld där figurerna i världen har ett beteende över tiden och där spelaren styr en av dessa figurer.

Läs följande text om arkadspel som Mikael Kindborg skrivit för lite inspiration.

Fokus i kursen ligger på objektorientering. Ni ska designa, beskriva och programmera ett spel med god objektorienterad design. I bedömningen av detta ingår förstås den färdiga produkten, men även de dokument ni producerar, som beskriver ert spel, och processer kring detta är en central del i bedömningen. Projektet ska genomföras i enlighet med vad som beskrivits i IP-projekt bilagan till Handboken för IP-studenter. Ni kan hitta den under "IP-projekt handbok" i menyn.

Krav på projektet

Programmet skall ha följande egenskaper/funktioner:
  • Spelet ska simulera en värld som innehåller olika typer av objekt. Objekten ska ha olika beteenden och röra sig i världen och agera på olika sätt när de möter andra objekt.
  • Det måste finnas minst tre olika typer av objekt och det ska finnas flera instanser av minst två av dessa. T.ex ett spelarobjekt och många instanser av två olika slags fiendeobjekt.
  • Ett beteende som måste finnas med är att figurerna ska röra sig över skärmen. Rörelsen kan följa ett mönster och/eller vara slumpmässig. Minst ett objekt, utöver spelaren ska ha någon typ av rörelse.
  • En figur ska styras av spelaren, antingen med tangentbordet eller med musen. Du kan även göra ett spel där man spelar två stycken genom att dela på tangentbordet (varje spelare använder olika tangenter). Då styr man var sin figur.
  • Grafiken ska vara tvådimensionell.
  • Världen (spelplanen) kan antas vara lika stor som fönstret (du kan göra en större spelplan med scrollning, men det blir lite krångligare).
  • 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.)
  • Det ska vara enkelt att lägga till eller ändra banor i spelet. Detta kan exempelvis lösas genom att läsa in banor från en fil (lite som i Sokoban-labben i TDP002), eller genom att ha funktioner i programkoden som bygger upp en datastruktur som definierar en bana.
  • Spelet måste upplevas som ett sammanhängande spel som går att spela!

Krav på implementationen

Modellering av en värld och kommunikation mellan objekt i världen och olika lösningar av detta är centralt för uppgiften. Ett sätt är att tänka i termer av lager, ett för visualiseringen (UI) och ett för simuleringsmodellen. Fördelen med en sådan uppdelning är att det blir färre beroenden mellan objekt, objekten har tydliga roller, programmet blir lättare att ändra i, och det blir enklare att skapa olika typer av visualiseringar i och med att gränssnittet och modellen har skiljts åt (kallas "decoupling").

Följande begrepp och tekniker blir då viktiga:

  • Hur man bygger upp en värld av objekt och hur man modellerar objekten med hjälp av arv.
  • Arv och polymorfirsm; en gemensam basklass (superklass) definierar ett gemensamt protokoll av meddelanden för objekt med liknande egenskaper.
  • Visualisering i form av tvådimensionella animerade figurer, så kallde "sprites".
Krav på koden:
  • Koden ska följa en accepterad kodstandard. Koden ska gå att kompilera och köra i Linux Mint.
  • Koden ska vara väldokumenterad. Doxygen ska användas.
  • "Information hiding" ska användas (ingen åtkomst av instanvariabler utanför klassen).
  • Designen ska vara modulär med så få beroenden mellan klasser som möjligt.
  • Det ska finnas en gemensam basklass (Sprite) för alla figurer i programmet. Övriga sprite-figurer ska ärva från denna klass.
  • Det ska finnas abstrakta metoder, åtminstone för er Sprite-hierarki.
  • Main-funktionen ska vara liten, huvuddelen av spelet ska finnas i de klasser ni designar. Ett exempel på en lämplig main-funktion:
    int main {
       Game game;
       game.run();
       return 0;
    }
        
  • Grafiken ska realiseras med hjälp av SFML.
  • Tillsammans med koden ska en Makefile lämnas in. Handledaren ska kunna köra koden i terminalen med hjälp av denna Makefile.

Bedömningskriterier

Utöver de absoluta kraven ovan, tar vi även hänsyn till nedanstående punkter vid bedömningen av koden. En stor vikt av bedömningen ligger på den objektorienterade designen som används samt hur den har realiserats i kod. För betyg 5 ska den objektorienterade designen vara väl genomtänkt och väl implementerad genomgående i projektet. För betyg 4 kan mindre brister finnas, antingen i implementationen eller i designen. Betyg 3 ges då det finns stora brister i implementationen och/eller den objetorienterade designen.

För att bedömma hur er design och implementation kommer vi titta på följande punkter:

  • Objektorienterad design:
    • Den objektorienterade designen är god.
    • Varje klass har en tydlig avgränsad uppgift, och är lagom i storlek.
    • Antalet beroenden mellan klasser är rimligt, och inte alltför högt.
    • Designen är flexibel, och det är lätt att utöka spelet med ny funktionalitet inom den aktuella designen.
  • Implementation:
    • Koden är tydlig, lättläst och lättförståelig.
    • Minne hanteras väl, inga minnesläckor finns.
    • const används på ett vettigt sätt.
    • Medlemsfunktioner och -variabler har lämplig åtkomst (dvs. public, protected och private används på ett bra sätt)

Checklista för kodstandard

För att åstadkomma en bra implementation utifrån er design är det bra att tänka på följande saker:

  • Koden är tydlig, lättläst och lättförståelig
    • Bra variabel- och metodnamn
    • Lämplig uppdelning mellan metoder
  • Minneshanteringen är god och inga minnesläckor finns
    • Konstruktorer och (virtuella) destruktorer är implementerade på ett korrekt sätt
    • Kopieringskonstruktor och tilldelningsoperator är korrekt implementerade eller privat deklarerade där detta är motiverat
    • Pekare används korrekt och säkert
    • Återlämning av minne är korrekt implementerat
  • Parameteröverföring (inkl. returvärden) sker på ett vettigt sätt
    • Lämplig användning av call-by-value, call-by-reference och pekare
    • Inga onödiga kopieringar görs vid parameteröverföring
    • const-deklarering används där detta är lämpligt
  • Variabler:
    • const-deklarerats där detta är motiverat
    • Har lämplig åtkomlighet: private, protected eller public
    • Lokala variabler används där det är lämpligt
    • Har lämpliga typer
    • Initialiseras med lämpliga värden
    • Inga globala variabler finns
    • Alla variabler används och har endast ett syfte
  • Metoder:
    • Har lämplig åtkomlighet: private, protected eller public
    • const-deklarering används där detta är lämpligt
  • Koden är säker:
    • Den ska inte kunna krascha
    • Input från användaren kontrolleras på ett säkert sätt
  • Koden är effektiv, till exempel genom att:
    • Lämpliga algoritmer och datastrukturer har använts
    • De vanligaste valen står först i if-satser
    • Beräkningar som kan göras utanför en loop gör det snarare än att stå i loopen
  • Upprepning av liknande/identisk kod har undvikits genom att till exempel använda lämpliga funktoner
  • Koden är kommenterad på lämpligt sätt
    • Kommentarer har angivits för klasser, metoder etc. enligt Doxygen, och de kan användas för att skapa en meningsfull dokumentation
    • Kommentarer används i koden när ett behov finns, men inte annars
    • Kommentarer är tydliga och lättförsåteliga
    • Kommentarer stämmer överens med koden

Sidansvarig: Filip Strömbäck
Senast uppdaterad: 2018-11-14