A LoL és a "spagetti kód": Macgyver is feltűnik gyakrabban, mint gondolnátok -harmadik rész

Tegnap megtudtuk, hogy a Jarvan ulti miért áll minionokból, ma pedig elmeséljük, hogy hogyan is jön egy 80-as évekbeli sorozat főszereplője a Riot hibakezeléséhez.

Egyre többet tudunk meg a Riot hibakereséséről, hogy miként is kezelik ezeket, hogyan kategorizálják és mivel jellemzik őket. Tegnap például megtanultuk, hogy a Jarvan ulti és több más tereptárgy a játékon belül valójában láthatatlan minionokból áll, mivel nem tudnak máshogy egyelőre ilyet létrehozni. Ez is egy úgynevezett helyi hiányosság, vagyis Local Debt volt.

A LoL és a "spagetti kód": miért áll 8 év után is minionokból a Jarvan ulti?

Aioween | 18/04/12 15:08 A "spagetti kód" második részében a hibák típusaival foglalkozunk majd és megtudjuk azt is, hogy például Jarvan IV ultija miért minionokból épül fel valójában. Tegnap megnéztük, hogy milyen jellemzők alapján sorolják be az egyes hibákat a Riotnál, ezek voltak az Impact (hatás a játékra), Fix Cost (javítási költség, vagy inkább ár), és Contaignon (fertőzésveszély).

A mai napon pedig megtudjuk, hogy mit keres a játék hibái között MacGyver és amúgy is mi köze lehet neki a League of Legends-hez. Ez is egy megnevezett hiányosság, azaz debt a játékon belül, amit MacGyver Debt-nek neveznek. Ha nem is láttátok, de bizonyára hallottatok már MacGyverről, az ezermesterről, aki szinte bármilyen problémát meg tudott oldani egy svájci bicskával, vagy épp egy gémkapoccsal, attól függően, hogy milyen helyzetben volt.

Később ugyanezt a színészt láthattuk a Csillagkapu sorozatban is, -az sem ma volt. De visszatérve MacGyverre, róla köztudott hogy sokszor elsőre két teljesen különálló dolgot épített össze akár szigszalaggal, vagy bármi mással és így működésre bírta őket, ha azok a megfelelő pontokon csatlakoztak. A League of Legends-ben ezeket az építőelemeket képzeljük el a különféle rendszerekként, amik a játék egyes funkcióiért felelnek, legyen az a karakterek mozgása, viselkedése, képességhasználata, vagy úgy bármi, ami a pályán történik. LtRandolph Seattle városképével érzékeltette legjobban a jelenséget.

Így néz ki, amikor két majdhogynem teljesen különböző rendszer találkozik egymással. A kép alsó felén látható, hogy az épületek inkább téglalap alakúak, míg fentebb már mindenféle van, a kettő között pedig kitöltötték az űrt, amivel tudták. Ott van például az a háromszög alakú épület is, ami területkihasználás szempontjából nem feltétlenül a leghatékonyabb. De a lényeg, hogy sikerült összemosni a két részt, még akkor is, ha a találkozás nem éppen tökéletes.

A játékon belül ezt leginkább a kódolás szintjén kell elképzelni. Azt tudni kell, hogy ugyanúgy, ahogy a valós világban, a programozás világában is több nyelv –pontosabban programnyelv– létezik. Ezeknek mind megvannak a saját jellemzői, hogy milyen szabályok érvényesek rájuk, milyen szintaxisokat alkalmaznak és hogy egyáltalán miként működnek. Anno mikor elkezdték a LoL-t fejleszteni, a C++ std::string rendszerét használták, ám azóta a Riot is fejlesztett egy saját nyelvet, ami jobban kiszolgálja az igényeiket, ez egy egyedi AString class. Ám ez csak sokkal később jött létre, addigra a játék már bőven futott, így mindkét megoldásban van tartalom bőven, amik kezelik a karakterek stringjeit.

