H álózati Bombermen

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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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)

8. 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ő: 25-30 ms 50 ms iterációs idő használata (állítható opció)

9. 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

10. Szinkronizáció és latency Fast client Server Slow client 0 0 0 1 1 2 1 2 3 2 3 3 4 4 5 4 5 5 6 6 6

11. Ö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)

12. Köszönöm a figyelmet. Játék specifikáció és elkészült forráskódok: http://i.aut.bme.hu/onlab/BeliczaAndras/index.html