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