Es ist schon wieder Montag#

Hallöchen,

es ist schon zwei Wochen her, seit ich den letzten Blogeintrag erstellt habe. Deshalb möchte ich euch erzählen, was ich in den letzten zwei Wochen gemacht habe.

Im letzten Blog habe ich geschrieben, dass ich mit dem NPC-Behavior bzw. der NPC-AI begonnen habe. Ich konnte daran jedoch nicht sofort weiterarbeiten, da Wastl noch einige Feature-Wünsche hatte.

Hier eine Übersicht der Features und Änderungswünsche in Form einer Bullet-Point-Liste:

  • Die Klasse „Door“ konnte den Spieler entweder in ein anderes Level laden oder ihn innerhalb eines Levels zu einer anderen „Door“ teleportieren. Es soll nun auch möglich sein, den Reiseort aktiv über eine GUI auszuwählen, die sich öffnet, sobald der Spieler mit der Tür interagiert – um beispielsweise eine Taxifahrt oder eine Fahrt mit einem anderen Verkehrsmittel zu simulieren. Außerdem sollen Dialog-Knoten neue Reiseorte freischalten können.
  • Wastl wünscht sich einen Wegweiser, um dem Spieler immersive Ortsangaben geben zu können.
  • Animierte Objekte: Objekte, die entweder dauerhaft eine Animation abspielen oder erst dann, wenn der Spieler mit ihnen interagiert.

Die „Door“-Klasse#

Ich habe mit der Erweiterung der Tür begonnen. Zuerst habe ich die GUI entworfen. Wastl möchte, dass die GUI so aussieht, als würde man aus der First-Person-Perspektive in einem Boot, Auto oder einem ähnlichen Verkehrsmittel sitzen – je nachdem, womit man interagiert.

In unserer Testszenen ist das Hauptverkehrsmittel aktuell ein Boot. Also habe ich ein Boot aus der First-Person-Perspektive gezeichnet. Da ich gerade motiviert war, habe ich zusätzlich weitere UI-Elemente gestaltet. Unser Inventar ist momentan ein altmodisches Tablet – also habe ich zwei Hände gezeichnet, die das Tablet halten. Das war eine gute Entscheidung, da es das „Feeling“ der UI deutlich verbessert hat.

Die Logik dahinter zu implementieren war relativ wenig Aufwand. Auch das Freischalten der Reiseorte ließ sich schnell umsetzen.

Nachdem das Thema mit der „Door“-Klasse abgeschlossen war, habe ich direkt mit dem nächsten Punkt begonnen: dem Wegweiser.

Der Wegweiser#

Zu Beginn war ich unsicher, wie ich den Wegweiser umsetzen sollte. Sollte eine Sprechblase erscheinen, wenn der Spieler mit dem Wegweiser interagiert? Das Problem dabei: Die Sprechblase wäre relativ klein, und ich müsste jede Beschreibung nacheinander anzeigen, nachdem der Spieler die Aktionstaste gedrückt hat. Oder sollte sich ein Modal-Fenster öffnen?

Ich habe mich schließlich für eine ähnliche Lösung wie bei der Door-Klasse entschieden. Wenn der Spieler den Wegweiser anklickt, öffnet sich eine UI aus der First-Person-Perspektive. Man sieht einen klassischen Wegweiser aus Holz, an dem pfeilförmige Holzschilder mit Ortsnamen angenagelt sind.

Umsetzung#

Ich habe einen Holzpfahl sowie die Holzschilder gezeichnet. Der Klasse muss lediglich eine Liste mit Ortsnamen sowie die jeweilige Richtung (links, rechts, oben, unten) übergeben werden. Die Schilder werden dann dynamisch generiert und automatisch am Mast platziert.

Goodbye Door-Klasse#

Später ist Wastl beim Leveldesign aufgefallen, dass wir eigentlich gar keine echte Tür im Spiel haben – was witzig ist, da wir buchstäblich eine Klasse namens „Door“ besitzen. Das Problem: Unsere Door-Klasse ist eigentlich eher ein Portal, das den Spieler teleportiert.

Wastl benötigte jedoch ein Objekt, das einen Weg physisch blockiert und erst nach dem „Öffnen“ den Durchgang freigibt.

Zunächst wollte ich die entsprechende Logik in die Door-Klasse integrieren, aber das hätte den Code unnötig unübersichtlich gemacht. Deshalb habe ich eine neue Klasse namens „Barrier“ erstellt und einen Großteil der Logik aus der Door-Klasse übernommen.

Ich habe sie „Barrier“ genannt, da nicht nur Türen Wege versperren können, sondern auch andere Objekte – etwa ein riesiger Felsen oder ein umgestürzter Baumstamm nach einem Unwetter. Außerdem habe ich die Klasse „Door“ in „Portal“ umbenannt, da dieser Name besser passt.

Irgendwann habe ich mich dann zum Refactoring gezwungen. Die beiden Klassen hatten einfach zu viele Gemeinsamkeiten – die Barrier-Klasse bestand zu etwa 60 % aus Copy-Paste-Code der ehemaligen Door-Klasse.

Deshalb habe ich eine neue Basisklasse namens „Gate“ eingeführt. Gemeinsame Funktionalitäten beider Klassen wurden in diese Basisklasse verschoben. „Barrier“ und „Portal“ erben nun von „Gate“ und teilen sich die gemeinsame Logik.

Das Thema animierte Objekte war schnell implementiert, daher gibt es dazu nicht viel zu sagen.

NPC AI#

Heute habe ich endlich das Thema aus meinem letzten Blogeintrag fertig implementiert: NPC AI bzw. Patrolling – zumindest die Core-Mechanik.

Man kann Bereiche definieren, in denen ein NPC patrouilliert, also von einem PatrolNode zum nächsten läuft. Innerhalb eines Bereichs wird kein Pathfinding verwendet. Erst wenn ein Bereichswechsel durch eine vordefinierte In-Game-Zeit ausgelöst wird, kommt Pathfinding zum Einsatz, um den NPC in den nächsten Bereich zu navigieren.

Das funktioniert aktuell erstaunlich gut. Ich muss es jedoch noch mit mehreren NPCs testen. Collision-Handling zwischen NPCs ist bisher noch nicht implementiert.

Die Patrol-Groups, die als Container für Bereiche dienen, funktionieren ebenfalls. Bei der Initialisierung wird geprüft, welche Gruppe aktiv ist. Aktuell kann man festlegen, in welchen Monaten und an welchen Wochentagen eine Gruppe aktiv ist. Das dynamische Wechseln zwischen Gruppen ist jedoch noch nicht implementiert.

Als Nächstes muss ich eine Art Konsole für Cheats implementieren, damit ich beispielsweise Tageszeit, Wochentag oder Monat per Befehl im Spiel ändern kann.

Ich hoffe, dieser Dev-Log-Beitrag hat euch gefallen.

LG
Nflaus