Csoport neve: Nil

Feladat sorszáma: 6

Feladat címe: Stratégiai játék

Analízis modell

Gyakorlatvezető::

Répási Tibor

Csoport tagok:

2006.04.21.

Történet

Tartalomjegyzék

1. Bevezetés

2. Kezdeti osztálydiagram

2.1 Osztálydiagram

2.2 Osztályok felsorolása

2.3. Alrendszerek

2.3.1. Multimédia alrendszer

2.3.2. Grafika alrendszer

2.3.3. Hang alrendszer

2.3.4. Kezelőfelület alrendszer

2.3.5. Játékmotor alrendszer

2.3.6. Hálózatkezelés alrendszer

2.3.7. Beállítások alrendszer

2.3.8. Naplózás alrendszer

3. Beállítások alrendszer modellje

3.1. Statikus modell

3.1.1. Kapcsolatok pontosítása

3.1.2. Attribútumok azonosítása

3.1.3. Bázisosztályok keresése

3.2. Dinamikus modell

3.3. Funkcionális modell

3.4. Operációk azonosítása

3.5. Az analízis modell osztálydiagramja.

3.6. Az analízis modell osztályainak listája

4. Grafikai alrendszer modellje

4.1. Statikus modell

4.1.1. Kapcsolatok pontosítása

4.1.2. Attribútumok azonosítása

4.1.3. Bázisosztályok keresése

4.2. Dinamikus modell

4.3. Funkcionális modell

4.4. Operációk azonosítása

4.5. Az analízis modell osztálydiagramja.

4.6. Az analízis modell osztályainak listája

5. Hang alrendszer modellje

5.1. Statikus modell

5.1.1. Kapcsolatok pontosítása

5.1.2. Attribútumok azonosítása

5.1.3. Bázisosztályok keresése

5.2. Dinamikus modell

5.3. Funkcionális modell

5.4. Operációk azonosítása

5.5. Az analízis modell osztálydiagramja.

5.6. Az analízis modell osztályainak listája

6. A kezelőfelület alrendszer modellje

6.1. Statikus modell

6.1.1. Kapcsolatok pontosítása

6.1.2. Attribútumok azonosítása

6.1.3. Bázisosztályok keresése

6.2. Dinamikus modell

6.3. Funkcionális modell

6.4. Operációk azonosítása

6.5. Az analízis modell osztálydiagramja.

6.6. Az analízis modell osztályainak listája

7. Játékmotor alrendszer modellje

7.1. Statikus modell

7.1.1. Kapcsolatok pontosítása

7.1.2. Attribútumok azonosítása

7.1.3. Bázisosztályok keresése

7.2. Dinamikus modell

7.3. Funkcionális modell

7.4. Operációk azonosítása

7.5. Az analízis modell osztálydiagramja.

7.6. Az analízis modell osztályainak listája

8. Hálózatkezelés alrendszer modellje

8.1. Statikus modell

8.1.1. Kapcsolatok pontosítása

8.1.2. Attribútumok azonosítása

8.1.3. Bázisosztályok keresése

8.2. Dinamikus modell

8.3. Funkcionális modell

8.4. Operációk azonosítása

8.5. Az analízis modell osztálydiagramja

8.6. Az analízis modell osztályainak listája

9. Naplózás alrendszer modellje

9.1. Statikus modell

9.1.1. Kapcsolatok pontosítása

9.1.2. Attribútumok azonosítása

9.1.3. Bázisosztályok keresése

9.2. Dinamikus modell

9.3. Funkcionális modell

9.4. Operációk azonosítása

9.5. Az analízis modell osztálydiagramja

9.6. Az analízis modell osztályainak listája

10. Mellékletek

1. Bevezetés

Az alábbi dokumentum a "Children of the Wüstenplanet" projekt analízis modelljét tartalmazza. A projekt célja egy valósidejű stratégiai játék létrehozása, amely Frank Herbert: Dune regényére épül. A stratégiai játékoktól elvárható funkciók mellett számos újítást kívánunk bevezetni, kiküszöbölve az eddigi programok esetleges hiányossságait.

A dokumentum ismerteti az elsődleges elképzelések alapján elkészített osztálytervet és az egyes osztályok általános szerepét. A következő részben a kezdeti osztályterv alapján kialakított alrendszerek vázlatos leírása található, majd a dokumentum hátralévő része ezeket az alrendszereket elemzi részletesen.

2. Kezdeti osztálydiagram

2.1. Osztálydiagram

1. ábra. Kezdeti osztálydiagram

2.2. Osztályok felsorolása

Game

A program fő osztálya. Összekapcsolja, vezérli a többi osztályt, melyek rajta keresztül kommunikálhatnak egymással.

GameObject

Belőle származik le a játék összes objektuma, belértve az egységeket és az épületeket, mindegyikhez ennek egy példánya tartozik. Azokat a tulajdonságokat tartalmazza amellyel a játék összes objektuma rendelkezik. Pl: helyét a térképen, életerejét stb.

Map

A játéktér adatait hordozza, úgymint a terep felépítése (hol, milyen típusú talaj található, stb.). A grafikai megjelenítés a MapSprite osztály segítéségével történik.

Sprite

A játék grafikai elemeinek megjelenítéséért felelős, tartalmazza azok vizuális adatait és a kirajzolást is ez végzi.

ObjectSprite

A Sprite leszármazottja az objektumok megjelenítésére. A kirajzolást a GameObject adatai alapján csinálja.

MapSprite

A Sprite leszármazottja, a térkép „építőköveinek” adatait hordozza, amelyek összességéből a pálya felépül.

Building

A GameObjectleszármazottja, az épületek és egyéb álló játékbeli objektumok speciális adatainak tárolására.

Unit

A GameObject leszármazottja, a harci, építő és egyéb mozgó egységek speciális adatainak tárolására.

Listener

A felhasználói utasításokat „figyeli” amelyek alapján a GameObject adattagjai megváltozhatnak. (Például új úticélt kap, megtámad valakit, egységet legyárt, …)

Log

A program futása során keletkező adatokat, naplózza, melyek segítségével könnyebbé válik az esetleges hibák megtalálása és javítása.

Menu

A szoftver által végezhető műveleteket tárolja el fastruktúrában, meghívja a kért műveletekhez tartozó rutinokat.

Options

A felhasználó által beállított játékparamétereket tartalmazza.

Player

A játékot irányító szubjektum (felhasználó vagy mesterséges intelligencia) ezen osztály segítségével kapcsolódik.

AIPlayer

A számítógépi ellenfél (mesterséges intelligencia) ezen keresztül valósul meg és cselekszik.

HumanPlayer

A felhasználó(k) ezen keresztül vesznek részt a játékban.

GameServer

Alapvető feladata a bejelentkezett kliensek közötti játék automatikus lebonyolítása, vagyis a mérkőző játékosok összekapcsolása, a felek közötti kommunikáció megszervezése, a mérkőzés végének automatikus detektálása, és a győztes kijelölése.

GameClient

Hálózati játék esetében az egyes felhasználók ezen keresztül kommunikálnak a játékszerverrel. (A játékos műveleteit továbbítja a játékszerverhez)

2.3. Alrendszerek

2. ábra. Alrendszerek

2.3.1. Multimédia alrendszer

A részegység feladata összefogni a képi megjelenítést és a hanghatások megszólaltatását. Ennek elemei a grafikai alrendszer és a hang alrendszer.

2.3.2. Grafika alrendszer

Feladata a képelemek kirajzolása. A játék felületének, pályájának, egységeinek kirajzolása, megjelenítése tartozik hozzá.

Az alrendszerhez tartozó osztályok :

• Sprite
• MapSprite
• ObjectSprite

2.3.3. Hang alrendszer

A játék részét képező hangeffektek, hanghatások, háttérzene, fegyverropogás, lövegtornyok tüzelése, bombák robbanásának megszólaltatása.

Az alrendszerhez tartozó osztályok :

• Sound

2.3.4. Kezelőfelület alrendszer

Ehhez az alrendszerher tartozik minden olyan elem, amin keresztül a felhasználó eléri az egyes funkciókat, beavatkozik a játékba, irányítja azt. Magában foglalja mind a játékon belüli irányítás, mind pedig a játék indításához, kezeléséhez szükséges entitások összességét. Kiválasztható elemeket és a beavatkozó szerveket (Human Interface Devices (HID) ) lekezelését is megvalósítja.

Az alrendszerhez tartozó osztályok :

• Menu
• Listener

2.3.5. Játékmotor alrendszer

Ez az alrendszer a szoftver legfontosabb része. Kapcsolatban áll a többi komponenssel, nyílvántartja a játékon belüli objektumokat, a játékosokat, vezérli azokat. A játékmotor műveleteinek eredményét használja fel a többi komponens.

Az alrendszerhez tartozó osztályok :

• Game
• Player
• AIPlayer
• HumanPlayer
• GameObject
• Building
• Unit
• Map

2.3.6. Hálózatkezelés alrendszer

A hálózatkezelési alrendszer felelelős a hálózaton keresztüli játék biztosításáért. Az alkamazás egy futó példánya működhet szerverként, illetve kliensként is. Szoros együttműködésben áll a Game osztállyal, amely a hálózaton elküldendő adatokat szolgáltatja.

Az alrendszerhez tartozó osztályok :

• GameServer
• GameClient

2.3.7. Beállítások alrendszer

A játék helyes működéséhez szükséges beállításokat kezelő komponens. Lehetőséget biztosít konfigurációs fájlok beolvasására, valamint képes elvégezni a megfelelő beállítások automatikus detektálását is. Szoros együttműködésben áll a Game osztállyal.

Az alrendszerhez tartozó osztályok :

• Options

2.3.8. Naplózás alrendszer

Az alkalmazás készítésénél fontos szempont, hogy az esetleges hibákról és egyéb eseményekről a fejlesztők megfelelő formában értesüljenek. Ezt a feladatot látja el a naplózás alrendszer. Megfelelő formátumban rögzíti a hibákat és azok körülményeit, amelyet később el lehet küldeni a fejlesztőknek.

Az alrendszerhez tartozó osztályok :

• Log

3. Beállítások alrendszer modellje

3.1. Statikus modell

3.1.1. Kapcsolatok pontosítása

Az Options osztály, melynek feladata tárolni a játék felhasználó által beállított paramétereit a Game osztállyal áll kapcsolatban. Mivel Options osztálynak csak egy példánya lehet jelen, ezért 1-1 kapcsolat van közöttük.

3.1.2. Attribútumok azonosítása

A beállítások alrendszer minden osztályának a specifikációjától függően tartalmaznia kell a szükséges paramétereket leíró attribútumokat. Ide tartoznak az audió beállításokat leíró hangerősség attribútumok, a videóbeállításokat leíró  felbontás, színmélység és kidolgozottsági szint attribútumok, a hálózatot és játékhasználatot leíró paraméterek is ide kerülnek.

3.1.3. Bázisosztályok keresése

A menürendszerhez való igazodás érdekében célszerű a beállítások specifikus alosztályokra leképezni (pl. AudioOptions, VideOptions ). Ezek azonban hasonló struktúrájuak, és közös tulajdonsággal is rendelkeznek (utolsó módosítás dátuma), így kézenfekvő közös bázis osztályból származtatni ezeket. Ez a bázis osztály az Options osztály.
 

3.2. Dinamikus modell

3.3. Funkcionális modell

Az alrendszer által tárolt paraméterekből építkezik a játék és általa biztosítható a felhasználó szabadsága, ezért fontos szerepet tölt be a játék struktúrájában. Két oldalról is övezi a játék: a játékmotor ( Game, GameObject ) osztályai innen veszik az alapvető audiovizuális, és játékelemi tulajdonságokat, ezeknek megadását pedig a Kezelőfelület alrenszer végzi.

3.4. Operációk azonosítása

Mivel az eltárolt paraméterek döntő többsége nem vehet fel akármilyen értéket, módosításuk csakis metódusokon keresztül valósulhat meg. Ezek a set szóval kezdődő metódusok. Ezek ellenőrzik az érték helyességét. Az adatelrejtés elve miatt ezeket a paramétereket privát adattagokban tároljuk el, így közvetlen módon más osztályból nem elérhetőek. A hozzáférés get szóval kezdődő metódusokan keresztül valósul meg.

3.5. Az analízis modell osztálydiagramja

3. ábra. Beállítások alrendszer osztálydiagramja

3.6. Az analízis modell osztályainak listája

3.6.1. Options

• felelőssége, feladata: tárolja a felhasználó által beállított játékparamétereket.

• együttműködők: Game

• attribútumok

• operációk

3.6.2. AudioOptions

• felelőssége, feladata: Az Options leszármazottja. Hangerő beállításokat tárolja.

• együttműködők: Options

• attribútumok

• operációk

3.6.3. VideoOptions

• felelőssége, feladata: Az Options leszármazottja. A megjelenítéssel kapcsolatos beállításokat tárolja el.

• együttműködők: Options

• attribútumok

• operációk

3.6.4. NetworkOptions

• felelőssége, feladata: Az Options leszármazottja. Hálózati beállításokat tárolja.

• együttműködők: Options

• attribútumok

• operációk

3.6.5. GameOptions

• felelőssége, feladata: Az Options leszármazottja. A játék közbeni beállításokat tárolja el.

• együttműködők: Options

• attribútumok

• operációk

3.6.6. NetworkOptions

• felelőssége, feladata: Az Options leszármazottja. Hálózati beállításokat tárolja.

• együttműködők: Options

• attribútumok

• operációk

3.6.7. LanguageOptions

• felelőssége, feladata: A játék nyelvi beállítása.

• együttműködők: Options

• attribútumok

• operációk

4. Grafikai alrendszer modellje

4.1. Statikus modell

4.1.1. Kapcsolatok pontosítása

A grafikai alrendszer a pálya és az objektumok megjelenítéséért felelős. Közvetlenül a Map és a GameObject osztályokkal áll kapcsolatban. A játéktér elemi mezőkre van osztva, a MapSprite ezeket a mezőket rajzolja ki a Map kérésére a tárolt pályainformációk alapján. A játék minden egyes mezőjéhez tartozik egy MapSprite. A játékban szereplő egységek animált kirajzolásáért az ObjectSprite felel. Minden GameObject-hez tartozik egy ObjectSprite, egy ObjectSprite több GameObjecthez is tartozhat. A megjeleníteni kívánt GameObject meghívja a hozzá tartozó ObjectSprite draw() metódusát, ahol átadja neki a rajzoláshoz szükséges paramétereket (koordináták, elforgatás). Az animációs fázisok léptetésére is az ObjectSprite ad utasítást. (Azt mondja meg, hogy az animáció melyik képét kell kirajzolni.)

4.1.2. Attribútumok azonosítása

