aboutsummaryrefslogtreecommitdiff
path: root/research.tex
diff options
context:
space:
mode:
authorLoek Le Blansch <loek@pipeframe.xyz>2024-09-12 19:50:35 +0200
committerLoek Le Blansch <loek@pipeframe.xyz>2024-09-12 19:50:35 +0200
commitee4743d28d81d9ba892597d1bdf5238c5c483697 (patch)
tree76e2a23c93a4ebb37545191bab4b24a1ac50930d /research.tex
parent5c20c659ec371957df08a6347fadfac9bf78a5a3 (diff)
parent894fe2fa4e234e5c643820611acfc2c10dd20773 (diff)
merge `master` into `loek/research`
Diffstat (limited to 'research.tex')
-rw-r--r--research.tex60
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}