| blob | 8c4418e827a54c8d6178d585af012e1e2cd5bf8b |
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.
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å.
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.
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.).
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.
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.
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
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
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:
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/
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.).
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.
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
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.
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.
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.
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.
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).
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.
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.
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.
261 JavaDoc-sidorna kommer gås igenom och deras innehåll kommer bedömas.
263 Javakoden kommer synas så den följer konventioner och "bra"
264 programmeringsstil. Ex. på mindre bra programmeringsstil är:
266 : if (a.getP() < 4)
267 : return false;
268 : else
269 : return true;
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
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.
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.
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.