A LoL és a "spagetti kód" -miként, vagy mi alapján javítja a Riot az egyes hibákat -első rész

A LoL egy roppant összetett program, több mint 400 000 programsorral és még számtalan alrendszerrel. Egy egyszerűnek tűnő probléma javítása is összetett lehet, a Riot betekintést adott, miként is működik ez.

A Riot Games legnagyobb és eddig egyetlen igazi alkotása, a League of Legends, egy nagyon összetett játék, rengeteg programsorral, egymásra épülő rendszerekkel, amiknek mi játékosok maximum egy részét látjuk ténylegesen, de a legtöbbünk valószínűleg fel sem fogja, mi folyik pontosan a háttérben, köztük én sem. Számtalanszor találkoztunk már a LoL kapcsán a spagetti kód meme-mel, ez leginkább akkor kerül elő, amikor egy hiba szemmel láthatóan "mérgezi" a játékot. Vandiril szokott ezekről leginkább videókat csinálni, de ő is maximum a jéghegy csúcsát tudja súrolni.

A hotfix után újra Irelia van a terítéken, de Vi sem marad érintetlen - PBE

Aioween | 18/04/11 09:38 Mielőtt beleugranánk a hősökbe, a PBE szerverekre most már bekerült a tegnap megmutatott MSI Baron kinézet, ami így néz ki. Szép lassan minden MSI tartalomra fény derül, a Baron is új kinézetet kapott, de a hősök sem maradhattak ki a mostani patch-ből. 40/55/70/85/100 helyett 60/70/80/90/100 mana.

LtRandolph írt erről egy elég velős anyagot, hogy miként is kezelik ezeket a hibákat, milyen kategóriákba sorolják őket és mi alapján határozzák meg az egyes hibák kijavításának szükségességét. Ő felel a hősöket érintő technikai háttérért. Az lehet, hogy kívülről az látszik, hogy a Riot egy roppant nagy és gazdag cég, de a programozói erőforrásaik nekik is végesek, amik egy ilyen méretű játéknál egyszerűen nem elegendőek arra, hogy minden hibát azonnal és véglegesen javítsanak. Angolul a fejlesztő egyszerűen tech debt-nek nevezte ezt a jelenséget, hívhatjuk ezt akár technikai elmaradásnak, vagy rövidebben hiányosságoknak.

Nézzük először a jellemző tulajdonságokat, ezeket a legegyszerűbb úgy felfogni, mint egy RPG-ben egy-egy karakter jellemzőit, legyen az erő, ügyesség, intelligencia, vagy épp karizma. Alapvetően három jellemzőt néznek minden egyes hibánál.

Az első az Impact, vagyis a hiba hatása a játékra. Mi játékosok leginkább ezzel szembesülünk, ha egy hiba nagyon feltűnő. Ezek lehetnek különféle bugok, hiányzó elemek, váratlan viselkedés, míg a fejlesztői oldalról ez leginkább a lassabb implementációban, munkafolyamatban és más apróbb dolgok figyelembevételénél jelenik meg. A fejlesztő itt bárki lehet, legyen az egy mérnökinformatikus, akit a kódolásban akadályoz, vagy a block designerek, akik a scripteket tervezik, vagy egy grafikus, aki nem tud emiatt új részecskéket tervezni.

A második jellemző a Fix Cost, vagyis egy javítás "ára". Ha rászánják magukat arra, hogy egy hibát kijavítanak, legyen az bármi, valakinek ez az idejébe fog kerülni. Ha egy mélyen fekvő gondról van szó, ami akár a játék összes programsorát érinti, akkor akár hetekbe, vagy hónapokba telhet a javítása, míg más problémák akár percek alatt is megoldhatóak. Függetlenül attól, hogy mennyi időt vesz igénybe, mindig figyelembe kell venni a javítás veszélyeit is. Még akkor is, ha egy rendszert hibásnak titulálnak, ugyanúgy lehet jó eszköz egy jó játék készítéséhez. Ha bármit megváltoztatnak a scripteknél, az könnyen további hibákat idézhet elő, hiszen több mint 500 képesség van a játékban és 140 karakter.

A harmadik és a fejlesztő szerint egyben legfontosabb jellemző a Contagion, vagyis fertőzésveszély. Mostanság leginkább erre figyel, ami egy ekkora méretű rendszernél érthető. Ha egy úgynevezett tech debt továbbra is létezik, a kérdés az, hogy mennyire fog tovább terjedni. A terjedés megfertőzhet más rendszereket, amik együtt működnek a hibás résszel, vagy azért, mert onnan másolnak ki bizonyos részeket, vagy attól függően, hogy a programozók egyes funkciókat miként építenek bele a játékba.

Ha egy tech debt jól el van szigetelve, akkor a javításának "költsége" később is ugyanannyi lesz, mint most. Azt kell megnézni, hogy az adott hiba az adott időben mekkora hatással van a játékra és mennyire szabadulhatnak el a dolgok, ha nem foglalkoznak vele. Ha egy hiba egy olyan rendszerben van, amivel sok másik dolgozik együtt könnyen kicsúszhat a kezeik közül és idővel csak egyre nehezebb lesz ezt javítani.

Cikksorozatunk következő részében a különféle hibatípusokkal foglalkozunk majd, hogy miként is kategorizálja az egyes hibákat, példákkal együtt, illetve milyen hatással vannak a játékra, és ezzel együtt persze ránk, a játékosokra is.