final

ch1.tex

@@ -8,7 +8,7 @@ Z pohledu hráče nejsou faktory jako pracovní podmínky vývojářů nebo kont
 Jelikož je zábava vysoce subjektivním konceptem, neexistuje univerzální model hry, který by vyhovoval všem uživatelům. Herní design proto využívá analytických metod, jako jsou uživatelské testování, behaviorální analýza a iterativní vývoj, aby maximalizoval pozitivní odezvu v cílové skupině hráčů.
 
 \section{Průběh vývoje}
-Pro nikoho snad není překvapivé, že pro vznik díla je potřeba nějaká myšlenka, která mu předchází. V tomto hry jsou stejný jako každé odvětví. Je potřeba, aby myšlenka byla funkční/potřebná, a v našem případě zábavná. Bohužel hry už z většinou odvětví nesdílí aspekt, při kterém funkčnost myšlenky lze ověřit již na začátku produkce. A je to ještě horší, protože to můžeme většinou zjistit jen až u konce. Spousta her proto potom jsou zamítnuté, neviditelné nebo dokonce předělány hned před koncem. O jednom takovém případu -- který skončil šťastně -- doporučuji si přečíst v knize ,,Blood, Sweat, and Pixels'' od Schreiera Jasona\footnote{Schreier, Jason. Blood, Sweat, and Pixels. HyperCollins US 2017. ISBN 97-800-6265-1235} o hře Uncharted 4. Celkově autor převypráví deset rozhovorů s vývojáři her různých žánrů a velikostí, které mohou začínající/ho vývojařku/e navest co je možné očekávat před, při a po vývoji. Hlavní myšlenkou ale je ukázat jak vývoj každý hry je unikátní příběh, který nemá pravidla.
+Pro nikoho snad není překvapivé, že pro vznik díla je potřeba nějaká myšlenka, která mu předchází. V tomto hry jsou stejný jako každé odvětví. Je potřeba, aby myšlenka byla funkční/potřebná, a v našem případě zábavná. Bohužel hry už z většinou odvětví nesdílí aspekt, při kterém funkčnost myšlenky lze ověřit již na začátku produkce. A je to ještě horší, protože to můžeme většinou zjistit jen až u konce. Spousta her proto potom jsou zamítnuté, neviditelné nebo dokonce předělány hned před koncem. O jednom takovém případu -- který skončil šťastně -- doporučuji si přečíst v knize \textit{Blood, Sweat, and Pixels} \cite{schreier2017blood} o hře Uncharted 4. Autor převypráví rozhovory s vývojáři her různých žánrů a velikostí, které znázorňují unikátní a zároveň společné překážky/problémy v oboru vývoje videoher.
 
 \subsection{Design dokument} Nedílnou součástí vývoje hry je iterace nápadů a celkový popis prostředí a způsobů produkce. To vše v sobě zahrnuje Design dokument. Ten může mít docela různou podobu, jelikož jeho hlavním cílem je uchovat potřebné nápady na rychlém a přehledném místě. Souhrn těchto nápadů, jejích propracovanost a to jak dobře fungují spolu, potom tvoří celou hru i výslednou zábavu. Proto dobré písemné zpracování pomůže předat myšlenky designéra a jejich aktuální verzi celému týmu vývojářů.
 
@@ -24,10 +24,9 @@ Samotná tvorba příběhů je poněkud podobná tvorbě knižní nebo kinematog
 \begin{figure}
 \centering
 \includegraphics[width=.6\linewidth]{img/pacing.pdf}
-\caption{Ukázkový graf představující distribuci klíčových momentů a cesty k ním.\protect\footnotemark}
+\caption{Ukázkový graf představující distribuci klíčových momentů a cesty k ním. Převzato z článku \protect\textit{Gameplay Fundamentals Revisited: Harnessed Pacing \& Intensity} \protect\cite{pacingIntensity}.}
 \label{fig:pacing}
 \end{figure}