A grafikai osztályok kevés információt tárolnak, így kevés attribútummal rendelkeznek, amelyek közül a legfontosabb maga a tárolt kép. A célkoordináták és az elforgatás tárolására nincs szükség, mert azt mindig a megkapják a kirajzolást kérő féltől. A GameObject esetében a kirajzolandó animációs fázis számát kell tárolni. A MapObject szintén megkapja a célkoordinátákat (itt nincs elforgatás vagy animáció), ezenkívül minden kirajzolás előtt be kell állítani a mező azon tulajdonságait (pl. van-e rajta homokféreg, fűszer), amelyek befolyásolják a kirajzolást.

4.1.3. Bázisosztályok keresése

Az összes grafikai osztály jellemző tulajdonsága, hogy tárolják a képet és gondoskodnak ennek megjelenítéséről, ezenkívül léteznie kell a képek betöltését végző metódusnak is, ezért érdemes bevezetni a Sprite osztályt, aminek adott egy adattagja, ami egy képet tárol, és adott egy draw(x,y) nevű metódusa, amely (x,y) koordinátákba kirajzolja a képet. MapSprite esetében tiszta a helyzet, egy képet tárol, amit meg kell tudni jelenítenie, azonban ObjectSprite-nál más a helyzet: valahogy tárolnia kell egy objektum különböző nézeteit és animációs fázisait, ezért ObjectSprite nem leszármazottja a Sprite-nak, hanem Sprite objektumokat tárol.

Tehát SpriteObject , egy Sprite tömböt tárol, és amikor meghívják draw()-ját ő dönti el, hogy a tömb melyik Sprite-ját (midig csak egyet!) fogja kirajzoltatni. Lényeges, hogy ez a tulajdonos GameObject számára teljesen transzparens, ugyan úgy meghívhatja draw()-t és animate()-t, aminek hatására a várt funkciók hajtódnak végre. (Ez azért történik így, az objektum minden nézetéhez és a nézetek minden animációs fázisához külön kép, tehát külön Sprite tartozik.) A későbbiekben következő ábrából kiderül hogy GameObject SpriteLoop objektumokat tartalmaz, ezek a különböző nézeteket tartalmazzák. A SpriteLoop-ok a különböző nézetek animációs fázisait hordozzák.

4.2. Dinamikus modell

Az ObjectSprite-ok működését az alábbi példa szemlélteti. Itt ObjectSprite-nak csak két nézete van: SpriteLoop_A és SpriteLoop_B. Minden egyes nézethez két animációs fázis tartozik. (Így ObjectSprite összesen négy Sprite-ot tárol.)

4. ábra. ObjectSprite működése

Amikor GameObject meghívja az ObjectSprite animate() metódusát, az „továbbküldi” azt az összes tartalmazott SpriteLoop-nak. Amikor GameObject ki akarja rajzolni, a megfelelő paraméterekkel meghívja a draw()-t. Ezután ObjectSprite maga dönti el a paraméterek alapján, hogy melyik nézetet rajzoltassa ki (melyik SprteLoop-ot válassza). Meghívja SpriteLoop draw() metódusát, ami a korábban megkapott animate() paraméterei alapján kirajzoltatja a megfelelő Sprite-ot.

4.3. Funkcionális modell

 Egy képernyő (pálya és egységek) kirajzolásának menete a következő:

1. a Map egyenként meghívja a kirajzolni kívánt mezők draw() metódusát (pontosan közölve, hogy hova történjen a kirajzolás)

2. miután a pálya kirajzolódott, a Game üzenetet küld a látótérbe eső Objektumoknak, hogy rajzolják ki magukat

