Programátor z Bethesdy Adam nám vysvětlil, jak vznikají moderní hry a proč se objevují bugy a propady fps (Rozhovor)

Adam Konrád je zručný programátor, který pracoval v herních společnostech jako Bethesda či Escalation Studios. Pracoval i jako nezávislý programátor, kdy vyvinul vlastní hru FPSCORE, a zkusil si i moderování Game Page, přičemž rovněž psal recenze na hry.

Poslední roky strávil v Bethesdě, kde pracoval na Wolfenstein 2, Starfield či TES. V Praze vystudoval SSŠVT a PEF ČZU. Více se o něm dozvíš na jeho vlastní webové stránce.

Programování jsi také vystudoval. Věděl jsi už tehdy, že chceš programovat videohry?

Rozhodoval jsem se o tom už na střední. Byl jsem velký fanoušek Doom a Quake. S kámošem jsme udělali i fan stránku pro Doom, přičemž tehdy byla akorát ve vývoji trojka. Na základě toho s námi Česká televize udělala i rozhovor.

V té době jsem si přečetl knihu Masters of Doom a o začátcích id Software a vývoji Doom, díky čemuž jsem se chtěl dostat do videoherního prostředí. Pomalu jsem tedy začal pracovat na FPSCORE s Janem Modrákem. Do tohoto průmyslu se spíše dostaneš, když máš za sebou nějaké demo či hratelný projekt.

Kolik vás na FPSCORE dělalo?

Většinu z toho jsem vymyslel a udělal já. Měl jsem nastudován engine z Quake, tak jsme to s Honzou dali dohromady.

Pokud se programátor chce naučit hry, tak do roku by měl zvládnout pohovor v AAA studiu.

Sám jsi to programoval i animoval?

Ze začátku jsem to dělal sám, ale ukázalo se, že prostě nemáš čas či talent naučit se vše o herním vývoji. Díky Honzovi a jeho organizaci jsme však byli schopni dokončit to i s pomocí dalších lidí.

Na Linkedinu uvádíš, že jsi přes dva roky pracoval v České televizi jako moderátor. Co jsi tam dělal?

V ČT jsem však ještě psal recenze a moderoval Game Page.

FPSCORE jsi v té době programoval přes nějaký engine?

Quake 3 vyšel ve dvou vlnách. Nejprve id Software uvolnil na internet celý zdrojový kód hry, takže jsem FPSCORE začal stavět na tom. Šest let po vydání Quake 3 vydal id Software zdrojáky celého enginu, takže jsem se do něj jako programátor ponořil.

Dokázal bys nějakým jednoduchým způsobem vysvětlit, co je to ten herní engine?

Když člověk chce pracovat s počítačem, v úplném základě potřebuje na práci operační systém (například Windows). Herní engine je tomu velmi podobný. Umožňuje nám dělat věci v herním prostředí. Jednoduše dokáže zachytit ten programátorský vstup a měnit jej na výstup, tedy to, co se děje na obrazovce. Dokáže spočítat fyziku či posílat data přes síť.

Můžeme to parafrázovat tak, že když je jakýkoliv herní vývojář zedník, tak engine jsou vlastně jeho nástroje, díky kterým tu práci z technického hlediska může provést?

Ano. Pointa enginu je, že dokáže rychle vytvořit hru.

Když jsi jako programátor ten engine otevřel, bylo to pro tebe známé prostředí, nebo jsi se v něm všechno musel učit nanovo?

Já jsem v té době ani nebyl nějak velmi zručný a šikovný programátor. Všechno jsem se učil za pochodu. Nejvíce jsem se o programování naučil až během své profesionální kariéry. Ten samotný engine byl napsán v klasickém programátorském jazyce C, takže pokud v něm člověk chce něco vykouzlit, ať už to je C, C++ nebo něco jiného, musí ovládat základy toho jazyka.

