Ashes of Creation – A Server Meshing és ami mögötte van

A Server Meshing-es Ashes of Creation stream után kicsit gondolkodtam, miért lett ez így kiemelve, aztán rájöttem, hogy valószínűleg azért, mert a srácok egy új technológia alapjait fektették le és úgy tűnik működni is fog. Ezért is gondoltam, hogy írok erről egy külön cikket, nem is annyira a technológiáról, inkább az evolúcióról, ami ezen a téren történt és természetesen az élményeimről is. Tehát egy kicsit ássunk mélyebbre, mitől lett a Server Meshing összefoglaló az eddigi legfontosabb téma az Ashes of Creation és úgy egyébként az mmo világ történetében. Már itt fel is tehetjük a kérdést, hogy ez most mitől olyan fontos újítás, de előtte egy kis történelem…

A Történelemóra:
A szélessávú internet elterjedése többek között magával hozta, az online játékos közösségek és az MMORPG, mint műfaj kialakulásának lehetőségét. Az Ultima Online, amely az egyik legnépszerűbb MMORPG lett, 1997 szeptemberében jelent meg és már pár ezer ember befogadására képes nevesített szerverekkel rendelkezett. Természetesen ez a játékosszám eloszlott a világban, de alapvetően jópár ember kezelésére volt képes egy adott területen is.
Technikailag nézve, úgy néztek ki az ebben az időszakban megjelenő játékok, hogy karakter készítés előtt választottál magadnak egy nevesített szervert a listából, lehetőség szerint azt, amelyiket a haverjaiddal előtte megbeszéltétek és igyekeztetek elkerülni a tömegnyomort (layer-ek még nem léteztek), így mindenki, aki a világban volt, láthatta a másikat és interakcióba is tudott lépni vele. Egyébként a világtérkép zónáit sem külön szerverek futtatták, egy szerver erőforrásaira építették fel az egész játékot.

Az MMORPG népszerűsége évről évre egyre nőtt, nyilvánvalóvá vált, hogy ez a rendszer képtelen kiszolgálni az igényeket. 2003-ban a Lineage 2, 2004-ben a WoW jelent meg, amelyek egy újabb szintet értek el. Pontos értékeket nem tudunk, de az biztos, hogy a szerverek max játékosszáma 3-5 ezer körül lehetett. Egy területen is képesek voltak már 50-100 körüli játékos egyidejű megjelenítésére és szinkronizálására. Természetesen a javítások és finomhangolások, valamint a vasak és a technológia fejlődésének hála ezek a értékek valamennyit idővel javultak, ha nem is kiemelkedően. Fontos különbség volt még az is, hogy például a WoW esetében a nevesített szerverek (shard-ok), több szerverparkból álltak, vagyis a töltőképernyős területeken, vagy a világtérképet felosztó zónákat már külön szerverek működtették. Erre azért volt szükség, mert a játékok már annyi új lehetőséget kínáltak a játékosok számára, hogy ezeket egy szerver már képtelen lett volna kiszolgálni.

2012-re jött el az idő, amikor az előző technológiából kipréselték a maximumot és valami új megoldással kellett előállni. Ez lett a forradalmi Mega Szerver technológia. A lényege röviden annyi volt, hogy nem voltak külön nevesített szerverek (shard-ok), hanem „egy mega” szerverre csatlakozott fel mindenki és különböző layer-ekre osztotta be a játékosokat a szerver. Vagyis ha egy területen sok játékos volt, akkor akár 10-20-30 layer is létezhetett. Ugyanis a szerver egy adott területen továbbra sem tudott több 100 embert egyszerre feldolgozni, így ha egy terület populációja megemelkedett, akkor zóna váltásoknál a játékos egy kevésbé túlterhelt layer-re került. Úgy kell ezt elképzelni, mint egy 30 emeletes épületet. A mega szerver irányítja a zónákat, a zóna egy emeletes ház, az emeletek külön layer-ek, vagyis szerverek. Vagyis ha az első 5 szinten már nem férnek el a zónában, közösségi területeken a játékosok, akkor kerülsz a 6. emeletre, vagy bámelyik másikra, ahol még nincs annyi játékos. Tulajdonképpen erőforrás menedzselték a szerverek kapacitását, amelyik területen sokan jártak ott több szinten játszottak emberek, akár 1-30 szinten is egyszerre.

