Postmortem: Star Trek: Hidden Evil od Presto Studios

Změna… To je opravdu to jediné, na co se v tomto odvětví můžete spolehnout. A pokud se nedokážete přizpůsobit, jdete od válu. Taková byla situace v Presto Studios v době, kdy na herní trh vtrhla vlna 3D enginů pracujících v reálném čase. Pro ty z vás, kteří o Presto Studios nic nevědí, doplním, že toto studio je nejznámější svou sérií grafických adventur Journeyman Project ve stylu Myst. Nádherně předrenderovaná pozadí, řešení hádanek a programování v Directoru – na tom byla tato společnost založena. Jenže najednou se zakladatelé rozhodli smést ze stolu vše, co uměli, a udělat vlastní zářez na pažbě real-time 3D. A tak najali skupinu programátorů, kteří měli dostatek zkušeností a znalostí, aby dokázali vytvořit nový engine od základu. První produkt vzešlý z tohoto úsilí, Star Trek: Hidden Evil, je rozumným prolnutím mezi tím, kde Presto bylo a kde by chtělo být.

Spojili jsme se s Activisionem, abychom vytvořili první hru podle jejich nové licence na Star Trek, kterou získali od Paramountu. Vzhledem k našim zkušenostem s předrenderovanými adventurami jsme dostali za úkol vytvořit předrenderovanou akční adventuru. Chtěli hru rozdělenou na jednotlivé mise, v nichž by jednoduché instrukce prováděly hráče krok za krokem, aby hra zaujala i příležitostné hráčské publikum. Chtěli, aby hra byla krátká, aby tyto příležitostné hráče neodradila. Chtěli, aby měla nádherná pozadí s postavami pohybujícími se po scénách v reálném čase s využitím postupu per-pixel depth sorting (objekty blíže ke kameře se vykreslují později, aby překrývaly objekty na pozadí, a to pro každý bod na obrazovce). Ale především potřebovali, abychom hru vytvořili během jediného roku, aby se dostala na předvánoční trh 1999 a tím zapadla do velkolepého marketingového plánu Activisionu s jejich chystanou řadou startrekových her. V konečném součtu mám zato, že se nám podařilo vytvořit přesně takovou hru, jakou Activision a Paramount chtěli, ačkoliv k našemu cíli vedla dlouhá a obtížná cesta.

Náš vývojářský tým se skládal ze dvou velmi odlišných skupin lidí. Tým programátorů, kteří měli bohaté zkušenosti s 3D hrami běžícími v reálném čase, se z větší části skládal z nových tváří. Já, jako hlavní programátor, jsem přišel z Volition, Inc., která proslula hrami Descent a FreeSpace. Hlavní technologický ředitel měl k dobru patnáct let zkušeností se zpracováváním 3D grafiky. Náš programátor umělé inteligence měl z tohoto oboru doktorát. Společně jsme tvořili jádro, které mělo společnosti usnadnit tvorbu jejího prvního real-time titulu.

Lidé z produkčního týmu pocházeli většinou z druhé strany herního světa, kde je nejdůležitější design a renderování. Ve většině případů to byli lidé, kteří pro Presto před lety pracovali na projektech série Journeyman. Naštěstí tam bylo i několik nových výtvarníků se zkušenostmi v oblasti real-time 3D, kteří pomohli překlenout propast mezi těmito dvěma tábory.

Výroba byla rozdělena mezi následující dvě oddělení: real-time skupinu a předrenderovací skupinu. Real-time skupina byla zodpovědná za tvorbu modelů postav a objektů, jednotlivé fáze animace, animace ve filmových scénách, kolizní geometrii a herní logiku. Na těchto úkolech se pracovalo v 3DSMax s pomocí mnoha našich vlastních vývojářských pluginů, které jsme využívali k vyexportování prostředí, objektů, animací a herní logiky. Předrenderovací skupina byla zodpovědná za design jednotlivých scén, tvorbu pozadí a předrenderování filmových sekvencí. To se dělalo v Electric Image s dodatečným naleštěním ve Photoshopu.

Dodali jsme, co jsme slíbili

