diff options
| -rw-r--r-- | img/ECSBlockDiagram.png | bin | 0 -> 64822 bytes | |||
| -rw-r--r-- | img/ECSComponentManager.png | bin | 0 -> 247012 bytes | |||
| -rw-r--r-- | img/ExtensionObjects.jpg | bin | 0 -> 48639 bytes | |||
| -rw-r--r-- | research.tex | 177 | ||||
| -rw-r--r-- | sources.bib | 49 |
5 files changed, 170 insertions, 56 deletions
diff --git a/img/ECSBlockDiagram.png b/img/ECSBlockDiagram.png Binary files differnew file mode 100644 index 0000000..4d36afa --- /dev/null +++ b/img/ECSBlockDiagram.png diff --git a/img/ECSComponentManager.png b/img/ECSComponentManager.png Binary files differnew file mode 100644 index 0000000..6602cd6 --- /dev/null +++ b/img/ECSComponentManager.png diff --git a/img/ExtensionObjects.jpg b/img/ExtensionObjects.jpg Binary files differnew file mode 100644 index 0000000..4807ff7 --- /dev/null +++ b/img/ExtensionObjects.jpg diff --git a/research.tex b/research.tex index 5340bf5..ed34730 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,28 +72,95 @@ 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 - \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} \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). +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 +\autocite{man:ECSComponentManager}. + +\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} -% TODO: Continue this explanation (also add some diagrams to make the ECS more clear)! +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 \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) \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 @@ -115,12 +182,56 @@ 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}. \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} @@ -304,48 +415,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} diff --git a/sources.bib b/sources.bib index bf04165..f48e8c3 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,48 @@ 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} +} + +@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} +} + |
