Jak jsem se dostal k vytvoření své Boomer Shooter: Historie vývoje WARAG / Hry / iXBT Live

Ahoj! Dnes vám povím, jak jsem se dostal k vytvoření vlastní boomer střílečky a co z toho vzniklo – jako příklad použiji svou hru WARAG.

pravěk

Všechno to začalo, když jsem byl dítě a hrál klasické střílečky z pohledu první osoby – ty bez tutoriálů, dlouhých filmečků a povinného děje. Spustil jste hru a okamžitě jste se ocitli v akci. Žádné vysvětlování, všechno je intuitivní. Grafika je jasná, stylizovaná, ale jednoduchá a zapamatovatelná. Nejedná se o pseudofotorealismus, jako v traileru na „Zaklínače 4“, sestavený z Unreal attachů a malovaný krajinářským štětcem. Každá textura a úroveň byla vytvořena ručně, s láskou, bez procedurálního generování.

Postupem času jsem chtěl nejen hrát, ale i tvořit. Začínal jsem s mapami pro Half-Life, pak jsem přešel na Cube 2, kde jste si mohli vytvářet vlastní úrovně z hotových materiálů. A samozřejmě FPS Creator Classic, jednoduchý a křivý konstruktor, ve kterém jsem si vytvořil své první hratelné střílečky. Uběhlo více než deset let. Šel jsem se vyvíjet v úplně jiném oboru, ale postupem času jsem si uvědomil, že dělám něco špatně a potřeboval jsem se pokusit splnit si svůj dětský sen – vytvořit střílečku z pohledu první osoby založenou na mých oblíbených hrách. Nezjistil jsem hned, že se tomu říká „boomer shooter“.

Touha vytvářet hry podle kánonů 90. let

Vždycky mě fascinoval přístup k vývoji z 90. let, žádné aktualizace SDK, žádná autorizace s potvrzovacím klíčem, žádné zbytečné prvky v pracovním prostředí – v duchu Unity Hubu nebo těžkopádného uživatelského rozhraní Unrealu. Jak řekl herní vývojář xkoster o tvůrcích DOOMu: „Jsou všichni chlupatí. Je to jako něco, co jsem opravdu chtěl udělat, ale nikdy jsem k tomu neměl příležitost.“

Nebyly žádné nekonečné online kurzy slibující „stát se vývojářem za 30 dní“, po kterých získáte zkreslenou představu o gamedevingu. Kde se jen řídíte šablonami někoho jiného. Nikdo vás nevedl za ruku, všechno záviselo jen na vaší touze porozumět, učit se a dotáhnout to, co jste začali, do konce. Sami jste se do enginu ponořili, studovali, jak funguje, experimentovali s každým prvkem. Tento přístup – prostřednictvím chyb, experimentů a samostatného ponoření – dává hloubku porozumění, nejedná se o povrchní znalosti naučené jen kvůli fajfce v životopise, ale o skutečný základ. To je to, co formovalo skutečné dovednosti a kreativní myšlení, a ne soubor povrchních znalostí podle kontrolního seznamu.

Opensource

Než se budu přímo věnovat enginu, udělám zajímavou odbočku a povím si o svém pohledu na software. Open source je základem, základem mého chápání správné struktury světa informačních technologií, můžeme si připomenout slova Richarda Stallmana: „Uživatel by měl ovládat software, a ne naopak.“ Nechci jen neplatit za software, nechci být vůbec závislý na licencování nebo registraci. I když mainstreamové enginy dnes nabízejí „dostupný“ vstup pro indie vývojáře, jedná se pouze o dočasnou dohodu. Zítra se podmínky mohou změnit, jako se to stalo s Unity, kdy se majitelé enginu náhle pokusili revidovat licenční smlouvu a zavést poplatek za každou instalaci. Poznamenám, že výsledný humbuk umožnil tuto inovaci zrušit, ale byl to hlasitý a indikativní skandál, který dal jasně najevo: nejste vlastníkem projektu, pokud nejste vlastníkem nástroje. Nebo si vezměte příklad enginu Game Maker – i jednoduchá autorizace se tam může kvůli regionálním omezením nebo problémům proměnit v quest.

Samozřejmě, ani open-source enginy nejsou dokonalé. I s nimi se setkávají problémy, konflikty a skandály. Jedním z nedávných je příběh kolem Godotu a jeho forku Redot. I ve světě svobodného softwaru mohou v komunitě vznikat neshody a otázky ohledně projektového řízení. Takové situace však jen zdůrazňují jednu jednoduchou pravdu: Je lepší volit ne populární, ale skutečně bezplatné nástroje.