Ačkoliv se naše hra v jednotlivých detailech silně lišila mezi původní představou a konečným provedením, základní cíl zůstal naštěstí nezměněn: vytvořit akční adventuru rozdělenou na mise, určenou příležitostným hráčům. A náš konečný výsledek se do tohoto cíle velmi přesně trefil. Jedním z klíčových faktorů našeho úspěchu bylo rozhodnutí vytvořit hru raději „příliš snadnou“. V průzkumu provedeném Activisionem se zjistilo, že z lidí, kteří vlastní herní PC a rádi sledují Star Trek, si pouze malý zlomek koupil nějakou startrekovou hru. A hlavním důvodem, proč si nikdy žádnou nekoupili, bylo to, že „se jim zdají být příliš těžké.“ A to byl náš zákazník. Chtěli jsme dát příležitostným hráčům možnost stát se součástí jedné epizody Star Treku. Chtěli jsme, aby mohli mluvit s Picardem a Datou, procházet se po okolí a zkoumat různé objekty pomocí trikordéru a střílet phaserem po nepřátelích. To je Star Trek, a proto jsme došli k závěru, že to fanoušky bude bavit.

Abychom upoutali pozornost začínajících hráčů, rozhodli jsme se, že akční stránka hry bude co nejjednodušší. Náš zákazník nemá zájem o souboje s ostatními hráči ve zběsilém tempu. Místo toho jsme náš koncept zjednodušili. Významný podíl na tom měla funkce automatického zaměřování. Jelikož na hru nahlížíte z pevně určené pozice, z pohledu třetí osoby, muset precizně ovládat svoji postavu, abyste zaměřili někoho jiného, by bylo příliš složité. Místo toho se provede jednoduchý test výseče, který určí, zda jste k určitému objektu otočeni dostatečně na to, aby vaše postava automaticky zaměřila jeho pozici. Abychom hráči prodloužili délku života, nastavili jsme zranění způsobované nepřáteli na velmi nízkou úroveň, zatímco síla hráčova phaseru byla vysoká. Snažili jsme se odstranit co nejvíc „zběsilého“ střílení a spolehnout se více na zábavu, která pramení z šoku z nového nepřítele, který vskočil (nebo vletěl) do výhledu, a následného potěšení z toho, jak padá po zásahu phaserovým paprskem.

Dalším hlavním herním prvkem, který jsme museli vyvážit s ohledem na příležitostné hráče, byly hádanky. Snažili jsme se, aby každá představovala výzvu a přinášela hráči zaslouženou odměnu, která ho bude hnát kupředu. Objevení nových dechberoucích oblastí čekajících jen na to, až je prozkoumáte, a sledování objektů, které v reálném čase reagují na to, co děláte, to vše představuje vynikající odměnu za vyřešenou hádanku. Do deseti misí je rozloženo pět zcela odlišných lokací, které můžete prozkoumávat, od Enterprise po starověkou podzemní civilizaci. Každá má přitom svůj vlastní nádech a herní styl. To příležitostnému hráči nabízí hodiny zábavy plynoucí čistě ze zkoumání světa.

Dodali jsme, kdy jsme slíbili

Velkým úspěchem, s čímž by podle mě souhlasil i náš vydavatel Activision, bylo, že jsme hru dodělali včas. V září 1998 jsme podepsali smlouvu, že jim CD s finální hrou odevzdáme v polovině října 1999, a v tomto termínu jsme stihli vytvořit produkt, který chtěli. To z finančního hlediska téměř zaručuje úspěch, protože hra se dostane na předvánoční trh a prodejci softwaru budou nabízet Star Trek: Hidden Evil s Jean-Lucem Picardem na krabici. V té chvíli je snadné utratit 29.95$ za něco, co příležitostní hráči znají, oproti mnoha dražším hrám, které jim jsou naprosto neznámé.

Tím, že jsme stihli uzávěrku finální verze, jsme se vešli i do rozpočtu. Podařilo se, aby hra byla krátkou, nízkonákladovou dobrodružnou hrou, která nezahltí začínajícího hráče. Kdykoliv se hra zpozdí, začnou kvůli platům narůstat náklady a je nutné čerpat zdroje přidělené ostatním projektům. V období, kdy překračujete termín odevzdání, se rychle vytrácí vaše marže, takže dokončit práci včas je pochopitelně převelice důležité pro finanční blaho vaší společnosti.

To, že hra vyšla včas, ušetřilo peníze i Activisionu. Každý rok uvádí přední vydavatel na trh během předvánoční sezóny půltuctu nebo i více titulů. Tím, že jsme náš projekt dokončili v říjnu, jsme v jejich oddělení záruky jakosti uvolnili včas cenné zdroje. Tím, že jsme produkt odevzdali podle rozvrhu, který Activision plánoval po celý rok, jsme je nedonutili k žádnému masivnímu přeplánování jejich reklamní strategie. Vydat hru včas je dobré pro každého, vývojářem počínaje, přes vydavatele, až po spotřebitele.

