Added the Extension Objects and ECS design patterns

1 files changed, 60 insertions, 12 deletions

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