| blob | 20b1cfb0037e16fc10e1cc4092adfc334b55cedf |
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
6 * Frågor
7 ** TODO Trådar
8 Vad skulle fördelen kunna vara med att försöka sätta varje Unit i
9 en separat tråd? Vad blir mest beräkningstungt, att göra massa
10 saker i samma tråd mot att hantera varje enhets logik separat?
12 * Thinking sessions
13 ** Första <2008-12-10 Wed 20:30>--<2008-12-10 Wed 00:36>
15 *** Klasser
16 - Item <|- Health, Teleport, SpeedBoost, Guns 'n' ammo.
17 - Square <|- Stone, Savanna, Road. Idé, varje Square har en
18 instans av Javas Rectangle för att kunna använda dess intersects
19 metod.
20 - Road <|- Sand, Ice.
21 - Intersection en Item? Ett sätt att välja väg vid
22 flervalskorsningar.
23 - Map, JComponent?
24 - Model håller koll på alla enheter.
25 - Controller, The allseeing eye, säger till varje enhet att
26 uppdatera sig själv.
27 - View, ritas upp för varje fram. Kontroller meddelar när det är
28 dags, data hämtas från Model.
29 - Poängräkning skulle kunna ske i separat tråd som sover
30 specificerat antal millisekunder för att sedan vakna upp och
31 räkna av antalet enheter på plan.
32 - Player, synchronized score!
34 *** Interface
35 - Ett interface för att se till att allt som behöver det har en
36 =intersects()= metod för att testa om den överlappar annan klass
37 som implementerar samma interface. Främst för Unit.
39 *** Logik
40 Squares extends JComponent, Observable (Towers ska vara Observers),
41 Units meddelar rutor att de befinner sig i dem. Towers får då en
42 referns till aktuell Unit och lägger denna i en lista för
43 beskjutning.
45 Anledningen till något typ av arv av JComponent är att
46 vi vill ha metoden getComponentAt(Point) från en högre nivå (Map av
47 typ JComponent?) för att Units ska kunna veta vilken ruta de
48 befinner sig på.
50 *** Kartor XML
51 : <map>
52 : <row>
53 : <square type="stone"/>
54 : <square type="road">
55 : <item type="health"/>
56 : </square>
57 : </row>
58 : </map>
60 *** Collision detection
61 Varje Unit kollar om den intersectar med någon annan Unit innan
62 den rör sig. Om den gör det så minskar den flytten tills den
63 hittar en flytt som inte intersectar med någon Unit.
65 *** Flytt av Unit
66 1) Unit leter upp rutan den befinner sig i: Frågar map (JComponent
67 getComponentAt(Point?))
68 2) Fråga ruta om aktuell speedFactor, för att modifiera sin
69 hastighet. 1 är standard, 1 * UnitSpeed.
70 3) Unit meddelar sin ruta att den befinner sig där, Obervable
71 ruta. Rutan meddelar Tower, Tower sparar Unit i kö. Se [[** Logik]].
72 4) Unit har en tidsenhet som intervall på hur ofta den får göra
73 förflyttningar, detta representerar hastighet. Unit tidstämplas
74 vid varje flytt med aktuell tid i millisekunder. Vid nästa flytt
75 kollar den så att satt tidsintervall har förflutit.
76 5) Enumeration håller koll på riktning.
77 6) Se [[*Collision%20detection][*Collision detection]]
79 - Vi använder XMLSchema.
81 *** TODO Till nästa gång
82 **** TODO Ta reda på hur vi svänger i kurvor.
83 **** TODO Metoderna intersects och contains.
84 **** TODO Easter eggs?
86 ** Andra
87 CLOCK: [2008-12-11 Thu 16:07]
88 *** Path <|- Turnpath
89 Hela Canvas har en mouseListener som lyssnar på musklick, dessa
90 koordinater kollas mot matris för spelplanen och objekt som finns
91 där returneras, Object instanceof Turnpath ger ändring i sväng.
92 *** Flyweight pattern för rutor?
93 *** En matris för spelplanen
94 Spelplanen vet koordinater för varje ruta, Units kan fråga
95 spelplanen efter ruta för aktuell koordinat!
97 *** DoubleBuffering
98 Skapa en instans av bakgrundsbild att rita hämtas till en instans
99 av BufferedImage för att rita upp gubbar på för varje
100 uppritning. Clear Canvas, rita upp BufferedImage och vipps så är
101 där DoubleBuffering.
103 *** Animationtråd
104 Tården kan se ut så här:
105 : while(running) {
106 : for (Unit unit : units) {
107 : unit.update();
108 : }
109 : for (Unit unit : units) {
110 : unit.paint(Graphics g);
111 : }
112 : }
113 *** Gränssnitt
114 Tänk på att knappar kan vara bilder.
115 *** Ett Game
116 - Nytt game startas, spelare finns redan.
117 - Karta skapas
118 - Pengar ges
119 - Poäng är noll
120 - Torn placeras
121 - Game on!
123 *** Levels.xml
124 - Levevels.xml Innerhåller information om hur banan ska byggas
125 upp.
126 - LevelStyle.xml innerhåller information om vilka bilder som hör
127 ihop med vilka ban-element.
128 - UnitStyles.xml innehåller information om vilka bilder som hör
129 ihop med vilka Units.
131 * Om spelet
132 Ett Tower Defence-spel är ett spel i vilket användarens uppgift är att
133 skydda sig mot fiender genom att sätta upp torn. Dessa torn ska sedan
134 skjuta ner fienden innan de når ett givet mål, och tornen måste
135 således placeras ut strategiskt.
137 För att göra spelet intressantare brukar det krävas att en viss mängd
138 fienden tar sig i mål för att man ska förlora, och det kan finnas
139 flera sorters fiender och torn (flygande och markgående fienden etc.).
141 * Spelets regler
142 - Att släppa ut trupper ska kosta valuta (nedan kallat kredit), och
143 spelaren får ett antal krediter tilldelade varje bana. När dessa
144 är slut kan inga trupper köpas, och spelaren förlorar om de
145 trupper på banan inte tar sig i mål och ger upphov till vinst.
146 - Vinst är när ett visst antal "målkrediter" tjänats. Detta brukar
147 bara vara ett antal truppmedlemmar, men kan mycket väl viktas med
148 deras hälsa när de kommer in i mål.
149 - Krediter tjänas på något sätt under banans gång, förslagsvis en
150 viss krediter/sekund för varje truppmedlem, samt en viss mängd
151 krediter vid målgång.
152 - Fienden behöver inte vara smarta. Det räcker med att de väljer en
153 varelse inom räckhåll och skjuter på den.
154 - Fienden får ha endast laser (ljusstråle som träffar direkt så ni
155 slipper beräkna en projektils bana).
156 - Utplacering av tornen som skjuter på trupperna behöver endast
157 placeras ut slumpmässigt i tillåtna zoner.
159 * Laborationen
160 Laborationen ska lösas i grupper om 2 (två) personer. Det ses från vår
161 sida som en näst intill omöjlig uppgift att göra laborationen enskilt
162 under kursens gång, därför finns det inga undantag. Parindelningen är
163 upp till er att fixa, men alla grupper ska anmäla sig på denna
164 sida. Vet ni inte om någon att jobba med så skriv in er i en ny grupp
165 , eller om det redan finns en grupp med bara en person så skriv in er
166 i den och kontakta så snart som möjligt personen som redan stod där om
167 att du vill jobba med honnom/henne.
169 Målet med spelet är att skapa en bas för utbyggnad av
170 funktionaliteten. Därför är det väldigt viktigt att ni lägger stor
171 möda på spelets interna struktur för att få en lättnavigerad kodbas
172 med logisk uppbyggnad. Dokumentationen är väldigt viktig den med,
173 vilket innebär att samtliga klasser, samtliga metoder samt
174 medlemsvariabler ska kommenteras med utförliga
175 JavaDoc-kommentarer. JavaDoc är dock inte den enda typen av grundlig
176 dokumentation som krävs, se nedan. Syfte
178 * Syftet med laborationen är att få pröva på och använda:
179 - Trådar
180 - XML / DTD / XMLSchema
181 - GUI (Swing)
182 - Grafik
183 - Öva färdigheten i rapportskrivning med en specifik målgrupp
184 - Följa en given kodkonvention
186 * Er uppgift
187 Er uppgift är inte att implementera ett Tower Defence-spel, utan ett
188 Anti-Tower Defence-spel. Ni ska alltså låta användaren skicka ut
189 fienden som sedan datorn ska skjuta ner. Ett exempel på ett sådant
190 spel är: [[http://www.sugar-free-games.com/playgame.php%3Fgame%3D1127][Anti-TD]] på Sugar Free Games.
191 ** Kravlista
192 För att göra spelet mer intressant ut laborationssynpunkt finns det
193 en del krav på er lösning:
195 *** I alla nivåer gäller:
196 **** TODO Implementera spelet AntiTD i Java
197 **** TODO Följa SUN:s kodkonvention: http://java.sun.com/docs/codeconv/index.html
198 **** TODO Följa god OO- och MDI-stil.
199 **** TODO Källkoden skall ligga i katalogen
200 : ~/edu/apjava/lab4/src/
201 **** TODO En komplierad version i katalogen
202 : ~/edu/apjava/lab4/bin/
203 **** TODO Rapporten skall ligga i katalogen
204 : ~/edu/apjava/lab4/report/
205 **** TODO JavaDoc-sidorna skall ligga i katalogen
206 : ~/edu/apjava/lab4/doc/
208 *** TODO Nivå 1 (grundnivå)
209 **** TODO Klassen "AntiTD"
210 Startar ett Anti Tower Defence-spel utan att ta emot några argument från användaren.
211 **** TODO Trådar
212 Spelet ska använda sig av flera trådar för att låta flera delar jobba parallellt.
213 **** TODO Uppdateringsintervall
214 Spelets uppdateringsintervall skall vara tidsberoende och inte
215 beroende av datorns hastighet.
216 **** TODO Banor
217 Det ska finnas minst en bana längs vilken man kan skicka ut
218 trupper.
219 **** TODO Vinst/Förlust
220 Vid "vinst" eller "förlust" så ska användaren presenteras med
221 valet om att spela igen eller avsluta spelet. Medans detta val
222 pågår så ska inte användaren kunna göra nåt annat, men objekt på
223 spelplanen ska fortsätta röra sig.
224 **** TODO GUI:t skall använda sig av Swing-biblioteket.
225 **** TODO Rendering
226 All rendering skall ske dubbelbuffrat för att undvika flimmer.
227 **** TODO Det ska finnas minst två huvudmenyer:
228 - En meny med valen:
229 + New Game/Restart
230 + Om inget spel har startats så heter menypunkten tex. "New
231 Game" och vid klick så startar den ett nytt spel. Om spelet
232 redan är igång så ska menypunkten heta tex. "Restart" och
233 spelet börjar om från början.
234 + Pause/Resume
235 + Menypunkten kan tex. heta "Pause" om spelet är igång och
236 när man klickar på menypunkten så ska alla trupper och torn
237 stanna och inga knappar ska gå att klicka på. Om spelet är
238 i "Pause"-läge så ska menypunkten byta namn till
239 tex. "Resume" och vid klick så ska spelet återupptas där
240 det sist var, dvs. fordonen skall fortsätta röra på sig
241 samt att användaren kan skicka ut fler trupper.
242 + Mute
243 + Sluta spela upp ljud. Då den här menyn väljs ska
244 menyalternativet bytas till "Unmute" och vice versa.
245 + Quit
246 + Avsluta spelet.
247 - Den andra menyn ska innehålla:
248 + About: Berättar i en dialogruta vem som gjort spelet och när.
249 + Help: Berättar i en dialogruta hur man spelar.
250 **** TODO Zoner i banor
251 Varje bana skall innehålla zoner där datorn kan placera ut torn,
252 vägar längs vilka trupper kan röra sig.
253 **** TODO Grupptyper
254 Minst två typer av trupper ska implementeras med olika förmågor
255 (klarar olika antal träffar, kostar olika mycket, har olika
256 hastighet, etc.).
258 *** TODO Nivå 2 (multipla banor/XML)
259 **** TODO Flera banor
260 Spelet ska klara av flera banor. Banorna ska se olika ut,
261 exempelvis hur trupperna kan röra sig.
262 **** TODO Spara banor i fil levels.xml
263 Flera banor skall lagras i en fil som heter
264 "levels.xml". XML-formatet skall följa en DTD som ni själva
265 specificerar. XML-filen skall valideras mot den DTD (eller XML
266 Schema) ni skriver.
267 **** TODO Banzoner
268 Varje bana skall innehålla zoner där datorn kan placera ut torn,
269 vägar längs vilka trupper kan röra sig, samt regler för banan,
270 exempelvis hur många trupper som måste komma igenom för att
271 användaren ska vinna. Allt detta ska stå i XML-filen under varje
272 bana.
273 **** TODO Vinst/förlust
274 När användaren "vinner" en bana så skall spelet fråga användaren
275 om den vill spela samma bana en gång till eller fortsätta till
276 nästa bana.
277 **** TODO Restart level
278 Den första menyn ska byggas ut med alternativet "restart level".
279 **** TODO Flera vägsträckor per bana
280 Det ska finnas (möjlighet till, samt exempel på) flera möjliga
281 vägsträckor per bana för trupperna.
282 **** TODO Spara resultat till Highscoreservice
283 Alla resultat ska sparas med hjälp av det ni gjorde i
284 lab 3. Highscores ska kunna visas (baserat på tid, poäng, nivå,
285 etc.).
286 **** TODO Parameter som anger levels.xml vid start
287 Ges ett argument vid körning ska detta tolkas som ett filnamn och
288 läsas in istället för levels.xml och på så vis kan fler banor
289 göras och köras utan att modifiera i spelets katalog.
291 *** TODO Nivå 3 (triggers / jar)
292 **** TODO Triggers, vägpekare i vägskäl?
293 Banor ska kunna innehålla (och det ska finnas exempel på banor
294 som innehåller) "växlar" som gör att en väg kan mynna ut i en
295 T-korsning där spelaren klickar på ex. en knapp för att välja åt
296 vilket håll trupperna ska gå.
297 **** TODO Skapa ett interface som har en metod "landOn".
298 **** TODO Banklasser implements landOn
299 De olika områdena på en bana skall finnas i egna klasser. Varje
300 sådan klass kan implementera interfacet beskrivet ovan.
301 **** TODO Läsa in class-filer från XML?
302 Vid start av en ny bana så skall programmet läsa in de
303 class-filer som XML-filen har deklarerat som sina områden och när
304 truppmedlemmarna går på ett visst område så ska denna
305 områdesklass funktion "landOn" anropas och någonting skall hända,
306 förutsatt att den implementerat ovan nämnda interface.
307 **** TODO Områden, ex Teleporters
308 Ett speciellt område utöver de beskrivna hittills skall
309 finnas. Tex: Teleporters, när en truppmedlem går på en viss ruta
310 så flyttas den till en annan på vägen.
311 **** TODO Teleportertrupper
312 Teleportertrupper ska implementeras som kostar mer, men ska kunna
313 lägga ner teleporterplattor när användaren väljer, och på så vis
314 kommer trupperna att kunna slippa förflytta sig lika långt.
315 **** TODO Spelet sparas i AntiTD.jar
316 Spelet samt de filer som behövs för grundspelet skall finnas i en
317 JAR-fil som heter "AntiTD.jar". Spelet ska startas med kommandot:
318 java -jar AntiTD.jar
320 * Redovisning
321 Den här laborationen har inte bara ett fungerande system som mål, utan
322 den ska även vara en bas för vidareutveckling. Därför ska den visas
323 upp för en fiktiv kund som ska köpa spelet av er för en stor hög
324 pengar. Därför är det viktigt att ni gör bra ifrån er på både spelets
325 uppvisning, och dokumentationen som ska lämnas in.
327 ** Milestone DEADLINE: <2008-12-18 Thu 15:00>
328 Innan jul ska ni boka in er för ett tillfälle hos handledarna för
329 att redovisa projektets framskridande. Vid detta möte bör delar av
330 programmet vara implementerat och ni bör kunna redovisa en plan (i
331 form av följande dokument) för hur arbetet ska fortskrida fram till
332 de olika redovisningstillfällena. Ni kommer att kunna boka in er
333 för denna redovisning 18/12 mellan 15-17. Bokning av tid kommer att
334 kunna ske senast veckan innan (info om detta kommer via mail). Om
335 ni av någon anledning vet att ni ej kan delta vid detta tillfälle
336 så hör av er till handledarna i förväg så kan redovisningen
337 genomföras vid något tidigare tillfälle.
339 ** Uppvisning (promotion) DEADLINE: <2009-01-13 Tue>
340 Samtliga lösningar ska visas på gruppövningen den 13e
341 januari. Ungefär 10 minuter per grupp ges. Tar uppvisningen för
342 lång, eller för kort tid, minskar intresset från kunden. Hjälpmedel
343 ni har att tillgå är: OH-apparat, ... Mer info kommer senare.
345 ** Fysisk inlämning av dokumentation
346 Det som i normala fall brukar vara en rapport om själva utvecklandet
347 kommer på den här laborationen ha en annan uppgift.
349 Utöver dokumentationen av programmet så ska ni även lämna in en
350 detaljerad beskrivning av vem som gjort vad i projektet. Detta för att
351 individuell poängbedömning ska kunna göras (var nogrann med
352 denna). Denna del ska ges som en bilaga till rapporten. Till exempel
353 kan en uppdaterad version av dokumentet från milestone tillfället
354 ingpå. Observera att det inte räcker med en mening där ni säger att ni
355 båda varit inblandade i allt och gjort lika mkt (lite mer detaljnivå
356 krävs).
358 * Programdokumentation DEADLINE: <2009-01-13 Tue 15:15>
359 Dokumentation av arbetet ska vara inlämnad senast Tisdag 13/1-09
360 15:15 Den största vikten i rapporten ligger på hur systemet är
361 uppbyggt. Vilka delar ska modifieras för att olika effekter ska
362 uppnås. Här hör ett eller flera UML-diagram hemma,
363 algoritmbeskrivningar i grafisk form, etc.
365 Tänk på att den här delen ska fungera som referenslitteratur. Det
366 ska alltså inte vara uppsatser, utan listor, bilder, grafer,
367 tabeller, träd, etc. Små textstycken behövs med, men en
368 beskrivningar i uppsatsform är inget alternativ.
370 * Bedömning
371 Rapporten kommer betygsättas utifrån dels utseende (teckensnittsval,
372 marginalbredd, sidnumrering), innehåll (styckeuppdelning, förlopp, hur
373 lätt det är att slå upp saker i den), informationsförmedling (vad
374 berättas i rapporten), och slutligen kommer även stavfel,
375 särskrivningar, meningsbyggnadsfel och språkblandningar in i bilden.
377 JavaDoc-sidorna kommer gås igenom och deras innehåll kommer bedömas.
379 Javakoden kommer synas så den följer konventioner och "bra"
380 programmeringsstil. Ex. på mindre bra programmeringsstil är:
382 : if (a.getP() < 4)
383 : return false;
384 : else
385 : return true;
387 En helhetsbedömning av bl.a. ovanstående kommer poängsätta rapporten,
388 kodens dokumentation, redovisning och källkoden. Resultatet kommer
389 bli: Nivå Poäng 1 0 - 7 2 0 - 14 3 0 - 20
391 Dokumentationen kommer stå för runt 1/3 av den totala poängen, så glöm
392 inte att lägga ner tid på den.
394 OBS: Poängsättningen av labben kommer att ske på den först inlämnade
395 versionen. Fel som ger O på labben kommer givetvis att bidra till att
396 minska poängtalet rätt rejält.
398 * Ev otydligheter i specifikationen
399 Är något otydligt i specifikationen så är det upp till er att klargöra
400 vad som gäller. Redovisa även sådana klargörande i rapporten.