Potřeba nové krve

Tu a tam udělá společnost rozhodnutí, které přinese náhlý obrat k lepšímu. Nebo alespoň udělá z nemožného možné. Tak bych popsal naše rozhodnutí najmout dvojici asistentů, Andyho Schatze a Narayana Brookse. V polovině projektu jsme si uvědomili, že nemáme dostatek lidí, abychom dokončili tvorbu levelů. Tím mám na mysli stavbu úrovně, rozložení dveří, rozmístění nepřátel, atd. A ačkoliv se to může zdát divné těm, kteří pochází ze společností pracujících na klonech Quaka, nezapomínejte, že Presto Studios vytvářelo předrenderované hry ve stylu Myst po celá léta. Dokud jsme se neponořili do real-time 3D, bylo vytváření úrovní úkolem výtvarníků, kteří pracovali na scénách s miliony polygonů. Vytvořit geometrii v nízké kvalitě a postavit dveře na správných místech vyžaduje odlišné, víc s enginem spjaté dovednosti. A tak jsme najali dva lidi, kteří usilovali o titul v počítačových vědách, aby nám pomohli vytvořit logiku, která by našim trojrozměrných světům vdechla život.

Protože oba dostali za úkol pracovat s našimi nástroji za účelem oživení jednotlivých prostředí, mohli s nimi experimentovat. A to bylo poprvé, kdy si někdo sedl a skutečně zkoušel, co naše nástroje dokáží. Když si k tomu přičtete, že oba očividně milovali tvorbu her, představovalo to dokonalé řešení mnoha našich problémů. Zničehonic jsme měli lidi, kteří nechtěli konstruovat jenom to, co jsme jim řekli, ale doslova sršili novými nápady. Vytvářeli scénáře, které naše návrháře levelů vůbec nenapadly. Jejich nadšení se brzo přeneslo i na ostatní členy týmu a skutečně pomohlo posunout projekt směrem k jeho konečnému cíli.

Těžká rozhodnutí

Jedním z nejtěžších okamžiků, který může herní společnost potkat, je ten, kdy musí slevit ze svého snu. Mohou ti, kteří jsou ve vedení, včas rozhodnout, že hra, tak jak je navržená, je prostě příliš velká? V Presto Studios bylo naštěstí odpovědí na tuto otázku „ano“. Původní herní návrh představoval mamutí úkol, obzvláště vezmeme-li v úvahu jednoroční termín. Jelikož jsme se už zanedlouho začali s jednotlivými klíčovými verzemi opozdívat, bylo nám hned jasné, že pokud náš projekt výrazně neupravíme, nemáme naději stihnout datum odevzdání finální verze ani Vánoce. Bylo rozhodnuto, že se musí krátit.

Vývojářský tým si téměř na celý týden sedl ke stolu a prošel kompletně celou hru. Probírali jsme každou úroveň, každou scénu, každou událost a dbali jsme na to, aby všichni u stolu chápali, co se musí udělat. Mnoho položek bylo zrušeno okamžitě, když se lidé dozvěděli, občas vůbec poprvé, o situaci, která se musela odehrát, aby se příběh posunul dál. Jiné nápady jsme rozebrali a sestavili jinak, abychom lépe využili naši technologii. Když jsme skončili, byla pryč celá jedna úroveň a všechny ostatní byly výrazně upraveny. Rušení některých prvků jsme doprovázeli slovy: „Pokud budeme mít na konci čas,“ ale jak všichni dobře věděli, znamenalo to jejich definitivní zánik. Ještě nikdo v historii tvorby her neměl na konci čas.

Ale to neznamenalo, že je všemu krácení konec. Ještě nás čekalo pět měsíců, kdy jsme rušili další prvky, a i ve zbývajícím čase se tu a tam objevila nějaká potíž. Engine například nedokázal provést určitou věc tak, jak si návrháři představovali. Nebo se nám krátil termín a my prostě neměli dostatek lidí, abychom mohli naanimovat určitou filmovou sekvenci. Obecně platilo, že jestliže nějaký prvek ohrožoval datum vydání, vyřadili jsme ho. Na ničem nezáleželo víc než na včasném vydání hry a všichni jsme se shodli na tom, že je lepší vydat menší ucelenou hru než větší a nestabilní. Navíc, testeři Activisionu si nikdy nevšimli, že by ve hře něco chybělo. Chybějící části vidí pouze ti z nás, kteří vědí, že tam kdysi měly být.

