ch2.tex

@@ -29,7 +29,7 @@ Jen pro představu, co~obnáší klasické získání reference na~instanci vlas
 \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 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.
+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.
 
 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.
 
@@ -46,11 +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 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.
+\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}).
 
-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.
+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.
 
 \begin{figure}
 \centering
@@ -66,7 +66,7 @@ Z~časových důvodů byla zamítnuta implementace modifikace geometrie objektu,
 Největší přínos nového systému zpracování vstupu v~Unreal Engine~5 se~projevil právě u~modifikátorů. Ty~využívají možnost dynamického přidávání nebo~odstraňování vstupních kontextů za~běhu.
 
 \subsection{Cutscény a Quick Time Events}
-Unreal Engine je~známý~tím, jak~dobře umožňuje animovát scény. Rozhraní a~editor systému Sequencer 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í.
+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í.
 \begin{itemize}
@@ -108,72 +108,76 @@ V~implementaci chybí kompletní logika boje s~hráčem. Aktuálně postavy pouz
 Každé chování využívá Navmesh pro~orientaci na~úrovni.
 
 \subsection{Nastavení}
-Hra využívá existující v enginu de/serializace 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. Tak k tvorbě vlastních parametrů stačí pouhá deklarace potřebných proměnných v C++ třídě.
+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ě.
 
-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.
+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.
 
-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.
+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.
 
-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.
+\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.
 
 \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ývala rozsáhlé herní žánry a situace, které dosud nebyly nebo nejsou často využívané s generovanou tvorbou.
+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é znalostí o lidském organismu, aby dokázal generovat strašidelný obsahu a následně ho správně režisérský 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 vygenerováné minihry.
-\item Level existuje pro generování nových logických úseků resp. ú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 museli 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, jejích logiku a jejich rozmístění na úrovní. 
+\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}
 
 \subsection{Návrh architektury}
-Architektura generování obsahu je založená na použití zřetězení různých modelů a kontrolních mechanismu. Kompletní řetězce modelů jsou nasazeny na soukromých serverech, které v různem intervalu nezávisle produkují nové assety. Po generaci assety jsou přemístěné na veřejné úložiště, odkud hra při zapínání stahuje nějaké množství ,,náhodných'' assetů (přesná definice výběru je vystvětlená později v podsekci \cref{par:contentSharing}).
+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}).
 
-\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í.
+\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í.
 
-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.
+\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.
 
 \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 pomocí 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čí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.
 
 Příklad tvorby interakčního objektu:
 \begin{enumerate}
-\item LLM vytváří popis assetu, v tomto případě nějaký interakční objekt, který umí přehrávat určitý zvuk a je umístěn nějakým způsobem na levelu 3.
-\item Kontrolní mechanismus vybírá následující potřebné modely a nástroje.
+\item LLM vytváří popis assetu, v~tomto případě interakční objekt, který~přehrává specifický zvuk a~je~umístěn na~konkrétním místě v~levelu~3.
+\item Kontrolní mechanismus vybírá následující potřebné modely a~nástroje.
 \item Popis prochází modelem generující obrázky.
-\item Obrázky prochází modelem generující 3D model (Nejdřív se generuje 360° video potřebného objektu, z kterého se následně generuje mesh).
-\item Další část popisu je použita modelem generující zvukové stopy.
-\item Poslední čast popisu se vloží do našeho dotrenováného programovácího modelu. Tento model se zároveň stará o umístění assetu v herních světech, protože jako jedíný je natrénovan na kontextu teto hry.
-\item Výsledné kousky linkovací mechanismus spojí do jedné třídy resp. vloží do jednoho Blueprintu. Předtím kousky konvertuje do assetů 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, kousky a výsledek se logují pro budoucí investigaci.
+\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 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.
 \end{enumerate}
 
 \subsection{Poskytování obsahu}
-\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{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ě.
+\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ů.
 
-\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.
+\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.
 
-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í.
+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.
+\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.
 
-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.
+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 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.
+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ůvodu, nám nebude vadít, ž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~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.
 
-Pořád bude možné revers-engeneernout 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.
+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ástrojí 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 tež vyžadují vlastní model, ale jsou tvořeny pomocí grafových prvků napodobující blueprinty 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álu a pouze vytvořit 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 postupu 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ž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.
 \end{itemize}
 
 \section{Grafika}