up to minigames review

ch2.tex

@@ -1,40 +1,42 @@
 \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~napsal znovu. UE~citelně rozšířil seznam dostupných tříd, přitom~některé jsou~již deprecated nebo~odstráněny úplně. Tak~například byly~odstraněny třídy Matinee (bývalý format 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~museli předělat).
+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).
 
-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:
+Přenos byl~odůvodněn převážně malou velikostí starého projektu a~taky lákavou nabídkou nových technologií, zejména Nanite a~Lumen. Navíc pátá verze Unrealu -- přesněji verze~5.5 -- přinesla značná vylepšení jako:
 \begin{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 naraz 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í (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 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áve 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. Dnes bychom určitě využili této~možnosti.
+\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 nastroj 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. Bohůž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.
+\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~například 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ěli vliv na~rozhodnutí.
+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í.
 
-Podrobné informace jak každá implementace funguje a jak vývojáři s ní pracovat jsou popsané v programátorské dokumentaci.
+Podrobné informace jak~každá implementace funguje a~jak s~ní~pracovat, je~popsáno v~přiložené programátorské dokumentaci.
 
 \section{Herní logika, systémy, mechaniky}
 \label{sec:systemsAndMechanics}
 \subsection{Architektura}
-Protože Unreal Engine byl na začátku vyvíjen primárně pro online multiplayer hru Unreal Tournament a dnes stejně tak vyvíjen spolu s extrémně velkou online multiplayer hrou Fortnite, je backend enginu velmi abstraktní. 
+Protože Unreal Engine byl~na~začátku vyvíjen primárně pro~online multiplayer hru Unreal Tournament a~dnes~je stejně~tak vyvíjen spolu s~extrémně velkou online multiplayer hrou Fortnite, je~backend enginu velmi abstraktní. 
 
-Například každý svět musí obsahovat vlastní game mode (třída AGameMode), který funguje jako správce daného světu -- přestože svět se může spravovat sám. Veškerá funkcionalita používaná v singleplayer hrách mohla by 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.
+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áná navzdory ustálený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ší jsou na architektuře singletonu. Přináší to nejen zmíněné pohodlí, ale navíc šetří od tří do desetí různých volání getteru, cast reflexe, 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 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í.
 
-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.} taktéž lze 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. Narozdíl od jiných enginů, v UE objekty ve světě nemůžou referencovat jiné nezávislé objekty. Jednoduše referenci nejde 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 príkladu chce otevřít dveře, musí zkusit poslat požádavek správcí herního světa, ten požadavek se nějak zpracuje a jen potom správce buď provede akci otevírání dveří samostatně nebo zavolá odpovídající funkci v instanci objektu. Pokud by byla potřeba zbavit se použití singleton architektury pro podporu paralelní existenci světů, stači předělat 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.
+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 prí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.
 
-Navíc hra byla rozšířena o implementaci obnovení hry z úložených dat. Při návrhu byla snaha udělat postup nejvíc triviální. Hru ukládá 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í. Využít byl existující v UE systém serializace, který ukládá inventář postavy, jmeno levelu a checkpoint na něm spolu s posledním stavem levelu.
+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 pomoci architektury interface tříd\footnote{Interface třídy jsou konkurenčním přístupem komponentní architektuře. Interface je běžná praktika v OOP, 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 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.
 
-Byl navržen komplexní systém pro správu každého interakčního objektu a komponent (viz.\Cref{fig:InteractableSystemDiagram}). Objekt dědicí třídu AInteractable při instancování samostatně nastaví a následně přepíná potřebné kolize. Navíc spravuje interakční komponenty a reaguje na požadavky k ním. Komponenty se dělí na aktivátory a modifikátory.
+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.
 
 \begin{figure}
 \centering
@@ -44,9 +46,11 @@ Byl navržen komplexní systém pro správu každého interakčního objektu a k
 \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 taky může obsahovat libovolný aktivator. Práce obsahuje klasický způsob detekce objektů pomoci raytracingu a dereference objektu v případě nárazu paprsku.
+\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í dereference 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 pipline 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 kníhovna 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ůvodu jsem nedodělal přenos dat mezi CPU a GPU, jelikož dohledat dokumentaci o použití shaderu je dost 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 takový úkol řeší náhodným promítáním velkého množství paprsků nebo velkým hitboxem napodobující tvar frustrumu kamery. Taková řešení jsou sice rychlá na implementaci, ale začínají být nekvalitní až nepoužitelné pro trochu větší vzdálenosti než ,,pár metrů''. Navíc zahrnují časté počítání nárazů na velké množství objektů, čímž výkonnostně nejsou o nic lepší implementované metody v této práci.
+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}).
+
+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 (nad pár metrů) vykazují výrazné snížení přesností nebo zcela neefektivními. 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
@@ -55,27 +59,30 @@ Navíc je k dispozici detekce objektů v zorném poli hráče. Ta funguje na zpo
 \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 zahlednutím ,,očí'' 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ůvodu byla zamítnuta implementace modifikace meshe objektu, která by využívala nového rozhraní Chaos.
