merge #15

4 files changed, 169 insertions, 92 deletions

diff --git a/img/decorator-design-pattern.puml b/img/decorator-design-pattern.puml
new file mode 100644
index 0000000..2bc406b
--- /dev/null
+++ b/img/decorator-design-pattern.puml
@@ -0,0 +1,62 @@
+@startuml
+!include theme.ipuml
+skinparam style strictuml
+skinparam Linetype ortho
+
+class Client
+class Component <<interface>> {
+	+ execute()
+	--
+}
+class ConcComponent as "Concrete\nComponent" {
+	...
+	--
+	+ execute()
+}
+class BaseDecorator as "Base Decorator" {
+	- wrappee: Component
+	+ BaseDecorator(c: Component)
+	+ execute()
+}
+class ConcDecorator as "Concrete\nDecorators" {
+	...
+	--
+	+ execute()
+	+ extra()
+}
+
+hide Client members
+hide circle
+
+Client --> Component
+Component <|.. ConcComponent
+Component <|.. BaseDecorator
+Component <--o BaseDecorator
+BaseDecorator <|-- ConcDecorator
+
+ConcComponent -right[hidden] BaseDecorator
+
+note right of Client
+	a = <b>new</b> ConcComponent()
+	b = <b>new</b> ConcDecorator1(a)
+	c = <b>new</b> ConcDecorator1(b)
+	c.execute()
+	// Decorator -> Decorator -> Component
+end note
+
+note right of BaseDecorator::BaseDecorator
+	wrappee = c
+end note
+
+note right of BaseDecorator::execute
+	wrappee.execute()
+end note
+
+note right of ConcDecorator::execute
+	super::execute()
+	extra()
+end note
+
+@enduml
+
+" referenced from <https://github.com/algamza/algamza.github.io>
diff --git a/img/theme.ipuml b/img/theme.ipuml
index 88d183a..4e3613e 100644
--- a/img/theme.ipuml
+++ b/img/theme.ipuml
@@ -1,5 +1,10 @@
 !theme plain
-skinparam DefaultFontSize 14
+skinparam ClassAttributeIconSize 0
+skinparam ClassFontStyle bold
 skinparam DefaultFontName Inter
+skinparam DefaultFontSize 14
+skinparam MaxMessageSize 200
+skinparam Nodesep 25
+skinparam Padding 2
+skinparam Ranksep 50
 skinparam RoundCorner 0
-skinparam maxMessageSize 200
diff --git a/research.tex b/research.tex
index 1ca5a2e..e07a428 100644
--- a/research.tex
+++ b/research.tex
@@ -52,8 +52,9 @@ layers are divided into the following categories:\noparbreak
 \subsubsection{Structures}
 
 The above mentioned layers should be structured, somehow. One of the requirements is
-that the game engine's API uses a so-called gameObject (with one or more component(s)).
-The gameObject is described in more detail at \cref{sec:Gameobjects/components}.
+that the game engine's API uses a so-called gameObject (with one or more
+component(s)). The gameObject is described in more detail at
+\cref{sec:Gameobjects/components}.
 
 There are multiple structures that could be used to structure a game engine. It's of
 course possible to use inheritance. A major disadvantages of inheritance is that it's
@@ -61,54 +62,62 @@ not flexible. However, the provided class diagram of the game engine's API alrea
 specifies that composition should be used (in stead of inheritance). So, let's take a
 look at structures that use composition.
 
