diff options
| -rw-r--r-- | img/DecoratorDesignPattern.png | bin | 0 -> 13528 bytes | |||
| -rw-r--r-- | research.tex | 86 | ||||
| -rw-r--r-- | sources.bib | 51 |
3 files changed, 117 insertions, 20 deletions
diff --git a/img/DecoratorDesignPattern.png b/img/DecoratorDesignPattern.png Binary files differnew file mode 100644 index 0000000..8830a3d --- /dev/null +++ b/img/DecoratorDesignPattern.png diff --git a/research.tex b/research.tex index ad33d10..052a5b2 100644 --- a/research.tex +++ b/research.tex @@ -44,14 +44,43 @@ layers are divided into the following categories:\noparbreak performance profiling. \item[Scripting layer] Runs scripts, such as Lua or Python. \item[Memory systems] Handles and monitors memory usage. - \item[\gls{ecs}] Provides a modular way to create game objects, add physics, and - define how the engine interacts with objects. \item[Physics] Adds specific physics to objects. \item[Audio] Processes audio. \item[AI] Provides artificial inteligent behavior. \end{description} -\subsubsection{ECS} +\subsubsection{Structure} + +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}. + +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 +not flexible. However, the provided class diagram of the game engine's API already +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} +\end{figure} + +Another very popular design pattern, is the Entity Component System (\gls{ecs}). ... + +\paragraph{ECS} A game engine must have the ability to keep track and update several game objects. To do this most game engines employ an \gls{ecs} model which uses modulair components to @@ -66,9 +95,28 @@ must be stored efficiently, and entities must be provided with the required beha such as audio, position, or physics. To create diverse entities with specific functions: A scene can contain many different kinds of entities, each with different properties and functions. But no matter how different each entity is, it remains an -entity. To assign properties and functions to entities, components are used. Entt is -an example of an \gls{ecs}. -% TODO: ref?entt +entity. To assign properties and functions to entities, components are used. + +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} +\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} \subsection{Conclusion} @@ -266,6 +314,7 @@ Not considered further: \subsection{Conclusion} \section{Gameobjects/components} +\label{sec:Gameobjects/components} \subsection{Introduction} @@ -282,16 +331,7 @@ A gameObject is the most important concept in Unity. Every object in a game is a GameObject, from characters and collectible items to the lights, cameras and special effects. However, a gameObject itself can't do anything on its own. A gameObject needs to be given properties before it can become a character, an envirnment, or a -special effect. -% TODO: cite https://docs.unity3d.com/Manual/GameObjects.html - -\subsection{Conclusion} - -\section{AI} - -\subsection{Introduction} - -\subsection{Findings} +special effect. \autocite{man:unityGameobjects} A gameObject can be seen as a container for components. Components are the properties of the gameObject. A few examples of components are sprites, animators, audioSources, @@ -306,14 +346,20 @@ gameObject. Each gameObject always has one transform class. The transform class describes the position, rotation, and scale within the scene. Some component use this information to e.g. scale a sprite. Other components eddit this information to e.g.~model -gravity. -% TODO: cite https://docs.unity3d.com/Manual/class-Transform.html +gravity. \autocite{man:unityTransformClass} A gameObject can have one (or multiple) children gameObject(s). All children gameObjects, of course, also have one transform class. However, the position, rotation, and scale of this class, is always the same as the child's parent. A child -can not have more than one parent. -% TODO: cite https://docs.unity3d.com/Manual/class-Transform.html +can not have more than one parent. \autocite{man:unityTransformClass} + +\subsection{Conclusion} + +\section{AI} + +\subsection{Introduction} + +\subsection{Findings} \subsection{Conclusion} diff --git a/sources.bib b/sources.bib index 50f5ead..e754959 100644 --- a/sources.bib +++ b/sources.bib @@ -47,4 +47,55 @@ 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}, + 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}, + date = {2023} +} + +@manual{man:unityGameobjects, + title = {GameObject}, + author = {Unity Technologies}, + 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} +} + +@misc{img:Decorator, + 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} +} + +@manual{man:Decorator, + title = {Decorator Design Pattern}, + author = {Refactoring Guru}, + organization = {Refactoring Guru}, + url = {https://refactoring.guru/design-patterns/decorator}, + date = {2024} +} |
