Hálózati Bombermen Belicza András Konzulens: Rajacsics Tamás BME-AAIT

Tervezési szempontok Jól konfigurálható, skálázható A kód teljes függetlensége a játékban használt hang és kép erőforrásoktól Kiemelt hálózati támogatás –korlátlan számú játékos –minimális sávszélesség-igény –csomagküldési „delay” kezelése

Konfigurálás, skálázás MVC architektúrát követ: –Java generikus „model”osztályok csak az adatok tárolására –„View” osztályok, melyek egy model osztály adatait JTabbedPane panelbe szervezik megfelelő komponensekkel –„Control” osztályok: ellenőrzött átjárás a komponensek és a modellek között, továbbá eseményvezérelt opciófeldolgozás

Grafikai és hang témák Nyitott grafika, hang: bárki újjal kiegé- szítheti, jellemzők téma property fájlokban Manager-ek kezelik egy téma összes paraméterét és adatát, a témát egyszerűen (könyvtár)névvel azonosítják A grafikai és hang téma egy-egy beállításnak felel meg, módosításukkor esemény generálódik, melyről a manager- ek értesülnek

Protokoll és szinkronizáció A hálózati protokollok teljes kidolgozása és implementálása –a hálózati adatforgalom: IP alapú TCP kapcsolat, szöveges üzenetek, parancsok paraméterekkel –Joining protokoll, kommunikációs protokoll, játékkezdés protokoll Szinkronizáció –gépek között a játékfázist, játszás alatt az iterációkat –gépen belül a szálakat a saját iterációkhoz

Kiemelt hálózati támogatás I. Korlátlan számú játékos: –a játék elkezdéséig a játékosok leíróit, csonkjait dinamikus méretű vektorokban, listákban tároljuk –a pályán a bizonytalan számú játékosok kezdeti elhelyezését külön algoritmus biztosítja –„igazából semmi nem indokolja a korlátozott játékosszámot”: a kliensek függetlenül 1 kapcsolatot tartanak a szerverrel

Kiemelt hálózati támogatás II. Korlátozott sávszélesség igény –lokális játékszámítás, csak szinkronizálás és akcióküldés –a parancsokat (Enum) számok azonosítják (ordinal()) –következő iterációknál: játékosok akcióit: a kontrol billentyűk állapota (csak ami változott)

Kiemelt hálózati támogatás III. Általános szabály: az új iteráció kiszámítása után az előző számítás utáni akciókat elküldjük, melyek a következő iterációban lesznek feldolgozva Felmérés: TCP kapcsolat esetén kb 50 karakter szöveg elküldése, és válaszként megvárása közötti átlagos idő: ms  50 ms iterációs idő használata (állítható opció)

Kiemelt hálózati támogatás IV. Csomagküldési „delay” kezelése –Network Latency fogalom bevezetése: a hálózati delay (és sávszélességtől) függően a Network Latency opció állítandó; hatása: gépek közti iteráció szinkronizálás csak 2 ill. 4 iterációnként történik (alapesetben minden iterációt szinkronizálunk) –a köztes iterációkat minden csomópont magának (saját időzítője alapján) szinkronizálja –következmény: csak 2 ill. 4 iterációnként kell szinkronizáló ill. akciókat tartalmazó csomagküldés  hálózati delay (oda-vissza) 50 ms-nak 2 ill. 4- szerese is lehet, sávszélességigény csökken

Szinkronizáció és latency Server Fast client Slow client

Összefoglalás Amit eddig tud a program: –teljes konfigurálási lehetőség –grafikus téma ellenőrzött betöltése, használata –játéklétrehozás és csatlakozás (korlátlan gépszám) –chat-elés, játékkezdés és „játszás” (a protokollok működésben, azonban még csak egy üres pályát látunk) Ami lesz: –játékimplementáció, tesztelések, korrigálások –opcionálisan: pályaeditor, játékmentés és visszanézés (replay)

Köszönöm a figyelmet. Játék specifikáció és elkészült forráskódok: