path: root/research.tex

\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}
This part of the research explains the use of physics in a game engine. Furthermore, it examines the ease of using a physics engine compared to implementing physics from scratch. Ultimately, a recommendation will be provided on whether using a physics engine is more feasible than a custom implementation.

\subsection{Physics Core Concepts}

\subsubsection{Kinematics}

\subsubsection{Dynamics}


Physics Core Concepts

https://bluebirdinternational.com/game-physics/#:~:text=Game%20physics%20is%20implemented%20using,solid%20and%20deformable%20objects%2C%20respectively.

rigid body
A chunk of matter that is so strong that the distance between any two bits of matter on the chunk is constant.

shape
A shape binds collision geometry to a body and adds material properties such as density, friction, and restitution.

constraint
A constraint is a physical connection that removes degrees of freedom from bodies. A 2D body has 3 degrees of freedom (two translation coordinates and one rotation coordinate). If I take a body and pin it to the wall (like a pendulum) I have constrained the body to the wall. At this point the body can only rotate about the pin, so the constraint has removed 2 degrees of freedom.

contact constraint
A special constraint designed to prevent penetration of rigid bodies and to simulate friction and restitution. You do not create contact constraints; they are created automatically by Box2D.

joint constraint
This is a constraint used to hold two or more bodies together. Box2D supports several joint types: revolute, prismatic, distance, and more. Joints may have limits, motors, and/or springs.

joint limit
A joint limit restricts the range of motion of a joint. For example, the human elbow only allows a certain range of angles.

joint motor
A joint motor drives the motion of the connected bodies according to the joint's degrees of freedom. For example, you can use a motor to drive the rotation of an elbow. Motors have a target speed and a maximum force or torque. The simulation will apply the force or torque required to achieve the desired speed.

joint spring
A joint spring has a stiffness and damping. In Box2D spring stiffness is expressed in terms or Hertz or cycles per second. This lets you configure how quickly a spring reacts regardless of the body masses. Joint springs also have a damping ratio to let you specify how quickly the spring will come to rest.

world
A physics world is a collection of bodies, shapes, joints, and contacts that interact together. Box2D supports the creation of multiple worlds which are completely independent.

solver
The physics world has a solver that is used to advance time and to resolve contact and joint constraints. The Box2D solver is a high performance sequential solver that operates in order N time, where N is the number of constraints.

continuous collision
The solver advances bodies in time using discrete time steps. Without intervention this can lead to tunneling.

Box2D contains specialized algorithms to deal with tunneling. First, the collision algorithms can interpolate the motion of two bodies to find the first time of impact (TOI). Second, speculative collision is used to create contact constraints between bodies before they touch.

events
World simulation leads to the creation of events that are available at the end of the time step:

body movement events
contact begin and end events
contact hit events
These events allow your application to react to changes in the simulation.



Box2D

Description: One of the most popular and widely used open-source 2D physics engines, Box2D is known for its simplicity, robustness, and efficiency. It powers many games across different platforms.

Key Features:
Collision detection and response.
Rigid body dynamics, including joints, springs, and constraints.
Support for convex polygons and circles.
Highly customizable, allowing fine control over physics simulation parameters.

Use Cases: Suitable for platformers, puzzles, and any game requiring realistic 2D physics.

License: MIT License.
https://box2d.org/


2. LiquidFun
Description: A fork of Box2D, LiquidFun adds particle-based fluid simulation to Box2D's rigid body dynamics. It's ideal for games that require both solid and fluid dynamics.
Key Features:
All features of Box2D.
Particle system for simulating fluids, soft bodies, and other deformable materials.
High performance with SIMD optimization.
Use Cases: Games requiring fluid simulations, like water physics or granular materials.
License: Apache License 2.0.
3. Chipmunk2D
Description: A lightweight and fast 2D physics engine that emphasizes ease of use and flexibility. Chipmunk2D is designed to be simple enough to understand and integrate but powerful enough for complex simulations.
Key Features:
Collision detection, including circle, segment, and polygon shapes.
Supports constraints, motors, and damped springs.
Built-in support for sleeping objects to optimize performance.
Written in C, but it has bindings for C++.
Use Cases: Ideal for developers who need a simple yet performant physics engine.
License: MIT License.
4. Nape
Description: A 2D physics engine that is optimized for use with the Haxe programming language but has a C++ backend. It focuses on ease of use, with a clean API and features tailored for 2D games.
Key Features:
Provides both rigid body and soft body physics.
Broad-phase and narrow-phase collision detection.
Constraints, forces, and motor simulations.
Integrates well with cross-platform tools that generate C++ code, like Haxe.
Use Cases: Suitable for developers using Haxe or projects that require an easy-to-use API.
License: MIT License.

liquidfun (fork of box2d)
https://google.github.io/liquidfun/

Chipmunk2D
https://chipmunk-physics.net/


\subsection{Findings}

\subsection{Conclusion}

\section{Conclusion}

\section{Gameobjects/components}

\subsection{Introduction}

\subsection{Findings}

\subsection{Conclusion}

\section{Conclusion}

\end{document}