Ennek oka az volt, hogy idővel rájöttek, a C++ nagyon sok memóriát különít el magának "titokban", ez pedig negatívan érintette a játék teljesítményét. Többek közt jó eséllyel ennek is köszönhetjük azt, hogy ahogy halad előre a játék időben, egyre jobban csökken az FPS-ünk. Emellett a "titkos" funkció mellett könnyű belefutni abba a hibába, hogy "rossz" kódot írnak a fejlesztők. Az AString abban más, hogy sokkal tudatosabban lett felépítve a játék konkrét igényeit figyelembe véve. A terv, illetve a cél természetesen az, hogy előbb utóbb az összes std::string-et az AString-re cseréljék le, ám egy ekkora méretű játéknál ez hatalmas feladat lenne egyben. Éppen ezért csak folyamatában lehet megtenni, amikor valamihez amúgy is hozzá nyúlnak, illetve az új tartalmakat is már ebben gyártják.

Ezért kellett egy "MacGyver" megoldás, hogy ezt a két rendszert összeragasztják, hogy békében létezzenek egymás mellett, amíg szép lassan kivezetik a régi kódot és ezzel növelve a játék teljesítményét. Az AStringet ráadásul tovább optimalizálták a fejlesztők számára is, hogy könnyebb legyen dolgozni vele és végre elfelejtsék a C++ alapú dolgokat. Ennek az eredménye idővel az lesz, hogy az elavultabb megoldás teljesen el fog tűnni a játékból.

Impact: 2/5

A legtöbb nagy erőforrásokat igénylő std::stringek már ki lettek vezetve a játékból egy úgynevezett "profiling" metódussal, ahol megkeresték a legproblémásabb részeket és rendszereket. Elsősorban ezekre koncentrált a Riot Games, tehát a legnagyobb akadály úgymond már csak az, hogy ténylegesen erre az AString gondolkodásmódra álljon át mindenki és szép lassan átváltsák a régi rendszert az újra.

Fix Cost: 3/5

Ennek a munkának az "ára" relatíve elég nagy, mivel nem egy egyszerű "keresd meg és cseréld ki" metódusról beszélhetünk jelen esetben, elég ha csak abba gondolunk bele, hogy egy rossz kód és a játék alapfunkcióit is elronthatjuk ezzel. Ehhez még hozzátartozik az is, hogy az AString bizonyos esetekben kicsit máshogy viselkedik, illetve más célt szolgál, mint az std::string (AStackString például a kezdeti memóriaelkülönítésért felel, az ARefStrinf pedig statikus stringekre hivatkozik azon felül pedig a dinamikus memóriafoglalásért is felel). Az egésznek a nehéz része az, hogy ehhez egy hús-vér ember kell, aki ránéz a dologra és végrehajtja a változtatásokat, ezért tart ennyire sokáig ez az egész, mivel egy program ezt nem tudná elvégezni.

Conatgion: 2/5

Azáltal, hogy könnyebb dolgozni az AStringgel, mint az std::stringgel, a fertőzésveszélyt a saját előnyükre fordították. Minden alkalommal, ha megnéznek valamit és át is írnak ott egyes dolgokat, az AString jó eséllyel tovább terjed, mert már nagyrészt ebben dolgoznak.

A legnagyobb ára ennek a MacGyver hiányosságnak, hogy folyamatos odafigyelést és tudatosságot igényel a fejlesztőktől, amikor átlépik a határokat a két rendszer között. Ha van egy bug, vagy funkció, amit a rossz rendszer fog vissza, akkor a javítás alatt a cél az, hogy ezt nem csak javítják, hanem át is emelik az új rendszerben, vagy az AStringbe. Arra kell leginkább figyelni, hogy melyik rendszer fertőzőbb, a régi, vagy az új. Ha ezt fenn tudják tartani, hogy az új domináljon a régivel szemben, akkor előbb-utóbb az újabb és jobb rendszer fogja átvenni az "irányítást".

Mindig, amikor felmerül egy MacGyver hiányosság javítása, akkor arra kell figyelni, hogy a helyi rendszert tegyük inkább jobbá és kívánatosabbá, ezáltal szép lassan egy rendszerszintű pozitív hatása lesz az egésznek. Ha szorítja az idő a fejlesztőt és önző módon optimalizál a napi munkája során, hogy azt könnyebben végezhesse el, akkor jó irányba halad, hiszen abból mindenki profitálhat.

A másik megoldás, hogy erőszakosan kell nagy skálájú átírásokat eszközölni, attól függően, hogy ezek a rendszerek hogy működnek, de pár okos megoldással a legtöbb MacGyver hiányosság áthidalható.