From cf7a38d87164a9be78efd8c045acd43422a1be04 Mon Sep 17 00:00:00 2001 From: WBoerenkamps Date: Sat, 26 Oct 2024 08:51:31 +0200 Subject: design gameloop, design --- img/event-uml.drawio.png | Bin 0 -> 217362 bytes img/gameloop-class.puml | 35 +++++++++++++++++++++++++++++++++++ img/gameloop-flow.puml | 27 +++++++++++++++++++++++++++ 3 files changed, 62 insertions(+) create mode 100644 img/event-uml.drawio.png create mode 100644 img/gameloop-class.puml create mode 100644 img/gameloop-flow.puml (limited to 'img') 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(-) (limited to 'img') 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 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(-) (limited to 'img') 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 (limited to 'img') 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 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 (limited to 'img') 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 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 (limited to 'img') 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 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 (limited to 'img') 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 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 (limited to 'img') 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 (limited to 'img') 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 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 (limited to 'img') 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 (limited to 'img') 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 (limited to 'img') 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 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 (limited to 'img') 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 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(-) (limited to 'img') 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