\chapter{Zásady tvorby}
\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 engagementu, 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 hry jsou stejný jako každé odvětví. Je potřeba, aby~myšlenka byla funkční/potřebná, a v našem případě zábavná. Bohužel hry už~z~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. Spousta her proto potom jsou zamítnuté, neviditelné nebo dokonce předělány 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/problémy 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 docela různou podobu, jelikož jeho hlavním cílem je uchovat potřebné nápady na rychlém a~přehledném místě. Souhrn těchto nápadů, jejích propracovanost a to jak dobře fungují spolu, 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ářů.

V dizajn dokumentu hry, která je nedílnou součástí této práce, jsou popsany nápady dost kratce až abstraktně. To bylo způsobeno tím, že nad hrou pracoval pouze jeden člověk. V reálném týmu by takový dokument byl ukázkovým příkladem těch špatných i přesto, že obsahuje všechny potřebné náležitostí.

\section{Téma, motivy, příběh, cíl}
Hra by měla poskytovat nějakou \emph{myšlenku} relativní pro hráče, aby ten si hru zahral. Počáteční myšlenku vždy vytváří a rozvíjí vývojář. Ta následovně může být ponechána i na konci vývoje, nebo být co nejvíc změněná samotnou hrou, její mechanikami a kreativním provedením. Krásný případ je známa desková hra ,,Landlord's Game'' od Lizzie Magie později známá jako ,,Monopoly''. Paní Magiová chtěla vytvořit hru s myšlenkou představit hrůzy kapitalismu a monopolí, poskytnutím hráčům zkušenosti, kde jeden jedinec neustale a nevyhnutelně bohatne zatímco zbytek stejně tak neustale a nevyhnutelně chudne. Bohužel hráči moc tuhle myšlenku nepochitili. Místo vystrašení z kapitalismu, ti naopak rádi zažíval hazard a možnost ekonomicky zkrachovat soupeře.

Způsobů jak předat myšlenku hráči je nespočetně mnoho. Pro účely této práce proto probereme poskytování myšlenky v příběhových hrach. Ty by měli mít v kostře nějaké hlavní téma, které se následovně obohacuje příběhy okolo. Je~velmi důležité, aby okolní příběhy měli \emph{motivy}, aby následovně i hráč měl motiv je prožít. Dokonce hráč nemusí vědět motivy až ke konci hry, stačí aby byla cítit smysluplná návaznost a pocit možné odměny. Proto za umění je považováno i~velkolepé předstírání existence motivů, které donutí hráče \emph{stravit 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ábavu, složitost a technická omezení.

\newpage
\paragraph{Cíle a jejich distribuce}pomáhají udržet hráče. \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 procí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. Některé herní žánry musí hra obsahovat a některé budou překážet zážitku. Podobné je to i~s~mechanikami. Například nebude moc zábavné hrát hlavní mechaniku farmářství, pokud cílový žá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}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 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}jsou základní interaktivní prvky, které hráč využívá k~postupu ve hře. Dobrý design 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}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í}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 vyhrála všechny ceny.

\paragraph{Minihry}jsou skvělou metodou, jak rozptýlit hráče od monotonie herního cyklu. 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}
Když už je rozhodnuto jak bude vypadat hra, je zapotřebí vybrat vhodné prostředí pro její tvorbu. Vývojář může vytvořit vlastní engine, ale dnes to většinou přináší pouze zbytečné komplikace. Proto se na trhu často objevují hotová řešení, která pokrývají většinu potřeb.

Tato práce je zamyšlená jako 3D příběhová hra s více žánry a s možností dynamického načítaní nového obsahu za běhu. Pro tyto účely se nabízí 4 hlavní enginy na trhu, ze kterých se v minulosti vybral Unreal Engine. Taky proto celá tato sekce s rozborem technologií enginů bude popisovat technologie dostupné právě v Unreal Engine.

