aboutsummaryrefslogtreecommitdiff
path: root/research.tex
diff options
context:
space:
mode:
authorMax-001 <80035972+Max-001@users.noreply.github.com>2024-09-20 15:34:19 +0200
committerMax-001 <80035972+Max-001@users.noreply.github.com>2024-09-20 15:34:19 +0200
commitb8e3fcbe333558d3c0aa1ae36fe80c161d8202c1 (patch)
treeb6552d9d14c88581cb250a285079e03a9d93939a /research.tex
parentaf0fa4a2ffce5f6a000c376cdadaec935dfc2fc4 (diff)
Moved the section GameObject/Components upwards
Diffstat (limited to 'research.tex')
-rw-r--r--research.tex84
1 files 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}