De mi van akkor, ha mi a barátainkkal szerettünk volna játszani, de őket más layer-ekre tette a játék? Ha valakivel partiztál, vagy guild társad volt, vagy bármilyen módon kapcsolat volt köztetek, akkor a játék igyekezett egy szintre, layer-re rakni ezeket a játékosokat. Ha valamiért ez nem működött akkor mindenkit a csapatban átrakott egy üresebb szintre. A szerver képes volt menedzselni a partiban játszani akaró játékosokat és a layer-eket, hogy a régiók ne legyenek túlterhelve és a játékosok is lássák egymás tevékenységét. Óriási dolog volt ez, mivel megoldotta azt a régi problémát, hogy minden kezdő MMORPG címnél a kezdeti szerver helyezkedés. Ha nem ültél ott a nyitás pillanatában, lehet már nem fértél fel a szerverre, annyira betelt, hogy már karaktert sem tudtál ott létrehozni. Guild-ek esetében ez egy igen stresszes téma volt. Arról nem is beszélve, hogy ha például kiürült a szerver alólad, vagy nem voltál elégedett a szerveren tartózkodó játékosállomány szellemi szintjével, akkor bizony sokszor a költözésre se volt lehetőség sokáig, vagy eleve fizetős volt. A Mega szerver technológia ezt megoldotta és mindenki azt gondolta, hogy minden mást is, de ahogy lenni szokott, nem minden volt fekete és fehér, ahogy a Guild Wars 2 masszív PvP csatái és később az Elder Srcolls Online is bebizonyította.

A layer-ezés ugyebár megoldotta 2012-re a szerver választási, költözési mizériát a nagyobb címeknél, de nem oldotta meg azt, hogy a masszív PvP valóban egy masszív PvP legyen, illetve mind kliens mind szerver oldalon jó minőségben, élvezhetően fusson. A Guild Wars 2 esetében a 100 száz fős csaták, várfoglalások iszonyú kliens és szerver lagokba torkoltak. Sajnos az Aion MMORPG névtábla háborúihoz képest sok minden nem változott, csak a környezet lett szebb, de 50 játékos felett ugyanúgy semmit nem láttál, csak neveket és szellemeket. Ezeket később sablon bábukra cserélték, hogy a gyengébb géppel rendelkező játékosok is legalább sejtsék merre van az ellenség.
A fejlődés természetesen látható volt, mert több embert, szebben és akadásmentesebben láthattunk, de azért a technológia korlátai elég hamar megmutatkoztak. Az Elder Scrolls Online esetében is hasonló események zajlottak le, csak még több embert engedtek egymásra. Az első pár hónapban mindenki élete csatáját vívta a várak között, még úgy is fantasztikus élmény volt, hogy 200 játékos körül már alig volt 15-20 fps, meg a latency is megemelkedett. Mindenesetre még soha nem üthette egymást 250vs250v250 ember egy PvP zónában, ami mondjuk hatalmas volt. Mint említettem, hónapokig csodálatosan új és nagyszerű élmény volt, de jött a fekete leves, sajnos a Csillagpontok bevezetésével a szerverek és a technológia és megadta magát. Elsőnek a PvP zóna létszámot csökkentették 20%-kal, aztán kivezették a felbérelhető NPC társakat, majd kivették az állatokat a területről és mindent, ami „fölösleges” erőforrást foglalt le. Ennek ellenére a problémák nem oldódtak meg, mert játékosonként túl sok adatot kellett fogadnia a szervernek minden másodpercben és azt összeszinkronizálni. Mindent kitaláltak, de a vége az lett, hogy a Csillagpont nélküli szerverek felé mentek el, kvázi beismerték, hogy a masszív PvP, mint élmény, a technológia és erőforrások hiányában elbukott.

