diff options
| -rw-r--r-- | .vscode/settings.json | 4 | ||||
| -rw-r--r-- | contributing.md | 3 | ||||
| -rw-r--r-- | glossary.bib | 30 | ||||
| -rw-r--r-- | latexmkrc | 45 | ||||
| -rw-r--r-- | projdoc.cls | 42 | ||||
| -rw-r--r-- | research.tex | 299 |
6 files changed, 301 insertions, 122 deletions
diff --git a/.vscode/settings.json b/.vscode/settings.json index 72f0e6b..25effcc 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -1,4 +1,8 @@ { + "editor.wordWrap": "wordWrapColumn", + "editor.wrappingIndent": "same", + "editor.wordWrapColumn": 85, + "files.trimTrailingWhitespace": true, "latex-workshop.latex.recipe.default": "latexmk", "latex-workshop.latex.tools": [ { diff --git a/contributing.md b/contributing.md index 770d02e..dd51532 100644 --- a/contributing.md +++ b/contributing.md @@ -15,7 +15,8 @@ other document. - Images should be placed in the img/ folder - Labels and bibliography keys should only consist of characters from the following set: `[a-z0-9:-]` (lower-case, numbers, colon, dash). -- Quotes are opened with the tilde (<code>`</code>) +- Quotes are opened with a backtick (<code>`</code>) +- Only environments indent the LaTeX source code # Banned practices diff --git a/glossary.bib b/glossary.bib new file mode 100644 index 0000000..4d02e4a --- /dev/null +++ b/glossary.bib @@ -0,0 +1,30 @@ +@abbreviation{ecs, + short = {ECS}, + long = {Entity-Component System}, +} + +@abbreviation{hid, + short = {HID}, + long = {Human Interface Device}, +} + +@abbreviation{sdl2, + short = {SDL2}, + long = {Simple DirectMedia Layer}, +} + +@abbreviation{sfml, + short = {SFML}, + long = {Simple and Fast Multimedia Library}, +} + +@entry{opengl, + name = {OpenGL}, + description = {Open-source graphics library}, +} + +@entry{d3d, + name = {Direct3D}, + description = {Graphics library developed by \hbox{Microsoft}}, +} + @@ -2,3 +2,48 @@ $pdflatex = "xelatex %O %S"; $pdf_mode = 1; $dvi_mode = 0; $postscript_mode = 0; + +# https://tex.stackexchange.com/questions/400325/latexmkrc-for-bib2gls +add_cus_dep('glo', 'gls', 0, 'run_makeglossaries'); +add_cus_dep('acn', 'acr', 0, 'run_makeglossaries'); +add_cus_dep('aux', 'glstex', 0, 'run_bib2gls'); + +sub run_makeglossaries { + if ( $silent ) { + system "makeglossaries -q '$_[0]'"; + } else { + system "makeglossaries '$_[0]'"; + }; +} + +sub run_bib2gls { + if ( $silent ) { + my $ret = system "bib2gls --silent --group '$_[0]'"; + } else { + my $ret = system "bib2gls --group '$_[0]'"; + }; + my ($base, $path) = fileparse( $_[0] ); + if ($path && -e "$base.glstex") { + rename "$base.glstex", "$path$base.glstex"; + } + # Analyze log file. + local *LOG; + $LOG = "$_[0].glg"; + if (!$ret && -e $LOG) { + open LOG, "<$LOG"; + while (<LOG>) { + if (/^Reading (.*\.bib)\s$/) { + rdb_ensure_file( $rule, $1 ); + } + } + close LOG; + } + return $ret; +} + +push @file_not_found, '^Package .* No file `([^\\\']*)\\\''; +push @generated_exts, 'glo', 'gls', 'glg'; +push @generated_exts, 'acn', 'acr', 'alg'; +$clean_ext .= ' %R.ist %R.xdy'; +$clean_ext .= ' bbl run.xml'; + diff --git a/projdoc.cls b/projdoc.cls index c6abaca..503f049 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -14,6 +14,18 @@ \PassOptionsToPackage{nosort}{cleveref} \PassOptionsToPackage{nameinlink}{cleveref} \PassOptionsToPackage{obeyspaces}{url} +\PassOptionsToPackage{toc=false}{glossaries} +\PassOptionsToPackage{record}{glossaries-extra} +\PassOptionsToPackage{ + backend=biber, + bibencoding=utf8, + style=iso-numeric, + % Technically, Avans University of Applied Sciences requires that we always use APA + % style references, but this often results in ugly citations when working with + % technical or online resources. At the end of the day, the bibliography is there + % to prove we didn't plagiarize or make shit up, so ISO 690 is *probably* fine. + autocite=plain, +}{biblatex} % frequently used packages \RequirePackage{geometry} @@ -38,9 +50,13 @@ \RequirePackage{cleveref} \RequirePackage{adjustbox} \RequirePackage{xparse} +\RequirePackage{biblatex} +\RequirePackage{glossaries} +\RequirePackage{glossaries-extra} \RequirePackage{ifdraft} \RequirePackage{enumitem} \RequirePackage{subcaption} +\RequirePackage{multicol} % font style \setmainfont{TeX Gyre Schola} @@ -171,18 +187,14 @@ \makeatother % bibliography -\usepackage[ - backend=biber, - bibencoding=utf8, - style=iso-numeric, - % Technically, Avans University of Applied Sciences requires that we always use APA - % style references, but this often results in ugly citations when working with - % technical or online resources. At the end of the day, the bibliography is there - % to prove we didn't plagiarize or make shit up, so ISO 690 is *probably* fine. - autocite=plain, -]{biblatex} \addbibresource{sources.bib} +% glossary +\GlsXtrLoadResources[ + src={./glossary.bib}, + selection={recorded and deps and see}, +] + % default document header/trailer \makeatletter \def\projdoc@header{ @@ -196,8 +208,16 @@ \newbool{projdoc@cited} \apptocmd{\abx@aux@cite}{\global\booltrue{projdoc@cited}}{}{} \def\projdoc@trailer{ - % end with bibliography (if citations used) + % bibliography (if citations used) \ifbool{projdoc@cited}{\printbibliography}{}% + % glossary + \ifcsundef{printunsrtglossary}{}{% + \section*{Glossary}% + \begin{multicols}{2}% + \renewcommand{\glossarysection}[2][]{}% + \printunsrtglossary% + \end{multicols}% + }% } \AtBeginDocument{\projdoc@header} \AtEndDocument{\projdoc@trailer} diff --git a/research.tex b/research.tex index 691c55a..ca2afed 100644 --- a/research.tex +++ b/research.tex @@ -5,124 +5,203 @@ \begin{document} \tablestables +\newpage + \section{Introduction} + \section{Game engine} - \subsection{Introduction} - To build a game engine, it must first be understood how it operates. - The functionalities it requires and how these functionalities work together must be determined. - In this section, the general functioning of a game engine and the different parts required are described. - \subsection{Findings} - A game engine is not the game itself but a platform with which games are built. It should provide the functionalities with which the game is constructed. - The purpose of a game engine is not to create data out of nothing. Instead, data is read, and the correlating features and effects are generated. - However, the engine is also used to create these files, referred to as "assets." The game engine must be able to accept a certain format of these assets—whether levels, sprites, or textures—and convert them into usable data. - \subsubsection{Layers} - A game engine is composed of multiple layers, each with its own functions. These layers are divided into the following categories: - \begin{itemize} - \item Resource manager: Responsible for what happens when the engine is launched, including loading data formats. - \item Application: Manages the run loop, time, code execution, and events (e.g., input events). - \item Window/HID (Human Interface Devices): Handles input and events. - \item Renderer: Responsible for drawing the necessary objects on the screen, usually once per frame. - \item Debugging support: Provides testing for the engine, such as logging or performance profiling. - \item Scripting layer: Runs scripts, such as Lua or Python. - \item Memory systems: Handles and monitors memory usage. - \item Entity-Component System (ECS): Provides a modular way to create game objects, add physics, and define how the engine interacts with objects. - \item Physics: Adds specific physics to objects. - \item Audio: Processes audio. - \item AI: Provides artificial inteligent behavior. - \end{itemize} - - \subsubsection{ECS} - A game engine must have the ability to keep track and update several game objects. To do this most game engines employ an ECS model which uses modulair components to give entities properties and features. - The need for an entity component system arises because multiple game objects are required to create a scene in a game. These game objects exist within the scene and perform actions, such as a UI display for a score. - This game object does not need to be rendered; it could be a script running in the background. - It could also be a player sprite that is controlled. - These entities need to be aware of other entities, for example, during collisions. - For this to function, a scene is required to host all game objects. - Within this scene, the game objects must be stored efficiently, and entities must be provided with the required behavior, such as audio, position, or physics. - To create diverse entities with specific functions: - A scene can contain many different kinds of entities, each with different properties and functions. - But no matter how different each entity is, it remains an entity. - To assign properties and functions to entities, components are used. - Entt is an example of an ECS. - \subsection{Conclusion} - \section{3rd Party Tools} - \subsection{Introduction} - Developing a game engine from scratch requires a significant amount of time, as many different features are necessary. - Fortunately, some of these features have already been developed and can be reused in the form of frameworks and 3rd party tools/libraries. The decision to use 3rd party libraries, and the selection of which ones to use, directly influences the development process of the game engine. In this section, several 3rd party frameworks and tools available for use are described. - - \subsection{Findings} - \subsubsection{Media Frameworks} - A game engine must have the ability to handle user input, render graphics, and process audio. Several large frameworks are available that provide these features and are already widely used by other game engines. - The two most popular and best-supported options are SDL2 and SFML. - - \emph{SDL2} - - According to its official website, SDL2 (Simple DirectMedia Layer) "is a cross-platform development library designed to provide low-level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. It is used by video playback software, emulators, and popular games, including Valve's award-winning catalog and many Humble Bundle games." - SDL2 is written in the C programming language, and therefore, structs and functions are used instead of objects and methods. - - The advantages of SDL2 are: - \begin{itemize} - \item Controller support is provided. - \item 2D and 3D rendering are supported. - \item Broad multiplatform support is offered, including older consoles such as the Wii. - \item Low-level control is available. - \item A large community ensures wide usage. - \item Extended libraries can be used to add functionalities, such as SDL\_Mixer for sound. - \end{itemize} - - The disadvantages of SDL2 are: - \begin{itemize} - \item A limited built-in 2D renderer is provided. - \item Extended libraries require setup. - \end{itemize} - - \emph{SFML} - - SFML (Simple and Fast Multimedia Library) is a simple framework consisting of five modules: audio, graphics, network, system, and window. This framework, written in C++, was designed to simplify game development. - - The advantages of SFML are: - \begin{itemize} - \item Object-oriented design is provided since it is written in C++. - \item A built-in 2D renderer is available for ease of use. - \item A built-in audio system is included. - \item Cross-platform support is available for Linux, Windows, and macOS. - \item Networking capabilities are provided for multiplayer or networked applications. - \end{itemize} - - The disadvantages of SFML are: - \begin{itemize} - \item The 2D rendering engine may experience performance issues in large-scale games. - \item The community is smaller compared to SDL2. - \item No native 3D support is provided. - \item Not all image formats are supported. - \end{itemize} - \subsubsection{Audio} - for audio some options could be: FMOD, Wwise, or iirKlang - \subsection{Conclusion} + +\subsection{Introduction} + +To build a game engine, it must first be understood how it operates. The +functionalities it requires and how these functionalities work together must be +determined. In this section, the general functioning of a game engine and the +different parts required are described. + +\subsection{Findings} + +A game engine is not the game itself but a platform with which games are built. It +should provide the functionalities with which the game is constructed. The purpose of +a game engine is not to create data out of nothing. Instead, data is read, and the +correlating features and effects are generated. However, the engine is also used to +create these files, referred to as ``assets.'' The game engine must be able to accept +a certain format of these assets---whether levels, sprites, or textures---and convert +them into usable data. + +\subsubsection{Layers} + +A game engine is composed of multiple layers, each with its own functions. These +layers are divided into the following categories:\noparbreak +\begin{description} + \item[Resource manager] Responsible for what happens when the engine is launched, + including loading data formats. + \item[Application] Manages the run loop, time, code execution, and events + (e.g.~input events). + \item[Window/\glspl{hid}] Handles input and events. + \item[Renderer] Responsible for drawing the necessary objects on the screen, + usually once per frame. + \item[Debugging support] Provides testing for the engine, such as logging or + performance profiling. + \item[Scripting layer] Runs scripts, such as Lua or Python. + \item[Memory systems] Handles and monitors memory usage. + \item[\gls{ecs}] Provides a modular way to create game objects, add physics, and + define how the engine interacts with objects. + \item[Physics] Adds specific physics to objects. + \item[Audio] Processes audio. + \item[AI] Provides artificial inteligent behavior. +\end{description} + +\subsubsection{ECS} + +A game engine must have the ability to keep track and update several game objects. To +do this most game engines employ an \gls{ecs} model which uses modulair components to +give entities properties and features. The need for an entity component system arises +because multiple game objects are required to create a scene in a game. These game +objects exist within the scene and perform actions, such as a UI display for a score. +This game object does not need to be rendered; it could be a script running in the +background. It could also be a player sprite that is controlled. These entities need +to be aware of other entities, for example, during collisions. For this to function, +a scene is required to host all game objects. Within this scene, the game objects +must be stored efficiently, and entities must be provided with the required behavior, +such as audio, position, or physics. To create diverse entities with specific +functions: A scene can contain many different kinds of entities, each with different +properties and functions. But no matter how different each entity is, it remains an +entity. To assign properties and functions to entities, components are used. Entt is +an example of an \gls{ecs}. +% TODO: ref?entt + +\subsection{Conclusion} + +\section{Third-party Tools} + +\subsection{Introduction} + +Developing a game engine from scratch requires a significant amount of time, as many +different features are necessary. Fortunately, some of these features have already +been developed and can be reused in the form of frameworks and third-party +tools/libraries. The decision to use third-party libraries, and the selection of +which ones to use, directly influences the development process of the game engine. In +this section, several third-party frameworks and tools available for use are +described. + +\subsection{Findings} + +\subsubsection{Media Frameworks} + +A game engine must have the ability to handle user input, render graphics, and +process audio. Several large frameworks are available that provide these features and +are already widely used by other game engines. The two most popular and +best-supported options are \gls{sdl2} and \gls{sfml}. + +\paragraph{SDL2} + +% TODO: ref?sdl2 +According to its official website, \gls{sdl2} is \emph{``a cross-platform development +library designed to provide low-level access to audio, keyboard, mouse, joystick, and +graphics hardware via \gls{opengl} and \gls{d3d}. It is used by video playback +software, emulators, and popular games, including Valve's award-winning catalog and +many Humble Bundle games.''} \gls{sdl2} is written in the C programming language, and +therefore, structs and functions are used instead of objects and methods. + +The advantages of \gls{sdl2} are:\noparbreak +\begin{itemize} + \item Controller support is provided. + \item 2D and 3D rendering are supported. + \item Broad multiplatform support is offered, including older consoles such as the + Wii. + \item Low-level control is available. + \item A large community ensures wide usage. + \item Extended libraries can be used to add functionalities, such as SDL\_Mixer for + sound. +\end{itemize} + +The disadvantages of \gls{sdl2} are:\noparbreak +\begin{itemize} + \item A limited built-in 2D renderer is provided. + \item Extended libraries require setup. +\end{itemize} + +\paragraph{SFML} + +\gls{sfml} is a simple framework consisting of five modules: audio, graphics, +network, system, and window. This framework, written in C++, was designed to simplify +game development. + +The advantages of \gls{sfml} are: +\begin{itemize} + \item Object-oriented design is provided since it is written in C++. + \item A built-in 2D renderer is available for ease of use. + \item A built-in audio system is included. + \item Cross-platform support is available for Linux, Windows, and macOS. + \item Networking capabilities are provided for multiplayer or networked + applications. +\end{itemize} + +The disadvantages of \gls{sfml} are: +\begin{itemize} + \item The 2D rendering engine may experience performance issues in large-scale + games. + \item The community is smaller compared to \gls{sdl2}. + \item No native 3D support is provided. + \item Not all image formats are supported. +\end{itemize} + +\subsubsection{Audio} + +for audio some options could be: FMOD, Wwise, or iirKlang + +\subsection{Conclusion} + \section{Gameloop/resource manager} - \subsection{Introduction} - \subsection{Findings} - \subsection{Conclusion} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + \section{Rendering} - \subsection{Introduction} - \subsection{Findings} - \subsection{Conclusion} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + \section{Event manager} - \subsection{Introduction} - \subsection{Findings} - \subsection{Conclusion} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + \section{Memory/debugging} - \subsection{Introduction} - \subsection{Findings} - \subsection{Conclusion} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + \section{Physics/scripting} - \subsection{Introduction} - \subsection{Findings} - \subsection{Conclusion} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + \section{Conclusion} + \section{Gameobjects/components} - \subsection{Introduction} - \subsection{Findings} - \subsection{Conclusion} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + \section{Conclusion} + \end{document} |