bachelor-thesis/ch1.tex

\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é 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}