Renderovací engine

Někdo říká, že jsem programátor. Abych tento názor potvrdil, měl bych nejspíš říct něco o programátorském úkonu, který představoval skutečnou výzvu… o renderovacím enginu. Původní koncept enginu byl docela prostý, předrenderovaná pozadí a objekty animované v reálném čase, to vše sloučené pomocí per-pixel depth sortingu. Měli jsme už k dispozici real-time renderovací engine, který byl použit pro tvorbu Beneath, 3D akční dobrodružné hry, jejíž výroba byla nakonec pozastavena. Přidání předrenderovaných pozadí si však vyžádalo mnohem víc kódu, než mnozí z počátku předpokládali.

Ke správnému vykreslení jednotlivých pixelů vzhledem k jejich vzdálenosti od kamery jsem se rozhodl použít algoritmus, který údaje o hloubce každého pixelu ukládá postupně do paměti (depth buffering). Electric Image dokázal vyexportovat příslušné údaje z vyrovnávací paměti (z-buffer), které jsem poté překonvertoval do našeho vlastního formátu. Musel jsem napsat zcela nový renderovací program, protože renderer Beneath obsahoval algoritmus pro odstraňování skrytého povrchu na základě zadaného rozpětí. To si žádalo přepsat všechny renderovací cesty, včetně průhlednosti, průsvitnosti, stínování, atd… Byl vytvořen kamerový subsystém, který dokázal nahrávat pozadí podle potřeby. Napsal jsem systém pro aktualizaci překrytých oblastí, který fungoval na principu postupného překreslování jednotlivých řádek obrazu a který dokázal obnovit poškozené části pozadí i údaj z vyrovnávací paměti, když přes pozadí přecházel objekt animovaný v reálném čase. Přidejte k tomu průsvitný displej, který překrýval jak pozadí, tak real-time geometrii, a máme tu docela zajímavý úkol, jak optimalizovat překreslování obrazu.

Nicméně, nejzajímavější částí kódu bylo podle mého názoru naše řešení hardwarového renderování. Museli jsme použít stejný koncept s předem uloženými údaji z vyrovnávací paměti, které bychom mohli překopírovat do karty a poté ji přimět správně vyrenderovat jednotlivé trojúhelníky. Původně jsem si myslel, že budu muset prozkoumat každou kartu na trhu, abych zjistil, jak zpracovává údaje z vyrovnávací paměti. Používá tato karta nějaký formát s plovoucí čárkou, používá tamta karta w-buffering (variace na z-buffering, která vede k rovnoměrněji rozložené přesnosti), používá tamhleta karta vyšší čísla pro objekty, které jsou blíže ke kameře? Výsledek mých pokusů mě překvapil. Ze všech karet, které jsme testovali a které uměly zpracovávat údaje z vyrovnávací paměti, se žádná nezajímala o to, jaké informace uložíte v jejich vlastní vyrovnávací paměti, dokud skrz renderer trojúhelníků pošlete stejné údaje. Nakonec jsem to vyřešil tak, že jsem do všech karet nechat posílat stejné údaje o hloubce ve formátu 1/z s pevnou čárkou. Dokud hodnoty, které jsem nakopíroval do vyrovnávací paměti, odpovídaly hodnotám, které jsem poslal kartě v bloku údajů o styčných bodech trojúhelníků, vše fungovalo. Jinými slovy, když pošlete hodnotu z skrz Direct3D nebo Glide, karty s nimi neprovádí žádná kouzla. Jednoduše použijí tuto hodnotu na polygon (s ohledem na perspektivu) a výsledek uloží do vyrovnávací paměti. Zapsat hodnotu přímo do vyrovnávací paměti karty je jako nakreslit na obrazovce obyčejný trojúhelník z pixelů, v jakékoliv hloubce se vám zamane.

Všechno je to o nástrojích

