A Source motor

A Source motorra épülő multiplayer játékok kliens/szerver halózati felépítésűek. Nagy általánosságban elmondható, hogy a játék dedikált szervereken zajlik, és ezek önállóságot élveznek a motort használó játék típusa, annak beállításai, szabályai, és az oda csatlakozó kliensek (játékosok) kezelését illetően. Ezek a kliensek a játékosok számítógépein futó programok, melyek kapcsolódnak a szerverhez, és a kettejük között zajló kommunikáció kis adatcsomagok nagy gyakoriságú küldéséből és fogadásából áll (20-30 csomag másodpercenként). Ebben a kétirányú adatközlésben a szerver folyamatosan frissíti az adott játékkal kapcsolatos adatokat a kliensnek, amiket az audio és video jelekké alakít át, valamint a kliens is folyamatosan frissíti a szerver irányába a perifériákról (billentyűzet, egér, mikrofon, stb.) mintavételezett változásokat, és küldi mindezt el a szervernek további feldolgozásra. A kliensek csak és kizárólag a szerverrel folytatják ezt a társalgást, egymással nem állnak kapcsolatban. Ellentétben az egyszemélyes vagy single (offline) játékkal, egy multiplayer játéknak éppen ezért, számos új problémával kell megbirkóznia, amit az eddig ecsetelt csomag alapú adatcsere okoz.

Mivel bármely használt hálózat sávszélessége korlátozott, a szerver nem engedheti meg magának, hogy a játékban bekövetkező változásokat rögtön és külön-külön frissítse minden egyes kliensnek, ezért ehelyett a szerver megadott időközönként pillanatképeket készít a játék menetéről, és ezeket küldi el. A hálózati csomagoknak időbe telik, míg megteszik a szerver és a kliens közötti távolságot (lásd: ping) és mindez azt is jelenti, hogy a kliensnek a megkapott információk alapján felépített aktuális jatékállapota, rendre egy kis késésben lesz a szerverhez képest.
Természetesen mindez igaz a kliens oldalról érkező csomagokra is, tehát a szerver is késleltetett kliens oldali parancsokat és állapotjelzéseket dolgoz fel. Ráadásul a kliensek késése a szerverhez rendre más és más, ami (a hálózati kapcsolatok típusából eredő különbségeken felül) az idővel is változik, függően a további hálózati forgalmától, vagy a kliens framerate-jétől is. Ezen egyidejűség-különbségek a szerver és a kliensek között, értelemszerűen vetnek fel problémakat, melyek csak rosszabbak lesznek ezen kétoldalú késés növekedésével.

Jellemzően a gyors menetű, akció játékokban a legkisebb, néhány ezredmásodperces késés is "laggos" játékélményt okozhat, nehezebbé teszi a másik játékos eltalálását vagy a mozgó tárgyakkal történő manipulációt (hisz máshol vannak valójában, mint amit látunk. a szerk.meg.). A sávszélesség korlátozása vagy a nagy mértékű késés, könnyen okozhat információvesztést a kommunikációban, köszönhetően, a hálózati csomagok eltűnésének vagy elévülésének.

Hogy mindezekkel a hálózati kommunikációval kapcsolatos, fentebb tárgyalt problémákkal megbirkózzon, a Source motorja több módszerrel küszöböli ki, vagy legalábbis próbálja kevésbe szembetűnővé tenni a játékosok számára mindezt. Ezen módszerek az adat kompresszió (tömörítés), interpoláció (kitöltés), predikció (előrejelzés/várakozás) és lag kompenzáció (kiegyenlítés). Mindezen eszközök szorosan kötődnek egymáshoz, és valamely változtatás valamelyikben komoly befolyással lehet a többire. Ez a dokumentum nagy általánosságban írja le ezen rendszerek működését, funkcióját és egymáshoz való viszonyát.

Az alapok

