Chapter 2 (#4)

Reviewed-on: #4
Co-authored-by: Oleg Petruny <oleg.petruny@gmail.com>
Co-committed-by: Oleg Petruny <oleg.petruny@gmail.com>

ch1.tex

@@ -15,13 +15,13 @@ Pro nikoho snad není překvapivé, že~pro~vznik díla je~potřeba nějaká my
 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~ten 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.
+Hra by~měla poskytovat nějakou \emph{myšlenku} relevantní pro~hráče, aby~ten 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í.
 
-\paragraph{Údržba pozornosti} 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} na další straně 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.
+\paragraph{Údržba pozornosti} 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} na další straně 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=.5\linewidth]{img/pacing.pdf}
@@ -45,7 +45,7 @@ Při jejich návrhu je~třeba zvážit: jak~mechaniky podporují zvolený žánr
 
 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{Kopírování} Kopírování cizích a~vlastních nápadů je~nedílnou součástí úspěšného vývoje. Vyplatí~se 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áčů.
 
 \newpage
 \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ě.
@@ -63,27 +63,28 @@ Tato práce je~zamýšlena jako~vývoj 3D příběhové hry s~více žánry a~s~
 
 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.
+V~roce 2019, kdy~vzníkala 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.
 
-Unity je~engine otevřený všem žánrům a~mnoha platformam jako~mobilní, VR a~další. Často je~použiván v~menších projektech a~menších týmech například při~vývoji indie her, ale~taky i~při~vývoji velkých her.
+Unity je~engine otevřený všem žánrům a~mnoha platformám jako~mobilní, VR a~další. Často je~použiván v~menších projektech a~menších týmech, například při~vývoji indie her, ale~taky i~při~vývoji velkých her.
 
-\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.
+\paragraph{Godot\protect\footnote{https://godotengine.org/}} Godot je~velmi diskutovaná novinka, která~se~celkem dobře šíří trhem. Hlavní výhoda je~jeho malá velikost 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 firmami.
 
-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}.
+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 vlastnoručně, jelikož často nefungují, jak~je~zapotřebí. Příklady jsou k~nahlédnutí online na~fórech\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.
+V~době vzniku hry přiložené k~práci byl~Godot ještě příliš nový a~nevypadal nijak perspektivně. Dnes 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ší.
+\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.
 
 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í.
 
-Aktuálně UE~se~orientuje na~3D~hry převážně s~grafikou vysoké kvality a~stejně jako Unity podporuje většinu aktuálních platforem. Taky se~skvěle hodí pro~tvorbu filmu, motion design a~realtime simulace. Navíc díky technologiím jako~Nanite a~Lumen začína přebírat trh architektonických rendereru.
+\newpage
+Aktuálně se~UE orientuje na~3D~hry převážně s~grafikou vysoké kvality a~stejně jako Unity podporuje většinu aktuálních platforem. Taky se~skvěle hodí pro~tvorbu filmu, motion design a~realtime simulace. Navíc díky technologiím jako~Nanite a~Lumen začína přebírat trh architektonických rendererů.
 
-\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í.
+\paragraph{CryEngine\protect\footnote{https://www.cryengine.com/}} CryEngine je velmi 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í.
 
-Všechny známé hry na~CE~jsou zaměřené na~velmi propracovanou grafiku a~částo hry s~mechanikami boje nebo~střelby od~první osoby. Nedokázal jsem dohledat žádné 2D~hry nebo~indie, což~je~pochopitelné. 2D~hry není specializace CryEngine a~tvořit indie na~tomto enginu je~neefektivní až~nepřínosné. Taky~často vývojáři her na~CE se~přiznávají, že~je~nutné přizpůsobovat zdrojový kód enginu podle vlastních potřeb, což~ještě~víc odrazuje začátečníky.
+Všechny známé hry na~CE~jsou zaměřené na~velmi propracovanou grafiku a~částo hry s~mechanikami boje nebo~střelby z~pohledu první osoby. Nedokázal jsem dohledat žádné 2D~hry nebo~indie, což~je~pochopitelné. 2D~hry není specializace CryEngine a~tvořit indie na~tomto enginu je~neefektivní až~nepřínosné. Taky~často vývojáři her na~CE se~přiznávají, že~je~nutné přizpůsobovat zdrojový kód enginu podle vlastních potřeb, což~ještě~víc odrazuje začátečníky.
 
 \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.
@@ -96,12 +97,12 @@ Samozřejmě to~přináší nějaký overhead, hlavně když se~jedná o~práci
 
 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, 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~třeba UCLASS a~UFUNCTION pro~možnost integrování kódu buď~přímo do~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.
+\paragraph{C++} Práce s~C++ v~Unreal Engine je podobná práci s~velkými frameworky, 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~třeba UCLASS a~UFUNCTION pro~možnost integrování kódu buď~přímo do~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šíně případů 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~import do~hry grafického 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é.
+V~rukou máme taktéž širokou nabídku technologií a~nástrojů pro~tvorbu grafiky nebo~import do~hry grafického obsahu vytvořeného v~jiném softwaru. Je~ale~potřeba dát~si~záležet na~veškerých nastaveních 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š univerzální 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.
@@ -110,7 +111,7 @@ Materiál je~odborné označení souboru dat a~funkcí, které reprezentují vý
 
 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.
+\paragraph{HLSL shadery} V~Unreal Engine lze napsat a~aplikovat HLSL shadery. Je~to~ale málo 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.
@@ -128,7 +129,7 @@ Podporován je import 3D modelů z~různých formátů. Navíc k~tomu UE poskytu
 
 \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.
+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ích 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áž).
 
@@ -142,27 +143,30 @@ Veškeré potřeby pro~animaci libovolného druhu jsou~taktéž pokryté.
 \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.
 
+\label{sec:forwardRenderer}
 \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. Nevýhodou je například nemožnost použití Screen Space vykreslovacích technik a~omezení na~maximalně 4~dynamických světel na~objekt -- 4~kanály resp.~RGBA.
 
+\label{sec:deferredRenderer}
 \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~Multisample Anti-Aliasing. 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\mbox{-}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 (Fast Approximate Anti-Aliasing) nebo~TAA (Temporal Anti-Aliasing). Ty~jsou podstatně méně kvalitní a~TAA dokonce způsobuje rozmazávání hran objektů v~dynamických scénach resp. ghosting efekt. SMAA (Subpixel Morphological Anti-Aliasing) je skvělá zhlazovací metoda pro deffered rendering, ale není podporováná v Unreal Engine.
 
-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.
+Zároveň deferred shading 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.
 
+\label{sec:screenspace}
 \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). 
+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 designový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~deferred 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.
+Je~více způsobů práce s~2D~grafikou, avšak udělat čistě 2D~hru by bylo 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 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.
 
 \newpage
-\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í.
+\paragraph{UI} UI~lze programovat v~C++ pomoci třídy Slate nebo~přímo pomoci Blueprintů v~editoru. V~Slate prostředí se~programuje nízkoúrovňově, tedy je stejné jako programování okenní aplikace pro Windows pomocí Win32~API bez~přímé vizualizace. 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.
+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 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~je pro~nás přijatelné rozmazání přiblíženého výstupu (kvůli pevnému rozlišení textury). 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.
+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žiku 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 chytrým kontejnerem 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.
 
@@ -179,39 +183,44 @@ Hlavní problém s~hudbou je~synchronizace linek. Hudba je~dost náchylná na~ja
 \label{fig:musicLinking}
 \end{figure}
 
+\label{prg:fmod}
 \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. 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~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~100~patchů.
 
-\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{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 streamingem dat po menších částech, 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 se tento problém 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.
+\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 se tento problém 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 pomocné třídě generované za běhu.
+\newpage
+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, určit 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.
 
+Základní implementaci NPC pozorujeme spíše ve~2D a~textových hrách kvůli jednoduchosti problému. Jedná~se o~strom podmínek IF-ELSE, který~je snadný na~implementaci, ale~hůře se~udržuje a~škáluje.
+
 \paragraph{Behavior tree} Strom pravidel neboli Behavior tree 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ější 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 Sequence, který~cyklicky spouští své~podřízené vrcholy postupně, dokud některý nevrátí přerušení,
+\item Selector, vybírá první podřízený vrchol, který~v~zadaném pořadí má~pozitivně zhodnocené pravidlo,
+\item 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. Postava se tak může řídít navigační síti (navmesh), která~napoví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.
+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. Postava se tak může řídít navigační síti (navmesh), která~napoví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~zvuky, obraz a~jiné objekty.
 
 \newpage
 \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ýkonnostním pokrokům se~rozšířují hranice použitelností umělé inteligence neboli~neuronových sítí (dále jako~NS). NS~ukazují skvělé výsledky v~generování obsahu různého charakteru v~poměru lidského času a~ceny. Nejúniverzálnější z~NS jsou Large Language Models~(LLM) pro~generování textu. Právě pomocí textu dnes předáváme informaci nejen od~člověka k~člověku, ale~i~od~člověka k~počítači. Proto~můžeme tvořit textové modely, které~umí ovládat systémy s~textovým vstupem (příkazové rozhraní OS, kompilátory programovacích jazyků) nebo~generovat textové datové struktury (JSON, XML) (viz~\textit{Language Models are~Unsupervised Multitask Learners} \cite{gptPaper}).
 
-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.
+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 osobnosti. 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~rozmístění objektů v~herním světě nebo~vyprávět příběh.
 
-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.
+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. Pro~jednoduchost se~zaměřím pouze na~univerzální~LLM.
 
-\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.
+\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.
 
@@ -224,11 +233,11 @@ Proto zásadní chybou je~použití LLM k~úplné tvorbě nového obsahu. A~spr
 \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}
 
-\section{Tato práce navazuje na předchozí}
-Původně drobné demo hry bylo již vytvořené za~účelem obhajoby maturitní práce. Předchozí práce ale~měla globálně jinou myšlenku a~motivaci. Aktuálně je~hra přeportovaná na~Unreal~Engine~verze~5 a~k~tomu nabyla konzistentního game designu a~příběhu. Stejně tak byl~předělán veškerý kód a~architektura herní logiky. Od~původní prace zbyly pouze:
+\section{Rozvoj předchozího konceptu hry}
+Původně drobné demo hry, na které tato práce navazuje, bylo vytvořené za~účelem obhajoby maturitní práce. Předchozí práce ale~měla globálně jinou myšlenku a~motivaci. Aktuálně je~hra přeportovaná na~Unreal~Engine~verze~5 a~k~tomu nabyla konzistentního game designu a~příběhu. Stejně tak byl~předělán veškerý kód a~architektura herní logiky. Od~původní prace zbyly pouze:
 \begin{itemize}
-\item většina 3D modelů s~animacemi (1/10~od~aktuálního množství),
-\item některé UI elementy a~textury (1/4~od~aktuálního množství),
+\item 3D modely s~animacemi (přibližně desetina současného obsahu),
+\item některé UI elementy a~textury (přibližně čtvrtína současného obsahu),
 \item level design prvního herního levelu~a
 \item koncept herního světa a~hlavní téma příběhu.
 \end{itemize}

ch2.tex

@@ -1,103 +1,437 @@
-\chapter{More complicated chapter}
-\label{chap:math}
+\chapter{Vývoj hry}
+\label{chap:main}
 
-After the reader gained sufficient knowledge to understand your problem in \cref{chap:refs}, you can jump to your own advanced material and conclusions.
+\paragraph{Koncept} Hra je postavená z pěti úrovní s pohledem převážně z první osoby.
+\begin{itemize}
+\item První level představuje thriller a horror adventuru.
+\item Druhý level je postaven na průzkumu menšího otevřeného světu s hraním miniher.
+\item Třetí level sestává z tří nezávislých hlavolamů s vlastním prostředím a mechanikami.
+\item Čtvrtý level představuje arkádový stealth.
+\item Pátý level představuje hardcorový top-down shooter.
+\end{itemize}
+Každý z levelů vyžaduje společné nebo i specifické ``systémy", které si popíšeme dále v této kapitole. Výjimkou je pátá úroveň, která nebyla dokončena.
 
-You will need definitions (see \cref{defn:x} below in \cref{sec:demo}), theorems (\cref{thm:y}), general mathematics, algorithms (\cref{alg:w}), and tables (\cref{tab:z})\todo{See documentation of package \texttt{booktabs} for hints on typesetting tables. As a main rule, \emph{never} draw a vertical line.}. \Cref{fig:f,fig:g} show how to make a nice figure. See \cref{fig:schema} for an example of TikZ-based diagram. Cross-referencing helps to keep the necessary parts of the narrative close --- use references to the previous chapter with theory wherever it seems that the reader could have forgotten the required context. Conversely, it is useful to add a few references to theoretical chapters that point to the sections which use the developed theory, giving the reader easy access to motivating application examples.
+\section{Přenos starého obsahu}
+Přenos starého projektu na~další major verzi~UE nebyl nijak problematický, dokonce v~editoru je~možnost rychlého exportu assetů do~jiného projektu. Rozhodně tomu pomohlo, že~se~C++~kód nepřenášel, ale~byl napsán znovu. UE~citelně rozšířil seznam dostupných tříd, přitom~některé jsou~již deprecated nebo~odstraněny úplně. Tak~mimo~jiné byly~odstraněny třídy Matinee (bývalý formát a editor animací objektů) pro~podporu novejší třídy Sequencer nebo~(staré) rozhraní PhysX\footnote{PhysX je open-source fyzický engine s hardwarovou akcelerací pro grafiky s CUDA architekturou (GPU společnosti NVIDIA).}, které~je nahrazeno systémem Chaos. Přesto se~něco pokazilo při~exportu objektů s~dynamickou fyzikou (závěsy, které~reagují na~simulaci větru, se~musely předělat).
 
-\section{Example with some mathematics}
-\label{sec:demo}
+Přenos byl~odůvodněn převážně malou velikostí starého projektu a~taky lákavou nabídkou nových technologií, zejména Nanite a~Lumen. Navíc pátá verze Unrealu -- přesněji verze~5.5 -- přinesla značná vylepšení jako:
 
-\begin{defn}[Triplet]\label{defn:x}
-Given stuff $X$, $Y$ and $Z$, we will write a \emph{triplet} of the stuff as $(X,Y,Z)$.
-\end{defn}
+\newpage
+\begin{itemize}
+\item Nový systém zpracování vstupu Enhanced Input\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/enhanced-input-in-unreal-engine}. Místy má~příliš mnoho objektové abstrakce, ale~rozhodně velký krok vpřed. Umožňuje snadné dynamické přepínání různých sad ovládání, dynamické modifikátory a~triggery vstupu (změna senzitivity, víceklik, podržení tlačítka určitou dobu), podpora vstupu více než~jedné periferie naráz a~podpora přeřazení vstupu (např.~změna tlačítka odpovídající skoku herní postavy). Předtím se muselo toto a mnoho dalších částí naprogramovat ručně.
+\item Podporu vektorové grafiky v~UI. Veškeré staré UI~elementy byly~tvořeny pomocí základních vektorových obdélníkových tvarů právě proto, aby~se~vyhnulo použití rastrové grafiky, která~je~velmi závislá na~rozlišení. Aktuálně všechny UI~elementy jsou tvořeny ještě starou metodou, pro~udržení konzistentního vzhledu. V~budoucnu bychom určitě využili této~možnosti.
+\item Přepracované vykreslování textů -- rychlejší vykreslování a~efektivnější využití paměti.
+\item MetaSound\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/metasounds-the-next-generation-sound-sources-in-unreal-engine} pro~přehrávaní nebo procedurální generování zvuků, který~nahrazuje starou třídu~Cue. De-facto se~jedná o~Digital Signal Processing (DSP) grafový engine a~editor. Bohužel jsem nestihl tento nástroj využit v~práci.
+\item World partition systém\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/world-partition-in-unreal-engine}, který~dokáže automaticky rozdělit jeden velký svět na~streamovací kousky a~propojit sdílení dat mezi nimi i~při multiplayer hře přes internet. Taky není využit v~této práci.
+\end{itemize}
+Samozřejmě je~toho mnohem více, ale~většina ostatních vylepšení jako~rovněž nové systémy animací postav Motion Matching\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/motion-matching-in-unreal-engine} nebo~nový fyzikální engine Chaos\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/destruction-overview} neměly vliv na~rozhodnutí.
 