V aréně real-time 3D je to všechno o nástrojích. K čemu je skvělý renderovací engine, který je rychlejší a hezčí než všechno ostatní na trhu, když váš vlastní produkční tým nedokáže nic vytvořit? Bude z toho nádherné demo, ale ne hra. První generace nástrojů v Presto se v podstatě nechala považovat za průvodce kurzem, jak nedělat nástroje. Nové prvky je rozežíraly ze všech stran, až hrozilo, že se celá jejich struktura zřítí sama na sebe. Jejich kód byl tak špatný, že občas padaly. A v naší šílené honičce za přidáváním nových prvků jsme si nikdy nedokázali najít čas, abychom tyto občasné problémy odstranili. A tak se na špatný kód nabalil další špatný kód a situace byla postupem času čím dál horší. Všichni programátoři v kanceláři, kromě toho, který tyto nástroje vytvořil, je považovali za jakousi temnou magii, která byla napsána v úplně cizím jazyce. Když něco nefungovalo, neměl produkční tým moc možností. Mohl jim pomoci jenom jediný programátor a ten neměl nikdy čas, což nebylo dobré řešení. Nikdy nesmíte dovolit, aby něco záviselo pouze na jednom programátorovi. Jakýkoliv systém by jich mělo zvládat víc.

Jednou z nejlepších věcí, kterou mohou nástroje udělat pro produkční i programátorský tým, je upozornit na případné potíže varováním nebo chybovým hlášením. Náš programátor nástrojů naneštěstí význam této vlastnosti neviděl. Vážné chyby ve vyexportovávaných datech nikdo nehlásil, zatímco jiná varování sloužila výtvarníkům jako znamení toho, že se jim daná věc podařila vyexportovat úspěšně. Podávat nesprávná varování je horší než nepodávat žádná, protože tím uživatele učíte je ignorovat. Správná kontrola chyb by všem bývala ušetřila týdny času strávené kontrolováním nefunkční herní logiky, která se nakonec ukázala být nesprávně nastavenou položkou v 3DSMax, kterou měly nástroje nahlásit.

Aby to měl produkční tým ještě těžší, rozhraní nástrojů vytvářel programátor za pochodu. A opět, design nových prvků na nás vyplázl svůj odporný jazyk a ukousl velkou část naší produktivity. A skutečnost, že programátor používající především levou polovinu mozku vytvářel grafické rozhraní pro výtvarníky, kteří spoléhají na pravou polovinu mozku, je chybou, se kterou se jistě setkala většina tvůrců her. Tak to prostě nejde. Bez funkčního spojení, které by přenášelo požadavky produkčního týmu směrem k programátorovi, byly nástroje stále více nestabilní. V jednom z nástrojů se tlačítko označené „Zničit všechna data“ necházelo hned vedle tlačítka „OK“, bez jakéhokoliv potvrzení „Jste si jistí?“ alespoň u jednoho z nich. To dokonale vystihuje naši první generaci nástrojů.

Chápání v souvislostech

Po hrabošení v programátorské stránce nástrojů cítím, že mám plné právo podívat se na zoubek druhé straně týmu. Produkce má svaté právo nenávidět nástroje, které musí používat, ale to není dostatečný důvod k tomu, aby je nepoužívala. Mnoha členům produkčního týmu scházela důkladná znalost enginu nebo nástrojů používaných k tvorbě herního světa. To se týkalo i lidí, kteří navrhovali herní prvky na papíře, aniž by dostatečně chápali, co bude zapotřebí k oživení jejich nápadů. Oba asistenti, které jsme najali v polovině projektu, se však dokázali v minovém poli, které představovaly naše nástroje, velmi dobře pohybovat. Jak je možné, že lidé, kteří byli poblíž celá léta, během nichž se engine vyvíjel, mu rozuměli tak málo, zatímco naši nejnovější pomocníci pochopili jeho koncept v několika týdnech? Domnívám se, že tu jde o to, kdo chce dělat hry a kdo chce dělat umění.

Ale cožpak nechceme všichni dělat hry? Proto přece jsme v herním průmyslu, ne? No, ano i ne. Někteří z nás studují hry ze všech stran. Od psaní skriptů po programování, od návrhu uživatelského rozhraní po řízení produkce. Sám jsem si postupně ušpinil ruce vším možným. Nedělám to proto, že bych měl pocit, že musím ve všech těchto dovednostech vynikat, ale protože se domnívám, že musím být v těchto dovednostech zběhlý natolik, abych mohl rozumně spolupracovat se všemi členy týmu. Zatímco specializace může být efektivní ve velkých vývojářských domech, v malých týmech je obvykle zapotřebí obecnějších dovedností. Každý by měl přinejmenším na základní úrovni chápat, jak to co dělá, ovlivní další členy týmu i konečný produkt. A k tomu je zapotřebí základní schopnosti umět řešit problémy. Pokud neradi odstraňujete potíže, pak vás s největší pravděpodobností bude tvorba her v jednom kuse frustrovat.

