TDP005 Projekt: Objektorienterade 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.

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.)
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 Ubuntu.
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-metoden ska vara liten, huvuddelen av spelet ska finnas i de klasser ni designar. Ett exempel på en lämplig main-metod:
```
int main {
   Game game;
   game.run();
   return 0;
}
```
Grafiken ska realiseras med hjälp av SDL.
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. För att få en 5:a gäller att alla punkter ska vara uppfyllda. För en 4:a ska punkterna vara uppfyllda i hög grad. För en 3:a gäller att huvuddelen av punkterna ska uppfyllas i relativt hög grad.

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.
Kod
- 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 implementerad
- 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ämnds 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
Kommentarer
- 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 tydlig och lättförsåteliga
- Kommentarer stämmer överens med koden

Slutredovisning av projektet

Förutom de rapporter ni lämnar in under kursen, ska projektet slutredovisas. I slutredovisningen ingår följande delar:

Koden. Den ska uppfylla de krav som återfinns nedan. Koden redovisas via GitLab.
En användarhandledning för ert spel
Dessutom ska ni vid demotillfället i kursens slut (se seminarium under "Schema") visa upp ert färdiga spel, samt kunna svara på frågor kring hur det är uppbyggt. Det är obligatoriskt att närvara vid demotillfället.

Under demotillfället visar du upp ditt spel och provar de program som de andra grupperna har utvecklat. Det går till så att halva klassen sitter vid datorerna och visar upp sina spel och den andra halvan går runt och provspelar. Efter halva tiden byter man.

Handledarna och examinator kommer också att gå runt och titta på alla spel och ställa frågor om spelen. Samtliga gruppmedlemmar ska kunna svara på frågor om spelets uppbyggnad, design och implementation.

Sidansvarig: Jonas Lindgren
Senast uppdaterad: 2013-11-10