"ez az ami halott ügy, mert nem tud átmenni szimulációba mert az szerverteremnek is túl sok"
En a 2002 utan jatszottam egy MMO/PFS/RPG-vel, amit Neocron-nak hivtak. Ez egy FPS nezetu, FPS iranyitasu, MMO RPG volt, particionalt, on demand betoltott pariciokkal. Anno meg nem tudtak megoldani a seamless particionalast, ezert a valtasoknal volt egy par masodperces szinkronizacio, ami akkor meg eleg gyakran szinkronizacios hiba miatti disconnect-el ert veget, de amikor mukodott, akkor jo volt.
Maga a jatek szerver oldali FPS motort hasznalt, a ballisztikai es mozgas szamitasokhoz is, csak a kevesbe fontos modellek, pl. a kidobott toltenyhuvelyek visszapattanasa a tereptargyakrol mentek kliens oldalon. De a lovedekek kilovesi iranyat a felhasznalo egere hatarozta meg, a pontossagot a karakter skill-je es az adott fegyver tipusa es szazalekos tulajdonsagai, mig a becsapodasi pontjat a lovedekek utjat kovetve a szerveren is jelen levo tereptargyak 3D modelljei. Nem azonnali hitscan alapon futott, igy egy mesterlovesz puska lovedekenek becsapodasa tavolsagtol fuggoen tovabb tartott es virtualis lolapon (pl. egy tetszoleges sik falon) tesztelve a becsapodasi nyomok statisztikailag helyes szoraskepet hoztak. Ugyanigy lehetett a kornyezo tereptargyakon visszapattintva granatot bedobni egy hazsarok vagy egy ladahalom moge.
Hogy oldottak meg? Egy particion belul a szerveren lokalis FPS jatek futott, rendes fizikaval, de csak a fizikai modell-t futtatva, rendereles nelkul. A jatekosok csak bekuldtek a parancsaikat, majd a fizikai motor kimeneteit update csomagokban atkuldte az osszes kliensnek, akik igy szinkronizacional par masodperc alatt be tudtak gyujtani az osszes aktiv objektum allapotat. A fizikai modell nem kulonboztette meg a jatekosokat, az npc-ket es a mob-okat, a jarmuveket, stb. mindegyik csak egy mozgo objektum volt. A jateklogikaban sem volt kulonbseg, minden mob es npc ugyanolyan fps jatekos volt, tehat a sikatorban futo csotany is ugyanugy volt kezelve mint egy jatekos, csak szinkronizalo adatkapcsolat helyett egy buta MI iranyitotta. A vendor npc-k pedig tamadas eseten fegyvert ragadtak es hasonlo algoritmusra valtottak mint a biztonsagi orok. (A fegyvertelen civilek meg elfutottak vagy elbujtak egy kitoro utcai lovoldozes hatasara, mar ha tuleltek.) A fentiek miatt a vendor-okat allandoan potolta a jatekmotor ujakkal, a fontos quest npc-k meg vagy ott voltak vagy varni kellett amig ok is respawn-oltak es visszamentek a helyukre.
Hogy mukodott ez 20 eve? Nehezen. Atlagosan 10-16 jatekosonkent kellett egy fizikai szerver, igy osszesen kb. 32 mozgo jatekos+mob+npc fert el egy szegmensben. Az evek alatt ez csiszolodott, amikor utoljara neztem 2 eve mar az egesz cluster egyetlen berelt szerver sarkaban elfert es meg igy is tobb tucat aktiv jatekos volt a teljes vilagban (amit eredetileg tobb ezer parhuzamos jatekosra terveztek) Ez tobb szaz szektort jelent, mind nagymeretu felszini terkepeket jarmuvekkel, mind kis szuk varosi szektorokat, 1-2 utcasaroknyi terulettel az instance-kent futo dungeon-ok es a jatekosok szabadon berendezheto lakasai nelkul. Minden szektor csak akkor futott, ha eppen volt benne valaki, egyebkent befagytak. Visszatolteskor pedig elore tekertek az idot, a leallitva toltott ido kompenzalasara. (mivel a foldre rakott targyak is megjelentek a kozos fizikai modellben, ezert ezek eltunese ido fuggo volt, jatekos lakasokban a butorok es a szekrenyekben levo dolgok nem tuntek el)
Milyen hibak voltak a szinkronizacio miatt? Movement lag es rubber banding, azaz ha nagyon elmaszott a player lokalis szimulacioja a szervertol, akkor a player visszarantodott a szerver szerinti helyere. Az osszes tobbi mozgo objektum (jatekosok, npc-k, mob-ok) pedig a szerver szinkron szerint mozgott, tehat a tobbi player kisse lemaradva a szerver allapottol, de a jatekosok a szerver fizikai szimulacioja szerinti helyukon lattak oket, ami a kepernyon mindig egy fel ping-nyit le volt maradva a szerverallapothoz kepest. Csomagvesztes eseten pedig predikcios algoritmussal tert el, majd ugrott vissza. Gyakorlatilag a quake 3 fele logika szerint. (a motor egyebkent binary space partitioning-et hasznalt mind a megjelenitesre, mind a fizikai motorhoz) Mindez a kisebb csuklasokat leszamitva mar jatszhato volt 20 eve.
Ehhez kepest a szerver oldali rendering meg gyorsabb es egyszerubb is. Megszunik ugyan a kliens oldali predikcio altal elert mozgas simitottsag csomagvesztes eseten, de en mar jatszottam google stadia-n fps-el es teljesen jol kezelheto, ha alacsony az ember ping-je. A nagy savszelesseg csak a nagyobb felbontashoz kell, de a jo iranyitashoz csak a ping szamit. Mig a zokkenomentes streaming-hez a kis csomagvesztes a fontos, mivel nincs buffer-eles es nincs ujrakuldes (osszesen 1 fame mely a streaming buffer), ha csomagvesztes van, akkor a kepkocka egyik darabja nem jon meg es ott vagy az elozobol tolti ki a kliens 2D mpeg predikcioval vagy sehogy. (lasd muholdas stream-ek mpeg hibait) Progressziv kepek es valamennyi baseline redundancia eseten csak az adott folt kepminosege esik vissza a 8...64-edere, a csomagvesztes merteketol fuggoen.
A fenti streaming kombinalva egy grid vagy BSP alapu dinamikus szektor kezelessel siman tudna biztositani egy nagymeretu jatekvilag szerver oldali kezeleset, szerver oldali fizikaval es ma mar akar tobb szaz vagy tobb ezer mozgo entitassal egy szektorban. Mindezek melle szerver instance-ban futtatva a dungeon-oket es a player houseing-ot mar siman skalazhato lenne a rendszer egy FF14 meretu vagy nagyobb vilagra is, teljes mertekben szerver oldalon futtatva mindent. A trukk, hogy a szerver nem szinkronizal senkivel, csak player input-okat kap, ezert egyszerubb sokkal tobb mozgo objektum kezelese es akar a terep is rombolhato lesz. (lasd multiplayer minecraft csak mondjuk pl. a fent emlitett FF14 szintu grafikaval)
Informatika és tudomány