-\newcommand{\Col}{\textsc{Colour}}
+Podrobné informace, jak~každá implementace funguje a~jak s~ní~pracovat, jak~kompilovat a~exportovat projekt, jsou~popsány v~přiložené programátorské dokumentaci.
 
-\begin{thm}[Car coloring]\label{thm:y}
-All cars have the same color. More specifically, for any set of cars $C$, we have
-$$(\forall c_1, c_2 \in C)\:\Col(c_1) = \Col(c_2).$$
-\end{thm}
+\section{Herní logika, systémy, mechaniky}
+\label{sec:systemsAndMechanics}
+\subsection{Architektura}
+Protože Unreal Engine byl~na~začátku vyvíjen primárně pro~online multiplayer hru Unreal Tournament a~dnes~je stejně~tak vyvíjen spolu s~extrémně velkou online multiplayer hrou Fortnite, je~backend enginu velmi abstraktní. 
 
-\begin{proof}
-Use induction on sets of cars $C$. The statement holds trivially for $|C|\leq1$. For larger $C$, select 2 overlapping subsets of $C$ smaller than $|C|$ (thus same-colored). Overlapping cars need to have the same color as the cars outside the overlap, thus also the whole $C$ is same-colored.\todo{This is plain wrong though.}
-\end{proof}
+Například každý svět musí obsahovat vlastní game mode (třída AGameMode), který~funguje jako~správce daného světa -- přestože svět se~může spravovat sám. Veškerá funkcionalita používaná v~singleplayer hrách mohla být přímo v~kódu levelu nebo~v~globální instanci celé hry. Důvodem této abstrakce je~právě nativní podpora multiplayer her, která~potom vývoj takových her zjednodušuje.
 