V čem jsou jednotlivé herní enginy rozdílné? Umíš vysvětlit, jaký je rozdíl mezi Unreal Engine, Unity či Cry Engine?

Mám zkušenosti s Unity, Unreal Engine a různými soukromými enginy od různých firem. Velmi se liší ve stylu, jak jsou napsány, a v úrovni nástrojů. Z Unreal Engine se stal průmyslový standard, který se dá skriptovat v Blueprintu a kód můžeš napsat v C++. Unity je menší a věci se v něm dají dělat rychleji. V Unity píšeš v kódu C# a je třeba v něm dost věcí dopisovat a řešit.

Jak rychle se dá naučit pracovat v herním enginu na úrovni, že můžeš jít dělat do nějakého AAA studia? Řeč je o programátorovi, který předtím neměl s vývojem her zkušenosti.

Myslím, že velmi náročné by to nebylo, když už umí programovat. Bariéra pro vstup do her je pro zkušené programátory nízká. Pokud se programátor chce naučit hry, do roku by měl zvládnout pohovor v AAA studiu.

Čili naučit se dělat hry v případě, že už ovládám programování, je jednodušší než zvládnout samotné programování, ano? Dalo by se říci, že jde o nějakou nadstavbu?

Nadstavba je vhodné pojmenování. V herním vývoji je spousta triků a věcí, které jsou specifické pro herní vývoj, a při jiném softwaru tě to nezajímá.

Hráč může udělat ve hře něco, s čím jsme nepočítali, nebylo to odzkoušené a může mu proto spadnout i hra.

Řekněme, že máš herní engine, který je stavěn na tvorbu stříleček – FPS (First Person Shooter) a chceš vytvořit jiný typ hry, respektive vytvořit v rámci toho FPS něco, co ten engine neumožňuje, protože se specializuje na úplně jiný žánr. Co je náročnější a déle to trvá: upravit ten engine, aby tuto možnost poskytoval nebo je náročnější následně ten herní mechanismus v upraveném enginu vytvořit?

Myslím, že tvorba toho nového mechanismu v upraveném enginu bude náročnější než samotná úprava enginu. Ten mechanismus se musí dokončit a musí být funkční, aby člověk vlastně zjistil, jestli se to do hry vůbec hodí a zda to funguje tak, jak si představoval. Nejjednodušší by to bylo „nafejkovat“. Tedy, že to, co chceš, v tom enginu sice vytvoříš, ale vůbec na to nemáš ideální podmínky.

Není to tedy dokonalé a nemyslí to na všechny možné edge cases, tedy hraniční případy, kdy ten mechanismus přijde do kontaktu s něčím jiným, což není odzkoušené, a vůbec nikdo neví, jak to bude reagovat. Jako příklad můžeme uvést, že daný mechanismus funguje na souši, ale ne ve vodě.

Čili se může stát, že vytvoříte něco, co je pro ten engine nepřirozené, a nakonec ani nevíte, v jakých případech to bude a nebude fungovat?

Ano, může se to stát.

Takže hráč může udělat ve hře něco, s čím jste nepočítali, nebylo to odzkoušené a může mu proto spadnout i hra?

Přesně tak. V drtivé většině případů jsou to však jen zábavné glitche, kdy postava létá a propadává přes textury a podobně. Děje se to úplně každému, ať pracuje v jakémkoliv enginu. Každá velká firma má buď vlastní engine, nebo jeden z těch větších, „veřejných“, jako Unity, Unreal Engine či CryEngine, s tím, že si ho upraví.

Co přesně dělá programátor při vývoji moderní hry?

Když děláš hru, musíš si to rozložit na různé části. Myslím, že dvě základní části toho, aby se něco zobrazovalo na obrazovce, je grafika a to, jakým způsobem bude fungovat ovládání. Musíš být schopen zaznamenat vstup z klávesnice či joysticku/gamepadu, přenést jej na obrazovku a zároveň vymyslet to, co se děje mezi tím, než to uděláš.

Může ti animátor zadat, jak se má postava hýbat, a ty následně vytvoříš ten kód?

Ano, i. Animátor má k dispozici celý balík pohybů a všech animací, aby s nimi mohl pracovat. Ovládá celý kód pohybů, ve kterém by mělo být i to, jak rychle se postava hýbe, z čeho se následně počítá i fyzika ve hře. Jako příklad můžeme použít pohyb, když hráč narazí do zdi. Animátor musí pracovat s takovým kódem, který mu dovolí ten pohyb u zdi upravit, aby to vypadalo tak, že postava před stěnou zastavila a neběží do ní čelem vpřed. V tom kódu musím jako programátor překlopit ten stav, kdy běží naplno a zastaví se před nějakou překážkou.

Vytvoří programátor pro animátory kód se všemi pohyby postav dávno předtím, než si s nimi animátoři začínají hrát a hýbat s nimi?

To asi ne. Dříve udáváš pravidla, jak to bude fungovat. Například pracuješ na inverzní kinematice, což je návaznost kloubů a kostí, aby byly pohyby lidské a autentické.

Pracuješ na hře od její předprodukce až po její vydání, nebo při dokončování hry už pracuješ na prototypování té další společně s jinými členy předprodukčního a produkčního týmu?

V posledních letech jsem nepracoval na něčem od samotného začátku, ale je to různé a podle potřeby projektu.

Ty jako programátor končíš s vývojem mezi prvními?

Ne, právě naopak. Dnes to ti programátoři dokončují do poslední chvíle, hlavně co se týče opravování bugů, tedy technických chyb.

Takže nejsi programátor, který se zabývá výlučně počátečním prototypováním hry a mechanismy, ale pracuješ i s QA týmem, a tedy Quality Assurance – testery.

Řekl bych, že skoro každý programátor pracuje s QA týmem a opravuje bugy na základě jejich nahlášení.

Máš v rámci vývoje rozdílné fáze, kdy na začátku například prototypuješ, následně vytváříš konkrétní mechanismy a kód a v závěru opravuješ bugy?

Ty bugy se většinou opravují postupně v průběhu celého vývoje. Ale v podstatě je to, jak říkáš. Nejdříve prototypuješ, to se testuje a upravuje, následně se tvoří kompletní kód a šperkuje se do dokonalosti.

Jak moc se liší práce herního programátora dnes a před 10-15 lety?

Řekl bych, že dnes je to složitější. Sice je snazší najít informace, které na to potřebuješ, a začít programovat, protože je milion návodů a videí, ale samotné programování je mnohem komplexnější. Když chceš udělat něco sofistikovaného s grafikou, pořádně se zapotíš.

Takže se jako programátor stále učíš nové věci a hledáš způsoby, jak překonat nové překážky.

Samozřejmě, neustále přichází něco nového a obtížnějšího. Jednoduše řečeno, množství kódu, které dnes potřebuješ na vykreslení něčeho, je několikanásobně větší než v minulosti.

Dalo by se říci, že tentýž úkon, například pohyb Doomslayera a zabití démona, vyžaduje v novém Doom Eternal oproti prvnímu Doom 10 násobek práce ve všech oblastech?

Jednoduchá odpověď by byla ano. Přibývají funkce, procesy, komplexnost audiovizuálního zpracování a celková složitost.

Co se ti programuje nejsnáze?

Rád programuji systémové věci, jako například engine.

Portovat mobilní hry je nesmírně obtížné, protože většinou se úplně jinak řeší ovládání. A to nejen ve smyslu samotné hry, ale i uživatelského rozhraní, nemluvě o optimalizaci.

Pro Bethesdu jsi pracoval i na Wolfenstein: The New Colossus. Čím konkrétním jsi do projektu přispěl?

Dělal jsem na DLC a odemykání různých věcí na všech platformách.

Viděl jsi i nějaké prototypy na nové The Elders Scroll či Indiana Jones?

Bohužel, ne.

Ani bys k tomu neměl jako programátor z jiného sesterského studia přístup?

Ne, tak to nefunguje. Rozhodně se na to nemůžeš podívat přes nějaký firemní server.

Starfield bude první nová IP (značka) od tohoto studia po 20 letech. Udělalo to ve studiu nějaké rozdíly a čím byla práce na tomto projektu unikátní nebo odlišná od ostatních projektů?

Pro Bethesdu už nepracuji, a i kdybych pracoval, o Starfield toho hodně říci nemohu. Hra je v aktivním vývoji a doufám, že to dopadne dobře.

Hry od Bethesda Game Studios jsou známé tím, že jsou při vydání slušně zabugované. Mnozí kritizují i starší engine, který tvůrci využívají, a údajně ho jen upgradují, což pro vývojáře nevytváří ideální podmínky pro vývoj moderních her v takovém rozsahu a ambicích, jaké mají pro blockbustery jako Fallout či TES. Co si o tom myslíš a můžeš nám přiblížit, jak vypadá práce s tímto enginem? Je pravda, že je zastaralý?

Každé studio se snaží, aby byl jejich projekt při vydání co nejlepší. Není to však nutně chyba enginu. Jeho zastaralost v tom má prsty, ale spíše za to může komplexnost toho projektu, na který se kladou velmi vysoké nároky a je velmi obtížné je všechny splnit.

Dělal jsi i na mobilních hrách Fallout Shelter a TES: Blades. Čím je programování pro mobilní hry odlišné od toho pro konzolové/počítačové hry?

Je to naprosto rozdílné. Za svůj nejúspěšnější projekt považuji Fallout Shelter na Nintendo Switch. Implementovali jsme tam službu, která vytváří dokonalé parametry na to, aby projekt fungoval na dané konzoli.

Jak náročné a zdlouhavé je udělat z mobilní hry konzolovou, například pro Nintendo Switch?

Je to těžké, protože většinou se úplně jinak řeší ovládání. A to nejen ve smyslu samotné hry, ale i uživatelského rozhraní, nemluvě o optimalizaci. Řešit ovládání takového TES: Blades na mobily versus na Switch vyžadovalo hodně práce, protože tam jsou úplně jiná tlačítka a možnosti.

Jak změnily tvou práci next-gen konzole a jejich hardware?

Mou práci programátora to až tak moc neovlivnilo. Logiku a chování těch konzolí jsem já osobně velmi neřešil a zaměřil jsem se spíše na backend.

Když se setkají dva kódy, s jejichž střetem jsme nepočítali, může to vyústit do propadu snímků za sekundu (frames per second – fps). Například když má někdo slabší konzoli a hraje už delší dobu, tak se mu postupně snižuje množství paměti. Když se tehdy začne na obrazovce objevovat několik předmětů, dojde k nepředvídatelným problémům a v důsledku pádu frame-ratu může přestat fungovat i nějaká část fyziky, což způsobí další bugy.

Když je ve studiu několik desítek programátorů, setkáváte se s tím, že dva či tři programátoři potřebují kód upravit, ale úplně jiným způsobem, takže vznikají problémy?

Řeší se to dost často. Snažíme se tomu předcházet tak, že aplikujeme revizi kódu, kdy je každá série změn hodnocena ostatními členy týmu. Takže když kód upravím, lidé z mého týmu mi na to dají feedback a následně se kód odešle do finálního produktu. Když je tam nějaký konflikt, kód buď upravuji nebo se snažím obhájit a vyargumentovat svůj názor.

Měl jsi už hádku s nějakým programátorem proto, že ti někdo chtěl upravit kód, který jsi dokončil po velmi dlouhém čase a hrozilo, že ho budeš po úpravě kolegy muset zase otevírat a upravovat? V takovém případě nejde jen o to, zda máš dostatek času na úpravu, ale ve hře jsou už pak i emoce a osobní pocity.

Za 11 let mé kariéry bylo právě řešení takových situací jednou z největších výzev. Správně přistoupit k revizi kódu, přijímat zpětnou vazbu a argumentovat bez emocí. U většiny konfliktů buď najdeme kompromis, nebo jeden druhého přesvědčíme o lepším řešení. Když dáš totiž jedno zadání třem programátorům, dostaneš tři různá řešení a každé může být technicky správně. V takovém případě se sleduje to, který styl toho řešení a individuálního kódu sedí nejlépe k celkovému stylu programování daného projektu.

Pokud po QA testerovi nedokáže zreplikovat bug ani programátor, existuje velmi nízká šance, že se to vůbec opraví.

Když máš hotový kód a přijde ti od testerů z QA požadavek upravit ho, protože jsou v něm bugy, stane se ti i to, že úprava kódu a oprava té chyby způsobí dominový efekt a rozbije ti větší část kódu?

Takto to nefunguje. QA tester řekne, co nefunguje, a je na tobě, abys v daném kódu našel chybu, která to způsobuje. Tester v zásadě o tvém kódu neví vůbec nic. Při takové úpravě kódu třeba myslet na to, že možná jde o úkon, který je umístěn, respektive nakopírovaný do více segmentů kódu. Musíš se tedy zamyslet nad tím, zda úprava kódu na jednom místě neovlivní jeho stejné verze v jiných částech hry.

Co se týče toho dominového efektu, každá sekce kódu končí při jistém společném jmenovateli. Určitě tedy žádná porucha neovlivní celý kód, jen jeho určitou část. V opačném případě bys ten kód upravoval donekonečna, neboť jedna změna by zapříčinila další poruchu – a donekonečna by ses točil v kruhu.

Komplexnost a komplikovanost kódu a her může způsobit i to, že se ve hře setkají dva kódy, s jejichž střetem jste nikdy nepočítali a ani ho nikdy nezkoušeli, takže mohou vyústit do nečekaných bugů a chyb?

Přesně tak. Často jsou to frame-related chyby, když vzhledem na takový střet kódů dochází k poklesu frame-ratu, a tedy počtu snímků, které hra vyprodukuje za sekundu (frames per second – fps). Například když má někdo slabší konzoli a hraje už delší dobu, tak se mu postupně snižuje množství paměti. Když se tehdy začne na obrazovce objevovat několik předmětů, dojde k nepředvídatelným problémům a v důsledku pádu frame-ratu může přestat fungovat i nějaká část fyziky, což způsobí další bugy.

Takto vypadá rozdíl mezi 30 a 60 fps. Abys to však pochopil naplno, musíš si to vyzkoušet sám. Zkus si na své konzoli na nějaké hře přepínat mezi 30 a 60 fps módy a uvidíš, jaký je to neuvěřitelný rozdíl.

Mnoho frame-dropů se nachází ve scénách, které hardware až tak velmi nezatěžují, zatímco hra si drží stabilních 60 fps v mnohem náročnějších sekcích. Sem tam na to poukazují i kluci z Digital Foundry, kteří dělají technické rozbory her. Vývojáři pak tyto frame-dropy opraví v patchi, protože se občas vyskytují na identických místech pro více hráčů. Je to právě výsledek neočekávaného střetu dvou kódů, které se neměly setkat, a proto tyto frame-dropy i docela snadno opraví, protože jde o menší nedostatek v kódu?

Přesně tak. V důsledku nejmenšího nedostatku kódu mohou takové frame-dropy trvat i několik sekund. Všechny takové problémy by měly být odhaleny v takzvaném Performance Testing. Avšak stejně jako se nezachytí a nestihnou opravit všechny bugy, se občas nestihnou najít a opravit ani frame-dropy, když padá počet snímků zobrazených za sekundu. Řekl bych, že samotný Performance Testing není až tak sofistikovaný, náročný na hardware a také na lidské zdroje.