Design konceptů vs. konstrukce úrovní

Možná nejhorším rozhodnutím při tvorbě Hidden Evil bylo oddělení designu úrovní a jejich konstrukce. Toto rozhodnutí pramenilo ze zkušeností naší společnosti s předchozími grafickými adventurami. Nechat jednoho výtvarníka vytvořit vizuální a mechanický koncept úrovně a jiného vymodelovat úroveň podle nákresů bylo dříve naprosto bezproblémové řešení. Ale ve hře s pohybem postav v reálném čase a bojem nemusíte ve snaze navrhnout něco čistě pro krásu získat nutně něco, co je zároveň zábavné. Když naši dva asistenti začali experimentovat s našimi nástroji a enginem, vytvořili scénáře, na které by se naši koncepční designéři nikdy nezmohli. Scénáře, které byly nejenom vzrušující, ale i snadno použitelné díky vrozeným vlastnostem naší technologie. Znalost nástrojů je jednou z nejdůležitějších dovedností, kterou může osoba pracující na designu úrovní mít.

Náš výrobní proces byl kvůli oddělení designu a konstrukce neefektivní. V polovině projektu jsme měli vytvořené celé úrovně, aniž bychom do nich zakomponovali bojové scénáře nebo se alespoň pokusili projít se těmito prostředími s naším hrdinou. Záběry kamer jsme volili pro jejich estetickou krásu, ne pro jejich efektivnost při akčních scénách. A kdykoliv jsme narazili na problém s umístěním bedny nebo kamery, museli jsme se vrátit k předrenderovaným souborům v Electric Image, provést změny, přerenderovat celou scénu a poté ji znovu vyzkoušet často se zjištěním, že jsme ji nezměnili dostatečně nebo jsme ji změnili až moc. Cesta od konceptu k provedení byla prostě příliš dlouhá. Modelování úrovní s viditelnou kolizní geometrií by bylo mnohem rychlejší, protože by vyžadovalo pouhou změnu v malém souboru v 3DSMax a její vyexportování do enginu. Jeden člověk by mohl každý den experimentovat s tucty nastavení místo jednoho provedení každých několik dní.

Technický design za pochodu

Špatný design není problémem jenom u výtvarníků. Programátoři musí navrhovat jednotlivé systémy předtím, než je začlení do projektu, obzvláště podílí-li se na něm i jiní programátoři. Při tvorbě Hidden Evil jsem kvůli ignorování této potřeby dosti trpěli. Protože jsme v podstatě vytvářeli hru i engine souběžně, dostávali jsme se neustále do konfliktních situací, kdy jsme okamžitě potřebovali nový prvek, abychom v příštím týdnu stihli uzávěrku. To vyústilo v to, co je při programování her často standardem: design za pochodu. Základní herní prvky jako algoritmus pro sledování postav nebo rotační objekty vytvářeli kus po kusu často různí programátoři, z nichž žádný zcela nevěděl, jak se daný systém bude, nebo jak by se měl, chovat vzhledem ke zbytku základního kódu. Docházelo k nejasnostem, používání částečně fungujících kódů a nevzešlo z toho nic dobrého. Kromě toho, že jsme si pokaždé odpřisáhli, že už se to nestane. Teď jsme do naší každodenní práce zahrnuli pravidelná sezení o designu a vícenásobné revize kódu. Výsledky jsou ohromující.

K zajímavému problému opačného rázu došlo u systému uživatelského rozhraní: tam bylo zase designu až příliš. Náš systém rozhraní je v podstatě knihovna zdrojového kódu, která řídí viditelnou část rozhraní a displeje ve hře. Tento kód napsal programátor s rozsáhlými znalostmi objektově orientovaného programování v C++, které také strašně rád používal. Strávil mnoho týdnů navrhováním a vytvářením systému rozhraní, který byl velmi… dobře… navržen. Privátní datová pole se nacházela pod privátními hlavičkami. Všude se používal operátor „const“. Ale ukazatele typu void skrývající interní datovou strukturu udělaly z odlaďování noční můru. Celý systém byl navržen tak, aby „klient“ nemohl měnit vnitřní údaje systému, eventuelně jim vůbec nedokázal porozumět. A třebaže tento styl programování má své opodstatnění v produkčním týmu o dvou stech programátorech, jehož cílem je prodat simulační knihovnu, zpomaluje práci tří programátorů, kteří společně pracují na nedlouho po sobě jdoucích milnících. Jinými slovy, po ostatních programátorech týmu i ta nejmenší změna systému vyžadovala hodiny zkoumání a ladění, což obvykle končilo tím, že rozhodili ruce, začali nahlas nadávat a proklínat proměnnou typu už_zase_další_problém_s_klávesovou_zkratkou_v_inventáři. Nebyl to pěkný pohled. K extrémům dochází na obou koncích designérského spektra a kterýkoliv z nich dokáže vážně uškodit celkové produktivitě. Ujistěte se, že trávíte čas designováním toho, co je důležité.

Jak pokrátit hru stojící na příběhu

Když děláte hru stojící na příběhu, budete na následující problém narážet po celou dobu vývoje. Jak můžeme to či ono vypustit? Vždyť pak nebude příběh dávat žádný smysl! Naším prvním problémem bylo, že jsme toho museli ze hry vypustit příliš mnoho. K tomu jsme měli dva hlavní důvody. Zaprvé, vzhledem ke krátkému produkčnímu cyklu nám docházel čas a navíc jsme museli hru dokončit na předvánoční trh. Nicméně, mnoho věcí jsme vyhodili jednoduše proto, že příběh byl příliš statický. Ve hře kontroluje detaily hráč. Kdy se přepne kamera, jak bude probíhat boj – to jsou detaily, které většinou návrhář úrovně neovlivní. A je to v podstatě i hlavní důvod, proč lidé hrají počítačové hry. Chtějí takové věci ovládat. Kdyby ne, zašli by si do kina a ušetřili čtyřicet dolarů. A proto herní scénář, který provádí hráče za ručičku nemůže nikdy fungovat. Pokud čtete popis herní scény, který je plný vět typu: „A potom hrdina shodí vraha ze schodů, doběhne ke stolu, vytáhne nůž, ale když se vrátí zpět, vrah už pod schody není,“ tak to není hra, ale film. A navíc dost špatný, když už jsme u toho.

Ve hře předložíte hráči možnosti a je na něm, aby se rozhodl, co udělá. Chcete-li, aby hráč mohl do někoho strčit, musíte tento prvek začlenit do standardního rozhraní. Musí to být něco, co lze dělat opakovaně. Nemá smysl plýtvat časem na design a tvorbu něčeho, co hráč využije pouze jednou. To znamená, že taková činnost musí obstát před testem vícenásobného použití. Lze dotyčnou věc dělat znovu a znovu, aby přesto byla zábavná? Nesnažte se naskriptovat bojové situace, s výjimkou jejich zahájení. Jakmile začnou lítat kulky (nebo phaserové paprsky), je na hráči a herní logice, aby rozhodla, co se stane dál. Nemůžete předpokládat, že hrdina poběží sem nebo tam. Kdo může říct, jestli vůbec někam poběží. Možná z akce pomalu vycouvá. Nebo třeba zůstane stát na místě. Je to prostě na hráči, a proto jsou hry jedinečné. Je to jediný zábavní formát určený pro hromadný trh, kde kupující může skutečně svůj produkt ovládat.

Poté, co jsme ze hry odstranili celou řadu scén, museli jsme zalátat díry, které tím v příběhu vznikly. Naším řešením ve většině případů bylo vytvořit předskriptovanou filmovou sekvenci. Některé z nich zobrazovaly základní činnosti nebo události, ale většina spadala do kategorie „datového bahna“. To jsou scény, které očividně existují pouze proto, aby předaly hráči nějaké informace. V Hidden Evil bylo výsledkem mnoho jedno- či dvouminutových rozhovorů, při kterých postavy stály na místě a povídaly si. Občas se tak dokonce dělo přes komunikátor, což vážně mrazivé napětí nevytvoří. Naším způsobem využití dialogů k předávání informací jsme porušili jedno ze základních pravidel vizuální zábavy, předávat informace společně s obrázky. Místo toho, abyste koukali na někoho, kdo vám podává informace o úrovni, proč neposlouchat jeho hlas, zatímco na svém trikordéru sledujete průlet tímto levelem?

Závěrem