Itt térnék ki zárójelesen arra, hogy az előző 20 évben az is probléma volt, hogy a szerverek sokszor lefagytak, akadtak, sűrűn kellett karbantartani azokat. A masszív csaták velejárója volt a kliens és szerver oldali crash-ek, valamint magának a szervernek az összeomlása túlterhelések és a bugok miatt.

A jövő technológiája, vagy nem:
Újabb évtized telt el és az MMORPG láz is szép lassan elmúlt. Ennek van jópár oka, nem is mennék bele a részletekbe, maradjunk annyiban, hogy túl sok életképes játék sem jött ki a témában és a megvalósult projektek sem nyújtottak szinte semmi újat, sem funkciókban, sem élményben, sem technológiában, mint ahogy a régi „öregek” tették azt.
A technológiában sem látszott működő modell arra, hogyan lehet sok játékost egy helyen normális fps és latency értékek mellett mozgatni. Amiről tudok az a Star Citizen és csapata, akik évek óta próbálnak valami életképes történettel előállni, de egyelőre még nem láttunk ebből semmit.
Az első pislákoló fény talán akkor jött el, amikor Steven és csapata bejelentette, hogy az Unreal Engine 4.2-ről 5.0-ra állnak át és pár hónappal később előhozakodtak egy szimulációval, ahogy több száz modell csapkodja egymást. Az új megoldások segítségével jóval több játékost, jóval kevesebb erőforrás igénnyel volt képes mozgatni az Unreal motor. Ez egyúttal megoldotta a kliens oldali megjelenítést, de még mindig ott van a szerver és a latency (akadás, lagolás) probléma. Nos úgy tűnik a srácoknak sikerült ezt is megvuduzni és ezt prezentálták nekünk a június havi összefoglalóban. Most pedig lássuk miben más ez a megoldás, mint amit eddig láttunk:

One World:
Intrepid Net-ként nevezték el a kialakított technológiák halmazát. Az Ashes of Creation játékban a következő elvárásnak kellett megfelelnie:
– Semmilyen intanszolt, layerezett terület, nulla töltőképernyő mindezt egy teljesen nyílt világban
– Ugyanazon a layeren nagy számú játékos megjelenítése (többszáz játékos)
– Bármilyen területen nyitott és nagy számú játékos PvP lehetősége
– Jó és stabil latency a PvP miatt

Ezek az elvárások nem feleltek meg a már létező technológiáknak, ezért újat kellett létrehozni. Az Intrepid Net a következő már létező, vagy újonnan létrehozott technológiákat tartalmazza:
– Server Meshing
– Inter-Server Replication
– Microservices
– Dynamic Gridding
– Replication Graph

Mi mire jó?
Actor: az önálló entitásokat jelöli a világban, legyen az ló, doboz, sátor, vagy karakter.

Replication: az entitások szinkronjáért felel szerver és kliens oldal között.

Server meshing: a világokat osztja fel különböző játék szerverekre, így egy világ működéséért több szerver felel.

Hogyan látják egymást a játékosok ha két különböző szerver zóna határán állnak?
Proxy: Megoldásként erre a proxy-t alkalmazzák, amely az eredeti játékos egy másolata, valós kapcsolat nélkül. A proxy nem a játékos, hanem annak egy up-to-date verziója és ha a játékos mozog, akkor vele együtt mozog a proxy másolat is. A szerverek határai láthatatlanok, nincs töltőképernyő és a két szerver közötti mozgás is tulajdonképpen észrevehetetlen. A proxy másolat segítségével kevesebb adat közlekedik a szerverek között, így gyorsabban és kevesebb erőforrásból tudják megoldani az átkeléseket.

Server meshing: Az itt látható prezentációban látható, hogyan néz ki egy tipikus server meshing megoldás, és hogyan néz ki az Intrepid féle megoldás:

