\chapter{Zásady tvorby počítačových her}
\label{chap:refs}

Vývoj her je~obor, který~je~často mylně interpretován širokou veřejností. Existuje všeobecná představa o~tom, jak~by~hry měly vypadat, jaké prvky musí či~nesmí obsahovat, kdo~a~jak~je~má~vyvíjet a~jaká by~měla být jejich cenová politika. Ve~skutečnosti však průměrného uživatele zajímá především míra \emph{zábavy} a~herní zážitek, který za~investovaný čas a~finanční prostředky získá.

Z~pohledu hráče nejsou faktory jako~pracovní podmínky vývojářů nebo~kontroverzní herní mechaniky primárními rozhodovacími kritérii. Klíčovým aspektem je~optimalizace uživatelského zážitku a~zajištění dostatečné interaktivity, plynulosti a~vtažení do~děje, které přímo ovlivňují retenci a~herní ekonomiku.

Jelikož je~zábava vysoce subjektivním konceptem, neexistuje univerzální model hry, který~by~vyhovoval všem uživatelům. Herní design proto~využívá analytických metod, jako~jsou uživatelské testování, behaviorální analýza a~iterativní vývoj, aby~maximalizoval pozitivní odezvu v~cílové skupině hráčů.

\section{Průběh vývoje}
Pro nikoho snad není překvapivé, že~pro~vznik díla je~potřeba nějaká myšlenka, která mu~předchází. V~tomto jsou~hry stejný jako~jiné kreativní odvětví. Je~potřeba, aby~myšlenka byla funkční, a~v~našem případě zábavná. Bohužel hry už~s~většinou odvětví nesdílí aspekt, při~kterém funkčnost myšlenky lze~ověřit již~na~začátku produkce. A~je~to ještě horší, protože~to~můžeme většinou zjistit pouze u~konce. Nezanedbatelná část her proto potom je~zamítnutá, neviditelná nebo dokonce předěláná hned před koncem. O~jednom takovém případu -- který skončil šťastně -- doporučuji si~přečíst v~knize \textit{Blood, Sweat, and Pixels} \cite{schreier2017blood} o~hře Uncharted 4. Autor převypráví rozhovory s~vývojáři her různých žánrů a~velikostí, které~znázorňují unikátní a~zároveň společné překážky v~oboru vývoje videoher.

\subsection{Design dokument} Nedílnou součástí vývoje hry je~iterace nápadů a~celkový popis prostředí a~způsobů produkce. To~vše~v~sobě zahrnuje Design dokument. Ten~může mít různé podoby, jelikož jeho hlavním cílem je~uchovat potřebné nápady na snadno dostupném a~přehledném místě. Souhrn těchto nápadů, jejích propracovanost a~to, jak~dobře spolu fungují, potom tvoří celou hru i~výslednou zábavu. Proto~dobré písemné zpracování pomůže předat myšlenky designéra a~jejich aktuální verzi celému týmu vývojářů.

Design dokument, jenž~tvoří nedílnou součást této práce, byl~vytvořen s~ohledem na~vývoj hry jedním autorem. Z~tohoto důvodu jsou v~něm jednotlivé nápady popsány poměrně stručně až~abstraktně, neboť~sloužil primárně jako~osobní vodítko. V~případě týmového vývoje by~však bylo vhodné dokument rozšířit o~podrobnější popis nápadů a~jejich zamýšlené realizace.

\section{Téma, motivy, příběh, cíl}
Hra by~měla poskytovat nějakou \emph{myšlenku} relevantní pro~hráče, aby~měl zájem si~ji~zahrát. Počáteční myšlenku většinou vytváří a~následně rozvíjí game designer. Ta~následovně může~být zachována i~na~konci vývoje, nebo být zásadně změněná samotnou hrou, jejími mechanikami a~kreativním provedením. Krásný případ je~známá desková hra ,,Landlord's Game'' od~Lizzie Magie později známá jako~,,Monopoly''. Paní Magiová chtěla vytvořit hru, která~by~hráčům představila hrůzy kapitalismu a monopolů tak, že by poskytla hráčům zkušenosti, kde~jeden jedinec neustále a~nevyhnutelně bohatne zatímco zbytek stejně~tak neustále a~nevyhnutelně chudne. Bohužel hráči moc tuhle myšlenku nepochitili. Místo vystrašení z~kapitalismu, naopak rádi zažívali hazard a~možnost ekonomicky zruinovat soupeře.

Způsobů, jak~předat myšlenku hráči, je~nespočetně mnoho. Pro účely této práce proto probereme možnosti předáni myšlenky v~příběhových hrách. Ty~by~měly~mít nějaké ústřední téma, které~se~následně obohacuje příběhy okolo. Je~velmi důležité, aby~okolní příběhy měly \emph{motivy}, aby~následně i~hráč měl motiv je~prožít. Dokonce hráč nemusí znát motivy až~do~konce hry, stačí aby~byla cítit smysluplná návaznost a~pocit možné odměny. Proto je~za~umění považováno i~velkolepé předstírání existence motivů, které~donutí hráče \emph{strávit ve~hře co~největší množství času}.

Samotná tvorba příběhů je~poněkud podobná tvorbě knižní nebo~kinematografické. Jen~je~zapotřebí oživovat a~propojovat nejen postavy a~svět, ale~i~herní mechaniky s~ohledem na~jejich zábavnost, složitost a~technická omezení.

