diff options
author | Jaro <jarorutjes07@gmail.com> | 2024-09-10 13:04:19 +0200 |
---|---|---|
committer | Jaro <jarorutjes07@gmail.com> | 2024-09-10 13:04:19 +0200 |
commit | 45e358297d7eb7d5d699e3cbd056ff7d1b8b906a (patch) | |
tree | 7acebb47ab36ffe4dfba0a2c367942ea355b6ea3 /research.tex | |
parent | a5254f3fb3962af81f39fd51911cdbf639b30aca (diff) | |
parent | e34bef0a738c710e8c09894f6d9bc66abda4d3b2 (diff) |
updated time
Diffstat (limited to 'research.tex')
-rw-r--r-- | research.tex | 207 |
1 files changed, 207 insertions, 0 deletions
diff --git a/research.tex b/research.tex new file mode 100644 index 0000000..ca2afed --- /dev/null +++ b/research.tex @@ -0,0 +1,207 @@ +\documentclass{projdoc} +\input{meta.tex} + +\title{Research document} + +\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:\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} + +\section{Rendering} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + +\section{Event manager} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + +\section{Memory/debugging} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + +\section{Physics/scripting} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + +\section{Conclusion} + +\section{Gameobjects/components} + +\subsection{Introduction} + +\subsection{Findings} + +\subsection{Conclusion} + +\section{Conclusion} + +\end{document} |