Ze zákulisí vývoje počítačových her 1. | Kapitola 2
Seznam kapitol
Občas až neuvěřitelné tempo vývoje hardware dnešních počítačů má v podstatě jeden hlavní důvod. Vedle honby výrobců za dalším a dalším ziskem jsou to hlavně nároky moderních her. Ty si žádají stále novější a výkonnější počítače, po kterých všichni tak prahneme. Ale jak taková hra vlastně vzniká? Kdo jsou ti vývojáři a co vlastně dělají?
Kde je tedy chyba? Zdálo by se, že stačí mít dobrý nápad, hodit ho na papír a je vyhráno. Problém je, že tohle je dnes schopný udělat skoro každý a papír plný vašeho holedbání není dostatečnými důkazem toho, že hru dokáže udělat i když dostanete finanční prostředky. Chybí vám totiž technologické demo nebo ideálně vertical slice... Existuje jistá šance, že se vám podaří uzavřít smlouvu i bez nějaké ukázky, ale to v případě, když toho za sebou máte opravdu hodně, jste s vydavatelem extrémně zadobře a jedná se o menší projekt. Nutnosti něco předvést nejsou ušetřena ani opravdu velká studia.
A to je ta uzavřená brána, před kterou končí amatérské projekty. Pro jakékoliv demo už potřebujete mít engine, potřebujete mít nějaký obsah a hlavně to nesmí vypadat, jako že jste se právě začali učit pracovat s vaším prvním 3D programem. Jak jste již jistě bystře odtušili, tohle všechno už samo o sobě stojí spoustu peněz – peněz, které v tuhle chvíli musíte dát často pouze ze svých zdrojů.
Není demo jako demo
Možná, že nejste zcela srozuměni s dvěma termíny, které jsem použil v předchozím odstavci. Co to tedy po vás vlastně chtějí za ukázku? Význam slovního spojení technologické demo je celkem zřejmý. Vezmete herní engine a v něm ukážete základní funkčnost hry. Když je to adventura, můžete s postavičkou chodit po jedné úrovni, dovolit hráči sebrat předmět či dva a občas prohodit nějakou tu repliku. Ve střílečce ho necháte chvíli pobloudit koridory nebo někde venku, občas na něj pošlete nějakou nepříliš inteligentní potvoru, která se dá zlikvidovat. To vše v „pracovní“ kvalitě, často spíš s důrazem na vizuální stránku hry než nějakou pokročilou funkčnost. V podstatě tím říkáte „takhle se bude hra zhruba hrát a grafika bude zhruba takováhle“. Pokud máte za sebou dostatek zkušeností, engine ve kterém se vyznáte a nesnažíte se prezentovat něco neskutečně originálního a pracného na implementaci, tak není vytvoření techdema obvykle nijak zvlášť náročné.
Tohle asi nebude pod osmnáct přístupné - zdroj appearstudio.com
Opravdová noční můra je dnes stále více požadovaný vertical slice. Jedná se o „vertikální průřez“ hrou – vaším úkolem je, ukázat víceméně finální funkčnost všech herních mechanizmů a vizuální stránku hry v malé oblasti – třeba v jedné místnosti nebo úrovni. Pokud byste tedy například chtěli vyvíjet scifi RPG, může po vás vydavatel chtít vidět v jedné obrazovce kompletní funkční uživatelské rozhraní i kompletní ovládání postavy. Hrátky s fyzikou jako je ragdoll či zničitelné prostředí, animace postav ve finální kvalitě a stejně tak jejich textury, částicové efekty, shadery... Ideálně byste při hraní toho drobného úseku hry ani neměli nijak zvlášť poznat, že se jedná o prototyp. Jestli vás děsí myšlenka toho, že musíte mít v podstatě kompletně hotovou značnou část hry – přinejmenším co se týká různých jejích subsytémů – abyste mohli vůbec začít reálně jednat s vydavatelem, tak nejste sami.
Je to nebezpečně nastavený systém, ze kterého samozřejmě těží publisher, protože zatímco jeho to nic nestojí, vývojáři musí do hry s nejistou budoucností nacpat nemalé množství peněz. Další nevýhodou je, že takový postup jde proti základní filozofii vývoje počítačových her a to experimentování. Průběžnému testování herních principů, zahazování těch, které nefungují dobře a jejich nahrazování a vylepšování. Dodatečným změnám ve hře které jsou často nejen nezbytné ale i žádoucí.
Návrhy zbraní do hry - sekera vs. rotačák
A navíc o tom, že ani tahle nesmírně pracně připravená herní ukázka nemusí nutně znamenat podepsání smlouvy a takto vynaložené prostředky mohou v podstatě „vyletět komínem“ by mohla vyprávět celá řada vývojářů. Že taková událost může slabší společnost bez problému zlikvidovat je zřejmé a také se to děje. Ale dosti truchlení. Představme si, že všechno dobře dopadlo a na hře se už konečně začíná pracovat.
Herní bible
V tuhle chvíli by tým měl už mít k dispozici design document. Jedná se o jakousi bibli, ve které je popsán veškerý obsah hry a funkčnosti jejích jednotlivých systémů. O tom, jak by měla správně vypadat tato dokumentace se vedou přednášky i spory. V podstatě můžete mít jeden či více (obvykle wordovských) dokumentů nebo interní projektovou wiki. Oboje má svoje pro a proti – například wiki je obvykle vhodnější, pokud dokumentaci upravuje často větší počet uživatelů, na druhou stranu má ale tendence se zanášet nepodstatnými výkřiky a také z ní může být problém vyexportovat v případě potřeby informace v kompaktní a použitelné formě. Každopádně pokud v týmu nevznikají prostoje, všichni vědí, co a jak mají dělat a z existujících podkladů je možné rychle získat veškeré potřebné informace, pak způsob dokumentace bez ohledu na formu funguje správně.
Bible svatá - přístupné od 3 let!
U menších projektů jsou design dokumenty obvykle v rozsahu desítek, u větších pak stovek stran. Opravdu velké projekty typu Mass Effect pak mají ještě speciální dokumenty věnované například pouze postavám (tzv. character bible), které se svým rozsahem blíží kompletní dokumentaci malých her.
Protože už tedy víme, co přesně chceme dělat a máme to pěkně přehledně připraveno, zaměříme se teď na věci techničtějšího rázu. Předně je to engine a otázka použitého middlewaru.
O srdci hry a dalších orgánech
Výběr enginu, na kterém hra poběží, je pochopitelně také jedna ze zásadních – a obvykle nevratných – voleb. Pokud má vývojářské studio k dispozici vlastní kvalitní engine, přesně ví, co od něj může očekávat a jaké jsou jeho limity. V průběhu vývoje hry ho pak jen vylepšuje a ladí. Další výhodou je, že tým je zvyklý na něco, obvykle označovaného jako tools(y) – tedy sadu aplikací, které slouží pro přípravu obsahu do hry, kterou pak zmíněný engine pohání. Je to pochopitelně nějaký druh editoru, ve kterém se scény sestavují, může to být aplikace pro správu assetů - jednotlivých prvků, ze kterých je hra složena, nebo třeba prográmek pro práci s textovou databází. Kvalita těchto aplikací významně ovlivňuje to, jak rychle a pohodlně se dá do hry dostat nějaký ten – hezky česky řečeno - content.
Podívejme se na příklad. Máte venkovní úroveň a potřebujete ji zatravnit. V nejhorším případě si někdo sedne k editoru a začne manuálně umísťovat, rotovat a upravovat měřítko tisícům trsů trav. Kvalitnější aplikace ale umožní například nad mapou terénu zakreslit barevně hustotu trávy a z tohoto obrázku pak do scény jednolité trsy vygenerovat. A kdo jde ještě dál, může mít pro rozmísťování vegetace naprogramovaný vlastní systém a rostliny se mu vygenerují prakticky samy tam, kde by měly růst. Schválně – kdo by radši trávil čas u první varianty? :)
Protože však vývoj enginu i toolsů je věc jak finančně tak i časově náročná, je možné pro určitou hru nějaký engine licensovat. Ozvete se jeho tvůrcům, sdělíte jim informace o vašem projektu a získáte časově omezenou testovací verzi, ze které zjistíte, jestli vám engine vyhovuje. Pokud ano, dohodnete se s jeho tvůrcem na ceně. Ta se může celkem významně různit například podle toho, na jaké platformy hra vyjde nebo jaký stupeň podpory budete mít k dispozici. U drahých enginů typu Unrealu už ale obvykle s jejich tvůrcem cenu neřeší přímo vývojář ale publisher, který hru financuje.
Není vše zlato co se třpytí
Může se zdát překvapivé, že i některé enginy z kategorie těch dražších nepředstavují kompletní řešení, které by od nich člověk za tu cenu očekával. Váš draze získaný engine nemusí mít ve svém základu například síťový kód, jakoukoliv formu AI včetně primitivního pathfindingu nebo dokonce ani systém pro přehrávání zvuků a hudby. Důvod je prostý – požadavky vývojářů na tyto oblasti se často liší a na trhu jsou dostupná 3rd party solutions, jinak taky označovaná jako middleware. Je logické, že pokud se nějaká firma specializuje čistě na vývoj specifického AI modulu (jako například Kynogon), bude její výsledný obvykle produkt lepší, než to, co byste dostali jako „bonus“. Proto poté, co je zřejmé, jaký engine budete při tvorbě hry používat, se musíte rozhodnout, které z těchto oblastí dořešíte inhouse a na co koupíte již hotový produkt.
Pixaři s enginem problém nemají...
Pokud máte peníze, můžete se chovat jako dítě v cukrárně. Je libo opravdu kvalitní AI? Nestačí vám pathfinding, ale chcete, aby vaše postavy při chůzi analyzovaly terén na potenciální rizika, mířily do oken a za rohy? Pak si dokoupíte třeba Kynapse od zmiňované firmy Kynogon. Její programátor obvykle přijede do vaší společnosti a s těmi vašimi během pár dní (v závislosti na kvalitě vašeho enginu a jeho dokumentace) systém zaimplementuje. Chcete vytvářet GUI do hry ve Flashi? Je tu Scaleform GFX. Obyčejná ragdoll fyzika vám připadá nudná? Koupíte Euphorii. A jestli se vašim grafikům nechce modelovat každý strom a keř do hry, pak je tu osvědčený šlágr – sada vegetace Speedtree. Když ji zaimplementujete – což obvykle nebývá problém, protože dražší enginy už s ní tak trochu počítají – můžete okamžitě vytvořit husté lesy a louky. Pokud jste spustili Gothic, nového onlinového Conana, Silverfall, Oblivion, Zaklínače, GTA IV nebo třeba poslední Settlery pak jste se se Speedtree setkali.
Takže jakmile máte ten svůj nadupaný engine a všechno, co k němu patří, můžete se pustit do opravdového dělání her. Na to, jak konkrétně tahle fáze vypadá, kdo se jí účastní a jaké problémy se při ní nejčastěji řeší si povíme někdy příště...