3. a Game gondoskodik az animációról is, ezért bizonyos időközönként üzenetet küld a GameObject-eknek, hogy frissítsék az animációs fázisukat (meghívják a GameObject-ük animate() metódusát

4. amikor a látótérbe eső egységek kirajzolására kerül a sor, a Game üzenetet küld a GameObject-eknek, hogy rajzolják ki magukat. Ekkor a GameObjectek meghívják a hozzájuk tartozó GameSprite draw() metódusát, átadva neki a szükséges paramétereket, úgymint koordináták és elforgatás.

4.4. Operációk azonosítása

Az összes grafikai osztály fontos része a draw(). Ez végzi (közvetve vagy közvetlenül) a megjelenítést. Szintén fontos egy load() metódus, ami betöti a háttértárolóról a képeket.

A MapSprite megjelenítést befolyásoló attribútumai beállítássához is szükség van néhány metódusra. Az ObjectSprite esetében pedig az aktuális animációs fázis beállítását kell megvalósítani.

4.5. Az analízis modell osztálydiagramja

5. ábra. Grafikai alrendszer osztálydiagramja

Sprite:

Az elemi állóképek tárolására.

SpriteLoop:

Sprite-ok tömbje, egy egység adott nézetéhez tartozó külöböző animációs fázisainak tárolására.

SpriteObject:

SpriteLoop-ok tömbje, amelynek elemei egy egység összes különböző nézete.

MapSprite:

Sprite leszármazottja a térkép grafikai elemeinek tárolására.

4.6. Az analízis modell osztályainak listája

4.6.1. Sprite

• felelőssége, feladata: különböző képek megjelenítéséért felelős

• attribútumok

• operációk

4.6.2. SpriteLoop

• felelőssége, feladata: Sprite-ok tömbje, egy egység adott nézetéhez tartozó külöböző animációs fázisainak tárolására.

• együttműködők: ObjectSprite

• attribútumok

• operációk

4.6.3. SpriteObject

• felelőssége, feladata: SpriteLoop-ok tömbje, amelynek elemei egy egység összes különböző nézete. A GameObject ténylegesen ennek a draw()-ját hívja meg, ezzel kommunikál.

• együttműködők: GameObject

• attribútumok

• operációk

4.6.4. MapSprite

• felelőssége, feladata: Sprite leszármazottja a térkép grafikai elemeinek tárolására.

• együttműködők: Map

• attribútumok (a Sprite attribútimain kívül)

• operációk

5. Hang alrendszer modellje

5.1. Statikus modell

5.1.1. Kapcsolatok pontosítása

A Hang alrendszer két jól elkülöníthető, logikailag mégis szorosan összetartozó tagból áll. Az első tag a SoundContinous osztály. Ennek egy példánya létezik a program futása során, ezen keresztül lehet a megszólaló zenéket vezérelni. A SoundEffect osztály pédányai a GameObject-hez tartoznak. Ez az egyes egységekhez/épületekhez tartozó hangeffekteket játssza le. Az osztályok nem közvetlenül játsszák le a hangokat, hanem objektummtömböket tárolnak, amik ténylegesen tárolják a zenéket/hangokat.

5.1.2. Attribútumok azonosítása

Az osztályoknak nem kell sok információt tárolni, csupán azt, hogy hány a tömbjük hány elemű. A SoundContinous még azt is tárolja, hogy a tömbjének hánydik eleme áll lejátszás alatt.

5.1.3. Bázisosztályok keresése

Mind a SoundContinous, mind a SoundEffect osztály nagyon hasonló egymáshoz, ezért érdemes lehetne közös őstől származtatni őket, azonban az eltérő felhasználási terület és a viszonylag kevés adattag- és metódusszám miatt nem éri meg.

5.2. Dinamikus modell

A SoundContonous a Game objektumtól kapott üzeneteket hajtja végre. Ez lehet:

• adott indexű elem lejátszása

• a listában soron következő elem lejátszása

• a lejátszás leállítása

Egy elem lejátszásának befejezésekor a SoundContinous ended() függvénnyel jelzi a befejezést.

6. ábra. SoundContinous működése

Minden GameObject-hez tartozhat egy vagy több SoundEffect objektum. Amikor a GameObject jónak találja (hangulatosabbá téve a játékot, pédául ágyúdörrenést szólaltat meg) meghívja a SoundEffect megfelelő indexű elemét. A SoundEffect tárolt hangjai lényegesen rövidebbek a SoundContinous-étól, ezért és felhasználásának más környezete miatt néhány dologban különbözik tőle:

• nincs playNext()

• a lejátszást nem lehet megszakítani

• egyszerre több hang is lejátszható különböző hangerősséggel

5.3. Funkcionális modell

A SoundContinous és SoundEffect osztályok play() (és hasonló) metódusainak meghívásakor az kiválasztja a tárolt hangok közül, hogy melyiket kell kiválasztani, majd meghívja annak lejátszásra szolgáló metódusát. A zene leállításakor ugyan ez a helyzet, az aktuálisan lejátszott elemnek meghívja a stop metódusát.

Kulcskérdés, hogy hogyan oldjuk meg a zenék lejátszását, azonban a fejlett programozási nyelvek erre beépített lehetőségeket nyújtanak.

5.4. Operációk azonosítása

Az osztályoknak rendelkezni kell a lejátszást elindító metódusokkal. Ekkor vagy paraméterként megadjuk a lejátszani kívánt elem sorszámát, vagy (SoundContinous esetében) csak annyit mondunk, hogy játssza le a következő elemet.

A másik fontos metódus a add(), amivel elemeket adhatunk a tárolókhoz. Ugyancsak fontos a load(), amivel betöltjük az elemeket.

5.5. Az analízis modell osztálydiagramja

7. ábra. Hang alrendszer osztálydiagramja

5.6. Az analízis modell osztályainak listája

5.6.1. Sound

• felelőssége, feladata: A GameObject-ekhez tartozó hangeffektek tárolására. Rövidségük miatt nincs szükség stop()-ra.s

• együttműködők: SoundEffect

• attribútumok

• operációk

5.6.2. Music

• felelőssége, feladata: Zene tárolására

• együttműködők: SoundContinous

• attribútumok

• operációk

5.6.3. SoundEffect

• felelőssége, feladata: Logikailag összetartozó hageffektek tömbje.

• együttműködők: GameObject

• attribútumok

• operációk

5.6.4. SoundContinous

• felelőssége, feladata: Music objektumokat foglalja egységbe, itt tároljuk a játék során megszólaló zenéket.

• együttműködők: Game

• attribútumok (a Sprite attribútimain kívül)

• operációk

6. A kezelőfelület alrendszer modellje

6.1. Statikus modell

6.1.1. Kapcsolatok pontosítása

Az alrendszer legfontosabb feladata a menü, és menüelemek lekezelése. A Menu osztály fogja össze a szerteágazó rendszert, ezért van kvázi csillagtopológia. Kapcsolata van a játék főmenüjével, és a játék közbeni elemekkel is.Az irányításért felelős osztályok attól függően vannak jelen, hogy éppen milyen GameObject van kijelölve, aktív állapotban. A MiniMap osztály a Game osztályhoz kapcsolódik, azon keresztül valósítja meg a navigálási funkciókat. A többrésztvevős játék nélkülözhetetlen kelléke, a ChatBox is a Game osztályon keresztül éri el a nekü szükséges hálózati funkciókat a beszélgetéshez.

A MainMenu-ből elérhető funkciókat hozzá kötődő további osztályok valósítják meg, ezek például a SubMenuNewgame és a SubMenuSetup. A főmenüből az új játék kiválasztásánál a SubMenuNewgame-en továbbhaladva tudjuk elérni a SubSinglegame egyjátékos és SubMultigame többjátékos menüpontokat.

A beállításokért felelős SubMenuSetup osztály beállítási lehetőségeket részben maga biztosítja részben pedig a szerteágazó audiovizuális entitások megválasztásáért felelős SubMenuVideo és SubMenuAudio osztályok. A megadott beállítások metódusokon keresztül az Options osztályban érhetők el.

6.1.2. Attribútumok azonosítása

A menük közötti navigáláshoz számon tartjuk a kiválasztott menüpontokat.A nem kifejezetten tradícionális menü osztály, a MiniMap tartalmaz koordináták tárolására szolgáló adattagokat, amivel teljes térkép egy pontját jelöli. A kis térképen a nagynak az a részlete fog megjelenni.Tartalmaz mellette scale tagot, amiben a nagyítás arányát tárolja.

A ChatBox szöveget tárol, ez lehet a játékos által bevitt szöveg is, de lehet a hálózaton keresztül érkezett is.Az időbeliségtől függ.

Mint beállítás tároló osztály szerepet kap az Options. A beállítások menüből a felhasználó megadott paramétereit erre képzi le.

6.1.3. Bázisosztályok keresése

Az Objcet osztályból származtathatók a közös tulajdonságok. Alapvetően mindegyik hasonlít egymásra.

6.2. Dinamikus modell

A felhasználó menübelépésének, majd kilépésének sematikus modelljét az alábbi szekvencia diagram mutatja be:

8. ábra. Felhasználó menübe lépése, kilépése

Az alábbi ábra szemlélteti a hangkártya kiválasztásának lépéseit:

9. ábra. Hangkártya kiválasztásának lépései

Szekvencia diagram a hangeffektek megválasztásának lépéseit mutatja be:

10. ábra. Hangeffektek megválasztásának a lépései

A felhasználó lépései a hengerő beállításához:

11. ábra. Felhasználó lépései a hangerő beállításához

Az automatikus beállítást kiválasztva a felhasználó hardware elemeihez igazítja a játék teljesítménybeli paramétereit. Ennek elérését jelöli a diagram:

12. ábra. Automatikus beállítás

Lehetőség van internetes frissítésre, azaz központi szerverünkön elérhető újabb verziókat egyszerűen elérhető, könnyen kezelhető lépéseken keresztül lehet elvégezni, a lezajló folyamatot jelöli a következő kép:

13. ábra. Internetes frissítés

Billentyűzet többféle kiosztása közül válogathat a felhasználó, ennek szemléltetése a következő:

14. ábra. Billentyűzet kiosztás választása

A nyelv beállításának folyamata:

15. ábra. A nyelv beállításának folyamata

Hálózati paraméterek megadásának lépése:

16. ábra. Hálózati paraméterek megadásának lépése

A megjelenítéshez szükséges videókártya kiválasztása érhető el az alábbi rajz szerint:

17. ábra. A megjelenítéshez szükséges videókártya kiválasztása

A teljesítmény szempontjából fontos tényező manuális megadása a grafikai minőségnek:

18. ábra. A teljesítmény szempontjából fontos tényező manuális megadása a grafikai minőségnek

A felhasználónak lehetősége nyílik egymás után több beállítás elvégzésére, anélkül hogy visszalépne a főmenübe:

19. ábra. Egymás után több beállítás elvégzése

6.3. Funkcionális modell

A játék irányításának, kezelésének feladatai két részre bonthatók: egyik része szükséges a játék vezérléséhez, figurák irányításához, másik részének feladatköre pedig ennek a környezetnek a felkonfigurálása, személyre - hardwarere szabása.

A kezelőfelület tulajdonképpen a játékmotor nyújtotta lehetőségek palettáját teszi a felhasználó elé, így szoros együttműködés szükséges a Game és a GameObject osztályokkal.

6.4. Operációk azonosítása

A főmenüt megvalósító MainMenu osztály tartalmaz a menü elemeinek elérését kiváltó operációkat. Az almenüpontokban elérhető funkciók szintén hasonló struktúrában épülnek fel. A beállítások műveletei értékeket változtatnak meg az Optionsban.

A MiniMap rendelkezik görgetés és közelítés-távolítás funkciókkal.

6.5. Az analízis modell osztálydiagramja

20. ábra. Kezelőfelület alrendszer osztálydiagramja

6.6. Az analízis modell osztályainak listája

6.6.1. SubMultigame

• felelőssége, feladata: a játék többjátékos módban indítása

• együttműködők: Game, SubMenuNewGame

• attribútumok: nincs

• operációk

6.6.2. SubSinglegame

• felelőssége, feladata: a játék egyjátékos módban indítása

• együttműködők: Game, SubMenuNewGame

• attribútumok : nincs

• operációk

6.6.3. SubMenuNewgame

• felelőssége, feladata: a új játék módjának kiválasztása

• együttműködők: MainMenu

• attribútumok : nincs

• operációk

6.6.4. SubMenuSetup

• felelőssége, feladata: a játék beállításainak beállítása

• együttműködők: MainMenu, SubMenuVideo, SubMenuAudio, Options

• attribútumok : nincs

• operációk

6.6.5. SubMenuVideo

• felelőssége, feladata: a játék grafikai paramétereinek beállítása

• együttműködők: SubMenuSetup, Options

• attribútumok : nincs

• operációk

6.6.6. SubMenuAudio

• felelőssége, feladata: a játék audio paramétereinek beállítása

• együttműködők: SubMenuSetup, Options

• attribútumok : nincs

• operációk

6.6.7. MainMenu

• felelőssége, feladata: a játék főmenüjének megvalósítása

• együttműködők: Game, SubMenuNewGame, SubMenuSetup, Menu

• attribútumok

• operációk

6.6.8. Menu

• felelőssége, feladata: a játék menürendszerének elérése

• együttműködők: Game, MainMenu, InGameMenu, GameObjectWorkerMenu, GameObjectBuildMenu, GameObjectUnitMenu

• attribútumok : nincs

• operációk

6.6.9. InGameMenu

• felelőssége, feladata: a játék közbeni menü

• együttműködők: Game, Menu

• attribútumok

• operációk

6.6.10. GameObjectWorkerMenu

• felelőssége, feladata: a kiválaszott munkás egység funkcióinak elérése

• együttműködők: Game, Menu, IGameMenu

• attribútumok : nincs

• operációk

6.6.11. GameObjectBuildMenu

• felelőssége, feladata: a épület kiválasztásakori menü

• együttműködők: Game, Menu, IGameMenu

• attribútumok

• operációk

6.6.12. GameObjectUnitMenu

• felelőssége, feladata: a katonák, egységek funkcióit teszi elérhetővé

• együttműködők: Game, Menu, IGameMenu

• attribútumok : nincs

• operációk

6.6.13. ChatBox

• felelőssége, feladata: a többjátékosmódban a játékosok kommunikációja

• együttműködők: Game

• attribútumok

• operációk

6.6.14. MiniMap

• felelőssége, feladata: a játék közbeni navigáció segítése, görgetés

• együttműködők: Game, Map

• attribútumok

• operációk

7. Játékmotor alrendszer modellje

7.1. Statikus modell

7.1.1. Kapcsolatok pontosítása

A játékmotor alrendszer Game osztálya az alkalmazás központi osztálya, így szinte az összes osztállyal valamilyen kapcsolatban áll. Tartozik hozzá legalább egy Player objektum, amely a játékosokat és a gépi ellenfeleket reprezentálja. A kapcsolatban a Player objektum a játékos, a Game objektum meg magának a játéknak a szerepét tölti be. Az összes játékbeli objektumot a GameObject osztály valósítja meg, a Game objektumhoz kapcsolódnak azok a GameObject példányok, amelyek az aktuális játékban szerepelnek, így egységesen lehet kezelni őket. A GameObject objektum a kapcsolatban a szereplő, tetszőleges számú részt vehet a kapcsolatban, míg a Game objektum a játék szerepét tölti be. Minden játékhoz tartozik egy térkép, amely az aktuális pályát reprezentálja, ezt valósítja meg a Map osztály a Game objektumhoz való kapcsolódása révén.

Egyéb alrendszerek osztályai is kapcsolódnak a központi Game objektumhoz, ezeknek a kapcsolatoknak a részletezése a megfelelő alrendszernél található. A Game osztály egyéb kapcsolatai: Menu, Options, Log, GameServer, GameClient.

A Player osztály, melyen keresztül a játékot irányító szubjektum bekapcsolódik a játékba, a Game osztállyal áll kapcsolatban. Mivel egy játékot legalább 2 felhasználó játszik, ezért a Player osztálynak legalább 2 példányának kell a játék fő osztályának objektumához kapcsolódni.

7.1.2. Attribútumok azonosítása

A Game osztály az alkalmazás központi osztálya, így számos attribútummal kell rendelkeznie. Mivel szinte az összes osztályhoz kapcsolódik, így ezeket a kapcsolatokat nyílván kell tartani attribútumokon keresztül. Szükséges lehet a játék kezdetét egy attribútumban tárolni, így biztosítva a lehetőséget az időlimites játékokra. Bizonyos játéktípusoknál egy adott pontszámot elérő játékos nyer, ezt a pontszámot tartjuk nyilván egy külön attribútumban. A játék végét jelzi majd a gameEnded logikai attribútum. Nyílván kell tartani, hogy összesen hány egység helyezkedik el a játéktéren, mivel maximális számuk limitálva van, erre szolgál a roomAvailable attribútum.

A GameObject osztály az összes játékbeli objektum őse, így a közös tulajdonságokat tartalmazza. Ezek a következők: életerő, támadóerő, páncélzat, pozíció, látótávolság, fejlettségi szint, képesség a támadásra. Egy logikai típusú attribútum fogja mutatni, hogy az objektumot a felhasználó kijelölte. Ezenkívül a kapcsolódó osztályokat is nyilván kell majd tartani. Ilyenek a Listener, Sound, ObjectSprite objektumpéldányok.

A Building osztály reprezentálja az épületeket a játékban, ezek speciális típusai a GameObject osztálynak. Jellemzőjük, hogy pozíciójukat nem tudják megváltoztatani, így a pozíció attribútum itt konstansként szerepel. Ezenkívül rendelkeznek még egy egész típusú attribútummal, amely az épületben tartózkodó egységek számát adja, illetve egy másik egész attribútum az éppen gyártott egységek számát tartalmazza. Vannak olyan épületek is a játékban, amelyeket nem lehet lerombolni, ennek a tulajdonságnak a rögzitésére egy logikai attribútumot alkalmazunk.

A Unit osztály reprezentálja az egységeket a játékban. További leszármazottai lehetnek, amelyek a speciális típusú egységeket valósítják meg, új attribútumokat bevezetve. Attribútumai: objektum állapotának nyilvántartására (támad, védekezik, őrjáratozik, mozog) egy, valamint az egység sebességét meghatározó attribútum.

A Map osztály a játékhoz tartozó aktuális pályát tartalmazza. A térképet négyzet alakú építőelemekből építjük fel, minden egyes elemet nyílván kell tartani a Map osztályon belül, ehhez egy kétdimenziós tömböt fogunk alkalmazni, amely az osztály attribútuma lesz. Lesznek pozíció attribútumok is, amelyek a pálya látható területét adják meg. Ezenkívül egy kétdimenziós tömb attribútum fogja tárolni, hogy az egyes térképpozíciókban milyen objektumok helyezkednek el.

A Player osztálynak kell tartalmazni minden olyan paramétert, amellyel egy játékban résztvevő szubjektum rendelkezhet. Ilyen lehet a játékos neve, hozzá tartozó pénzösszeg stb. Ezen kívül ennek az osztálynak a feladata tárolni a játékos szubjektum által kért műveletek listáját. Ezeket fogja továbbítani a Game osztálynak.

7.1.3. Bázisosztályok keresése

Több helyen is lehetőség van bázisosztályok létrehozására az alrendszeren belül. Tekintve az AIPlayer és a HumanPlayer objektumokat, felfedezhetőek közös vonások, amelyek általában jellemzőek egy játékosra, függetlenül attól, hogy az éppen gépi, vagy emberi játékos. Ilyenek például a hozzá tartozó egységek, a játékos neve, különböző erőforrások mennyisége stb. Ezek a közös jellemzők kiemelhetőek egy Player bázisosztályba.

A másik lehetőség a Building és a Unit osztályok esetében adódik. Az egyik az épületek, a másik az egységek reprezentálására szolgál. Mindkettő rendelkezik közös tulajdonságokkal, pl. életerő, páncélzat, támadóerő stb. Ezeket kiemelve egy közös bázisosztályba egy másik nagy előnyhöz is jutunk. GameObject ősosztály referenciákon keresztül eltudjuk majd érni az összes játékon belüli objektumot, amely megkönnyíti a kezelésüket.

A játékot ember és gép egyaránt játszhatja, ezért elkerülhetetlen különböző osztályba szeparálni őket. De mivel jópár ugyanolyan tulajdonsággal rendelkezik mindkettőjük (név,pénz) kézenfekvő ezeket egy egységes Player nevű bázisosztályból származtatni.

7.2. Dinamikus modell

7.2.1. Objektumok kezelése

Az alrendszer legfontosabb feladata a játékban szereplő objektumok kezelése, frissítése. Ezt a frissítést egy külön operáció fogja megvalósítani a Game osztályon belül, amelynek forgatókönyve, legfontosabb lépései a következők:

1. Játék paraméterek aktualizálása: megvizsgálja, hogy a játék paraméterein kell-e változtatni (pl. játék vége, új pálya stb.)
2. Felhasználói beavatkozás figyelése: amennyiben a felhasználó kiadott valamilyen utasítást, akkor erről a célobjektumot értesíteni kell (gombnyomás, egérkattintás stb.)
3. Mozgatás: minden egyes mozgatható objektumot a következő pozíciójába mozgatunk.
4. Objektumok frissítése: objektumok frissítése, hogy reagáljanak a környezetükre.
5. Takarítás: elpusztuló egységek eltűntetése, törlése, új objektumok kihelyezése, létrehozása.
6. Animáció: animáljuk az egyes objektumokat.
7. Kirajzoltatás: a változtatásoknak megfelelően kirajzoljuk az objektumokat.

Azért választottuk ezt a sorrendet, mert így a felhasználói inputok lekezélese mindig a feldolgozás elején történik, így a válaszidők megfelelőek lesznek.

A következő szekvencia diagram mutatja az objektum kezelési műveleteket egy adott példaobjektum esetén:

21. ábra. Objektumkezelés szekvencia diagramja

7.2.2. Objektum(ok) kijelölése

A játékos kijelölhet objektumokat a játéktéren, amely hatására az adott GameObject objektum kijelölést jelző attribútuma igaz értéket fog felvenni.

7.2.3. Objektum(ok) kijelölésének megszüntetése

A játékos megszüntetheti az objektum kijelölését, ilyen a megfelelő GameObject objektum kijelölést jelző attribútuma hamis értéket fog felvenni.

7.2.4. Katonai egységek kezelése

A katonai egységeket alapvetően négyféle műveletre lehet utasítani: támadás, védekezés, mozgás, őrjárat. A különböző műveleteket a felhasználó kattintással, illetve a megfelelő billentyűkombináció lenyomásával érheti el, ilyenkor a megfelelő Unit objektum állapotjelző attribútuma a megfelelő értéket veszi fel, és meghívódik a végrehajtó metódus.

7.2.5. Dolgozó egységek kezelése

Hasonlóan a katonai egységekhez meghívódik a megfelelő metódus, és az állapotjelző attribútum is felveszi az aktuális értékét.

7.2.6. Épületek kezelése

Az épületek több különböző funkcióval rendelkeznek, ezek a következők: új egység létrehozása, fejlesztés, kiürítés, támadás (opcionális). Új egység létrehozásánál a megfelelő nyersanyag mennyiség rendelkezésre állása esetén, valamint ha az adott játékos tud még új egységet létrehozni, akkor az adott épület a megfelelő metódus hívásával példányosít egy új Unit objektumot. A fejlesztés szintén erőforrás igényes művelet, és szintén egy metódushíváson keresztül valósul meg. Az épületben tartózkodó egységek rendelkeznek egy sorszámmal, ezen keresztül lehet őket kiküldeni az épületből a kiürítést végző metódus meghívásával.

Új egység létrehozásának szekvencia diagramja:

22. ábra. Új egység létrehozása

7.2.7. Objektumok speciális tevékenységének végrehajtása

Mivel minden egyes objektum típus a GameObject-ből származik, így az általános tulajdonságokon túl rendelkezhet speciális tulajdonságokkal, tevékenységekkel is. Ezeket a tevékenységeket a speciális osztályokban lehet definiálni.

7.2.8. Csapatkezelés

A csapatok kezelésénél három alapvető művelet van: összevonás, szétbontás, formáció. A kijelölt objektumcsoportot a játékos összevonhatja egy csapatba, ilyenkor az adott játékos csapattáblájába az adott sorszámú csapathoz bekerülnek az objektumok. Szétbontásnál törlődik a csapattábla bejegyzése. Formációba rendeződésnél az előre elkészített formációk egyikét veszik fel az egységek, aminek a hatására megváltoztatják a pozíciójukat, amennyiben ez lehetséges.

7.2.9. Objektumok tulajdonságainak megjelenítése

Az egyes objektumok tulajdonságait megjeleníti az alkalmazás az információs panelen, amikor az adott objektum aktív. Ezt egy külön metódus valósítja meg.

7.2.10. Térképkezelés

A térképkezelés alapvetően a Map objektum látható tartományának változtatásán alapul. Mind a három térképkezelési lehetőségnél (minimap, scrollozás, pozícionálás) a Map objektum látható tartományának a határát állítja a program a megfelelő operációkkal.

7.2.11. AIPlayer osztály működése

23. ábra. AIPlayer osztály működése

7.2.12. A HumanPlayer osztály működése

24. ábra. HumanPlayer osztály működése

7.2.13. Állapotdiagramok

25. ábra. Game osztály állapotdiagramja

26. ábra. GameObject osztály állapotdiagramja

7.3. Funkcionális modell

A játék alrendszer kezeli az összes játékban résztvevő objektumot, a térképet és a játékosokat. Legfontosabb feladata az objektumok ciklikus frissítése, amelynek feldolgozási lépéseit már ismertette a dokumentum az előző pontokban.

7.4. Operációk azonosítása

A központi Game osztály elsősorban a játék állapotára vonatkozó információkat tartalmaz, a többi funkciót a kapcsolódó egyéb osztályok biztosítják. Ennek megfelelően a Game osztály operációi is állapotok lekérdezésére, illetve azok beállításara szolgálnak. Biztosítani kell, hogy a játék végét jelző attribútum értékét le tudjuk kérdezni, illetve módosítani tudjuk, ugyanis ezek adják a vezérlés alapját. Tehát ezen funkcióknak külön operációk felelnek majd meg. A létrehozható objektumok számának kezeléséhez is szükségesek különböző beállító és lekérdező operációk. A Game osztály legfontosabb operációja a játék ciklus kezeléséért felelős, ami az egész alkalmazás mozgató rugója. Működésének lényege a 7.2.1. pontban található.

A GameObject osztály operációinak nagy része a tulajdonság értékek beállítására és lekérdezésére szolgál. Ezenkívül tartalmaz egy kirajzoló operációt, amely az objektum helyzetének megfelelően kirajzolja azt a képernyőre. Másik fontos operáció az objektum animálására szolgál. Meg kell tudni jeleníteni az objektumok tulajdonságait is, erre egy külön operáció fog szolgálni.

A Building osztály a GameObject operációin kívül rendelkezik új egységek gyártását végző, fejlesztő, valamint az épületben tartózkodó egységek kiküldésére szolgáló operációkkal.

A Unit osztály a GameObject operáción kívül rendelkezik az egység mozgatására szolgáló operációval, mivel ezek az objektum típusok mozogni is képesek. Ezenkívül szükséges a támadást, védekezést, őrjáratozást végrehajtó operációk is.

A Map objektumok inicializálása történhet fájlból, illetve generálható véletlen térkép is, ennek megfelelően ehhez a két funkcióhoz külön operációk szükségesek. Nyílván kell még tartani, hogy az egyes térkép pozíciókban milyen objektumok tartózkodnak, ehhez szintén külön operáció társul.

A Player osztály attól függetlenül, hogy játékos vagy mesterséges intelligencia irányítja azt, végtelen ciklusban vizsgálja, hogy érkezett-e végrehajtandó utasítás. Ha érkezett a processMessages metódussal adja azokat át a Game osztálynal végrehajtásra. (A checkForMessages metódus ellenőrzi, hogy van-e ilyen)  Ezeket az üzeneteket a játékos és a mesterséges intelligencia különböző módon állítja elő. Az utóbbiakat a makeStrategicDecision és makeAttackDecision metódusok meghívásával hajtja végre a mesterséges intelligencia. Ezeket a loopAI végtelen ciklus ismétli meg időről időre. A HumanPlayer osztály szintén végtelen ciklusban figyeli, a felhasználó utasításait.

7.5. Az analízis modell osztálydiagramja

27. ábra. Játékmotor alrendszer osztálydiagramja

7.6. Az analízis modell osztályainak listája

7.6.1. Game

• felelőssége, feladata: a játék központi osztálya, az egész alkalmazás vézérléséért felelős.

• együttműködők: GameServer, GameClient, Menu, Options, Log, Map, GameObject, Player

• attribútumok

• operációk

7.6.2. GameObject

• felelőssége, feladata: a játékban található objektumok kezelésére szolgál. A minden objektumra közösen jellemző attribútumokat és operációkat tartalmazza.

• együttműködők: Game, Listener, Sound, ObjectSprite

• attribútumok

• operációk

7.6.3. Building

• felelőssége, feladata: A játékon belüli épületeket reprezentáló osztály, a GameObject osztály leszármazottja, amelyet az épületekre jellemző speciális attribútumokkal és operációkkal egészit ki. Ebből származtathatóak le a speciális épület tipusok.

• együttműködők: GameObject

• attribútumok

• operációk

7.6.4. Unit

• felelőssége, feladata: A játékon belüli egységeket reprezentáló osztály, a GameObject osztály leszármazottja, amelyet az egységekre jellemző speciális attribútumokkal és operációkkal egészit ki. Ebből származtathatóak le a speciális egység tipusok.

• együttműködők: GameObject

• attribútumok

• operációk

7.6.5. Map

• felelőssége, feladata: A térkép reprezentálására szolgáló osztály.

• együttműködők: Game, MapSprite

• attribútumok

• operációk

7.6.6. Player

• felelőssége, feladata: A játékot irányító szubjektum, ezen osztályon keresztül kapcsolódik be a játékba.

• együttműködők: Game

• attribútumok

• operációk

7.6.7. HumanPlayer

• felelőssége, feladata: A Player leszármazottja, a felhasználók ezen keresztül vehetnek részt a játékban.

• együttműködők: Player

• operációk

7.6.8. AIPlayer

• felelőssége, feladata: A számítógépes ellenfél ezen keresztül valósul meg és cselekszik.

• együttműködők: Player

• attribútumok

• operációk

8. Hálózatkezelés alrendszer modellje

8.1. Statikus modell

8.1.1. Kapcsolatok pontosítása

A hálózatkezelő alrendszer minden osztálya a központi Game objektummal van kapcsolatban. A program egy futó példánya működhet szerverként, illetve kliensként is. Ez a szerver funkció csak és kizárólag helyi hálózaton keresztüli játékra érvényes, a dedikált szerverek összetettségük folytán külön szoftverként valósulnak meg. Szerverként való működéskor a GameServer osztály egy példánya kapcsolódik a központi Game objektumhoz a "hálózat kiszolgáló" kapcsolaton keresztül. Ilyenkor a futó alkalmazás egyben szerver és egyben kliens is. A kapcsolatban a GameServer osztály a hálózatkezelő, míg a Game objektum a játék adatait szolgáltatja. Minden esetben kapcsolódik a Game objektumhoz egy GameClient objektum is a "hálózat" kapcsolaton keresztül. Itt a Game objektum megint csak a játék adatait szolgáltatja, míg a GameClient a kapcsolatot biztosítja a szerverrel.

8.1.2. Attribútumok azonosítása

A GameServer osztály legfontosabb attribútuma a hálózati socket kezelésére szolgál, amelyen a kliensek csatlakozási és egyéb kérelmeit fogadja. Rendelkezik még egy port attribútummal, amely azon port számát adja, amelyen a kérelmeket fogadja. Valamilyen módon nyílván kell tartani a kapcsolódott klienseket is, ez valamilyen tömb típusú attribútummal valósulhat meg. Szükséges még egy buffer attribútum, amely a hálózaton áthaladó adatok átmeneti tárolását szolgálja.

A GameClient osztály szintén rendelkezik egy socket attribútummal, ami a kapcsolatot biztosítja a szerverrel. A játékos azonosítása miatt rendelkezni fog egy név attribútummal. Szükséges még egy buffer attribútum, amely a hálózaton áthaladó adatok átmeneti tárolását szolgálja.

A GameServer osztályon belül szükséges a csatlakozott kliensekről különböző adatokat tárolni, így célszerű bevezetni egy ServerClient osztályt, amely egy csatlakozott kliens adatait tartalmazza. Így ServerClient objektumok tömbje lesz a GameServer osztály egy attribútuma.

A ServerClient osztály attribútumai a következők: kliens neve, csapat neve, amelyikhez tartozik, channel (csatorna), amelyen keresztül a kliens kommunikál.

8.1.3. Bázisosztályok keresése

A kezdeti osztálydiagram megfelelő osztályokat tartalmaz, nem lehetséges bázisosztályokat bevezetni.

8.2. Dinamikus modell

8.2.1. LAN / Szerver létrehozása

Helyi hálózaton történő játék esetén az egyik játékos elvállalhatja a szerver szerepét. Ilyenkor a Game objektum adott metódusának segítségével létrehozunk egy GameServer objektumot, amely fogadja a csatlakozó kliensek kérelmeit, és szétosztja a megfelelő információt a kliensek között. A szerver létrehozása többnyire nem okozhat hibát, kivéve ha más program által használt portot jelöl ki a felhasználó, ebben az esetben ezt jelzi a szoftver. A szervert létrehozó játékos adja meg a játék típusát, a csatlakozható kliensek számát

8.2.2. LAN / Csatlakozás létező szerverhez

A szoftver érzékeli az aktív szervereket, és listát ajánl fel azokról. Ezek közül a felhasználó kiválaszt egyet, és a GameClient objektum példány megfelelő metódusának segítségével megpróbál csatlakozni ahhoz. Sikeres csatlakozás esetén elkezdődhet a játék.

8.2.3. Internet / Csatlakozás dedikált szerverhez

Az előző funkcióhoz hasonlóan itt is egy listát kap a felhasználó, ám az a dedikált szervereket sorolja fel. A csatlakozás itt is ugyanúgy történik.

8.2.4. Állapotdiagramok

28. ábra. GameServer osztály állapotdiagramja

29. ábra. GameClient osztály állapotdiagramja

8.3. Funkcionális modell

A hálózat alrendszeren belül a GameServer osztály egy példánya kommunikál több GameClient példánnyal. A GameClient objektumok a megfelelő Game objektum kérésére kérelmeket küldhetnek a szervernek, amelyet a GameServer objektum reprezentál. A GameServer objektum figyeli, hogy melyik csatlakozott kliens felől érkezett kérés. Ha érkezett kérés, akkor ellenőrzi, hogy értelmes-e az üzenet. Ammenyiben igen, akkor a szerver válaszüzenetet generál, és azt elküldi a megfelelő klienseknek. Amennyiben nem értelmes az üzenet, akkor szerver egy hibaüzenetet küld vissza a kérelmező kliensnek. A kliensek is fogadnak üzeneteket a szervertől, amelyre üzenettípustól függő választevékenységet hajtanak végre.

Mindkét osztály folyamatos kapcsolatban áll a megfelelő Game objektummal, azon keresztül történik az adatok áramlása.

8.4. Operációk azonosítása

A GameServer osztálynak rendelkeznie kell egy futtató metódussal, amely elindítja a kapcsolódási és egyéb kérelmek beérkezésének figyelését. Mivel kérelmeket tud fogadni a kliensektől, és válaszokat küld nekik, ezért lesz egy üzenet fogadó és egy üzenet küldő operáció is. Nyilván kell tartani a csatlakozott klienseket is, így lesz kliens hozzáadása és kliens törlése operáció is. Ki kell tudni választani a nyilvántartott kliensek közül azt, amelyiknek a választ küldeni kell. Ez név alapján fog történni, erre külön operáció fog szolgálni.

A GameClient osztályon keresztül tudunk csatlakozni a szerverhez, így szükséges egy csatlakozás operáció. Szintén kell tudnia üzeneteket fogadni és küldeni, amelyeket egy-egy operáció valósít meg. Lehetőséget kell biztosítani a kliens nevének lekérdezésére és megváltoztatására.

A ServerClient osztály elsősorban adattárolási célból jött létre, így lekérdező és beállító operációkat kell megvalósítania.

8.5. Az analízis modell osztálydiagramja

30. ábra. Hálózati alrendszer osztálydiagramja

8.6. Az analízis modell osztályainak listája

8.6.1. GameServer

• felelőssége, feladata: helyi hálózaton keresztüli játéknál valósítja meg a szerver funkciókat. Kezeli a kliensekkel folytatott hálózati forgalmat, feldolgozza a bejövő kérelmeket, és válaszüzeneteket küld szét.

• együttműködők: Game, ServerClient

• attribútumok

• operációk

8.6.2. ServerClient

• felelőssége, feladata: a szerveren belül nyilván kell tartani a csatlakozott klienseket. Egy csatlakozott kliens reprezentálására szolgál ez az osztály.

• együttműködők: GameServer

• attribútumok

• operációk

8.6.3. GameClient

• felelőssége, feladata: Hálózatkezelést valósítja meg a kliens oldalon, gondoskodik a szerverrel történő üzenetváltások lebonyolításáról.

• együttműködők: Game

• attribútumok

• operációk

9. Naplózás alrendszer modellje

9.1. Statikus modell

9.1.1. Kapcsolatok pontosítása

A Naplózás alrendszer feladata, tárolni a végrehajtott módosításokat. Ezeknek a módosításoknak a leírásait a Log osztály a játék fő osztályától a Game-től kapja. Mindkét osztálynak csak egy példánya van jelen egy időben ezért 1-1 kapcsolat van közöttük. A Log osztály tartalmaz még egy ún. Note osztályt, ez tárolja el a módoítások leírását, dátummal összekötve. Egy Log típusú objektumhoz tetszőleges számú Note példány tartozhat.

9.1.2. Attribútumok azonosítása

Log osztály: Mivel a naplózott adatok végül egy logfileba kerülnek bele, tartalamaznia kell egy File referenciát.
Note osztály: A Note osztály objektumjai tárolják el a naplózott eseményeket és a hozzá tartozó dátumot, ezért tartalmaznia kell egy Stringet az esemény leírásával és egy Date típusú objektumot.

9.1.3. Bázisosztályok keresése

9.2. Dinamikus modell

9.2.1. Állapotdiagramok

31. ábra. Log osztály működése

9.3. Funkcionális modell

9.4. Operációk azonosítása

A Naplózás alrendszer feladata, nyílvántartani a végrehajtott módosításokat. Ezek AddNote és AddEvent metódusok segítségével  kerülnek eltárolásra. Szükség van még a logfile-t beállító (setLogFile) és ezeket oda kiíró utasításokra is (writeOut).

9.5. Az analízis modell osztálydiagramja

32. ábra. Naplózás alrendszer osztálydiagramja

9.6. Az analízis modell osztályainak listája

9.6.1. Log

• felelőssége, feladata: a program futása során keletkező adatmódosításokat naplózza, melyek segítségével könnyebbé válik a hibakeresés.

• együttműködők: Game, Note

• attribútumok

• operációk

9.6.2. Note

• felelőssége, feladata: eltárol egy bejegyzést, azaz egy módosítás illetve annak az idejét.

• együttműködők: Log.

• attribútumok

10. Mellékletek

10.1. Információ források

A projekt létrejöttének nélkülözhetetlen forrás irodalma:

• Ian Somerwille
  Software engineering, 6th Edition, Addison Wesley, 2001


• Erik Bethke
  Game Development and Production, Wordware Publishing, Inc., 2003


• Tom Meigs
  Ultimate Game Design: Building Game Worlds, McGraw-Hill/Osborne, 2003

Internetes oldalak:

• http://www.iit.uni-miskolc.hu/ficsor
• http://java.sun.com
• http://www.eclipse.org/org/documents/epl-v10.php
• http://www.esrb.com
• Java kódolási konvenció
• OpenSource szabályok
• All-Seeing Eye
• PunkBuster