Om spelet

Ett Tower Defence-spel är ett spel i vilket användarens uppgift är att skydda sig mot fiender genom att sätta upp torn. Dessa torn ska sedan skjuta ner fienden innan de når ett givet mål, och tornen måste således placeras ut strategiskt.

För att göra spelet intressantare brukar det krävas att en viss mängd fienden tar sig i mål för att man ska förlora, och det kan finnas flera sorters fiender och torn (flygande och markgående fienden etc.).

Er uppgift

Er uppgift är inte att implementera ett Tower Defence-spel, utan ett Anti-Tower Defence-spel. Ni ska alltså låta användaren skicka ut fienden som sedan datorn ska skjuta ner.

Spelets regler

Laborationen

Laborationen ska lösas i grupper om 2 (två) personer. Det ses från vår sida som en näst intill omöjlig uppgift att göra laborationen enskilt under kursens gång, därför finns det inga undantag. Parindelningen är upp till er att fixa, men alla grupper ska anmäla sig på denna sida. Vet ni inte om någon att jobba med så skriv in er i en ny grupp , eller om det redan finns en grupp med bara en person så skriv in er i den och kontakta så snart som möjligt personen som redan stod där om att du vill jobba med honnom/henne.

Målet med spelet är att skapa en bas för utbyggnad av funktionaliteten. Därför är det väldigt viktigt att ni lägger stor möda på spelets interna struktur för att få en lättnavigerad kodbas med logisk uppbyggnad. Dokumentationen är väldigt viktig den med, vilket innebär att samtliga klasser, samtliga metoder samt medlemsvariabler ska kommenteras med utförliga JavaDoc-kommentarer. JavaDoc är dock inte den enda typen av grundlig dokumentation som krävs, se nedan.

Syfte

Syftet med laborationen är att få pröva på och använda:

Er uppgift

Er uppgift är inte att implementera ett Tower Defence-spel, utan ett Anti-Tower Defence-spel. Ni ska alltså låta användaren skicka ut fienden som sedan datorn ska skjuta ner. Ett exempel på ett sådant spel är: Anti-TD på Sugar Free Games.

I alla nivåer gäller:

Kravlista

För att göra spelet mer intressant ut laborationssynpunkt finns det en del krav på er lösning:

Nivå 1 (grundnivå)

Nivå 2 (multipla banor/XML)

Nivå 3 (triggers / jar)

Redovisning

Den här laborationen har inte bara ett fungerande system som mål, utan den ska även vara en bas för vidareutveckling. Därför ska den visas upp för en fiktiv kund som ska köpa spelet av er för en stor hög pengar. Därför är det viktigt att ni gör bra ifrån er på både spelets uppvisning, och dokumentationen som ska lämnas in.

Milestone

Innan jul ska ni boka in er för ett tillfälle hos handledarna för att redovisa projektets framskridande. Vid detta möte bör delar av programmet vara implementerat och ni bör kunna redovisa en plan (i form av följande dokument) för hur arbetet ska fortskrida fram till de olika redovisningstillfällena. Ni kommer att kunna boka in er för denna redovisning 18/12 mellan 15-17. Bokning av tid kan göras här. Om ni av någon anledning vet att ni ej kan delta vid detta tillfälle så hör av er till handledarna i förväg så kan redovisningen genomföras vid något tidigare tillfälle. Varje grupp kommer att få 10 minuter till sitt förfogande.

Uppvisning (promotion)

Samtliga lösningar ska visas på gruppövningen den 13e januari. Ungefär 10 minuter per grupp ges. Tar uppvisningen för lång, eller för kort tid, minskar intresset från kunden.
Boka in er på ett redovisningstillfälle här
Hjälpmedel ni har att tillgå är: OH-apparat, Dator med projektor.

Fysisk inlämning av dokumentation

Det som i normala fall brukar vara en rapport om själva utvecklandet kommer på den här laborationen ha en annan uppgift.

Utöver dokumentationen av programmet så ska ni även lämna in en detaljerad beskrivning av vem som gjort vad i projektet. Detta för att individuell poängbedömning ska kunna göras (var nogrann med denna). Denna del ska ges som en bilaga till rapporten. Till exempel kan en uppdaterad version av dokumentet från milestone tillfället ingå. Observera att det inte räcker med en mening där ni säger att ni båda varit inblandade i allt och gjort lika mkt (lite mer detaljnivå krävs).

Programdokumentation

Dokumentation av arbetet ska vara inlämnad senast Tisdag 13/1-09 15:15

Den största vikten i rapporten ligger på hur systemet är uppbyggt. Vilka delar ska modifieras för att olika effekter ska uppnås. Här hör ett eller flera UML-diagram hemma, algoritmbeskrivningar i grafisk form, etc.

Tänk på att den här delen ska fungera som referenslitteratur. Det ska alltså inte vara uppsatser, utan listor, bilder, grafer, tabeller, träd, etc. Små textstycken behövs med, men en beskrivningar i uppsatsform är inget alternativ.

Bedömning

Rapporten kommer betygsättas utifrån dels utseende (teckensnittsval, marginalbredd, sidnumrering), innehåll (styckeuppdelning, förlopp, hur lätt det är att slå upp saker i den), informationsförmedling (vad berättas i rapporten), och slutligen kommer även stavfel, särskrivningar, meningsbyggnadsfel och språkblandningar in i bilden.

JavaDoc-sidorna kommer gås igenom och deras innehåll kommer bedömas.

Javakoden kommer synas så den följer konventioner och "bra" programmeringsstil. Ex. på mindre bra programmeringsstil är: 

  if (a.getP() < 4)
    return false;
  else
    return true;

En helhetsbedömning av bl.a. ovanstående kommer poängsätta rapporten, kodens dokumentation, redovisning och källkoden. Resultatet kommer bli:
Nivå Poäng
10 - 7
20 - 14
30 - 20

Dokumentationen kommer stå för runt 1/3 av den totala poängen, så glöm inte att lägga ner tid på den.

OBS: Poängsättningen av labben kommer att ske på den först inlämnade versionen. Fel som ger O på labben kommer givetvis att bidra till att minska poängtalet rätt rejält.

Ev otydligheter i specifikationen

Är något otydligt i specifikationen så är det upp till er att klargöra vad som gäller. Redovisa även sådana klargörande i rapporten.