\newpage
\paragraph{Cíle a jejich distribuce}pomáhají hře udržet~si hráče. Pokud například za~sebou následuje několik "nudných" pasáží, nebo~je~hra příliš repetativní, hráč může ztratit zájem. \Cref{fig:pacing} znázorňuje ukázkový příklad pěkné distribuce klíčových momentů. Co~přesně jsou~klíčové momenty, je~na~vývojáři. Mohou to~být důležité momenty v~příběhu, vylepšení postavy hráče, představení nové důležité mechaniky atd. Důležité je~nechat hráče v~každém okamžiku pocítit jeho úspěchy na~začátku tohoto momentu nebo~jeho~konci. Je~to~dost~abstraktní, ale~přesto fungující způsob jak~udržet pozornost hráče a~poskytnout mu zábavu.
\begin{figure}
\centering
\includegraphics[width=.6\linewidth]{img/pacing.pdf}
\caption{Ukázkový graf představující distribuci klíčových momentů a~cesty k~ním. Převzato z~článku \protect\textit{Gameplay Fundamentals Revisited: Harnessed Pacing \& Intensity} \protect\cite{pacingIntensity}.}
\label{fig:pacing}
\end{figure}

\section{Žánr, mechaniky, reference, platforma}
Důležité~je také rozmyslet si~vhodné umělecké a~technické aspekty hry. Například nebude moc zábavné hrát hlavní mechaniku farmářství, pokud hlavní žánr hry je~horor. Správná volba žánru a~mechanik je~tedy klíčová pro~vytvoření konzistentního a~poutavého herního zážitku.

\paragraph{Žánr} Žánr hry určuje její základní atmosféru, pravidla a~často i~cílovou skupinu hráčů. Většinou se~dnes setkáváme s~hybridními žánry, které dokážou poskytnout hráči více obsahu a~tím pádem i~více možné zábavy.

\newpage
Při výběru žánru je~důležité vzít v~úvahu preferované herní mechaniky a~jejich složitost. Například hra zaměřená na~rychlou a~dynamickou akci bude pravděpodobně obsahovat prvky střílečky nebo bojové hry, zatímco narativně založená hra může využívat prvky adventury či~RPG.

\paragraph{Herní mechaniky} Herní mechaniky jsou základní interaktivní prvky, které hráč využívá k~postupu ve~hře. Spravný návrh mechanik zajistí, že~hra bude plynulá, intuitivní a~zábavná.

Při jejich návrhu je~třeba zvážit: jak~mechaniky podporují zvolený žánr, jak~se~budou vyvíjet v průběhu hry a~jak~se~kombinují s~ostatními prvky hry. Například v~hororové hře bude dobře fungovat správa omezených zdrojů pro~zvětšení napětí, zatímco ve~strategické hře budou klíčové rozhodovací prvky a~řízení ekonomiky.

\paragraph{Platforma} Platforma ovlivňuje technické aspekty vývoje i~celkový dosah hry mezi hráči. Každá platforma má~své specifické a~občas i~náročné požadavky. Za~to~ale~odmění hráče vhodnějším ovládáním nebo~unikátním vizuálním zážitkem.

Při~výběru platformy je~nutné zvážit: technická omezení a~očekávání hráčů na~dané platformě. Například mobilní hry často využívají dotykové ovládání a~krátké herní smyčky, zatímco hry pro~PC a~konzole mohou nabídnout komplexnější mechaniky a~delší herní dobu.

\paragraph{Kopírování} Kopírování cizích a~vlastních nápadů je~nedílnou součástí úspěšného vývoje. Hodně se~vyplatí mít přehled ve~vybraném žánru a~mechanikách. Není nic špatného učit~se na~chybách a~úspěších jiných her. Důležité ale~je si~pamatovat, že~neexistuje deterministický vzorec, jak~vytvořit dokonalou kombinaci příběhů, žánrů a~mechanik tak, aby~hra získala oblibu hráčů.

\paragraph{Minihry} Skvělou metodou, jak~rozptýlit hráče od~monotonie herního cyklu jsou~minihry. Přitom je~lze aplikovat kdykoliv. Minihry většinou buď poskytují odměnu, anebo slouží k~relaxaci mezi náročnějšími segmenty hry. Důležité~je, aby~jejich design byl v~souladu s~celkovým stylem hry a~nepůsobil rušivě. Například rytmická minihra ve~fantasy RPG může být zajímavým doplňkem, ale~v~realistické hororové hře by~působila nepatřičně.

\section{Engine}
Jakmile je~rozhodnuto, jak~bude hra vypadat, je~zapotřebí zvolit vhodné prostředí pro~její vývoj. Vývojář sice může vytvořit vlastní herní engine, avšak v~dnešní době to~zpravidla znamená jen~zbytečné komplikace. Proto jsou na~trhu dnes již~běžně dostupná hotová řešení, která~pokrývají většinu potřeb.

Základní funkce herních enginů obvykle zahrnují editor scény, přehrávače a~čtečky různých multimediálních či~digitálních formátů, simulaci fyziky, zpracování uživatelského vstupu a~zajištění kompatibility výstupu mezi různými operačními systémy a~hardwarem. Nad~rámec~toho většina enginů poskytuje i~vlastní univerzální implementaci herních objektů a~mechanik. Například primitivní chůze herní postavy, či~implementace renderingu obrazu a~grafických prvků jako~osvětlení, stíny, odrazy a~případně další. Tedy většinou se~jedná o~technologie, které~se~využívají poměrně často, ale~jejich implementace bývá časově náročná až~nevýhodná.

Vytvářet hru pomoci enginu může mít~i~své nevýhody. Některé technologie, zejména grafické, mohou~být vynucené, čili pevně svázané s~daným enginem, čímž~vynucují určité způsoby použití a~tím~pádem omezují kreativní svobodu. Kromě~toho většina enginů není distribuována zcela zdarma. Vývojáři buď musí předem uhradit licenční poplatky za~middleware, nebo~jsou vázáni na~procentuální odvody z~výdělků, což~je~dnes častější model.