+\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.
 
-Právě u modifikátorů nejvíc přispěl nový systém zpracování vstupu pro Unreal Engine 5. Modifikatory využívájí možnosti přidávání resp. odstranění kontextů vstupu za běhu.
+Z~časových důvodů byla zamítnuta implementace modifikace geometrie objektu, která~by~využívala nového rozhraní Chaos.
+
+Největší přínos nového systému zpracování vstupu v~Unreal Engine~5 se~projevil právě u~modifikátorů. Ty~využívají možnost dynamického přidávání nebo~odstraňování vstupních kontextů za~běhu.
 
 \subsection{Cutscény a Quick Time Events}
-Unreal je slavný, jak dobře lze v něm animovat scénu. Rozhraní a editor systému Sequencer je pohodlné a bohaté na funkcionality. Bohůžel veškeré skvěle věci končí mimo editor, jelikož chybí pohodlná funkcionalita režie různých souborů animací (stejná poznámka se vztahuje i k UI animacím). Proto byl dodán systém UCutsceneManager implementující frontu animací spolu s uživatelským rozhraním přeskočení animace.
+Unreal Engine je~známý~tím, jak~dobře umožňuje animovát scény. Rozhraní a~editor systému Sequencer je~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í.
+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 Zároveň spuštěné animace bojují o~vlastnictví objektů,
 \item animace nelze přetáčet,
-\item u animace nelze zjistit zpětně jestli byla přehrana do konce, pouze přivázat volání funkce po ukončení,
+\item u~animace nelze zjistit zpětně zda~byla přehrána až~do~konce, pouze přivázat volání funkce po~ukončení,
-\item animace umí říct jestli je někde přehráváná, ale neřekne kde.
+\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 nečekaný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 postavy. Při takových událostech lze přiblížit hráče k dynamické a napínavé situaci pomoci 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íc-krátné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 souborů dialogů a k tomu celý systém má nedostačující dokumentace. 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 rozhrání napovídají návody na tvorbu vlastních dialogů nebo vývojářský obchod plný pluginů implementujících tento systém lépe.
+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.
 
-Protože kvalitná řešení jsou placená a ty zdarma jsou často nevyhovující kvality, byla navržená vlastní implementace. Jedna 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. Jedná 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 do poslední, jednu náhodnou větu nebo přesně jednu větu podle id.
+\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.
 
 \subsection{Minihry}
 Gameplay druhého levlu je celý složen z miniher. V moment vydání -- práce obsahuje pouze pět hlavních pro game design miniher v podobě ,,proof of concept''. Z časových důvodů zbylé vedlejší minihry nebyly implementovány. Každá z hlavních miniher je parodie na již existující známe hry.
@@ -85,14 +92,14 @@ Minihry jsou samostatné objekty, které manažer scény restartuje nebo vypín
 Dostupné zkušební implementace:
 \begin{itemize}
 \item Parodie flash hry Age of War. V pozadí uklízení knížek dějepisu jsou umístěny základny hráče a soupeře (umělé inteligence). Hráč ovládá minihru pomici 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á soupeř, který dokázal přejít přes jednotky nepřátele až k základně a zdemolovat ji. V aktuální implementaci chybí vylepšení éry jednotek, zvuky, grafické efekty, modely a animace jednotek. Přesto lze vyzkoušet nakup a jejich ,,souboj'' jednotek.
