review of half ch2

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}
@@ -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 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.
@@ -101,7 +102,7 @@ Největší nevýhodou je~překvapivě nepřehlednost kódu, která~nejčastěji
 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áž).
 
@@ -148,21 +149,21 @@ Z~rendererů lze~vybrat mezi~Forward a~Deferred rendererem. Jsou~to~systémy, kt
 
 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.
 
 \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 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. V~Slate prostředí se~programuje nízkoúrovňové tedy je stejné jako programování okenní windows aplikace 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í.
+\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.
 
@@ -183,36 +184,40 @@ Hlavní problém s~hudbou je~synchronizace linek. Hudba je~dost náchylná na~ja
 \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.
 
@@ -225,11 +230,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,19 +1,32 @@
 \chapter{Vývoj hry}
 \label{chap:main}
 
-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~odstráně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ý PhysX\footnote{PhysX je open-source fyzický engine s hardwarovou akcelerací pro grafiky s CUDA architekturou (GPU společnosti NVIDIA).} rozhraní, 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).
+\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.
+
+\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).
 
 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:
+
+\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í (multiplayer hry, gameplay/menu), dynamické modifikátory a~spouštěče 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í za~skok herní postavy). Předtím tohle a~spoustu dalšího se~muselo naprogramovat ručně.
+\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. Bohůžel jsem nestihl tento nástroj využit v~práci.
+\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 daleko víc, 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í.
+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í.
 
-Podrobné informace jak~každá implementace funguje a~jak s~ní~pracovat, jak~kompilovat a~exportovat projekt  je~popsáno v~přiložené programátorské dokumentaci.
+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.
 
 \section{Herní logika, systémy, mechaniky}
 \label{sec:systemsAndMechanics}
@@ -22,21 +35,21 @@ Protože Unreal Engine byl~na~začátku vyvíjen primárně pro~online multiplay
 
 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.
 
-Protože tento projekt je~zaměřen pro~hru jednoho hráče, práce je~často programována navzdory ustáleným UE~C++ zásadám (guidelines) pro~pohodlí a~rychlost vývoje. Proto~často třídy manažerů systémů, game~modů, instance hráče a~další jsou na~architektuře singletonu. Přináší~to nejen zmíněné pohodlí, ale~navíc šetří od~tří do~deseti 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ýkonem zařízení.
+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.
+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.
-\newpage
-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~jednou 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.
+
+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 Jazyce), 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ětu~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 v~obsáhlém a~repetitivním nastavení každého objektu, který~chceme zapojit do~mechaniky 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.
 
-Byl navržen 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.
+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
@@ -45,12 +58,12 @@ Byl navržen komplexní systém pro~správu každého interakčního objektu a~k
 \label{fig:InteractableSystemDiagram}
 \end{figure}
 
-\newpage
 \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 viditelné hráčem 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}).
+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}).
 
-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 frustrumu 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.
+\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
@@ -59,7 +72,7 @@ Původně bylo předpokládáno využití HLSL compute shaderu\footnote{High-Lev
 \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.
+\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.
 
@@ -68,7 +81,8 @@ Největší přínos nového systému zpracování vstupu v~Unreal Engine~5 se~p
 \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í.
 
-Pro~přiblížení problému, vyjmenuji časté potřeby, které~vznikají při~běžném použití animací.
+\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,
@@ -76,70 +90,76 @@ Pro~přiblížení problému, vyjmenuji časté potřeby, které~vznikají při~
 \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.
+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}
-V~enginu je~zavádějící implementace pokročilého dialogového systému. Dialogy jsou~neintuitivní pro~tvorbu a~použití, vyžadují časté repetitivní kopírování stejných parametrů mezi~soubory dialogů a~k~tomu celý systém má~nedostatečnou dokumentaci. Navíc~,,dialogy'' v~tomto systému jsou~pouze samostatné věty, které~musí přehrávat nějaký zvuk a~mohou se~vybírat v~závislosti na~omezeném kontextu typu ,,kdo~na~koho mluví''. O~nepoužitelností takového rozhraní svědčí návody na~tvorbu vlastních dialogů nebo~vývojářský obchod plný pluginů implementujících tento systém lépe.
+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í.
 
-\newpage
-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.~množinu 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.
+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ého levlu 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 implementovány. Každá z~miniher je~parodie na~již existující známou hru.
+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.
 
-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. Jestli~minihra nebyla ukončena dočasně, ale~dohraná, vráti ovládání zpět hráči spolu s~výsledkem a~skóre.
+\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 Parodie 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). Hráč ovládá minihru pomicí~UI, kde~nakupuje jednotky typu: pěšák, střelec a~tank. 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 Parodie na~mobilní hru 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 část důležitého pro~příběh předmětu. 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 Podoba počítačové rytmické hry Osu!. Hráč má~za~úkol klikat na~objevující~se na~obloze hvězdičky v~souladu s~rytmem hudby (v~pořadí ve~kterém se~objevily). Aktuálně ,,hvězdičky'' jsou~v~podobě čtverečků, ale~hudba je~zcela hotova. Již~teď lze vyzkoušet klikání během prvních 10~sekund hudby.
-\item Podoba mobilní hry Crossy Road. Hráč pomocí pohybu dopředu, dozadu, 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 hry). 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ší (rychlost pohybu není lineární, ale~kvadratická). V~implementaci chybí zvukové assety a~vyváženost složitosti, ale~je k~dispozici kompletní~UI a~mechanika lovu.
+\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 až~zahlédnou hráče.
+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á existující v~enginu 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ě.
+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í) nebo~nevhodná reprezentace rozlišení, které~monitor nebo~GPU uživatele nepodporuje.
+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.
 
