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 | 72 | ||||
| -rw-r--r-- | sources.bib | 32 |
5 files changed, 90 insertions, 14 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 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} +} |