-\item Parodie na mobilní hru Subway Surfers. Aktuálně má minihra nevhodné pozadí, neobsahuje audio a grafické prvky. Podle návrh hráč nahání veverku v lese, která mu ukradla část důležitého pro příběh předmětu. Pomoci pohybů nahoru, dolu, doleva a vpravo hráč uhýbá objevujícím se lesním překážkam. Překážková dráha má šířku třech běžících pruhů a překážky mohou vyžadovat přeskočení, sklouznutí nebo úhyb do strany.
+\item Parodie na mobilní hru Subway Surfers. Aktuálně má minihra nevhodné pozadí, neobsahuje audio a grafické prvky. Podle návrh hráč nahání veverku v lese, která mu ukradla část důležitého pro příběh předmětu. pomocí pohybů nahoru, dolu, doleva a vpravo hráč uhýbá objevujícím se lesním překážkam. Překážková dráha má šířku třech běžící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í pro prvních 10 sekund doprovodu.
-\item Podoba mobilní hry Crossy Road. Hráč pomoci pohybu dopředu, dozadu, doleva a dolu 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áctí 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ď teď lze vyzkoušet posun dopředu a úhyb překážkam.
+\item Podoba mobilní hry Crossy Road. Hráč pomocí pohybu dopředu, dozadu, doleva a dolu 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áctí 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ď teď lze vyzkoušet posun dopředu a úhyb překážkam.
 \item Jednoduchá minihra rybolovu (více podob napříč různými hry). Hráč má na obrazovce svislý obdelní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 dolu 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.
 \end{itemize}
 
 \subsection{Nehratelné postavy}
-Pro tvorbu NPC (Non-Playable Characters) byli použité základní prostředky enginu. Podle dizajnu hry, k dispozici by měli být tři druhy logiky pro NPC, ale z časových důvodu 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.
+Pro tvorbu NPC (Non-Playable Characters) byli použité základní prostředky enginu. Podle dizajnu hry, k dispozici by měli 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žíváji nový pro UE5 systém vjemů nehratelných postav. Postavy tak 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.
 
@@ -105,7 +112,7 @@ Hra využívá existující v enginu de/serializace v textovém formátu ,,.ini'
 
 Triviálně se pracuje s preferencemi hráče, které určují hlasitost různých kategorií zvuků nebo preferencemi ovládání. Tam 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. Zejmená změny zaměřené na okno aplikace mohou zhavarovat a vypnout hru 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í znamenát problem v aplikaci. Například předčasný zásah OS k neodpovídajícímu procesu (hra se delší dobu načítá po aplikaci nového nastavení) nebo nevhodná reprezentace rozlišení, které monitor nebo GPU uživatele nepodporuje.
 
-V libovolném případě hra musí být schopna obstát nečekáné závady, a proto byl navržen mechanismus obnovení předchozích funkčních nastavení. Po zvolení nových parametrů a jejich aplikaci, hra nejprv uloži stávájící nastavení a až poté aplikuje ty nová. Po aplikovaní 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.
+V libovolném případě hra musí být schopna obstát nečekáné závady, a proto byl navržen mechanismus obnovení předchozích funkčních nastavení. Po zvolení nových parametrů a jejich aplikaci, hra nejprv uloži stávájící nastavení a až poté aplikuje ty nová. Po aplikovaní 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ůvodů změnu neschválí, potom jsou obnoveny předchozí parametry.
 
 Navíc právě nastavení zobrazení okna (a výber zhlazovácí metody) byly ručně implementovány, 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ěná režimu vykreslování okna (neokenní, okenní bez rámce, okenní s rámcem), změná obnovovací frekvence. Při výběru a nastavení rozlišení se pracuje napří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.
 
@@ -130,7 +137,7 @@ Architektura generování obsahu je založená na použití zřetězení různý
 Dotrénování může mít více podob. Nejspíš by se jednalo o fine-tuning programovácího modelu v C++ s dodatečnou Unreal Engine syntaxí 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 co je lepší, obě metody vyžadují ověřit. Pro C++ modely je víc dat a k tomu toto prostředí má více kreativní svobody, přestože může zhavarovat aplikaci. Blueprinty jsou zdaleka bezpečnější, ale na oplátku bude těžší sbírat trénovací data.
 
 \paragraph{Postup generování}
-Vše by začínálo v textovém modelu, který vytvoří typ a popis generováného objektu. Pomocí třídícího mechanismu se vybere potřebná množina ostatních modelů, kontrolních mechanismu a konvertovácí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 pomoci unit-testů ve hře. Pokud asset neprojde validací, celý postup, soubor a vstupní popis se zalogují pro budoucí ruční fine-tuning.
+Vše by začínálo v textovém modelu, který vytvoří typ a popis generováného objektu. Pomocí třídícího mechanismu se vybere potřebná množina ostatních modelů, kontrolních mechanismu a konvertovácí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 zalogují pro budoucí ruční fine-tuning.
 
 Příklad tvorby interakčního objektu:
 \begin{enumerate}
