diff options
| -rw-r--r-- | img/decorator-design-pattern.puml | 62 | ||||
| -rw-r--r-- | img/theme.ipuml | 9 | ||||
| -rw-r--r-- | research.tex | 93 | ||||
| -rw-r--r-- | sources.bib | 97 |
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} } + |