A szerver az adott játék szimulációját nem folyamatosan, hanem diszkrét változások/változtatásokon keresztül végzi, ez a játék szívverése, és mostantól tick néven hivatkozunk rá. Alapértelmezésben a motor 66 ticket szimulál másodpercenként, de a különböző modok saját beállításokat használhatnak. Például a Counter-strike: Source alacsonyabb, 33-as értekkel dolgozik, hogy így is csökkentse a szerver CPU terhelését. Minden szívdobbanás, azaz tick után, a játék beállításaival összhangban, a szerver feldolgozza a kliens oldalról kapott parancsokat és ezek együttese alapján pedig szimulálja a objektumok változását, befrissíti azokat. Miután a szerver lejátszotta magában ezt a szívverést, ellenőrzi, hogy mely kliensekkel szükséges változásokat közölni, és ezek alapján eldönti, hogy a szükséges pillanatképet megcsinálja-e. A szimuláció pontossága értelemszerűen a tickrate növekedésével nő, ugyanakkor mind a kliens, mind a szerver oldal sávszélességével valamint a szerver CPU-jával szemben is nagyobb követelményeket támaszt. A szerver adminja tetszés szerint állíthatja a szerver szívverését a -tickrate futtatási paraméterrel, de nem feltétlenül szerencsés, mert a motor adott modja nem feltétlenül fog a tervezett módon működni a módosított tickrate-tel.

Általában a kliensek rendelkezésére álló sávszélessége korlátozott. Egy modemes kapcsolat esetén a kliens által kapható maximális adatmennyiség 5-7 KB/másodperc, csak hogy a legrosszabb esetet említsük. Amennyiben a szerver nagyobb mennyiségű adatot próbál közölni mint amennyit a kliens befogadni képes, a csomagvesztés elkerülhetetlen. Éppen ezért a rate(bytes/másodperc) változó megfelelő beállításával, minden egyes kliensnek meg kell mondania a szervernek, hogy az ő személyes kapacitása a csomagok fogadására mekkora. Ez a legfontosabb kliens oldali hálózati beállítás, melynek pontos eltalálása elengedhetetlen az optimális játékélményhez. A kliens szintén megadhatja, a cl_updaterate paranccsal, hogy másodpercenként maximum hány pillanatképet, csomagot hajlandó fogadni a szervertől, de a szerver soha nem fog többet küldeni az általa legenerált szívverésekből, mint amennyit a rate parancs által megadott sávszélességkorlát lehetővé tesz, és természetesen szintén korlátja az, hogy maga a szerver hány ilyen szívverést generál le, tehát hogy mekkora tickrate-en fut. A szerver üzemeltetője korlátozhatja a maximálisan elküldhető adatokat a már említett bontásban, tehát a maximális kliens oldalra nyíló sávszélességet az sv_maxrate, és a maximimalis lefrissítés gyakoriságát a sv_maxupdaterate parancsokkal.