@@ -145,15 +152,15 @@ Příklad tvorby interakčního objektu:
 \end{enumerate}
 
 \subsection{Poskytování obsahu}
-\paragraph{Nasazování generátoru} Nezávislé řetězce modelů zjednodušují řízení sítě workerů. Pomoci docker containeru\footnote{Docker je software umožňující lokální virtualizaci prostředí nazývané containery.} nebo nasazovacího skriptu by se snadno vytvořil další nový worker (naše generující jednotka), který může ihned začít s generováním. Vygenerovaný obsah poté může být ihned přemístěn na veřejné úložiště, a proto worker nepotřebuje nijak velké úložiště. Protože workery nemusí odpovídat na požadavky uživatele v reálnem čase a plánovaná doba jedné hry je 15-30 minut nemusí generátory být rychlé a tedy ani náročné na výpočetní prostředky. Nezáleží nám ani na dlouhodobé životností workeru, jelikož modely se často sekvenčně přepínají resp. 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 jednotky megabajtů a máme větší časový intervaly mezi vznikem souborů.
+\paragraph{Nasazování generátoru} Nezávislé řetězce modelů zjednodušují řízení sítě workerů. pomocí docker containeru\footnote{Docker je software umožňující lokální virtualizaci prostředí nazývané containery.} nebo nasazovacího skriptu by se snadno vytvořil další nový worker (naše generující jednotka), který může ihned začít s generováním. Vygenerovaný obsah poté může být ihned přemístěn na veřejné úložiště, a proto worker nepotřebuje nijak velké úložiště. Protože workery nemusí odpovídat na požadavky uživatele v reálnem čase a plánovaná doba jedné hry je 15-30 minut nemusí generátory být rychlé a tedy ani náročné na výpočetní prostředky. Nezáleží nám ani na dlouhodobé životností workeru, jelikož modely se často sekvenčně přepínají resp. 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 jednotky megabajtů a máme větší časový intervaly mezi vznikem souborů.
 
-\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 reverse-engineeringem\footnote{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.} získat klíč z binárních souborů hry a napadnout celý systém. Jestli se zamyslet, volný přístup k generovaným assetům nemá žádné zápory. Je jednoduchý na implementaci a udržbu. Je ale očekáváné přípojení pomoci 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 kopii 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.
+\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 reverse-engineeringem\footnote{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.} získat klíč z binárních souborů hry a napadnout celý systém. Jestli se zamyslet, volný přístup k generovaným assetům nemá žádné zápory. Je jednoduchý na implementaci a udržbu. Je ale očekáváné přípojení 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 kopii 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.
 
-Hra zahájí stahování pomoci 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í.
+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} Potom co hráč zahraje s úrčitým assetem, máme možnost získat odezvu od hráče. Hodnocení využíjeme k váhové manipulaci náhodného výběru a zároveň jako data pro doládě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áčů, které si s tímto obsahem opravdu zahráli. Protože nemáme žádnou authentifikaci, 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. Authentifikáce tomu taky nezabraní, pouze oddálí takovou situaci.
 
-Některé hry v praxi používájí sofistikováné metody využívájící detekci nelegální kopie hry, nebo vyžití API herních obchodů (dosažení, odznaky, id účtu atd.). Takové metody se zdají být účinné, ale už dávno se lehce obchází pomoci triviální simuláce API odezvy.
+Některé hry v praxi používájí sofistikováné metody využívájící detekci nelegální kopie hry, nebo vyžití API herních obchodů (dosažení, odznaky, id účtu atd.). Takové metody se zdají být účinné, ale už dávno se lehce obchází pomocí triviální simuláce API odezvy.
 
 Táto práce nabízí sledování id účtu hráče, který hru zahrál a jeho seznam stažených souboru, pokud hra bude šířená na platformě Steam. UUID (Unique User Identificator) účtu ví pouze vlastník účtu, čili je to citlivá informace. Proto před odesláním takových dat budeme je 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 v Steam opravdu vlastní hru, že takový UUID stahovalo tento obsah z našeho serveru a že toto UUID ještě tento obsah nehodnotilo.