V herním vývoji se každá koruna obrací třikrát – s Jakubem Hamarim o herním testingu, práci v herní branži a průmyslu jako takovém
Seznam kapitol
Rozporuplné vydání Cyberpunku v prosinci minulého roku vyvolalo (nejen) v herních kuloárech poměrně vášnivé diskuse ohledně neuspokojivého technického stavu dnešních her. Při hledání viníků pak spočinuly prsty mnohých i na herních testerech. Co pojem „herní testing“ rámcově obnáší jsem se již pokoušel objasnit ve shrnovacím článku – cítil jsem však, že k opravdové analýze situace bude potřeba člověka tzv. „od fochu“. Obrátil jsem se tedy na Jakuba Hamariho, který po mnohaleté praxi v softwarovém testingu v současnosti zastává pozici technického designéra na velmi úspěšném projektu Vigor v českém studiu Bohemia Interactive. Jakub mě v brněnském sídle „Bohemky“ mimo skvělé horké čokolády uvítal i ve své typicky ukecané náladě, čímž jsme položili základ pravděpodobně nejdelšímu rozhovoru, který jste kdy četli. Jak opravdu vypadá práce herního testera, jací lidi pracují v herním průmyslu a co si Jakub myslí o filmech Zdeňka Trošky? To a mnohem více se dozvíte na následujících řádcích…
Hrej.cz: Dovedl bys popsat rozdíly mezi softwarovým a herním testingem?
Jakub Hamari: Oproti klasickému softwarovému testingu je obrovský rozdíl ve struktuře testů. Dělat testy krok za krokem pro gameplay může být docela oříšek, protože je těžké izolovat všechny faktory, které se dějí všude okolo. A obrovský rozdíl je samozřejmě v tom, že většina běžného testingu probíhá ve 2D. Pokud pracuješ na 3D projektu, tak je až neuvěřitelné, co všechno musíš brát do úvahy. Když testuješ stránky v internetovém prohlížeči, nemusíš zpravidla řešit gravitaci, nezajímají tě ambientní okolní zvuky. Někdo by mohl namítat, že když klikneš na tlačítko, tak se třeba dočkáš nějakého zvuku – ano, podobnosti tam jsou, ostatně je to stále testing. Pořád testujeme komponenty, testuje se i integrace, výkon, zátěž…
Obecně bych ale řekl, že pro testera je herní testing větší zábava, protože se toho prostě více děje. Není to „plochý svět“ aplikace nebo internetového prohlížeče. Pro mě byl právě ten přechod do 3D prostředí (a vše, co s sebou přináší), ten největší rozdíl. Stejně jako běžné aplikace také máme frontend, middleware a backend a všechno si to se sebou „povídá“ na podobné bázi. I slovník máme podobný, protože se snažíme vše unifikovat – chodí k nám ostatně pracovat lidé z různých prostředí a chceme se s nimi domluvit. Ale i tady máme jistá specifika. Například pojem regresní testování jsem během své testerské praxe v různých firmách slýchal neustále, ale v herní branži jsem jej prakticky neslyšel. Říkáme tomu playtesty nebo smoke testy. A lidé by mohli namítat – „Ale vždyť vy používáte úplně špatnou terminologii!“ No jo, ale my víme, co děláme. Můžeme tomu klidně říkat hodina basketbalu…
V terminologii se tedy s běžným softwarovým testováním občas potkáváme, občas ne. Jak jsem již nastínil výše, psát step-by-step scénáře může být komplikovaná záležitost – někdy by člověk právě psaním scénářů strávil více času než samotným testováním, což je samozřejmě drahý spálený čas. Některé věci se tedy testují velmi exploratory (průzkumně, testování na základě vlastních zkušeností a intuice – pozn. autora), no a o to si ostatně hry vyloženě říkají. Aby lidé zkoušeli, co je napadne. To, co zkouší testeři, jaké bugy mi občas chodí na opravu… To tě běžně opravdu nenapadne. Ani jako hráče, ani jako člověka, který tu funkcionalitu napsal, ani jako designéra. „Vyskoč, u toho si otevři inventář, drž tlačítko na zaměřování, udělej piruetu a na chvíli zavrávorá zvuková stopa.“ To se například ve velmi izolovaném a bezpečném prostředí banky nestane. Tam mě rušil maximálně antivir nebo firewall (smích).
O KRÁSÁCH REGRESNÍHO TESTOVÁNÍ
Ve vývoji je běžné, že se na funkční kostru postupem času nabalují další a další funkcionality. Ty ovšem nemusí dobře fungovat pospolu, a stejně tak mohou negativně ovlivnit i samotnou (a dříve funkční) kostru. Kvůli nemalým finančním nákladům ovšem nelze donekonečna testovat všechny části programu či hry, a právě tehdy přichází ke slovu regresní testy. Ty mají za úkol odhalit, zdali nedošlo k zavedení chyb do části programu, která dříve fungovala. Obvykle se jedná o pravidelné testy základních a rizikových funkcionalit, ke kterým dochází před každým veřejným vydáním softwaru.
Jak tedy herní testing konkrétněji probíhá?
Běžně využíváme smoke testů, například při updatech. Vezmeme funkcionality, které musí za jakýchkoliv okolností fungovat – například změny postavení (stoj, klek, leh), načítání hry ve všech herních módech a podobně. Máme takový „zlatý seznam“, na kterém jsou věci, u kterých potřebujeme, aby za jakékoliv situace spolehlivě fungovaly. To je asi nejblíž testovacímu scénáři, co jsem se v Bohemia Interactive dostal. A rozhodně nejde o návod krok po kroku ve stylu:
1) Zapni konzoli
2) Zapni Vigor
3) V hlavním menu zmáčkni tlačítko doprava
4) Zmáčkni tlačítko s nápisem „Play“
To určitě ne. Je to spíše:
1) Vyskoč
2) Zamiř
3) Vystřel
Jen je těch úkonů opravdu hodně, protože samozřejmě máme například několik kategorií zbraní. Díky tomu se test natolik rozvětví, že se člověk nestačí divit, že to testeři opravdu stíhají. A stíhají, protože to jsou frajeři. Máme obrovské štěstí na to, že u nás testují opravdu zapálení a bystří lidé, je to opravdový dar.
Chodí k vám testeři hlavně nabrat zkušenosti s herním vývojem a následně se posunout do jiných oddělení, nebo mají spíše ambice vypracovat se v rámci testingu jako takového?
Obě možnosti jsou samozřejmě validní. No a někdo třeba časem zjistí, že by chtěl být raději včelařem. Rok testuješ a potom zjistíš že prostě ne, že včely.
To je ovšem velice specifický případ, to se vám děje běžně? (smích)
Nevím, jestli někdo utekl úplně pryč z vývoje, navíc za něčím tak divokým (smích). Ale samozřejmě se děje i to, že člověka, který přijde do testingu, políbí múza a řekne si, že by ho bavilo spíše vytvářet audio. Tak začne drtit audio. Máme spoustu možností rozvoje a na každém oddělení pracují extrémně zapálení lidé, takže když za někým přijdeš a řekneš: „Hej kámo, fakt se mi líbí, co děláš, taky bych to chtěl umět!“, tak se mi nikdy nestalo, že by mě někdo poslal do háje. V korporátních prostředích člověk často zjistí, že se kolegové nechtějí dělit o své know-how. Něco takového tady neznáme. U každého problému se najde pomocná ruka, díky čemuž nemáme ani časové prodlevy, ke kterým běžně dochází u korporátů. Tam se mi stávalo, že jsem měl problém a měsíc čekal, než se mi k němu někdo vyjádří. S takovým přístupem bychom však museli zavřít krám.
Na živé multiplayerové hře něco takového neexistuje. Tam se platí krví i výpadek na víkend – neexistuje, že by se na něco čekalo. A když se náhodou na něco čeká, tak na tom v tu chvíli už někdo pracuje. Ne že by to někdo měl na seznamu a za pár týdnů se na to možná podívá. Když vznikne nějaký problém, řeší se hned a v každém okamžiku víš, co se s ním konkrétně děje.
Takže interakce mezi testery, vývojáři a dalšími rolemi jsou pro práci v herním testingu klíčové?
Určitě, nedovedu si představit, že bychom tyhle věci řešili nějak rigidně, waterfallem (viz níže). Osobně by mě opravdu zajímalo, jak fungují herní studia, která outsourcují svoji práci, protože to musí být opravdu velká výzva. Vím, že například CCP Games mají u EVE Online testing jinde než vývoj. Ale upřímně si nedovedu představit, jak takový vývoj vypadá, když se tester nemůže přímo zeptat, přímo na místě komunikovat s vývojářem. Díky Covidu jsme teď samozřejmě také roztříštění po home officech, tudíž taky musíme řešit věci všelijak po internetu, ale rozhodně upřednostňujeme situaci, kdy jsou všichni v kanclu. Home office je samozřejmě pecka, ale v osobní interakci mezi kolegy vidím neuvěřitelný přínos.
I PŘES VODOPÁDY BUGY PLYNOU DÁL
Obzvláště historicky (a ve spoustě firem dodnes) probíhal vývoj softwaru dle tzv. vodopádového modelu (waterfall). Co si pod tímto označením představit? Jednotlivé fáze vývoje na sebe navazují takovým způsobem, že další je započata až ve chvíli, kdy je předchozí fáze hotová. Iniciace práce tedy nemůže začít bez toho, aniž by nebyl plně hotový koncept, testing pak začíná až v době, kdy je software plně vyvinutý.
Ale představte si, že by se takovým stylem vyvíjely hry – jednalo by se o časovou (a tím pádem i finanční) sebevraždu. Hry tak ve svém vývoji velmi často využívají agilních metodik – tedy pravidelného dodávání malých kousků, které jsou testovány kontinuálně. Místo tříletého čekání na hotovou hru je tedy například vyvinut a odtestován inventář, za čtrnáct dní integrace herní mapy, za dalších čtrnáct dní bestiář a tak dále.
Komentáře naleznete na konci poslední kapitoly.