Chápu naprosto dobře, že tento přístup a aspirace nejsou blízké každému. Ne každý je připraven ponořit se do filozofie svobodného softwaru a pochopit detaily architektury enginu. Ale pro mě je to nedílná součást práce: rozumět tomu, co používám, být schopen to opravit nebo vylepšit a nebýt závislý na rozmarech třetích stran nebo vývojářů.

Výběr motoru

Moje volba padla na GZDoom a později jsem přešel na VKDoom. GZDoom je jeden z nejflexibilnějších a technicky nejvyspělejších portů klasického Doomu. Vznikl z projektu ZDoom, vytvořeného na základě id Tech 1 podle open source kódu DOOMu, a výrazně rozšířil jeho možnosti. Díky podpoře OpenGL, skriptovacích jazyků, 3D modelů, dynamického osvětlení a dalších moderních technologií se GZDoom stal plnohodnotnou platformou pro tvorbu nejen modů, ale plnohodnotných her, a zároveň si zachoval identitu a přístup k vývoji staré školy.

Na konci roku 2023 byl vydán VKDoom, fork původního portu GZDoom. Zachovává veškerou funkcionalitu GZDoomu, ale rozšiřuje ji o nové technologie, jako jsou ray-tracované světelné mapy a dynamické světlo a stín s hardwarovou podporou ray tracingu. Grafický systém byl pro Vulkan přepracován, což ve srovnání s GZDoomem poskytuje vyšší výkon a umožňuje širokou škálu vizuálních efektů. Již v roce 2025 jsem přešel na beta verzi VKDoomu.

Jednou ze silných stránek GZDoomu a jeho derivátů je architektura, která kombinuje zdrojový kód C++ a výkonné vestavěné skriptovací jazyky, z nichž každý hraje důležitou roli:

• ZScript je hlavním nástrojem pro tvorbu logiky. Poskytuje přístup k interním prvkům, jako jsou menu a aktéři, podporuje plnohodnotné uživatelské třídy, struktury, virtuální metody a dědičnost. ZScript se používá k implementaci téměř všech herních prvků: logiky nepřátel, zbraní, vizuálních efektů, rozhraní,
• ACS (Action Code Script) je úžeji zaměřený skriptovací jazyk zodpovědný za události na úrovni mapy: otevírání dveří, pasti, filmečky, ovládání spouštěčů, chování monster a další interaktivní prvky.

Při práci s GZDoom jsem si uvědomil, že se musím ponořit hlouběji a postupně jsem začal studovat C++, abych lépe pochopil vnitřní strukturu a vytvořil si jasnější představu o kódu a možnostech implementace. Za zmínku také stojí, že komunita má mnoho užitečných zdrojů: podrobnou dokumentaci na DoomWiki, průvodce ZScriptem a ACS, stejně jako zdrojové kódy samotných GZDoom a VKDoom, které jsou otevřené ke studiu.

Vývoj

Asi rok jsem se hluboce ponořil do práce s enginem – hodně jsem experimentoval a krok za krokem objevoval stále více jeho možností. V roce 2024 jsem začal Blender ovládat a postupně se zlepšoval ve vytváření vlastních 3D modelů.

WARAG se neobjevil hned, zpočátku jsem měl dvě vývojové větve. Ta hlavní byla postavena na ponuré, grimdark atmosféře v duchu Quake a zaměřená na 3D modely. Za zmínku stojí, že engine podporuje formát IQM s animací kostí a strávil jsem nad jeho zjišťováním spoustu času, ačkoli WARAG později přešel na spriteovou bázi, tato zkušenost mi pomohla lépe porozumět jak samotnému enginu, tak práci s Blenderem (právě díky tomu jsem později dokázal vytvářet animace pro spriteová monstra).

Druhá větev se zrodila spontánně – jako sekundární projekt pro Ludum Dare 57, jeden z největších mezinárodních herních jamů. Rozhodl jsem se vzít za základ téměř slovanský styl – zaujal mě, rychle jsem si poskládal základ: soupeře, zbraně, mechaniku. Ale když jsem se přesunul k tvorbě map, uvědomil jsem si, že mě tato „sekundární“ myšlenka inspirovala mnohem víc. Projekt se rychle rozvíjel a ukázalo se, že tohle není jen prázdné místo pro jam.

Nakonec jsem se pevně rozhodl odstoupit od LD57, ukončit hlavní vývojovou větev a plně se soustředit na tento projekt. Tak se zrodil WARAG – hra, která začala jako zábavný nápad na jam party a nakonec se stala mým hlavním zaměřením.

Plnohodnotný vývoj WARAGu jsem zahájil výběrem vizuální složky a její úpravou ve vztahu k tomu, co již bylo hotové pro LD57. Jako základní styl jsem zvolil směs slovanských a gotických prvků. Doom sloužil jako herní reference – především jako zdroj barevné palety a obrázků monster. A styl a architekturu textur jsem si vypůjčil z Quake, Hexen a Heretic. Začal jsem s referencemi: vytvořil jsem koláž z grafiky, screenshotů a textur, abych si představil, jak by měly úrovně vypadat, jaké barvy by dominovaly, jak by měli vypadat nepřátelé, zbraně a rozhraní. Poté jsem přidal textový popis.

