1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
\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}
One of the requirements of our customer, is that the game engine's structure is similar to Unity. The customer has created a class diagram of the game engine's API, which is (of course) very similar to Unity. One of the most important parts of the class diagram is a so-called gameObject (with several components). It's needed to understand the exact meaning/function of these gameObjects, that's why this research question arose.
\subsection{Findings}
A gameObject itself does/is nothing.
\subsection{Conclusion}
\section{Conclusion}
\end{document}
|