From 7102902f319d450253159a20da207b013d77f7ce Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 13:13:33 +0200 Subject: Replaced .puml with .png, since .puml was causing LaTeX errors --- research.tex | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/research.tex b/research.tex index 5340bf5..ffba7ca 100644 --- a/research.tex +++ b/research.tex @@ -76,7 +76,7 @@ harder \autocite{man:DecoratorDesignPattern,man:Decorator}. \begin{figure} \centering - \includepumldiag{img/decorator-design-pattern.puml} + \includegraphics[width=0.5\textwidth]{img/DecoratorDesignPattern.png} \caption{Decorator design pattern} Source: \autocite{img:Decorator} \label{fig:decorator} -- cgit v1.2.3 From 6f802231674685b9d1bb365d345c96aa15cdd311 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 14:47:03 +0200 Subject: Added the Extension Objects and ECS design patterns --- img/ECSBlockDiagram.png | Bin 0 -> 64822 bytes img/ECSComponentManager.png | Bin 0 -> 247012 bytes img/ExtensionObjects.jpg | Bin 0 -> 48639 bytes research.tex | 72 ++++++++++++++++++++++++++++++++++++-------- sources.bib | 32 ++++++++++++++++++-- 5 files changed, 90 insertions(+), 14 deletions(-) create mode 100644 img/ECSBlockDiagram.png create mode 100644 img/ECSComponentManager.png create mode 100644 img/ExtensionObjects.jpg diff --git a/img/ECSBlockDiagram.png b/img/ECSBlockDiagram.png new file mode 100644 index 0000000..4d36afa Binary files /dev/null and b/img/ECSBlockDiagram.png differ diff --git a/img/ECSComponentManager.png b/img/ECSComponentManager.png new file mode 100644 index 0000000..6602cd6 Binary files /dev/null and b/img/ECSComponentManager.png differ diff --git a/img/ExtensionObjects.jpg b/img/ExtensionObjects.jpg new file mode 100644 index 0000000..4807ff7 Binary files /dev/null and b/img/ExtensionObjects.jpg differ diff --git a/research.tex b/research.tex index ffba7ca..bec9471 100644 --- a/research.tex +++ b/research.tex @@ -24,7 +24,7 @@ A game engine is not the game itself but a platform with which games are built. should provide the functionalities with which the game is constructed. The purpose of a game engine is not to create data out of nothing. Instead, data is read, and the correlating features and effects are generated. However, the engine is also used to -create these files, referred to as ``assets.'' The game engine must be able to accept +create these files, referred to as ``assets''. The game engine must be able to accept a certain format of these assets---whether levels, sprites, or textures---and convert them into usable data. @@ -72,7 +72,7 @@ such Decorator design pattern, is that the interface of all components should be 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}. +harder \autocite{man:DecoratorDesignPattern}. \begin{figure} \centering @@ -82,18 +82,66 @@ harder \autocite{man:DecoratorDesignPattern,man:Decorator}. \label{fig:decorator} \end{figure} -TODO: Add Extension Objects design pattern (if this is applicable)! +The Extension Objects design pattern (as shown in \cref{fig:extension objects}) could +also be used to structure the game engine. The Extension Objects design pattern allows +to modify an object's propperties/behavior by adding one (or more) Extensions. The +object that is modified, could be the gameObject and the components could be the +Extensions. This is quite the same as the required API. An advantage is, that the client +(which is the scene in our case) can call all kind of different Extension's methods +(depending on the kind of Externsion, e.g. the method render() for the sprite Extension +and the method update() for the script Extension). In other words, the interfaces of the +different Extensions should not be the same. This is way more flexible than the Decorator +design pattern. A disadvantage is that the data and functionality are in the same class +(namely inside the Extion's methods), so it's not sepperated. Another disadvantage is +that the Extension Objects design pattern can be quite slow, because objects are scattered +in memory (and it is very hard to quickly get their memory address) +\autocite{man:ExtensionObjectDesignPattern, man:extionsionObjectsStackOverflow}. + +\begin{figure} + \centering + \includegraphics[width=0.5\textwidth]{img/ExtensionObjects.jpg} + \caption{Extension Objects design pattern} + Source: \autocite{img:extionsionObjects} + \label{fig:extension objects} +\end{figure} 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)! +Component System (\gls{ecs}) (as shown in \cref{fig:ECS Block Diagram}). 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), which is an advantage. + +\begin{figure} + \centering + \includegraphics[width=0.5\textwidth]{img/ECSBlockDiagram.png} + \caption{ECS design pattern} + Source: \autocite{img:ECSBlockDiagram} + \label{fig:ECS Block Diagram} +\end{figure} + +The \gls{ecs} is normally equipped with a component manager (as shown in +\cref{fig:ECS Component manager}). The component manager keeps track of the entities +(Alien, Player, Target, etc in \cref{fig:ECS Component manager}) and the connected +components (Position, Movement, Render, etc in \cref{fig:ECS Component manager}). +The component manager stores two lists (key value pairs). The key of the first list +is the ID of an entity, and the value of this list are the connected components. The key +of the second list is the component, and the value of this list are the entities that +have this component. These two lists make it possible to very quickly gather components +or entities. This makes the \gls{ecs} very fast, which is of course an advantage. + +\begin{figure} + \centering + \includegraphics[width=0.5\textwidth]{img/ECSComponentManager.png} + \caption{ECS Component manager} + Source: \autocite{img:ECSComponentSystem} + \label{fig:ECS Component manager} +\end{figure} + +Disadvantage: systems have to cummincate with each other... 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 diff --git a/sources.bib b/sources.bib index bf04165..e025492 100644 --- a/sources.bib +++ b/sources.bib @@ -84,7 +84,7 @@ date = {2024} } -@manual{man:DecoratorDesignPattern, +@manual{man:ExtensionObjectDesignPattern, title = {Extension Object Design Pattern}, author = {James Fawcett}, organization = {Syracuse University}, @@ -92,7 +92,7 @@ date = {2024} } -@manual{man:Decorator, +@manual{man:DecoratorDesignPattern, title = {Decorator Design Pattern}, author = {Refactoring Guru}, organization = {Refactoring Guru}, @@ -100,3 +100,31 @@ date = {2024} } +@misc{img:extionsionObjects, + title = {Extension Objects Diagram}, + author = {stackoverflow}, + url = {https://i.sstatic.net/GoIQ6.jpg}, + date = {2024} +} + +@manual{man:extionsionObjectsStackOverflow, + title = {Extension Object Design Pattern}, + author = {Supun Wijerathne}, + organization = {stackoverflow}, + url = {https://stackoverflow.com/questions/39331752/what-is-the-difference-between-extension-objects-pattern-and-adapter-pattern}, + date = {2016} +} + +@misc{img:ECSBlockDiagram, + title = {ECS Diagram}, + author = {Unity}, + url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/images/ECSBlockDiagram.png}, + date = {2024} +} + +@misc{img:ECSComponentSystem, + title = {ECS Component System}, + author = {Joel van der Werf}, + url = {https://i.imgur.com/VMQFIjW.png}, + date = {2024} +} -- cgit v1.2.3 From 110ffb785a8eaf54106b92f49f008f0003193a2b Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 15:13:48 +0200 Subject: Continued ECS research --- research.tex | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/research.tex b/research.tex index bec9471..8a2ad7b 100644 --- a/research.tex +++ b/research.tex @@ -141,7 +141,25 @@ or entities. This makes the \gls{ecs} very fast, which is of course an advantage \label{fig:ECS Component manager} \end{figure} -Disadvantage: systems have to cummincate with each other... +Another aspect that makes the \gls{ecs} very fast, is that a system can handle all +components (of the same type) together at once. This is possible because all entities +are independent of each other. + +There are many ways of implementing the systems. Some say that each component type has +their own system. This interpretation of the systems does not take the interplay of +different component types, into account. A less restrictive approach is to let different +systems deal with all components they should be concerned with. For instance a Physics +Systems should be aware of Collision Components and Rigidbody Components, as both +probably contain necessary information regarding physics simulation. It's best to see +systems as “closed environments”. That is, they do not take ownership of entities nor +components. They do access them through independent manager objects, which in turn will +take care of the entities and components life-cycle. + +Sometimes systems, entities and even components need to cummincate with each other. This +might be very hard because systems, entities and components are more or less independent. +One option is to use an event systems. A system, entity and component can raise an event +and other systems, entities and components can react to that event. This is what makes the +\gls{ecs} a complicated system (disadvantage). 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 -- cgit v1.2.3 From af0fa4a2ffce5f6a000c376cdadaec935dfc2fc4 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 15:22:50 +0200 Subject: Added sources --- research.tex | 7 ++++--- sources.bib | 17 +++++++++++++++++ 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/research.tex b/research.tex index 8a2ad7b..f9de6a5 100644 --- a/research.tex +++ b/research.tex @@ -131,7 +131,8 @@ The component manager stores two lists (key value pairs). The key of the first l is the ID of an entity, and the value of this list are the connected components. The key of the second list is the component, and the value of this list are the entities that have this component. These two lists make it possible to very quickly gather components -or entities. This makes the \gls{ecs} very fast, which is of course an advantage. +or entities. This makes the \gls{ecs} very fast, which is of course an advantage +\autocite{man:ECSComponentManager}. \begin{figure} \centering @@ -153,13 +154,13 @@ Systems should be aware of Collision Components and Rigidbody Components, as bot probably contain necessary information regarding physics simulation. It's best to see systems as “closed environments”. That is, they do not take ownership of entities nor components. They do access them through independent manager objects, which in turn will -take care of the entities and components life-cycle. +take care of the entities and components life-cycle \autocite{man:ECSExplanation}. Sometimes systems, entities and even components need to cummincate with each other. This might be very hard because systems, entities and components are more or less independent. One option is to use an event systems. A system, entity and component can raise an event and other systems, entities and components can react to that event. This is what makes the -\gls{ecs} a complicated system (disadvantage). +\gls{ecs} a complicated system (disadvantage) \autocite{man:ECSExplanation}. 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 diff --git a/sources.bib b/sources.bib index e025492..f48e8c3 100644 --- a/sources.bib +++ b/sources.bib @@ -128,3 +128,20 @@ url = {https://i.imgur.com/VMQFIjW.png}, date = {2024} } + +@manual{man:ECSExplanation, + title = {The Entity Component System C++ Game Design Pattern - Part 1}, + author = {GameDev.net}, + organization = {GameDev.net}, + url = {https://www.gamedev.net/tutorials/programming/general-and-gameplay-programming/the-entity-component-system-c-game-design-pattern-part-1-r4803/}, + date = {2024} +} + +@manual{man:ECSComponentManager, + title = {ECS Core API}, + author = {Unity Technologies}, + organization = {Unity}, + url = {https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/ecs_core.html}, + date = {2024} +} + -- cgit v1.2.3 From b8e3fcbe333558d3c0aa1ae36fe80c161d8202c1 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 15:34:19 +0200 Subject: Moved the section GameObject/Components upwards --- research.tex | 84 ++++++++++++++++++++++++++++++------------------------------ 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/research.tex b/research.tex index f9de6a5..ed3d2cf 100644 --- a/research.tex +++ b/research.tex @@ -188,6 +188,48 @@ library \autocite{github:ecsfaq}. \subsection{Conclusion} +\section{Gameobjects/components} +\label{sec:Gameobjects/components} + +\subsection{Introduction} + +One of the requirements of our customer, is that the game engine's structure is +similar to Unity. The customer has created a class diagram of the game engine's API, +which is (of course) very similar to Unity. One of the most important parts of the +class diagram is a so-called gameObject (with several components). It's needed to +understand the exact meaning/function of these gameObjects, that's why this research +question arose. + +\subsection{Findings} + +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. \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, +and so on. Multiple (different) components can be assigned to a single gameObject +(e.g.~a sprite and an audioSource). + +Since we now know that a gameObject needs components to do something, it's obvious +that there should be a way to add components to a gameObject. Some components +(e.g.~the behaviorScript component) should also be able to reference to its +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. \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. \autocite{man:unityTransformClass} + +\subsection{Conclusion} + \section{Third-party Tools} \subsection{Introduction} @@ -371,48 +413,6 @@ Not considered further: \subsection{Conclusion} -\section{Gameobjects/components} -\label{sec:Gameobjects/components} - -\subsection{Introduction} - -One of the requirements of our customer, is that the game engine's structure is -similar to Unity. The customer has created a class diagram of the game engine's API, -which is (of course) very similar to Unity. One of the most important parts of the -class diagram is a so-called gameObject (with several components). It's needed to -understand the exact meaning/function of these gameObjects, that's why this research -question arose. - -\subsection{Findings} - -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. \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, -and so on. Multiple (different) components can be assigned to a single gameObject -(e.g.~a sprite and an audioSource). - -Since we now know that a gameObject needs components to do something, it's obvious -that there should be a way to add components to a gameObject. Some components -(e.g.~the behaviorScript component) should also be able to reference to its -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. \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. \autocite{man:unityTransformClass} - -\subsection{Conclusion} - \section{AI} \subsection{Introduction} -- cgit v1.2.3 From 444550c8fa8c88fcfe4c450012156051a0ea60c7 Mon Sep 17 00:00:00 2001 From: Max-001 <80035972+Max-001@users.noreply.github.com> Date: Fri, 20 Sep 2024 15:48:13 +0200 Subject: Added a TODO --- research.tex | 2 ++ 1 file changed, 2 insertions(+) diff --git a/research.tex b/research.tex index ed3d2cf..ed34730 100644 --- a/research.tex +++ b/research.tex @@ -182,6 +182,8 @@ based on the amount of stars on GitHub. \label{tab:popularECSLibraries} \end{table} +TODO: Add library benchmark to find the best library. + 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}. -- cgit v1.2.3