\paragraph{Unity\protect\footnote{https://unity.com/}}je nejspíš stale 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 rozsahle návody, jednodušší programovací jazyk C\# a skriptování herních objektů. Zároveň již obsahuje zmíněnou v požadavku možnost načtení obsahu. 

Má ale své problémy, které ohleduplný vývojář procití už v polovině vývoje. 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 garbage collectoru. Všechny tyto problémy lze částečně opravit a vylepšit, jen je potřeba hromada těžších znalostí navíc. Lze o tom přečíst online \cite{unityComparing}.

V roce 2019 kdy hra přiložena k této práci vzníkalá, byl také problém s paralelizací hlavního cyklu samotného enginu a rendrovacích úloh. V celku Unity tehdy ještě nebyl tak robustní a nenabízel tolik vývojářských možností/oprav. V den vydání této práce, je rozhodně nejlepší volbou nejen pro jednotlivce a malé týmy.

\paragraph{Godot\protect\footnote{https://godotengine.org/}}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í. Má podobné problémy jako Unity a někdy ještě horší. 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í. V dobu vzniku hry přiložené k práci, Godot byl ještě příliš nový a nevypadál nijak perspektivně. V den vydání této práce, je solidní konkurent v některých herních žánrech.

\paragraph{Unreal Engine\protect\footnote{https://www.unrealengine.com/}}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 vychlubuje 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ší.

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, pokud ti 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é úrovně a často i modifikovat zdrojový kód. 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í.

Jestli zapomenout na 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 samotný engine si dovoluje sebe modifikovat, protože lze zcela zdarma dostat přístup ke~zdrojovým souborům. Což velké týmy tuto nezávislost s radostí využívají.

\paragraph{CryEngine\protect\footnote{https://www.cryengine.com/}}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 mizerně 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 vivinout 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, když to 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. A na první pohled jednoduchý vizuální programování je ve skutečností velmi komplexní už samotnou téměř nekonečnou nabídkou funkcí. 

\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. Základní nastavení totiž jsou příliš univerzalní a nekompletní. Přestože i v základu hra snimi 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ž nedají zaležet, jak jejich hra vypadá kvůli lenosti nebo technické náročnosti tohoto kroku. Proto se většina her cítí jak si podobní a nepříjemný pro hráče.

\subsection*{- Materiály}
Materiál je odborné označení souboru dat a funkcí, které reprezentují výsledný vzhled objektu/efektu/světla/postprocesu. 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álů rozšířit na potřebné funkcionality a v případě hodně velké nouze napsat i vlastní render pipeline, jak to často dělají velký studia nebo nezavislé github projekty.

\paragraph{Substrate\protect\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/overview-of-substrate-materials-in-unreal-engine}}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/materiálů je opravdu pohodlné a podobá se klasickému vrstvení v grafických editorech. Umožňuje to tvorbu hodně komplexních a nádherných povrchů za relativně málo úsilí.

Problémem však je zjednodušenost systému s zaměřením na pohodlnost 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}lze v Unreal Engine napsat a aplikovat. Je to ale hodně nezdokumentovaný aspekt a zahrnuje spoustu práce okolo, narozdil od toho jak to je v~Unity před verzi 6.

\subsection*{- Osvětlení}
Unreal Engine vyniká právě 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 a mlhy, technik odrazů a stínů. Všechno lze velmi 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}}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 dotěrného nastavení ploch odrazů. Vytváří velice kvalitní osvětlení za opravdu malo úsili.

Nevýhodu, kterou ale již neprezentují, není tolik trochu větší zátěž na hardware, ale šum vyrendrovaného osvětlení a odrazů. Lumen totíž v reálném čase generuje buffer s odrazy a osvětlení ve velice malém rozlišení a to navíc vynecháva náhodně zhruba polovinu pixelů. Potom výsledný buffer se rescaluje na~potřebné rozlišení a aplikuje. Celé se to spoléha na zhlazovací metodu TAA, která~akumuluje výsledky předchozích snímku a interpoluje jich do aktuálního, což~šum zdanlivě dobře potlačuje ikdyž ne kompletně. Ve výsledku tak potom TAA vytváří ghosting efekt nejen na hranach objektů ale i osvetlení s odrazy, který~dost~bije do oka v dynamických scénach.

\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ř.:

\paragraph{Render occlusion culling}vykreslující objekty pouze pokud se nachází v zorném poli kamery, nebo

\paragraph{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.

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

Technika je založená na předčasné clustarizaci a následně dynamickém streamování pouze viditelných trojúhelníků. Bohužel neumožňuje kompletního vynechání LOD systému, jak to reklamuje 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 stale zustava nejefektivnější technikou zlevnění vykreslovacího času objektu.

\paragraph{Instancování/Foliáž}umožňuje zmenšení paměti potřebnou pro reprezentaci skupiny stejných objektů a výsledně i zlevnění 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 táto technika používa 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é. Akorát UE neposkytuje žádné high-level ovládání přehráváných sekvencí a proto užitelské ovládání je potřeba dodělat navíc manuálně.

\paragraph{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 hrach díky jednoduchosti tvorby a práci s ní.

\paragraph{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, materiály a postprocesovými efekty pro dosažení realistické nebo stylizované grafiky.

\paragraph{Forward rendering}je metoda renderingu, kde se každý objekt renderuje jednotlivě se všemi aplikovanými světelnými efekty. 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á rychlost výkonu.

\paragraph{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 nebo TAA. Ty jsou podstatně méně kvalitní a TAA dokonce vytváří rozmazávání hran objektů v dynamických scénach resp. ghosting efekt.

\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, screen space světelné efekty, efekty tepelného/nočního vidění atd..

\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í hodně 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 pro 2D hry Unreal Engine se moc nehodí a je doporučené rozhlédnout se po konkurenčních enginech.

\paragraph{UI}lze programovat v C++ pomoci Slate třídy nebo přímo pomoci Blueprintů v editoru. Programování se Slate je hodně nízkoúrovňový nýbř stejný jako slepé programování okenní windows aplikace pomocí windows.h knihovny. Mnohem pohodlnější je práce v editoru, kde rovnou lze vidět vizuální výsledek. 

Celkově tvorba UI v Unreal Engine je jedná z jeho nejsilnějších stránek i mezi konkurenty, i když se o ní moc nemluví.

\paragraph{Pro 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 Meshe 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ší, avšak je~nemožné dosáhnout hodně kvalitního výstupu. Nejlepší možností je generovat text vektorově v UI a následně ho projektovat 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é vymožeností. 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četli. 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 Cues} umožňují precizní modifikaci přehravaného zvuku. 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, attenuaci, modulaci, dělat přechody a spoustu 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{Attenuace} 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 někde v zákoutí byl stvořen tým z jednoho člověka, který daný nástroj programoval a dokonce byl dostupný v alfa verzi na githubu. S příchodem Unreal Engine 5 práce nad nástrojem byla pozastavená a tedy žádný oficiální nástroj stále neexistuje a není v plánu.

Hlavní problém s hudbou je synchronizace linek. Hudba hodně netoleruje 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ď zvukový data se~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/}}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 Unreal Engine. 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}
Integrace nového obsahu do hry za běhu obnáší ošetření spousty technických problémů. Nejzávažnější z nich jsou načtení nového obsahu a jeho kompatibilita. Tyto dvě věci ani nejde ošetřit bez značných omezení a proto jsou ponechány na~vývojářech.

\paragraph{Načtení}i těch menších assetů může značně pozastavit hru v načítání. 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}nového a starého kódu je něco co může zhavarovat celou aplikaci. Naštěstí Unreal Engine řeší havarijní stavy a hra poběží dál, ale potřebné nám 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áva 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 resp. globálními cesty 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é ve slovníku variantů. 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}
Nehratelné postavy resp. NPC jsou součástí většiny her, protože pomáhají vyprávět příběh nebo obohatit/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ěji 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, úrčují akci, kterou objekt provede. Cestu od kořene k listům vytváří řídicí vrcholy, každý z kterých 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}

\section{Umělá inteligence pro tvorbu obsahu}
Celé toto téma je technicky a odborně velice zkrácené s ohledem na rozsah bakalářky. Taky tak jednotlivé modely a práce s nimi nejsou součástí této práce. Táto práce zakládá pouze potřebný koncept pro integraci umělé inteligence.

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

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ě. Textury a sprity jsou na pohled snad nekonečné, a k tvorbě nevyžadují umělecký cit nebo znalostí. Vývojáři mohou poměrně rychle vygenerovat jednoduchý kód nebo velké konfigurační soubory a struktury.

\paragraph{Udržení kontextu}je největší problém této technologie. Nejvíc se to projevuje při generování videí, kde je zřetelný jak model má potíže udržet konstantní/konkrétní obsah nebo myšlenku jednotlivých scén a následně i vzhled vizuálních objektů. LLM z každou další iteraci má poměrně vysokou šanci změnit směr ,,myšlenky''. A to proto, že LLM nemyslí, LLM je pouze konvoluce velkého množství pravděpodobnostní. Tak například LLM nevytváří logicky souvislý text ale pouze predikuje další pravděpodobnostně nejvhodnější sekvence textu na~základě trenovaný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}jsou další významnou slabinou LLM. 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ů, questů 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.

\paragraph{Řešení nejsou dokonalá,}ale mohou výrazně polepš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 validaci výstupů.
\end{itemize}