From c1c0df012141d1d9c8646e803238e5ea535ae9ce Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Fri, 4 Oct 2024 10:32:28 +0200 Subject: added gameloop subsection and intro --- design.tex | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/design.tex b/design.tex index 1e42c03..f786f40 100644 --- a/design.tex +++ b/design.tex @@ -25,6 +25,17 @@ workflows. \section{Overview} \subsection{Core} +\subsubsection{Game Loop} +Problem Statement\ + +In the context of game development, a robust game loop is essential for maintaining consistent gameplay and ensuring that game logic, physics, and rendering are executed in a synchronized manner. Without a well-defined game loop, issues such as inconsistent frame rates, unresponsive input handling, and unpredictable behavior can arise, leading to a poor user experience. Therefore, the implementation of a game loop within a game engine is crucial for providing a stable foundation upon which game developers can build their projects. +Game Loop Design\ + +The game loop is integrated directly into the engine to streamline development and minimize timing issues for game developers. Two separate update functions are employed. A fixed-time update is used with a consistent time delay per update call for game logic and physics, ensuring predictable behavior regardless of fluctuations in frame rates. By performing physics calculations at regular intervals, game logic and physics are decoupled from frame rate, ensuring consistent behavior across different hardware. + +Rendering and animations are handled separately on a per-frame basis. +A delay and delta time calculation are applied to create consitent visual behavior, even when frame rates vary. +This separation between game logic and rendering ensures that both simulation accuracy and visual fluidity are optimized. \subsection{Patterns} -- cgit v1.2.3 From da846dea2906ae2395ebc6351cae1ca8f8d3313b Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Wed, 23 Oct 2024 21:17:26 +0200 Subject: made changes to introduction gameloop --- design.tex | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/design.tex b/design.tex index 587174f..4642f0c 100644 --- a/design.tex +++ b/design.tex @@ -28,10 +28,15 @@ workflows. \subsubsection{Game Loop} Problem Statement\ -In the context of game development, a robust game loop is essential for maintaining consistent gameplay and ensuring that game logic, physics, and rendering are executed in a synchronized manner. Without a well-defined game loop, issues such as inconsistent frame rates, unresponsive input handling, and unpredictable behavior can arise, leading to a poor user experience. Therefore, the implementation of a game loop within a game engine is crucial for providing a stable foundation upon which game developers can build their projects. +In the context of game development, a robust game loop is essential for maintaining consistent gameplay and ensuring that game logic, physics, and rendering are executed in a synchronized manner. +Without a well-defined game loop, issues such as inconsistent frame rates, unresponsive input handling, and unpredictable behavior can arise, leading to a poor user experience. +Therefore, the implementation of a game loop within a game engine is crucial for providing a stable foundation upon which game developers can build their projects./ + Game Loop Design\ -The game loop is integrated directly into the engine to streamline development and minimize timing issues for game developers. Two separate update functions are employed. A fixed-time update is used with a consistent time delay per update call for game logic and physics, ensuring predictable behavior regardless of fluctuations in frame rates. By performing physics calculations at regular intervals, game logic and physics are decoupled from frame rate, ensuring consistent behavior across different hardware. +The game loop is integrated directly into the engine to streamline development and minimize timing issues for game developers. +Two separate update functions are employed. A fixed-time update is used with a consistent time delay per update call for game logic and physics, ensuring predictable behavior regardless of fluctuations in frame rates. +By performing physics calculations at regular intervals, game logic and physics are decoupled from frame rate, ensuring consistent behavior across different hardware. Rendering and animations are handled separately on a per-frame basis. A delay and delta time calculation are applied to create consitent visual behavior, even when frame rates vary. -- cgit v1.2.3 From cf7a38d87164a9be78efd8c045acd43422a1be04 Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Sat, 26 Oct 2024 08:51:31 +0200 Subject: design gameloop, design --- design.tex | 55 +++++++++++++++++++++++++++++++++++------------ img/event-uml.drawio.png | Bin 0 -> 217362 bytes img/gameloop-class.puml | 35 ++++++++++++++++++++++++++++++ img/gameloop-flow.puml | 27 +++++++++++++++++++++++ 4 files changed, 103 insertions(+), 14 deletions(-) create mode 100644 img/event-uml.drawio.png create mode 100644 img/gameloop-class.puml create mode 100644 img/gameloop-flow.puml diff --git a/design.tex b/design.tex index 0457d8b..6b936a1 100644 --- a/design.tex +++ b/design.tex @@ -25,27 +25,53 @@ workflows. \section{Overview} \subsection{Core} -\subsubsection{Game Loop} -Problem Statement\ -In the context of game development, a robust game loop is essential for maintaining consistent gameplay and ensuring that game logic, physics, and rendering are executed in a synchronized manner. -Without a well-defined game loop, issues such as inconsistent frame rates, unresponsive input handling, and unpredictable behavior can arise, leading to a poor user experience. -Therefore, the implementation of a game loop within a game engine is crucial for providing a stable foundation upon which game developers can build their projects./ +\subsection{Patterns} -Game Loop Design\ +\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} -The game loop is integrated directly into the engine to streamline development and minimize timing issues for game developers. -Two separate update functions are employed. A fixed-time update is used with a consistent time delay per update call for game logic and physics, ensuring predictable behavior regardless of fluctuations in frame rates. -By performing physics calculations at regular intervals, game logic and physics are decoupled from frame rate, ensuring consistent behavior across different hardware. +\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. -Rendering and animations are handled separately on a per-frame basis. -A delay and delta time calculation are applied to create consitent visual behavior, even when frame rates vary. -This separation between game logic and rendering ensures that both simulation accuracy and visual fluidity are optimized. +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. -\subsection{Patterns} +\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. -\section{Design} +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} @@ -204,6 +230,7 @@ contains the following classes: \subsection{Physics} + \section{Tools} \section{Conclusion} diff --git a/img/event-uml.drawio.png b/img/event-uml.drawio.png new file mode 100644 index 0000000..9eab458 Binary files /dev/null and b/img/event-uml.drawio.png differ diff --git a/img/gameloop-class.puml b/img/gameloop-class.puml new file mode 100644 index 0000000..c9d7917 --- /dev/null +++ b/img/gameloop-class.puml @@ -0,0 +1,35 @@ +@startuml +class LoopManager { + +static LoopManager& getInstance() + + +void loop() + +void setup() + -void render() + -void processInput() + -void fixedUpdate() + -void update() + -bool gameRunning + -LoopManager() +} + +class LoopTimer { + +static LoopTimer& getInstance() + +void start() + +void update() + +float getLag() + +float getFixedDeltaTime() + +void advanceFixedUpdate() + +void enforceFrameRate() + +float getDeltaTime() + -float lag + -float fixedDeltaTime + -float deltaTime +} + +LoopManager --> LoopTimer : uses +LoopManager : loop() +LoopManager : |-- processInput() +LoopManager : |-- fixedUpdate() +LoopManager : |-- update() +LoopManager : |-- render() +@enduml diff --git a/img/gameloop-flow.puml b/img/gameloop-flow.puml new file mode 100644 index 0000000..1a46cd7 --- /dev/null +++ b/img/gameloop-flow.puml @@ -0,0 +1,27 @@ +@startuml +title Game Loop Flowchart + +start + +:Initialize LoopManager; +:Start LoopTimer; + +repeat + :Update LoopTimer; + :Check for Events; + :Process Input; + + while (Lag >= Fixed Delta Time?) is (yes) + :Perform Fixed Update; + :Advance Fixed Update; + endwhile + + :Perform Normal Update; + :Render Frame; + +repeat while (Game Running?) + +:Game exit logic; + +stop +@enduml -- cgit v1.2.3 From 370c72acdb43ddb79583c232af9f91155425fc8d Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sat, 26 Oct 2024 15:58:11 +0200 Subject: WIP save manager design --- design.tex | 45 +++++++++++++++++++++++++++++++++------------ img/class-scripts.puml | 7 +++++-- projdoc.cls | 2 +- reqs.toml | 45 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 84 insertions(+), 15 deletions(-) diff --git a/design.tex b/design.tex index 08ea7cc..a3da41c 100644 --- a/design.tex +++ b/design.tex @@ -24,15 +24,15 @@ workflows. \section{Overview} -\subsection{Core} - -\subsection{Patterns} +% TODO: high-level design introduction +% - which parts of the design are prerequisites (and therefore not designed by us) +% - why are all parts in the following section arranged in the way they are \section{Design} -\subsection{Rendering} +% \subsection{Rendering} -\subsection{Physics} +% \subsection{Physics} \subsection{Scripting} @@ -91,10 +91,11 @@ follows:\noparbreak contains the following classes:\noparbreak \begin{description} \item[Script] This is the script \emph{interface}, and is used by the game - programmer to create derived script classes. All methods in this class are - declared virtual and have an empty implementation. + programmer to create derived script classes. All virtual methods in this class + have an empty implementation by default, and are optionally implemented by the + game programmer. - This class' methods are protected by default, and a friend relation to + This class' virtual methods are protected by default, and a friend relation to \codeinline{ScriptSystem} is used to ensure only \codeinline{ScriptSystem} is able to call these methods. @@ -103,6 +104,10 @@ contains the following classes:\noparbreak function returns a reference to the \codeinline{BehaviorScript} instance it was called on so it can be chained after the call to \codeinline{GameObject::add_component}. + + \codeinline{Script} also has a reference to its parent + \codeinline{BehaviorScript} instance so components can easily be retrieved using + the component manager. \item[BehaviorScript] This is the script \emph{component}, and is given as the template parameter to \codeinline{GameObject::add_component}. @@ -184,13 +189,29 @@ contains the following classes: \label{fig:class-audio-facade} \end{figure} -\subsection{Input} +\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}). -\subsection{Physics} +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:???}) +\end{itemize} -\section{Tools} +% \subsection{Input} -\section{Conclusion} +% \subsection{Physics} \end{document} diff --git a/img/class-scripts.puml b/img/class-scripts.puml index 8fc36c9..44cbe85 100644 --- a/img/class-scripts.puml +++ b/img/class-scripts.puml @@ -10,10 +10,12 @@ package api { class Component <> class Script { + - Script() + -- # init() <> # update() <> -- - - Script() + - parent : BehaviorScript * } class BehaviorScript { @@ -26,7 +28,8 @@ package api { } BehaviorScript -u-|> Component - Script .u.> BehaviorScript + Script <.u. BehaviorScript : > friend + Script ..u> BehaviorScript } class System <> diff --git a/projdoc.cls b/projdoc.cls index b369b18..a0c8e10 100644 --- a/projdoc.cls +++ b/projdoc.cls @@ -330,7 +330,7 @@ % adjust scale for puml diagrams \newcommand{\includepumldiag}[1]{% \StrSubstitute{#1}{.puml}{.eps}[\filename]% - \fitimg{\includegraphics[scale=0.75]{\filename}}% + \fitimg{\includegraphics[scale=0.65]{\filename}}% } % prevent page break between two paragraphs diff --git a/reqs.toml b/reqs.toml index a83208e..8cf9bca 100644 --- a/reqs.toml +++ b/reqs.toml @@ -117,3 +117,48 @@ Unless explicitly changed by the game programmer, methods on instances of must be called by the script system. ''' +[savemgr] +type = 'user' +priority = 'must' +description = ''' +The engine provides an \gls{api} for saving various kinds of game data +(e.g.~progress, levels, statistics, unlocked items, achievements). +''' + +[savemgr:journalling] +type = 'system' +priority = 'should' +description = ''' +The save manager uses a journal to store data, such that partial saves do not +cause data loss. +''' + +[savemgr:types-custom] +type = 'system' +priority = 'will not' +description = ''' +The save manager can be extended to store and retrieve game programmer-defined +types and data structures. +''' + +[savemgr:types-scalar] +type = 'system' +priority = 'must' +description = ''' +The save manager is able to store and retrieve scalar types. +''' + +[savemgr:types-string] +type = 'system' +priority = 'must' +description = ''' +The save manager is able to store and retrieve strings. +''' + +[savemgr:multi-file] +type = 'system' +priority = 'will not' +description = ''' +The save manager can load multiple different save files. +''' + -- cgit v1.2.3 From ec0ec67936f03a3e44dcfde40d8398edf8afa517 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sat, 26 Oct 2024 15:59:46 +0200 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 7fde818..1abed63 100644 --- a/time.txt +++ b/time.txt @@ -85,6 +85,7 @@ loek: 2024-10-24 1h20m project meeting loek: 2024-10-24 30m review :: PR review (merge only, #8 and #11) loek: 2024-10-25 30m implementation :: scripting interface loek: 2024-10-25 20m review :: PR review (+errands, merge only, #12 and #13) +loek: 2024-10-26 3h20m implementation :: save manager max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From e4ec06b02288dbf3c9898e3d7c029b1fe3fc3e27 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 27 Oct 2024 12:38:17 +0100 Subject: restore audio facade puml theme include --- img/facade-audio.puml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/img/facade-audio.puml b/img/facade-audio.puml index d3e732b..60af60f 100644 --- a/img/facade-audio.puml +++ b/img/facade-audio.puml @@ -1,5 +1,5 @@ @startuml -!include ../img/theme.ipuml +!include theme.ipuml skinparam Linetype ortho package crepe { -- cgit v1.2.3 From 07a919befbdff9d7da8db95a890c2f647396cd23 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 27 Oct 2024 19:34:23 +0100 Subject: more WIP design --- design.tex | 16 +++++++++++++++- img/class-savemgr.puml | 13 +++++++++++++ reqs.toml | 20 ++++++++++++++++++++ 3 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 img/class-savemgr.puml diff --git a/design.tex b/design.tex index a3da41c..761658c 100644 --- a/design.tex +++ b/design.tex @@ -206,9 +206,23 @@ 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:???}) + (\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. + % \subsection{Input} % \subsection{Physics} diff --git a/img/class-savemgr.puml b/img/class-savemgr.puml new file mode 100644 index 0000000..30bcd08 --- /dev/null +++ b/img/class-savemgr.puml @@ -0,0 +1,13 @@ +@startuml +!include theme.ipuml +skinparam Linetype ortho + +class SaveManager { + +} + +class ValueBroker { + +} + +@enduml diff --git a/reqs.toml b/reqs.toml index 8cf9bca..9ad0a86 100644 --- a/reqs.toml +++ b/reqs.toml @@ -162,3 +162,23 @@ description = ''' The save manager can load multiple different save files. ''' +[savemgr:file-manage] +type = 'system' +priority = 'must' +description = ''' +The save manager manages opening/closing the underlying file, and flushing +in-memory data to the file. +''' +done = ''' +The game programmer is able to use the save manager without explicit +(de)initialization. +''' + +[savemgr:var-key] +type = 'system' +priority = 'must' +description = ''' +The save manager provides access to variables uniquely identified by a key +string. +''' + -- cgit v1.2.3 From 606e29c0fc261854ed440fd7a7d57dc92158b9c5 Mon Sep 17 00:00:00 2001 From: jaroWMR Date: Tue, 29 Oct 2024 22:06:53 +0100 Subject: added fixed loop flowchart --- figs.drawio | 387 ++++++++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 327 insertions(+), 60 deletions(-) diff --git a/figs.drawio b/figs.drawio index 7d04108..2a2cb54 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,4 +1,4 @@ - + @@ -736,7 +736,7 @@ - + @@ -1068,7 +1068,7 @@ - + @@ -1094,7 +1094,7 @@ - + @@ -1108,21 +1108,24 @@ - + + + + - + - + - + @@ -1132,14 +1135,17 @@ + + + - + - + - + @@ -1156,7 +1162,7 @@ - + @@ -1169,11 +1175,47 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + @@ -1243,7 +1285,7 @@ - + @@ -1257,7 +1299,7 @@ - + @@ -1266,10 +1308,13 @@ - + - + + + + @@ -1282,8 +1327,8 @@ - - + + @@ -1354,12 +1399,12 @@ - + - - + + - + @@ -1368,27 +1413,27 @@ - + - - + + - - + + - - + + - - + + @@ -1397,8 +1442,7 @@ - - + @@ -1407,7 +1451,8 @@ - + + @@ -1416,7 +1461,7 @@ - + @@ -1453,7 +1498,7 @@ - + @@ -1491,55 +1536,90 @@ - + - - + + - + - - + + - - + + + + + + + + + + + + + + + + + - - + + + + + + + + - - + + - - + + - - + + + + + + + + + + + + + + + + + - - + - + - + @@ -1553,7 +1633,7 @@ - + @@ -1561,8 +1641,195 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + -- cgit v1.2.3 From 1d13f01699fb2337b71ef265bfb459b92b277f75 Mon Sep 17 00:00:00 2001 From: jaroWMR Date: Thu, 31 Oct 2024 08:57:21 +0100 Subject: updated design --- figs.drawio | 276 ++++++++++++++++++++++++++++++------------------------------ 1 file changed, 138 insertions(+), 138 deletions(-) diff --git a/figs.drawio b/figs.drawio index ef84f8d..a45199b 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + @@ -18,10 +18,10 @@ - + - + @@ -143,7 +143,7 @@ - + @@ -198,7 +198,7 @@ - + @@ -209,7 +209,7 @@ - + @@ -229,7 +229,7 @@ - + @@ -255,7 +255,7 @@ - + @@ -272,40 +272,40 @@ - + - + - + - + - + - + - + - + - + - + - + - + @@ -360,7 +360,7 @@ - + @@ -519,7 +519,7 @@ - + @@ -617,19 +617,19 @@ - + - + - + - + @@ -652,83 +652,83 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -737,7 +737,7 @@ - + @@ -747,12 +747,12 @@ - + - + @@ -761,32 +761,32 @@ - + - + - + - + - + - + - + - + @@ -795,7 +795,7 @@ - + @@ -804,72 +804,72 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -879,7 +879,7 @@ - + @@ -889,7 +889,7 @@ - + @@ -898,7 +898,7 @@ - + @@ -907,12 +907,12 @@ - + - + @@ -921,58 +921,58 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -981,7 +981,7 @@ - + @@ -990,12 +990,12 @@ - + - + @@ -1005,40 +1005,40 @@ - + - + - + - + - + - + - + - + - + - + @@ -1048,26 +1048,26 @@ - + - + - + - + - + - + @@ -1077,7 +1077,7 @@ - + @@ -1085,10 +1085,10 @@ - + - + @@ -1098,13 +1098,13 @@ - + - + - + @@ -1114,7 +1114,7 @@ - + @@ -1124,10 +1124,10 @@ - + - + @@ -1137,10 +1137,10 @@ - + - + @@ -1150,20 +1150,20 @@ - + - + - + - + -- cgit v1.2.3 From 8ea0137aeeb5cc32c0456a7e2b7c4cbd8b73f010 Mon Sep 17 00:00:00 2001 From: max-001 Date: Thu, 31 Oct 2024 16:40:59 +0100 Subject: Made chapter two of the design --- design.tex | 86 +++++++++++++++++++++++++++++++++++++++++++++++-- img/JetpackJoyride.jpg | Bin 0 -> 295103 bytes sources.bib | 12 +++++++ 3 files changed, 96 insertions(+), 2 deletions(-) create mode 100644 img/JetpackJoyride.jpg diff --git a/design.tex b/design.tex index 08ea7cc..94ff3a7 100644 --- a/design.tex +++ b/design.tex @@ -23,10 +23,92 @@ Unity and are looking for a flexible, cost-effective solution with familiar workflows. \section{Overview} +As described above, the cr\^epe game engine's goal is to offer a Unity-like experience +tailored for developing 2D games similar to Jetpack Joyride. That is why Jetpack +Joyride and Unity provided the main inputs for this game engine design. Firstly, a +quick overview will be given of the Unity game engine, in particular the \gls{ecs}. +Secondly, this Overview will quickly talk you through some of the most important +parts of the game engine, and why these parts are needed to create the Jetpack +Joyride game. + +\subsection{ECS} +The Unity game engine is structured using the Entity Component System (\gls{ecs}) +(as shown in \cref{fig:ECS Block Diagram}). The \gls{ecs} is made out of three +main subsystems, namely entities, components and systems. Entities are just IDs. +An entity is also called a GameObject in Unity and it is made out of one (or +more) components. Components are the classes that hold the data. The components +determine what kind of entity it is (e.g. an enemy, audio, and so on). Systems take +care of the behavior of the entities. Systems mainly read and write the enity's +components data. The \gls{ecs} clearly distinguishes the data (components) from the +functionality (systems). -\subsection{Core} +\begin{figure} + \centering + \includegraphics[width=0.5\textwidth]{img/ECSBlockDiagram.png} + \caption{ECS design pattern} + Source: \autocite{img:ECSBlockDiagram} + \label{fig:ECS Block Diagram} +\end{figure} + +The \gls{ecs} will also be used at the cr\^epe game engine. Everything (from the +protagonist and bullets to the walls and enemies) in the cr\^epe game engine will +be a GameObject (a.k.a. entity). The game programmer must program his game by +creating all kind of GameObjects and placing them in one (or multiple) scenes, just +like Unity. + +\subsection{Jetpack Joyride} +Firstly, some background information about Jetpack Joyride. Jetpack Joyride is a +side-scrolling endless runner action video game created by Halfbrick Studios. The +protagonist is called Barry Steakfries, who the player controls as he steals a +bullet-powered jet pack from a top-secret laboratory \autocite{wiki:JetpackJoyride}. +A screenshot from the game can be seen in \cref{fig:JetpackJoyride} (pleae 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). + +\begin{figure} + \centering + \includegraphics[width=0.5\textwidth]{img/JetpackJoyride.jpg} + \caption{Jetpack Joyride} + Source: \autocite{img:JetpackJoyride} + \label{fig:JetpackJoyride} +\end{figure} -\subsection{Patterns} +The protagonist wears a jetpack with which he can float in the air. The player must +avoide obstacles (such as lasers, missiles and zappers) by floating at the right +height. The player can control the protagonist's jetpack, thereby also controlling +the protagonist's height. The protagonist experiences gravity and other forces (like +the force from his jetpack pushing him upwards). These forces should be easily +programmable by the game programmer. That is why a physics system is needed in the +cr\^epe game engine. Only very limited/easy physics are needed for Jetpack Joyride, +that is why this is only supported by the cr\^epe game engine. + +The protagonist must avoid obstacles. That is why the cr\^epe game engine should +also support a collision system. Again, only very limited/easy collision is needed +for Jetpack Joyride, that is why only very limited/easy collision is supported +by the cr\^epe game engine. + +The game must, of course, also be visible to and playable by the user. A rendering +system will take care of rendering (displaying) the game and its GameObjects. An +input system will take care of all the inputs (mouse and keyboard). + +Jetpack Joyride also offers audio. A system will take care of the audio in the cr\^epe +game engine. + +Particles are very common in Jetpack Joyride, e.g. underneath the jetpack and behind +the rockets. Particles will be supported by the particle system. + +The start of a scene is described in a scene. However, the game programmer might also +want to write game logic code which is running during the game (e.g. to switch to a +new scene or to perform a custom action at a collision). For these purposes, Unity +uses scripts. These scripts will also be supported by the cr\^epe game engine. + +Finally, as an extra, replay functionality will be supported by the cr\^epe game +engine. A dedicated replay system will be used to support replay. + +It turns out that a physics, collision, rendering, input, audio, particle, script, +and replay system are needed to create the Jetpack Joyride game. These systems form +the main part of the \gls{ecs}. The design of these eight systems in combination with +\gls{ecs}, will be briefly discussed in the next parts of this design document. \section{Design} diff --git a/img/JetpackJoyride.jpg b/img/JetpackJoyride.jpg new file mode 100644 index 0000000..d1c0e9e Binary files /dev/null and b/img/JetpackJoyride.jpg differ diff --git a/sources.bib b/sources.bib index 7d7b6f7..dc05a95 100644 --- a/sources.bib +++ b/sources.bib @@ -194,3 +194,15 @@ date = {2024} } +@online{wiki:JetpackJoyride, + title = {Jetpack Joyride wikipedia}, + url = {https://en.wikipedia.org/wiki/Jetpack_Joyride}, + urldate = {2024-10-22}, +} + +@misc{img:JetpackJoyride, + title = {Jetpack Joyride}, + author = {Halbrick}, + url = {https://www.halfbrick.com/games/jetpack-joyride-2}, + date = {2024} +} -- cgit v1.2.3 From 36f25d64abc37f6fa0fbd1c10f11dfe3ac10b5ea Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 31 Oct 2024 17:01:46 +0100 Subject: WIP more design --- design.tex | 41 ++++++++++++++++++++++++++++++++++++++++- img/activity-scripts.puml | 21 +++++++++++++++++++++ img/theme.ipuml | 14 ++++---------- 3 files changed, 65 insertions(+), 11 deletions(-) create mode 100644 img/activity-scripts.puml diff --git a/design.tex b/design.tex index 761658c..340a662 100644 --- a/design.tex +++ b/design.tex @@ -69,6 +69,7 @@ architecture:\noparbreak \end{itemize} \subsubsection{Architecture} +\label{sec:scripts:architecture} The restrictions detailed at the start of this section are mitigated as follows:\noparbreak @@ -115,7 +116,8 @@ contains the following classes:\noparbreak This class also uses a friend relation to \codeinline{ScriptSystem} to restrict access to its private reference member \codeinline{script}. \item[ScriptSystem] This is the system class that runs the methods implemented in - the derivative instances of \codeinline{Script}. + the derivative instances of \codeinline{Script}. Described further in + \cref{sec:scripts:sytem}. \end{description} \begin{figure} @@ -125,6 +127,32 @@ contains the following classes:\noparbreak \label{fig:class-scripts} \end{figure} +\subsubsection{System} +\label{sec:scripts:sytem} + +Because most of the complexity in the scripting interface comes from the containers +described in \cref{sec:scripts:architecture}, the script system class itself is +relatively simple. The script system provides a method +\codeinline{ScriptSystem::update} that calls all active script's update functions. + +Because of the limitation that types cannot be passed as parameters in C++, the +user-defined script class (derived from \codeinline{Script}) can not directly be +instantiated when adding the component to the component manager. To work around this +limitation, the method \codeinline{BehaviorScript::set_script} was created. This +results in the possibility that an instance of \codeinline{BehaviorScript} does not +reference an instance of \codeinline{Script}. In addition to the non-active script +components, the script system skips over these `invalid' instances. This is +illustrated in \cref{fig:activity-scripts}. + +\begin{figure} + \centering + \includepumldiag{img/activity-scripts.puml} + \caption{Script system update method} + \label{fig:activity-scripts} +\end{figure} + +A \gls{poc} for the script system + \subsection{Audio} Since writing a custom real-time audio mixing engine is outside the scope of this @@ -227,5 +255,16 @@ requirements were also set:\noparbreak % \subsection{Physics} +\appendix + +\section{\Glsfmtlongpl{poc}} + +\subsection{Script system} +\label{poc:scripts} + +\subsection{Global configuration interface} + +\subsection{Logging utilities} + \end{document} diff --git a/img/activity-scripts.puml b/img/activity-scripts.puml new file mode 100644 index 0000000..b833bdf --- /dev/null +++ b/img/activity-scripts.puml @@ -0,0 +1,21 @@ +@startuml +!include theme.ipuml + +start + +label continue +:Get list of ""BehaviorScript"" components from ""ComponentManager""; + +while (for each ""BehaviorScript"" in list) + if (""BehaviorScript"" is active) then (yes) + if (""BehaviorScript"" has an instance of ""Script"") then (yes) + :Call update function of ""BehaviorScript""'s ""Script"" instance; + else (no) + endif + else (no) + endif +endwhile + +stop + +@enduml diff --git a/img/theme.ipuml b/img/theme.ipuml index 81391e2..c44db05 100644 --- a/img/theme.ipuml +++ b/img/theme.ipuml @@ -1,18 +1,10 @@ ' vim:ft=plantuml - - - +!theme plain skinparam ClassAttributeIconSize 0 skinparam ClassFontStyle bold skinparam DefaultFontName Inter skinparam DefaultFontSize 10 +skinparam DefaultMonospacedFontName "JetBrains Mono" skinparam MaxMessageSize 200 skinparam Nodesep 25 ' skinparam Padding 0 @@ -20,6 +12,8 @@ skinparam Ranksep 50 skinparam RoundCorner 0 skinparam PackageStyle rectangle skinparam PackageFontStyle italic +skinparam ActivityStartColor black +skinparam ActivityEndColor black hide class circle -- cgit v1.2.3 From bc4353cba5323a1e60c41e357838edc0be67958b Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 31 Oct 2024 17:15:49 +0100 Subject: fix code style --- design.tex | 73 ++++++++++++++++++++++++++++++++----------------------------- sources.bib | 16 +++++++++----- 2 files changed, 48 insertions(+), 41 deletions(-) diff --git a/design.tex b/design.tex index 94ff3a7..88d7cc8 100644 --- a/design.tex +++ b/design.tex @@ -23,58 +23,61 @@ Unity and are looking for a flexible, cost-effective solution with familiar workflows. \section{Overview} -As described above, the cr\^epe game engine's goal is to offer a Unity-like experience -tailored for developing 2D games similar to Jetpack Joyride. That is why Jetpack -Joyride and Unity provided the main inputs for this game engine design. Firstly, a -quick overview will be given of the Unity game engine, in particular the \gls{ecs}. -Secondly, this Overview will quickly talk you through some of the most important -parts of the game engine, and why these parts are needed to create the Jetpack -Joyride game. + +As described above, the cr\^epe game engine's goal is to offer a Unity-like +experience tailored for developing 2D games similar to Jetpack Joyride. That is why +Jetpack Joyride and Unity provided the main inputs for this game engine design. +Firstly, a quick overview will be given of the Unity game engine, in particular the +\gls{ecs}. Secondly, this Overview will quickly talk you through some of the most +important parts of the game engine, and why these parts are needed to create the +Jetpack Joyride game. \subsection{ECS} -The Unity game engine is structured using the Entity Component System (\gls{ecs}) -(as shown in \cref{fig:ECS Block Diagram}). The \gls{ecs} is made out of three -main subsystems, namely entities, components and systems. Entities are just IDs. -An entity is also called a GameObject in Unity and it is made out of one (or -more) components. Components are the classes that hold the data. The components -determine what kind of entity it is (e.g. an enemy, audio, and so on). Systems take -care of the behavior of the entities. Systems mainly read and write the enity's -components data. The \gls{ecs} clearly distinguishes the data (components) from the -functionality (systems). + +The Unity game engine is structured using the Entity Component System (\gls{ecs}) (as +shown in \cref{fig:ecs-block-diagram}). The \gls{ecs} is made out of three main +subsystems, namely entities, components and systems. Entities are just IDs. An entity +is also called a GameObject in Unity and it is made out of one (or more) components. +Components are the classes that hold the data. The components determine what kind of +entity it is (e.g. an enemy, audio, and so on). Systems take care of the behavior of +the entities. Systems mainly read and write the enity's components data. The +\gls{ecs} clearly distinguishes the data (components) from the functionality +(systems). \begin{figure} \centering \includegraphics[width=0.5\textwidth]{img/ECSBlockDiagram.png} \caption{ECS design pattern} - Source: \autocite{img:ECSBlockDiagram} - \label{fig:ECS Block Diagram} + Source: \autocite{img:ecs-block-diag} + \label{fig:ecs-block-diagram} \end{figure} The \gls{ecs} will also be used at the cr\^epe game engine. Everything (from the -protagonist and bullets to the walls and enemies) in the cr\^epe game engine will -be a GameObject (a.k.a. entity). The game programmer must program his game by -creating all kind of GameObjects and placing them in one (or multiple) scenes, just -like Unity. +protagonist and bullets to the walls and enemies) in the cr\^epe game engine will be +a GameObject (i.e.~entity). The game programmer must program his game by creating all +kind of GameObjects and placing them in one (or multiple) scenes, just like Unity. \subsection{Jetpack Joyride} + Firstly, some background information about Jetpack Joyride. Jetpack Joyride is a side-scrolling endless runner action video game created by Halfbrick Studios. The protagonist is called Barry Steakfries, who the player controls as he steals a -bullet-powered jet pack from a top-secret laboratory \autocite{wiki:JetpackJoyride}. -A screenshot from the game can be seen in \cref{fig:JetpackJoyride} (pleae 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). +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 +create an exact replica of Jetpack Joyride, it is only used as a source of +inspiration). \begin{figure} \centering \includegraphics[width=0.5\textwidth]{img/JetpackJoyride.jpg} \caption{Jetpack Joyride} - Source: \autocite{img:JetpackJoyride} - \label{fig:JetpackJoyride} + Source: \autocite{img:jetpack-joyride} + \label{fig:jetpack-joyride} \end{figure} The protagonist wears a jetpack with which he can float in the air. The player must -avoide obstacles (such as lasers, missiles and zappers) by floating at the right +avoid obstacles (such as lasers, missiles and zappers) by floating at the right height. The player can control the protagonist's jetpack, thereby also controlling the protagonist's height. The protagonist experiences gravity and other forces (like the force from his jetpack pushing him upwards). These forces should be easily @@ -82,17 +85,17 @@ programmable by the game programmer. That is why a physics system is needed in t cr\^epe game engine. Only very limited/easy physics are needed for Jetpack Joyride, that is why this is only supported by the cr\^epe game engine. -The protagonist must avoid obstacles. That is why the cr\^epe game engine should -also support a collision system. Again, only very limited/easy collision is needed -for Jetpack Joyride, that is why only very limited/easy collision is supported -by the cr\^epe game engine. +The protagonist must avoid obstacles. That is why the cr\^epe game engine should also +support a collision system. Again, only very limited/easy collision is needed for +Jetpack Joyride, that is why only very limited/easy collision is supported by the +cr\^epe game engine. The game must, of course, also be visible to and playable by the user. A rendering system will take care of rendering (displaying) the game and its GameObjects. An input system will take care of all the inputs (mouse and keyboard). -Jetpack Joyride also offers audio. A system will take care of the audio in the cr\^epe -game engine. +Jetpack Joyride also offers audio. A system will take care of the audio in the +cr\^epe game engine. Particles are very common in Jetpack Joyride, e.g. underneath the jetpack and behind the rockets. Particles will be supported by the particle system. diff --git a/sources.bib b/sources.bib index dc05a95..0ff00a1 100644 --- a/sources.bib +++ b/sources.bib @@ -164,7 +164,7 @@ date = {2016} } -@misc{img:ECSBlockDiagram, +@misc{img:ecs-block-diag, title = {ECS Diagram}, author = {{Unity}}, url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/images/ECSBlockDiagram.png}, @@ -194,15 +194,19 @@ date = {2024} } -@online{wiki:JetpackJoyride, - title = {Jetpack Joyride wikipedia}, - url = {https://en.wikipedia.org/wiki/Jetpack_Joyride}, +@online{wikipedia:jetpack-joyride, + author = {{Wikipedia contributors}}, + title = {Jetpack Joyride --- {Wikipedia}{,} The Free Encyclopedia}, + year = {2024}, + url = {https://en.wikipedia.org/w/index.php?title=Jetpack_Joyride&oldid=1252734266}, urldate = {2024-10-22}, } -@misc{img:JetpackJoyride, +@misc{img:jetpack-joyride, title = {Jetpack Joyride}, author = {Halbrick}, url = {https://www.halfbrick.com/games/jetpack-joyride-2}, - date = {2024} + date = {2024}, + urldate = {2024-10-22}, } + -- cgit v1.2.3 From 84a307ad81d5b2ba0e92c70a1da2cd9075e7c191 Mon Sep 17 00:00:00 2001 From: jaroWMR Date: Thu, 31 Oct 2024 18:57:36 +0100 Subject: added flowcharts for systems --- figs.drawio | 518 ++++++++++++++++++++++++++++++------------------------ notulen/wk9-1.txt | 54 ++++++ 2 files changed, 339 insertions(+), 233 deletions(-) create mode 100644 notulen/wk9-1.txt diff --git a/figs.drawio b/figs.drawio index a45199b..ec66484 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + - + @@ -259,7 +259,7 @@ - + @@ -290,29 +290,26 @@ - - - - + - + - + - + - + - + - + @@ -481,25 +478,6 @@ - - - - - - - - - - - - - - - - - - - @@ -653,7 +631,7 @@ - + @@ -681,52 +659,46 @@ - + - + - - - - - - - + - + - + - + - + - + - + - + - + - - + + - + @@ -927,7 +899,7 @@ - + @@ -937,20 +909,17 @@ - - - - + - + - + - + @@ -1151,7 +1120,7 @@ - + @@ -1170,6 +1139,39 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -1293,291 +1295,341 @@ - + - - - - + - - + + - + - - + + + + + - + - - - + - - - - + - - + + - + - - - + + + + + + + + + + + + + + + + + + + + + - - + + - - + + - + - - + + - - + + - - + + - - - + + + - - - - - + + - - + + + - + - - + + - + - + + + + - - + + - + - + - - + + - - + + - + - - - - - - - - - + + - - + + - - + + - + - - + + - + - - - - - + + + + + + - - + + + + - - + + + + + + - - + + + + - - + + - + - + + + + - - + - - - + + + + + + + + - - + + - - + + + + + + + + + + + - - + + - - + + + + + - + - - - - - - - - - + + + + + + - - + + + + - - + + - + - - - - - + + - + - - + + - - + + - - + + - - - + + + + + + + + + + + + - - - - - - - + + + - - + + - - + + + + - + - - + + - - + + - - + + - + - - - + - - - - - + + - + - + + + + - - + + - - + + - - + + + + + + + + + - - + + + + + + + + + diff --git a/notulen/wk9-1.txt b/notulen/wk9-1.txt new file mode 100644 index 0000000..f897d96 --- /dev/null +++ b/notulen/wk9-1.txt @@ -0,0 +1,54 @@ + Documents + Research Document + Continue adding research information + Project plan + - + Document standard + Add updates when needed + Requirement + physics sub-requirements -> Jaro write document + eventmanager sub-requirements -> Wouter write document + gameloop sub-requirements -> Wouter write document + ecs sub-requirements + particles sub-requirement -> Jaro write document + resourceManager sub-requirement -> Niels write document + rendering sub-requirement + script requirements added. + design document + API in design document + Game design + - + Git + Code standard -> LOEK update + Show updates + Code standard with examples not in main? -> niels + Environments + - + Research (POC) + [closed] research eventmanager -> Wouter POC is af + start research ui -> wouter POC uit + start research ai + start research playback -> Max + start research scenes -> Max + star research camera -> Niels POC + start research savedata -> loek + start research renderer -> niels (sprite & color & transform) POC simple (SDL_GPU voor efficiency verbetering) + [closed] start research physics Starting POC -> Jaro + More research about physics + [closed] start reasearch collision detection -> Jaro + [closed] start research particles Starting research -> Jaro (start lifetime. spawning area) + start poc animatie -> niels + Design + Adding design asset class -> niels + Adding design resource holder -> niels + How does a game designer make a scene? + Product + - + Test + - + Question Bob + mag de API gewoon een interface worden voor wat onderliggend een ECS is. + Overig + Timers voor systems (profiler van systems) + + -- cgit v1.2.3 From cf6c883c5b09d2cd2d3f7a117b5ce2b31c92a00f Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 31 Oct 2024 19:00:06 +0100 Subject: more POC showcase --- design.tex | 64 +++++++++++++++++++++++++++++++++++++-------- img/poc-output-scripts.png | Bin 0 -> 31761 bytes 2 files changed, 53 insertions(+), 11 deletions(-) create mode 100644 img/poc-output-scripts.png diff --git a/design.tex b/design.tex index 340a662..9088528 100644 --- a/design.tex +++ b/design.tex @@ -151,7 +151,7 @@ illustrated in \cref{fig:activity-scripts}. \label{fig:activity-scripts} \end{figure} -A \gls{poc} for the script system +A \gls{poc} for the script system is showcased in \cref{poc:scripts}. \subsection{Audio} @@ -168,15 +168,7 @@ searching for libraries (search terms: `dynamic/adaptive audio', `real-time audi `audio library', `game audio engine'), several libraries were found. These libraries were checked against the audio engine requirements \autocite{crepe:requirements} and then tested by writing the same benchmark-style \gls{poc} using the remaining -qualifying libraries:\noparbreak -\begin{enumerate} - \item Load a background track (Ogg Vorbis) - \item Load three short samples (WAV) - \item Start the background track - \item Play each sample sequentially while pausing and resuming the background track - \item Play all samples simultaniously - \item Stop all audio and exit -\end{enumerate} +qualifying libraries. These \glspl{poc} are detailed in \cref{poc:audio}. Of these libraries the following were determined to be unsuitable for use in this project:\noparbreak @@ -217,6 +209,8 @@ contains the following classes: \label{fig:class-audio-facade} \end{figure} +A \gls{poc} for the final Audio fa\c{c}ade 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 @@ -251,6 +245,8 @@ requirements were also set:\noparbreak % In order to realize \cref{req:savemgr:journalling,req:savemgr:var-key}, a third-party % key-value database library is used. +\subsection{Global configuration interface} + % \subsection{Input} % \subsection{Physics} @@ -259,12 +255,58 @@ requirements were also set:\noparbreak \section{\Glsfmtlongpl{poc}} +The full (documented) source code of these \glspl{poc} is available on GitHub +\autocite{crepe:code-repo}. + \subsection{Script system} \label{poc:scripts} -\subsection{Global configuration interface} +The script system \gls{poc} \autocite[script example]{crepe:code-repo} consists of +the following:\noparbreak +\begin{itemize} + \item A user-defined class (\codeinline{MyScript}) derived from + \codeinline{Script}, which only implements the \codeinline{update()} function. + \item A main function that--- + \begin{itemize} + \item Creates a game object with \codeinline{Transform} and + \codeinline{BehaviorScript} components. + \item A call to \codeinline{ScriptSystem::update}, which results in + \codeinline{MyScript::update} being called. + \end{itemize} +\end{itemize} + +Running the \gls{poc} results in the output shown in \cref{fig:poc-output-scripts}, +demonstrating that the system works as intended. + +\begin{figure} + \centering + \fitimg{\includegraphics{img/poc-output-scripts.png}} + \caption{Script system \glsfmtshort{poc} output} + \label{fig:poc-output-scripts} +\end{figure} \subsection{Logging utilities} +\label{poc:log} + +\subsection{Audio} +\label{poc:audio} + +A test that consists of the following steps was written for each audio library +mentioned in \cref{sec:audio:libs}:\noparbreak +\begin{enumerate} + \item Load a background track (Ogg Vorbis) + \item Load three short samples (WAV) + \item Start the background track + \item Play each sample sequentially while pausing and resuming the background track + \item Play all samples simultaniously + \item Stop all audio and exit +\end{enumerate} + +The repository \autocite{crepe:code-repo} contains two finished \glspl{poc} under the +\codeinline{mwe/audio/} subdirectory for miniaudio and SoLoud. The SoLoud \gls{poc} +was later converted to a full audio fa\c{c}ade, which is currently part of the +cr\^epe engine. The \gls{poc} using the audio fa\c{c}ade is available from the same +repository, under the \codeinline{src/example/audio_internal.cpp} file. \end{document} diff --git a/img/poc-output-scripts.png b/img/poc-output-scripts.png new file mode 100644 index 0000000..068f345 Binary files /dev/null and b/img/poc-output-scripts.png differ -- cgit v1.2.3 From 299a59f4f9644d4584a39a5f2bcd5a8490645273 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Thu, 31 Oct 2024 19:00:57 +0100 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index dda4bbf..d426660 100644 --- a/time.txt +++ b/time.txt @@ -91,6 +91,7 @@ loek: 2024-10-29 10m tooling :: documentation (fix plantuml theme errors) loek: 2024-10-30 30m project meeting (min/max component count constraints) loek: 2024-10-24 10m review :: PR review (#40, #41 and #42) loek: 2024-10-31 3h45m project meeting +loek: 2024-10-31 2h50m docs :: design :: POCs max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 9bffb077a944c8baa6a93415d65908a511f9a85f Mon Sep 17 00:00:00 2001 From: jaroWMR Date: Thu, 31 Oct 2024 19:16:41 +0100 Subject: updated main diagram --- figs.drawio | 91 +++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 74 insertions(+), 17 deletions(-) diff --git a/figs.drawio b/figs.drawio index ec66484..b3f6eea 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + @@ -135,22 +135,22 @@ - - + + - - + + - - + + - + - + @@ -209,7 +209,7 @@ - + @@ -229,7 +229,7 @@ - + @@ -281,7 +281,7 @@ - + @@ -635,7 +635,7 @@ - + @@ -676,7 +676,7 @@ - + @@ -1119,8 +1119,8 @@ - - + + @@ -1172,6 +1172,63 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -1342,7 +1399,7 @@ - + -- cgit v1.2.3 From ed46b157f211c46d22ecd75e4e682f0c4f0665be Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Fri, 1 Nov 2024 12:24:27 +0100 Subject: time update --- time.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/time.txt b/time.txt index d426660..1b4a5b3 100644 --- a/time.txt +++ b/time.txt @@ -203,7 +203,11 @@ wouter: 2024-10-21 3h working on design document wouter: 2024-10-12 30m reviewing pull request logging wouter: 2024-10-24 1h20m project meeting wouter: 2024-10-25 2h added collision functionality to event manager - +wouter: 2024-10-28 2h added iKeyListener and iMouseListener to poc +wouter: 2024-10-29 20m discusing api change for UI objects +wouter: 2024-10-30 15m helping out with gameloop question +wouter: 2024-10-29 4h created diagrams for gameloop/events/inputs system +wouter: 2024-10-31 3h45m fiftheent project meeting niels: 2024-09-02 1h project meeting :: project kickoff -- cgit v1.2.3 From 24611c757318be124c01a6c335d116e7d1529554 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 1 Nov 2024 15:09:03 +0100 Subject: add design for global configuration manager + appendix log poc --- design.tex | 58 ++++++++++++++++++++++++++++++++++++++++++-------- glossary.bib | 4 ++++ img/class-config.puml | 14 ++++++++++++ img/poc-log.png | Bin 0 -> 12526 bytes 4 files changed, 67 insertions(+), 9 deletions(-) create mode 100644 img/class-config.puml create mode 100644 img/poc-log.png diff --git a/design.tex b/design.tex index 9088528..75e9ec6 100644 --- a/design.tex +++ b/design.tex @@ -151,13 +151,13 @@ illustrated in \cref{fig:activity-scripts}. \label{fig:activity-scripts} \end{figure} -A \gls{poc} for the script system is showcased in \cref{poc:scripts}. +A \gls{poc} for the script system is shown in \cref{poc:scripts}. \subsection{Audio} Since writing a custom real-time audio mixing engine is outside the scope of this project\mref and C++ does not provide a built-in cross-platform audio \gls{api}, the -audio system inside the cr\^epe engine is implemented as a fa\c{c}ade around an +audio system inside the cr\^epe engine is implemented as a \gls{facade} around an existing audio library. \subsubsection{Libraries} @@ -184,12 +184,12 @@ project:\noparbreak The only library that remained after these tests is SoLoud \autocite{lib:soloud}. It is Zlib/LibPng licensed and provides a high-level object-oriented C++ \gls{api}. -\Cref{sec:audio:architecture} describes the fa\c{c}ade written for this library. +\Cref{sec:audio:architecture} describes the \gls{facade} written for this library. \subsubsection{Architecture} \label{sec:audio:architecture} -\Cref{fig:class-audio-facade} shows a class diagram of the audio fa\c{c}ade. It +\Cref{fig:class-audio-facade} shows a class diagram of the audio \gls{facade}. It contains the following classes: \begin{description} \item[SoundContext] This is a wrapper around the \codeinline{SoLoud::soloud} @@ -205,11 +205,11 @@ contains the following classes: \begin{figure} \centering \includepumldiag{img/facade-audio.puml} - \caption{Audio fa\c{c}ade class diagram} + \caption{Audio \glsfmtshort{facade} class diagram} \label{fig:class-audio-facade} \end{figure} -A \gls{poc} for the final Audio fa\c{c}ade is also showcased in \cref{poc:audio}. +A \gls{poc} for the final Audio \gls{facade} is also showcased in \cref{poc:audio}. \subsection{Save manager} @@ -247,6 +247,26 @@ requirements were also set:\noparbreak \subsection{Global configuration interface} +Because the game programmer only has access to interfaces within the public \gls{api} +namespace (\codeinline{crepe::api}), they would not be able to configure aspects of +engine-internal components. To work around this access restriction, a global +interface was made that stores arbitrary data, which can be accessed both internally +and via the public \gls{api}. + +\subsubsection{Architecture} +\label{sec:config:architecture} + +The global configuration interface consists of a single singleton class that can be +accessed globally (see \cref{fig:class-config}). This class holds several anonymous +structs, which are used to organize options per system or engine component. + +\begin{figure} + \centering + \includepumldiag{img/class-config.puml} + \caption{Global configuration interface class diagram} + \label{fig:class-config} +\end{figure} + % \subsection{Input} % \subsection{Physics} @@ -280,7 +300,7 @@ demonstrating that the system works as intended. \begin{figure} \centering - \fitimg{\includegraphics{img/poc-output-scripts.png}} + \fitimg{\includegraphics[scale=0.7]{img/poc-output-scripts.png}} \caption{Script system \glsfmtshort{poc} output} \label{fig:poc-output-scripts} \end{figure} @@ -288,6 +308,26 @@ demonstrating that the system works as intended. \subsection{Logging utilities} \label{poc:log} +A small \gls{poc} was written to test the engine's logging functions \autocite[log +example]{crepe:code-repo}. The following calls are used in this example: + +\begin{blockcode} +dbg_trace(); // the dbg_* macros automatically show +dbg_logf("test printf parameters: %d", 3); // where the message is coming from +logf(LogLevel::INFO, "info message"); +logf(LogLevel::WARNING, "warning"); +logf(LogLevel::ERROR, "error"); +\end{blockcode} + +The output of this test is shown in \cref{fig:poc-log}. + +\begin{figure} + \centering + \includegraphics[scale=0.7]{img/poc-log.png} + \caption{Logging function outputs} + \label{fig:poc-log} +\end{figure} + \subsection{Audio} \label{poc:audio} @@ -304,8 +344,8 @@ mentioned in \cref{sec:audio:libs}:\noparbreak The repository \autocite{crepe:code-repo} contains two finished \glspl{poc} under the \codeinline{mwe/audio/} subdirectory for miniaudio and SoLoud. The SoLoud \gls{poc} -was later converted to a full audio fa\c{c}ade, which is currently part of the -cr\^epe engine. The \gls{poc} using the audio fa\c{c}ade is available from the same +was later converted to a full audio \gls{facade}, which is currently part of the +cr\^epe engine. The \gls{poc} using the audio \gls{facade} is available from the same repository, under the \codeinline{src/example/audio_internal.cpp} file. \end{document} diff --git a/glossary.bib b/glossary.bib index fda634f..0842ff8 100644 --- a/glossary.bib +++ b/glossary.bib @@ -51,4 +51,8 @@ long = {proof-of-concept}, } +@entry{facade, + name = {fa\c{c}ade}, + description = {Design pattern used to provide an abstraction from other software}, +} diff --git a/img/class-config.puml b/img/class-config.puml new file mode 100644 index 0000000..72e5e6c --- /dev/null +++ b/img/class-config.puml @@ -0,0 +1,14 @@ +@startuml +!include theme.ipuml + +class Config <> { + - Config() + + ~Config() + -- + + get_instance() : Config & <> + -- + + log : struct ... + ... +} + +@enduml diff --git a/img/poc-log.png b/img/poc-log.png new file mode 100644 index 0000000..12e2c61 Binary files /dev/null and b/img/poc-log.png differ -- cgit v1.2.3 From f316e5582c40cbfe18567c7fd34cbb1bfff3ddbb Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 1 Nov 2024 15:42:06 +0100 Subject: comment out WIP design --- design.tex | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/design.tex b/design.tex index 4a8208d..4c4794d 100644 --- a/design.tex +++ b/design.tex @@ -296,27 +296,27 @@ 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} - +% \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} % -- cgit v1.2.3 From 0cfe85c3a8766992f9b04c082143283698d756d7 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 1 Nov 2024 15:46:11 +0100 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 1b4a5b3..ba7d6ed 100644 --- a/time.txt +++ b/time.txt @@ -92,6 +92,7 @@ loek: 2024-10-30 30m project meeting (min/max component count constraints) loek: 2024-10-24 10m review :: PR review (#40, #41 and #42) loek: 2024-10-31 3h45m project meeting loek: 2024-10-31 2h50m docs :: design :: POCs +loek: 2024-11-01 1h05m docs :: design (log POC & Global configuration interface) max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 3c1d6ae0271e6f5eec968787a53fb77285215931 Mon Sep 17 00:00:00 2001 From: jaroWMR Date: Fri, 1 Nov 2024 15:47:40 +0100 Subject: update time --- time.txt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/time.txt b/time.txt index 1b4a5b3..7c8e267 100644 --- a/time.txt +++ b/time.txt @@ -329,7 +329,14 @@ jaro: 2024-10-24 1h20m project meeting jaro: 2024-10-24 3h30m physics and collision jaro: 2024-10-24 1h static collision handeling jaro: 2024-10-25 2h collision handeling and onderzoek collision event unity - +jaro: 2024-10-28 2h30m Mergen rendering + events +jaro: 2024-10-29 4h Physics,collision design + latex +jaro: 2024-10-30 2h diagrams design +jaro: 2024-10-31 30m discusing design questions +jaro: 2024-10-31 3h30m discusing design questions +jaro: 2024-10-31 1h changing diagrams +jaro: 2024-10-31 45m adding diagrams physics,collision,particles +jaro: 2024-11-1 15m weeklyupdate -- cgit v1.2.3 From d98d21ba947f79f35dda0aa5f1b9bdb2c4f9f4d4 Mon Sep 17 00:00:00 2001 From: heavydemon21 Date: Sat, 2 Nov 2024 14:19:17 +0100 Subject: design --- design.tex | 120 ++++++- figs.drawio | 784 ++++++++++++++++++++++++++++++++++++-------- img/AssesManager.png | Bin 0 -> 571725 bytes img/Rendering.png | Bin 0 -> 654711 bytes img/flowchart_rendering.png | Bin 0 -> 631423 bytes img/poc-camera.pdf | Bin 0 -> 169814 bytes img/texture.png | Bin 0 -> 593444 bytes 7 files changed, 762 insertions(+), 142 deletions(-) create mode 100644 img/AssesManager.png create mode 100644 img/Rendering.png create mode 100644 img/flowchart_rendering.png create mode 100644 img/poc-camera.pdf create mode 100644 img/texture.png diff --git a/design.tex b/design.tex index 4c4794d..c7d0ca0 100644 --- a/design.tex +++ b/design.tex @@ -115,7 +115,96 @@ the main part of the \gls{ecs}. The design of these eight systems in combination \section{Design} -% \subsection{Rendering} +\subsection{Texture} +The textures in our game engine are represented by the \codeinline{Texture} class. It is implemented a \gls{facade} around the \gls{sdl} library. + +\subsubsection{Architecture} +\Cref{fig:class-texture} shows a class diagram of the texture \gls{facade}. It contains the following classes: + +\begin{description} + \item[SDLContext] This is a facade around the \codeinline{SDL2} library which is used around different parts of the engine, + and is therefore implemented as a singleton. + This class is friends with \codeinline{Texture}, \codeinline{LoopManager}, \codeinline{RenderSystem} and \codeinline{AnimatorSystem}. + \item[Texture] This is a wrapper around the \codeinline{SDL_Texture} class, and uses + cr\^epe's \codeinline{Asset} class to load an Texture instead. +\end{description} + +\begin{figure} + \centering + \includegraphics[width=\textwidth]{img/texture.png} + \caption{User texture class diagram} + \label{fig:class-texture} +\end{figure} + + +\subsection{AssetManager} +The AssetManager is a \gls{api} class that the user can use to make a \codeinline{Asset} available from different scenes. + +\subsubsection{Architecture} +\Cref{fig:class-assetmanager} shows a class diagram of the AssetManager. It contains the following classes: + +\begin{description} + \item[AssetManager] is a Singleton class, meaning only one instance of this class exists throughout the application. + This ensures a single point of access and control over asset management, simplifying resource handling and avoiding duplicated assets in memory. +\end{description} + +\begin{figure} + \centering + \includegraphics[width= 0.5\textwidth]{img/AssesManager.png} + \caption{User AssetManager class diagram} + \label{fig:class-assetmanager} +\end{figure} + +\subsection{Rendering} +Every game engine has an rendering structure to present all the different enities and components on the screen. + +\subsubsection{Architecture} +\Cref{fig:class-rendering} shows a class diagram of the RenderSystem. It contains the following classes: + +\begin{itemize} + \item The system architecture is centered around rendering and component management, with the following key components: + \begin{enumerate} + \item \emph{System} - an interface class, containing the virtual \codeinline{update()} function. + \item \emph{RenderSystem} - a derived class of \codeinline{System} responsible for rendering operations. \end{enumerate} + \item The \codeinline{System::get_instance()} function provides a static, singleton instance for managing system-wide operations. + \item The \codeinline{RenderSystem} class implements various rendering functions: + \begin{itemize} + \item \codeinline{sort_layers()} - organizes the rendering layers. + \item \codeinline{clear_screen()} - clears the screen prior to rendering. + \item \codeinline{update_sprites()} - updates sprite positions and states. + \item \codeinline{update_camera()} - manages the camera view. + \item \codeinline{present_screen()} - presents the final rendered image to the screen. + \end{itemize} + \item The \emph{SdlContext} class, another singleton, manages the \gls(SDL) and has a friendship relationship with \codeinline{ComponentManager} + for tighter integration with component management. + \item Components are organized as follows: + \begin{itemize} + \item The \emph{Component} base class allows for generic handling of components. + \item Derived component classes include: + \begin{itemize} + \item \emph{Sprite} - represents visual elements with attributes like \codeinline{sprite}, + \codeinline{color}, \codeinline{flip}, \codeinline{sortingLayer}, and \codeinline{orderInLayer}. + \item \emph{Transform} - manages positional attributes, including \codeinline{position}, \codeinline{rotation}, and \codeinline{scale}. + \end{itemize} + \end{itemize} + \item Both \codeinline{Sprite} and \codeinline{Transform} components provide a \codeinline{get_instances_max()} function to retrieve the maximum instance count. +\end{itemize} + +\begin{figure} + \centering + \includegraphics[width=\textwidth]{img/Rendering.png} + \caption{System Rendering class diagram} + \label{fig:class-rendering} +\end{figure} + +\subsubsection{System} +\begin{figure} + \centering + \includegraphics[width=\textwidth]{img/flowchart_rendering.png} + \caption{System Rendering flowchart } + \label{fig:class-renderingflowchart} +\end{figure} + % \subsection{Physics} @@ -433,5 +522,34 @@ was later converted to a full audio \gls{facade}, which is currently part of the cr\^epe engine. The \gls{poc} using the audio \gls{facade} is available from the same repository, under the \codeinline{src/example/audio_internal.cpp} file. +\subsection{Camera} +\label{poc:camera} + +The camera \gls{poc} \autocite[camera example]{crepe:code-repo} consists of +the following:\noparbreak + +\begin{itemize} + \item An \codeinline{on_key_pressed} function, which listens for key presses and adjusts camera position and zoom based on key inputs. + \item A user-defined script class (\codeinline{MyCameraScript}) derived from \codeinline{Script}, implementing only the \codeinline{update()} function. + To update the camera movements and zoom. + \item A main function that— + \begin{itemize} + \item Subscribes the \codeinline{on_key_pressed} function to handle \codeinline{KeyPressedEvent} events. + \item Creates a \codeinline{GameObject} for the camera and adds \codeinline{Camera} and \codeinline{BehaviorScript} components, + with \codeinline{MyCameraScript} attached to manage the camera’s transformation. + \item Instantiates a background \codeinline{GameObject} with \codeinline{Transform} and \codeinline{Sprite} components, loading an external texture as its background. + \end{itemize} +\end{itemize} + +Running this \gls{poc} allows for controlled camera movement and zoom in response to key inputs. The \codeinline{MyCameraScript::update} function ensures that these transformations are applied each frame, as demonstrated by the output in \cref{fig:poc-output-camera}. + + + +\begin{figure} + \centering + \fitimg{\includegraphics[scale=0.7]{img/poc-camera.pdf}} + \caption{camera \glsfmtshort{poc} output} + \label{fig:poc-output-camera} +\end{figure} \end{document} diff --git a/figs.drawio b/figs.drawio index 3dec3aa..8a9e7cd 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + - + @@ -656,7 +656,7 @@ - + @@ -743,13 +743,13 @@ - + - + - + @@ -1139,7 +1139,7 @@ - + @@ -1148,17 +1148,17 @@ - + - + - + @@ -1167,66 +1167,66 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -2477,408 +2477,910 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/img/AssesManager.png b/img/AssesManager.png new file mode 100644 index 0000000..9dfb435 Binary files /dev/null and b/img/AssesManager.png differ diff --git a/img/Rendering.png b/img/Rendering.png new file mode 100644 index 0000000..d3491ba Binary files /dev/null and b/img/Rendering.png differ diff --git a/img/flowchart_rendering.png b/img/flowchart_rendering.png new file mode 100644 index 0000000..41306a1 Binary files /dev/null and b/img/flowchart_rendering.png differ diff --git a/img/poc-camera.pdf b/img/poc-camera.pdf new file mode 100644 index 0000000..c67c078 Binary files /dev/null and b/img/poc-camera.pdf differ diff --git a/img/texture.png b/img/texture.png new file mode 100644 index 0000000..97b79fe Binary files /dev/null and b/img/texture.png differ -- cgit v1.2.3 From 0bed01a4e2e820b8974207145cd2eb3430864ad7 Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Sat, 2 Nov 2024 20:54:17 +0100 Subject: eerste opzet --- design.tex | 105 ++++++++++++++++++++++++++++++++++++++---------- img/event-sequence.puml | 16 ++++++++ 2 files changed, 100 insertions(+), 21 deletions(-) create mode 100644 img/event-sequence.puml diff --git a/design.tex b/design.tex index 4e46388..131031f 100644 --- a/design.tex +++ b/design.tex @@ -116,17 +116,49 @@ the main part of the \gls{ecs}. The design of these eight systems in combination \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. +A game loop is essential for maintaining a continuous flow of game actions, ensuring that updates to game logic, physics, and rendering occur in a synchronized manner. Without a game loop, the game would lack consistent timing and leading to unpredictable behavior. +The game loop is mainly responsible for these 2 purposes: +\begin{itemize} + \item Updating all systems in the correct order. + \item Making sure the gameloop timer is up to date +\end{itemize} +The game loop can be external where the user has the ability to update the systems 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{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. +The game loop of this engine is integrated into the engine, this is done for the following reasons: +\begin{itemize} + \item \emph{Simplify development} The user only has to call startGame(). + \item \emph{Uniform system calls} The systems are always updated in the same order limiting overwrites and undefined system behavior. + \item \emph{Reliable timer update} Each cycle the game loop timer is always updated limiting timing issues. +\end{itemize} +As seen in figure \ref{gameloop-flow} the gameloop is divided into different steps. +\begin{itemize} + \item \emph{Update loop timer} The loop timer gets updated and the expected frame time is calculated. + \item \emph{Check events} Queued events get dispatched and callback functions are handled acordingly. + \item \emph{Process input} The input system is called and user input is processed. + \item \emph{Fixed update} A fixed loop for timing sensitive systems such as physics. + \item \emph{Update} A per frame update for all per frame updates. + \item \emph{Render} Calling the render system to render the frame. +\end{itemize} +This is done 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. +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 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. +The loop() function keeps looping as long as the game is running. +The gamedeveloper start the game engine/game using the code example below: +\begin{blockcode} + Gameloop loop; + loop.start(); +\end{blockcode} +This starts calls the setup() and loop() functions and starts the game loop timer; +To get the current frames Delta time \codeinline{LoopTimer::getInstance().getDeltaTime()} can be used which will return the expected frame time. + \begin{figure} \centering \includepumldiag{img/gameloop-flow.puml} @@ -139,28 +171,59 @@ The loop() function keeps looping as long as the game is running. Within this fu \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. - -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 +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 manipulate adn affect multiple other objects is beneficial for game developers, providing greater flexibility in designing interactions within the game. + + +\subsubsection{Architecture:} +The sollution to connect the various systems and BehaviorScripts together without inducing high coupling is an event system that facilitates communication between systems and BehaviorScripts using 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. +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. \begin{figure} \centering - \includegraphics[width=\linewidth]{img/event-uml.drawio.png} % or specify a custom width + \includegraphics[width=\linewidth]{img/event-uml.drawio.png} \caption{event system class diagram} \label{fig:event-uml} \end{figure} -\subsection{Rendering} +the event system as seen in \ref{fig:event-uml} includes several parts such as: +\begin{description} + \item[eventManager] The manager has the functions to subscribe/trigger/queue/dispatch events. It also stores all callback functions corresponding to specific event. + The manager is a singleton and can therefor only exist once so all events are stored in one place. + \item[IEventWrapper] This is a EventWrapper \emph{interface} which is used to store all the different templated eventshandlers in one map in the event manager. + this wrapper contains the logic to convert the parent class \emph{event} to the correct subclasses. It also contains a variable onSuccessDestroy which can be set to destroy the callback call onces completed. + This can be used to make a one time only event. + \item[Event] This is the parent class where all specific event classes are derived from. Each event contains a + \begin{itemize} + \item \emph{\codeinline{static std::uint32_t getStaticEventType()}} to set type during compiling. + \item \emph{\codeinline{virtual std::uint32_t getEventType() const override }} function to manage the type conversion during runtime. + \end{itemize} + Other functions can be freely added when creating a custom function. + When an event is triggered a specific derived class must be used to indicate which event is triggered. A reference to this event is then transfered to all callback functions subscribed. +\end{description} +The EventManager is a singleton so all all callbacks are stored in one place and it can be called everywhere in the system or game. +The user can use the EventManager for the following functions: +\begin{itemize} + \item \emph{Subscribe:} This subscribes a function pointer or lambda function to a given event. The function can be subscribed either to all event triggers or a specifc ID. + \item \emph{Trigger:} This triggers a given event and all callbacks correlating to this event are executed immediately. + \item \emph{Queue event:} This queues an event to be executed at a fixed time during the gameloop. + \item \emph{Unsubscibe:} This removes the callback function from the event and it will no longer be executed. +\end{itemize} +Figure \ref{fig:event-seq} shows that when a specific function is triggered or dispatched using the callback(eventHandler) is executed. +\begin{figure} + \centering + \includepumldiag{img/event-sequence.puml} + \caption{Sequence diagram for event calling} + \label{fig:event-seq} +\end{figure} % \subsection{Physics} - +\subsection{Rendering} \subsection{Scripting} The scripting interface was designed around a `target' \gls{api} (described by diff --git a/img/event-sequence.puml b/img/event-sequence.puml new file mode 100644 index 0000000..2555f33 --- /dev/null +++ b/img/event-sequence.puml @@ -0,0 +1,16 @@ +@startuml +skinparam SequenceParticipantPadding 15 + + +participant EventHandler +participant Publisher +participant EventManager + +EventHandler -> EventManager : Subscribe event +Publisher -> EventManager : trigger event + +EventManager -> EventHandler : execute callback function +Publisher -> EventManager : Queue Event +EventManager -> EventHandler : dispatching queued events +EventHandler -> EventManager : unsubscribe event +@enduml -- cgit v1.2.3 From 3007b3677ae6a0752a9d1fb136d6ea84c1b6d555 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sat, 2 Nov 2024 23:30:46 +0100 Subject: merge #48 --- design.tex | 173 +++++++++++++++++++++++++++++++++++++------------------------ 1 file changed, 105 insertions(+), 68 deletions(-) diff --git a/design.tex b/design.tex index c7d0ca0..a7ad91e 100644 --- a/design.tex +++ b/design.tex @@ -15,7 +15,7 @@ similar to Jetpack Joyride. The cr\^epe engine is designed to ease the transition for developers familiar with Unity, ensuring minimal friction when switching platforms. Our aim is to preserve -many of Unity’s core features while introducing a lightweight and open-source +many of Unity's core features while introducing a lightweight and open-source alternative, licensed under the MIT License. The engine is primarily aimed at indie developers who have prior experience with @@ -116,96 +116,126 @@ the main part of the \gls{ecs}. The design of these eight systems in combination \section{Design} \subsection{Texture} -The textures in our game engine are represented by the \codeinline{Texture} class. It is implemented a \gls{facade} around the \gls{sdl} library. + +% 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. \subsubsection{Architecture} -\Cref{fig:class-texture} shows a class diagram of the texture \gls{facade}. It contains the following classes: +\Cref{fig:class-texture} shows a class diagram of the texture \gls{facade}. It +contains the following classes:\noparbreak \begin{description} - \item[SDLContext] This is a facade around the \codeinline{SDL2} library which is used around different parts of the engine, - and is therefore implemented as a singleton. - This class is friends with \codeinline{Texture}, \codeinline{LoopManager}, \codeinline{RenderSystem} and \codeinline{AnimatorSystem}. - \item[Texture] This is a wrapper around the \codeinline{SDL_Texture} class, and uses - cr\^epe's \codeinline{Asset} class to load an Texture instead. + \item[SDLContext] This is a facade around the \codeinline{SDL2} library which is + used around different parts of the engine, and is therefore implemented as a + singleton. This class is friends with \codeinline{Texture}, + \codeinline{LoopManager}, \codeinline{RenderSystem} and + \codeinline{AnimatorSystem}. + \item[Texture] This is a wrapper around the \codeinline{SDL_Texture} class, and + uses cr\^epe's \codeinline{Asset} class to load an Texture instead. \end{description} \begin{figure} \centering + % TODO: export as vector format instead \includegraphics[width=\textwidth]{img/texture.png} \caption{User texture class diagram} \label{fig:class-texture} \end{figure} - \subsection{AssetManager} -The AssetManager is a \gls{api} class that the user can use to make a \codeinline{Asset} available from different scenes. + +The AssetManager is a \gls{api} class that the user can use to make a +\codeinline{Asset} available from different scenes. \subsubsection{Architecture} -\Cref{fig:class-assetmanager} shows a class diagram of the AssetManager. It contains the following classes: +\Cref{fig:class-assetmanager} shows a class diagram of the AssetManager. It contains +the following classes:\noparbreak \begin{description} - \item[AssetManager] is a Singleton class, meaning only one instance of this class exists throughout the application. - This ensures a single point of access and control over asset management, simplifying resource handling and avoiding duplicated assets in memory. + \item[AssetManager] is a Singleton class, meaning only one instance of this class + exists throughout the application. This ensures a single point of access and + control over asset management, simplifying resource handling and avoiding + duplicated assets in memory. \end{description} \begin{figure} \centering - \includegraphics[width= 0.5\textwidth]{img/AssesManager.png} + % TODO: export as vector format instead + \includegraphics[width=0.5\textwidth]{img/AssesManager.png} \caption{User AssetManager class diagram} \label{fig:class-assetmanager} \end{figure} \subsection{Rendering} -Every game engine has an rendering structure to present all the different enities and components on the screen. + +Every game engine has an rendering structure to present all the different enities and +components on the screen. \subsubsection{Architecture} -\Cref{fig:class-rendering} shows a class diagram of the RenderSystem. It contains the following classes: - -\begin{itemize} - \item The system architecture is centered around rendering and component management, with the following key components: - \begin{enumerate} - \item \emph{System} - an interface class, containing the virtual \codeinline{update()} function. - \item \emph{RenderSystem} - a derived class of \codeinline{System} responsible for rendering operations. \end{enumerate} - \item The \codeinline{System::get_instance()} function provides a static, singleton instance for managing system-wide operations. - \item The \codeinline{RenderSystem} class implements various rendering functions: - \begin{itemize} - \item \codeinline{sort_layers()} - organizes the rendering layers. - \item \codeinline{clear_screen()} - clears the screen prior to rendering. - \item \codeinline{update_sprites()} - updates sprite positions and states. - \item \codeinline{update_camera()} - manages the camera view. - \item \codeinline{present_screen()} - presents the final rendered image to the screen. - \end{itemize} - \item The \emph{SdlContext} class, another singleton, manages the \gls(SDL) and has a friendship relationship with \codeinline{ComponentManager} - for tighter integration with component management. - \item Components are organized as follows: - \begin{itemize} - \item The \emph{Component} base class allows for generic handling of components. - \item Derived component classes include: - \begin{itemize} - \item \emph{Sprite} - represents visual elements with attributes like \codeinline{sprite}, - \codeinline{color}, \codeinline{flip}, \codeinline{sortingLayer}, and \codeinline{orderInLayer}. - \item \emph{Transform} - manages positional attributes, including \codeinline{position}, \codeinline{rotation}, and \codeinline{scale}. - \end{itemize} - \end{itemize} - \item Both \codeinline{Sprite} and \codeinline{Transform} components provide a \codeinline{get_instances_max()} function to retrieve the maximum instance count. + +% TODO: anyone read this? +\Cref{fig:class-rendering} shows a class diagram of the RenderSystem. It contains the +following classes:\noparbreak +\begin{itemize} + \item The system architecture is centered around rendering and component + management, with the following key components:\noparbreak + \begin{description} + \item[\codeinline{System}] An interface class containing the virtual + \codeinline{update()} function. + \item[\codeinline{RenderSystem}] A derived class of \codeinline{System} + responsible for rendering operations. + \end{description} + \item The \codeinline{System::get_instance()} function provides a static, singleton + instance for managing system-wide operations. + \item The \codeinline{RenderSystem} class implements various rendering + functions:\noparbreak + \begin{description} + \item[\codeinline{sort_layers()}] Organizes the rendering layers. + \item[\codeinline{clear_screen()}] Clears the screen prior to rendering. + \item[\codeinline{update_sprites()}] Updates sprite positions and states. + \item[\codeinline{update_camera()}] Manages the camera view. + \item[\codeinline{present_screen()}] Presents the final rendered image to the + 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. + \item Components are organized as follows:\noparbreak + \begin{itemize} + \item The \codeinline{Component} base class allows for generic handling of + components. + \item Derived component classes include:\noparbreak + \begin{description} + \item[\codeinline{Sprite}] Represents visual elements with attributes like + \codeinline{sprite}, \codeinline{color}, \codeinline{flip}, + \codeinline{sortingLayer}, and \codeinline{orderInLayer}. + \item[\codeinline{Transform}] Manages positional attributes, including + \codeinline{position}, \codeinline{rotation}, and \codeinline{scale}. + \end{description} + \end{itemize} + \item Both \codeinline{Sprite} and \codeinline{Transform} components provide a + \codeinline{get_instances_max()} function to retrieve the maximum instance count. \end{itemize} \begin{figure} \centering + % TODO: export as vector format instead \includegraphics[width=\textwidth]{img/Rendering.png} \caption{System Rendering class diagram} \label{fig:class-rendering} \end{figure} \subsubsection{System} + \begin{figure} \centering + % TODO: export as vector format instead \includegraphics[width=\textwidth]{img/flowchart_rendering.png} \caption{System Rendering flowchart } \label{fig:class-renderingflowchart} \end{figure} - % \subsection{Physics} \subsection{Scripting} @@ -386,36 +416,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. @@ -525,31 +555,38 @@ repository, under the \codeinline{src/example/audio_internal.cpp} file. \subsection{Camera} \label{poc:camera} -The camera \gls{poc} \autocite[camera example]{crepe:code-repo} consists of -the following:\noparbreak - +The camera \gls{poc} \autocite[camera example]{crepe:code-repo} consists of the +following:\noparbreak \begin{itemize} - \item An \codeinline{on_key_pressed} function, which listens for key presses and adjusts camera position and zoom based on key inputs. - \item A user-defined script class (\codeinline{MyCameraScript}) derived from \codeinline{Script}, implementing only the \codeinline{update()} function. - To update the camera movements and zoom. - \item A main function that— - \begin{itemize} - \item Subscribes the \codeinline{on_key_pressed} function to handle \codeinline{KeyPressedEvent} events. - \item Creates a \codeinline{GameObject} for the camera and adds \codeinline{Camera} and \codeinline{BehaviorScript} components, - with \codeinline{MyCameraScript} attached to manage the camera’s transformation. - \item Instantiates a background \codeinline{GameObject} with \codeinline{Transform} and \codeinline{Sprite} components, loading an external texture as its background. + \item An \codeinline{on_key_pressed} function, which listens for key presses and + adjusts camera position and zoom based on key inputs. + \item A user-defined script class (\codeinline{MyCameraScript}) derived from + \codeinline{Script}, implementing only the \codeinline{update()} function. To + update the camera movements and zoom. + \item A main function that--- + \begin{itemize} + \item Subscribes the \codeinline{on_key_pressed} function to handle + \codeinline{KeyPressedEvent} events. + \item Creates a \codeinline{GameObject} for the camera and adds + \codeinline{Camera} and \codeinline{BehaviorScript} components, with + \codeinline{MyCameraScript} attached to manage the camera's transformation. + \item Instantiates a background \codeinline{GameObject} with + \codeinline{Transform} and \codeinline{Sprite} components, loading an + external texture as its background. \end{itemize} \end{itemize} -Running this \gls{poc} allows for controlled camera movement and zoom in response to key inputs. The \codeinline{MyCameraScript::update} function ensures that these transformations are applied each frame, as demonstrated by the output in \cref{fig:poc-output-camera}. - - +Running this \gls{poc} allows for controlled camera movement and zoom in response to +key inputs. The \codeinline{MyCameraScript::update} function ensures that these +transformations are applied each frame, as demonstrated by the output in +\cref{fig:poc-output-camera}. \begin{figure} \centering \fitimg{\includegraphics[scale=0.7]{img/poc-camera.pdf}} - \caption{camera \glsfmtshort{poc} output} + \caption{Camera \glsfmtshort{poc} output} \label{fig:poc-output-camera} \end{figure} + \end{document} -- cgit v1.2.3 From aeab907956e93fd1b1acdd6fd2a92f94835a2c4c Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 3 Nov 2024 00:25:02 +0100 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index ba7d6ed..9a3df4c 100644 --- a/time.txt +++ b/time.txt @@ -93,6 +93,7 @@ loek: 2024-10-24 10m review :: PR review (#40, #41 and #42) loek: 2024-10-31 3h45m project meeting loek: 2024-10-31 2h50m docs :: design :: POCs loek: 2024-11-01 1h05m docs :: design (log POC & Global configuration interface) +loek: 2024-11-02 35m review :: PR review (#48 and #49) max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 862b9d90825855514092ba36053852ea7744ec23 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 3 Nov 2024 01:30:17 +0100 Subject: add full-size class diagram --- design.tex | 26 ++++++++++++++++++++++++++ img/class-api-full.pdf | Bin 0 -> 25055 bytes time.txt | 1 + 3 files changed, 27 insertions(+) create mode 100644 img/class-api-full.pdf diff --git a/design.tex b/design.tex index 6bef7dc..a208cd3 100644 --- a/design.tex +++ b/design.tex @@ -1,5 +1,7 @@ \documentclass{projdoc} +\usepackage{eso-pic} + \title{Software Design} \begin{document} @@ -765,5 +767,29 @@ transformations are applied each frame, as demonstrated by the output in \label{fig:poc-output-camera} \end{figure} +\makeatletter% +\newbox\full@class@diag% +\newlength\full@class@diag@width% +\newlength\full@class@diag@height% +\savebox\full@class@diag{\includegraphics{img/class-api-full.pdf}}% +\settowidth\full@class@diag@width{\usebox\full@class@diag}% +\settoheight\full@class@diag@height{\usebox\full@class@diag}% +\begingroup% +\eject% +\thispagestyle{empty}% +\pdfpagewidth=\full@class@diag@width% +\pdfpageheight=\full@class@diag@height% +\AddToShipoutPictureBG*{% + \AtPageUpperLeft{% + \raisebox{-\full@class@diag@height}{% + \usebox\full@class@diag% + }% + }% +}% +\section{Full API class diagram}% +\newpage% +\endgroup% +\makeatother% + \end{document} diff --git a/img/class-api-full.pdf b/img/class-api-full.pdf new file mode 100644 index 0000000..fb413df Binary files /dev/null and b/img/class-api-full.pdf differ diff --git a/time.txt b/time.txt index 9a3df4c..accf76b 100644 --- a/time.txt +++ b/time.txt @@ -94,6 +94,7 @@ loek: 2024-10-31 3h45m project meeting loek: 2024-10-31 2h50m docs :: design :: POCs loek: 2024-11-01 1h05m docs :: design (log POC & Global configuration interface) loek: 2024-11-02 35m review :: PR review (#48 and #49) +loek: 2024-11-03 55m docs :: design :: add full-size class diagram max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 561b9b8e5c2d377c17fa56121f1ed7c460a2d680 Mon Sep 17 00:00:00 2001 From: Jaro Date: Sun, 3 Nov 2024 09:47:37 +0100 Subject: added images --- img/ParticlePOC.png | Bin 0 -> 466 bytes img/collisionPOC1.png | Bin 0 -> 5316 bytes img/collisionPOC2.png | Bin 0 -> 4783 bytes 3 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 img/ParticlePOC.png create mode 100644 img/collisionPOC1.png create mode 100644 img/collisionPOC2.png diff --git a/img/ParticlePOC.png b/img/ParticlePOC.png new file mode 100644 index 0000000..85229c4 Binary files /dev/null and b/img/ParticlePOC.png differ diff --git a/img/collisionPOC1.png b/img/collisionPOC1.png new file mode 100644 index 0000000..550059b Binary files /dev/null and b/img/collisionPOC1.png differ diff --git a/img/collisionPOC2.png b/img/collisionPOC2.png new file mode 100644 index 0000000..1636bd2 Binary files /dev/null and b/img/collisionPOC2.png differ -- cgit v1.2.3 From b81399f199d7a1c2107813e2cb8865691e25c933 Mon Sep 17 00:00:00 2001 From: jaroWMR Date: Sun, 3 Nov 2024 13:55:00 +0100 Subject: Physics,Collison and particle systems added --- design.tex | 147 ++++++- figs.drawio | 806 ++++++++++++++++++++++++++++++++----- img/Collision_system.png | Bin 0 -> 53554 bytes img/Collision_system_flowchart.png | Bin 0 -> 28876 bytes img/Fixed_update.png | Bin 0 -> 11636 bytes img/ParticlePOC.png | Bin 466 -> 0 bytes img/Particle_system.png | Bin 0 -> 50497 bytes img/Particle_system_flowchart.png | Bin 0 -> 21084 bytes img/Physics_system.png | Bin 0 -> 44621 bytes img/Physics_system_flowchart.png | Bin 0 -> 8055 bytes img/class-api-full.pdf | Bin 25055 -> 64648 bytes img/collisionPOC1.png | Bin 5316 -> 0 bytes img/collisionPOC2.png | Bin 4783 -> 0 bytes img/poc-collision-1.png | Bin 0 -> 5316 bytes img/poc-collision-2.png | Bin 0 -> 4783 bytes img/poc-particles.png | Bin 0 -> 466 bytes 16 files changed, 848 insertions(+), 105 deletions(-) create mode 100644 img/Collision_system.png create mode 100644 img/Collision_system_flowchart.png create mode 100644 img/Fixed_update.png delete mode 100644 img/ParticlePOC.png create mode 100644 img/Particle_system.png create mode 100644 img/Particle_system_flowchart.png create mode 100644 img/Physics_system.png create mode 100644 img/Physics_system_flowchart.png delete mode 100644 img/collisionPOC1.png delete mode 100644 img/collisionPOC2.png create mode 100644 img/poc-collision-1.png create mode 100644 img/poc-collision-2.png create mode 100644 img/poc-particles.png 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 @@ -318,6 +322,13 @@ time. \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} @@ -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% diff --git a/figs.drawio b/figs.drawio index 8a9e7cd..f994fa8 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + @@ -259,57 +259,60 @@ - + - + + + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - - + + - + - + @@ -632,31 +635,31 @@ - + - + - + - + - + - + - + - + - + @@ -665,7 +668,7 @@ - + @@ -676,7 +679,7 @@ - + @@ -1172,7 +1175,7 @@ - + @@ -1192,7 +1195,7 @@ - + @@ -1212,7 +1215,7 @@ - + @@ -1352,11 +1355,11 @@ - + - + @@ -1371,31 +1374,31 @@ - + - + - + - + - + - + - + @@ -1408,13 +1411,13 @@ - + - + @@ -1489,186 +1492,597 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + + + + - + - + - + - + - + - + - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -1678,7 +2092,7 @@ - + @@ -1688,6 +2102,196 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/img/Collision_system.png b/img/Collision_system.png new file mode 100644 index 0000000..24f83f4 Binary files /dev/null and b/img/Collision_system.png differ diff --git a/img/Collision_system_flowchart.png b/img/Collision_system_flowchart.png new file mode 100644 index 0000000..ee43ddf Binary files /dev/null and b/img/Collision_system_flowchart.png differ diff --git a/img/Fixed_update.png b/img/Fixed_update.png new file mode 100644 index 0000000..2cacd48 Binary files /dev/null and b/img/Fixed_update.png differ diff --git a/img/ParticlePOC.png b/img/ParticlePOC.png deleted file mode 100644 index 85229c4..0000000 Binary files a/img/ParticlePOC.png and /dev/null differ diff --git a/img/Particle_system.png b/img/Particle_system.png new file mode 100644 index 0000000..89f7363 Binary files /dev/null and b/img/Particle_system.png differ diff --git a/img/Particle_system_flowchart.png b/img/Particle_system_flowchart.png new file mode 100644 index 0000000..09a9fd9 Binary files /dev/null and b/img/Particle_system_flowchart.png differ diff --git a/img/Physics_system.png b/img/Physics_system.png new file mode 100644 index 0000000..0e98b9e Binary files /dev/null and b/img/Physics_system.png differ diff --git a/img/Physics_system_flowchart.png b/img/Physics_system_flowchart.png new file mode 100644 index 0000000..f6238c0 Binary files /dev/null and b/img/Physics_system_flowchart.png differ diff --git a/img/class-api-full.pdf b/img/class-api-full.pdf index fb413df..2f49f99 100644 Binary files a/img/class-api-full.pdf and b/img/class-api-full.pdf differ diff --git a/img/collisionPOC1.png b/img/collisionPOC1.png deleted file mode 100644 index 550059b..0000000 Binary files a/img/collisionPOC1.png and /dev/null differ diff --git a/img/collisionPOC2.png b/img/collisionPOC2.png deleted file mode 100644 index 1636bd2..0000000 Binary files a/img/collisionPOC2.png and /dev/null differ diff --git a/img/poc-collision-1.png b/img/poc-collision-1.png new file mode 100644 index 0000000..550059b Binary files /dev/null and b/img/poc-collision-1.png differ diff --git a/img/poc-collision-2.png b/img/poc-collision-2.png new file mode 100644 index 0000000..1636bd2 Binary files /dev/null and b/img/poc-collision-2.png differ diff --git a/img/poc-particles.png b/img/poc-particles.png new file mode 100644 index 0000000..85229c4 Binary files /dev/null and b/img/poc-particles.png differ -- cgit v1.2.3 From 525f6fc8bfdcc898862aa45621a71d951df4f7ca Mon Sep 17 00:00:00 2001 From: heavydemon21 Date: Sun, 3 Nov 2024 15:14:24 +0100 Subject: final touches, cannot do latex svg image as TODO comment from @lonkars --- design.tex | 9 ++---- figs.drawio | 102 ++++++++++++++++++++++++++++++------------------------------ 2 files changed, 54 insertions(+), 57 deletions(-) diff --git a/design.tex b/design.tex index a208cd3..cb7532b 100644 --- a/design.tex +++ b/design.tex @@ -139,9 +139,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} @@ -220,9 +219,7 @@ following classes:\noparbreak \item[\codeinline{present_screen()}] Presents the final rendered image to the 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. + \item The \codeinline{SdlContext} class, another singleton, manages the \gls{sdl} library \item Components are organized as follows:\noparbreak \begin{itemize} \item The \codeinline{Component} base class allows for generic handling of diff --git a/figs.drawio b/figs.drawio index 8a9e7cd..8f22628 100644 --- a/figs.drawio +++ b/figs.drawio @@ -2882,125 +2882,125 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -3008,60 +3008,60 @@ - - + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + -- cgit v1.2.3 From 77fc5a21bdcb18b5ef4da1a898e556ff1a630a3f Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Sun, 3 Nov 2024 10:45:49 +0100 Subject: added poc description and updated uml diagram --- design.tex | 240 +++++++++++++++++++++++++++++++++++--------- img/custom-event-output.png | Bin 0 -> 2088 bytes img/event-uml.drawio.png | Bin 217362 -> 453179 bytes img/gameloop-console-10.png | Bin 0 -> 9313 bytes img/gameloop-console.png | Bin 0 -> 18235 bytes img/gameloop-squares.png | Bin 0 -> 5034 bytes img/poc-button.png | Bin 0 -> 4395 bytes img/poc-event-button.png | Bin 0 -> 4955 bytes 8 files changed, 192 insertions(+), 48 deletions(-) create mode 100644 img/custom-event-output.png create mode 100644 img/gameloop-console-10.png create mode 100644 img/gameloop-console.png create mode 100644 img/gameloop-squares.png create mode 100644 img/poc-button.png create mode 100644 img/poc-event-button.png diff --git a/design.tex b/design.tex index a208cd3..be69c8f 100644 --- a/design.tex +++ b/design.tex @@ -123,13 +123,11 @@ the main part of the \gls{ecs}. The design of these eight systems in combination A game loop is essential for maintaining a continuous flow of game actions, ensuring that updates to game logic, physics, and rendering occur in a synchronized manner. -Without a game loop, the game would lack consistent timing and leading to -unpredictable behavior. - -The game loop is mainly responsible for these 2 purposes:\noparbreak +Without a game loop, the game would lack consistent timing, leading to unpredictable +behavior. The game loop is primarily responsible for two main tasks:\noparbreak \begin{itemize} \item Updating all systems in the correct order - \item Making sure the gameloop timer is up to date + \item Ensuring the game loop timer remains accurate \end{itemize} The game loop can be external where the user has the ability to update the systems @@ -258,70 +256,70 @@ following classes:\noparbreak \label{fig:class-renderingflowchart} \end{figure} -\subsubsection{Design} +\subsubsection{Architecture} -The game loop of this engine is integrated into the engine, this is done for the -following reasons:\noparbreak +This engine uses an integrated game loop for the following reasons:\noparbreak \begin{description} - \item[Simplify development] The user only has to call \codeinline{startGame()}. - \item[Uniform system calls] The systems are always updated in the same order - limiting overwrites and undefined system behavior. - \item[Reliable timer update] Each cycle the game loop timer is always updated - limiting timing issues. + \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 gameloop is divided into different +As seen in \cref{fig:gameloop-flow}, the game loop consists of multiple steps:\noparbreak \begin{description} - \item[Update loop timer] The loop timer gets updated and the expected frame time is + \item[Update loop timer] The loop timer is updated, and the expected frame time is calculated. - \item[Check events] Queued events get dispatched and callback functions are handled - acordingly. - \item[Process input] The input system is called and user input is processed. - \item[Fixed update] A fixed loop for timing sensitive systems such as physics. - \item[Update] A per frame update for all per frame updates. - \item[Render] Calling the render system to render the frame. + \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} -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, -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. As seen in \cref{fig: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. - -The gamedeveloper start the game engine/game using the code example below:\noparbreak +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. + +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 +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} -This starts calls the setup() and loop() functions and starts the game loop timer; To -get the current frames' delta time, the \codeinline{getDeltaTime()} method on the -\codeinline{LoopTimer} singleton can be used, which will return the expected frame -time. +% 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{Gameloop Flowchart Diagram} + \caption{Game loop flowchart diagram} \label{fig:gameloop-flow} \end{figure} \begin{figure} \centering \includepumldiag{img/gameloop-class.puml} - \caption{Gameloop Flowchart Diagram} + \caption{Gameloop flowchart diagram} \label{fig:gameloop-class} \end{figure} @@ -386,11 +384,18 @@ as:\noparbreak event is triggered a specific derived class must be used to indicate which event is triggered. A reference to this event is then transfered to all callback functions subscribed. + \item[IKeyListener] This is an interface designed to match the API. By deriving + from this interface the game developer can override the key event functions to + add their own functionality. The derived class will immediately be subscribed to + the EventManager and will Unsubscibe when deleted. + \item[IMouseListener] Like the IKeyListener this is also an interface to interact + with the eventManager. The derived classes from this interface handle various + mouse related events. These events are triggered when the mouse is + clicked/pressed/released or moved. \end{description} -The EventManager is a singleton so all all callbacks are stored in one place and it -can be called everywhere in the system or game. The user can use the EventManager for -the following functions:\noparbreak +The gamedeveloper can interact with the EventManager using the following +functions:\noparbreak \begin{description} \item[Subscribe] This subscribes a function pointer or lambda function to a given event. The function can be subscribed either to all event triggers or a specifc @@ -731,6 +736,145 @@ was later converted to a full audio \gls{facade}, which is currently part of the cr\^epe engine. The \gls{poc} using the audio \gls{facade} is available from the same repository, under the \codeinline{src/example/audio_internal.cpp} file. +\subsection{Gameloop} +\label{poc:gameloop} + +\begin{figure} + \centering + \includegraphics[scale=0.4]{img/gameloop-squares.png} + \caption{Gameloop running example} + \label{fig:poc-gameloop-squares} +\end{figure} + +This \gls{poc} shows the functionality of the different loops and the approaches to +decouple the updates from the framerate. \Cref{fig:poc-gameloop-squares} shows two +squares that keep moving at the same speed no matter how high or low the framerate +gets. This is done by updating the squares in the per frame update loop with the +delta time generated by the timer. By multipling deltaTime to the velocity of the +square the velocity is converted to a time instead of frames. this can be seen in de +following code example\noparbreak +\begin{blockcode} +float delta = timer.getDeltaTime(); // get delta time of current frame + if (obj->direction == 1) { + obj->setX(obj->getX() + 50 * delta); // multiply velocity by delta time for consistent behavior. + } else { + obj->setX(obj->getX() - 50 * delta); + } +\end{blockcode} + +The second functionality this \gls{poc} shows is how the fixed loop is executed. +Based on the framerate of the gameloop the fixed loop is executed multiple times per +frame or skips a certain amount of frames as seen in +\cref{fig:poc-gameloop-500fps,fig:poc-gameloop-10fps}. + +\begin{figure} + \centering + \begin{subfigure}[b]{0.45\textwidth} + \centering + \includegraphics[scale=0.5]{img/gameloop-console.png} + \caption{Fixed loop (50Hz) with 500 fps} + \label{fig:poc-gameloop-500fps} + \end{subfigure} + \hfill + \begin{subfigure}[b]{0.45\textwidth} + \centering + \includegraphics[scale=0.5]{img/gameloop-console-10.png} + \caption{Fixed loop (50Hz) with 10 fps} + \label{fig:poc-gameloop-10fps} + \end{subfigure} + \caption{Comparison of game loop performance at different frame rates} + \label{fig:poc-gameloop-console-comparison} +\end{figure} + +\subsection{Events/input system} +\label{poc:event} + +\begin{figure} + \centering + \includegraphics[scale=0.4]{img/poc-button.png} + \caption{Gameloop running example} + \label{fig:poc-event} +\end{figure} + +The event/input system \gls{poc} shows the different ways the event system can be +used. It also serves as a basis on which the input system is developed. the first two +features show the workings of the two interfaces which are created so the game +developer doesnt need to subscribe each function individualy. The gamedeveloper only +needs to create a derived class from the parent IKeyListener or IMouseListener and +override the functions with their own implementation as shown below.\noparbreak +\begin{description} + \item[KeyListener] \codeinline{KeyListenerTest keyListener(testListenerId);} this + line creates a concrete KeyListener that has been created as follows. + \begin{blockcode} + class KeyListenerTest : public IKeyListener { + public: + KeyListenerTest(int listenerId); + ~KeyListenerTest(); + + void onKeyPressed(const KeyPressedEvent& event) override; + void onKeyReleased(const KeyReleasedEvent& event) override; + }; + \end{blockcode} + The functions have been overridden to add custom functionality, which is called + when a key is pressed or released. + \item[MouseListener] Like the KeyListener, \codeinline{MouseListenerTest + mouseListener(testListenerId);} is a concrete derived class of IMouseListener, + created as follows:\noparbreak + \begin{blockcode} + class MouseListenerTest : public IMouseListener { + public: + MouseListenerTest(int listenerId); + ~MouseListenerTest(); + + void onMouseClicked(const MouseClickEvent& event) override; + void onMousePressed(const MousePressedEvent& event) override; + void onMouseReleased(const MouseReleasedEvent& event) override; + void onMouseMoved(const MouseMovedEvent& event) override; + }; + \end{blockcode} +\end{description} + +Secondly the \gls{poc} shows how the gamedeveloper can create custom events by +creating a derived class from the parent class Event. This custom event can then be +used to subscribe callbacks to which can use the data within the derived class. Below +is an example of such a custom event.\noparbreak +\begin{blockcode} +class PlayerDamagedEvent : public Event { +public: + PlayerDamagedEvent(int damage, int playerID) + : Event("PlayerDamaged"), damage(damage), playerID(playerID) {} + + REGISTER_EVENT_TYPE(PlayerDamagedEvent); + + int getDamage() const { return damage; } + int getPlayerID() const { return playerID; } + +private: + int damage; + int playerID; +}; +\end{blockcode} + +An example of a callback function using the custom PlayerDamagedEvent:\noparbreak +\begin{blockcode} +void onPlayerDamaged(const PlayerDamagedEvent & e) { + std::cout << "Player " << e.getPlayerID() << " took " << e.getDamage() + << " damage." << std::endl; +} +\end{blockcode} + +Lastly the \gls{poc} shows how a button can be handled using a input sytem. The blue +square in \cref{poc:event} represents a button component which will call its +onClick() function when the mouse click event triggers within its boundary. The +result can be seen in \cref{fig:poc-event-button}. + +\begin{figure} + \centering + \includegraphics[scale=1]{img/poc-event-button.png} + \caption{gameloop running example} + \label{fig:poc-event-button} +\end{figure} + \subsection{Camera} \label{poc:camera} diff --git a/img/custom-event-output.png b/img/custom-event-output.png new file mode 100644 index 0000000..f818293 Binary files /dev/null and b/img/custom-event-output.png differ diff --git a/img/event-uml.drawio.png b/img/event-uml.drawio.png index 9eab458..008dd85 100644 Binary files a/img/event-uml.drawio.png and b/img/event-uml.drawio.png differ diff --git a/img/gameloop-console-10.png b/img/gameloop-console-10.png new file mode 100644 index 0000000..af0cd71 Binary files /dev/null and b/img/gameloop-console-10.png differ diff --git a/img/gameloop-console.png b/img/gameloop-console.png new file mode 100644 index 0000000..a675fae Binary files /dev/null and b/img/gameloop-console.png differ diff --git a/img/gameloop-squares.png b/img/gameloop-squares.png new file mode 100644 index 0000000..6481c7e Binary files /dev/null and b/img/gameloop-squares.png differ diff --git a/img/poc-button.png b/img/poc-button.png new file mode 100644 index 0000000..633ea99 Binary files /dev/null and b/img/poc-button.png differ diff --git a/img/poc-event-button.png b/img/poc-event-button.png new file mode 100644 index 0000000..7d3b546 Binary files /dev/null and b/img/poc-event-button.png differ -- cgit v1.2.3 From 537eac615fd768935bcd4f5bb47d3864ea5dc577 Mon Sep 17 00:00:00 2001 From: jaroWMR Date: Fri, 1 Nov 2024 15:47:40 +0100 Subject: update time --- time.txt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/time.txt b/time.txt index accf76b..a0d8664 100644 --- a/time.txt +++ b/time.txt @@ -332,7 +332,14 @@ jaro: 2024-10-24 1h20m project meeting jaro: 2024-10-24 3h30m physics and collision jaro: 2024-10-24 1h static collision handeling jaro: 2024-10-25 2h collision handeling and onderzoek collision event unity - +jaro: 2024-10-28 2h30m Mergen rendering + events +jaro: 2024-10-29 4h Physics,collision design + latex +jaro: 2024-10-30 2h diagrams design +jaro: 2024-10-31 30m discusing design questions +jaro: 2024-10-31 3h30m discusing design questions +jaro: 2024-10-31 1h changing diagrams +jaro: 2024-10-31 45m adding diagrams physics,collision,particles +jaro: 2024-11-1 15m weeklyupdate -- cgit v1.2.3 From 2022665a8fe783514e25cd753b569b23deb46ebe Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Sun, 3 Nov 2024 11:20:01 +0100 Subject: added ui/event/gameloop to uml --- figs.drawio | 1147 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 1123 insertions(+), 24 deletions(-) diff --git a/figs.drawio b/figs.drawio index 8a9e7cd..d62252c 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + - + @@ -782,7 +782,7 @@ - + @@ -799,31 +799,43 @@ - + - - + + - - + + + + + + + + + + + + + + - + - + - + - + @@ -832,7 +844,7 @@ - + @@ -841,24 +853,16 @@ - + - - - - - + - - - - - + @@ -1229,6 +1233,121 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -3383,4 +3502,984 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit v1.2.3 From 324602e153b052afe0b4b5ae15b25310f5aa6d9f Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 3 Nov 2024 16:17:07 +0100 Subject: wrap lines --- design.tex | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/design.tex b/design.tex index 37428b1..3ec077b 100644 --- a/design.tex +++ b/design.tex @@ -137,8 +137,8 @@ reliability. \subsection{Texture} -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. +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} @@ -217,7 +217,8 @@ following classes:\noparbreak \item[\codeinline{present_screen()}] Presents the final rendered image to the screen. \end{description} - \item The \codeinline{SdlContext} class, another singleton, manages the \gls{sdl} library + \item The \codeinline{SdlContext} class, another singleton, manages the \gls{sdl} + library \item Components are organized as follows:\noparbreak \begin{itemize} \item The \codeinline{Component} base class allows for generic handling of -- cgit v1.2.3 From 52e028a655383289e7473737b20c3cd1a49de303 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 3 Nov 2024 16:20:20 +0100 Subject: update time.txt --- time.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/time.txt b/time.txt index a0d8664..0938b5a 100644 --- a/time.txt +++ b/time.txt @@ -95,6 +95,8 @@ loek: 2024-10-31 2h50m docs :: design :: POCs loek: 2024-11-01 1h05m docs :: design (log POC & Global configuration interface) loek: 2024-11-02 35m review :: PR review (#48 and #49) loek: 2024-11-03 55m docs :: design :: add full-size class diagram +loek: 2024-11-03 1h30m implementation :: save manager +loek: 2024-11-03 55m review :: PR review (#15, #50, #52) max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 1bb040a091623b3867489fe85e75d1f035f16a43 Mon Sep 17 00:00:00 2001 From: heavydemon21 Date: Sun, 3 Nov 2024 16:31:02 +0100 Subject: hours --- time.txt | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/time.txt b/time.txt index a0d8664..c343f06 100644 --- a/time.txt +++ b/time.txt @@ -268,6 +268,11 @@ niels: 2024-10-25 2h researching camera niels: 2024-10-26 2h merge wouter events branch to niels/rendering niels: 2024-10-26 1h fix my own git camera mistake niels: 2024-10-26 2h programming camera poc with movement and script +niels: 2024-10-29 2h30m Helping Jaro with events +niels: 2024-10-30 3h fixing camera SDL viewort bug +niels: 2024-10-31 3h45m meeting +niels: 2024-11-2 3h design document, diagrams and flowcharts +niels: 2024-11-3 1h design document, diagrams and flowcharts jaro: 2024-09-02 1h project meeting :: project kickoff jaro: 2024-09-02 45m project meeting -- cgit v1.2.3 From e300c7fb3cdc1c27bd246376cf79b820d541279f Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 3 Nov 2024 16:31:03 +0100 Subject: merge #53 (#51) --- design.tex | 129 +++++++++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 95 insertions(+), 34 deletions(-) diff --git a/design.tex b/design.tex index cdfa6cf..23bdf5b 100644 --- a/design.tex +++ b/design.tex @@ -284,10 +284,17 @@ 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. - +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. @@ -430,17 +437,23 @@ using the callback(eventHandler) is executed. \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. - +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 + +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} + \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}} @@ -449,7 +462,12 @@ The \emph{PhysicsSystem} is a system and therefor a singleton in this engine. Be \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}. + +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 @@ -460,15 +478,24 @@ The physics system is not a complex system. It works in three steps. It will req \subsection{Collisions} -The Collisions in the game engine are handled by the \emph{CollisionSystem}. This system check if a collider collided with another collider. +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 + +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. + \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}. @@ -480,7 +507,13 @@ This is shown in \cref{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. + +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 @@ -489,19 +522,25 @@ The collision system is complex compared to other systems. This is shown in the \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. +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 + +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[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} @@ -512,16 +551,20 @@ This is shown in \cref{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. + +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} + \label{fig:particle-system-flowchart} \end{figure} - \subsection{Scripting} The scripting interface was designed around a `target' \gls{api} (described by @@ -1015,9 +1058,16 @@ transformations are applied each frame, as demonstrated by the output in \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. +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). +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 @@ -1029,11 +1079,22 @@ This \gls{poc} showed that pooling is a must, even with lower amounts of particl \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.. +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 -- cgit v1.2.3 From 03bbc565e08ca6b759bea9fa818b394bb0ff2923 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 3 Nov 2024 16:31:42 +0100 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index 0938b5a..81cfac2 100644 --- a/time.txt +++ b/time.txt @@ -97,6 +97,7 @@ loek: 2024-11-02 35m review :: PR review (#48 and #49) loek: 2024-11-03 55m docs :: design :: add full-size class diagram loek: 2024-11-03 1h30m implementation :: save manager loek: 2024-11-03 55m review :: PR review (#15, #50, #52) +loek: 2024-11-03 10m review :: PR review (#53) max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 548e24ef159cd5f8d82a2460146c5d33356d0f7f Mon Sep 17 00:00:00 2001 From: jaroWMR Date: Sun, 3 Nov 2024 17:19:46 +0100 Subject: Removed old placeholder --- figs.drawio | 118 ++++++++++++++++++++++--------------------------- img/class-api-full.pdf | Bin 64648 -> 73613 bytes 2 files changed, 52 insertions(+), 66 deletions(-) diff --git a/figs.drawio b/figs.drawio index 6114e52..3e0d2f3 100644 --- a/figs.drawio +++ b/figs.drawio @@ -1,6 +1,6 @@ - + - + @@ -544,20 +544,6 @@ - - - - - - - - - - - - - - @@ -3605,125 +3591,125 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -3732,59 +3718,59 @@ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + diff --git a/img/class-api-full.pdf b/img/class-api-full.pdf index 2f49f99..cd28b08 100644 Binary files a/img/class-api-full.pdf and b/img/class-api-full.pdf differ -- cgit v1.2.3 From 52f3ef6d1b6d794098deffc3294653b5f1aad742 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Mon, 4 Nov 2024 08:29:26 +0100 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index ec3fb36..d03feed 100644 --- a/time.txt +++ b/time.txt @@ -98,6 +98,7 @@ loek: 2024-11-03 55m docs :: design :: add full-size class diagram loek: 2024-11-03 1h30m implementation :: save manager loek: 2024-11-03 55m review :: PR review (#15, #50, #52) loek: 2024-11-03 10m review :: PR review (#53) +loek: 2024-11-04 20m implementation :: save manager max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3 From 7ff5dd129c2708086c536d6f258e1cf54d2a7293 Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Mon, 4 Nov 2024 10:01:42 +0100 Subject: notules + design fix --- design.tex | 187 +++++++++++++++++++++++++++++++------------------------------ 1 file changed, 96 insertions(+), 91 deletions(-) diff --git a/design.tex b/design.tex index 23bdf5b..e5a7a91 100644 --- a/design.tex +++ b/design.tex @@ -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 -- cgit v1.2.3 From 1502a7fa2325763d3b752ea7e2fece706dffe13d Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Mon, 4 Nov 2024 10:06:05 +0100 Subject: fix spaces --- design.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/design.tex b/design.tex index e5a7a91..3f91893 100644 --- a/design.tex +++ b/design.tex @@ -994,8 +994,8 @@ public: REGISTER_EVENT_TYPE(PlayerDamagedEvent); - int getDamage() const { return damage; } - int getPlayerID() const { return playerID; } + int getDamage() const { return damage; } + int getPlayerID() const { return playerID; } private: int damage; @@ -1128,7 +1128,7 @@ back if the collided with anything. \pdfpagewidth=\full@class@diag@width% \pdfpageheight=\full@class@diag@height% \AddToShipoutPictureBG*{% - \AtPageUpperLeft{% + \AtPageUpperLeft{% \raisebox{-\full@class@diag@height}{% \usebox\full@class@diag% }% -- cgit v1.2.3 From e696e7a6ac438c4af2e3d597c12950ad72b88520 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Mon, 4 Nov 2024 12:58:39 +0100 Subject: update time.txt --- time.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time.txt b/time.txt index d03feed..afc9ec2 100644 --- a/time.txt +++ b/time.txt @@ -99,6 +99,7 @@ loek: 2024-11-03 1h30m implementation :: save manager loek: 2024-11-03 55m review :: PR review (#15, #50, #52) loek: 2024-11-03 10m review :: PR review (#53) loek: 2024-11-04 20m implementation :: save manager +loek: 2024-11-04 4h project meeting max: 2024-09-02 1h project kickoff max: 2024-09-02 45m first project meeting -- cgit v1.2.3