diff options
Diffstat (limited to 'design.tex')
| -rw-r--r-- | design.tex | 217 |
1 files changed, 208 insertions, 9 deletions
@@ -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). @@ -137,9 +137,8 @@ reliability. \subsection{Texture} -% FIXME: our -The textures in our game engine are represented by the \codeinline{Texture} class. It -is implemented a \gls{facade} around the \gls{sdl} library. +The textures in cr\^epe game engine are represented by the \codeinline{Texture} +class. It is implemented as an \gls{facade} around the \gls{sdl} library. \subsubsection{Architecture} @@ -219,8 +218,7 @@ following classes:\noparbreak screen. \end{description} \item The \codeinline{SdlContext} class, another singleton, manages the \gls{sdl} - and has a friendship relationship with \codeinline{ComponentManager} for tighter - integration with component management. + library \item Components are organized as follows:\noparbreak \begin{itemize} \item The \codeinline{Component} base class allows for generic handling of @@ -286,9 +284,21 @@ and the current frame, is used to measure the duration of each frame. This value converted into a time-based unit, enabling systems to create frame rate-independent behavior. +The fixed update has a specific order to update seperate systems as seen in +\cref{fig:fixed-update}. 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 on a per-frame basis. A delay, combined with delta time calculation, ensures consistent visuals even at varying frame rates. -\Cref{gameloop-class} shows a \codeinline{TimerClass} using a singleton design +\Cref{fig:gameloop-class} shows a \codeinline{TimerClass} using a singleton design pattern, allowing access to \codeinline{deltaTime} throughout the system. The game loop updates the timing and delta time in this class to keep it accurate. @@ -318,6 +328,13 @@ frame 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} @@ -418,9 +435,135 @@ using the callback(eventHandler) is executed. \label{fig:event-seq} \end{figure} -% \subsection{Physics} +\subsection{Physics} -\subsection{Rendering} +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 +\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 a factor of 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{Scripting} @@ -911,6 +1054,62 @@ 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.09\,ms and with pooling 0.009\,ms. +Decreasing calculation times of physics is important because everything needs to eb +calculated in 16.6\,ms (60\,hz). + +\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% |