QA tester někdy nedokáže zreplikovat technickou chybu, respektive bug, který našel, ačkoli ví, že se udál a jde o chybu. Jak řešíte takové chyby, které se sice stanou, ale nevíte, z jakého důvodu, a tak je ani neumíte opravit?

Pokud to nedokáže zreplikovat ani programátor, existuje velmi nízká šance, že se to vůbec opraví.

Trochu lépe se mi pracovalo s Playstationem. Jejich nástroje byly rychlejší a jednodušší na pochopení.

Existuje situace, kdy by měl jistý bug znamenat specifickou chybu v jisté sekci kódu, ale neumíte ho tam najít? Tedy že logicky by ten bug měla způsobit chyba v tomto a tomto kódu, ale neexistuje tam, takže ho způsobí něco úplně jiného?Stát se to může, odlišuje se to od příkladu k příkladu. Kód může vypadat a působit úplně jinak, a to ve stejných herních sekcích. Každý hráč má unikátní Game State, tedy stav té hry, respektive status toho světa, podle toho, jak hrál. Na základě toho i ten kód pak vypadá unikátně.

Když portujete nějakou hru na jiné platformy, například z PC na Xbox a Playstation, je ten kód většinou podobný nebo tam probíhají velké změny?Mění se tam toho hodně. Je to v podstatě změna na úrovni Windows a Linuxu. Nějaké základní funkce jsou stejné, ale to, jak hra pracuje s tím operačním systémem, je úplně jiné.

Mnoho lidí si neuvědomuje, že kvalita portování nezávisí jen na síle hardwaru konzole či kvality vývojářského týmu, ale také na takzvaných development tools. Jde o nástroje, se kterými se v podstatě vytvářejí hry pro konzole. Řada vývojářů už v minulosti i v současnosti při vydání next-gen konzolí řeklo, že Playstation vývojářům poskytuje lepší vývojářské nástroje, díky čemuž se tvůrcům jednodušeji pracuje právě na Playstationu. Jaká je pravda?

No, to je výborná otázka. Já osobně jsem nepracoval s naprosto všemi nástroji, které Xbox a Playstation nabízejí. Pokud bych to měl zjednodušit, tak řeknu, že Xbox funguje více jako Windows, Playstation zase funguje více jako Linux. Trochu lépe se mi pracovalo s Playstationem. Jejich nástroje byly rychlejší a jednodušší na pochopení.

Mohly být tyto nástroje důvodem, proč některé hry při vydání next-gen konzolí vypadaly lépe na PS5 než na Xbox Series X, a to i přesto, že Xbox má silnější hardware?

Ano, pravděpodobně to bylo proto. Šlo o nové konzole, takže vývojářům chvíli trvá, než se s nimi seznámí. Pokud se jim tedy jednodušeji pracovalo s Playstationem, byl to důležitější faktor než konkrétní čísla na seznamu hardwarových specifikací. Ještě bych to však porovnal s něčím, co bude lidem blíž. Když si porovnáš iPhone se stejně drahým Androidem, tak iPhone nebude mít na papíře silnější specifikace a hardware. A přece jen, tedy alespoň podle mě, běží ten iPhone rychleji. Z mé pozice je těžké zhodnotit to zcela objektivně.

Jak práce z domova a koronavirus ovlivnily vývoj her z pohledu programování?

Ovlivnilo to práci pozitivně i negativně. Záleží na tom, na co konkrétně by ses ptal. Ale tak to mají zřejmě v každé firmě po celém světě. Myslím si, že se setkáváme se stejnými problémy jako ostatní. Neznáme se s novými kolegy, drhne komunikace a podobně. Na programování se musíš nesmírně soustředit. Někdy je to tedy těžké, když je kolem tebe rodina a děti. Osobně mi však práce z domova nevadí.

I jsi někdy rodinu vyhnal z domu, protože ses s ní nedokázal soustředit?