Současnou situaci zde v Presto Studios mohu popsat jedině jako vzrušující. Nikdo si nedělá velké starosti s tím, co jsme při tvorbě Hidden Evil udělali správně nebo špatně, protože konečným výsledkem je, že jsme včas dokončili kvalitní produkt. Jsem však nadšen tím, kolik se tu toho lidé naučili. Naše první kroky směrem k „další velké věci“ vypadají docela slibně. Náš produkční tým se teď více soustředí na vývoj real-time enginu a je lépe zorganizován. Naši programátoři spolupracují na tvorbě nástrojů a enginu nové generace. Lidé, kteří nesdíleli naši vizi, odešli za prací, která jim lépe vyhovuje, a my jim přejeme hodně štěstí. Za svou kariéru jsem se podílel na mnoha projektech, z nichž celá řada nikdy nespatřila denní světlo. Ale ještě nikdy jsem neviděl skupinu lidí, která se tak rychle dokázala tolik poučit ze svých chyb. Doufám, že tato exkurze do našeho projektu, Star Trek: Hidden Evil, vám umožnila spatřit několik eventuálních chyb ve vašem vlastním týmu. A možná vám poskytla jeden nebo dva nápady, jak ho přeorganizovat a posunout blíž k soudržnějšímu týmovému prostředí.

Tým Star Trek: Hidden Evil: Zleva doprava

Horní řada: Lars Liden, Ph.D. – programátor umělé inteligence, Jamey Scott – skladatel/návrhář zvuku, Tim Tembreull – producent, Eric Dallaire – spisovatel/herní návrhář, Derek Becker – výtvarník předrenderovaných scén, Eli Enigenburg – technický ředitel/animátor, Phil Saunders – otrok designu, Mike Brown – animátor
Prostřední řada: Francis Tsai – koncepční návrhář, Sean Keegan – modelář, Victor Navone – výtvarný ředitel, Michael Saladino – hlavní programátor, Naryan Brooks – konstruktér úrovní
Spodní řada: Dan Gregoire – hlavní výtvarník předrenderovaných scén, Casey Steffen – konstruktér světů/úrovní, Keith Gurganus – programátor, Max Elliott – služebně starší programátor/hlavní technický ředitel
Nepřítomni: Michel Kripalani – výkonný producent, Andy Schatz – konstruktér úrovní, Raymond Wong – výtvarník předrenderovaných scén, Steve Kim – animátor, James Rochelle – výtvarník textur, Scott Benefield – návrh nepřátel

Star Trek: Hidden Evil

Vývojář: Presto Studios
5414 Oberlin Drive, Suite 200
San Diego, CA 92121
Vydavatel: Activision

Tým:
Tim Tembreull – producent
Eric Dallaire – spisovatel/herní návrhář
Victor Navone – výtvarný ředitel
Michel Kripalani – výkonný producent
Michael Saladino – hlavní programátor
Max Elliott – služebně starší programátor/hlavní technický ředitel
Lars Liden, Ph.D. – programátor/specialista na umělou inteligenci
Keith Gurganus – programátor
Casey Steffen – konstruktér světů/úrovní
Andy Schatz – konstruktér úrovní
Narayan Brooks – konstruktér úrovní
Francis Tsai – návrhář konceptů
Dan Gregoire – hlavní výtvarník předrenderovaných scén
Derek Becker – výtvarník předrenderovaných scén
Raymond Wong – výtvarník předrenderovaných scén
Eli Enigenburg – technický ředitel/animátor
Mike Brown – animátor
Steve Kim – animátor
Sean Keegan – modelář
James Rochelle – výtvarník textur
Scott Benefield – návrhář nepřátel
Jamey Scott – skladatel/návrhář zvuku

Doba vývoje: Jeden rok

Datum vydání: 16. listopadu 1999

Minimální požadavky: PC Pentium 200 MHz, 32 MB RAM, 3D hardwarová akcelerace volitelná

Hardware použitý při vývoji: PII 400 MHz – programování, PII 400 MHz – real-time grafika, Macintosh G3 – předrenderovaná grafika, šest PowerMaců – renderování

Software použitý při vývoji: Microsoft's Visual C++ Developer 6.0, Microsoft's SourceSafe 6.0, NuMega's Boundschecker 6.0, Intel's Vtune 4.0, Kinematic's 3DSMax 2.5, Play's Electric Image 2.9, AutoDesys' Form Z 2.9.5, Adobe's Photoshop 5.0, After Effects 3.1 a Premiere, Terran Media Cleaner 4.0

Knihovny třetích stran: DirectX 6.0 (využívá DirectDraw, Direct3D, DirectInput), 3Dfx Glide 2.0, Miles Sound System 5.0q, QuickTime 4.0

Michael Saladino byl hlavním programátorem Star Trek: Hidden Evil v Presto Studios.