Neben dem Dialog Actor Component ist der meiste Code auf dem Spieler*innen-Objekt selbst drauf, da das die einzige Komponente ist, die auf allen Maps drauf ist. Das hat schwerwiegende Folgen für die Performance und würde in späteren Projekten anders gelöst werden.
Auf dem Spieler*innen-Objekt sind standard Funktionen, wie Movement und die Kamera Einstellung.
Aber auch komplexere Funktionen wie das Spielspeichern, bedeutet, wir haben ein Objekt welches alle Variablen, die gespeichert werden sollen in sich hat und beim starten eines Levels vom Spieler*innen-Objekt ausgelesen wird, damit dann über das Spieler*innen-Objekt die passenden Sprites, Sounds und andere Werte aufgerufen werden können. Zusätzlich ist auf dem Spieler noch eine Variable drauf, damit dieser mit der Actor Component “AC_Dialoge” von jedem NPC interagieren kann und da werden eben verschiedene Boolean angeschaltet und verschiedene Collider, damit diese Interaktion möglich ist.
Das Größte, was wahrscheinlich besser auf einzelne Objekten drauf hätte gelegt werden sollen und nicht auf den Spieler selbst, ist die E-Interaktion, da es sehr viele Probleme erzeugt. Denn jede einzelne Interaktion auf E ist auf dem Spieler und nicht auf den Objekten drauf, bedeutet die Cutscenes, die Minispiele, das Teleportieren durch Türen.
Genau bei den Türen wird eben immer geschaut, welche Tür es ist, dann hat das ein bestimmtes Ziel für die Teleportation. Bei den Minispielen wird beim Klamottenwechseln einfach nur das Sprite des Spielers geändert und das für Stillstehen, Laufen nach vorne, zurück und zur Seite. Beim Briefkasten sind es einfach Buttons, die unterschiedliche Briefe aufrufen und einen mehr Inhalt zur Story geben.
Das Müll-Minispiel war ein aufwendigeres, weil jedes Metallteil seinen eigenen Wert bekommen hat und dann sortiert werden musste, welcher Müll wo rein kommt. Das bedeutet, dass die Kästchen auf den Mülltonnen immer überprüft haben, welche Textur in ihnen ist und löschen nur bestimmte Texturen. Wenn diese bestimmte Textur gelöscht ist, wird in der Mitte ein Randomizier eingeschaltet, der dann eine neue Textur ausgibt.
Wenn ein Objekt gelöscht wird, geht ein Integer hoch und wenn dieser zwischen
7 - 13 ist, ist das Minispiel beendet und man kann sich wieder bewegen.
Den Tag zu beenden ist eine ganz einfache Variable, bei der einfach ein Integer hochgezählt wird.
Die Regelungen sind noch einmal eine Sache für sich. Diese werden nämlich im Spieler zu einem Array hinzugefügt, welches dann von dem Notizbuch ausgelesen wird. Allerdings dürfen hier ja noch nicht alle Regelungen ausgelesen werden, weshalb ich einen neuen Integer eingefügt habe welche pro Tag hochgezählt wird. Für diese Regelungen wird zum Beispiel bei Tag drei geschaut, ob man immer noch das rote Outfit trägt und wenn ja, dann kommt man ins Gefängnis, sein Spielstand wird gelöscht und man muss von vorne anfangen.
Die Alignment-Mechanik ist auf dem Notizbuch drauf, hier wird einfach nur eine Prozentanzeige hochgezählt, diese ist von allen BPs zugänglich und kann durch Dialogoptionen hochgezählt werden. Die End-Dialoge, also der Schluss, wo man erfährt, was passiert, wird auch aus dem Speicherstand ausgelesen. In “BP_Save” wird einfach nur ein Boolean aktiviert für das jeweilige Ende und daran wird dann der Text orientiert, der am Ende angezeigt wird.
