A követelmények leírása Júz Kéz az indián kincskereső barlangokban gyémántra vadászik. Ehhez korlátozott mennyiségű robbanószer és élet áll rendelkezésére. A játékos feladata az indián irányítása, és a gyémántok megszerzése. A játék világa kétdimenziós, az indián bármerre mozoghat és áshat, ahol föld, vagy már kiásott barlang található. Nem mehet keresztül a keményebb grániton, illetve a sziklákon. A különbség, hogy míg a gránit az egyszerű földet helyettesítheti bizonyos helyeken, a szikla egy különálló tárgy, amely eltolható, alsó alátámasztás hiányában lezuhan, oldalsó alátámasztás hiányában oldalra elgördül, hasonlóan a gyémánthoz. Ha Júz Kéz fejére szikla vagy gyémánt esik, meghal. Előfordulhat az is, hogy olyan helyzetbe kerül, ahonnan a játék nem folytatható, mert a szükséges gyémántokat és az indiánt elzárták egymástól a kövek, vagy a gránit. A barlangban élnek még különböző szörnyek is, ezeket meg lehet ölni, de nem kötelező, ha viszont elkapják az indiánt, meghal. A szörnyek nem képesek ásni. Megölhetők valaminek (gyémánt vagy szikla) ráejtésével, illetve robbantással. Négyféle szörny létezik. Az első ha van elég hely, adott időközönként szaporodik, de csak össze-vissza bolyong. A második üldözi a kincskeresőt, és ha szikla esik rá, gyémánttá alakul. Létezik még egy össze-vissza bolyongó, szikla ráejtés hatására gyémánttá alakuló lény, és egy kincskeresőt üldöző, de a sziklától egyszerűen meghaló lény is. A robbanószer egy gomb megnyomásával elhelyezhető, majd egy másik gombbal felrobbantható. Egyszerre több robbanószer is lehet letéve, ezek egyszerre fognak robbanni, így például nagy számú szörny csalható csapdába. A robbanás mindent elpusztít, ami a hatósugarán belül van. A robbanószernek nem kell alátámasztás, hogy a helyén maradjon. Ha sikerült megszerezni a szükséges gyémántokat, akkor a barlang kijárata kinyílik, ezen belépve lehet tovább haladni a következő pályára, ahol kezdetben robbanószer utánpótlást kaphatunk, az életek viszont nem pótlódnak.
Szótár • alátámasztás - Tárgyak gördülését, illetve zuhanását megakadályozó dolog, például szikla, föld vagy gránit. • ás - Az indián olyan mozgása, melynek során földet távolít el. (a helyén barlang lesz) • barlang - Üres terület, ahol minden szabadon mozoghat. • bejárat - Az a terület, ahol egy új pályán kezd az indián. • esik - Lásd zuhan. • élet - Számláló, ami ha eléri a nullát, a játéknak vége. Meghalás hatására csökken. • föld - Kiásható terület, csak a szörnyek mozgását akadályozza. Alátámasztást biztosít. • gördül - Oldalsó alátámasztás hiányában oldalirányba elmozdul. • gránit - Olyan terület, amely csak robbantással ásható ki. • gyémánt - Összegyűjtendő fényes tárgy. • indián - A szereplő, amit a játékos irányít. • Júz Kéz - Vagy a játék neve, vagy az indián. • lezuhan - Egy gyémánt vagy szikla, ha nincs alátámasztva, elindul lefelé, és amíg meg nem áll, megöli az útjába kerülő indiánt és szörnyeket. • lény - Ellenfelek, különböző képességekkel. • kijárat - Az a terület, ahol a pálya teljesítése után továbbmehetünk a következő szintre. • kincskereső - Lásd indián. • meghal - Ha egy lény hal meg, akkor egyszerűen eltűnik a pályáról, többé nem jelent
• • • • • •
veszélyt. Ha a kincskereső, akkor egyel csökken az életek száma, és ismét a bejárattól indul a játék. pálya - A játék egy szakasza. Egymást követik. Ha elfogytak, a játékos nyert. ráesik - Valamit zuhanás közben felülről eltalál. robbanás - A robbanószer körüli adott sugarú körben mindent elpusztító esemény. robbanószer - Robbantani lehet vele, de amíg csak el van helyezve, veszélytelen, minden áthaladhat rajta. Alátámasztást nem igényel és nem is biztosít. szikla - Olyan tárgy, amit tologatni lehet, de átmenni rajta nem. szörny - Lásd lény.
Követelmény definíció A program célja, alapvető feladata A program egy oldalnézetből megjelenített barlangban játszódó játék. A cél a megfelelő mennyiségű gyémánt megszerzése, és így a pályák teljesítése. Ezt különböző ellenfelek és lezuhanó sziklák nehezítik. Részletesebb leírás a játék ismertetésénél található. A fejlesztés célja egy olyan játékprogram előállítása, mely működőképes, élvezhetően játszható, és amely minden olyan gépen futtatható, melyen a megfelelő Java futtatókörnyezet található. A fejlesztés során különleges hangsúlyt kap az UML modellező rendszer minél tökéletesebb használata.
A fejlesztő környezet A forráskódot Subversion verziókezelőben fogjuk tárolni. Itt csak a .java forrásfile-ok lesznek, az IDE-k különböző projekt file-jai nem, ezért minden csapattag szabadon választhat. A dokumentációt egy, a wikipediához hasonló rendszerben szerkesztjük, majd minimális módosításokkal (tartalom, fedőlap hozzáadása) nyomtatjuk ki. A dokumentáció egyes részeit (mint az osztálydiagram, az egyes osztályok, metódusok és adattagok leírása) a kódból generáljuk a Doxygen és a Code2UML nevű programok segítségével. A további UML ábrákat Netbeans segítségével rajzoljuk meg. Ezekből sem kód nem generálható, sem kódból nem generálhatóak, így bármilyen más programmal is megtehetnénk.ű A használt rendszerek előnye, hogy utólag is látható, hogy ki mely részeken dolgozott, ami nagy segítség a napló elkészítésében.
A futtatáshoz szükséges környezet Java Runtime Environment, illetve az a számítógép, mely ezt futtatni képes. (A Sun ajánlásai PC-re: Pentium 166Mhz vagy gyorsabb processzor és 32Mb memória.) A játék használatához grafikus képernyő és egér szükséges. Magának a programnak nem lesz nagy memóriaigénye, de elképzelhető, hogy a grafikus részek miatt meghaladja az 1Mb-ot. (Ez csak becslés.)
A felhasználói felület A játékprogram végső változata grafikus felhasználói felülettel rendelkezik. A programot a felhasználó a billentyűzet segítségével vezérelheti.
Minőségi tényezők Teljesítmény: A cél az, hogy a játék élvezhetően játszható legyen a fentebb meghatározott minimális rendszeren. A grafikus felületnél törekedni fogunk a folyamatos animációk alkalmazására, és ügyelni fogunk a folyamatos játékmenet biztosítására. Újrafelhasználhatóság: A cél az, hogy a grafikus felhasználói felületet a program többi részétől teljesen különválasszuk, így lehetővé téve azt, hogy később a grafikus felület egyszerűen és gyorsan változtatható legyen. Rugalmasság: A rugalmasságot a fejlesztőkörnyezet biztosítja, a játéknak ugyanis minden olyan környezetben futtathatónak kell lennie, melyben létezik megfelelő Java futtatókörnyezet. Felhasználhatóság: A használat különösebb tanítást nem igényel, alapfokú számítástechnikai tudással akár a felhasználói kézikönyv elolvasása nélkül is könnyen játszható.
A software minősítése A kifejlesztett software akkor megfelelő, ha minél pontosabban megegyezik a fentebb leírtakkal. Ezt ellenőrizni lehet a játék futtatásával és kipróbálásával, illetve a forráskód és a modell összevetésével.
A kibocsátás A program kibocsátása először a forráskóddal együtt a konzulens felé fog történni, valamint hozzáférhető lesz az Interneten is.
Project terv A fejlesztői csapat Csapattag neve Feladatköre Ferenczy Szabolcs
Grafikus részek kódja, tesztelés.
Stribik András
Kód és ami abból generálható (osztály diagram, osztály/metódus/adattag leírások), főként a nem grafikus részek.
Széll Tamás
Dokumentáció karbantartása, kódrészletek.
Életciklus modell A feladat először a program megtervezése, mely a dinamikus- és objektummodelleket foglalja magába. Ha ez készen van, elkezdhető a skeleton implementálása. Ez a lépés már teljesen meghatározott, nem merülhet fel semmilyen komplikáció, ha a modellek megfelelőek voltak. A következő feladat a prototípus elkészítése. A programnak ebben az állapotban könnyen tesztelhetőnek kell lennie, hogy a programozási és funkcionalitási logikai hibák könnyen felismerhetők legyenek. A könnyű tesztelhetőség azt jelenti, hogy a bemenetet és a kimenetet is lehet állományból illetve állományba generálni, hogy ennek kiértékelése is egyszerű legyen. Ha már a prototípus is megfelelő, akkor kezdődhet a grafikus felület megvalósítása. Itt is fontos a
tesztelés és a kiértékelés, mert a jó megjelenés sokat számít a játék élvezhetőségében. Ha ennek kifejlesztése is sikeres, készen van a program első teljes változata. A kötelező feladat csak eddig tart. Ezt a változatot kell leadni a dokumentációval és a forráskóddal együtt.
Szervezési struktúra A csapat három emberből áll. A feladat szempontjából a tudásunk nem azonos, mindenki más-más területet érez a magáénak, illetve a feladat eltérő részinek megoldásához van nagyobb kedvünk. Azt a felépítést választottuk, hogy mindenki az érdeklődésének és tudásának legmegfelelőbb részt kapja az egész feladatból. A feladatok szétosztását találkozókon beszéljük meg, ahol az egyéni kívánságok mellett ügyelünk arra, hogy minden feladat kiosztásra kerüljön, valamint a csapattagok az egész feladat megoldásából nagyjából egyenlő mértékben vegyék ki a részüket. A találkozók keretében, mivel a szétosztott feladatok nagy mértékben függnek egymástól, javaslatokat teszünk egymásnak a feladat megoldásának körülményeit és a határidőt illetően. Ezt követően egyikünk (beadásonként változhat, hogy melyikünk) három, közelítőleg egyenlő részre osztja az elvégzendő feladatokat, amelyből először a másik két csapattag választja ki a neki tetsző részt, majd a szétosztást végző tag megkapja a megmaradt részfeladatot. Végül a csapattagok elvégzik a rájuk kiosztott feladatot, ennek során természetesen segíthetnek egymásnak. Hogy a fejlesztés minél hatékonyabb és zökkenőmentesebb legyen, a következő korszerű eszközöket alkalmazzuk: • E-mail: Egyes fontos adatokat, dokumentumokat e-mailben küldhetünk el egymásnak. Főként akkor használjuk, ha nem elérhető a teljes csapat MSN-en. • MSN: Elsődlegesen az MSN protokollon keresztül tartjuk egymással a kapcsolatot, akár online meetingek is megvalósíthatók vele. • Google Code: A Google kiváló szolgáltatása biztosítja a dokumentáció elkészítéséhez a wikit, és a verziókezelő rendszert is. Így mindenki a legfrissebb változatokon dolgozhat.
Fejlesztési ütemterv A program fejlesztésének három fő lépcsőfoka van. Ezek a következők: Skeleton: A cél az, hogy mind a dinamikus, mind az objektum modell jól legyen kitalálva. Ha ezek elkészültek, akkor a fejlesztés szempontjából sikeresen leraktuk az alapokat. Prototípus: Ez már szinte a teljes változat, csak a grafikus felület elemei hiányoznak. Ez a változat tökéletesen megfelelő arra, hogy az objektumok, rutinok, függvények szemantikai helyességét vizsgáljuk. Grafikus változat: A program teljes változata. Tulajdonképpen a prototípus a grafikus felülettel kiegészítve, esetleg kismértékben továbbfejlesztve.
Határidők 1
február 13. csapatok regisztrációja
2
február 19. Követelmény, projekt, funkcionalitás - beadás
3
február 26. Analízis modell kidolgozása 1. - beadás
4
március 5.
Analízis modell kidolgozása 2. - beadás
5
március 12.
Szkeleton tervezése - beadás
6
március 19.
Szkeleton - beadás
7
március 26.
Prototípus koncepciója - beadás
8
április 2.
Részletes tervek - beadás
1 0
április 16.
Prototípus - beadás
1 1
április 23.
Grafikus felület specifikációja - beadás
1 3
május 7.
Grafikus változat - beadás
1 4
május 14.
Összefoglalás - beadás
Szükséges dokumentációk Az a dokumentáció, mely a fejlesztés során keletkezik, a program belső működési elvét jeleníti meg, egy esetleges továbbfejlesztésnél nagy előnyt jelent. Ezentúl a felhasználó számára is szükséges egy dokumentáció készítése, a játszhatóság és a könnyű használhatóság érdekében. (Telepítési útmutató, felhasználói leírás.) Ezek a további dokumentumok a fejlesztési dokumentációt ismerő szakembernek semmi újat nem mondanak, az átlagfelhasználótól azonban nem várhatjuk el, hogy kiigazodjon a Use Case-ek és a State Chart-ok között. A program a felhasználónak készül, így azt úgy kell közzétenni, ahogy a felhasználó elvárja, hogy a használata bosszúságok helyett minél több örömöt okozzon neki.
Essential use case-ek Diagramok
Use Case leírások Use Case
Új játék
Actor
Player
Leírás
Új játék kezdése az első pályától.
Use Case
Újrakezdés
Actor
Player
Leírás
Az életek számának szándékos csökkentése eggyel, és újrakezdés a bejáratól.
Use Case
Pálya léptetés
Actor
Player
Leírás
Az adott pálya kijáratára mozogva a következő pálya betöltését kezdeményezi.
Use Case
Mozgatás
Actor
Player
Leírás
A játékos mozgatja az indiánt, ide tartozik az ásás, a sziklák eltolása és a gyémánt összegyűjtése is, mert ugyanúgy csinálja.
Use Case
Robbanószer elhelyezése
Actor
Player
Leírás
Az indián jelenlegi helyén robbanószert tesz le.
Use Case
Robbantás
Actor
Player
Leírás
A lerakott robbanószerek felrobbantása.
Napló Dátum
Alany
Tárgy
2009-02-11 17:56 2009-02-15 23:33
Ferenczy Szabolcs, Stribik András, Széll Tamás
Szervezési struktúra, fejlesztő környezet, adminisztratív és technikai teendők megbeszélése e-mailben és MSN-en.
2009-02-15 22:28 2009-02-15 22:38
Stribik András
A mintapéldából átvehető részek "megírása".
2009-02-17 22:24 2009-02-17 22:54
Stribik András
Fejlesztőkörnyezetről szóló rész megírása.
2009-02-17 22:55 2009-02-17 22:59
Stribik András
A program célja, alapvető feladata rész megírása.
2009-02-17 22:56 2009-02-17 23:01
Stribik András
Fejlesztőkörnyezetes rész kisebb javítása.
2009-02-17 23:00 2009-02-17 23:01
Stribik András
Határidők rész megírása.
2009-02-17 23:12 2009-02-17 23:52
Stribik András
Követelmények leírása és szótár elkészítése.
2009-02-18 18:37 2009-02-18 19:07
Stribik András
Use case leírások elkészítése.
2009-02-18 23:48 2009-02-19 00:18
Széll Tamás
Use case diagram elkészítése.
2009-02-19 00:44 2009-02-19 01:14
Stribik András
Napló elkészítése.