-\newpage
-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~příkazové rozhraní enginu.
+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{enumerate}
-\item 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 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 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 Level umožňuje vyzkoušet generování sekvencí chodeb. Chodby by~musely obsahovat patroly a~kryty~tak, aby~hráč dokázal nenápadně prolézt skrz patroly.
-\item Poslední Level bude testovat schopnost navržení herních nepřátel, jejich logiku a~rozmístění na~úrovni. 
-\end{enumerate}
+\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}
-Architektura generování obsahu je~založená na~použití zřetězení různých modelů a~kontrolních mechanismů. Kompletní řetězce modelů jsou~nasazeny na~soukromých serverech, které~v~různých intervalech nezávisle produkují nové assety. Po~generování jsou hotové soubory přemístěny na~veřejné úložiště, odkud~hra při~zapínání stahuje několik~,,náhodných'' assetů (přesnou definici výběru obsahuje \cref{par:contentSharing}).
+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.
 
-\paragraph{Fine-tuning} V~podobě open-source je~k~dispozici většina potřebných druhů modelů. Po~analýze vyplývá, že~bude~potřeba vytvořit pouze jeden~model, 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í.
+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
-Dotrénování může~mít více~podob. Nejspíš by~se~jednalo o~fine-tuning programovacího modelu v~C++ s~dodatečnou syntaxí Unreal Enginu nebo~fine-tuning tvorby diagramů 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. Blueprinty jsou~zdaleka bezpečnější, ale~na~oplátku bude~těžší sbírat trénovací data.
+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í třídícího mechanismu se~vybere příslušná množina dalších modelů, kontrolních mechanismů a~konverzních nástrojů. Asset bude~postupně procházet takovým řetězcem až~nabyde 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.
+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}
@@ -148,36 +168,46 @@ Příklad tvorby interakčního objektu:
 \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~jako~jediný je~natrénovaný na~kontext této~hry.
+\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-testy. 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.
+\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ě.
+\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
-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ů.
+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.
 
-\paragraph{Stahování obsahu}\label{par:contentSharing} Hra automaticky stahuje a~aktivuje obsah před začátkem nové hry. Z~podrobné analýzy jsem~rozhodnul, že~nejsou~zapotřebí žádné autentifikační nebo~šifrovací vrstvy. Vždy~by~byla~možnost zpětnou analýzou (reverse-engineeringem)\footnote{Reverse-engineering je~metoda analýzy hotového produktu (v~nášem~případě binárního souboru), pro~získání neveřejných informací popisujících funkčnost produktu.} získat klíč z~binárních souborů hry a~napadnout celý systém. Když~se~nad~tím zamyslíme, volný přístup k~generovaným assetům nemá žádné zápory. Je~jednoduchý na~implementaci a~údržbu. Očekává~se ale připojení pomocí HTTPS\footnote{Hypertext Transfer Protocol Secure je~protokol pro~šifrovaný přenos dat využívaný pro~poskytování webových serverů.} a~ověření certifikátu\footnote{Certifikáty v~digitální podobě jsou~řetězcem veřejných asymetrických klíčů různých vydavatelů. Každý~předchozí vydavatel ručí za~důvěryhodnost dalšího vydavatele.} s~kopií uloženou v~aplikaci. Mohlo~by~totiž dojít k~man-in-the-middle útoku\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.} a~hráč by~mohl spustit ve~hře nebezpečný obsah.
+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áčů.
 
-Hra zahájí stahování pomocí API, který~vybere nějaké soubory. V~základu assety jsou~vybírány náhodně, ale~zároveň se~používá hodnocení získané od~hráčů, které~váhově lehce~mění hustotu pravděpodobnosti normálního rozdělení.
-
-\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. Protože~nemáme žádnou autentifikaci, volné~hodnocení nemusí fungovat. Kdokoliv může~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~oddálí takovou situaci.
+\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~bude~možné 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.
+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ě.
+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žadují 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 můžeme vystačit si~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 k-DOP\footnote{k-DOP (k-Discrete Oriented Polytope) je~jeden z~postupů obalování složitých 3D~objektu do~jednodušších tvarů.} algoritmus dostupný~v~UE.
+\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}
@@ -187,11 +217,11 @@ Engine disponuje modely základních tvarů (krychle, koule, válec) a~navíc lz
 
 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.
 \newpage
-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.
+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ů. 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é normaly 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.
+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é normaly 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.
 
@@ -352,7 +382,7 @@ Při~tvorbě projektu jsem~si~dal záležet, aby~veškerý text viditelný hrá
 \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.
+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, 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.
 

refs.bib

@@ -36,6 +36,19 @@
   note         = {[cit. 2025-04-01]. Dostupné z: \url{https://alfredbaudisch.com/blog/gamedev/godot-engine/godots-3d-confusing-workflow-inconsistencies-conflicting-behaviours-and-annoyances/}}
 }
 
+@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
+}
+
 @misc{fabRealityCheck,
   title        = {FAB - Review (Disaster for Customers and Sellers)},
   author       = {Unreal Engine Forums},