A kliens a perifériákról ugyanazzal a tickrate-tel mintavételezi az adatokat, és generálja ezekből a szerver számára feldolgozható parancsokat (user commands), mint amin a szerver is fut. (igen praktikus, hisz így a szervernek csak az általános késéssel kell törődnie, hisz maguk a parancsok szinkronban lehetnek a szerver szimulációjával (a szerk.meg). Egy ilyen felhasználói parancs (mostantól usercommand) alapvetően semmi más, mint egy, az adott szívveréshez tartozó pillanatkép a billentyűzet és az egér státuszáról. Ugyanakkor ahelyett hogy minden egyes tickre új csomagokat küldene a kliens a szervernek az éppen aktuális usercommandokkal, a kliens a usercommandokat tartalmazó csomagokat megadott időközönként közli csak. Mindez azt is jelenti, hogy kettő vagy több usercommand is érkezhet ugyanazzal a csomaggal a szerverhez. A kliens a küldés gyakoriságának beállítására a cl_cmdrate parancsot használja, ennek a növelésével javítható az interaktivitása a játéknák, érzékenyebben fog reagálni a változásokra, viszont nagyobb kifele menő sávszélességet követel.

A játék által kommunikált adatmennyiség, ú.n. delta kompressziót, egy adott tömörítési eljárást használ, hogy csökkentse a sávszélesség igénybevételét. Ez azt jelenti, hogy a szerver nem közli a klienssel az összes információt, amit tickenként szimulál, hanem csak azon változásokat (delta snapshot), amik az utolsó megerősített frissítés után történtek. A megerősítés úgy történik, hogy minden elküldött és fogadott csomaghoz, ami a kliens és a szerver között áthaladt, egy számot rendelnek, hogy mindkét fél tudja követni és ellenőrizni az adatfolyam kontinuitását, folyamatosságát. (igen, ez alapján tudja a kliens, hogy neki pocket loss-a van. a szerk. meg.) Általában teljes pillanatképet (tehát ami nem delta snapshot), csak a játék kezdetekor küld a szerver, vagy ha a kliens oldalon komoly csomagvesztés jelentkezik. (mikor a kliens már nem képes összerakni a pillanatképet, és egyszerűbb neki egy teljes frissítést kérni, hisz a delta tömörítés eredménye sem lenne nagyon más, mert az utolsó visszajelzett frissítés óta majd minden változott. a szerk. meg.) A kliens manuálisan is kérheti a teljes frissítést a cl_fullupdate parancsal. (valószínűleg a csítek elleni harcban lehet szerepe, de ez a parancs csak sv_cheats 1 szerveroldali beállítással működik. (A szerk. meg.)

Interpoláció

A kliens annyi pillanatképet, csomagot kap a szervertől másodpercenként, amekkora a cl_updaterate paraméterének az értéke. Ha egy adott dolog helyzete a játékosnál, a kliens oldalon csak akkor és ott lenne kiszámolva és kirajzolva, ahol és amikor azt éppen aktuálisan a szerver közölné, a mozgó dolgok, modellek, tárgyak, stb. darabosnak, akadozónak látszanának, és szintén problámat jelentene a megjelenítésben az elveszett, vagy figyelmen kívül hagyott csomagok is. A trükk ahhoz, hogy mindezt elkerüljük az, hogy a renderelést, tehát a megjelenítendő dolgok kiszámolását nem a legfrissebben megkapott pillanatkép, hanem időben az ezelőtti valamelyik csomag tartalma szerint keszíttetjük el, ezzel a jelenlegi pozíciókhoz vezető animáció folyamatossá tehető, hisz kitöltődik a jelenlegi pozició, és az ezt megelőző pozíció közötti út. Ezt nevezik kliens oldali entitás interpolaciónak, kicsit magyarosabban kliens oldali folytonosításnak, diszkrét poziciók közötti kitöltődésnek. (egyik sem magyaros, de úgy kell elképzelni mintha teniszben csak azt tudnánk hogy hol ért földet a labda, és hogy hol ütöttek bele; csak akkor tudjuk szépen megrajzolni a labda repülésének az ívet, ha nem abból indulunk ki, hogy hol ért földet, hanem hogy hol ütött bele a játékos, majd a földetérés, és az ütés, mely időben előbb történt, között megmutatjuk, interpoláljuk, hogy merről érkezett a labda a földetérés pontjához (A szerk. meg.). Ezen kitöltődés ki-, bekapcsolható a cl_interpolate 0/1 változó segítségével. Egy másodpercenként húsz pillanatképet frissítő kliens esetében, az aktuálisan következő frissítés körülbelül minden 50. ezredmásodpercben érkezik meg. Az előzőek alapján, ha az aktuális kép kiszámolásához az 50 ezredmásodperccel azelőtti pillanatképet veszi alapul, akkor a dolgok a megjelenítésben az utoljára megkapott pillanatkép, és az az előtti között tökéletes kitöltés valósítható meg. A Source motor az entitás interpolációt 100 ezredmásodperces késleltetéssel végzi alapértelmezésben, ami azt jelenti, hogy 20 frissítés eséten, az egyik frissítés elvesztésekor is képes két valós pillanatkép közötti helyzetkitöltés elvégzésére. (ez a cl_interp parancs, mely a 100 ezredmásodpercnél 0.1-et jelent. Mikor az ember ezt az értéket 0-ra rakja, az 1/cl_updaterate íródik be automatikusan, mely pontosan azt jelenti, hogy éppen nem képes a két pozíció közötti kitöltésre, hisz az interpoláció mérteke pont a két megkapott pillanatkép között eltelt idő (A szerk. meg.). Az alábbi ábrán elmélázva láthatjuk a megjelenítés, frissítés és interpoláció kapcsolatát az idő függvényében.

A kliens oldalra megérkező pillanatkép a 344-es ticknél történt, időben kifejezve a 10.30 másodpercnél. A kliens oldalon az idő szalad tovább természetesen, és a szívverésének megfelelő következő pillanatban, jelen esetben 10:32 (current time), megjelenít egy képkockát, ami viszont a kliens jelenlegi időpillanata (client time) mínusz az interpolációs (kitöltés miatt szükséges) késleltetés, azaz 0.1 másodperccel csökkentett, 10:22-kor birtokolt pillanatkép alapján számított pozíció. Tehát a megjelenített animáció alapja példánkban, a 340 és a 342 közötti pillanatkép.

Minekután az interpolációs késés 100 ezredmásodperc, az interpoláció akkor is működőképes ha a 342-es pillanatkép valamely oknál fogva elveszett. Ekkor ugyanis az interpoláció még mindig használhatja a 340 és 344-es pillanatképek közötti kitöltést. Ha több mint egy csomag veszik el, a kitöltés megbízhatatlanná válik, hisz nincs elég információ a birtokában hozzá. Ebben az esetben a renderelés extrapolációt használ (cl_extrapolate 1), és megpróbálja egyszerű, a birtokában levő információk alapján, egyenes arányosságon alapuló mintaillesztéssel betippelni, hogy hol lehetnek a dolgok. Az extrapoláció csak 25 századmásodpercig működik ( cl_extrapolate_amount) csomagvesztés esetén, mert ezután a motor úgy ítéli meg, hogy a jóslás hibahatára túl alacsonnyá válik, tehát kevésbé valószínű, realitását vesztettnek tekinti saját extrapolációját, kiegészítését.


Predikció

Tegyük fel, hogy egy játékos 0.1 másodperces késést szenved el a hálozata miatt, és elindul előre. Az információt, hogy ő elindult, tehát a +FORWARD gomb lett nyomva, egy usercommand formájában először tárolja, majd továbbítja a kliens a szervernek. Ekkor a szerver feldolgozza ezt, és a játékos a szerveren szimulált világban megindul előre. Ekkor a világ státusza megváltozik, és a következő pillanatkép, amit a többi játékosnak lefrissít, már tartalmazza ezt a megváltozott állapotot. Tehát 0.1 másodperccel azután hogy elindult, mindenki más, köztük ő is, érzékeli hogy elindul, és ez a késés minden jatékos bármely akciójára is igaz, legyen az mozgás, lövés, stb., és csak roszabbá válik nagyobb késés esetén.

A játékos akciója és a szervertől érkezett válasz késése, mely egyben a vizuális megjelenés késését is jelenti, szokatlan, természetellenes érzést kölcsönöz az egész jatéknak, nehezítve a precíz mozgást és lövést. A kliens oldali predikció (cl_predict 1) segít megszűntetni mindezt, csökkentve a késést, és így a játékos a beavatkozásait sokkal közvetlenebbnek érezheti. Ahelyett hogy arra várna a kliens, hogy a szervertől megérkezzen a saját poziciójának a frissítése, a kliens önmaga megbecsüli a saját usercommandjának az eredményét. Ehhez a kliens pontosan ugyanazokat a beállításokat használja, amit a szerver, és miután a predikció befejeződött, a játékos már az új poziciójában fogja látni magát, függetlenül attól hogy a szerver őt még a régi pozíciójában látja.

A kliens 0.1 másodperccel ezután kapja meg a szervertől azt a pillanatképet, amiben azok a változások vannak benne, amiket ő már végrehajtott, és semmi más dolga nincs, mint összehasonlítani a szerver által megadott változásokat a saját maga által végrehajtottakkal. Amennyiben ezek nem egyeznek, predikciós hiba lépett fel, ami azt mutatja, hogy a kliensnek nem álltak birtokában megfelelő információk a jatéktérben rajta kívül szereplő dolgokról, mikor a usercommandot végrehajtotta. Ekkor a kliens felülbírálja magát a szervertől kapott pillanatkép alapján. Amennyiben a cl_showerror 1 be van kapcsolva, a kliens látja mikor következik be ilyen hiba, ugyanakkor ezen hibák kijavításai a jatékban is észlelhetőek, mert kép ugrásához vezetnek. Ahhoz hogy a látható képen ez kevésbe tükröződjön vissza, a predikciós hiba fokozatosan javítódik ki egy adott időintervallum alatt (cl_smoothtime). A predikciós hiba kijavításának az elmosását szintén ki lehet kapcsolni, a cl_smooth 0 kapcsolóval.

Ez a fajta előrejelzés vagy predikció csak akkor működhet, ha a kliens pontosan tisztában van mindazzokkal az információkkal amivel a szerver is bír. Természetesen ez az esetek töredékében lehet csak így, hisz a szerver többet lát, és több belső információval rendelkezik mint a kliens. A kliens csak egy apró szeletét láthatja az egész jatéknak, pont annyit, hogy ideális esetben meg tudja mindazt és csakis azt jeleníteni, ami rá tartozik. Éppen ezért csak azt tudhatja pontosan a kliens, ami ő maga, így a predikció csak és kizárólag a saját mozgás esetében lehet pontos, bármi amibe más, interaktív objektum szerepel, már elvből elveszíti azt a lehetőséget, hogy őrá nézve predikciót lehessen alkalmazni.

Lag Kompenzáció

Tegyük fel, hogy egy játékos rálő a célpontra 10.5-kor. Az információ, hogy játékosunk megnyomta a tűz gombot, egy usercommandba fog megérkezni a szerverre. Miközben a csomag amiben ez a usercommand szerepel halad át a hálózaton, a szerver továbbra is folytatja a játék szimulációját, és a célpont elmozoghat egy másik pozícióba, és ezáltal mire a csomag 10.6-kor megérkezik a szerverre, a szerver nem lát találatot, holott játékosunk pontosan célzott. Ennek a hibának a kiküszöbölésére szolgál az sv_unlag 1 .

A lag kompenzációs rendszer emlékezik minden játékos pozíciójára kb. 1 másodpercig visszamenőleg (allítható az sv_maxunlag változóval). Amennyiben egy usercommand befut a szerverhez, a szerver a feldolgozásakor megbecsüli,hogy az adott parancs mikor keletkezett. Mindez az alábbiak alapján történik:

A parancs kiadásának időpontja = A szerver aktuális időpillanata - a kliens késése - a kliens interpolációja

Ebben az esetben a szerver a megadott számítás alapján visszahelyezi a szerveroldalon a játékosokat abba az időpozicióba, amikor a kliens oldali parancsot kiadták, és ez alapján ellenőrzi, hogy milyen következményei vannak az adott usercommandnak. Miután a usercommand lefutott, a szerver visszahelyezi az eredeti pozíciókba a játékosokat. A szerveroldalon, amennyiben nem dedikált szerverről, hanem ú.n. listen szerverről van szó, az sv_showimpacts 1 parancs segítségével megjeleníthetővé tehető a különbség a szerver oldali és a kliens oldali hitboxok helyzete között.

Ez a kép egy ilyen szerveren keszült 0.2 másodperces lag beállítással (használva a net_fakelag parancsot), a piros hitbox jelzi a célpont pozícióját a kliens oldalon 0.1 másodperccel ezelőtt. Azóta a célpont folytatta a bal irányú mozgást, de hála a beépített lagnak, ez az információ még "utazik a szerver és a kliens között". Miután a lövésre vonatkozó usercommand megérkezett, a szerver visszahelyezte a hitboxot abba a pozícióba, ahol lennie kéne (kék hitbox). A szerver leköveti a lövést, és nyugtázza a találatot (lásd vér). Az is jól látszik, hogy a kliens és a szerver hitboxok nem fedik egymást tökéletesen, de egész jó közelítés, figyelembe véve hogy a legkisebb eltérések is egy ilyen játékban a gyorsan mozgó modelleknél, centiméteres eltéréseket okozhatnak. A multiplayer játékok nem pixelpontosan jegyzik a találatokat, és a pontosság nagyban függ a tickrate-től és a célpont mozgási sebességétől. Mint azt már említettük, a magasabb tickrate növeli a találatérzékelés pontosságát, de majd minden erőforrás tekintetében többet is követel.

Joggal merül fel a kérdés; Miért olyan komplikált a szerver oldalon a találat észlelése? Sokkal egyszerűbb lenne a szervernek elküldeni a pozíciókat csupán, és minden mást a kliensre bízni, elérve ezzel a pixelpontosságú találatfelismerést. A kliens csak közölné a szerverrel amikor "találat"-ot vitt be, és megmondaná kit és hol ért a találat. Sajnos nem megengedhető, hogy ilyen fontos döntés kliens oldalon zajlódjon le, mert nem lehet bízni a kliensben. Még akkor is, ha a kliens "tiszta", és VAC fut rajta, a csomagok akkor is módosíthatóak egy köztes harmadik gép által. Ezen "cheat proxik" képesek lennének "találat"-okat csempészni a rajtuk áthaladó csomagokba, úgy hogy a VAC ezellen semmit nem tudna tenni. (nem mintha amúgy akármit is tenne a VAC. A szerk. meg.)

A hálózati késés és lag kompenzáció könnyen eredményezhet paradox, életszerűtlen szituációkat. Például találatot szenvedhet valaki, aki nem is látja az ellenfelet, mert az már takarásban volt. Ezek a hibák kijavíthatatlanok, mert a csomagok sebessége viszonylag lassú, és soha nem közelítheti meg a fény sebességét, (legalábbis a közeljövőben), és így az élethűség mindenképpen csorbát szenved.

NetGraph

A Source motor rengeteg lehetőséget és eszközt kínál, hogy a hálózati beállítások helyzetét ellenőrizni lehessen. Ezek közül a legnépszerűbb a netgraph, melynek több verziója is elérhető a játékban. Mi most a netgraph 2 paranccsal foglalkozunk. A beérkező csomagokat balról jobbra futó vonalak mutatják, és a magassága a vonalaknak a csomag méretére utalnak. Amennyiben szünet látszik a vonalak között, az nem értelmezhető, vagy elveszett csomagot jelent. Mindezek felett a vonalak színkóddal vannak ellátva, amelyek pedig a csomagot alkotó információ típusára utalnak.

A netgraph alatt az első sorban az fps, (másodpercenként megjelenített képkockák) az átlagos késés, és az updaterate, tehát a frissítés gyakorisága latható, a második sorban az utolsó megérkezett csomag mérete, az átlagos bejövő sávszélesség, és a másodpercenként átlagosan kapott csomagok száma látható. Míg a harmadikban, a szervernek küldött csomagokra vonatkozó információk láthatóak.

Forrás:CS2HU