Tato práce je~zamýšlena jako~vývoj 3D příběhové hry s~více žánry a~s~možností dynamického načítání nového obsahu za~běhu. Pro~tyto účely se~nabízí čtyři hlavní enginy na~trhu, přičemž výběr v předchozí práci padl na~Unreal Engine a proto táto navazujiící práce v tom pokračuje. Z~tohoto důvodu veškerý následující sekce, věnované technologickému rozboru či implementaci, se~zaměří výhradně na~možnosti, které~Unreal Engine nabízí.

\paragraph{Unity\protect\footnote{https://unity.com/}} Unity~je nejspíš stále nejpopulárnější volbou v~roce vzniku této práce. Lze na~něm vytvořit hru libovolného žánru a~rozsahu. Má~rozhodně největší komunitu a~rozsáhle návody, jednodušší programovací jazyk C\# a~skriptování herních objektů. Zároveň již~obsahuje možnost načítání obsahu za~běhu, zmíněnou v požadavcích. 

Má ale~své problémy, které pozorný vývojář procití už~v~polovině vývoje jestli ne~dřív. Tvorba dobré grafiky často vyžaduje psaní vlastních HLSL shaderů, což~moc nekoreluje s~jednoduchostí C\#. Navíc grafika často vyžaduje psaní vlastních optimalizačních algoritmů nebo~manuální adaptaci cizích pluginů. Následovně i~samotný C\# vytváří komplikace s~rychlostí běhu programu, obsahem zabrané paměti a~přítomností garbage collectoru. Všechny tyto problémy lze~částečně opravit a~vylepšit, jen~je~potřeba mnoho pokročilých znalostí navíc. Detaily a~zkušenosti vývojářů lze~nalézt online, například~zde\cite{unityComparing}.

V~roce 2019, kdy~vzníkalá předchozí práce, v~Unity byl také problém s~paralelizací hlavního cyklu samotného enginu a~rendrovacích úloh. Byl používán triviální model herní smyčky, který~spouštěl logiku sekvenčně v~hlavním vlákně. Stejně~tak bylo triviální i~spouštění renderovacích úloh bez~dynamického clusteringu a~paralelizace. V celku Unity tehdy ještě nebyl tak~robustní a~nenabízel tolik vývojářských možností resp. oprav. V~den vydání této navazující práce, je~pravděpododně nejlepší volbou pro~jednotlivce ale~i~malé týmy. Proto pro~tuto práci bychom dnes zvolili Unity, kdybychom už~neměli předchozí prototyp postavěný na~Unreal Engine.

\paragraph{Godot\protect\footnote{https://godotengine.org/}} Godot je~velmi diskutovaná novinka, která~se~celkem dobře šíří trhem. Hlavní výhoda je~jeho drobnost a~že~je~úplně zdarma za~všech okolností. Godot je~totiž open source produkt vyvíjený komunitou a~dokonce jeho vývoj je~podpořen některými herními studii či~jinými firmy.

Má~podobné problémy jako~jiné enginy a~něco navíc nefunguje dobře nebo chybí. Například výchozí implementace fyziky a~kolizí není často dostačující nebo nepředvídatelně a~uživatelsky špatně řeší určité okamžiky. Je~ale~vskutku ohromující, co~vše~může nabídnout. I~když většinu nabízených technologií vývojář potřebuje přepsat vlastní rukou, jelikož často nefungují, jak~je~zapotřebí. Příklady jsou k~nahlédnutí online na~forumech\cite{godotRealityCheck} nebo~taky blozích\cite{godotRealityCheck2}.

V~době vzniku hry přiložené k~práci byl~Godot ještě příliš nový a~nevypadal nijak perspektivně. V~den vydání této práce, je~solidní konkurent ve~2D~herních žánrech jako~platformery, logické hry či~mobilní hry.

\paragraph{Unreal Engine\protect\footnote{https://www.unrealengine.com/}} Unreal Engine verze 4 byl kdysi zvolen enginem pro~hru, z~které potom vznikla tato práce. Jeho primární výhodou oproti konkurenci jsou vysoce standardizované postupy neboli pipelines, které~zlevňují nebo vůbec umožňují tvorby her ve~velkých týmech. Celý engine se~navíc chlubí velkými ,,úspěchy'' v~různých technologiích, zejména rendrovacích -- což~probereme v~další sekci -- a~taky odvětvích jako motion design, kinematografie, design architektury a~další.

Nabízené možností jsou vskutku ohromující, když~se~snažíte vybrat budoucí stavební kámen pro vaši~hru. Je~ale~potřeba brát v~úvahu silnou nepřívětivost enginu k~nováčkům, kteří~chtějí udělat něco vlastního mimo již~existující návody. Stejné lze říct o~oficiální dokumentaci, která~je často a~velmi nedostačujicí -- jestli vůbec existuje. Navíc při~snaze udělat něco kompletního pomocí nabízených pokročilých technologií, v~závěru vývojář musí dané technologie ovládnout na~velmi vysoké úrovni a~často i~modifikovat zdrojový kód enginu. V~některých případech technologie jako Nanite nebo Lumen nejde použit pro~dokonalé a~odladěné výsledky, proto se~prostě zahazují -- probereme v~další sekci.

Pokud ignorujeme chybějící dokumentaci, je~Unreal Engine stejný engine jako ostatní. Některé technologie má nesrovnatelně lepší a~některé horší. Lze~najít návody a~neoficiální dokumentaci diky velké komunitě. Dokonce vývojář může samotný engine upravovat podle sebe, protože lze zcela zdarma dostat přístup ke~zdrojovým souborům. Velké týmy tuto nezávislost s~radostí využívají.

\paragraph{CryEngine\protect\footnote{https://www.cryengine.com/}} CryEngine je hodně podobný Unreal Enginu za~výjimkou toho, že~se~specialuzuje jen na~vývoj her. Taky~již~není tolik univerzalní, dokumentace je~ještě míň, komunita je~velmi malá a~přívětivost je snad nejhorší možná. Je~to dost úzce specializovaný engine, který potřebuje silné odborníky k~jeho ovládání.

\subsection{Programovácí jazyk}
Unreal Engine umožňuje programovat pomoci vizuálních bloků tzv. Blueprintů nebo textově v~jazyce C++. I~při~použití pouze jedné z~variant lze vyvinout celou hru. Veškerý potenciál se~ale~projevuje při jejich kombinaci. V~C++ se~skvěle programují komplexní a~nízkoúrovňové prvky, zatímco Blueprinty jsou skvělé pro~skriptování úrovní a~objektů pomocí high-level bloků. Samozřejmě samotné vizuální bloky lze~v~C++ vlastnoručně vytvořit.

Je~to~vše zároveň velmi obsáhlý aspekt Unreal Engine. Začátečníkovi bude celkem dlouho trvat než začne sám něco vymýšlet. Na~první pohled jednoduché vizuální programování je~ve~skutečností velmi komplexní už~samotnou téměř nekonečnou nabídkou funkcí.

\paragraph{Blueprinty} Blueprinty jsou skvělé pro~rychlé a~jednoduché skriptování. Umožňuje~to do~procesu programování hry zapojit členy týmu z~jiných méně technických odvětví. Potom například level designer může iterovat vlastní nápady mnohem rychleji a~nečekat na~programátora, tím~že~si~poskláda vlastní logiku a~hned ji~může vyzkoušet. Spolu s~jednoduchostí jsou zároveň velmi bezpečné. Nefunkční kód se~za~běhu jen~poznamená do~logů a~engine nebude havarovat.

Samozřejmě to~přináší nějaký overhead, hlavně když se~jedná o~práci s~velkými daty. Pokud~ale udržovat Blueprinty s~malým počtem funkcí a~používat reference místo kopírování dat, potom je~overhead zanedbatelný.

Největší nevýhodou je~překvapivě nepřehlednost kódu, která~nejčastěji značí špatný programátorský návrh nebo lenost autora. Totiž velký počet vizuálních bloků a~jejich propojení není možné umístit přehledně na~jednu obrazovku. To~potom vyúsťuje v~nepřehledný mix různých logických částí, které~jsou dost obtížné na~orientaci a~údržbu. Napravit~to nejde ani~rozdělením jedné funkce do~více funkcí v~samotném Blueprintu. Nepřehledný mix propojení bloků se~pouze změní na~nepřehledný mix oken s~ruzným kódem. Správný postup v~tomto případě je~ručně konvertovat logiku z~Blueprintu do~C++.

\paragraph{C++} Práce s~C++ v~Unreal Engine je~hodně podobná práci s~velkými frameworky jako například Qt. Použití čistého C++ je~zcela povolené, ale~takový kód potom nelze použít v~blueprintech a~tedy i~editoru. Unreal Engine proto definuje speciální makra jako například UCLASS a~UFUNCTION pro~možnost integrování kódu buď~přímo blueprintu nebo~aspoň systému reflexe. Makra se~potom zpracovávají ne~macro preprocessor, ale~Unreal Header Tool nebo~Unreal Build Tool, které~slouží jako~generatory kódu. Generatory potom sami generují potřebné funkce a~proměnné pro~systém reflexe a~editor.

V~C++ a~navíc s~otevřeným kódem celého enginu, má~vývojář plnou kontrolu nad~během programu nebo~jeho debugováním. Problém je~ale~použití assetů z~editoru nebo~reference objektů v~herním světě. Jsou~možnosti jak~to~obejít, například statické načtení assetu z~registru pomoci konstantní plné cesty k~assetu nebo~přeiterovat všechny objekty ve~světě. Editor samořejmě není schopen takové reference udržovat v~případě přemístění assetu a~časté iterování přes všechny objekty je~citelná zátěž. Proto ve~většínu případu je~potřeba zpřístupnít celou třídu do~Blueprintu a~v~editoru rovněž vytvořit Blueprint podtřídu, která~bude pouze přiřazovat potřebné reference.

\subsection{Grafika}
V~rukou máme taktéž širokou nabídku technologií a~nástrojů pro~tvorbu grafiky nebo~začlenění do~hry obsahu vytvořeného v~jiném softwaru. Je~ale~potřeba dát~si~záležet na~veškerých nastavení enginu. Těch~nastavení je~velké množství a~rozhodně se~budou iterovat během celého vývoje hry. Výchozí nastavení totiž jsou~příliš univerzalní a~nekompletní. Přestože i~v~základu s~nimi hra vypadá na~dostatečné úrovní, při~hraní bude stálý pocit nedokončenosti produktu nebo~kopírování cizího díla. Většina vývojářů si~totiž nedá zaležet, jak~jejich hra vypadá kvůli úspoře času nebo~technické náročnosti tohoto kroku. Proto se~mnoho her (postavených na~Unreal Engine) vizuálně a~"pocitově" podobá, což~je~mnoha hráčům nepříjemné.

\subsection*{- Materiály}
Materiál je~odborné označení souboru dat a~funkcí, které reprezentují výsledný vzhled objektu, efektu, světla nebo~post-processu vyrenderovaného snímku. Je~to~de-facto vysokourovňový shader, který,~i~přestože je~dost omezený, dokáže generovat skvělý a~kreativní výstup. Případně~lze zdrojový kód materiálu poskytnutého enginem rozšířit o~potřebné funkcionality a~v~případě potřeby napsat i~vlastní render pipeline, jak~to~často dělají nekterá studia.

\paragraph{Substrate\protect\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/overview-of-substrate-materials-in-unreal-engine}}Substrate je~nově vyvíjený systém materiálů, který~se~primárně chlubí jednoduchostí vrstvení textur/materiálů a~celkového návrhu. Vrstvení textur a~materiálů je~jistě pohodlné a~podobá se~klasickému vrstvení v~grafických editorech. Umožňuje~to tvorbu komplexních a~nádherných povrchů za~relativně málo úsilí.

Problémem však je zjednodušenost systému se~zaměřením na~pohodlí generického grafického umělce. Vytváří to~ještě víc omezení pro~grafické a~technické možností a~téměř úplnou nepoužitelnost technických triků.

\paragraph{HLSL shadery} V~Unreal Engine lze napsat a~aplikovat HLSL shadery. Je~to~ale~malo dokumentovaný aspekt a~zahrnuje spoustu práce okolo, narozdil od~toho jak~lehce to~lze zprovoznit v~Unity.

\subsection*{- Osvětlení}
Unreal Engine vyniká bohatým výběrem možností provedení osvětlení. Lze~zde najít různé druhy přímých a~nepřímých zdrojů světel, technik odrazů a~stínů. Nebo taktéž velké množství objemných prostorů pro~ovlivňování světla jako~mlhy nebo~rozptyl a~paprsky. Všechno lze~relativně podrobně nastavit buď~pro~účely výkonu nebo~grafické estetiky.

\newpage
\paragraph{Lumen\protect\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/lumen-global-illumination-and-reflections-in-unreal-engine}} Lumen je~zdánlivě revoluce v~realtime herním osvětlení. Jedná~se o~speciální režim osvětlení a~odrazů, který~umožňuje za~běhu počítat dynamické osvětlení bez~potřeby vytváření lightmap nebo~pracného nastavení ploch odrazů. Vytváří velice kvalitní osvětlení při~vynaložení minimálního úsili.

Nevýhodu, kterou ale~již~autoři UE neprezentují, není jen výrazně větší zátěž na~hardware, ale~i~šum vyrendrovaného osvětlení a~odrazů. Lumen totíž v~reálném čase generuje buffer s~odrazy a~osvětlením ve~velice malém rozlišení a~navíc vynechává náhodně zhruba polovinu pixelů. Potom se~výsledný buffer rescaluje na~potřebné rozlišení a~aplikuje. Celý tento systém se~spoléhá na~zhlazovací metodu Temporal Anti-Aliasing, která~akumuluje výsledky předchozích snímku a~interpoluje je~do~aktuálního. Tak~potom v~klidných scénach šum je~zdanlivě dobře potlačen i~když~ne~kompletně. Ale~v~dynamických scénach neboli rychlejším pohybu kamery, TAA vytváří ghosting efekt nejen na~hranach objektů ale~i~osvetlení s~odrazy, který~často hráčům je~nepřijemný.

\subsection*{- 3D}
Podporován je import 3D modelů z~různých formátů. Navíc k~tomu UE poskytuje dostatečné množství optimalizačních technik jako~např.:
\begin{itemize}
\item Render occlusion culling vykreslující objekty pouze pokud se~nachází v~zorném poli kamery, nebo
\item Level Of Details (LOD) vykreslující různě detailizované verze objektu v~závislosti na~jeho vzdalenosti od~hráče, protože~proč~vykreslovat detaily, které~z~dálky nejsou vidět.
\end{itemize}

\paragraph{Nanite\protect\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/nanite-virtualized-geometry-in-unreal-engine}} Nanite je~další specialita Unreal~Engine~5, která umožňuje vykreslování a~instancování objektů s~miliony až~miliardami trojúhelníků v~reálném čase. Umožňuje tak~použití v~enginu extremně detailních objektů, získaných pomoci skenování objektů v~realitě tzv.~fotogrammetrie.

Technika je~založená na~clustarizaci objektů při~importu a~následně dynamickém streamování pouze viditelných trojúhelníků. Bohužel neumožňuje kompletní vynechání LOD~systému, jak~to~inzeruje tvůrce enginu. Nanite sice může ušetřit spoustu času modeláři, ale~reálný zisk ve~výkonu je~pouze ve~velmi náročných scénach obsahující statické objekty. Proto~LOD stále zůstává nejefektivnější technikou zkrácení vykreslovacího času objektu.

\paragraph{Instancování} Instancování umožňuje zmenšení paměti potřebné pro~reprezentaci skupiny stejných objektů a~výsledně i~zkrácení renderovacího času. Je~postavená na~jednoduché myšlence, že~instance objektů drží v~paměti pouze transformaci, a~zbytek dat je~referencován z~jedíneho pravého objektu. Často se~tato technika používá pro~naplnění světa různými drobnými objekty (instancování) nebo~tvorbu vegetace (foliáž).

\subsection*{- Animace}
Veškeré potřeby pro~animaci libovolného druhu jsou~taktéž pokryté.

\paragraph{Skeleton} Skeleton animace je~založená doslovně na~animování kostry přivázané k~3D modelu. Skupiny trojúhelníků jsou~namapované na~určité kosti, tak~že~při~pohybu kosti je~stejným směrem interpolovaná pozice trojúhelníků. Daný druh 3D~animace může vytvářet velkou zátěž na~procesor zejména při~velkém počtu instancí, jelikož~ten~musí propočítávat pohyb každé kostí vůči hernímu světu a~až~potom odesílat renderovací požadavek na~grafiku. Přesto daná technika tvoří převážnou část všech animací ve~hrách díky jednoduchosti tvorby a~práci s~ní.

\paragraph{Shader} Shader animace je~exotická technika s~myšlenkou přeskočit krok s~výpočtem na~procesoru. Animace se~zakóduje do~textury a~následně je~aplikovaná ve~vertex shaderu jako~offset vrcholů. Výsledně lze~například velmi levně animovat velké hejno ptáků, které~nemusí mít kolizi ve~světě.

\subsection*{- Renderer}
Z~rendererů lze~vybrat mezi~Forward a~Deferred rendererem. Jsou~to~systémy, které~se~starají o~zpracování grafiky a~vykreslování scény. Zajišťují převod 3D~objektů a~jejich vlastností na~obraz, který~se~zobrazí na~monitoru. Renderer pracuje s~osvětlením, stíny a~materiály pro~dosažení realistické nebo~stylizované grafiky. V~Unreal Engine ovlivňuje také dostupné prostředky pro~post-processing.

\paragraph{Forward rendering} Forward rendering je~metoda renderingu, kde~objekty se~renderují pro~každý zdroj světla zvlášť a~výsledné osvětlení je~součtem těchto průchodů. Je~vhodný pro~scény s~malým množstvím světel a~vyžaduje menší paměťovou náročnost. Dnes se~převážně používá v~mobilních a~VR aplikacích, kde~je~důležitá nízka latence.

\paragraph{Deferred rendering} Deferred rendering odkládá aplikaci světelných efektů a~v~první fázi ukládá informace o~geometrii scény do~bufferu (G-buffer). Světla se~aplikují až~v~druhé fázi, což~umožňuje efektivnější práci s~větším množstvím dynamických světelných zdrojů. Tato~metoda se~používá především v~moderních AAA~hrách, kde~je~vyžadována vysoká vizuální kvalita. Je~to~výchozí renderer v~Unreal~Engine, který~navíc umožňuje použití technologií Nanite a~Lumen.

Nevýhodou je~nemožnost použití kvalitních zhlazovacích metod jako~MSAA. MSAA funguje~tak, že~ukládá průměr více vzorků na~pixel během rasterizace, což~dobře funguje u~forward renderingu, kde~se~barva a~hloubka určují okamžitě. V~deferred renderingu se~však barvy a~osvětlení aplikují až~v~pozdější fázi, kdy~se~světelné výpočty provádějí na~pixelech na~základě uložených dat v~G-bufferu. Problém~je, že~MSAA by~muselo být aplikováno na~všechny jednotlivé buffery (normály, hloubku, albedo atd.), což~je~extrémně výpočetně náročné a~neefektivní. Proto se~místo MSAA často používají jiné metody zhlazování, jako~FXAA, SMAA nebo~TAA. Ty~jsou podstatně méně kvalitní a~TAA dokonce způsobuje rozmazávání hran objektů v~dynamických scénach resp. ghosting efekt.

Zároveň takova metoda není schopná poskytnout některé grafické techniky. Například transparentní materiály (např. skla) nebo~subsurface scattering (rozptyl světla při~průchodu objektem nebo dopadu na~něj) se~musí renderovat na~konci ještě jedním průchodem tzv.~forward passem.

\subsection*{- Postprocessing}
Postprocessing je~technika dodatečného zpracování vyrenderovaného obrazu. Většinou se~jedná o~triviální manipulaci barev, ale~lze~tady dělat i~spoustu dizajnových a~technickych triků. Např.~různé glitch efekty, efekty tepelného/nočního vidění~atd. získané pomocí procedurální nebo~statické modulace obrazu. V~deffered rendereru navíc lze~používat screen space techniky, které~používají vyrenderovaný snímek k~rychlé tvorbě odrazů (SSR - Screen Space Reflections) nebo~zastínění (SSAO - Screen Space Ambient Occlusion). 

\subsection*{- 2D}
Je~více způsobů práce s~2D~grafikou, avšak udělat čistě 2D~hru bude problematické. V~oficiální nabídce je~rozhraní Paper~2D\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/paper-2d-overview-in-unreal-engine}, které~vývoj 2D~hry sice zjednodušuje, ale~přesto má pouze základní prvky 2D~enginu. Místy chybí optimalizace, protože soubory v~editoru jsou neracionálně velké a~ve~větších projektech engine začíná být hodně náročný na~hardware. Proto se~pro~2D~hry Unreal~Engine moc nehodí a~je doporučené rozhlédnout~se po~konkurenčních enginech.

\paragraph{UI} UI~lze programovat v~C++ pomoci třídy Slate nebo~přímo pomoci Blueprintů v~editoru. Programování se~Slate je~hodně nízkoúrovňové tedy stejné jako~slepé programování okenní windows aplikace pomocí Win32~API. Mnohem pohodlnější je práce v~editoru, kde~rovnou lze vidět výsledek. Celkově tvorba UI v~Unreal Engine je~jedna z~jeho nejsilnějších stránek mezi konkurenty, i~když se~o~ní~moc nemluví.

Pro~zobrazení UI~nebo jiných 2D~prvků ve~3D bylo vždy možné vytvořit klasickou plochu s~texturou/materiálem nebo~renderovat text do~3D~světa. Samotné renderování textu ve~3D je~implementováno pomoci generace 3D~objektu z~vektorového fontu, což~je často výkonnostně přehnané řešení neboť mesh texty jsou již součástí hotového modelu. Ještě lze použít renderování textu z~předgenerované průhledné rastrové textury fontu. Poslední způsob je~dost rychlý na~implementaci a~výkonnostně nejlepší pokud výstup nemusí být nějak extra kvalitní. Nejlepší možností je~generovat text vektorově v~UI a~následně ho promítnout do~3D~světa, což~je umožněno pomoci již~zmíněných UI~tříd.

\subsection{Zvuk}
Pro práci se~zvuky máme taktéž bohaté možností. Důležité je předem nastavit kompresi a~způsob streamování zvukových dat z~assetů hry. Ještě lepší je rozdělit zvuky do~menších spojitých balíčků assetů. Často totiž chceme zvukovou stopu použít hned v~okamžik nějaké udalostí, a~je~důležité, aby~se~data co~nejrychleji načetla. Samozřejmě taky lze některé zvuky načíst předem a~držet v~paměti procesu. Ale~i~když se~nezdá, zvuky mohou obsadit poměrně velký kus paměti aplikace a~většinou zbytečně, což~také~většina vývojářů ignoruje.

\paragraph{Mixer a Cue} Cue je kontejner pro jeden a~více konkrétních zvuků, který~se~chová jako~jeden samostatný zvuk. V~tomto kontejneru lze~zvuky mixovat nebo~větvit, modifikovat tonalitu, hlasitost, modulaci, dělat přechody a~mnoho dalšího. Navíc veškeré efekty a~jejich intenzitu lze~aplikovat staticky nebo~dynamicky. Dohromady vše~prochází přes~Mixer, který~funguje jako~zjednodušený mixážní pult. Nastavuje a~kombinuje přiřazené zvukové třídy a~může na~nich~aplikovat equalizer.

\paragraph{Dynamická hlasitost} Attenuation je struktura parametrů popisující modifikaci zvuku při~rozdílné vzdálenosti posluchače od~zdroje zvuku. Dohromady tak~popisuje, na~jakou vzdálenost lze~zvuk slyšet a~jak~bude znít ztlumení a~zesílení. Parametry podrobně upřesňují, jak~se~zvuk bude šířit, blokovat, odrážet a~splývat v~prostoru. Většinou je~postačující pouze první základní skupina parametrů popisující objem zvukového prostoru a~funkci, která provádí interpolaci hlasitosti.

\subsection{Hudba}
Během existence Unreal Engine 4 neexistoval téměř žádný oficiální nástroj pro~dynamickou ani~statickou kompozici hudebních linek. Proto~vzníkl jednočlenný tým, který~daný nástroj programoval a~dokonce byl dostupný v~alfa verzi ke~stažení. S~příchodem Unreal Engine 5 práce na~nástroji byla pozastavena a~tedy žádný oficiální nástroj stále neexistuje a~není v~plánu.

Hlavní problém s~hudbou je~synchronizace linek. Hudba je~dost náchylná na~jakékoliv zpoždění neboli desynchronizaci linek, protože i~milisekunda rozdílu může přeměnit nádherně zkomponovanou hudbu v~neposlouchatelnou kaši. Proto~jednoduché přehrání linky v~potřebný okamžik nefunguje. Buď~se~zvukový data načtou pomalu nebo herní tik provede spuštění opožděně, protože~je závislý na~renderovácí frekvenci snímků viz.~\Cref{fig:musicLinking}.
\begin{figure}
\centering
\includegraphics[width=.6\linewidth]{img/musicLinking.pdf}
\caption{Diagram znázorňující desynchronizaci hudebních linek kvůli závislosti spouštění na~snímkové frekvenci hry.}
\label{fig:musicLinking}
\end{figure}

\paragraph{FMOD\protect\footnote{https://www.fmod.com/}} FMOD je middleware audio engine pro~hry poskytující velice silné rozhraní pro~práci se~zvuky nebo~jejich manipulaci. Nejčastěji se~k~němu přiklání pro~tvorbu dynamických hudebních doprovodů, což~vyplňuje hudební mezeru v~UE. Je~to~nejpopulárnější řešení, které~se~používá od~indie po~AAA~hry. Taktéž v~populárních enginech má~integrovanou podporu nebo~poskytuje engine v~podobě samostatného procesu, který~potom může komunikovat s~procesem hry. FMOD~také poskytuje editor zvukových stop a~s~nimi spojených eventů, pro~jednoduché ovládání audia přímo ve~hře.

\subsection{Načítání obsahu}
V~Unreal~Engine načítání obsahu je~realizované v~podobě herních patchů. Umožnuje~to exportovat a~nahrát libovolný asset nebo~kód, což~je~potom znázorněno v~praktické části práce. Nevýhodou takového přístupu je~dlouha iterace a~aplikace patchů v~případě jejích většího množství -- oficiální dokumentace doporučuje nepřesahovat mez~v~100~patchů. V~den psaní práce, UE~neumožňuje bezproblémové načítání nanite objektů.

\paragraph{Zdlouhavé načítání} Načtení i~těch menších assetů může značně pozastavit hru. Proto~je~potřeba načítání nového obsahu provést hned při~načtení celé hry, nebo~zapracovat nad~vhodným malým streamingem dat, který~nezpůsobí velkou zátěž na~hardware.

\paragraph{Kompatibilita} Kompatibilita nového a~starého kódu je~něco, co~může zhavarovat celou aplikaci. Naštěstí UE řeší havarijní stavy a~hra v~případě načtení nekompatibilního nebo~poškozeného obsahu poběží dál, ale~potřebné assety se~již~nenačtou. Nejvíc tento problém se~projevuje s~klasickým kódem v~C++, kde~výsledný strojový kód očekává nějakou proměnnou nebo~funkci v~přesně daném místě paměti. O~něco lepší je~to~se~vším ostatním, protože~vše je propojeno a~voláno relativními nebo~globálními cestami a~názvy. Tak například funkce v~blueprintech jsou~vždy voláné pomoci názvů funkcí v~řetězcové podobě. Stejně~tak proměnné jsou uložené v~runtime generované pomocné třídě. Takové využití víceúrovňové reflexe, umožňuje ošetřit libovolný problém s~kompatibilitou a~zaručit bezpečný běh za~cenu trochu většího zatížení prostředků. Navíc stejnou reflexi v~C++ lze~jednoduše udělat pomoci maker, které~Unreal~Engine poskytuje. Ovšem ošetření kompatibility není~součástí této~práce.

\subsection{Umělá inteligence herních postav}
Nehratelné postavy resp.~NPC jsou~součástí většiny her, protože~pomáhají vyprávět příběh nebo~oživit prostředí. NPC~jako~každý herní prvek lze~napevno navrhnout a~naprogramovat všechny potřebné varianty vzhledů a~použití. Ale~z~designových a~časových důvodů ve~většině případu chceme, aby~NPC~byli více univerzální. Chceme aby~se~mohli samostatně orientovat v~prostředí, pohybovat~se a~občas dokonce reagovat na~okolí a~ovlivňovat~ho.

\paragraph{Behavior tree}resp. strom pravidel je~nejčastěší způsob kódování chování NPC. Takový strom umožňuje efektivní rozhodování a~řízení chování umělé inteligence. Hlavní výhodou oproti jiným přístupům, jako~například konečné automaty nebo~plánování, je~modularita, škálovatelnost, snadná údržba a~současně přehlednost. Samozřejmě má~i~nevýhody, mezi~které zejména patří optimalizace a~náročný návrh složitých víceúrovňových chování.

NPC začíná rozhodování v~kořenu stromu, od~kterého postupuje k~vrcholům s~pravidly. Listy jsou vždy akční vrcholy a,~jak~napovídá~název,~určují akci, kterou~objekt provede. Cestu od~kořene k~listům vytváří řídicí vrcholy, každý~z~nich určuje pořadí a~podmínky přechodu na podřízené vrcholy. Nejčastěji používané jsou:
\begin{itemize}
\item sekvenční resp. Sequence, který~cyklicky spouští své~podřízené vrcholy postupně, dokud některý nevrátí přerušení,
\item selektor resp. Selector, vybírá první podřízené vrchol, který~v~zadaném pořadí má~pozitivně zhodnocené pravidlo,
\item paralelní resp. Parallel, který~spouští podřízený vrcholy současně,
\item a~podmínkové vrcholy, které~rozhodují, zda~pokračovat v~dané větvi, nebo~se~vrátit ke~kořenu.
\end{itemize}

Pomocí těchto pravidel lze~popsat mnoho různých chování postav neboli objektů. UE~navíc poskytuje užitečné systémy pro~pokročilé chování "inteligentních" objektů, jako~například systémy koordinace pohybu. Například navigační síť (navmesh), která~odpovídá objektům místo a~způsob obcházení překážek. K~tomu~jsou k~dispozici i~pokročilejší implementace reakcí chytrých objektů na~zvuký, obraz a~jiné objekty.

\section{Umělá inteligence pro tvorbu obsahu}
Již~dnes se~objevují hry, které~integrují danou technologii. NPC~tak~umí poměrně realisticky a~nekonečně držet konverzaci s~hráčem v~textové a~dokonce i~hlasové podobě s~definovaným typem osobností. Možnosti generování textur a~spritů jsou~na~pohled snad nekonečné. Vývojáři mohou poměrně rychle vygenerovat jednoduchý kód nebo~velké konfigurační soubory a~struktury. Navíc již~existuje a~zdokonaluje se~generování 3D~objektů, videí a~hudby. V~teorii stejná umělá inteligence je~schopná generovat popis a~rozmistění obejktů v~herním světě nebo~vyprávět příběh.

V~současné době díky výkonostním pokrokům se~rozšířují hranice použitelností umělé intelegence a~to~zejména velkých jazykových modelů (Large Language Models). LLM~ukazují skvělé výsledky v~generování obsahu různého charakteru v~poměru lidského času a~ceny.

Celé toto téma je~technicky a~odborně velice zkrácené s~ohledem na~rozsah bakalářské práce. Jednotlivé modely a~práce s~nimi nejsou součástí této~práce. Tato~práce zakládá pouze potřebný koncept pro~integraci umělé inteligence.

\paragraph{Udržení kontextu} Udržení kontextu je~největší problém této technologie. Nejvíce se~to~projevuje při~generování videí, kde~je~zřetelné jak~model má~potíže udržet konkrétní obsah nebo~myšlenku jednotlivých scén a~následně i~vzhled vizuálních objektů. LLM~s~každou další iteraci má poměrně vysokou šanci změnit směr ,,myšlenky''. A~to~proto, že~LLM nemyslí, LLM~je pouze násobení velkého množství matic pravděpodobnostní tzv.~váhové transformery. Tak~například LLM nevytváří logicky souvislý text ale~pouze predikuje další pravděpodobnostně nejvhodnější sekvence textu na~základě trénovacích dat.

Proto zásadní chybou je~použití LLM k~úplné tvorbě nového obsahu. A~správné je~používat LLM pouze jako~nástroj buď pro~tvorbu počáteční verze obsahu nebo~vedlejší obohacení již~existujícího díla. Právě s~touto myšlenkou byl~doprovázen vznik této~práce, díky~níž bude možné otestovat, jak~dobře LLM bude obohacovat již~hotovou počítačovou hru.

\paragraph{Halucinace} Další významnou slabinou LLM jsou halucinace. Jedná~se o~situace, kdy~model generuje nesprávné, zavádějící nebo~zcela smyšlené informace. V~kontextu počítačových her tak~může docházet například k~halucinacím při~generování herních dialogů, příběhu nebo~vizuálních prvků, kde~model vymýšlí neexistující herní mechaniky, postavy či~události, které~nepatří do~hry. Kořen tohoto problému je~stejný jak~v~udržení kontextu, kde~navíc se~to~prohlubuje slabým natrenováním modelu.

Řešení halucinací nejsou dokonalá, ale~mohou výrazně zlepšit stav problémů. K~dispozici je~větší množství metod a~některé dokonce proprietární. V~teorii se~ale~většinou jedná o~metody:
\begin{itemize}
\item retrieval-augmented generation (RAG), která~kombinuje model s~databází obsahující ověřené informace,
\item jemné doladění modelu resp.~fine-tuning, které~spočívá v~dotrenování modelu na~specifických datech (na~datech naši~hry), 
\item a~omezení generativní volnosti pomocí pravidel a~pevně definovaných scénářů, které~se~zároveň kryjí s~kontrolními mechanismy a~pomocí validace výstupů.
\end{itemize}
