aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLoek Le Blansch <loek@pipeframe.xyz>2024-09-18 20:51:55 +0200
committerLoek Le Blansch <loek@pipeframe.xyz>2024-09-18 20:51:55 +0200
commit7dc00a616e186bb8b02902e06b7cb38164acbbbd (patch)
tree081bae74afdc0ffe0e5696b20f90062f3274d680
parentc69c8815df1c0e1e6ef155a9cfc4747132e0e1c6 (diff)
merge #15
-rw-r--r--img/decorator-design-pattern.puml62
-rw-r--r--img/theme.ipuml9
-rw-r--r--research.tex93
-rw-r--r--sources.bib97
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}
}
+