-The Decorator design pattern (as shown in \cref{fig:decorator}) could be used to structure
-the game engine. A gameObject's propperties/behavior is determined by one (or more)
-components. The Decorator design pattern allows to modify an object's propperties/behavior
-by adding one (or more) Decorators. The object that is modified, could be the gameObject and
-the components could be the Decorators. This is not exactly the same as the required API,
-but it's very close. A major disadvantage of such Decorator design pattern, is that the
-interface of all components should be the same (they should share the same methods), because
-the client (which is the scene in our case) can only call/reach the components through the
-interface. This would require very general methods (at the interface), which might make the
-programming harder. \autocite{man:DecoratorDesignPattern} \autocite{man:Decorator}
-\begin{figure}[H]
-    \centering
-    \includegraphics[width=0.5\textwidth]{img/DecoratorDesignPattern.png}
-    \caption{Decorator design pattern \autocite{img:Decorator}}
-    \label{fig:decorator}
+The Decorator design pattern (as shown in \cref{fig:decorator}) could be used to
+structure the game engine. A gameObject's propperties/behavior is determined by one
+(or more) components. The Decorator design pattern allows to modify an object's
+propperties/behavior by adding one (or more) Decorators. The object that is modified,
+could be the gameObject and the components could be the Decorators. This is not
+exactly the same as the required API, but it's very close. A major disadvantage of
+such Decorator design pattern, is that the interface of all components should be the
+same (they should share the same methods), because the client (which is the scene in
+our case) can only call/reach the components through the interface. This would
+require very general methods (at the interface), which might make the programming
+harder \autocite{man:DecoratorDesignPattern,man:Decorator}.
+
+\begin{figure}
+	\centering
+	\includepumldiag{img/decorator-design-pattern.puml}
+	\caption{Decorator design pattern}
+	Source: \autocite{img:Decorator}
+	\label{fig:decorator}
 \end{figure}
 
 TODO: Add Extension Objects design pattern (if this is applicable)!
 
-Another (very popular) design pattern to structure the game engine, is the Entity Component
-System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems, namely entities,
-components and systems. Entities are just IDs. An entity is made out of a gameObject and one
-(or more) components. Components are the classes that hold the data. The components determine
-what kind of entity it is (e.g. a sprite, 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).
-TODO: Continue this explanation (also add some diagrams to make the ECS more clear)!
+Another (very popular) design pattern to structure the game engine, is the Entity
+Component System (\gls{ecs}). The \gls{ecs} is made out of three main subsystems,
+namely entities, components and systems. Entities are just IDs. An entity is made out
+of a gameObject and one (or more) components. Components are the classes that hold
+the data. The components determine what kind of entity it is (e.g. a sprite, 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).
+
+% TODO: Continue this explanation (also add some diagrams to make the ECS more clear)!
 
 There are many C/C++ libraries available, completely dedicated to \gls{ecs}. The most
-popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is based
-on the amount of stars on GitHub.
-\begin{table}[ht]
-    \centering
-    \begin{tabular}{ll@{\qquad}lr}
-        \toprule
-        \textbf{Name} & \textbf{Short Description} & \textbf{Stars} & \textbf{License} \\
-        \midrule
-        EnTT & Fast and reliable entity-component system & 10k & MIT \\
-        Flecs & A Multithreaded Entity Component System & 6.3k & MIT \\
-        EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT \\
-        \bottomrule
-    \end{tabular}
-    \caption{Popular \gls{ecs} libraries \autocite{github:001}}
-    \label{tab:popularECSLibraries}
+popular libraries are shown in \cref{tab:popularECSLibraries}. The popularity is
+based on the amount of stars on GitHub.
+
+\begin{table}
+	\centering
+	\begin{tabular}{ll@{\qquad}lr}
+		\toprule
+		\textbf{Name} & \textbf{Short Description} & \textbf{Stars} & \textbf{License}\\
+		\midrule
+		EnTT & Fast and reliable entity-component system & 10k & MIT\\
+		Flecs & A Multithreaded Entity Component System & 6.3k & MIT\\
+		EntityX & Fast, type-safe C++ entity component system & 2.2k & MIT\\
+		\bottomrule
+	\end{tabular}
+	\caption{Popular \gls{ecs} libraries}
+	Source: \autocite{github:awesome-ecs}
+	\label{tab:popularECSLibraries}
 \end{table}
 
-It is, of course, not necessary to use a library to implement an \gls{ecs} architecture.
-However, it seems very hard to achieve the same performance as a library. \autocite{github:002}
+It is, of course, not necessary to use a library to implement an \gls{ecs}
+architecture. However, it seems very hard to achieve the same performance as a
+library \autocite{github:ecsfaq}.
 
 \subsection{Conclusion}
 
diff --git a/sources.bib b/sources.bib
index e754959..bf04165 100644
--- a/sources.bib
+++ b/sources.bib
@@ -13,89 +13,90 @@
 }
 
 @misc{miro:scrum-board,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Scrum Board on Miro},
