diff options
Diffstat (limited to 'design.tex')
| -rw-r--r-- | design.tex | 187 |
1 files changed, 96 insertions, 91 deletions
@@ -116,7 +116,8 @@ the main part of the \gls{ecs}. The design of these eight systems in combination \gls{ecs}, will be briefly discussed in the next parts of this design document. \section{Design} - +%TODO: lag uitleggen uit diagram +%TODO: process input \subsection{Game Loop} \subsubsection{Problem statement} @@ -134,7 +135,91 @@ The game loop can be external where the user has the ability to update the syste themselves or an intergrated game loop which is managed by the gameloop. Both of these approaches have advantages and disadvantages when it comes to flexibility and reliability. +\subsubsection{Architecture} + +This engine uses an integrated game loop for the following reasons:\noparbreak +\begin{description} + \item[Simplifies development] The user only needs to call \codeinline{startGame()}. + \item[Ensures uniform system calls] Systems are always updated in the same order, + reducing the likelihood of overwrites and undefined system behavior. + \item[Provides a reliable timer update] The game loop timer is updated with each + cycle, minimizing timing issues. +\end{description} + +As seen in \cref{fig:gameloop-flow}, the game loop consists of multiple +steps:\noparbreak +\begin{description} + \item[Update loop timer] The loop timer is updated, and the expected frame time is + calculated. + \item[Check events] Queued events are dispatched, and callback functions are + executed accordingly. + \item[Process input] The input system is called, and user inputs are processed. + \item[Fixed update] A fixed loop for timing-sensitive systems, such as physics. + \item[Update] A per-frame update for all necessary frame-dependent changes. + \item[Render] The render system is called to display the current frame. +\end{description} + +The game loop continues to call the fixed update function as long as there is +sufficient time. Delta time, calculated as the time between the last frame’s start +and the current frame, is used to measure the duration of each frame. This value is +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{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. + +The two main functions of the game loop are \codeinline{setup()} and +\codeinline{loop()}. \codeinline{setup()} handles all startup procedures and is +called only once when the game begins. The \codeinline{loop()} function repeats as +long as the game is running. + +The code example below shows how to start the game engine/game:\noparbreak +\begin{blockcode} +Gameloop loop; +loop.start(); +\end{blockcode} + +% FIXME: not a technical reference +This code calls both \codeinline{setup()} and \codeinline{loop()}, starting the game +loop timer. The current frame’s delta time can be accessed using +\codeinline{LoopTimer::getInstance().getDeltaTime()}, which returns the expected +frame time. + +\begin{figure} + \centering + \includepumldiag{img/gameloop-flow.puml} + \caption{Game loop flowchart diagram} + \label{fig:gameloop-flow} +\end{figure} + +\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} +\end{figure} \subsection{Texture} The textures in cr\^epe game engine are represented by the \codeinline{Texture} @@ -161,7 +246,8 @@ contains the following classes:\noparbreak \caption{User texture class diagram} \label{fig:class-texture} \end{figure} - +%TODO: lijntjes verbeteren in de diagrammen +%TODO: verwijzen naar assets \subsection{AssetManager} The AssetManager is a \gls{api} class that the user can use to make a @@ -185,7 +271,10 @@ the following classes:\noparbreak \caption{User AssetManager class diagram} \label{fig:class-assetmanager} \end{figure} - +%TODO geen 2 actien +%TODO: is er geen transform mag wel +%TODO: nog kijken wel of geen spirte keuze in het diagram +%TODO: in het diagram kijken of er een particle emiter \subsection{Rendering} Every game engine has an rendering structure to present all the different enities and @@ -193,7 +282,7 @@ components on the screen. \subsubsection{Architecture} -% TODO: anyone read this? +% TODO: anyone read this?, fix disgram lines, add particle emitter and camera and reference other classes better \Cref{fig:class-rendering} shows a class diagram of the RenderSystem. It contains the following classes:\noparbreak \begin{itemize} @@ -254,92 +343,8 @@ following classes:\noparbreak \label{fig:class-renderingflowchart} \end{figure} -\subsubsection{Architecture} - -This engine uses an integrated game loop for the following reasons:\noparbreak -\begin{description} - \item[Simplifies development] The user only needs to call \codeinline{startGame()}. - \item[Ensures uniform system calls] Systems are always updated in the same order, - reducing the likelihood of overwrites and undefined system behavior. - \item[Provides a reliable timer update] The game loop timer is updated with each - cycle, minimizing timing issues. -\end{description} - -As seen in \cref{fig:gameloop-flow}, the game loop consists of multiple -steps:\noparbreak -\begin{description} - \item[Update loop timer] The loop timer is updated, and the expected frame time is - calculated. - \item[Check events] Queued events are dispatched, and callback functions are - executed accordingly. - \item[Process input] The input system is called, and user inputs are processed. - \item[Fixed update] A fixed loop for timing-sensitive systems, such as physics. - \item[Update] A per-frame update for all necessary frame-dependent changes. - \item[Render] The render system is called to display the current frame. -\end{description} - -The game loop continues to call the fixed update function as long as there is -sufficient time. Delta time, calculated as the time between the last frame’s start -and the current frame, is used to measure the duration of each frame. This value is -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{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. - -The two main functions of the game loop are \codeinline{setup()} and -\codeinline{loop()}. \codeinline{setup()} handles all startup procedures and is -called only once when the game begins. The \codeinline{loop()} function repeats as -long as the game is running. - -The code example below shows how to start the game engine/game:\noparbreak -\begin{blockcode} -Gameloop loop; -loop.start(); -\end{blockcode} - -% FIXME: not a technical reference -This code calls both \codeinline{setup()} and \codeinline{loop()}, starting the game -loop timer. The current frame’s delta time can be accessed using -\codeinline{LoopTimer::getInstance().getDeltaTime()}, which returns the expected -frame time. - -\begin{figure} - \centering - \includepumldiag{img/gameloop-flow.puml} - \caption{Game loop flowchart diagram} - \label{fig:gameloop-flow} -\end{figure} - -\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} -\end{figure} +%TODO: blokken voor callback in sequence \subsection{Event system} \subsubsection{Problem Statement} @@ -475,7 +480,7 @@ the velocities. after this update it will move all objects. This is shown in the \caption{Physics system flowchart} \label{fig:physics-system-flowchart} \end{figure} - +%TODO: andere lijn in het diagram \subsection{Collisions} The Collisions in the game engine are handled by the \emph{CollisionSystem}. This @@ -521,7 +526,7 @@ changing the design. The same is for child and parent gameobjects. \caption{Collision system flowchart} \label{fig:collision-system-flowchart} \end{figure} - +%TODO: diagram particle \subsection{Particles} The Particles in the game engine are handled by the \emph{ParticlesSystem}. This |