diff options
Diffstat (limited to 'design.tex')
| -rw-r--r-- | design.tex | 58 |
1 files changed, 50 insertions, 8 deletions
@@ -114,8 +114,50 @@ 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} +\subsection{Game Loop} +\subsubsection{Problem statement:} +The game loop is integrated into the engine to simplify development and minimize timing issues. By embedding the game loop within the engine, uniform execution of engine systems is ensured. +Two separate update functions are employed: a fixed-time update with a consistent time delay per call is used for game logic and physics, ensuring predictable behavior regardless of fluctuations in frame rates. +This approach decouples physics calculations from the frame rate, allowing consistent behavior across different hardware configurations. +\subsubsection{Design:} +As illustrated in Figure \ref{gameloop-flow}, the game loop continues to call the 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. + +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. This separation of game logic from rendering ensures that both simulation accuracy and visual fluidity are optimized. +As seen in figure Figure \ref{gameloop-class} to access the deltaTime anywhere in the system a timerClass is created using a singleton desing pattern which ensures only one instance of the class is created; the gameloop updates the timing and delta time of this class to ensure it is accurate. +The gameloops two main functions are the setup() and loop(). The first is called when the game starts and handles all startup procedures this function only runs once. +The loop() function keeps looping as long as the game is running. Within this function are the functions: processInputs for handling user input(mouse,keyboard,other controllers),fixed update,frame update and render function. +\begin{figure} + \centering + \includepumldiag{img/gameloop-flow.puml} + \caption{Gameloop Flowchart Diagram} \label{gameloop-flow} +\end{figure} + +\begin{figure} + \centering + \includepumldiag{img/gameloop-class.puml} + \caption{Gameloop Flowchart Diagram} \label{gameloop-class} +\end{figure} +\subsection{Event system} +\subsubsection{Problem statement:} +\subsubsection{Problem Statement:} +The game engine utilizes the Entity-Component-System (ECS) architecture, where components store data, and systems process that data to apply changes. Each system is responsible for managing a specific domain, such as physics in the physics system and rendering in the rendering system. To facilitate communication between systems without introducing direct dependencies, a method of inter-system communication is required to maintain loose coupling. + +Additionally, a mechanism that allows one object's trigger to elicit responses from multiple other objects is beneficial for game developers, providing greater flexibility in designing interactions within the game. + +\subsubsection{Design:} +The solution to the aforementioned problems is an event system that facilitates communication between systems and utilizes BehaviorScripts to handle various types of events. The event system includes several pre-defined events, all derived from a parent Event class, capable of handling user input and application-level events, such as window resizing. -% \subsection{Rendering} +Furthermore, a specific event is designated for the collision handler within the physics system, which can be triggered when two objects collide. The event system also allows developers to create custom events, such as "onPlayerDeath," and assign callback functions that execute when the event is triggered. + +When such an event occurs, the EventManager calls the assigned callback function, executing the associated code to handle the event's consequences +\begin{figure} + \centering + \includegraphics[width=\linewidth]{img/event-uml.drawio.png} % or specify a custom width + \caption{event system class diagram} + \label{fig:event-uml} +\end{figure} +\subsection{Rendering} % \subsection{Physics} @@ -297,36 +339,36 @@ contains the following classes: A \gls{poc} for the final Audio \gls{facade} is also showcased in \cref{poc:audio}. % \subsection{Save manager} -% +% % The save manager \gls{api} is designed to give the game programmer an easy to use % interface for retrieving and storing game-specific data (\cref{req:savemgr}). -% +% % Because the engine validation app only stores statistics and highscores, the save % manager is not required to support loading different save files % (\cref{req:savemgr:multi-file}), nor storing complicated data types % (\cref{req:savemgr:types-custom}). The save manager only supports storing simple % types (\cref{req:savemgr:types-scalar,req:savemgr:types-string}). -% +% % In order to reduce complexity for the game programmer further, the following % requirements were also set:\noparbreak -% +% % \begin{itemize} % \item Prevent data loss in the case of crashes (\cref{req:savemgr:journalling}) % \item Handle opening/closing/flushing of the underlying file automatically % (\cref{req:savemgr:file-manage}) % \item Save file variables are uniquely identified (\cref{req:savemgr:var-key}) % \end{itemize} -% +% % \subsubsection{Architecture} % \label{sec:savemgr:architecture} -% +% % \begin{figure} % \centering % \includepumldiag{img/class-savemgr.puml} % \caption{Save manager class diagram} % \label{fig:class-savemgr} % \end{figure} -% +% % In order to realize \cref{req:savemgr:journalling,req:savemgr:var-key}, a third-party % key-value database library is used. |