Nejprve jsem si vymyslel monstra. Definoval jsem jejich základní typy: boj zblízka, útok na dálku, behaviorální rysy a metody útoku. Poté jsem začal vybírat vhodné grafiky, sestavovat je do obrázků a na tomto základě vytvářet jednotnou vizuální referenci.

Pak jsem začal vytvářet modely v Blenderu a texturovat je. Pak jsem vytvořil modely zbraní a poté začala fáze animace. Pomocí speciálního pluginu jsem začal modely převádět do sprite a postupně je načítat do projektu.

Později jsem se pustil do kódové základny. Stojí za zmínku, že mi zbylo hodně práce z předchozích projektů, ale o tom později.

Pro tvorbu textur, jak jsem již zmínil, jsem vycházel z her Quake, Hexen a Heretic a prohlížel jsem si také obrázky mnoha historických hradů. Postupně jsem vše shromáždil do jedné koláže, doplnil ji příklady úrovní z jiných her a začal jsem vytvářet vlastní textury.

Zde bylo všechno mnohem jednodušší – hledal jsem příklady jak na internetu (včetně panoramat), tak i v reálném životě, při fotografování interiérových prvků. Poté, co jsem shromáždil kritickou základnu obrázků, začal jsem je zpracovávat: nejprve v jednoduchém Photoshopu (GIMP), kde jsem vytvořil bezešvý základ, poté jsem je načetl do SLK_img2pixel, abych aplikoval paletu a stylizaci. Poté jsem v Aseprite nebo stejném GIMPu provedl finální úpravy – pokud to bylo nutné.

A teď se přesuňme k budování úrovní, psaní kódu a obecné logice. Jak jsem již zmínil, měl jsem trochu práce: Vzal jsem několik experimentálních, nedokončených projektů a spojil je do jednoho. Kód pro stejné monstra už byl z velké části hotový. Jediné, s čím jsem se musel opravdu zapotit, bylo vytváření map (úrovní).

V době aktivního vývoje jsem se tvorbě map moc nevěnoval, i když jsem měl obecnou představu o práci a možnostech doom-builderů, konkrétně o 3D podlahách a flexibilním skriptování. Musel jsem se však ponořit hlouběji, experimentovat a strávit spoustu času studiem všech jemností, abych mohl implementovat přesně to, co jsem si naplánoval. Nyní jsem se v tvorbě map docela dobře propracoval, věnoval jsem tomu více než měsíc, ale stále se zlepšuji a demo verze se v budoucnu dočká vylepšení.

Hlavním objevem pro mě byl ACS a tady se mi velmi hodily mé základní znalosti C++. S jeho pomocí jsem ve WARAGu implementoval mnoho interaktivních prvků – od plošinovění s dočasně stoupajícími plošinami až po vypouštění kyseliny v jedné z lokací. Mimochodem, stojí za zmínku, že kyselina je vlastně 3D podlaha se schopností vznášet se, která se po aktivaci tlačítka skryje pod mapou. Kromě toho prostřednictvím ACS ovládám spawnování monster, a také například souboj s bossem: když hráč překročí určitou čáru, teleport je zablokován sloupy a objeví se boss.

Skybox jsem implementoval zajímavým způsobem – jedná se o samostatnou lokaci s instalovanou kamerou, uvnitř které se nacházejí plovoucí textury, vytvářející efekt pohybující se atmosféry. Navíc jsou použity statické 3D podlahy s průhlednou texturou, které umocňují pocit hloubky a objemu oblohy.

Nakonec jsem se chtěl podělit o postřeh o tom, jak někteří hráči, kteří se s klasickými střílečkami nikdy předtím nesetkali, vnímají mechaniku interakce s prostředím. Jedním z pozoruhodných příkladů je úvodní lokace WARAG, kde je potřeba uhodnout, že se dveře otevírají stisknutím E. Zdálo by se to jako elementární věc. Pro některé se to ale stává překážkou, protože hra vám nikde neříká, co máte dělat. Záměrně jsem odmítl vyskakovací nápovědy a „vizuální trénink“. Původní DOOM, Hexen ani Quake tohle neměly – hráč si prostředí sám prozkoumával, zkoušel, klikal na všechno po sobě a o to šlo.

No, to je asi vše, co jsem vám chtěl říct o mé cestě k vytvoření boomer střílečky. WARAG je stále v aktivním vývoji, ale demo verze je již k dispozici na Steamu, je open source a může se na ni podívat kdokoli.