-  url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Scrum Board on Miro},
+	url = {https://miro.com/app/board/uXjVKjtdM64=/?share_link_id=303851465474},
+	date = {2024-09-10},
 }
 
 @misc{crepe:code-repo,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Code Repository},
-  url = {https://github.com/lonkaars/crepe},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Code Repository},
+	url = {https://github.com/lonkaars/crepe},
+	date = {2024-09-10},
 }
 
 @misc{crepe:docs-repo,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Documentation Repository},
-  url = {https://github.com/lonkaars},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Documentation Repository},
+	url = {https://github.com/lonkaars},
+	date = {2024-09-10},
 }
 
 @misc{crepe:docs-standard,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Documentation Standard},
-  url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Documentation Standard},
+	url = {https://github.com/lonkaars/crepe-docs/blob/master/contributing.md},
+	date = {2024-09-10},
 }
 
 @misc{crepe:code-standard,
-  author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
-  title = {Crepe Code Standard},
-  url = {https://github.com/lonkaars/crepe/blob/master/contributing.md},
-  date = {2024-09-10},
+	author = {Loek Le Blansch and Wouter Boerenkamps and Jaro Rutjes and Max Smits and Niels Stunnebrink},
+	title = {Crepe Code Standard},
+	url = {https://github.com/lonkaars/crepe/blob/master/contributing.md},
+	date = {2024-09-10},
 }
 
-@misc{github:001,
-  author = {Sangjun Lee},
-  title = {Awesome Entity Component System},
-  url = {https://github.com/jslee02/awesome-entity-component-system?tab=readme-ov-file},
+@misc{github:awesome-ecs,
+	author = {Sangjun Lee},
+	title = {Awesome Entity Component System},
+	url = {https://github.com/jslee02/awesome-entity-component-system?tab=readme-ov-file},
 	date = {2023}
 }
 
-@misc{github:002,
-  author = {Sander Mertens},
-  title = {ECS FAQ},
-  url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs},
+@misc{github:ecsfaq,
+	author = {Sander Mertens},
+	title = {ECS FAQ},
+	url = {https://github.com/SanderMertens/ecs-faq?tab=readme-ov-file#should-i-write-my-own-ecs},
 	date = {2023}
 }
 
 @manual{man:unityGameobjects,
 	title = {GameObject},
 	author = {Unity Technologies},
-  organization = {Unity},
-  url = {https://docs.unity3d.com/Manual/GameObjects.html},
+	organization = {Unity},
+	url = {https://docs.unity3d.com/Manual/GameObjects.html},
 	date = {2024}
 }
 
 @manual{man:unityTransformClass,
-  title = {Transform Class},
-  author = {Unity Technologies},
-  organization = {Unity},
-  url = {https://docs.unity3d.com/Manual/class-Transform.html},
-  date = {2024}
+	title = {Transform Class},
+	author = {Unity Technologies},
+	organization = {Unity},
+	url = {https://docs.unity3d.com/Manual/class-Transform.html},
+	date = {2024}
 }
 
 @misc{img:Decorator,
-  title = {Decorator Pattern Structure Diagram},
-  author = {Refactoring Guru},
-  url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png},
-  date = {2024}
+	title = {Decorator Pattern Structure Diagram},
+	author = {Refactoring Guru},
+	url = {https://refactoring.guru/images/patterns/diagrams/decorator/structure.png},
+	date = {2024}
 }
 
 @manual{man:DecoratorDesignPattern,
-  title = {Extension Object Design Pattern},
-  author = {James Fawcett},
-  organization = {Syracuse University},
-  url = {https://ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/ExtensionObject.pdf},
-  date = {2024}
+	title = {Extension Object Design Pattern},
+	author = {James Fawcett},
+	organization = {Syracuse University},
+	url = {https://ecs.syr.edu/faculty/fawcett/handouts/CSE776/PatternPDFs/ExtensionObject.pdf},
+	date = {2024}
 }
 
 @manual{man:Decorator,
-  title = {Decorator Design Pattern},
-  author = {Refactoring Guru},
+	title = {Decorator Design Pattern},
+	author = {Refactoring Guru},
 	organization = {Refactoring Guru},
-  url = {https://refactoring.guru/design-patterns/decorator},
-  date = {2024}
+	url = {https://refactoring.guru/design-patterns/decorator},
+	date = {2024}
 }
+