Tulajdonképpen az Intrepid teljesen kihagyta a központi objektum replikátort, ami ugye a szinkronért felel, cserébe a szerverek felelnek a szinkronért, így például ha valamelyik szerveren hiba keletkezik, akkor nem áll meg az egész zóna, hanem tovább tud működni a rendszer. A régi rendszer hátránya volt, hogy hiába a sok szerver, ha a replikátor túlterhelődik, akkor a latency romlik, elkezd akadni minden, meghalunk a semmitől a szinkron csúszása miatt, jöhet az összeomlás, amit eddig szinte minden eddigi MMORPG játékban láthattunk tömegrendezvények esetében. Az Intrepid megoldása praktikusabb, gyorsabb és ha hiba történik, sokkal könnyebb megtalálni és javítani a hibát. 

Ahhoz, hogy a játékosok interrakciói szinkronban legyenek a világ szervereivel, ezért létrehozták a Microservice rendszert. A szerverek felett van még egy halom szerver, amely a játékosok különböző interrakcióiért felelősek. Ez a rendszer tulajdonképpen egy alrendszer, amely rendszer minden adatot szinkronban tart a világ szerverein. Ezen kívül a csapat létrehozott egy Shols Eye nevű szolgáltatást a Microservice rendszeren belül, amelynek segítségével, minden játékos aktivitást, NPC mozgást, és egyéb entitás jelenlétét képesek látni és kezelni. A rendszer kapcsán szintén előnyös lehet, ha például összeomlik a Social Service-ért felelős szerver, attól még a többi működni fog, nem áll meg az összes szolgáltatás.

Dynamic Gridding:
A prezentáción egész jól látható miről is szól ez a megoldás. Minden zónáért felelős egy szerver, de ha egy zóna túlterhelődik, mert sok játékos jelenik meg, akkor képesek felosztani a zónát és több szervert rákapcsolni a területre, így az erőforrás jobban eloszlik a szerverek között. Nem ők az elsők, akik ezzel a módszerrel próbálkoztak, de eddig nem igazán sikerült megvalósítani, mert ugye az átmenetnek úgy kéne megtörténnie, hogy a játékos ebből nem vesz észre semmit. Nos úgy tűnik az Intrepid csapata ezt megoldotta. Ez a dinamikus erőforrás menedzselés még fejlesztés alatt áll, de jó hír, hogy már az Alfa 2 verzióban is szerepelni fog, így látni fogjuk, a gyakorlatban mennyire működik a rendszer.

Replication Graph:
Ez a témakör már egy kicsit mély volt nekem, de valami olyasmi lehet, hogy ha a játékostól túl messze van egy-egy Actor/indentitás, akkor azt figyelmen kívül hagyja a rendszer, így nem kell fölöslegesen annyi erőforrást felhasználnia.

Multithreading the Replication Graph:
A probléma az, hogy az Unreal Engine egy nagyon egyszálú motor, és a replikáció az egyik leginkább egyszálú rendszer. Ez azt jelenti, hogy a szerver CPU-ja nincs kihasználva, mivel a magok közül mindig csak 1 dolgozik a rendszeren. Többszálúvá tenni hihetetlenül nehéz, és a tudomásuk szerint még nem sikerült eddig senkinek….mostanáig, ugyanis az Intrepid csapatának sikerült megoldani a Replication Graph rendszer többszálúsítását az Unreal Engine-en belül, ezáltal 94%-kal csökkent a replikációs idő, amely már elég ahhoz, hogy a céljaikat elérjék.

Végszó:
Röviden összefoglalva ennyi fért bele a mai cikkbe. Egészen elképesztő ez a csapat és egészen elképesztő, amit eddig létrehoztak. Az Alfa 2 tesztek alatt lesz idő kipróbálni a mágiát, amit létrehozott ez a csapat. Ha a sors úgy hozza, akkor ezek a fejlesztések később más játékokban is meg fognak jelenni, ezáltal a következő 10 évben találn már nem egy laghullámban kell majd masszív PvP ostromokat vívnia a játékosoknak. Megjegyzésként szúrom be ide, hogy ehhez megint nem kellett egy többszázmillió dolláros cég, csak egy lelkes kis csapat, aki megoldást szeretett volna találni a problémákra… ugye Amazon, Blizzard, Bethesda,…?! 🙂

Itt láthatjátok a teljes összefoglalót, ha esetleg lemaradtatok róla: