report/README.org

   1 #+TITLE:     Spec/plan laboration 4, apjava
   2 #+AUTHOR:    Anton Johansson, Andreas Jacobsson
   3 #+EMAIL:     anton.johansson@gmail.com
   4 #+DATE:      2008-12-08 Mon
   5 * Notes
   6 ** Första <2008-12-10 Wed 20:30>--<2008-12-10 Wed 23:29>
   7    Squares extends JComponent, Observable (Towers ska vara Observers),
   8    Units meddelar rutor att de befinner sig i dem. Towers får då en
   9    referns till aktuell Unit och lägger denna i en lista för
  10    beskjutning.
  11
  12    Anledningen till något typ av arv av JComponent är att
  13    vi vill ha metoden getComponentAt(Point) från en högre nivå (Map av
  14    typ JComponent?) för att Units ska kunna veta vilken ruta de
  15    befinner sig på.
  16
  17
  18   - Vi använder XMLSchema.
  19 * Om spelet
  20   Ett Tower Defence-spel är ett spel i vilket användarens uppgift är att
  21   skydda sig mot fiender genom att sätta upp torn. Dessa torn ska sedan
  22   skjuta ner fienden innan de når ett givet mål, och tornen måste
  23   således placeras ut strategiskt.
  24
  25   För att göra spelet intressantare brukar det krävas att en viss mängd
  26   fienden tar sig i mål för att man ska förlora, och det kan finnas
  27   flera sorters fiender och torn (flygande och markgående fienden etc.).
  28
  29 * Spelets regler
  30   - Att släppa ut trupper ska kosta valuta (nedan kallat kredit), och
  31     spelaren får ett antal krediter tilldelade varje bana. När dessa
  32     är slut kan inga trupper köpas, och spelaren förlorar om de
  33     trupper på banan inte tar sig i mål och ger upphov till vinst.
  34   - Vinst är när ett visst antal "målkrediter" tjänats. Detta brukar
  35     bara vara ett antal truppmedlemmar, men kan mycket väl viktas med
  36     deras hälsa när de kommer in i mål.
  37   - Krediter tjänas på något sätt under banans gång, förslagsvis en
  38     viss krediter/sekund för varje truppmedlem, samt en viss mängd
  39     krediter vid målgång.
  40   - Fienden behöver inte vara smarta. Det räcker med att de väljer en
  41     varelse inom räckhåll och skjuter på den.
  42   - Fienden får ha endast laser (ljusstråle som träffar direkt så ni
  43     slipper beräkna en projektils bana).
  44   - Utplacering av tornen som skjuter på trupperna behöver endast
  45     placeras ut slumpmässigt i tillåtna zoner.
  46
  47 * Laborationen
  48   Laborationen ska lösas i grupper om 2 (två) personer. Det ses från vår
  49   sida som en näst intill omöjlig uppgift att göra laborationen enskilt
  50   under kursens gång, därför finns det inga undantag. Parindelningen är
  51   upp till er att fixa, men alla grupper ska anmäla sig på denna
  52   sida. Vet ni inte om någon att jobba med så skriv in er i en ny grupp
  53   , eller om det redan finns en grupp med bara en person så skriv in er
  54   i den och kontakta så snart som möjligt personen som redan stod där om
  55   att du vill jobba med honnom/henne.
  56
  57   Målet med spelet är att skapa en bas för utbyggnad av
  58   funktionaliteten. Därför är det väldigt viktigt att ni lägger stor
  59   möda på spelets interna struktur för att få en lättnavigerad kodbas
  60   med logisk uppbyggnad. Dokumentationen är väldigt viktig den med,
  61   vilket innebär att samtliga klasser, samtliga metoder samt
  62   medlemsvariabler ska kommenteras med utförliga
  63   JavaDoc-kommentarer. JavaDoc är dock inte den enda typen av grundlig
  64   dokumentation som krävs, se nedan.  Syfte
  65
  66 * Syftet med laborationen är att få pröva på och använda:
  67   - Trådar
  68   - XML / DTD / XMLSchema
  69   - GUI (Swing)
  70   - Grafik
  71   - Öva färdigheten i rapportskrivning med en specifik målgrupp
  72   - Följa en given kodkonvention
  73
  74 * Er uppgift
  75   Er uppgift är inte att implementera ett Tower Defence-spel, utan ett
  76   Anti-Tower Defence-spel. Ni ska alltså låta användaren skicka ut
  77   fienden som sedan datorn ska skjuta ner. Ett exempel på ett sådant
  78   spel är: [[http://www.sugar-free-games.com/playgame.php%3Fgame%3D1127][Anti-TD]] på Sugar Free Games.
  79 ** Kravlista
  80    För att göra spelet mer intressant ut laborationssynpunkt finns det
  81    en del krav på er lösning:
  82
  83 *** I alla nivåer gäller:
  84 **** TODO Implementera spelet AntiTD i Java
  85 **** TODO Följa SUN:s kodkonvention: http://java.sun.com/docs/codeconv/index.html
  86 **** TODO Följa god OO- och MDI-stil.
  87 **** TODO Källkoden skall ligga i katalogen: ~/edu/apjava/lab4/src/
  88 **** TODO En komplierad version i katalogen: ~/edu/apjava/lab4/bin/
  89 **** TODO Rapporten skall ligga i katalogen: ~/edu/apjava/lab4/report/
  90 **** TODO JavaDoc-sidorna skall ligga i katalogen: ~/edu/apjava/lab4/doc/
  91
  92 *** TODO Nivå 1 (grundnivå)
  93 **** TODO Klassen "AntiTD"
  94      Startar ett Anti Tower Defence-spel utan att ta emot några argument från användaren.
  95 **** TODO Trådar
  96      Spelet ska använda sig av flera trådar för att låta flera delar jobba parallellt.
  97 **** TODO Uppdateringsintervall
  98      Spelets uppdateringsintervall skall vara tidsberoende och inte
  99      beroende av datorns hastighet.
 100 **** TODO Banor
 101      Det ska finnas minst en bana längs vilken man kan skicka ut
 102      trupper.
 103 **** TODO Vinst/Förlust
 104      Vid "vinst" eller "förlust" så ska användaren presenteras med
 105      valet om att spela igen eller avsluta spelet. Medans detta val
 106      pågår så ska inte användaren kunna göra nåt annat, men objekt på
 107      spelplanen ska fortsätta röra sig.
 108 **** TODO GUI:t skall använda sig av Swing-biblioteket.
 109 **** TODO Rendering
 110      All rendering skall ske dubbelbuffrat för att undvika flimmer.
 111 **** TODO Det ska finnas minst två huvudmenyer:
 112      - En meny med valen:
 113        + New Game/Restart
 114          + Om inget spel har startats så heter menypunkten tex. "New
 115            Game" och vid klick så startar den ett nytt spel. Om spelet
 116            redan är igång så ska menypunkten heta tex. "Restart" och
 117            spelet börjar om från början.
 118        + Pause/Resume
 119          + Menypunkten kan tex. heta "Pause" om spelet är igång och
 120            när man klickar på menypunkten så ska alla trupper och torn
 121            stanna och inga knappar ska gå att klicka på. Om spelet är
 122            i "Pause"-läge så ska menypunkten byta namn till
 123            tex. "Resume" och vid klick så ska spelet återupptas där
 124            det sist var, dvs. fordonen skall fortsätta röra på sig
 125            samt att användaren kan skicka ut fler trupper.
 126        + Mute
 127          + Sluta spela upp ljud. Då den här menyn väljs ska
 128            menyalternativet bytas till "Unmute" och vice versa.
 129        + Quit
 130          + Avsluta spelet.
 131      - Den andra menyn ska innehålla:
 132        + About: Berättar i en dialogruta vem som gjort spelet och när.
 133        + Help: Berättar i en dialogruta hur man spelar.
 134 **** TODO Zoner i banor
 135      Varje bana skall innehålla zoner där datorn kan placera ut torn,
 136      vägar längs vilka trupper kan röra sig.
 137 **** TODO Grupptyper
 138      Minst två typer av trupper ska implementeras med olika förmågor
 139      (klarar olika antal träffar, kostar olika mycket, har olika
 140      hastighet, etc.).
 141
 142 *** TODO Nivå 2 (multipla banor/XML)
 143 **** TODO Flera banor
 144      Spelet ska klara av flera banor. Banorna ska se olika ut,
 145      exempelvis hur trupperna kan röra sig.
 146 **** TODO Spara banor i fil levels.xml
 147      Flera banor skall lagras i en fil som heter
 148      "levels.xml". XML-formatet skall följa en DTD som ni själva
 149      specificerar. XML-filen skall valideras mot den DTD (eller XML
 150      Schema) ni skriver.
 151 **** TODO Banzoner
 152      Varje bana skall innehålla zoner där datorn kan placera ut torn,
 153      vägar längs vilka trupper kan röra sig, samt regler för banan,
 154      exempelvis hur många trupper som måste komma igenom för att
 155      användaren ska vinna. Allt detta ska stå i XML-filen under varje
 156      bana.
 157 **** TODO Vinst/förlust
 158      När användaren "vinner" en bana så skall spelet fråga användaren
 159      om den vill spela samma bana en gång till eller fortsätta till
 160      nästa bana.
 161 **** TODO Restart level
 162      Den första menyn ska byggas ut med alternativet "restart level".
 163 **** TODO Flera vägsträckor per bana
 164      Det ska finnas (möjlighet till, samt exempel på) flera möjliga
 165      vägsträckor per bana för trupperna.
 166 **** TODO Spara resultat till Highscoreservice
 167      Alla resultat ska sparas med hjälp av det ni gjorde i
 168      lab 3. Highscores ska kunna visas (baserat på tid, poäng, nivå,
 169      etc.).
 170 **** TODO Parameter som anger levels.xml vid start
 171      Ges ett argument vid körning ska detta tolkas som ett filnamn och
 172      läsas in istället för levels.xml och på så vis kan fler banor
 173      göras och köras utan att modifiera i spelets katalog.
 174
 175 *** TODO Nivå 3 (triggers / jar)
 176 **** TODO Triggers, vägpekare i vägskäl?
 177      Banor ska kunna innehålla (och det ska finnas exempel på banor
 178      som innehåller) "växlar" som gör att en väg kan mynna ut i en
 179      T-korsning där spelaren klickar på ex. en knapp för att välja åt
 180      vilket håll trupperna ska gå.
 181 **** TODO Skapa ett interface som har en metod "landOn".
 182 **** TODO Banklasser implements landOn
 183      De olika områdena på en bana skall finnas i egna klasser. Varje
 184      sådan klass kan implementera interfacet beskrivet ovan.
 185 **** TODO Läsa in class-filer från XML?
 186      Vid start av en ny bana så skall programmet läsa in de
 187      class-filer som XML-filen har deklarerat som sina områden och när
 188      truppmedlemmarna går på ett visst område så ska denna
 189      områdesklass funktion "landOn" anropas och någonting skall hända,
 190      förutsatt att den implementerat ovan nämnda interface.
 191 **** TODO Områden, ex Teleporters
 192      Ett speciellt område utöver de beskrivna hittills skall
 193      finnas. Tex: Teleporters, när en truppmedlem går på en viss ruta
 194      så flyttas den till en annan på vägen.
 195 **** TODO Teleportertrupper
 196      Teleportertrupper ska implementeras som kostar mer, men ska kunna
 197      lägga ner teleporterplattor när användaren väljer, och på så vis
 198      kommer trupperna att kunna slippa förflytta sig lika långt.
 199 **** TODO Spelet sparas i AntiTD.jar
 200      Spelet samt de filer som behövs för grundspelet skall finnas i en
 201      JAR-fil som heter "AntiTD.jar". Spelet ska startas med kommandot:
 202      java -jar AntiTD.jar
 203
 204 * Redovisning
 205   Den här laborationen har inte bara ett fungerande system som mål, utan
 206   den ska även vara en bas för vidareutveckling. Därför ska den visas
 207   upp för en fiktiv kund som ska köpa spelet av er för en stor hög
 208   pengar. Därför är det viktigt att ni gör bra ifrån er på både spelets
 209   uppvisning, och dokumentationen som ska lämnas in.
 210
 211 ** Milestone DEADLINE: <2008-12-18 Thu 15:00>
 212    Innan jul ska ni boka in er för ett tillfälle hos handledarna för
 213    att redovisa projektets framskridande. Vid detta möte bör delar av
 214    programmet vara implementerat och ni bör kunna redovisa en plan (i
 215    form av följande dokument) för hur arbetet ska fortskrida fram till
 216    de olika redovisningstillfällena. Ni kommer att kunna boka in er
 217    för denna redovisning 18/12 mellan 15-17. Bokning av tid kommer att
 218    kunna ske senast veckan innan (info om detta kommer via mail). Om
 219    ni av någon anledning vet att ni ej kan delta vid detta tillfälle
 220    så hör av er till handledarna i förväg så kan redovisningen
 221    genomföras vid något tidigare tillfälle.
 222
 223 ** Uppvisning (promotion) DEADLINE: <2009-01-13 Tue>
 224   Samtliga lösningar ska visas på gruppövningen den 13e
 225   januari. Ungefär 10 minuter per grupp ges. Tar uppvisningen för
 226   lång, eller för kort tid, minskar intresset från kunden. Hjälpmedel
 227   ni har att tillgå är: OH-apparat, ... Mer info kommer senare.
 228
 229 ** Fysisk inlämning av dokumentation
 230    Det som i normala fall brukar vara en rapport om själva utvecklandet
 231    kommer på den här laborationen ha en annan uppgift.
 232
 233    Utöver dokumentationen av programmet så ska ni även lämna in en
 234    detaljerad beskrivning av vem som gjort vad i projektet. Detta för att
 235    individuell poängbedömning ska kunna göras (var nogrann med
 236    denna). Denna del ska ges som en bilaga till rapporten. Till exempel
 237    kan en uppdaterad version av dokumentet från milestone tillfället
 238    ingpå. Observera att det inte räcker med en mening där ni säger att ni
 239    båda varit inblandade i allt och gjort lika mkt (lite mer detaljnivå
 240    krävs).
 241
 242 * Programdokumentation  DEADLINE: <2009-01-13 Tue 15:15>
 243   Dokumentation av arbetet ska vara inlämnad senast Tisdag 13/1-09
 244   15:15 Den största vikten i rapporten ligger på hur systemet är
 245   uppbyggt. Vilka delar ska modifieras för att olika effekter ska
 246   uppnås. Här hör ett eller flera UML-diagram hemma,
 247   algoritmbeskrivningar i grafisk form, etc.
 248
 249   Tänk på att den här delen ska fungera som referenslitteratur. Det
 250   ska alltså inte vara uppsatser, utan listor, bilder, grafer,
 251   tabeller, träd, etc. Små textstycken behövs med, men en
 252   beskrivningar i uppsatsform är inget alternativ.
 253
 254 * Bedömning
 255   Rapporten kommer betygsättas utifrån dels utseende (teckensnittsval,
 256   marginalbredd, sidnumrering), innehåll (styckeuppdelning, förlopp, hur
 257   lätt det är att slå upp saker i den), informationsförmedling (vad
 258   berättas i rapporten), och slutligen kommer även stavfel,
 259   särskrivningar, meningsbyggnadsfel och språkblandningar in i bilden.
 260
 261   JavaDoc-sidorna kommer gås igenom och deras innehåll kommer bedömas.
 262
 263   Javakoden kommer synas så den följer konventioner och "bra"
 264   programmeringsstil. Ex. på mindre bra programmeringsstil är:
 265
 266   : if (a.getP() < 4)
 267   :    return false;
 268   :  else
 269   :    return true;
 270
 271   En helhetsbedömning av bl.a. ovanstående kommer poängsätta rapporten,
 272   kodens dokumentation, redovisning och källkoden. Resultatet kommer
 273   bli: Nivå Poäng 1 0 - 7 2 0 - 14 3 0 - 20
 274
 275   Dokumentationen kommer stå för runt 1/3 av den totala poängen, så glöm
 276   inte att lägga ner tid på den.
 277
 278   OBS: Poängsättningen av labben kommer att ske på den först inlämnade
 279   versionen. Fel som ger O på labben kommer givetvis att bidra till att
 280   minska poängtalet rätt rejält.
 281
 282 * Ev otydligheter i specifikationen
 283   Är något otydligt i specifikationen så är det upp till er att klargöra
 284   vad som gäller. Redovisa även sådana klargörande i rapporten.