aboutsummaryrefslogtreecommitdiff
path: root/design.tex
diff options
context:
space:
mode:
authorjaroWMR <jarorutjes07@gmail.com>2024-11-03 13:55:00 +0100
committerjaroWMR <jarorutjes07@gmail.com>2024-11-03 13:55:00 +0100
commitb81399f199d7a1c2107813e2cb8865691e25c933 (patch)
tree6a601496967cf4ac73065dbaed18126a6803e37f /design.tex
parent561b9b8e5c2d377c17fa56121f1ed7c460a2d680 (diff)
Physics,Collison and particle systems added
Diffstat (limited to 'design.tex')
-rw-r--r--design.tex147
1 files changed, 143 insertions, 4 deletions
diff --git a/design.tex b/design.tex
index a208cd3..c899f5d 100644
--- a/design.tex
+++ b/design.tex
@@ -66,7 +66,7 @@ side-scrolling endless runner action video game created by Halfbrick Studios. Th
protagonist is called Barry Steakfries, who the player controls as he steals a
bullet-powered jet pack from a top-secret laboratory
\autocite{wikipedia:jetpack-joyride}. A screenshot from the game can be seen in
-\cref{fig:jetpack-joyride} (pleae be aware that the goal of this project is not to
+\cref{fig:jetpack-joyride} (please be aware that the goal of this project is not to
create an exact replica of Jetpack Joyride, it is only used as a source of
inspiration).
@@ -284,12 +284,16 @@ steps:\noparbreak
\end{description}
This is done as illustrated in \cref{fig:gameloop-flow}, the game loop continues to call
-the fixed update function as long as sufficient time is available. Delta time,
+the fixed update \cref{fig:fixed-update} function as long as sufficient time is available. Delta time,
calculated using the time between the start of the last frame and the current frame,
is used to measure the duration of each frame. This value is converted into a
time-based unit, enabling other systems or game developers to create behavior
independent of frame rate.
+The fixed update has a specific order to update seperate systems. The scripts update is called first so a gamedevelop can use the onupdate() in a script to move objects. after this movement the PhysicsSystem will move objects as well. after all movement is done the collision system will use the velocity and the current position to determine if something collided. Then the collisions system will call all collision handelers. After all collisions are handeled the particle system will update.
+
+This order can not be changed because the systems work in a specific way. Collisions looks back in the past and the emitter can be moved so the particle update must be the last in the fixed update.
+
Rendering and animations are handled separately on a per-frame basis. A delay, in
conjunction with the delta time calculation, is applied to maintain consistent visual
behavior, even when frame rates vary. As seen in \cref{fig:gameloop-class} to access the
@@ -320,6 +324,13 @@ time.
\begin{figure}
\centering
+ \fitimg{\includegraphics[scale=0.7]{img/Fixed_update.png}}
+ \caption{Fixed update}
+ \label{fig:fixed-update}
+\end{figure}
+
+\begin{figure}
+ \centering
\includepumldiag{img/gameloop-class.puml}
\caption{Gameloop Flowchart Diagram}
\label{fig:gameloop-class}
@@ -413,9 +424,99 @@ using the callback(eventHandler) is executed.
\label{fig:event-seq}
\end{figure}
-% \subsection{Physics}
+\subsection{Physics}
+
+The Physics in the game engine are handled by the \emph{PhysicsSystem}. The physics calculate the velocity and moves each component with a Rigidbody. This game engine does not use any third party tools for calculating physics.
+
+
+\subsubsection{Architecture}
+The \emph{PhysicsSystem} is a system and therefor a singleton in this engine. Besides the \codeinline{getinstance()} and \codeinline{update()} function it does not include more functions. The \emph{PhysicsSystem} uses a couple components:\noparbreak
+\begin {description}
+ \item[Transform] The \emph{PhysicsSystem} is the only system to change the values in the transform. A user is able to change these values through a script.
+ \item[Rigidbody] The \emph{PhysicsSystem} uses this to know what the next velocity should be and if it can move. What the physics system includes is shown in \cref{fig:physics-system}
+\end{description}
+
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/Physics_system.png}}
+ \caption{Physics system}
+ \label{fig:physics-system}
+\end{figure}
+
+\subsubsection{Design}
+The physics system is not a complex system. It works in three steps. It will request all physicsbodies. If there are no physicsbodies linked to a gameobject than that object does not have physics. It will read the values within the rigidbody and update the velocities. after this update it will move all objects. This is shown in the \cref{fig:physics-system-flowchart}.
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/Physics_system_flowchart.png}}
+ \caption{Physics system flowchart}
+ \label{fig:physics-system-flowchart}
+\end{figure}
+
+\subsection{Collisions}
+
+The Collisions in the game engine are handled by the \emph{CollisionSystem}. This system check if a collider collided with another collider.
+
+\subsubsection{Architecture}
+The \emph{CollisionSystem} is a system and therefor a singleton in this engine. Besides the \codeinline{getinstance()} and \codeinline{update()} function it does not include more functions. The \emph{CollisionSystem} uses a couple components:\noparbreak
+\begin {description}
+ \item[Transform] The \emph{CollisionSystem} Read the location and rotation value to know where all colliders are located.
+ \item[Rigidbody] The \emph{CollisionSystem} uses this to know if collision needs to be check, how collisions should be checked and how they are handled.
+ \item[BoxCollider] The box collider is a square with a width and height used to check for collisions.
+ \item[CircleCollider] The circle collider is a circle with a radius used to check for collisions.
+\end{description}
+This is shown in \cref{fig:collision-system}.
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/Collision_system.png}}
+ \caption{Collision system}
+ \label{fig:collision-system}
+\end{figure}
+
+\subsubsection{Design}
+The collision system is complex compared to other systems. This is shown in the \cref{fig:collision-system-flowchart}. Because multiple colliders of different types can be added to one gameobject this system is complex. For this game it is not needed to check for more than one collider per gameobject but this functionality is added to the design. If the engine needs to be able to do this it can be added without changing the design. The same is for child and parent gameobjects.
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/Collision_system_flowchart.png}}
+ \caption{Collision system flowchart}
+ \label{fig:collision-system-flowchart}
+\end{figure}
+
+
+
+\subsection{Particles}
+
+The Particles in the game engine are handled by the \emph{ParticlesSystem}. This system uses particleEmitters to create and move particles.
+
+\subsubsection{Architecture}
+The \emph{ParticlesSystem} is a system and therefor a singleton in this engine. Besides the \codeinline{getinstance()} and \codeinline{update()} function it does not include more functions. The \emph{ParticlesSystem} uses a couple components:\noparbreak
+\begin {description}
+ \item[Transform] The \emph{ParticlesSystem} Read the location and rotation value to know where the emitter is located
+ \item[ParticleEmitter] The \emph{ParticlesSystem} uses the particle emitter to know what the values and configuration of the emitter are.
+ \item[Particle] info for each particle.
+\end{description}
+This is shown in \cref{fig:particle-system}.
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/Particle_system.png}}
+ \caption{Particle system}
+ \label{fig:particle-system}
+\end{figure}
+
+\subsubsection{Design}
+The particle system is a bit strange because it uses a component which has objects (particles). How this system works is shown in the \cref{fig:Particle-system-flowchart}. Because each particle needs to be create pooling is used to increase efficientcy in the calulcation time of all the particles. Pooling decreases the calculation time by /10.
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/Particle_system_flowchart.png}}
+ \caption{Particle system flowchart}
+ \label{fig:Particle-system-flowchart}
+\end{figure}
-\subsection{Rendering}
\subsection{Scripting}
@@ -767,6 +868,44 @@ transformations are applied each frame, as demonstrated by the output in
\label{fig:poc-output-camera}
\end{figure}
+
+\subsection{Particles}
+\label{poc:particle}
+
+The particles \gls{poc} \autocite[particles example]{crepe:code-repo} consists of the one particle emitter that is shown in \cref{fig:poc-particles}.This particle emmitter is controlled by the particle system using ECS. I can generate particles in a specified direction and velocity. With min and max values the system will determine what the exact value of eacht particle will be.
+
+This \gls{poc} showed that pooling is a must, even with lower amounts of particles. The calculation time of 100 particles was about 0.09ms and with pooling 0.009ms. Decreasing calculation times of physics is important because everything needs to eb calculated in 16.6 ms (60hz).
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/poc-particles.png}}
+ \caption{Particles \glsfmtshort{poc} output}
+ \label{fig:poc-particles}
+\end{figure}
+
+\subsection{Collision}
+\label{poc:collision}
+
+The collision \gls{poc} \autocite[collision example]{crepe:code-repo} uses a couple of systems. It uses ECS, Physics system, Collisions system and Render system. It uses a lot of components like a gamedeveloper would use. This poc shows that multiple systems can work together and shows physics described by the gamedeveloper.
+
+This \gls{poc} shows two boxes with some distance from each other \cref{fig:poc-no-collision}, and collide \cref{fig:poc-collision}. The red box is static and can not be moved be physics even if it has gravity. The green box is dynamic and is moved by gravity. These movements are done to add the velocity to the transform. the velocity is calculated by the physics and saved in the rigidbody. before moving the collision system checks if there is collison, so it looks at the future. if the green box wants to move through the red box it is pushed back by the collision handler because the green box is static.
+
+This \gls{poc} showed that it is better to do the opposite. Move all object then look back if the collided with anything..
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/poc-collision-1.png}}
+ \caption{No collision \glsfmtshort{poc} output}
+ \label{fig:poc-no-collision}
+\end{figure}
+
+\begin{figure}
+ \centering
+ \fitimg{\includegraphics[scale=0.7]{img/poc-collision-2.png}}
+ \caption{Collision \glsfmtshort{poc} output}
+ \label{fig:poc-collision}
+\end{figure}
+
\makeatletter%
\newbox\full@class@diag%
\newlength\full@class@diag@width%