1 files changed, 57 insertions, 3 deletions
diff --git a/research.tex b/research.tex
index 16dcef4..00b006d 100644
--- a/research.tex
+++ b/research.tex
@@ -152,7 +152,7 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Gameloop/resource manager}
+\section{Resource manager}
 
 \subsection{Introduction}
 
@@ -168,7 +168,7 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \subsection{Conclusion}
 
-\section{Event manager}
+\section{Event manager/game loop}
 
 \subsection{Introduction}
 
@@ -207,13 +207,23 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 % should audio research be scoped down to SDL2 (if that's what we're going with) or
 % standalone libraries only (for modularity?).
 
+\section{Physics}
+
+\subsection{Introduction}
+
+\subsection{Findings}
+
+\subsection{Conclusion}
+
+\section{Scripting}
+
 \subsection{Introduction}
 
 \subsection{Findings}
 
 \subsection{Conclusion}
 
-\section{Physics/scripting}
+\section{Audio}
 
 \subsection{Introduction}
 
@@ -225,8 +235,52 @@ for audio some options could be: FMOD, Wwise, or iirKlang
 
 \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.
+% TODO: cite https://docs.unity3d.com/Manual/GameObjects.html
+
+\subsection{Conclusion}
+
+\section{AI}
+
+\subsection{Introduction}
+
+\subsection{Findings}
+
+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.
+% TODO: cite https://docs.unity3d.com/Manual/class-Transform.html
+
+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
+
 \subsection{Conclusion}
 
 \end{document}