Musím se přiznat, že ano. Byl jsem ve stresu, potřeboval jsem něco odevzdat a při nich se to nedalo. Jindy však tomu jdu naproti a trávím s nimi čas, když bych ho měl věnovat práci, kterou zase doháním po večerech, když už děti spí.

Přinutily vás tyto podmínky zlepšit nějaké pracovní postupy, respektive přišli jste/přišel jsi na něco, co implementujete i po návratu do normálu?

Určitě. Minimálně jsme se naučili jednodušeji a efektivněji pracovat z domu. Nebýt covidu, nikdy bychom nebyli schopni takto pracovat mimo kanceláře. Práce z domova má své výhody a čekám, že řada firem tuto možnost svým zaměstnancům nabídne.

Francouzská firma Dontnod (Life is Strange, Vampyr) už prohlásila, že všichni její zaměstnanci mohou trvale pracovat z domu.

Jo, to je super. Větší firmy to však už budou mít těžší, protože se to všechno nedá přizpůsobit práci z domu.

Jaké jsou tvé zkušenosti s crunchem, tedy dlouhodobými přesčasy v Bethesdě?

V herním vývoji je to prostě tak, že někdy musíš crunchovat, jelikož tě deadliny nepustí. Jiným lidem se to může stávat častěji, ale já jsem hodně necrunchoval.

Když už jsi ten crunch zažil a byl jsi nucen pracovat přesčasy, jak fungovalo odměňování?

Tady v Texasu zákony fungují i tak, že v rámci tvé mzdy jsou již započítané přesčasy, které dále nevykazuješ. Dostaneš prostě nějaký bonus, odměnu a hotovo. Zdarma jsem rozhodně nepracoval a po skončení velkého projektu nás odměnili.

Není to však nijak určeno, co přesně ten crunch znamená. Může to znamenat i několik měsíců každodenního přesčasu.

S takovým drastickým crunchem jsem se já osobně nesetkal. Dělali jsme přesčasy maximálně 2-3 týdny. Pokud ten tým je veden dobře, ke crunchům v takové velké míře nedojde.

Jsi tedy zastáncem názoru, že crunch vzniká v důsledku selhání managementu a plánování produkce a že se mu z větší části dá vyhnout?

Určitě.

V Bethesdě, respektive Zenimaxu jsi byl 3-4 roky. V srpnu tohoto roku jsi tam skončil. Prozradíš, proč ses tak rozhodl?

Chtěl jsem se posunout dál. Myslím, že jsem viděl a řešil většinu problémů, jaké se objevují v herním průmyslu. Vliv mělo i to, že při větších projektech trvá celé roky, než se člověk dočká výsledku, a chtěl bych pracovat na něčem, čehož výsledek uvidím dříve.

Co děláš teď?

Stále dělám programátora, akorát už ne v herní firmě.

Microsoft loni oznámil koupi Zenimaxu, a tedy i Bethesdy. Jak to změnilo práci na hrách, když jste začali patřit pod Xbox Game Studios?

Nemyslím si, že se mnoho věcí změnilo. Bethesda má nyní více výhod, protože se zařadily k ostatním studiím.

Věděli jste o tom, že se připojíte k Xboxu, dříve než celý svět, když to Microsoft oznámil přes média?

Oznamuje se to všem ve stejný čas. Microsoft je veřejně obchodovaná firma, takže o sdělení takové velké akvizice nesmí vědět mnoho lidí. Kdyby to lidé věděli dříve, mohli by obchodovat s akciemi dříve, než změní svou hodnotu, což by značilo insider-trading, tedy zločin.

Měli s touto akvizicí někteří tví kolegové nebo ty sám problém? Vývoj her bude jednodušší, když už se nemusí zabývat vývojem na platformu Playstation, ale určitě se mezi vývojáři našel někdo, kdo nedokázal překousnout, že si většinu her od Bethesdy už na PlayStationu nezahraje.

Je to obchodní rozhodnutí a musíme ho všichni respektovat. Myslím, že by bylo lepší, kdyby hry vycházely na všech platformách.