-\begin{table}
-% uncomment the following line if you use the fitted top captions for tables
-% (see the \floatsetup[table] comments in `macros.tex`.
-%\floatbox{table}[\FBwidth]{
-\centering\footnotesize\sf
-\begin{tabular}{llrl}
-\toprule
-Column A & Column 2 & Numbers & More \\
-\midrule
-Asd & QWERTY & 123123 & -- \\
-Asd qsd 1sd & \textcolor{red}{BAD} & 234234234 & This line should be helpful. \\
-Asd & \textcolor{blue}{INTERESTING} & 123123123 & -- \\
-Asd qsd 1sd & \textcolor{violet!50}{PLAIN WEIRD} & 234234234 & -- \\
-Asd & QWERTY & 123123 & -- \\
-\addlinespace % a nice non-intrusive separator of data groups (or final table sums)
-Asd qsd 1sd & \textcolor{green!80!black}{GOOD} & 234234299 & -- \\
-Asd & NUMBER & \textbf{123123} & -- \\
-Asd qsd 1sd & \textcolor{orange}{DANGEROUS} & 234234234 & (no data) \\
-\bottomrule
-\end{tabular}
-%}{  % uncomment if you use the \floatbox (as above), erase otherwise
-\caption{An example table.  Table caption should clearly explain how to interpret the data in the table. Use some visual guide, such as boldface or color coding, to highlight the most important results (e.g., comparison winners).}
-%}  % uncomment if you use the \floatbox
-\label{tab:z}
-\end{table}
+Protože tento projekt je~zaměřen pro~hru jednoho hráče, práce je~často programována navzdory ustáleným zásadám UE~C++ (guidelines) pro~pohodlí a~rychlost vývoje. Proto~často třídy manažerů systémů, game~modů, instance hráče a~další využívají návrhový vzor Singleton. Přináší~to nejen zmíněné pohodlí, ale~navíc šetří tři až~deset volání getterů, reflexí (castů), vyhledávání v~hash tabulkách a~iteraci polí v~každém místě použití. Přesto nemá žádný vliv na~stabilitu programu a~dokonce šetří výkon zařízení.
+
+Jen pro představu, co~obnáší klasické získání reference na~instanci vlastní třídy hráče na~pozadí: GetGameMode()\textrightarrow GetPlayerController(index)\textrightarrow GetPlayerPawn()\textrightarrow Cast<Class>(). A~blueprinty disponují zkrácenou verzí GetPlayerPawn(index)\textrightarrow Cast<Class>(). V~případě~C++ je~potřeba navíc ověřovat, zda~nějaké z~volání nevrátilo nullptr.
+
+\subsection{Scény a ukládání hry}
+Scény, resp. levely (třídy UWorld a ALevelScriptActor)\footnote{UWorld instance je~přímo celý svět, který~funguje jako~balík metadat a~kontejner pro~veškeré instancované objekty v~něm. ALevelScriptActor je~objekt instancovaný v~UWorld automaticky a~obsahuje uživatelskou logiku světa.}, lze~taktéž získat v~podobě singletonu. Základní implementace byla~rozšířená pro~high level mechanismus volání událostí ve~scéně. Ten~je~zapotřebí například, když~hráč aktivuje spínací plošinu ve~hře a~ta~následně otevře dveře.
+
+Na rozdíl od~jiných enginů, v~UE objekty ve~světě nemůžou referencovat jiné~nezávislé objekty. Jednoduše referenci nelze přiřadit z~důvodu abstrakce popsané v~předchozí podsekci, protože~každý objekt může~mít vlastní herní svět (a~nejen~to). Proto~pokud~plošina z~našeho příkladu chce otevřít dveře, musí~zkusit poslat požadavek správci herního světa, ten~požadavek se~nějak zpracuje a~teprvé~poté správce buď~provede akci otevírání dveří samostatně nebo~zavolá odpovídající funkci v~instanci objektu. Pokud~by~bylo potřeba opustit singleton architekturu pro~podporu paralelní existenci světů, stačí předělat členskou (member) funkci instance světa na~statický multicast delegate\footnote{Delegate jsou obaly na~C++ funkce, lambdy, funkce s~reflexi a~funkce z~Blueprintu. Delegate může~být typu single, pro~uložení reference na~jednu funkci, nebo~multicast pro~uložení dynamického seznamu funkcí. Podrobněji jsou~popsané v~programátorské dokumentaci.}, ke~kterému se~každý svět při~konstrukci bude vázat.
+
+Navíc hra byla rozšířena o~implementaci obnovení hry z~úložených dat. Při~návrhu byla~snaha udělat postup co~nejjednodušší. Hra se ukládá pomoci globální herní instance (třída GameInstance)\footnote{GameInstance je~první objekt vytvořený enginem hned po~úvodním načtení základu enginu a~taky poslední objekt na~destrukci při~vypínání hry.} při~vypínání hry a~načítá taktéž při~spuštění. Byl~využit existující systém serializace v~UE, který~ukládá inventář postavy, jméno levelu a~checkpoint na~něm spolu s~posledním stavem levelu.
+
+\subsection{Interakce}
+Interakce jsou~často řešeny pomocí architektury interface tříd\footnote{Interface třídy jsou~konkurenčním přístupem komponentní architektuře. Interface je~běžná praktika v~OOP (Objektově Orientovaném Programování), která~funguje jako~domluva, že~objekt bude obsahovat určité member funkce. Komponenty jsou~samostatné určité podinstance objektu. Komponentní přístup se~osvědčuje jako~intuitivnější a~více flexibilní zatímco Interface přístup při~vývoji her je~spíše nepříjemné vynucení ze~světa~OOP.} především kvůli populárním návodům vyzdvihující tuto metodu jako~nejlepší ještě~z~doby, kdy~Unreal Engine~4 pouze vznikal. Nevýhodou je~potřeba obsáhlého a~repetitivního nastavení každého objektu, který~chceme zapojit do~mechaniky interakce.
+
+Navrhl jsem komplexní systém pro~správu každého interakčního objektu a~komponent (viz~\Cref{fig:InteractableSystemDiagram}). Objekt dědící třídu AInteractable při~instancování samostatně nastaví a~následně přepíná potřebné kolize. Zároveň spravuje interakční komponenty a~reaguje na~požadavky, které~jsou na~ně směřovány. Komponenty se~dělí na~aktivátory a~modifikátory.
 
 \begin{figure}
 \centering
-\includegraphics[width=.6\linewidth]{img/ukazka-obr02.pdf}
-\caption{A figure with a plot, not entirely related to anything. If you copy the figures from anywhere, always refer to the original author, ideally by citation (if possible). In particular, this picture --- and many others, also a lot of surrounding code --- was taken from the example bachelor thesis of MFF, originally created by Martin Mareš and others.}
-\label{fig:g}
+\includegraphics[width=1\linewidth]{img/InteractableSystemDiagram.pdf}
+\caption{Diagram zpracování systému interakčních objektů.}
+\label{fig:InteractableSystemDiagram}
+\end{figure}
+
+\paragraph{AInteractableActivator} Aktivátory jsou~komponenty s~určitými mechanismy detekce objektů. Instance hráče automaticky vytváří pro~sebe jednu podinstanci každého aktivátoru registrovaného v~enginu. Libovolný objekt může rovněž obsahovat libovolný aktivator. Práce obsahuje klasický způsob detekce objektů pomoci ray~tracingu a~následného dereferencování objektu v~případě nárazu paprsku.
+
+Navíc je~k~dispozici detekce objektů v~zorném poli hráče. Ta~funguje na~zpomaleném snímání určité stencil vrstvy\footnote{Stencil Buffer sousedí s~Z-Bufferem a~má~pouze jeden osmi~bitový celočíselný kanál. Slouží především jako~pomocník při~tvorbě specifických renderovacích technik a~efektů. Nejběžnější použití je~renderování obrysů objektů, označení objektů pro~následné zpracování v~nějaké render pipeline a~tvorba portálů.} s~vynecháním většiny render pipeline a~v~malém rozlišení. Zachycený snímek obsahuje pouze hráčem viditelné interakční objekty v~podobě masky. Následně je~maska v~grafickém vlákně zpracovaná pomocí algoritmu vyhledávání komponent z~počítačového vidění, kterou~poskytuje knihovna OpenCV. Nakonec do~středu nalezených komponent se~promítne paprsek a~zachytí objekty (viz~\Cref{fig:InteractableScreenCapture}).
+
+\newpage
+Původně bylo předpokládáno využití HLSL compute shaderu\footnote{High-Level Shader Language je~proprietární shader jazyk používaný v~DirectX.} pro~vyhledání komponent v~textuře, ale~z~časových důvodů jsem nedodělal přenos dat mezi CPU a~GPU, jelikož dohledat dokumentaci o~použití shaderu je~poměrně náročné. Proto~aktuální vyhledávání komponent je~spouštěno na~procesoru a~v~renderovacím vlákně na~moderních zařízeních trvá pět až~deset milisekund. V~praxi se~tento problém často řeší náhodným promítáním velkého množství paprsků nebo~velkého hitboxu napodobujícího tvar pohledového jehlanu kamery. Tato řešení jsou sice~rychlá na~implementaci, avšak~při~větších vzdálenostech vykazují výrazné snížení přesností a~větší spotřebu výpočetních prostředků. Navíc zahrnují časté počítání nárazů na~velké množství objektů, čímž~výkonnostně nejsou o~nic~lepší metody implementované v~této práci.
+
+\begin{figure}
+\centering
+\includegraphics[width=1\linewidth]{img/InteractableScreenCapture.pdf}
+\caption{Debug náhled aktivace interakčních objektů v zorném poli hráče.}
+\label{fig:InteractableScreenCapture}
+\end{figure}
+
+\paragraph{AInteractableModificator} Modifikátory jsou~komponenty s~určitou logikou libovolné modifikace objektu, ve~kterém jsou~instancovány. Tyto~komponenty mohou obsahovat pouze objekty označené jako~interakční (dědí třídu interakčního objektu). Aktuální implementace nabízí modifikátory pro~aktivaci nějaké události pomoci dosahu~``ruky'' nebo zahlédnutím~``očima'' hráče, pohyb a~rotace předmětu v~prostoru, ukládání předmětu do~inventáře hráče.
+
+Z~časových důvodů byla zamítnuta implementace modifikace geometrie objektu, která~by~využívala nového rozhraní Chaos.
+
+Největší přínos nového systému zpracování vstupu v~Unreal Engine~5 se~projevil právě u~modifikátorů. Ty~využívají možnost dynamického přidávání nebo~odstraňování vstupních kontextů za~běhu.
+
+\subsection{Cutscény a Quick Time Events}
+Unreal Engine je~známý~tím, jak~dobře umožňuje animovát scény. Rozhraní a~editor systému Sequencer jsou~přívětivé a~nabízejí široké možnosti. Bohužel~však většina těchto výhod končí mimo samotný editor, jelikož~chybí pohodlné prostředky pro~režii různých souborů animací (totéž platí i~pro~UI animace). Proto byl~dodán systém UCutsceneManager implementující frontu animací spolu s~uživatelským rozhraním pro~jejich přeskakování.
+
+\newpage
+Pro~přiblížení problému vyjmenuji časté potřeby, které~vznikají při~běžném použití animací.
+\begin{itemize}
+\item Zároveň spuštěné animace bojují o~vlastnictví objektů,
+\item animace nelze přetáčet,
+\item u~animace nelze zjistit zpětně zda~byla přehrána až~do~konce, pouze přivázat volání funkce po~ukončení,
+\item systém dokáže určit, zda~se~animace někde přehrává, ale~není schopen ukázat, kde~přesně.
+\end{itemize} 
+
+Převážně pro~použití v~animacích je~implementována fronta rychlých interaktivních událostí (QTE - Quick Time Events), což~jsou~interaktivní UI~elementy na~obrazovce hráče. V~herním průmyslu jsou~využívány zejména v~cutscénách, pro~``hlubší ponoření'' hráče do~děje. Klasickými příklady jsou~animace šplhání herní postavy po~nějaké překážce nebo~kinematografický souboj mezi postavami. Při~takových událostech lze~přiblížit hráče k~dynamické a~napínavé situaci pomocí klikání na~stejně dynamické UI~elementy na~obrazovce v~souladu s~pohybem herní postavy. V~praxi se~objevují i~pokročilejší varianty napodobení děje pohybem myší a~joystickem nebo~gyroskopem ovládače. V~implementaci jsou~k~dispozici eventy jednotného a~vícenásobného klikání a~držení tlačítka v~časovém intervalu.
+
+\subsection{Dialogy}
+Běžně pod~pojmem herní dialog rozumíme způsob vyprávění příběhu hráči v~nějaké mediální podobě. Existující ``dialogový" systém v~UE je de-facto IF-ELSE kontejner, který řeší pouze přepínání cílové věty odesílatele na~základě stavu příjemce. Tedy ``dialogy" představené v~UE jsou~pouze samostatné věty, nikoliv posloupnost vět. O~nedostatku systému pro~tvorbu a~řízení dialogů svědčí návody na~tvorbu vlastních dialogů nebo~vývojářský obchod plný hotových řešení.
+
+Protože kvalitní řešení jsou~placená a~ty~zdarma jsou~často nevyhovující kvality, byla~navržená vlastní implementace. Jedná~se o~frontu, která~umí přehrávat celé tabulky dialogových vět. Dialog, resp.~posloupnost vět společného kontextu, lze~pohodlně zapsat do~tabulkového formátu přímo v~editoru. Jednotlivá věta obsahuje id, text, dobu přehrání nebo~zvukovou stopu. Ve~výsledku lze~do~fronty zařadit několik tabulek, které~se~mohou přehrávat sekvenčně od~n-té věty po~poslední, jednu náhodnou větu nebo~přesně jednu větu podle id.
+
+\subsection{Minihry}
+Herní průchod druhé úrovně je~celý složen z~miniher. V~době vydání práce obsahuje pouze pět~hlavních miniher v~podobě ``proof of~concept''. Z~časových důvodů nebyly vedlejší minihry doplněny o~konečnou grafiku a~optimalizovány pro~zábavnost. Každá z~miniher je~adaptace na~již existující známou hru.
+
+\newpage
+Minihry jsou samostatné objekty, které~může správce scény restartovat nebo~vypnout. Po~spuštění si~minihra sama přepne kontext ovládání na~sebe a~řídí svůj vlastní stav. Po~dohrání nebo~po~předčasném ukončení minihra zobrazí skóre a~vrátí ovládání hráči.
+
+Dostupné zkušební implementace:
+\begin{itemize}
+\item Adaptace flash hry Age of~War. V~pozadí scény s~úklidem učebnic dějepisu jsou~umístěny základny hráče a~soupeře (umělé inteligence, která je popsaná v programatorské dokumentaci). Hráč ovládá minihru pomicí~UI, kde~nakupuje jednotky typu lišící se útočnou silou, vzdáleností útoku a obranou. Peníze získává za~zničení nepřátelských jednotek. Vyhrává ten, kdo~dokáže proniknout přes obranu nepřítele až~k~jeho základně a~zničit~ji. V~aktuální implementaci chybí vylepšení jednotek, zvuky, grafické efekty, modely a~animace jednotek. Přesto~lze vyzkoušet nákup a~``souboj'' jednotek.
+\item Adaptace mobilní hry Subway Surfers. Aktuálně má~minihra nevhodné pozadí, neobsahuje audio a~grafické prvky. Podle návrhu hráč nahání veverku v~lese, která~mu ukradla předmětu důležitého pro~příběh. Pomocí pohybů nahoru, dolů, vlevo a~vpravo se~hráč vyhýbá objevujícím se~překážkam v~lese. Překážková dráha má~šířku tří~běžeckých pruhů a~překážky mohou vyžadovat přeskočení, sklouznutí nebo~úhyb do~strany.
+\item Obdoba počítačové rytmické hry Osu!. Hráč má~za~úkol klikat na~objevující~se hvězdy na~obloze v~souladu s~rytmem hudby (v~pořadí ve~kterém se~objevily). Aktuálně ``hvězdy'' jsou~v~podobě čtverečků, ale~hudba je~zcela hotova. Již~teď lze vyzkoušet klikání během prvních 10~sekund doprovodu.
+\item Adaptace hry Frogger. Hráč pomocí pohybu dopředu, doleva a~dolů potřebuje posouvat se~vpřed po~překážkové dráze. Dráha je~složená z~pěti~pruhů kolmých ke~kameře, a~každý pruh je~složen z~dvanácti políček, na~které~může stoupnout hráč. Náhodně na~krajích pruhu se~objevují divoká zvířata, laviny a~silný vítr (v~originální hře to~jsou auta na~silnici), které~se~posouvají k~opačnému kraji přes všechna políčka a~mohou ukončit běh hráče. Podle návrhu se~minihra odehrává v~ledovém prostředí, kde~hráč prochází sněžnou krajinou. Audiovizuální prvky opět nejsou k~dispozici, ale~již~teď lze vyzkoušet posun dopředu a~úhyb překážkám.
+\item Jednoduchá minihra rybolovu (více podob napříč různými hrami). Hráč má~na~obrazovce svislý obdélníkový indikátor znázorňující vodní hlubinu. Podél indikátoru se~náhodně pohybuje obrázek rybičky, kterou~hráč musí udržovat v~malé pohyblivé zóně. Zóna se~pohybuje automaticky dolů nebo~nahoru držením tlačítka myši (zóna kvadraticky zrychluje/zpomaluje vzhledem k délce držení/puštění tlačítka). V~implementaci chybí zvukové assety a~vyváženost složitosti, ale~je k~dispozici kompletní~UI a~mechanika lovu.
+\end{itemize}
+
+\newpage
+\subsection{Nehratelné postavy}
+Pro~tvorbu NPC (Non-Playable Characters) byly použité základní prostředky enginu. Podle návrhu hry, k~dispozici měly~by~být tři~druhy logiky pro~NPC, ale~z~časových důvodů jsou~implementovány pouze~dvě. Jedno~z~chování je~pouhá chůze k~dynamickým bodům. Toto~základní chování se~potom rozděluje na~střežení oblasti nebo~boj s~hráčem.
+
+Postavy, které~střeží oblast, využívají v~UE5 nový systém vjemů nehratelných postav. Postavy umí reagovat na~zvuky, dotyky nebo~zahlédnutí jiných objektů. Toto~je~využito pro~postavy, které~hlídají vězení v~levelu 4. Ty~patrolují předem navržené trasy a~spouští určité akce, když~zahlédnou hráče.
+
+V~implementaci chybí kompletní logika boje s~hráčem. Aktuálně postavy pouze běží k~hráči pokud ho~zahlédnou. Zbytek nedodělané logiky je~spíš vizuálního charakteru a~spočíval~by v~jednoduchých animacích použití střelné nebo~ruční zbraně ve~hře.
+
+Každé chování využívá Navmesh pro~orientaci na~úrovni.
+
+\subsection{Nastavení}
+Hra využívá enginem nabízenou de/serializaci v~textovém formátu~,,.ini''. Při~exportu hry v~podobě samostatného buildu lze~využívat i~binární formát konfiguračních souborů. Tento~přístup značně zjednodušuje tvorbu konfiguračních proměnných. Díky~tomu stačí pro~tvorbu vlastních parametrů pouze~deklarovat potřebné proměnné v~C++~třídě.
+
+Triviálně se~pracuje s~preferencemi hráče, které~určují hlasitost různých kategorií zvuků nebo~preferencemi ovládání. U~těchto preferencí stačí pouze~přečíst resp.~zapsat hodnotu. Jednoduché to~přestává~být v~momentě nastavení kvality grafiky a~parametrů zobrazení okna aplikace. Zejména změny zaměřené na~okno aplikace mohou způsobit pád~aplikace nebo~ještě hůř zablokovat vstup celého počítače a~donutit uživatele ke~kompletnímu restartování zařízení. Takové~situace mohou nastat celkem běžně, a~nemusí znamenat problém v~aplikaci. Například předčasný zásah~OS k~neodpovídajícímu procesu (hra se~delší dobu načítá po~aplikování nového nastavení).
+
+V~libovolném případě hra musí~být~schopna obstát nečekané závady, a~proto byl~navržen mechanismus obnovení předchozích funkčních nastavení. Po~zvolení nových parametrů a~jejich aplikování, hra nejprv~uloží stávající nastavení a~až~poté aplikuje ty~nová. Po~aplikování a~až se~proces okna vrátí zpět do~renderujícího stavu, v~menu se~objeví okénko po~dobu pěti~sekund očekávající schválení od~uživatele. Pokud~uživatel stihne potvrdit úspěšnou změnu parametrů, jsou~uložené jako~funkční. Pokud~uživatel z~libovolného důvodu změnu neschválí, potom jsou~obnoveny předchozí parametry.
+
+Právě nastavení zobrazení okna (a~výběr zhlazovácí metody) byly implementovány navíc, jelikož~nejsou volně k~dispozici v~high-level implementaci enginu. Jedná~se~o~možnost výběru rozlišení a~jeho třídění podle poměru stran, změna režimu vykreslování okna (bezokenní, okenní bez~rámce, okenní s~rámcem) a~změná obnovovací frekvence. Při~výběru a~nastavení rozlišení se~pracuje přímo s~DirectX\footnote{DirectX je~množina API pro~práci s~grafikou a~převážně pro~počítačové hry.} rozhraním a~zhlazovací metoda se~nastavuje přes~API enginu.
+
+\section{Návrh tvorby generativního obsahu a jeho načítání za běhu}
+\label{sec:contentGenerationAndIntegration}
+
+\subsection{Možností generativních modelů v tomto projektu}
+Herní úrovně jsou navrženy~tak, aby~pokrývaly rozsáhlé herní žánry a~situace, které~dosud~nebyly nebo~nejsou~často využívané s~generovanou tvorbou.
+\begin{itemize}
+\item První level je~zaměřen na~tvorbu hororového obsahu. Je~to~skvělá příležitost vývoje a~použití modelu, který~využívá naše~fyzické, chemické a~psychické znalosti o~lidském organismu, aby~dokázal generovat strašidelný obsah a~následně ho~vhodně začlenit.
+\item Druhý level slouží k~testování modelu schopného tvorby libovolných miniher. Nabízí~se~tady~taktéž online tabulka skóre pro~základní a~vygenerované minihry.
+\item Třetí level existuje pro~generování nových logických úseků a~úkolů a~modifikaci stávajících logických překážek. Například nová logika zapojení kabelů v~elektrotechnické místnosti nebo~přestavba bludiště.
+\item Čtvrtý level umožňuje vyzkoušet generování sekvencí chodeb. Chodby by~musely obsahovat hlídače a~kryty~tak, aby~hráč dokázal nenápadně projít mezi hlídači.
+\item Pátý level bude testovat schopnost navržení herních nepřátel, jejich logiku a~rozmístění na~úrovni. 
+\end{itemize}
+
+\subsection{Návrh architektury}
+Tato práce popisuje pouze návrh generovací pipeline a~její~využití. Aktuálně je k~dispozici pouze systém stahování a~načítání objektů. Generované assety jsou~nahrazeny ručně tvořenými~tak, aby~předvedly načítání libovolného obsahu (interakční objekt, dialog a~kompletní instance nezávislé úrovni) a~integraci obsahu (změna příběhového předmětu v~třetí úrovní). Implementace byla tvořena s~ohledem na~širokou univerzalitu a~nezávislost na~stavu aplikace, aby~v~budoucnu vyžadovala minimální úpravy.
+
+Návrh architektury generování obsahu pro tento projekt je~založený na~použití zřetězení různých modelů a~kontrolních mechanismů. Řetězení modelů resp.~jejich výstupů je dnes běžný koncept, který~slouží k~přírozenému rozkladu komplexních úkolů na~menší kousky. Již~můžeme najít příklady využití takových řetězců pro~nějaké tvůrčí programy, kde~AI pomocník umí pomocí vstupu od~uživatele vygenerovat prototyp požadovaného objektu, nebo~aspoň napovědět, jak~jej~dosáhnout. Například generování popisu množiny 3D~modelů a~jejich následné jednotné generování. Nebo~iterativní parsování webových stránek do~datových struktur a~následné zpracování dat.
+
+Jelikož je plánované generování herních assetů bez~řízení a~úpravy člověkem, bude~zapotřebí navrhnout automatické kontrolní mechanismy. Nejdůležitější pro~nás není~kvalita výstupů modelů, ale~především technická koherence a~funkčnost takových výstupů, které~nám zaručí bezpečný běh programu a~umožní objektu plnit účel v~herním světě.
+
+\newpage
+Navrhovaný je nasazování kompletních instancí řetězců modelů na~soukromých serverech, které~v~různých intervalech nezávisle produkují nové assety. Po~generování budou hotové soubory přemístěny na~veřejné úložiště, odkud~hra ihned~po~spuštění stáhne několik~``náhodných'' assetů (přesnou definici výběru obsahuje \cref{par:contentSharing}).
+
+\paragraph{Fine-tuning} Většina potřebných druhů modelů je~k~dispozici v~podobě open-source a~tedy můžeme je dotrénovat na~vlastních datech. Pro~nás bude zásadní tvorba generativního modelu, který~bude~schopen pracovat s~kódem v~Unreal Engine. Je~to~potřeba pro~programování assetu, nebo~aspoň~jeho~umístění ve~světě hry. Nejjednodušší a~zároveň efektivní cesta je~založená na~fine-tuningu resp.~dotrénování modelu, který~se~již~využívá pro~programování.
+
+Dotrénování může~mít více~podob. Nejspíš by~se~jednalo o~fine-tuning jazykového LLM modelu, který~je schopen výstupu v~jazyce C++. Takový model bychom ``doučili" potřebnou syntaxi Unreal Enginu nebo~tvorbu textového popisu, ze~kterého~by~bylo možné zkonstruovat graf v~Blueprintech. Výsledné blueprinty potom~lze konvertovat do~Python příkazů, které~vytvoří vygenerovaný diagram v~editoru. Nelze jednoznačně říct, který~přístup je~vhodnější. Pro~C++~model je~k~dispozici více dat a~toto prostředí umožňuje větší tvůrčí svobodu, přestože~může zhavarovat aplikaci. U~Blueprintů díky jednodušší ``syntaxi" (předem definované nody a~jejich možností propojení) lze snáze ověřit správnost vygenerovaného výstupu, ale~na~oplátku bude~těžší sbírat trénovací data.
+
+\paragraph{Postup generování}
+Vše~by~začínalo v~textovém modelu, který~vytvoří typ a~popis generovaného objektu. Pomocí nějakého algoritmu se~vybere příslušná množina dalších generovácích modelů, kontrolních mechanismů a~konverzních nástrojů. Asset bude~postupně procházet takovým řetězcem, až~nabude finální podoby. Na~konci bude~vždy kontrolní mechanismus, který~zvaliduje soubor a~ověří funkčnost assetu pomocí unit-testů ve~hře. Pokud~asset neprojde validací, celý postup, soubor a~vstupní popis se~zaznamenají pro~budoucí ruční doladění modelu.
+
+Příklad tvorby interakčního objektu:
+\begin{enumerate}
+\item LLM vytváří popis assetu, v~tomto případě interakční objekt, který~přehrává specifický zvuk a~je~umístěn na~konkrétním místě v~levelu~3.
+\item Kontrolní mechanismus vybírá následující potřebné modely a~nástroje.
+\item Popis prochází modelem generující obrázky.
+\item Obrázky prochází modelem generující 3D~model (nejdřív se~generuje 360°~video potřebného objektu, ze~kterého se~následně generuje mesh).
+\item Další část popisu je~použita modelem generující zvukové stopy.
+\item Poslední část popisu se~vloží do~našeho dotrénovaného programovacího modelu. Tento~model se~zároveň stará o~umístění assetu v~herních světech, protože~je zároveň natrénovaný na~kontextu naše~hry.
+\item Výsledné kousky linkovací mechanismus spojí do~jedné~třídy resp.~vloží do~jednoho Blueprintu. Předtím převede jednotlivé části na~assety v~enginu a~případně aktualizuje cesty referencí.
+\item Konečný asset se~zkouší na~kompilaci a~prochází unit a~smoke testy, pro~které v~UE existuje API. Pokud~tento~krok bude úspěšný, asset je~exportovan v~podobě~DLC nebo~patch~obsahu. Jinak~popis, vygenerováné částí a~výsledek se~logují pro~budoucí investigaci.
+\end{enumerate}
+
+\subsection{Poskytování obsahu}
+\paragraph{Nasazování generátoru} Nezávislé řetězce modelů zjednodušují řízení sítě workerů. Pomocí Docker kontejneru\footnote{Docker je~software umožňující lokální virtualizaci prostředí nazývané kontejnery. Kontejnery jsou~předvytvořené samostatné prostředí s~potřebnými nástroji.} nebo~nasazovacího skriptu by~se~snadno vytvořil další worker (naše~generující jednotka), který~může ihned~začít s~generováním. Vygenerovaný obsah je~poté přemístěn na~veřejné úložiště, tedy~worker nepotřebuje nijak~velké vlastní úložiště. Protože~workery nemusí~odpovídat na~požadavky uživatele v~reálném čase a~plánovaná doba jedné hry je~15-30~minut, generátory nemusí~být~rychlé a~tedy~ani~náročné na~výpočetní prostředky. Nezáleží~nám ani~na~dlouhodobé životnosti workerů, jelikož~modely se~často sekvenčně přepínají (běží vždy pouze jeden model najednou). Takový~přístup přináší flexibilitu v~řízení prostředků a~umožňuje ukládat mezistavy generátorů. Dokonce nepotřebujeme nijak~velkou propustnost sítě, protože~jednoduché assety nemohou přesahovat velikost jednotek megabajtů a~jistě~máme větší časové intervaly mezi~vznikem souborů.
+
+\paragraph{Stahování obsahu}\label{par:contentSharing} Při sdílení obsahu je zapotřebí přemýšlet o zabezpečení tak, aby především nedošlo k poškození majetku hráče a následně i našeho majetku. V takovém procesu útočník může napadnout všechny tři části procesu, tedy:
+\begin{itemize}
+\item naše zařízení, které odesílá nějaká data,
+\item data na cestě k příjemci,
+\item a zařízení příjemce.
+\end{itemize}
+
+Zařízení hráče a~naše servery mohou být napadeny různými způsoby, které~se~odvíjí od~účelů útočníků. Zabezpečení zařízení hráče ponecháváme na~něm a~jeho okolí. Zabezpečení našich zařízení provedeme přísným krytím za~aktivními a~pasivními ochrannými systémovými a~síťovými prvky. Z~důvodu zaměření práce, analýza a~provedení zabezpečení zařízení jsou vynechány, jelikož v~aplikační části můžeme pracovat pouze s~procesem přenosu a~příjmu dat.
+
+Skrytí místa a~způsobu stahování dat pouze zpomalí jejich odhalení a~zvýší nároky na~údržbu. Tedy nejsou zapotřebí žádné autentikační nebo~šifrovací vrstvy pro~obfuskaci (ztěžování analýzy) procesu. Vždy~by~zůstala~možnost zpětnou analýzou (reverse-engineeringem\footnote{Reverse-engineering je~metoda analýzy hotového produktu (v~našem~případě binárního souboru), pro~získání neveřejných informací popisujících funkčnost produktu.}) rozluštit a~napodobit proces. Když~se~nad~tím zamyslíme, volný přístup k~generovaným assetům nám nijak nevadí, je~jednoduchý na~implementaci a~údržbu.
+
+\newpage
+Opravdový problém by~mohl nastat, až~když útočník vymění data během přenosu a~hráč by~mohl spustit ve~hře nebezpečný obsah. Proto~při~komunikaci mezi serverem a~uživatelem použijeme připojení pomocí HTTPS\footnote{Hypertext Transfer Protocol Secure je~protokol pro~šifrovaný přenos dat využívaný pro~poskytování webových serverů.}, které~nás ochrání před~man-in-the-middle útokem\footnote{Man-in-the-middle (MITM) je~druh kyberútoku, ve~kterém útočník tajně sleduje nebo~upravuje komunikaci mezi~dvěma uzly.}. Navíc pro~případ, kdy~útočník přes~naše snahy přesto~prolomí zabezpečení komunikace nebo~serveru zodpovědného pro~odeslání dat, budeme assety posílat s~digitálním podpisem. Podpis se~bude vytvářet na~izolovaných generativních workerech pomocí prvního asymetrického klíče a~ověřovat přímo ve~hře pomocí předinstalovaného druhého klíče. Takovým způsobem vždy ověříme, že~data, které~chceme načíst do~hry, pochází opravdu od~nás a~ručíme za~jejich bezpečnost.
+
+Ve~výsledku hra automaticky zahájí stahování pomocí API a~aktivuje obsah před~začátkem nové hry. Pokud~ověření dat selže, pak~je zahodíme a~zastavíme veškeré připojení. Assety jsou~vybírány náhodně, nebo~se~používá hodnocení získané od~hráčů.
+
+\paragraph{Hodnocení obsahu} Poté, co~si~hráč zahraje s~určitým assetem, máme~možnost získat zpětnou vazbu od~hráče. Hodnocení využíjeme k~váhové manipulaci náhodného výběru a~zároveň jako~data pro~doladění generátorů. Návrh~systému hodnocení staženého obsahu je~již náročnější problém. Úkolem je~umožnit pouze unikátní hodnocení a~pouze od~hráčů, kteří~si~s~tímto obsahem opravdu zahráli. Pokud~bychom neměli žádnou autentikaci, volné~hodnocení nemusí fungovat. Kdokoliv by~mohl spamováním falešných hodnocení přemístit špatně hodnocený obsah do~kategorie lepších a~naopak. Autentifikace tomu~také nezabrání, pouze~ztíží útočníkům práci.
+
+Některé hry v~praxi používají sofistikováné metody využívající detekci nelegální kopie hry, nebo~využití API herních obchodů (achievementy, odznaky, ID~účtu~atd.). Takové metody se~zdají~být účinné, ale~už~dávno se~lehce obchází pomocí triviální simulace odpovědí API.
+
+Táto práce nabízí sledování ID~účtu hráče, který~hru zahrál a~jeho seznam stažených souborů, pokud~hra bude šířená na~platformě Steam. UUID (Unique User Identifier) účtu ví~pouze vlastník účtu, čili~je~to citlivá informace. Proto~před odesláním takových dat je~budeme vždy šifrovat asymetrickým klíčem (veřejným certifikátem webu ze~kterého~zároveň obsah stahujeme). Až~bude hráč chtít ohodnotit ve~hře obsah se~kterým~zahrál, API~zkontroluje zda~UUID~hráče na~Steamu opravdu vlastní hru, že~toto~UUID stahovalo tento~obsah z~našeho serveru a~že~toto~UUID ještě tento~obsah nehodnotilo.
+
+Pokud~by~hra byla~šířená zdarma, bude~potřeba zavést omezení na~N~hodnocení denně pro~jedno~UUID, protože~lze bezproblémově vytvářet falešné účty. Jinak, z~ekonomických důvodů, nám~nebude vadit, že~někdo bude~nakupovat hru víckrát, aby~víckrát nevhodně ohodnotil obsah.
+
+Pořád bude možné reverse-engineerovat~API a~zapsat stažení libovolného obsahu pro~nějaký účet. Taková situace je~zcela zanedbatelná, jelikož~jedno~hodnocení má~malý vliv na~průměr ve~větších číslech.
+
+\subsection{Problémové typy obsahu}
+Již teď je možné předpovědět, co~nebude kompletně fungovat nebo~nebude fungovat v~dostatečné kvalitě.
+\begin{itemize}
+\item Herní obsah tvořený ručně nástroji v~editoru vyžaduje samostatné modely. Například animace objektů na~levelu tvořené v~Sequencer, tvorba~UI~v editorovém designeru, práce~se~zvuky v~Cue, statická tvorba úrovní a~tedy i~Landscape nebo~foliáž a~tvorba fyzických objektů (simulace tkáně, destrukce, pružnosti a~dalších~jevů). Pravděpodobně i~jiné, ale~víc technologií v~této práci využito nebylo.
+\item Materiály též vyžadují vlastní model, ale~jsou tvořeny pomocí grafových prvků podobné blueprintům a~máme k~dispozici velké~množství dat pro~trénování takového modelu. V~základu si~můžeme vystačit bez~generování materiálů a~pouze vytvářet variace barev.
+\item Grafické provedení generovaných objektů může~mít velký dopad na~výkon hry. Optimalizaci může provést další model, který~bude provádět retopologii\footnote{Retopologie je proces zjednodušení složité topologie 3D~objektu bez~značně viditelných změn.} a~pro~tvorbu kolizí lze~použít algoritmus k-DOP\footnote{k-DOP (k-Discrete Oriented Polytope) je~jeden z~postupů obalování složitých 3D~objektu do~jednodušších tvarů.} dostupný~v~UE.
+\end{itemize}
+
+\section{Grafika}
+\label{sec:graphics}
+\subsection{Statické objekty}
+Engine disponuje modely základních tvarů (krychle, koule, válec) a~navíc lze zdarma vzít libovolné assety z~balíčku Starter Content\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/starter-content-in-unreal-engine} nebo~assety použité v~demo projektech společnosti Epic~Games. Přestože assety mají souvislý styl, většinou jsou~zaměřeny na~konkrétní prostředí, a~proto~v~další~hře nemusí najít využití. Zřejmě lze nahrát vlastní modely, které~lze~ručně vytvořit nebo~obstarat na~libovolné online platformě.
+
+V~Unreal Engine verze~5 navíc přidali funkčně bohatý editor 3D~modelů. Tvůrci propagují editor tak, že~v~něm lze vytvářet vlastní modely, protože~množina funkcí dovoluje tvořit hardsurface a~sculpting modely, ale~aktuální provedení není~dostačující ve~srovnání s~dedikovaným softwarem. Drobné editovací funkce na~druhou stranu jsou~užitečné a~šetří čas. Ty~umožňují například editování UV~map, normálových vektorů plošek nebo~změnu středového bodu modelu. ``Best practice'' je~využití tohoto editoru pouze v~případě nouze (například časová výhoda nebo~neexistence původního souboru), jinak~je~v~dlouhodobém měřítku prospěšné editovat původní verzovaný soubor.
+
+\paragraph{Použití cizích assetů} Rychlejší a~občas jednodušší je~získání assetů třetí strany. K~tomu~existují různé volně dostupné webové platformy. Jednou z~takových platform je~FAB\footnote{https://www.fab.com/}, která~navíc má přímou integraci s~UE~5. Objektivně FAB nemá dostatečně velký výběr assetů, jelikož nemá ani~dostatečnou popularitu vývojářů a~tvůrců.
+\newpage
+Příčinou jsou~hlavně větší platformní marže z~prodeje a~sice jednoduché, ale~přesto nevýhodné licencování produktů pro~kupující stranu. Tyto a~další problémy popisují i~jiní uživatelé na~fórech\cite{fabRealityCheck}.
+
+Z~finančních důvodů, v~této praci byly využity pouze produkty dostupné zdarma. Neznamená~to, že~vše~končí pouhým stahováním souborů a~vložením do~editoru. Často (v~této práci všech~100\%) assety nevykazují známky optimalizace nebo~profesionální tvorby. Modely tak~mají některé normálové vektory plošek invertované\footnote{Invertované normály plošek jsou při~tvorbě objektů běžné a~triviálně řešitelný problém, který~často způsobuje, že~ploška ve~scéně není vidět, jelikož~se~vykresluje pouze ve~viditelném směru normálového vektoru a~tedy vytváří ``díry'' v~objektu.}, středové body jsou~nesmyslně mimo, textury a~UV~mapy je~potřeba kompletně předělat. Nejhorší jsou primitivní objekty, které~mají bezdůvodně velké množství vrcholů. V~praxi se~nachází i~náhodné vrcholy bezúčelně existující v~prostoru modelu.
+
+\paragraph{Vlastní tvorba} Vlastnoručně jsou tvořeny modely ze~staré verze hry a~během vývoje této práce se~pouze upravovaly nebo tvořily textury. Standardem v~oboru jsou~obecně Maya\footnote{https://www.autodesk.com/products/maya/overview} nebo~3ds~Max\footnote{https://www.autodesk.com/products/3ds-max/overview} pro~víceúčelové zpracování a~úpravy, ZBrush\footnote{https://www.maxon.net/en/zbrush} pro~sculpting a~Substance~Painter\footnote{https://www.adobe.com/products/substance3d/apps/painter.html} pro~texturování objektu. V~tomto projektu byl použit výhradně Blender\footnote{https://www.blender.org/} a~software pro~editaci obrázkových formátů, které~jsou k~dispozici na~internetu zdarma. Výsledný model lze často bez~problémů rovnou využít v~enginu.
+
+\paragraph{Modeling a Sculpting} Nejprve se~vytváří tvar modelu. Toho se~docílí pomocí modelování polygonů nebo~sculptingu. Obě~metody jsou velmi odlišné a~stejně~tak mají odlišný výstup. 
+
+Sculpting se~provádí především přes~grafický tablet, kde~pomocí různých 3D~štětců se~natahují nebo~smršťují vrcholy a~celý proces napodobuje tvorbu sochy z~plastického materiálu. Především takový přístup se~používá pro~tvorbu organických modelů nebo~modelů s~měkkým povrchem jako~například živé bytosti, rostliny nebo~oblečení. Modeling na~druhou stranu je obecnější zpracování vrcholů, hran a~ploch. Tady se~manuálně přidávají resp.~odebírají a~posouvají vrcholy. Navíc toto~prostředí obsahuje funkce umožňující různé druhy efektivního instancování, množinových operací mezi objekty a~zjednodušených simulací vrcholů. V~takovém prostředí se~tvoří především komplexní resp.~hybridní nebo~tvrdé povrchy jako~například nábytek, architektura nebo~scény se~sculpting modely.
+
+Specifickou sculpting instancí v~enginu je Landscape\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/landscape-overview}, de-facto síť vrcholů předem určené hustoty, kterou~můžeme v~editoru sculptovat a~napodobovat křivý resp.~různě vysoký terén. Manuální sculpting je pomalý a~přináší slabé až~nevyhovující výsledky. Proto místo sculptingu se~používá výšková neboli height~mapa, což~je textura odstínů šedi, kde~každý pixel kóduje výšku v~3D prostoru. Potom stačí naskenovat nějaký povrch v~reálném světě a~získat skvělé výsledky. Stejné height~mapy lze používat i~jako~štětce v~běžném sculptingu, pro~specifické detalizace povrchů, a~samotné height mapy lze získat na~některých online platformách dokonce zdarma.
+\newpage
+Ukázka landscapu je k~dispozici ve~druhé úrovni, kde~povrch terénu jsem vytvořil pomocí textury výšek a~hory jsem tvořil ručně základními štětci. 
+
+\paragraph{Animace} Animace se~tvoří v~dalším kroku modelingu. Pokud jsme předtím vytvořili model pomocí sculptingu, potřebujeme ho importovat do~modeling prostředí. Začíná~se tvorbou umělé kostry z~tzv.~kostí a~kloubů.
+
+Klouby slouží pouze ke~specifikaci hierarchie mezi kostmi tak, že~kost propaguje vlastní otočení a posun na~všechny následující. Navíc specifikují střed rotačního bodu.
+
+Kosti jsou samostatné abstraktní označení pro~nosič prostorových transformací, pro~který~můžeme přiřadit množinu vrcholů. Potom v~logice animace stačí pouze posouvat určité kosti a~předrenderovácí engine bude souvislé modifikovat přiřazené vrcholy. Navíc kosti často modifikují vrcholy podle předem určené váhy pro~každý vrchol, čímž~lze škálovat a~skládat posuny různých kostí na~určitých vrcholech. Jen~je~potřeba brát v~úvahu, že~skeleton animace neboli modifikace provedené předrenderovacím enginem jsou spuštěné na~CPU, jelikož jsou řízeny logikou herního světa. Naštěstí moderní procesory s~instrukčními sadami AVX a~více jádry v~takových úlohách dokážou předvádět poměrně skvělé až~nadbytečné výkony.
+
+V~Unreal~Engine~5 přidaly rozhraní pro~tvorbu skeleton animací přímo v~editoru. Předtím bylo možné pouze hotové animace naimportovat. Uvnitř editoru je příliš mnoho způsobů jak~režírovat animace (myšleno přehrávání, slepení přechodů, modifikace, skládání atd.) a~lze se~v~tom jednoduše ztratit. V~základu je předpokládaná tvorba stavového automatu, který~bude přehrávat a~cyklit jednotlivé animace v~závislosti na~větvení grafu a~podmínkách hran.
+
+Tato práce obsahuje pouze jednoduché animace postav, které~byly přeneseny ze~staré verze. Animace hráče navíc disponuje imersivním\footnote{Imersivita je označení pro~větší stupeň uživatelské odezvy nebo~pocit přítomností a~ponoření do~děje hráčem.} otáčením trupu a~animace nohou jsou přitahovány k~podlaze pomocí inverzní kinematické metody\footnote{Inverzní kinematická metoda umožňuje procedurální modifikaci skeleton animace. Obvykle se jedná o dopočítání pozice kloubů po cestě (např. loktu nebo kolena) pro určenou pozici "listů" (např. dlaně nebo chodidla)}.
+
+Tráva viditelná v~první a~druhé úrovní je animovaná pomocí offsetů vrcholů. V~reálném čase pod~hráčem se~generují částice s~barevným gradientem kódující offset v~prostoru. Takové~částice jsou viditelné pouze pro~speciální render target menší velikosti -- snímá~se pouze blízké okolí hráče. Materiál trávy následný render target interpretuje jako~texturu, kterou~interpoluje spolu s~texturou jednoduchého procedurálního shaderu větru dostupného v~enginu. Výsledkem je~výkonná procedurální animace reakce na~vítr a~chůzi hráče v~okolí objektu obsahující velké množství instancí resp.~vrcholů.
+
+\paragraph{Texturování} Za~účelem texturování nejdřív potřebujeme objektu určit jedinečnou UV~mapu, která~bude mapovat plošky 3D~modelu na normalizovaný prostor 2D~obrázku. Často tvůrci mají na~začátku problém pochopit, o~co~se~vlastně jedná a~jak~model rozložit. K~tomu může napomoci myšlenka s~rozlepováním resp.~slepováním hran papírové figurky. Celý koncept UV~mappingu je totožný se~zpětným procesem tvorby například papírové krychle, kde~rozbalenou krychli skládáme z~jednoho uceleného kousku materiálu.
+
+Když máme hotové mapování, můžeme volně přiřazovat textury, které~mohou určovat barvu vrcholů, modifikovat jejich normálový vektor, lesk, matnost, průhlednost a~případně další. Přibližně do~roku~2014, kdy~vznikl Substance Painter (program na~procedurální tvorbu materiálů a texturování) a~dnes i~jeho alternativy, jediný způsob texturování objektu bylo manuální kreslení navrch vytvořené mapy. Dnes existují uživatelsky příjemné programy, kde~stačí kreslit rovnou komplexní materiály na~povrch 3D~modelu a~aplikace sama obstará data všech textur.
+
+V~tomto projektu většina objektů používá pouze jednobarevné textury pro~vybarvení určitých skupin plošek. Přesto jsou často využívané normal mapy nebo~masky průhlednosti. Bohužel se~musely zahodit mapy pro~tesselaci\footnote{Teselace je technika podrozdělení a~modifikace plošek za~účelem zvětšení detalizace objektu.} povrchů používané v~staré verzi projektu, jelikož s~příchodem UE~5 tvůrci odebrali celou podporu tesselace kvůli technologii Nanite. 
+
+\paragraph{Exportování a Importování}
+Workflow nebo~pipeline exportu jsou standardizované v~profesionálních softwarech jako~3ds~Max. Blender má pouze základní možnosti exportu, které~je potřeba nejdřív přizpusobit specifickému hernímu enginu. Potřebné minimum je zajištění správné interpretace dopředního a~vrchního vektorů\footnote{Dopřední "forward" a~vrchní "up" vektory určují, jak~program interpretuje osy ve~3D prostoru. Ve~většině programů dopřední vektor odpovídá ose~Z a~vrchní ose~Y, ale~v~UE je~to obrácené.} celého modelu. Taky se~vyplatí:
+\begin{itemize}
+\item nastavit šablonu pro~všechny budoucí projekty, tak~aby~modelovací program a~herní editor sdíleli měřítko jednotek,
+\item vyzkoušet, jak~se~chová exportovaná hierarchie modelů v~jednom souboru,
+\item před exportem ověřit, že~všechny plošky modelu mají správně natočený normálový vektor (očekává~se směr mířící ven z~objektu).
+\end{itemize}
+
+Unreal Engine je standardem herního oboru a~proto verze~5 implementuje systém importovacích pipelines. Jedná~se o~mocný nástroj, který~citelně zrychluje a~sjednocuje postupy importování různých assetů nebo~dokonce stejných assetů podle specifických filtrů (adresář assetu, typ, obsah, podřetězce názvu atd.). Subjektivně největší výhodou je předání zodpovědnosti specifického importu pouze osobám v~týmu s~odpovídajícími znalostmi. V~praxi týmový senior založí pipelines pro~často využívané importy~tak, aby~odpovídaly vnitřním firemním politikám a~proto celý tým nemá žádné starosti při importu assetů.
+
+\paragraph{Optimalizace} I~když objekty jsou statické, stále vyžadují optimalizace. Takové lze najít i~v~tomto projektu:
+\begin{itemize}
+\item Instancování se~využívá k~tvorbě prostorů hustých na~specifické modely. V~UE se~jedná o~editovací prostředek sousedící vedle Landscape. Umožňuje pokročilé nastavení různých množin instancí a~jejich parametry náhodného umístění.
+\item Optimální topologie objektu pro~minimalizaci vrcholů potřebných k~vykreslování. Převážná většina modelů -- patří sem i~získané od~třetích stran -- mají mnou ručně přepracované topologie. Jedná~se nejen~o~jednoduchou redukci nepotřebných vrcholů, ale~taky použití létající neboli floating geometrie.
+\newpage
+Tato~metoda spočívá v~protínání plošek, místo skutečného propojení vrcholů někde uprostřed, jelikož takové propojení by~vyžadovalo podrozdělení plošek, což~by~vedlo ke~zbytečnému zvětšení počtu vrcholů (viz \Cref{fig:FloatingGeometry}). Taktéž objekty mají redukovanou k-DOP kolizní topologii, pro~urychlení výpočtů fyzických simulací.
+\item Modely náročné na~vykreslování nebo~použité v~instancování používají LOD~technologii (viz \Cref{fig:LodShowcase} na~další stránce). Nanite v~práci nebyl využit, jelikož~máme vypnutý deferred renderer (viz \Cref{sec:deferredRenderer}).
+\end{itemize}
+
+\begin{figure}
+\centering
+\includegraphics[width=1\linewidth]{img/FloatingGeometry.pdf}
+\caption{Floating geometrie využitá v~modelu okna. Vlevo je výsledný vzhled, uprostřed floating geometrie (48~vrcholů a~52~trojúhelníků) a~napravo běžná naivní topologie (64~vrcholů a~152~trojúhelníků).}
+\label{fig:FloatingGeometry}
 \end{figure}
 
 \begin{figure}
 \centering
-\tikzstyle{box}=[rectangle,draw,rounded corners=0.5ex,fill=green!10]
-\begin{tikzpicture}[thick,font=\sf\scriptsize]
-\node[box,rotate=45] (a) {A test.};
-\node[] (b) at (4,0) {Node with no border!};
-\node[circle,draw,dashed,fill=yellow!20, text width=6em, align=center] (c) at (0,4) {Ugly yellow node.\\Is this the Sun?};
-\node[box, right=1cm of c] (d) {Math: $X=\sqrt{\frac{y}{z}}$};
-\draw[->](a) to (b);
-\draw[->](a) to[bend left=30] node[midway,sloped,anchor=north] {flow flows} (c);
-\draw[->>>,dotted](b) to[bend right=30] (d);
-\draw[ultra thick](c) to (d);
-
-\end{tikzpicture}
-\caption{An example diagram typeset with TikZ. It is a good idea to write diagram captions in a way that guides the reader through the diagram. Explicitly name the object where the diagram viewing should ``start''. Preferably, briefly summarize the connection to the parts of the text and other diagrams or figures. (In this case, would the tenative yellow Sun be described closer in some section of the thesis? Or, would there be a figure to detail the dotted pattern of the line?)}
-\label{fig:schema}
+\includegraphics[width=1\linewidth]{img/LodShowcase.pdf}
+\caption{Ukázka LOD instancí kytky.}
+\label{fig:LodShowcase}
 \end{figure}
 
-\begin{algorithm}
-\begin{algorithmic}
-\Function{ExecuteWithHighProbability}{$A$}
-	\State $r \gets$ a random number between $0$ and $1$
-	\State $\varepsilon \gets 0.0000000000000000000000000000000000000042$
-	\If{$r\geq\varepsilon$}
-		\State execute $A$ \Comment{We discard the return value}
-	\Else
-		\State print: \texttt{Not today, sorry.}
-	\EndIf
-\EndFunction
-\end{algorithmic}
-\caption{Algorithm that executes an action with high probability. Do not care about formal semantics in the pseudocode --- semicolons, types, correct function call parameters and similar nonsense from `realistic' languages can be safely omitted. Instead make sure that the intuition behind (and perhaps some hints about its correctness or various corner cases) can be seen as easily as possible.}
-\label{alg:w}
-\end{algorithm}
+Optimalizace textur je zajištěná pouze hlídáním rozumných rozlišení. Jinak některé textury je určitě možné seskupit do~jedné a~výběr instance řídit pomocí UV~mapy, což~zrychlí přístup k~datům.
 
-\section{Extra typesetting hints}
+Jiná grafická optimalizace není řešená. Modely použité v~instancování občas mohou vyvolat snížení výkonu, což~by~bylo potřeba už~řešit nahrazením plnohodnotných modelů za~kolekce průhledných textur (billboard metoda popsaná v~další podsekci).
 
-Do not overuse text formatting for highlighting various important parts of your sentences. If an idea cannot be communicated without formatting, the sentence probably needs rewriting anyway. Imagine the thesis being read aloud as a podcast --- the storytellers are generally unable to speak in boldface font.
+\newpage
+\subsection{Dynamické a procedurální objekty}
+\paragraph{Sequencer} Běžná dynamická animace se~vytváří přímo v~editoru objektu Sequencer\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-sequencer-movie-tool-overview}. Taková animace dokáže modifikovat parametry objektů na~úrovni a~volat funkce v~určité okamžiky. Objekty mohou~být určené předem, nebo~Sequencer umí dynamicky vyhledat jejich reference před~spuštěním. Právě v~tomto prostředí se~tvoří cutscény nebo~cyklické animace objektů na~úrovni.
 
-Most importantly, do \underline{not} overuse bold text, which is designed to literally \textbf{shine from the page} to be the first thing that catches the eye of the reader. More precisely, use bold text only for `navigation' elements that need to be seen and located first, such as headings, list item leads, and figure numbers.
+\paragraph{Procedurální generování} V~předchozí verzi hry model trávy byl vytvořen pomocí billboard metody, kde~místo vykreslování 3D~geometrie vegetace se~vykresluje průnik ploch s~texturou vegetace a~průhledným pozadím. Tato~technika je~standardem ve~videohrách, přesto nestačila ke~splnění dizajnových účelů projektu. Buď~vegetace musela být řídká, nebo~vyžadovala nesmyslně mnoho hardwarových prostředků a~občas vzniklo i~drobné zmrazení aplikace.
 
-Use underline only in dire necessity, such as in the previous paragraph where it was inevitable to ensure that the reader remembers to never typeset boldface text manually again.
+Za~tímto účelem jsem implementoval nástroj pro~editor, který~je schopen na základě určitých parametrů vygenerovat náhodnou a~hustou trávu z~trojúhelníků. Uživatel může specifikovat oblast generování a~cílový Landscape objekt společně s~materiálem, na~kterém má~být tráva generována. K~tomu lze specifikovat hustotu, variabilitu velikostí, minimální a~maximální velikost. Generování se~skládá ze~tří kroků:
+\begin{itemize}
+\item Rozložíme oblast na mřížku definované hustoty.
+\item Z~každé buňky v~mřížce vyšleme kolizní paprsek směrem k~Landscape povrchu, čímž~získáme střed pro~budoucí stéblo.
+\item V~prostoru každé buňky náhodně umístíme dva vrcholy ve~výšce středu a~jeden uprostřed s~náhodnou výškou, čímž~získáme trojúhelník, kterému~říkáme stéblo. Z~pozic vrcholů stébla dopočítáme normálové vektory (potřebujeme ke~správnému stínování stébel ve~světě) a~UV~mapu (pokud chceme určit stéblu texturu, např.~gradientu s~přechodem od~tmavé do~světlé zelené).
+\end{itemize}
+Výsledný objekt má několikanásobně více geometrických dat než~billboard metoda, přesto~má skvělý výkon a~navíc vegetace působí mnohem hustěji, má kvalitnější vzhled a~lépe reaguje na~offset vrcholů v~shaderech (viz \Cref{fig:GrassShowcase} na~další stránce).
 
-Use \emph{emphasis} to highlight the first occurrences of important terms that the reader should notice. The feeling the emphasis produces is, roughly, ``Oh my --- what a nicely slanted word! Surely I expect it be important for the rest of the thesis!''
+Trik~je v~přenesení velké texturové zátěže s~převýpočty průhledností na~vykreslování jednotné a~jednoduché 3D~geometrie. K~tomu generativní přístup umožňuje kvalitnější pokrytí ploch, jako~například v~tomto projektu, kde~tráva se~generuje pouze v~oblastech určité velikosti a~jestli jsou pokryté určitým materiálem, tedy~tráva se~negeneruje na~cestičkách a~mezi povolenou a~zakázanou plochou je pozvolný přechod ve~velikosti jednotlivých stébel. Takový přístup byl inspirován hrou Ghosts~of~Tsushima od~studia Sucker~Punch~Productions, kde~autoři si~vytvořili podobný proprietární nástroj, jelikož~chtěli dosáhnout husté kinematické a~stylistické vegetace na~konzolích.
 
-Finally, never draw a vertical line, not even in a table or around figures, ever. Vertical lines outside of the figures are ugly.
+\begin{figure}
+\centering
+\includegraphics[width=1\linewidth]{img/GrassShowcase.pdf}
+\caption{Ukázka procedurální~(vlevo) a~billboard~(vpravo) metody pro~vykreslování vegetace. Procedurální metoda má přibližně 6-krát menší render time a~paměťové požadavky.}
+\label{fig:GrassShowcase}
+\end{figure}
+
+\subsection{Osvětlení}
+Téměř každý objekt osvětlení sdílí podobné parametry, které~mohou definovat~to, jak~světlo vypadá nebo~ovlivňuje prostředí. Vedle běžných dizajnových parametrů nechybí ani~široká škála technických triků a~úskalí.
+
+\paragraph{Forward shading} Jelikož celá hra je v~režimu forward shading (viz \Cref{sec:forwardRenderer}), některé technologie jsou značně omezené nebo~nefungují. Například není podporován Rect Light (světelný zdroj ve tvaru obdelníku), který~ale~můžeme napodobit~tak, že~Point Light (světelný zdroj ve tvaru kruhu) zdroji přiřadíme IES~texturu, která~nám specifikuje způsob šíření světla neboli~tvar světla v~herním světě. Stejně~tak lze~vytvořit vlastní Light Function, což~je~materiál definující, co~a~jak světelný zdroj vyzařuje. Navíc je potřeba pamatovat na~technická omezení enginu pro~forward shadingu, jako~nejvýše tři~zdroje světla na~jeden objekt a~nedostatek SSAO nebo~SSR (viz \Cref{sec:screenspace}). S~čímž~stále si~můžeme poradit. Pokud~je potřeba víc zdrojů světel ve~scéně, můžeme specifikovat tři~různé kanály pro~objekt a~zdroje zvlášť.
+\newpage
+Jestli~nutně potřebujeme ambientní okluzi můžeme použít Lightmass Volume\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/cpu-lightmass-global-illumination-in-unreal-engine} pro~jeho simulaci a~stejně tak~můžeme použít Planar~Reflections\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/planar-reflections-in-unreal-engine} pro simulaci odrazů.
+
+\paragraph{Základy osvětlení} Kromě bodových světel na~úrovní téměř vždy chceme přidat globální osvětlení, které~sestává z~Directional~Light a~Sky~Light.
+
+Directional zdroj funguje jako~jeden velký nekonečně vzdálený zdroj pro~celou scénu, který~napodobuje funkci slunce a~slouží primárně k~vykreslování stínů. Zdroj typu Sky~Light také~může ovlivňovat stíny, ale~primárně zobrazuje Skybox texturu a~modifikuje ambient složku celého osvětlení.
+
+Navíc pokud chceme zobrazit venkovní prostory, je dobré použít nějakou formu mlhy, jako~je Ambient~Fog. Mlha přidá pocit velkého a~neomezeného prostoru i~když ve~skutečnosti je malý a~uzavřený. Navíc mlha výborně skryje a~tedy~umožní horší detailizaci objektů v~dálce, čímž~efektivně zkrátíme dobu vykreslování snímku.
+
+Nakonec se~lze odchýlit k~použití mnoha různých Volume objektů, které~z~důvodů rozsahu práce nebudou podrobně probrány. Pomocí těchto prostorů lze~specifikovat oblastí s~určitými parametry, které~budou napovídat enginu potřebné optimalizace, nebo~zapínat výkonnostně náročné vykreslovací technologie. Pro~představu Lightmass~Importance~Volume\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/lightmass-basics-in-unreal-engine} specifikuje oblast, kde~je potřeba propočítat větší počet odrazů paprsků světla při ``zapekání" statických stínů\footnote{Zapekání světla neboli~light map baking je proces náročného předpočítání osvětlení a stínů tvořených statickými objekty na~statickém povrchu do~formátu textury.}.
+
+\subsection{Post-Processing}
+Post-processing jsou funkce, které~pracují s~již vyrenderovaným snímkem před~jeho zobrazením. Tímto způsobem lze např.~napadobit rozmazání/rozostření (depth-of-field), mlhu nebo~efekty popsané níže. Post-Processing lze~definovat přímo v~kameře nebo~v~již zmíněných Volume objektech. Každá~definice je de-facto materíál (v~kontextu~UE), který~lze vrstvit mezi sebou. PP~vyžaduje hlubší grafické znalosti, aby~bylo možné vytvořit něco užitečnějšího než~barevnou korekci. Zároveň kvůli tématice práce pouze nastíním, jak~jsem naimplementoval PP~materiály (viz~\Cref{fig:PPShowcase} na~další stránce), které~mají gamedizajnový důvod, ale~se~nestihli použít.
+
+\begin{figure}
+\centering
+\includegraphics[width=1\linewidth]{img/PPShowcase.pdf}
+\caption{Ukázka post-process materiálů ve~hře. Efekt deště jsem nedokázal rozumně zachytit, aby~byl vidět na~statickém obrázku.}
+\label{fig:PPShowcase}
+\end{figure}
+
+\begin{enumerate}
+\item Plovoucí obrazovka - UV~prostor obrazu se~lehce zakřiví pomocí animované šumové textury.
+\item Bezpečnostní kamera - obraz rozložíme na~trochu sesunuté proužky dle~rozlišení výstupu a~zároveň tyto~proužky střídavě obarvíme. Nakonec proužky animujeme posunem nahoru nebo~dolu.
+\item Slepota - výstupní obraz nahradíme vlastním, ve~kterém zobrazujeme pouze ohraničení objektů s~efektem emise. Ohraničení lze dosáhnout různými způsoby a~v~tomto projektu je~implementováno pomocí drobného posunu hloubkové textury ve~všech směrech. Mezi posuny se~provede rozdíl s~originální hloubkou a~sloučením rozdílů získáme obrysy objektů.
+\item Pixelizace - obraz rozložíme na~potřebnou mřížku dle~rozlišení a~modifikujeme UV~prostor výstupního obrazu.
+\item Námraza - obraz interpolujeme s~animavanou texturou. Nejlépe použít nějaký gradient uprostřed jako~masku průhlednosti, aby~hráč měl čistší vidění.
+\item Tužka a~papír - výstupní obraz nahradíme texturou ambient occlusion.
+\item Tavení pixelů - vytvoříme netriviální vertikální gradient s~více přechody. Výsledek poškodíme zaokrouhlováním a~násobením dat, zpixelizujeme vzorkováním na~mřížku a~výsledek použijeme k~modifikaci UV~prostoru výstupního obrazu a~barevné korekci.
+\item Déšť - obraz rozložíme na~jemnou mřížku a~v~blocích vygenerujeme různé kapky pomocí složení dvou turbulencí, každá~z~nich bude mít animovanou lehce odlišnou rychlost posunu, aby~kapky nebyly stále stejné. Paralelně k~tomu znovu rozložíme obraz, ale~teď na~hrubou mřížku, kde~animujeme svislé pády bloků s~gradientním ocasem. Oba~výstupy složíme~tak, že~hrubá mřížka představuje animovanou masku průhlednosti, která~nám bude v~různý okamžik otevírat pouze některé kapky. Nakonec přidáme trochu distortion a~výsledek použijeme jako modifikátor UV~výstupního obrazu.
+\end{enumerate}
+
+\subsection{Materiály a shadery}
+Materiál v~UE je high-level programovátelný objekt popisující vizuální reprezentaci povrchu objektu. Materiál se~programuje pomocí odpovídajících Blueprintů, které~engine převede nejdřív do~HLSL a~potom kompiluje jako~fragment/pixel a~vertex shader.
+
+Přestože materiály jsou omezené shadery, stále lze pomocí nich definovat mnoho různých a~komplexních grafických funkcí. Základem jsou jednoduché barevné výstupy s~triviálními parametry lesku, matnosti a~emise. Může záležet na druhu objektu, pro~který~materiály tvoříme, tedy~potřebujeme správně nastavit i~druh materiálu, čímž~následně dostaneme další, předtím uzavřené, výstupy a~vstupy. Například za~účelem optimalizace můžeme přepnout materiál ze~základního režimu osvětlení neboli~Default~Lit do~neosvětleného režimu Unlit, čímž~budeme moci definovat barvu objektu pouze emisní složkou, ale~zmenšíme vykreslovací čas potřebný pro~materiál.
+
+V~UE materiály resp.~shadery mají mnoho globálních(uniform) proměnných, z~kterých můžeme získat cenné údaje o~enginu, scéně, vykreslovaném objektu, render buffrech atd. Dokonce můžeme definovat vlastní globální nebo~lokální parametry a~měnit jejich hodnoty v~logice světa. Použití takových proměnných lze často vidět v~již~zmíněných post-procesech, které~přebírají a~modifikují hodnoty výstupního zobrazení nebo~jsou animované pomocí sinusové funkce s~globálním parametrem herního času jako~vstup.
+
+Stojí~za~to zmínit, že~některé materiály se~hodí pouze na~určitý druh objektů podle velikosti a~umístění ve~světě. Jedním z~příkladů v~této hře je materiál skla. Původně navržený shader, který~simuluje zalamování a~vnitřní objem, skvěle funguje na~drobných objektech jako lahve nebo~skleněné střepy. Při~použití na~velkých skleněných plochách jako~jsou~okna, takové simulace vytváří nežádané artefakty. Pro takové situace byl přidán duplicitní shader skla, který~primárně vykresluje poloprůhlednou barvu na~povrchu objektu.
+
+\paragraph{Funkce} V~materiálech se~lze zbavit duplicitního kódu, čímž~se~zároveň zrychlí kompilace a~běh shader variací. Implementoval~jsem funkce:
+\begin{itemize}
+\item Škálování vstupní hodnoty podle vzdálenosti objektu od~kamery.
+\item Uniformní škálování a~tiling textury nezávislé na~velikosti objektu.
+\item Získání obrysů objektů v~podobě masky.
+\item Rotace objektu ve~směru kamery.
+\end{itemize}
+
+\subsection{Uživatelské rozhraní}
+Uživatelské rozhraní neboli UI je sada 2D~prvků vykreslených na~vyrenderováný obraz 3D~scény. Běžně se~jedná o~menu, titulky nebo~popisky ovládání. Před~Unreal~Engine~5 téměř každé~UI byl rastrový obrázek a~v~minulosti to~ani~nebyl problém. Stačilo vytvořit mip-mapy pro~menší množinu nejrozšířenějších rozlišení (HD, WSXGA a~Full~HD) a~k~tomu škálovat mip~texturu menšího rozlišení na~potřebný lehce větší výstup. Předtím hry nevypadaly zaostřeně takže nemuselo ani~UI a~dokonce to~rozostření rastrového obrazu nebylo tak~viditelné na~displejích menší velikosti v~té~době. Dnes rastrové~UI vytváří příliš komplikací při~tvorbě a~vykreslování. Je potřeba mnoho mip-map ve~velkých rozlišeních pro~ostrý obraz na~každém displeji, které~vyžadují velké množství paměti a~hlavně velkou propustnost při~čtení dat, což~se~nejvíc projevuje u~rastrových animací.
+
+Jelikož původní projekt vznikal ve~čtvrté verzi enginu, ale~v~době již~velkých rozlišení, nebylo realistické pro~dva vývojáře vypracovat přijatelné rastrové~UI. Proto jsem tehdy a~teď vytvořil všechny prvky pomocí černobílých poloprůhledných vektorových čtverců s~transformacemi. Rastrové textury se~používají pouze v~podobě masek nebo gradientů, při~použití~kterých nejsou zřejmé škalovací artefakty.
+
+Všechny kořenové UI~prvky (overlay, kontejner questů, kontejner nápověd ovládání, menu~atd.) spravuje mnou implementována třída Widget~Manager. Tato~třída slouží nejen jako~high-level~API pro~všechny kořenové prvky resp.~kontejnery, ale~primárně přehledně udržuje reference na~takové prvky. Bez~manuálního udržování reference, po~instancování libovolného UI~prvku ho~již~nelze získat a~tedy nemůžeme prvek ani~odstranit z~obrazovky.
+
+Každý prvek se~instancuje na~začátku a~udržuje~se v~paměti po~celou dobu. Důvodem stálého udržování prvků v~paměti je jejich naplňování daty, které~občas může trvat déle a~tak při~dynamickém instancování vyvolávat zaseknutí aplikace.
+
+\paragraph{Texty a překlady} V~enginu je více druhů řetězců:
+\begin{itemize}
+\item FString - běžný řetězec pro~reprezentaci UTF-16 se~stejnou množinou funkcí jako~u~std::string. Je optimalizovaný pro~konkatenace.
+\item FName - pouhý ukazatel na~tabulku triviálních unikátních bajtových řetězců. Používá~se pro~pojmenování konstant v~kódu nebo~tagování objektů a~je~to doporučený textový formát pro~přenos přes internet.
+\item FText - komplexní řetězec schopný překládat obsah podle tabulky nebo~formátovat čísla podle pravidel jazyka.
+\end{itemize}
+Engine při~instancování určitého FText nebo~FString se~snaží najít již~existující instanci v~paměti, čímž~se~výrazně redukuje duplicita dat zejména v~blueprintech.
+
+Při~tvorbě projektu jsem~si~dal záležet, aby~veškerý text viditelný hráčem byl překladatelný. Zároveň jsem dbal na~zachování unikátností řetězců, aby~se~v~tabulce překladů nevyskytovaly duplicitní záznamy. Engine pochopitelně takové záznamy nemůže eliminovat sám a~ani to~nechceme, protože~každá stejná slova v~jednom jazyce, mohou~být již různá v~jiném jazyce v~závisloti na~gramatice a~kontextu.
+
+\paragraph{Načítací obrazovka} Načítací obrazovka je povinná z~důvodů licenčních podmínek některých knihoven a~programů. Zejména Unreal~Engine a~FMOD vyžadují, aby~produkt obsahoval načítací obrazovku s~logem jejich softwaru. Tato~zdánlivě triviální problematika ve~skutečnosti zahrnuje netriviální množství časové investice a~rozboru startovací sekvence enginu, což~vyúsťuje v~nekompetentní řešení začínajících i~pokročilých vývojářů. Přesně se~jedná~o:
+\begin{itemize}
+\item úplné vynechání celé funkcionality a~tedy porušování licenčních podmínek, 
+\item nebo~simulaci načítaní~tak, že~po již plném načtení enginu se~otevře speciální scéna obsahující pouze UI s~animaci načítání s~předem definovanou délkou zobrazování.
+\end{itemize}
+Ve~své práci pro~mě bylo zásadní vytvářet věci technicky správně a~tedy vyhýbat~se programátorským workaroundům nebo~technickému ``lhaní'' hráči. Proto~jsem~si~dal záležet i~na~správném provedení načítací obrazovky.
+
+Postup tvorby načítací obrazovky vývojáři enginu nedokumentují a~běžně dostupné návody třetích stran jsou již zmíněné nekvalitní simulace. Dokázal jsem najít pár funkčních ukázek u~kolegů z~Číny\Cite{chinaLoadingScreen} a~Japonska\Cite{japanLoadingScreen}, které~mi~umožnily se~zorientovat v~základech a~následně provést reverse engineering celé problematiky. K~mému překvapení jedná~se o~důkladně propracovaný systém, který~je podrobně přizpůsoben specifikům různých platforem.
+
+Engine při~načítaní nepodporuje UI vytvořený v~blueprintech, jelikož blueprinty jsou assety s~hlubokou reflexí, kterou~engine teprve~načítá (po~načtení již~lze zobrazit blueprint načítací obrazovky mezi úrovněmi). Proto~jsem~musel vytvořit navíc UI~v~nízkoúrovňovém Slate.
+
+\section{Audio}
+\label{sec:audio}
+V~tomto projektu jsem~se~zaměřil primárně na~zprovoznění všech technologií potřebných k~dokončení uceleného produktu a~proto~je ve~hře značný nedostatek audia. Přesto je připravené široké technické zázemí, které~obsahuje drobné ukázky:
+\begin{itemize}
+\item nastavení a~ukládání hlasitostí různých kategorií audia,
+\item prostorové přehrávání,
+\item dynamický hudební doprovod
+\item a~možnost dabování dialogů spolu s~hotovým procesem generování hlasů.
+\end{itemize}
+
+\newpage
+Optimalizace audia nepatřila mezi cíle této práce, avšak~základní systematická pravidla byla určena.
+\begin{itemize}
+\item Použít streaming a~kompresi dat kdekoliv to~bude možné,
+\item hudební doprovod je~ve~formátu~MP3,
+\item hlasy a~jiné zvuky jsou~ve~formátu~WAV.
+\end{itemize}
+V~budoucnu by~také pomohlo zabalit všechny hlasy a~jiné audio do~samostatných datových balíčků neboli~chunků. Aktuálně všechny herní assety jsou automaticky zabalené do~pár ucelených balíčků, což~sice může vyvolat drobné zpomalení načtení assetů, ale~stále zásadně ovlivnit audio zážitek. Tomu~tak~je, protože uši jsou mnohem ``časově citlivější" než~oči. Zatímco pro~vnímání plynulosti obrazu často stačí vyšší desítky snímků za~sekundu\Cite{videoSampling}, pro~zachycení všech slyšitelných zvukových frekvencí je potřeba nad~40~tisíc vzorků za~sekundu\Cite{audioSampling}. Navíc i~drobné záseky nebo~vypadnutí několika vzorků jsou snadno slyšet.
+
+\subsection{Dynamický hudební doprovod}
+Když~mluvíme o~dynamickém doprovodu ve~hrách, často myslíme právě~dynamické přepínání částí skladby v~závislosti na~proměnných světa. Pří~vývoji jsem se~uchýlil k~použití zvukového enginu~FMOD (viz~\Cref{prg:fmod}) a~hudbu jsem skládal sám bez~použití samplů, tedy~pomocí~VST (Virtual~Studio~Technology) hudebních nástrojů. Častí hotových kompozic za~účelem dynamiky by~měly~být nerušivě zacyklené, na~což~jsem kladl největší důraz. Bohužel kvůli~omezenému času jsem~nemohl věnovat dostatečnou pozornost rozmanitosti a~komplexitě hudebních kompozic. Prototypy dynamického doprovodu lze již~zaslechnout v~průběhu třetí úrovně, tedy postupné vrstvení zvukových stop při~propojování kabelů a~adaptivní hudební progrese napříč částmi bludiště.
+
+\subsection{Dabing dialogů}
+Jelikož hra by~měla poskytnout prostor pro~AI generovaný obsah, dialogy jsou již~nadabované pomocí~AI. Původně jsem začínal s~Python knihovnou Coque~TTS\footnote{https://github.com/coqui-ai/TTS}, ale~dosáhnout v~ní aspoň dobrých výsledků bylo náročné. Proto~jsem~přešel na~knihovnu a~model Zonos\footnote{https://github.com/Zyphra/Zonos}, který~již v~základu poskytuje vynikající výsledky a~navíc má~prostředky pro~udržování kontextu nebo~parametry zabarvení hlasu.
+
+V~modulu VoiceGenerator v~repozitáři hry je~k~dispozici skript pro~jednoduchou instalaci prostředí. Z~časových důvodů jsem~nestihl vytvořit skript, který~by jednoduše generoval množiny resp.~sekvence dialogů přímo z~jednoho textového souboru. Aktuálně je~potřeba ručně generovat každou větu jednotlivě přes~webové rozhraní, které~je~součástí knihovny, ale~naprogramovat klienta, který~bude pro~každou textovou linku volat stejné generující~API a~ukládat výsledky, by~nemělo~být složité.
+
+Ukázkové dialogy lze již~zaslechnout v~průběhu třetí úrovně. Původně jsem~taky~plánoval vytvořit robotický hlas ve~třetí úrovni pomocí modifikace základního hlasu v~novém pro~UE5 zvukovém systému MetaSound. Ten~dokáže komplexně modifikovat zvukový signál za~běhu, ale~na~začlenění takové technologie do~hry nezbýval čas. 
+
+\newpage
+\section{Co se~nestihlo nebo~změnilo}
+Přestože do~práce jsem~vložil mnoho času a~úsilí, nepodařilo se~mi splnit všechny mnou stanovené cíle. Místo herního dema práce představuje spíš demo technické, neboli~jsem~úspěšně vytvořil technické zázemí, ale~nestihl naplnít hru obsahem. Třetí úroveň nějakým obsahem disponuje a~dohromady lze tuto úroveň považovat za~hru. Jinak~všechny úrovně resp.~celá hra trpí nedostatkem nebo~neobsahuje vůbec:
+\begin{itemize}
+\item grafické prvky jako~animace postav, efekty, 3D modely,
+\item zvukové prvky jako~hudební doprovod, zvuky~interakce se~světem a~UI,
+\item příběhové dialogy, cutscény a~dokončený level design,
+\item balancování herních mechanik a~doladění ovládání.
+\end{itemize}
+Nepodařilo~se~mi vytvořit poslední pátou úroveň z~časových důvodů. Zároveň jsem~se~rozhodl změnit žánr této úrovně z~first-person shooter na~top-down shooter. Důvodem změny posloužila analýza náročnosti tvorby obsahu pro~takový žánr. Přestože~first-person shooter se~může zdát jako~jednoduchý koncept, ve~skutečnosti pro~hezký herní zážitek je~potřeba vložit mnoho úsilí a~času. Pro~tento~žánr je~nutné pečlivě odladit všechny prvky hry a~hlavně animace, které~jsou má slabá stránka. Na~druhou stranu top-down shooter neklade tak~vysoké nároky a~dokonce umožňuje skrytí od~hráče nedostačující animace.
+\subsection{Obsah mimo hru}
+Projekt není~tvořen pouze technickým demo hry, ale~také zahrnuje nasazení a~údržbu sítě s~veřejnou ip~adresou, webového a~Git\footnote{https://git-scm.com/} serveru. Postupy nasazení a~údržby vzhledem k~zaměření práce nejsou zveřejněny. Zvolil jsem údržbu vlastní sítě a~zařízení převážně z~finančních důvodů. Vlastní Git server je zapotřebí z~důvodu nadstandardní velikosti repozitáře, kterou~veřejné platformy jako~GitHub\footnote{https://github.com/} a~Gitlab\footnote{https://about.gitlab.com/} již~zpoplatňují. Webový server slouží jako~rozhraní pro~poskytování assetů hráči v~podobě běžné indexovací složky se~soubory, kterou~poskytujé základní implementace serveru Nginx\footnote{https://nginx.org/}.

intro.tex

@@ -1,19 +1,18 @@
 \chapwithtoc{Úvod}
 
-Běžně příběhové hry jsou navrhnuté předem a~zůstávají neměnné. Existují ale~i~výjimky, například hry žánru rogue-like, kde~ale~stále generování obsahu je~založeno na~použití speciálně vytvořeného a~odladěného algoritmu. Tento algoritmus různé složitosti stále používá pouze prostředky předem navržené a~odladěné vývojáři. To~vše má podstatný důvod, jelikož vývojáři mají za~úkol vytvořit tzv.~dobrý herní zážitek a~zaručit, že~hra bude umělecky správně interpretovaná hráčem. Bohužel, nezávísle na~kvalitě výsledné hry -- počet opakovaného zahrání hry v~nejlepším případě klesá nebo~v~tom horším je~pouze jeden.
+Běžně příběhové hry jsou navrhnuté předem a~zůstávají neměnné. Existují ale~i~výjimky, například hry žánru rogue-like, kde~je generování obsahu stále založeno na~použití speciálně vytvořeného a~odladěného algoritmu. Tento algoritmus různé složitosti stále používá pouze prostředky předem navržené a~odladěné vývojáři. To~vše má podstatný důvod, jelikož vývojáři mají za~úkol vytvořit tzv.~dobrý herní zážitek a~zaručit, že~hra bude umělecky správně interpretovaná hráčem. Bohužel, nezávisle na~kvalitě výsledné hry -- počet opakovaného zahrání hry v~nejlepším případě klesá nebo~v~tom horším je~pouze jeden.
 
-Celý problém v~branži příběhových her je~řešen tzv.~mody neboli modifikacemi hry a~to~různých druhů, jako například grafické, kódové a~další. Samotní vývojáři poskytují potřebné prostředky pro~podporu nebo~tvorbu modů. Dokonce i~technicky zdatní hráči dokážou oblíbené hry úpravit, aby~ony jakousi podporu měly. V~každém případě modifikace značně zvětšují počet přehrání her, kde~klasickým příkladem je~hra The Elder Scrolls: Skyrim od~studia Bethesda.
+Celý problém v~branži příběhových her je~řešen tzv.~mody neboli modifikacemi hry a~to~různých druhů, jako například grafické, kódové a~další. Samotní vývojáři poskytují potřebné prostředky pro~podporu nebo~tvorbu modů. Dokonce i~technicky zdatní hráči dokážou oblíbené hry úpravit, aby~ony jakousi podporu měly. V~každém případě modifikace značně zvětšují počet znovuzahrání hry, kde~klasickým příkladem je~hra The Elder Scrolls: Skyrim od~studia Bethesda.
 
-Přestože celé řešení zdánlivě funguje, spoléhá~se na~ochotu samotných hráčů módy vytvářet. Jestliže hra nebude mít dostatek hráčů, potom~taktéž nebude mít dostatek nového fanouškovského obsahu a~výsledně počet přehrání neroste. Nedavným příkladem je~hra Starfield od~již zmíněného studia Bethesda. Navíc k~mnoha technickým omezením samotných módů, musí~mít hráči nejen ochotu, ale~i~být technicky a~umělecky zdatní, aby~něco vytvořili. Minimálně musí vynaložit úsilí k~manuálnímu vyhledání, stažení a~instalaci modů.
+Přestože celé řešení zdánlivě funguje, spoléhá~se na~ochotu samotných hráčů mody vytvářet. Jestliže hra nebude mít dostatek hráčů, potom~taktéž nebude mít dostatek nového fanouškovského obsahu a~výsledně počet znovuzahrání neroste. Nedavným příkladem je~hra Starfield od~již zmíněného studia Bethesda. Navíc k~mnoha technickým omezením samotných modů, musí~mít hráči nejen ochotu, ale~i~být technicky a~umělecky zdatní, aby~něco vytvořili. Minimálně musí vynaložit úsilí k~manuálnímu vyhledání, stažení a~instalaci modů.
 
-Tato práce se~zaměřuje na~tvorbu hry a~návrh systému který~umožní výše popsaný lidský faktor a~nedostatky eliminovat. Přináší tak příběh rozdělený na~pět žánrově odlišných úrovní a~zavádí high-level API pro~Unreal~Engine na~stahování a~načítání obsahu do~hry přímo za~běhu. Specifický příběh snižuje ludonarativní disonanci\footnote{Souvislost resp.~logické propojení herního světa, příběhu a~gameplaye.} při vzníku nového obsahu ve~hře a~přítomnost více žánrů umožňuje otestovat, jestli toto řešení v~každém z~nich dostatečně funguje. Zároveň tato práce přenechává samotné generování obsahu pomoci AI modelů a~testování výsledků až~jako další rozšíření. Čili primárně se~zaměřuje na~kostru samotné hry, aby~spotom byl prostor, kam nový obsah začlenit.
+Tato práce se~zaměřuje na~tvorbu hry a~návrh systému, který~umožní výše popsaný lidský faktor a~nedostatky eliminovat. Přináší tak příběh rozdělený na~pět žánrově odlišných úrovní a~zavádí high-level API pro~Unreal~Engine na~stahování a~načítání obsahu do~hry přímo za~běhu. Specifický příběh snižuje ludonarativní disonanci\footnote{Souvislost resp.~logické propojení herního světa, příběhu a~gameplaye.} při vzniku nového obsahu ve~hře a~přítomnost více žánrů umožňuje otestovat, jestli toto řešení v~každém z~nich dostatečně funguje. Zároveň tato práce přenechává samotné generování obsahu pomocí AI modelů a~testování výsledků až~jako další rozšíření. Čili primárně se~zaměřuje na~kostru samotné hry, aby~potom byl prostor, kam nový obsah začlenit.
 
 \pagebreak
-Hlavními tématy, na~které se~práce zaměřuje, jsou:
+Hlavní témata na~které se~práce zaměřuje:
 \begin{itemize}
-\item Práce s~Unreal~Engine, jeho reálná omezení, obcházení/vyrovnání se~s~těmito omezení a~tipy.
-\item Postupy tvorby různých druhů grafiky pro~3D hry zejména v~UE.
-\item Postupy tvorby zvuků a~hudby pro~hry.
-\item Ukázkové příklady tvorby herních systémů a~mechanik pro~Unreal~Engine.
-\item Tvorba generativního obsahu a~jeho načítaní na~Unreal Engine.
+\item Ukázkové příklady tvorby herních systémů a~mechanik pro~Unreal~Engine (\cref{sec:systemsAndMechanics}).
+\item Návrh tvorby generativního obsahu a~jeho načítaní v~Unreal Engine (\cref{sec:contentGenerationAndIntegration}).
+\item Postupy tvorby různé grafiky v~UE (\cref{sec:graphics}).
+\item Postupy tvorby zvuků a~hudby pro~hry (\cref{sec:audio}).
 \end{itemize}

refs.bib

@@ -36,62 +36,50 @@
   note         = {[cit. 2025-04-01]. Dostupné z: \url{https://alfredbaudisch.com/blog/gamedev/godot-engine/godots-3d-confusing-workflow-inconsistencies-conflicting-behaviours-and-annoyances/}}
 }
 
-
-@book{knuth1979tex,
-  title={TEX and METAFONT: New directions in typesetting},
-  author={Knuth, Donald Ervin},
-  year={1979},
-  publisher={American Mathematical Society}
+@article{gptPaper,
+  author = {Radford, Alec and Wu, Jeffrey and Child, Rewon and Luan, David and Amodei, Dario and Sutskever, Ilya},
+  biburl = {https://www.bibsonomy.org/bibtex/233e4b003b64b1060334660fbf6db1f3f/albinzehe},
+  interhash = {b926ece39c03cdf5499f6540cf63babd},
+  intrahash = {33e4b003b64b1060334660fbf6db1f3f},
+  journal = {OpenAI},
+  keywords = {gpt gpt2 languagemodelling transferlearning transformer},
+  note = {[cit. 2025-07-01]. Dostupné z: \url{https://cdn.openai.com/better-language-models/language_models_are_unsupervised_multitask_learners.pdf}},
+  timestamp = {2024-11-15T12:44:17.000+0100},
+  title = {Language Models are Unsupervised Multitask Learners},
+  year = 2019
 }
 
-@book{lamport1994latex,
-  title={LATEX: a document preparation system: user's guide and reference manual},
-  author={Lamport, Leslie},
-  year={1994},
-  publisher={Addison-Wesley}
+@misc{fabRealityCheck,
+  title        = {FAB - Review (Disaster for Customers and Sellers)},
+  author       = {Unreal Engine Forums},
+  year         = 2024,
+  note         = {[cit. 2025-07-01]. Dostupné z: \url{https://forums.unrealengine.com/t/fab-review-disaster-for-customers-and-sellers/2092291}}
 }
 
-@book{glasman2010science,
-  title={Science research writing for non-native speakers of English},
-  author={Glasman-Deal, Hilary},
-  year={2010},
-  publisher={World Scientific}
+@misc{chinaLoadingScreen,
+  title        = {PreLoadScreen and LoadingScreen in Unreal Engine 4 (Translated)},
+  author       = {AGuner58 (Translated)},
+  year         = 2023,
+  note         = {[cit. 2025-07-01]. Dostupné z: \url{https://zhuanlan.zhihu.com/p/608502007}}
 }
 
-@book{sparling1989english,
-  title={English or Czenglish? Jak se vyhnout čechismům v angličtině},
-  author={Sparling, Don},
-  year={1989},
-  publisher={Státní pedagogické nakladatelství}
+@misc{japanLoadingScreen,
+  title        = {[UE4] Display an image immediately after launching the app using EarlyStartupScreen (Translated)},
+  author       = {Ogura (Translated)},
+  year         = 2021,
+  note         = {[cit. 2025-07-01]. Dostupné z: \url{https://historia.co.jp/archives/19862/}}
 }
 
-@book{tufte1990envisioning,
-  title={Envisioning information},
-  author={Tufte, Edward R and Goeler, Nora Hillman and Benson, Richard},
-  year={1990},
-  publisher={Graphics press Cheshire, CT}
+@misc{videoSampling,
+  title        = {How to Use Frame Rates in Your Videos},
+  author       = {Daniela Bowker},
+  year         = 2024,
+  note         = {[cit. 2025-07-01]. Dostupné z: \url{https://artlist.io/blog/how-to-use-frame-rates/}}
 }
 
-@book{tufte1983visual,
-  title={Visual display of quantitative information},
-  author={Tufte, Edward R},
-  year={1983},
-  publisher={Graphics press Cheshire, CT}
-}
-
-@book{wilke2019fundamentals,
-  title={Fundamentals of Data Visualization},
-  author={Wilke, Claus O},
-  year={2019},
-  publisher={O'Reilly Media, Inc.},
-  url={https://clauswilke.com/dataviz/},
-  isbn={9781492031086}
-}
-
-@techreport{tantau2015tikz,
-  title={The TikZ and PGF Packages (Manual for version 3.1.8b)},
-  author={Tantau, Till},
-  year={2020},
-  institution={Institut f{\"u}r Theoretische Informatik Universit{\"a}t zu L{\"u}beck},
-  url={http://mirrors.ctan.org/graphics/pgf/base/doc/pgfmanual.pdf}
+@misc{audioSampling,
+  title        = {Digital audio basics: audio sample rate and bit depth},
+  author       = {Ian Stewart},
+  year         = 2024,
+  note         = {[cit. 2025-07-01]. Dostupné z: \url{https://www.izotope.com/en/learn/digital-audio-basics-sample-rate-and-bit-depth}}
 }

thesis.tex

@@ -132,6 +132,7 @@
 \include{ch3}
 \include{conclusion}
 \include{bibliography}
+\listoffigures
 
 \appendix
 \include{howto}

thesis.xmpdata

@@ -1,7 +1,7 @@
 % Metadata to be stored in PDF, see documentation of the pdfx package for more details.
 
 \Author{Oleg Petruny}
-\Title{Multi-genre game with support for loading new content in real-time}
-\Keywords{Computer game\sep Unreal Engine\sep dynamic content loading\sep 3D graphics}
+\Title{Vícežánrová příběhová počítačová hra s podporou načítání nového obsahu za běhu}
+\Keywords{Počítačová hra\sep Unreal Engine\sep dynamické načítání obsahu\sep 3D grafika}
 \Subject{Abstract of thesis}
 \Publisher{Charles University}