Add actual documentation
This commit is contained in:
@@ -280,6 +280,67 @@ Diese Struktur erlaubt es, neue Modelle ohne tiefgreifende Änderungen am Code h
|
||||
|
||||
|
||||
\newpage
|
||||
|
||||
|
||||
\section{Technische Dokumentation}
|
||||
Das Unity Projekt basiert auf verschiedenen C\# Klassen, welche den Ablauf Regeln.
|
||||
Dabei unterscheiden wir zwischen 3 Typen.
|
||||
|
||||
\subsection{Informationsmodell}
|
||||
Die Klassen des Informationsmodell befinden sich in Assets/Scripts/Model und beschreiben die theoretische Ausführung eines Modelles. Sie tragen die Informationen über die einzelheiten der Modelle, führen selbst jedoch nichts aus.
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Model} \\
|
||||
Das Model ist die Grundlage für das Base- und ChildModel. Es umfässt Namen (Human-Readable), ID, Mesh (Form), Material (Oberfläche), Position, Rotation, Skalierung, Mögliche Farbauswahlen. Die Möglichkeit des Passthrough-Models existiert auch, welches für Hilfsobjekte gedacht ist, und Informationen wie die Farbe an seine Kinder weiterleitet. Auch werden Ports definiert.
|
||||
\item \textbf{Port} \\
|
||||
Ein Port ist eine Schnittstelle, welche von einem Modell definiert wird und passenden ChildModels erlaubt, angebunden zu werden. Er trägt eine nicht-unqique PortID, eine DefaultID (eine Modell-ID welche Standardmäßig an diesem Port geladen wird), eine Chooseable-Flag (ob der Port in der Auswahl erscheint), Positionsinformationen, einen Human-Readable Name der im Menü erscheint (sofern Chooseable), sowie eine Explode-Direction für das Explosions-Feature.
|
||||
\item \textbf{BaseModel} \\
|
||||
Ein BaseModel ist der Startpunkt einer Konfiguration. Es ist im Hauptmenü auswählbar. Die Farbe des BaseModels ist in der aktuellen Struktur nicht änderbar und es ist empfohlen, ein leeres oder festes unänderbares Objekt als BaseModel auszuwählen, um maximale Konfigurierbarkeit zu gewährleisten.
|
||||
\item \textbf{ChildModel} \\
|
||||
Ein ChildModel ist ein an einen Port angebundenes Modell. Der ParentPort ist der Name des Ports an den dieses Modell angebunden werden darf. Das ChildModel selbst auch Ports definieren, wodurch eine Rekursive Baumstruktur möglich ist.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Real-Modelle}
|
||||
Die Real-Modelle befinden sich in Assets/Scripts/Model und beschreiben die konkreten MonoBehaviours welche dem Nutzer angezeigt werden. Sie bilden das Informationsmodell somit ab.
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{ModelBehaviour} \\
|
||||
Ein ModelBehaviour verwaltet konkret die Visualisierung eines Ports sowie seiner Kinder. Es ist einem konkreten Port zugewiesen (Ausnahme BaseModelSelector) und zeigt das aktuell ausgewählte Modell des Ports an. Der Logikablauf des Modellwechsels ist in diesem Implementiert.
|
||||
\item \textbf{BaseModelBehaviour} \\
|
||||
Die Implementierung des ModelBehaviour's für das BaseModel. Sie enthält keine Logik über die Des ModelBehaviour's und existiert nur zu Identifikationszwecken
|
||||
\item \textbf{ChildModelBehaviour} \\
|
||||
Die Implementierung des ModelBehaviour's für das ChildModel. Sie enthält neben dem ModelBehaviour informationen die nur ein ChildModel tragen. Dies umfässt Port sowie Parent.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Manager}
|
||||
Die Manager verwalten verschiedene Aspekte des Programmablaufes.
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{ModelManager} \\
|
||||
Der ModelManager befindet sich in Assets/Scripts/Model und verwaltet das Wissen über alle Informationsmodelle und deren (theoretische) Zusammenhänge. Nur Modelle die dem ModelManager bekannt sind können genutzt werden. Er kennt und verwaltet das aktuelle BaseModel sowie dessen BaseModelBehaviour.
|
||||
\item \textbf{StateManager} \\
|
||||
Der StateManager befindet sich in Assets/Scripts/Managing und verwaltet alle IResettable's. Dies ist ein Interface welches alle bei Modelwechsel alle zu Resettenden Elemente anspricht. Es wird konkret von dem "Return to Menu" Knopf genutzt
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Transformer}
|
||||
Die Transformer verwalten das Interaktioneverhalten mit der angezeigten Konfiguration.
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Exploder} \\
|
||||
Der Exploder verwaltet den Explosionszustand der Konfiguration und spielt bei Explode oder Unexplode eine Animation ab.
|
||||
\item \textbf{Rotator} \\
|
||||
Der Rotator verwaltet das Drehverhalten sowie die Eingabe über die Meta-Quest 3 Joysticks. Dabei können beide Joysticks genutzt werden, um die Drehgeschwindigkeit anzupassen. Wir haben uns entschieden, nur Rotation um die y-Achse zu erlauben, da sonst durch das Controllerdesign des Meta Quest 3 Plus Controller keine saubere Rotation möglich ist (keine Einrastpunkte).
|
||||
\end{itemize}
|
||||
|
||||
\subsection{UI}
|
||||
Das UI basiert auf vielen Einzelteilen welche Zusammen eine Angenehme Nutzererfahrung bieten.
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{TODO: MAX HAT DAS UI GEMACHT, DAS SOLL DER SCHREIBEN}
|
||||
\end{itemize}
|
||||
|
||||
\newpage
|
||||
|
||||
\section{Test und Evaluation}
|
||||
|
||||
Die Qualität und Funktionalität der Anwendung wurden im Rahmen interner End-to-End Tests überprüft. Ziel war es, die Stabilität, Usability und Performance auf der Meta Quest 3 sicherzustellen. Dabei kamen sowohl manuelle Testszenarien als auch explorative Tests durch das Team selbst zum Einsatz. Auch das Ausprobieren durch projektfremde Personen gab einen wertvollen Einblick wie User mit wenig technischer Erfahrung sich in unserer App zurechtfanden, wodurch wir wertvolle Tipps zur UI Gestaltung erhalten haben.
|
||||
|
||||
Reference in New Issue
Block a user