almost
Some checks failed
CI / Build thesis PDFs (pull_request) Failing after 40s
CI / Verify PDF/A (pull_request) Has been skipped

This commit is contained in:
Oleg Petruny 2025-03-22 22:28:18 +01:00
parent b1b3cd9106
commit e2a0e30278
2 changed files with 73 additions and 8 deletions

74
ch1.tex
View File

@ -45,22 +45,80 @@ Při výběru platformy je nutné zvážit: technická omezení a očekávání
\paragraph{Minihry} jsou skvělou metodou, jak rozptýlit hráče od monotonie herního cyklu. Přitom je lze aplikovat kdykoliv. Minihry většinou buď poskytují odměnu, anebo slouží k relaxaci mezi náročnějšími segmenty hry. Důležité je, aby jejich design byl v souladu s celkovým stylem hry a nepůsobil rušivě. Například rytmická minihra ve fantasy RPG může být zajímavým doplňkem, ale v realistické hororové hře by působila nepatřičně.
\section{Engine}
Když už je rozhodnuto jak bude vypadat hra, je zapotřebí vybrat vhodné prostředí pro její tvorbu. Vývojář může vytvořit vlastní engine, ale dnes to většinou přináši pouze zbytečné komplikace. Proto se na trhu často objevují hotová řešení, která pokrývají většinu potřeb.
Tato práce je zamyšlená jako 3D příběhová hra s více žánry a s možností dynamického načítaní nového obsahu za běhu. A pro tyto účely se nabizí 4 hlavní enginy na trhu.
\paragraph{Unity}\footnote{https://unity.com/} je nejspíš stale nejpopularnější volbou v roce vzníku 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 scriptování herních objektů. Zároveň již obsahuje zmíněnou v požadavku možnost načítaní obsahu.
Má ale své problémy, které ohleduplný vývojař procití už v polovině vývoje. Tvorba dobré grafiky často vyžaduje napsaní vlastních HLSL shaderů, což moc nekoreluje s jednoduchostí C#. Navíc grafika často vyžaduje napsaní 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 v ~\citet{unityComparing}.
V roce 2019 kdy hra přiložena k této práci vzníkala, 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ývojařských možností/oprav. V den vydání této práce, je rozhodně nejlepší volbou nejen pro jednotlivce a malé týmy.
\paragraph{Godot}\footnote{https://godotengine.org/} je velmi dikutovaná novinka, která se celkem dobře rozšiřuje. Hlavní výhoda je jeho drobnost a že je úplně zdarma za všch okolností. Má podobné problemy jako Unity a někdy ještě horší. Je ale vskutku ohromujicí, co vše může nabídnout. Ikdyž většinu nabízených technologií vývojař potřebuje přepsat vlastní rukou, jelikož často nefungují jak je zapotřebí. V dobu vzniku hry přiložené k práci, Godot byl ještě přiliš nový a nevypadal nijak perspektivně. V den vydání této práce, je solidní konkurent v některých herních žánrech.
\paragraph{Unreal Engine}\footnote{https://www.unrealengine.com/} verze 4 byl kdysi zvolen enginem pro hru, z které potom vznikla tato práce. Jeho primární výhodou oproti konkurenci jsou vysoce standartizované postupy neboli anglicky ,,pipliny'', které zlevňují nebo vůbec umožňují tvorby her ve velkých týmech. Celý engine se navíc vychlubuje 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ší.
Vskutku ohromující když se snažite vybrat budoucí stavební kámen pro váši hru. Je ale potřeba brát v úvahu silnou nepřivětivost enginu k nováčkum, pokud ti chtěji udělat neco vlastního mimo již existujicí 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ývojař musí dané technologie ovladnout na velmi vysoké úrovně a často i modifikovat zdrojový kód. 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í.
Jestli zapomenout na chybějicí dokumentaci, je Unreal Engine stejný engine jako ostatní. Některé technologie má nesrovnatelně lepší a nekteré horší. Lze najít návody a neoficiální dokumentaci diky velké komunitě. Dokonce samotný engine si dovoluje sebe modifikovat, protože lze dostat přístup ke zdrojácím. Což velké týmy tuto nezávislost s radostí využívají.
\paragraph{CryEngine}\footnote{https://www.cryengine.com/} je hodně podobný Unreal Enginu za výjimkou toho, že se specialuzuje jen na vývoj her. Taky již není tolik univerzalní, dokumentace je ještě míň, komunita je mizerně malá a přivětivost je snad nejhorší možná. Je to dost úzce specializovaný engine, který potřebuje silné odborníky k jeho ovládání.
\subsection{Programovácí jazyk}
Unreal Engine umožňuje programovat pomoci vizuálních bloku tzv. Blueprintů nebo textově v jazyce C++. I při použití pouze jedné z variant lze vivinout celou hru. Veškerý potenciál se ale projevuje při jejích kombinaci. V C++ se skvěle programují komplexní a nizkoúrovňové prvky, když to Blueprinty jsou skvěly pro skriptování úrovní a objektů pomocí high-level bloků. Samozřejmě samotné vizuální bloky lze v C++ vlastnoručně vytvořit.
Je to vše zároveň velmí obsáhlý aspekt Unreal Engine. Začatečníkovi bude celkem dlouho trvat než začné sám něco vymýšlet. A na první pohled jednoduchý vizuální programování je ve skutečností velmi komplexní už samotnou teměř nekonečnou nabídkou funkcí.
\subsection{Grafika}
\subsection{Renderer}
\subsection{Materiály}
\subsection{Osvětlení}
\subsection{Postprocessing}
\subsection{3D modely}
\subsection{2D modely}
\subsection{Animace} (shader a skeleton)
\subsection{Instancování/Foliáž}
Unreal Engine poskytuje širokou nabídku technologií a nástrojů pro tvorbu grafiky nebo začlenění do hry 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 behěm celého vývoje hry. Základní nastavení totiž jsou příliš univerzalní a nekompletní. Přestože i v základu hra snimi vypadá na dostatečné úrovní, při hraní bude stalý pocit nedokončenosti produktu nebo kopirování cizího díla. Většina vývojařu totiž si nedají zaležet, jak jejich hra vypadá kvůli lenosti nebo technické náročnosti tohoto kroku. Proto se většina her cití jak si podobný a nepřijemný pro hráče.
\subsubsection{Materiály}
Materiál je odborné označení souboru dat a funkcí, které reprezentují výsledný vzhled objektu/efektu/světla/postprocessu. Je to de-facto vysokourovňový shader, který i přestože je dost omezený dokaže generovat skvělý a kreativní výstup. Případně lze zdrojový kód materiálů rozšířit na potřebné funkcionality a v případě nouze napsat i vlastní render pipelinu, jak to dělají velký studia nebo nezavislé github projekty.
\paragraph{HLSL shadery} lze v Unreal Engine napsat a aplikovat. Je to ale hodně nezdokumentovaný aspekt a zahrnuje spoustu práce okolo, narozdil od toho jak to je v Unity před verzi 6.
\subsubsection{Osvětlení}
Unreal Engine vyníká právě bohatým výběrem možsností provedení osvětlení. Lze zde najít ruzné druhy přimých a nepřimích zdrojů světel a mlhy, technik odrazů a stínů. Všechno lze velmi podrobně nastavit buď pro účely výkonu nebo grafické estetiky.
\paragraph{Lumen}\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/lumen-global-illumination-and-reflections-in-unreal-engine} je zdánlivě revoluce v realtime herním osvětlení. Je to speciální režim osvětlení a odrazů, který umožňuje za běhu počítat dynamické osvětlení bez potřeby vytváření lightmap nebo dotěrného nastavení ploch odrazů. Vytváří velice kvalitní osvětlení za opravdu malo úsili. Nevýhodu, kterou ale již neprezentují, není tolik trochu větší zátěž na hardware, ale šum vyrendrovaného osvětlení a odrazů. Lumen totíž v reálném čase generuje buffer s odrazy a osvětlení ve velice malém rozlišení a to navíc vynacháva nahodně zhruba polovina pixelů. Potom výsledný buffer se rescaluje na potřebné rozlišení a aplikuje. Celé se to spoléha na zhlazovací metodu TAA, která akumuluje výsledky předchozích snímku a interpoluje jich do aktuálního, což šum zdanlivě dobře potlačuje ikdyž ne kompletně. Ve výsledku tak potom TAA vytváří ghosting effekt nejen na hranach objektů ale i osvetlení s odrazy, což dost bije do oka v dynamických scénach.
\subsubsection{3D}
Unreal Engine podporuje import 3D modelů z různých formátů. Navíc k tomu poskytuje dostatečné množstí optimalizačních technik jako např.:
\paragraph{Render occlusion culling} vykresluje objekty pouze pokud se nacházi v zorném poli kamery, nebo
\paragraph{Level Of Details(LOD)} vykreslující různě detalizované verze objektu v závislosti na jeho vzdalenosti od hráče, protože proč vykreslovat detaily, které z dálky nejsou vidět.
\paragraph{Nanite}\footnote{https://dev.epicgames.com/documentation/en-us/unreal-engine/nanite-virtualized-geometry-in-unreal-engine} je ještě jedná specialita Unreal Engine 5, která umožňuje vykreslování a instancování objektů s miliony až miliardy trojúhelniků v reálnem čase. Umožňuje tak použití v enginu super detalizovaných objektů, získaných pomoci skenování objektů v realitě. Technika je založená na předčasné clustarizaci a následně dynamickém streamování pouze viditelných trojúhelníků. Bohužel neumožnujě kompletního vynechání LOD systému, jak to reklamuje 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 stale zustáva nejefektivnější technikou zlevnění vykreslovacího času objektu.
\paragraph{Instancování/Foliáž} umožňuje zmenšení paměti potřebnou pro reprezentaci skupiny stejných objektů a výsledně i zlevnění rendrovací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 táto technika používa pro naplnění světa různými drobnými objekty (instancování) nebo tvorbu vegetace (foliáž).
\subsubsection{Animace}
Unreal Engine pokrýva veškeré potřeby pro animaci libovolného druhu. Jen neposkytuje žádne high-level ovladaní přehrávání a proto užitelský ovládání a triky je potřeba dodělat manuálně.
\paragraph{Skeleton} animace je založená doslova na animování kostry přivázané k 3D modelu. Skupiny trojúhelníků jsou namapovany na úrčité kosti, tak že při pohybu kosti je stejným směrem interpolovaná pozice trojúhelníků. Daný druh 3D animace může vytvářet velkou zátěž na procesor zejména při velkém počtu instancí, jelikož ten musí propočitávat pohyb každé kostí vůči hernímu světu a až potom odesílat rendrovací požadavek na grafiku. Přesto daná technika tvoří převažnou čast všech animací ve hře.
\paragraph{Shader} animace je exotická technika s myšlenkou přeskočit krok s výpočtem na procesoru. Animace se zakóduje do textury a následovně je aplikováná ve vertex shaderu jako offset vrcholů. Výsledně lze například velmi levně animovat velké hejno ptáků, který nemusí mít kolizi ve světě.
\subsubsection{Renderer}
V Unreal Enginu lze vybrat mezi Forward a Deffered renderem. Jsou to systémy které se starájí o zpracování grafiky a vykreslování scény. Zajišťují převod 3D objektů a jejich vlastností na obraz, který se zobrazí na monitoru. Renderer pracuje s osvětlením, stíny, materiály a postprocessingovými efekty pro dosažení realistické nebo stylizované grafiky.
\paragraph{Forward Renderer} Forward rendering je metoda renderingu, kde se každý objekt renderuje jednotlivě se všemi aplikovanými světelnými efekty. Je vhodný pro scény s malým množstvím světel a vyžaduje menší paměťovou náročnost. Používá se často v mobilních a VR aplikacích, kde je důležitá efektivita výkonu.
\paragraph{Deferred Renderer} Deferred rendering odkládá aplikaci světelných efektů a v první fázi ukládá informace o geometrii scény do bufferu (G-buffer). Světla se aplikují až v druhé fázi, což umožňuje efektivnější práci s větším množstvím dynamických světených zdrojů. Tato metoda se používá především v moderních AAA hrách, kde je vyžadována vysoká vizuální kvalita. Je to výchozí renderer v Unreal Engine, který navíc umožňuje použití technologií Nanite a Lumen.
Nevýhodou je nemožnost použití kvalitních zhlazovácích metod jako MSAA. MSAA funguje tak, že ukládá 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-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 nebo TAA. Poslední ale vytváří rozmazávaní hran objektů v dinamických scénach.
\subsubsection{Postprocessing}
Postprocessing je technika dodatečného zpracování vyrendrovaného obrazu. Většínou se jedná o manipulaci barev, ale lze tady dělat i spoustu dizajnovych a technickych triků. Např. různé glitch efekty, screen space světelné efekty, efekty tepleného/nočního vidění atd..
\subsubsection{2D}
\subsection{Zvuk}
\subsection{Hudba}
\subsection{Načítání obsahu}
\subsection{Umělá intelegence}
\section{Umělá intelegence pro tvorbu obsahu}

View File

@ -1,3 +1,10 @@
@misc{unityComparing,
title = {Objectively comparing Unity and Unreal Engine},
author = {Sirawat Pitaksarit},
year = 2019,
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},