Námet čitateľa: Rád by som sa viac dozvedel o vývoji PC hier. Prečo sa niekedy v hrách stávajú neočakávané veci, keď je tam vlastne všetko naprogramované? Viac krát sa mi napríklad stalo, že som začal plávať a lietať pod zemou, že sa nepriatelia zasekli v dverách, aute a pod. Prečo k tomu dochádza? To sú programátori danej hry takí zlí alebo neskúsení, že toľko bugov a glitchov robia?
Ide o fascinujúcu problematiku. Bugmi, zádrhmi či všeobecne neočakávanými chybami netrpia len hry. Týkajú sa akéhokoľvek softvéru, vrátane operačných systémov.
Ich výskyt nemôžeme len zhrnúť vetou, že ľudia sú skrátka omylní a preto nevyhnutne dochádza pri tvorbe hier ku chybám. Takáto samozrejmá odpoveď by vám totiž tento svet nijako nepriblížila a vôbec by vám neozrejmila podstatu celej problematiky. Skutočné jadro tohto problému sa totiž týka nielen softvéru, ale takisto aj napríklad navrhovanie zákonov, zmlúv či tvorby pravidiel nejakého športu.
Správny chlap si pri hraní Assassin’s Creed musí vždy zachovať svoju tvár
Ako prvé zahoďte častú chybnú predstavu, že bugy sú nejaké preklepy v zdrojovom kóde. Nejde o to, že by niekto napísal „doľava“ namiesto „doprava“, zabudol na nejaké interpunkčné znamienko, alebo že by „stlačil zlé tlačidlo“. Bug v hre je obvykle spôsobený tým, že nastane nejaká situácia, pri ktorej programátor nepredpokladal, že vôbec môže nastať.
Ukážme si to na jednoduchom príklade, v ktorom ste majiteľom firmy s mnohými zamestnancami, pričom vás začne trápiť, že nemáte žiadneho vrátnika a do vašej budovy môže v pracovnej dobe vojsť ktokoľvek. Nainštalujete teda na dvere elektronický zámok a každému zamestnancovi dáte prístupovú kartu, ktorou si pípne pri vstupe.
Všetko funguje dobre a po čase vás napadne, že by ste toto pípanie mohli využiť aj na monitoring dochádzky. Vytvoríte teda malý program, ktorý preberie dáta z toho, kedy si kto dvere kartou otvoril a zobrazí vám absencie. Ihneď si všimnete, že jeden zo zamestnancov už týždeň neprišiel do práce. Kontaktujete ho, nech vám vysvetlí prečo, ale zisťujete, že v práci práve sedí, pričom vehementne tvrdí, že do nej chodil celý týždeň a jeho spolupracovníci to dosvedčia.
Problémom bolo, že ho do práce vozí autom kolega. Do budovy teda vždy prichádzajú spolu, kolega svojou kartou otvorí dvere a obaja vojdú dnu. Ako vidíte, váš dochádzkový program obsahuje chybu – bug. Nie preto, že by ste urobili preklep v kóde. Nie preto, že by váš existujúci kód bol nesprávny a nerobil to čo má. Skrátka ste len zabudli počítať s jednou zvláštnou situáciou, ktorá nastáva.
Vykonáte teda nápravu a nakážete zamestnancom, že do dverí musia vchádzať len po jednom a každý musí povinne kartou pípnuť pri príchode aj odchode. Považujete to tým za vyriešené. Bug je opravený a ku chybným počtom už nemôže dôjsť. Ale ejha. Za mesiac sa pozeráte na štatistiku príchodov aj odchodov, pričom si všimnete veľmi čudnej veci. Niektorí zamestnanci do firmy prišli viac krát, než z nej odišli. Neveriacky sa na to pozeráte a nechápete, ako k tomu mohlo dôjsť. Previnilcov sa pýtate, čo to stvárajú a ako je to možné, ale oni o ničom nevedia a tvrdia, že kartou pípajú tak, ako bolo nakázané.
Sadnete si teda k bezpečnostným kamerám a začnete si prehrávať záznamy z posledného mesiaca. Všimnete si pritom, ako jedného dňa príde jeden zo zamestnancov k dverám, pípnutím si ich otvorí, ale uprostred nich si zrazu buchne dlaňou do čela a beží preč. O minútu neskôr ho vidíte prichádzať znova s taškou v ruke, ktorú si zrejme zabudol v aute. Dvere si pípnutím karty otvorí a vojde dnu. Problémom je, že podľa vášho systému vošiel do budovy už dvakrát, bez toho aby z nej odišiel.
Výsledkom je vznik bugu vo vašom dochádzkovom programe. Zamestnanec neurobil žiadnu chybu. Robil to, čo ste mu nakázali. Nemohol si ale „pípnuť odchod“, pretože do budovy nikdy nevošiel. Vy ako tvorca programu ste skrátka nepočítali s tým, že akt otvorenia dverí nemusí vždy znamenať, že zamestnanec nimi do budovy aj naozaj vojde.
Tieto dva príklady slúžia na ilustráciu toho, že aj pri tak triviálnom programe, slúžiacom na tak triviálnu úlohu je veľmi jednoduché zabudnúť na nejakú špecifickú situáciu.
Moderné hry či iné programy sú pritom mnohonásobne komplexnejšie a riešia obrovské množstvo stavov. Nie je teda ťažké si domyslieť, že k podobným situáciám prakticky nevyhnutne dôjde.
AKO HERNÉ BUGY NAOZAJ TECHNICKY VYZERAJÚ?
Hra je podobne ako iný softvér tvorená zdrojovým kódom, ktorý sa dá vnímať ako súprava zákonitostí, čo a ako sa kedy má stať. Bug teda nie je žiadna zámena „jednotky, za nulu“, ale práve neprítomnosť alebo neaktívnosť nejakej zákonitosti.
Typickým prípadom reálneho bugu je, že programátor vytvorí mechanizmus, ktorý predpokladá dorazenie kladného čísla, ale z nejakého dôvodu do neho náhle dorazí záporné. Keďže jednotlivé časti kódu si možno predstaviť ako súčiastky stroja, ktoré na seba reagujú, dochádza k vzniku situácie, pre ktorú chýba vytvorená zákonitosť a celý stroj zareaguje neočakávane.
Toto neočakávané správanie môže mať napríklad podobu tzv. „integer overflow“, čo sa dá voľne preložiť ako pretečenie či preplnenie čísla. Reálny prípad z praxe je legendárny bug z prvej hry Civilization.
V tejto hre sa staviate do pozície vodcu impéria, ktoré má prežiť tisícročia, pričom riešite medzinárodné a diplomatické vzťahy vznikajúce v priebehu času. Každý vládca impéria či štátu mal na pozadí nastavenú mieru agresie, na stupnici 0 až 255, ktorá určovala pravdepodobnosť naštartovania vojnového konfliktu podľa druhu konkrétnej provokácie.
Ako sa dá predpokladať, diktátori z rôznych autoritatívnych štátov ju mali skryte nastavenú veľkú, napríklad na číslo 80, iní miernejší vodcovia napríklad na hodnotu 10 či 20. Vodca Indov, ktorým bol Mahátmá Gándhí, ju mal ako pacifista nastavenú na veľmi malú hodnotu, konkrétne na číslo 1. Z pohľadu hráča tak bol Gándhí veľmi mierumilovný a prakticky žiadna akcia ho nevyprovokovala.
Problémom bolo, že ako hra postupovala jednotlivými dekádami až k modernej ére, štáty začali prechádzať na demokratické systémy. Tento akt mal za následok, že jednotlivé hlavy štátov znížili mieru svojej agresie o -2 body. Kým u bežných vodcov teda došlo k zníženiu agresie napríklad na 18 bodov (20 – 2), u Gándhího, ktorý mal toto číslo maličké, došlo k vzniku zápornej hodnoty (1 – 2 = -1). Ak by bolo v hre na to myslené, hodnota „-1“ by jednoducho znamenala nulovú hodnotu agresie. Avšak vzhľadom na to, že programátor pri tvorbe s niečím takým nepočítal, došlo k vzniku bugu.
Hra používala stupnicu 0 až 255 a namiesto negatívnej hodnoty -1 sa premenná preklopila na stupnici na 255. To z Gándhího spravilo extrémneho agresora, najviac ako to len bolo možné, čo viedlo do komickej situácie, kde na konci hry aj pri tej najmenšej provokácii všetkých vybombardoval nukleárnymi hlavicami.
Na tomto mieste sa môžete právoplatne opýtať, ako sa to vôbec mohlo stať. Čo ten programátor nevidel, že číslo Gándhího klesá do zápornej hodnoty? Prečo to nespravil tak, aby číselný mechanizmus s takýmto vstupom počítal?
Hra je však rozsiahlym projektom, ktorý tvorí mnoho ľudí, pričom v priebehu času sa menia oblasti, na ktorých sa aktívne pracuje. Tento číselný mechanizmus bol nepochybne vytváraný v úplnom počiatku vývoja, pričom v tom čase hra mohla byť navrhovaná napríklad tak, že žiadne odčítavanie hodnoty agresie ani nebolo možné. Bola nastavená na trvalo a hotovo. Až neskôr sa v rámci vývoja a ladenia mohol vytvoriť mechanizmus, ktorý mieru agresie znižoval.
Alternatívne mohlo byť odčítanie pôvodne len na úrovni -1 a keďže najmenej agresívny Gándhí mal hodnotu 1, došlo vždy len k vytvoreniu 0 a bug sa nikdy neprejavil. Až neskôr sa rozhodlo, že sa bude znižovať o dva body, pričom aplikovanie tejto zmeny na prvý pohľad ani nič zlé neprinieslo (bug sa totiž zo svojej podstaty prejavoval až v úplnom závere hry, nie kedykoľvek).
Kufrový pes v hre Fallout 4
Inou a takisto extrémne častou kategóriou sú tzv. kolízne bugy. Ide o prípady, kedy hra reaguje v určitej situácii zle na kolíziu, respektíve kontakt dvoch objektov. Výsledkom je, že sa napríklad hráč prepadne cez podlahu, niečo sa zasekne vo dverách, alebo sa objekt komicky zachytí na hlave postavy, ako vidieť na obrázku vyššie.
Obvyklou príčinou tohto stavu je to, že sa z nečakaného dôvodu nejaké úlohy, kontroly či výpočty vykonajú v nežiaducom poradí, čím vytvoria nechcený koncový stav.
Prakticky každý hra má naprogramovaný nejaký systém pohybu, ktorý zaručuje, že herná postavička sa hýbe dopredu či dozadu podľa toho, ktoré tlačidlo držíte stlačené. To sa kombinuje s kolíznym systémom, ktorý zaručí, že sa pohyb postavičky zastaví, keď sa objaví na úrovni steny či inej prekážky (aj napriek tomu, že tlačidlo pohybu držíte stále stlačené).
Programátor teda naprogramuje nejakú logiku, ktorá sa bude o to starať. Typicky môže vyzerať takto:
- hráč stlačil tlačidlo doľava
- skontroluj, či na pozícii vľavo nie je objekt
- ak áno, stoj
- ak nie, pohni postavičku doľava.
Ide o veľmi jednoduchý princíp a ak ho programátor otestuje, zistí, že sa správa tak ako očakáva. Postavička, ako je napríklad Mário, beží doprava a v okamihu ako príde na úroveň steny či rúry, zastaví sa.
Tento systém programátor následne doplní o logiku kolízie s podlahou, ktorá bude neustále kontrolovať či postavička stojí na zemi, alebo nabehla na dieru, pričom ak je to ten druhý prípad, vytvorí jednoduchý fyzikálny systém, simulujúci gravitáciu a zachovanie hybnosti. Výsledkom je, že ak Mário za behu „príde o pôdu pod nohami“, začne našikmo padať dolu.
Objavuje sa ale problém.
To, že Mário padá šikmo smerom dole má za následok to, že systém kontrolujúci smer a kolíziu povie „vpravo voľný pixel – môžeš sa hýbať doprava,“ pričom Máriova noha sa v určitý moment ocitne kúsok zaborená v stene, ktorá sa z dôvodu šikmého letu ocitne pod ním skôr ako vpravo.
Kolízny systém na to myslí a logika hry je vytvorená tak, že ak sa postavička nachádza už kúsok v stene, systém ju z nej vytlačí von do opačného smeru. Všetko je teda v poriadku. Mário do steny nevošiel. Lenže skôr ako sa táto logika vykoná, je spustená logika, ktorá kontroluje, či Mário nenarazí na podlahu. Toto poradie operácii vytvorí relatívne neškodný bug, ktorý Máriovi umožňuje „dvojskok“, čo môžete vidieť tu:
Na maličký okamih, kedy je Mário nohou v stene/zelenej rúre, logika hlási, že je na podlahe (pod jeho nohou sa totiž nachádza pixel pevného objektu), takže než kolízny systém Mária vytlačí zo steny von, môže hráč v malom časovom okne vykonať skok.
Oproti relatívne primitívnemu Super Máriovi majú moderné 3D hry fyzikálne systémy ohromne komplexné a simulujú správanie objektov skutočne veľmi dobre. Bezvládne telá zastrelených nepriateľov padajú dole skaliskom, či vypadávajú z okna, postavu hráča odhadzuje explózia či auto, ktoré do neho v rýchlosti narazí.
Fyzikálny systém je dnes často samostatná časť kódu, ktorú tvorí niekto iný a herné štúdio ho do hry len integruje (takýmito systémami sú napríklad PhysX, Havoc či Bullet). Následne tento systém spolupracuje s mechanizmami na pohyb a kolíziu.
A tu práve môže dôjsť k nesprávnemu poradiu vykonávania operácii a k vzniku bugu. Fyzikálny systém funguje napríklad tak, že zoberie vstupnú silu pôsobenia na konkrétny objekt (napr. explózia, odkopnutie, či pád) a vypočíta, kam sa má pod jej vplyvom objekt pohnúť. Následne podľa výsledku objektom pohne na danú lokalitu. Kolízny systém kontroluje, kde sa objekt nachádza a nenechá ho vojsť napríklad do steny či iného objektu.
Ak sa ale pre daný snímok (frame) vykoná kontrola kolízie skôr, ako presun, objekt sa dostáva do vnútra iného objektu. Čo sa stane v nasledujúcim snímku? Nuž, obvykle je na to vytvorená logika „vytlač ho zo steny von“, čo sa obvykle stane v nasledujúcom snímku, takže si to ani nevšimnete (pretože sa ich v jednej sekunde spraví napr. 60).
Čo ak sa ale objekt dostane do steny naskrz a jeho automatické tlačenie von znamená, že druhá polovica objektu do steny vchádza a nie vychádza? Nuž, bug je na svete, pričom ho vidíte demonštrovaný na tomto krátkom videu z hry The Elder Scrolls IV: Oblivion.
V hre za bežných podmienok objekt do steny nevojde. Mŕtvolu môžete pohadzovať smerom k stene či dverám a odrazí sa od nich, pretože kolízny systém prechodu zabráni. Ako ale môžete vidieť, na jednu vec sa zabudlo. Dvere majú zabudovanú jednoduchú logiku zavretia, ktorá nič nekontroluje, pričom akceleruje bezvládne telo do rýchlosti (spracované fyzikálnym systémom), ktorá ho v jenom snímku pretlačí do steny rýchlejšie, než kolízny systém zareaguje.
V nasledujúcich snímkach sa ho snaží kolízny systém z objektu vytlačiť do protismeru, problémom ale je, že telo je skrz, takže vytláčaním zo steny/dverí zas iné časti tela do steny naopak vchádzajú (z opačného smeru) a systém ho vytláča zas opačne. To spôsobuje to komické trasenie, ako sa systém snaží zúfalo s týmto nečakaným stavom popasovať.
S týmito komplikáciami súvisí aj relatívne častý herný bug známy ako „prepadnutie podlahou“, pri ktorom sa hráč akoby teleportuje do alternatívnej reality za zrkadlom.
Objekty v hre, vrátane stien a podlahy, nie sú celistvé kusy tak ako vo fyzickom svete. Sú ako papierové modely z časopisu ABC, tvorené tenučkými vrstvičkami, za ktorými nič je nič. Kolízny systém sa snaží len v prechodu cez túto vrstvu zabrániť.
Ak napríklad niekde v komplikovanom teréne kúsoček vrstvy chýba (pri obrovskom množstve uhlov ju nie je jednoduché počítať bez akýchkoľvek nedostatkov), alebo vás za ňu presunie fyzikálny systém po tom, ako sa pre daný snímok už kolízia vypočítala, vaša postava sa skrátka ocitne za ňou a je hotovo.
Ak s tým žiadna logika nepočíta a nevráti vás späť, hra nevie ako na to má reagovať a zareaguje skrátka logikou, ktorá je prítomná – spustí sa animácia padania a fyzikálny systém vás tlačí smerom dole, pretože je hlásené, že nemáte „pôdu“ pod nohami.
Ak na to programátor celkom zabudol. Budete padať naveky. Môže sa ale prirodzene aktivovať iný systém (vytvorený pre iný účel), ktorý vás pred nekonečným pádom zachráni napríklad tým, že postavu zabije pri nejakej konkrétnej dĺžke pádu z hľadiska času, alebo vyvolá znovu načítanie kontrolného bodu či posledného uloženia, pretože ste sa príliš vzdialili od cieľového objektu z misie a podobne.
Tu môžete behom pár sekúnd vidieť, ako ľahko vznikajú nežiaduce diery cez ktoré môžete prepadnúť, pri tvorbe jaskyne v hre Skyrim. Je nutné ich pozorne vždy zaplátať textúrami kameňov či iných objektov. Celý nezrýchlený proces môžete vidieť na tomto videu.
PREČO MAJÚ DNEŠNÉ HRY VIAC BUGOV AKO TIE STARÉ?
Aj v relatívne jednoduchých hrách, ktoré tvorí jediný človek, je nesmierne ťažké mať kompletný prehľad o všetkých možných mechanikách a stavoch, ktoré môžu nastať.
Čím komplexnejší programový kód je, tým viac naviazaností existuje a tým väčší problém je odhadnúť dôsledky aj malých zmien. Postupné dopĺňanie a rozširovanie funkcií sa tak prejavuje na inom správaní tých predchádzajúcich.
Moderné pokročilé hry tvoria desiatky až stovky programátorov, pričom využívajú často časti kódu, prenášaných z iných projektov od iných ľudí.
Vývojári hry Assassin’s Creed Odyssey /Foto: Ubisoft/
Je pravdou, že dnešné hry majú viac bugov, ako tie z prelomov storočí. Nie je to ale zapríčinené tým, že by dnes vývojári boli horší ako v minulosti. Viac bugov je predovšetkým dôsledkom zvyšujúcej sa komplexnosti hier.
Ak sa pozriete na hry ako Tetris alebo Super Mário, množstvo kódu a zákonitostí vyzerá celkom smiešne v porovnaní so súčasnými hrámi ako Fallout 4, GTA V či Witcher 3.
Kým v počiatkoch herného biznisu mávali hry niekoľko tisíc či niekoľko desiatok tisíc riadkov kódu, dnes ich má len samotný použitý herný systém, ako napríklad Unreal Engine, viac ako 2 milióny.
K tomu sa priráta kód ktorý je špeciálne navrhnutý na konkrétnu hru a pridružené knižnice pre rôzne herné platformy, výsledkom čoho súčasné komplexné hry s rozsiahlym svetom, ako napríklad tie zo série Assassin’s Creed, majú niekoľko desiatok miliónov riadkov zdrojového kódu.
Aj keď veľká časť kódu sa nepoužíva súčasne a je napríklad len súčasťou nejakých knižníc, z ktorých sa berie len nejaká jedna konkrétna funkcia, možnosti vzniku bugov a vzájomných nepredpokladateľných kolízií je enormná.
Vzhľadom na veľkosť súčasných vývojových tímov moderných hier už konkrétny programátor nemá všeobecný prehľad o tom, aké naviazanosti na kód ktorý vytvára sú alebo budú. Ak teda pridáva novú vlastnosť či opravuje nejaký nájdený bug, nikdy dopredu nemôže s istotou vedieť, že použitá zmena nevytvorí nejaký nový bug.
Veselý bug z hry Spiderman, zapríčinený tým, že animácia kotrmelca sa vykonala skôr, ako kolízny systém zareagoval na vodnú hladinu
Existencia bugov je vždy očakávaná a v priebehu vývoja hry či iného softvéru ich programátori a testeri nachádzajú a neustále opravujú.
Každá vývojárske štúdio má veľký zástup testerov, ktorí hru v priebehu vývoja nonstop hrajú/používajú a skrátka testujú rôznymi možnými spôsobmi a hľadajú čo možno najviac bugov. Nikdy však nemôžu nájsť všetko. Počet variant a rôznych situácií, ktoré môžu v moderných hrách nastať, je prakticky nekonečný.
Hra sa napokon vždy jedného dňa musí vydať a je preto nevyhnutné, že hráči následne v hre odhalia nové bugy, ktoré bude nutné opraviť formou aktualizácií.
Je jedno koľko by herné štúdio pred vydaním hru testovalo. Desať či sto testerov, pracujúcich hoc aj 24 hodín denne sa skrátka nevyrovná tomu, keď ju začne hrať napr. 10 miliónov ľudí, ktorí si ju zakúpia v prvý deň predajov (čo je pri vrcholových tituloch bežné).
Ak ju následne hrajú napríklad 4 hodiny, ide o 40 miliónov herných hodín, teda 4566 odohraných rokov (24 hodín denne). Je jasné, že dvadsaťčlenný tím testerov danej firmy, ktorí hru testoval posledných pár mesiacov, sa tomu ani nepriblížil. To čo zákazníci odohrajú za deň, by dvadsať členný tým testerov odohral za 200 rokov.
Keď sa na to pozeráte z tejto stránky, nie je už tak prekvapivé, že hráči nájdu krátko po uvedení hier veľa bugov a vytvárajú rôzne zábavné YouTube videá, kde sa z nich smejú a poukazujú v nich na neschopnosť herných vývojárov.
Fyzické herné nosiče v podobe kaziet /Foto: 16bitten/
Celkom bežne sa dá stretnúť s nie príliš relevantným argumentom, že firmy sú už pri testovaní ľahkovážnejšie ako v minulosti, pretože majú ľahkú možnosť chyby opravovať.
V minulosti sa hry distribuovali na fyzických médiách, ako kazety a CD, takže ak sa hra takto vylisovala a rozposlala do obchodov, bolo hotovo a chyby tam boli už prakticky navždy. Firmy si teda dali extrémny pozor, aby im nejaká neprekĺzla.
S nástupom rýchleho internetu a digitálnej distribúcie sa však situácia zmenila a herné štúdia majú možnosť hru dodatočne opravovať hoc aj každý deň. Láka teda povedať, že skrátka už ich nič nenúti testovať tak pozorne, pretože nájdenú chybu rýchlo dodatočne opravia prakticky bez distribučných nákladov.
Tento argument je v základe pravdivý a koniec koncov sa uplatňuje napríklad aj v médiách, pri porovnaní tlačených a webových článkov. Nedajte sa ním však príliš ovplyvniť. Aj tieto hry vždy nejaké bugy obsahovali, pričom rozdiel v objeme v porovnaní s tými dnešnými je naozaj spôsobený hlavne zvýšenou komplexnosťou a nutnou veľkosťou dnešných vývojových tímov.
U špičkových titulov už dávno hru netvorí hŕstka vševedkovských programátorov a grafikov. Moderné vývojové tímy dnes potrebujú zástup špecialistov na vývoj herných enginov, zástup grafikov na 3D modely, grafikov na textúry a animátorov na realistický pohyb postáv a iných objektov.
Potrebujú ľudí na dizajn levelov a lokalít, zvukových inžinierov, špecialistov na hernú fyziku, inžinierov osvetlenia scén, špecialistov na portovanie hier pre rôzne platformy (Windows, Playstation či Xbox). Mnoho vecí je tak komplexných, že už do tímu musia byť najatí aj úzky špecialisti na jednu konkrétnu vec, ako napríklad pohybové ovládanie, VR rozhranie, procedurálne generovanie obsahu či fyziku konkrétnych prvkov, ako oblečenia a vlasov.
Nečakané zjavenie lietajúceho kôňa Pegasa v hre Witcher 3
Komplexnosť herných projektov stúpla za posledné tri dekády natoľko, že konkrétny vývojár už skrátka nemôže „vedieť všetko“ a o vývoj hry sa tak stará veľký tím, kde je každý expertom už len na nejakú malú časť celku. Hry sú navyše mierne odlišné od iných druhov softvéru, vďaka čomu sú prirodzene na vznik chýb náchylnejšie. V mnohých druhoch softvéru sa akcie programujú tak, že dochádza k nejakej priamo vytvorenej konkrétnej činnosti na akciu používateľa. Pokročilé hry simulujúce reálny svet ale fungujú celkom inak. V moderných rozsiahlych hrách je nemožné vytvoriť inštrukciu na každú možnú situáciu, pretože ich prakticky existuje nekonečné množstvo.
Programovanie takýchto všeobecných pravidiel umožňuje, že sme takéto hry vôbec schopný spraviť. Tieto všeobecné pravidlá však v špecifických prípadoch spôsobia problémy a obvykle naň prídeme až vtedy, keď sa stanú.
Obvyklá a relatívne správna poznámka k tejto problematike je, že niektoré vývojárske štúdiá majú značne menej bugov v hrách, ako iné. Láka teda znovu povedať, že niektoré sú viac zodpovednejšie ako iné a venujú testovaniu viac času.
Tu je ale vhodné upozorniť na problém zvyšujúcej sa finančnej náročnosti. Na začiatku 21. storočia stál vývoj tých najšpičkovejších herných titulov okolo 10 miliónov dolárov. V súčasnosti je to viac ako 100 miliónov dolárov, pričom to sú nálady len na vývoj hry ako takej.
Veľké herné spoločnosti následne investujú 100 až 200% tohto objemu do marketingu. V prípade GTA V šlo o 137 miliónov dolárov na vývoj a 128 miliónov na marketing, v prípade Call of Duty: Modern Warfare 2 šlo o 50 miliónov dolárov na vývoj a 200 miliónov na marketing.
To všetko je naviazané na prácu pokojne aj 10 000 ľudí, ktoré veľké štúdiá zamestnávajú, pričom sa venujú predajom, lokalizácam a iným záležitostiam. Všetko to pripomína naolejovaný stroj, vďaka čomu napr. Ubisoft môže masívne veľké tituly (ako Assassin’s Creed Origins, Watch Dog 2, Assassin’s Creed Odyssey či Far Cry 5) vydávať v relatívne v krátkom čase jedného roku (vyvíja ich viacero nezávislých tímov).
Býval som dobrodruh ako ty, ale potom som stratil hlavu (Skyrim)
Ak sa všetko podarí, tržby sa pohybujú v miliardách dolárov. Riziko neúspechu je však pri takýchto obrovských sumách masívne a je jasné, že v okamihu ako sa napríklad rozbehne nejaká trojmesačná stámiliónová reklamná kampaň, nasmerovaná na konkrétny dátum, následne už nie je možné hru posúvať a oneskorovať jej vydanie, len preto že včera testeri našli nejaké ďalšie dve chyby. Najmä ak sa v minulosti preukázalo, že bugy predaje nijako vážne neznižujú.
Menšie vývojárske a herné štúdia o takýchto cifrách ani nechyrovali a z ich pohľadu teda nie je až tak problematické oznámiť, že sa hra vydá „keď bude pripravená“, pričom sa posúva pokojne aj o niekoľko mesiacov či rokov. Výsledkom pravdaže je, že sa im o tržbách v miliardách dolárov nemôže ani snívať.
PREČO NIEKTORÉ BUGY ZOSTÁVAJÚ V HRÁCH NAVŽDY NEOPRAVENÉ?
Každé vývojárske štúdio prevádzkuje databázu bugov, ktoré boli v priebehu vývoja a testovania hry odhalené a priraďuje k nim programátorov, ktorý ich majú opraviť. Databáza bugov veľkých hier obsahuje tisíce či desiatky tisíc rôznych chýb najrôznejšieho charakteru, pričom prednosť dostávajú tie najvážnejšie, ktoré by ideálne mali byť opravené do vydania hry.
Oprava však nie je vždy jednoduchá. Nejde len o to, že programátor musí zistiť, čím je vlastne bug zapríčinený a nežiadúci stav nejako odstrániť. Oprava musí byť aj otestovaná na rôznych platformách a na rôznom hardvéri, aby sa zistilo či vôbec funguje všade a či nespôsobuje iný problém a iný bug v nejakej inej situácii a inej časti hry.
Hra sa napokon vydáva a obrovský objem hráčov, ktorí hru začnú hrať, nevyhnutne odhalia nové bugy. Vývojárske štúdia pokračujú mnoho týždňov a mesiacov v ich opravovaní a postupne vydávajú aktualizácie, ktoré ich zaplátajú. Aj tu majú prednosť tie najvážnejšie bugy, ktoré sú obvykle veľmi promptne riešené, pretože krátko po vydaní na hre ešte pracuje veľká časť programátorského tímu.
Typický vážny bug je taký, ktorý hráčovi zabráni v hernom postupe. Ak sa napríklad po získaní nejakého predmetu majú otvoriť dvere, ktoré vpustia hráča do ďalšieho levelu a v nejaký moment sa tak nestane a hráč zostane na danom mieste naveky zaseknutý, označuje sa to ako stop bug a je to chyba ktorú treba promptne vyriešiť a opraviť. Najmä ak sa stane napríklad 10 či 20 % hráčom. Iné vážne bugy sa týkajú napríklad nefunkčného ukladania alebo náhlych aplikačných pádov.
Naproti tomu kozmetický bug, ktorý napríklad v 1 % prípadov zapríčiní, že spadnutá zbraň zastreleného vojaka zostane visieť vo vzduchu, alebo že mŕtvola zostane spolovice nad priepasťou, popierajúc tak zákony fyziky, je malého významu. Kazí síce grafický dojem z hry, ale ak sa objaví len raritne a hráč sa nad nimi len pousmeje a za sekundu sa už pozerá inam, nemá jeho oprava prioritu.
V nadchádzajúcich mesiacoch po vydaní hry vývojári opravujú najvážnejšie nové odhalené bugy a postupne sa dostávajú k tým menej vážnym. Nikdy sa ale nestane, že by hra bola kompletne bez bugov a je jedno, koľko ju budú vývojári zaplátať. Hráči totiž budú nachádzať stále nové a nové, pričom nie je nič nezvyčajné, že sa v nejakej hre nájdu dovtedy neznáme bugy aj 10 či 15 rokov po jej vydaní, ako sa nedávno stalo napríklad pri hre GTA: Vice City (bug umožňoval preskočiť veľkú časť herného deja).
V určitý moment po vydaní hry už teda prestáva byť ekonomicky únosné bugy opravovať. Nikdy totiž neopravíte všetky a vždy sa objavia nejaké nové. Ak sú ale tie známe už len „otravné“, nezasahujú príliš do hry a stanú sa len vo veľmi raritných prípadoch, ich oprava nemá zmysel.
Opravy stoja čas aj peniaze (niekto tú prácu musí zaplatiť) a ak už hra negeneruje financie kontinuálne (čo je prípad on-line hier), jedného dňa sa skrátka projekt a podpora hry musí ukončiť. Programátori odchádzajú pracovať na iných projektoch a hra je naveky ponechaná v poslednom stave.
Preboha živého neodpájajte ten ovládač. Bolí ma z toho za krkom.
Ak ste na herné štúdio nahnevaný, že už hru opustili, keď ešte neopravili nejaký otravný bug a neveky ho v hre nechali, nemusí to byť len prípad, že ho ignorovali pre malú vážnosť. Môže ísť aj o situáciu, že nejaký bug je pomerne nepríjemný a dobre identifikovaný, ale jeho oprava by si vyžiadala obrovský zásah do kľúčových častí kódu a prepis jeho veľkej časti.
Mnoho mesiacov či rokov po vydaní už je takýto zásah nemožný, pretože ak by si nové vytvorenie alternatívneho kódu vyžiadalo stovky či tisíce hodín vývojárskej práce, už ju nemá čo zaplatiť.
Navyše pri tom hrozí veľké riziko, že nový obrovský zásah by priniesol vznik nových iných vážnych bugov a tie už by nemal v budúcnosti kto opravovať. Niektoré bugy tak v hre zostávajú preto, že ich oprava je skrátka priveľkým rizikom a je lepšie zostať pri tom známom a nevýznamnom kozmetickom bugu, ako riskovať vznik ďalších.
A to je tak povediac celý príbeh. Zdrojový kód moderných 3D hier je obrovsky komplexný program, simulujúci „svet“. Rôzne jeho časti píšu rôzni ľudia a vzájomné interakcie kódu môže vždy priniesť nečakané problémy a kolízie. V moderných hrách je skrátka už príliš veľa premenných a závislostí, ktoré sa môžu pokaziť a je fyzicky nemožné, aby programátori mysleli na každú možnosť, pretože ich je skrátka prakticky nekonečný počet.
A to sú dôvody, prečo hry obsahujú bugy a prečo sa ich nikdy nezabavíme.
Prečítajte si aj ďalšie články zo seriálu Čo je prečo tak.
 |  |  |
|---|---|---|
 |  |  |