-\footnotetext{\url{https://www.gamedeveloper.com/design/gameplay-fundamentals-revisited-harnessed-pacing-intensity}}
 
 \section{Žánr, mechaniky, reference, platforma}
 Důležité je také rozmyslet si vhodné umělecké a technické aspekty hry. Některé herní žánry musí hra obsahovat a některé budou překážet zážitku. Stejně je to i s mechanikami. Například nebude moc zábavné hrát hlavní mechaniku farmářství, pokud cílový žánr hry je horor. Správná volba žánru a mechanik je tedy klíčová pro vytvoření konzistentního a poutavého herního zážitku.
@@ -55,7 +54,7 @@ Tato práce je zamyšlená jako 3D příběhová hra s více žánry a s možnos
 
 \paragraph{Unity\protect\footnote{https://unity.com/}}je nejspíš stale nejpopulárnější volbou v roce vzniku této práce. Lze na něm vytvořit hru libovolného žánru a rozsahu. Má rozhodně největší komunitu a rozsahle návody, jednodušší programovací jazyk C\# a skriptování herních objektů. Zároveň již obsahuje zmíněnou v požadavku možnost načtení obsahu. 
 
-Má ale své problémy, které ohleduplný vývojář procití už v polovině vývoje. 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 pluginu. Následovně i samotný C\# vytváří komplikace s rychlostí běhu programu, obsahem zabrané paměti a garbage collectoru. Všechny tyto problémy lze částečně opravit a vylepšit, jen je potřeba hromada těžších znalostí navíc. Lze o tom přečíst online ~\cite{unityComparing}.
+Má ale své problémy, které ohleduplný vývojář procití už v polovině vývoje. 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 pluginu. Následovně i samotný C\# vytváří komplikace s rychlostí běhu programu, obsahem zabrané paměti a garbage collectoru. Všechny tyto problémy lze částečně opravit a vylepšit, jen je potřeba hromada těžších znalostí navíc. Lze o tom přečíst online \cite{unityComparing}.
 
 V roce 2019 kdy hra přiložena k této práci vzníkalá, byl také problém s paralelizací hlavního cyklu samotného enginu a rendrovacích úloh. V celku Unity tehdy ještě nebyl tak robustní a nenabízel tolik vývojářských možností/oprav. V den vydání této práce, je rozhodně nejlepší volbou nejen pro jednotlivce a malé týmy.
 
@@ -135,16 +134,48 @@ Hlavní problém s hudbou je synchronizace linek. Hudba hodně netoleruje jakék
 \begin{figure}
 \centering
 \includegraphics[width=.6\linewidth]{img/musicLinking.pdf}
-\caption{Diagram znázorňující desynchronizaci hudebních linek kvůli závislosti spouštění funkcí na snímkové frekvenci hry.}
+\caption{Diagram znázorňující desynchronizaci hudebních linek kvůli závislosti spouštění na snímkové frekvenci hry.}
 \label{fig:musicLinking}
 \end{figure}
 
-\paragraph{FMOD\protect\footnote{https://www.fmod.com/}} ... TODO
+\paragraph{FMOD\protect\footnote{https://www.fmod.com/}}je middleware audio engine pro hry poskytující velice silné rozhraní pro práci se zvuky nebo jejich manipulací. Nejčastějí se k němu přiklání pro tvorbu dynamických hudebních doprovodů, což vyplňuje hudební mezeru v Unreal Engine. Je to nejpopulárnější řešení, které se používa od indie po AAA hry. Taktéž v populárních enginech má integrovanou podporu nebo poskytuje engine v podobě samostaného procesu, který potom může komunikovat s procesem hry. FMOD také poskytuje editor zvukových stop a s nimi spojených eventů, pro jednoduché ovládání audia přímo ve hře.
 
 \subsection{Načítání obsahu}
+Integrace nového obsahu do hry za běhu obnáší ošetření spousty technických problémů. Nejzávažnější z ních jsou načténí nového obsahu a jeho kompatibilita. Tyto dvě věci ani nejde ošetřit bez značných omezení a proto jsou ponechány na vývojářech.
 
+\paragraph{Načtení}i těch menších assetů může značně pozastavit hru v načítání. Proto je potřeba načítání nového obsahu provést hned při načtení celé hry, nebo zapracovat nad vhodným malým streamingem dat, který nezpůsobí velkou zátěž na hardware.
+
+\paragraph{Kompatibilita}nového a starého kódu je něco co může zhavarovat celou aplikaci. Naštěstí Unreal Engine řeší havarijní stavy a hra poběží dál, ale potřebné nám assety se již nenačtou. Nejvíc tento problém se projevuje s klasickým kódem v C++, kde výsledný strojový kód očekáva nějakou proměnnu 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 ralativními resp. globálními cesty a názvy. Tak například funkce v blueprintech jsou vždy voláné pomoci názvů funkcí v řetězcové podobě. Stejně tak proměnné jsou uložené ve slovníku variantů. Takové využití víceúrovňové reflexe, umožňuje ošetřit libovolný problém s kompatibilitou a zaručit bezpečný běh za cenu trochu většího zatížení prostředků. Navíc stejnou reflexi v C++ lze jednoduše udělat pomoci maker, které Unreal Engine poskytuje. Ovšem ošetření kompatibility není součástí této práce.
 
 \subsection{Umělá intelegence}
+Nehratelné postavy resp. NPC jsou součastí většíny her, protože pomáhají vyprávět příběh nebo obohatit/oživit prostředí. NPC jako každý herní prvek lze napevno navrhnout a naprogramovat všechny potřebné varianty vzhledů a použití. Ale z dizajnových a časových důvodů ve většíně případu chceme, aby NPC byli více univerzální . Chceme aby mohli samostatně v prostředí orientovat, chodit a občas dokonce, aby NPC reagovali a ovlivňovali prostředi.
 
+\paragraph{Behavior tree}resp. strom pravidel je nejčastěji způsob kódování chování NPC. Takový strom umožňuje efektivní rozhodování a řízení chování umělé inteligence. Hlavní výhodou oproti jiným přístupům, jako například konečné automaty nebo plánování, je modularita, škálovatelnost, snadná údržba a současně přehlednost. Samozřejmě má i nevýhody mezi které zejména patří optimalizace a náročný návrh složitých viceú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í úzly a jak napovídá název, úrčují akci, kterou objekt provede. Cestu od kořene k listům vytvárí řídicí vrcholy, každý z kterých určuje pořadí a podmínky přechodu na podřízené vrcholy. Nejčastějí používáné 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řádí má pozitivně zhodnocené pravidlo,
+\item paralelní resp. Parallel, který spouští podřízený vrcholy současně,
+\item a podmínkové vrcholy, které rozhodují, zda pokračovat v dané větvi nebo se vrátit ke kořenu.
+\end{itemize}
 
 \section{Umělá intelegence pro tvorbu obsahu}
+Celé toto téma je technicky a odborně velice zkrácené s ohledem na rozsah bakalářky. Taky tak jednotlivé modely a práce s nimi nejsou součastí této práce. Táto práce zakláda pouze potřebný koncept pro integraci umělé inteligence.
+
+V současné době díky výkonostním pokrokum se rozšířují hranice použitelností uměle intelegence a to zejmena velké jazykové modely neboli LLM. LLM ukazují skvělé výsledky v generování obsahu různeho charakteru v poměru lidského času a ceny. Nejlepší výsledky jsou zatím v textových nebo grafických modelech.
+
+Již dnes se objevují hry, které integrují dánou technologii. NPC tak umí poměrně realisticky a nekonečně držet konverzaci s hráčem v textové a dokonce i hlasové podobě. Textury a sprity jsou na pohled snad nekonečné, a k tvorbě nevyžadují umělecký cit nebo znalostí. Vývojáři můžou poměrně rychle vygenerovat jednoduchý kód nebo velké konfigurační soubory a struktury.
+
+\paragraph{Udržení kontextu}je největší problém této technologie. Nejvíc se to projevuje při generování videí, kde je zřetelný jak umělý model má potíže udržet konstantní/konkretní obsah nebo myšlenku jednotlivých scén a nasledovně i vzhled vizuálních objektů. LLM z každou další iteraci má poměrně vysokou šanci změnit směr ,,myšlenky''. A to proto, že LLM nemyslí, LLM je pouze konvoluce velkého množství pravděpodobnostní. Tak například LLM nevytváří logicky souvislý text ale pouze predikuje další pravděpodobnostně nejvhodnější sekvence textu na základě trenovaných dat.
+
+Proto zásadní chybou je použití LLM k úplné tvorbě nového obsahu. A spravně je používat LLM pouze jako nástroj buď pro tvorbu počáteční verze obsahu nebo vedlejší obohacení již existujicího díla. Pravě s touto myšlenkou byl doprovázen vzník této práce, déky niž bude možné otestovat jak dobře LLM bude obohacovat již hotovou počítačovou hru. 
+
+\paragraph{Halucinace}jsou další významnou slabinou LLM. Jedná se o situace, kdy model generuje nesprávné, zavádějící nebo zcela smyšlené informace. V kontextu počítačových her tak může docházet například k halucinacím při generování herních dialogů, questů nebo vizuálních prvků, kde model vymýšlí neexistující herní mechaniky, postavy či události, které nepatří do hry. Kořen tohoto problému je stejný jak v udržení kontextu, kde navíc se to prohlubuje slabým natrenováním modelu.
+
+\paragraph{Řešení nejsou dokonalá,}ale mohou výrazně polepšit stav problémů. K dispozici je větší množství metod a některé dokonce proprietární. V teorii se ale většinou jedná o metody:
+\begin{itemize}
+\item retrieval-augmented generation (RAG), která kombinuje model s databází obsahující ověřené informace,
+\item jemné doladění modelu (fine-tuning), které spočívá v dotrenování modelu na specifických datech (na datech naši hry), 
+\item a omezení generativní volnosti pomocí pravidel a pevně definovaných scénářů, které se zároveň kryjí s kontrolními mechanismy a validaci výstupů.
+\end{itemize}

refs.bib

@@ -1,3 +1,20 @@
+@book{schreier2017blood,
+  title={Blood, Sweat, and Pixels: The Triumphant, Turbulent Stories Behind How Video Games Are Made},
+  author={Schreier, J.},
+  isbn={9780062651242},
+  lccn={2017034583},
+  url={https://books.google.cz/books?id=-bK-DQAAQBAJ},
+  year={2017},
+  publisher={HarperCollins}
+}
+
+@misc{pacingIntensity,
+  title        = {Gameplay Fundamentals Revisited: Harnessed Pacing \& Intensity},
+  author       = {Mike Lopez},
+  year         = 2018,
+  note         = {\url{https://www.gamedeveloper.com/design/gameplay-fundamentals-revisited-harnessed-pacing-intensity} [Accessed: (03.2025)]}
+}
+
 @misc{unityComparing,
   title        = {Objectively comparing Unity and Unreal Engine},
   author       = {Sirawat Pitaksarit},
@@ -5,6 +22,11 @@
   note         = {\url{https://gametorrahod.com/objectively-comparing-unity-and-unreal-engine/} [Accessed: (03.2025)]}
 }
 
+
+
+
+
+
 @book{knuth1979tex,
   title={TEX and METAFONT: New directions in typesetting},
   author={Knuth, Donald Ervin},

thesis.tex

@@ -110,6 +110,8 @@
 
 \input{macros} % use this file for various custom definitions
 
+% setup urls
+\usepackage{xurl}
 
 \begin{document}