Hauptdesignanforderungen

*Dieser Inhalt wurde mit KI (Beta) übersetzt und kann Fehler enthalten. Um diese Seite auf Englisch zu sehen, klicke hier.

Die folgende Liste gibt einen Überblick über die wichtigsten technischen Designanforderungen, die wir erörtert haben, als wir an The Mystery of Duvall Drive gearbeitet haben.Für weitere Informationen zum visuellen Design dieser Elemente siehe die Mystery of Duvall Drive Showcase, die die verschiedenen Funktionen und Werkzeuge von Studio hervorhebt, die wir verwendet haben, um die immersive Umgebung zu erstellen.

Missionen

Es gibt mehrere Arten von Missionen, die Spieler lösen müssen, um durch die Erlebnisvoranzukommen, einschließlich der Navigation einer Reihe von drehenden Plattformen, bis Spieler einen speziellen Artikelabrufen können oder verschiedene Zutaten in einer erweiterten Speisekammer finden und sie in einen kochenden Topf legen.Um den Skriptierungsprozess der Erstellung und Fehlersuche von Missionen zu organisieren, haben wir einen Mission-Framework und eine Fehlersuche-Version erstellt.

Missionsrahmen

Um sicherzustellen, dass wir jeden Schritt der Mission während des Erlebnisses vereinheitlichten, entwickelten wir einen einfachen Puzzle-Missionsrahmen für jede Mission, der aus Hooks für den Start und das Ende des Puzzles, einem Ort zur Lektüre der Konfigurationsdaten und einer Schaltfläche zur Vervollständigung des Puzzles für Fehlerbehebungszwecke bestand.Für detailliertere Informationen zu diesem Prozess und seinen Parametern siehe Missionslogik.

Siegel und Spielzustände

Wenn Spieler bestimmte Räume betreten, wollten wir, dass sie mit speziellen kleinen Objekten interagieren, die als Seelöwen bekannt sind, um Missionen auszulösen.Nachdem sie die Mission gelöst hatten, wollten wir, dass sie den Siegel ergreifen und es an einem vordefinierten Ort im Foyer platzieren, um durch das gesamte Gameplayfortzuschreiten.Nachdem sie das Siegel an der richtigen Stelle platziert hatten, konnten sie dann in einen anderen Raum im Haus gehen und die nächste Mission starten, indem sie auf das spezielle Objekt in diesem Raum klicken.

Wir haben ein einfaches Greifsystem entwickelt, um ein Objekt zu halten, indem wir das Objekt dem rechten Arm des Charakters anbringen.
Das Foyer, in dem Spieler jedes Siegel platzieren müssen, um durch das Erlebnis fortzuschreiten.

Um dies zu implementieren, haben wir Spielzustände erstellt, die die Zeit spezifizieren würden, in der Spieler den Prozess starten könnten, wie:

  • Suche nach einem "beschädigten" Siegel in einem Raum, um die Mission auszulösen.
  • Nimm das "wiederhergestellte" Siegel auf, wenn sie die Mission lösen.
  • Platziere das Siegel in den Foyer-Kreis.

Spielzustände kontrollieren weitgehend den Fluss des Erlebnisses und wie Spieler mit der Erlebniserzählung interagieren.Für weitere Informationen, siehe GameStateManager.

Normale und korrupte Räume

Wir wollten zwei Zustände von sechs Zimmern im Haus haben: einen normalen Zustand und einen korrupten Zustand.Wenn ein Spieler eine beschädigte Dichtung in einem Raum berühren würde, um den beschädigten Zustand des Raums auszulösen, würde sich die Umgebung in eine dunklere Atmosphäre mit modifizierter Beleuchtung, Umweltgegenständen und Spezialeffekten verändern.Spieler müssten dann die Mission lösen, um in den normalen Zustand des Raums zurückzukehren.

Der normale Zustand der Studie
Der korrupte Zustand der Studie

Um dies zu implementieren, haben wir einen speziellen Raum im Erlebnis vorbereitet, der sehr weit vom Haus entfernt war, etwa 6.500 Klötze in der X -Richtung, der den beschädigten Zustand eines Raums aufnehmen konnte.Wenn ein Spieler einen korrupten Zustand auslöst, klont der korrupte Zustand dieses bestimmten Raums von bis TempStorage/Cloned in dieses Gebiet, dann teleportieren sich die Spieler in diesen Raum.Kleine Parts existieren in jedem normalen und korrupten Raum, der als Spawn-Punkte für Spieler dient, wenn sie Räume betreten oder verlassen.Nachdem sie die Mission gelöst haben, teleportieren wir gleichzeitig Spieler zurück in den normalen Zustand des Raums und zerstören alle Objekte im beschädigten Zustand des Raums.Für weitere Informationen über die Spielzustände, die diesen Teleportationsprozess steuern, siehe GameStateManager.

Testversion

Um uns bei der regelmäßigen Fehlersuche von Missionen zu helfen, haben wir eine Version des Erlebnisses erstellt, in der wir nicht in der Lobby oder für Cutscenes warten müssen.Diese Version hatte Tastatkniffe und Schaltflächen, mit denen wir Missionen automatisch abschließen könnten, damit wir Aspekte des Erlebnisses schnell testen konnten.Wir würden diese Version regelmäßig kopieren und veröffentlichen, um die Version zu veröffentlichen, die den richtigen Spielablauf hatte.Um diese beiden Versionen zu unterscheiden, haben wir ein DemoGlobalSettings Skript erstellt, um die placeID zu überprüfen, zu sehen, ob es im Studio ausgeführt wird, und verschiedene Spielcheats und Schaltflächen zu aktivieren/deaktivieren.Weitere Informationen finden Sie unter Missionslogik und Konfigurationsskripte.

Teleportieren

Es gibt drei Arten von Teleportation, die innerhalb der Erlebnisauftreten:

  1. Teleportieren von Spielern von der einfachen Lobby in den Hauptspielbereich in einem reservierten Server.
  2. Teleportiere Spieler vom normalen Zustand eines Raums in den beschädigten Zustand und wieder zurück, während du eine Cutscene zeigst.
  3. Teleportiere Spieler innerhalb einiger Puzzle oder wenn sie respawnen nachdem sie den Spielbereich verlassen haben.

Reservierte Server

Wir haben uns entschieden, Spieler in Gruppen von fünf in einer einfachen Lobby zu gruppieren, bevor wir sie auf einen reservierten Server für den Hauptbereich des Spiels des Hauses teleportieren.Die Lobby bot Zeit für zusätzliche Spieler, um sich anzuschließen und zusammen zu spielen, und reservierte Server verhinderten, dass zusätzliche Spieler Aspekte des Spielablaufs und der Narrative der Erfahrung spät vermissen.Diese Teleportation geschieht nur einmal.

Schnittszenen

Wir wollten in der Lage sein, Spieler während des Spiels zu transportieren, wann immer sie bestimmte Aufgaben erledigen, wie z. B. einen Seelöwen berühren oder eine Mission abschließen.Um dies zu implementieren, entwickelten wir eine einfache Version eines skriptbasierten Werkzeugs namens EventManager , das verschiedene Eigenschaften und Attribute steuert, Skripte und Audiodateienausführt und Kamerabewegungen über einen Zeitraum durchführt.Dies ermöglichte es uns, sowohl Spieler zu bewegen als auch in verschiedenen Räumen ein- und auszustreamen, während wir diesen Prozess vom Spieler mit speziellen Effekten aus verbergen.Für weitere Informationen, siehe EventManager.

Spieler respawnen

Der dritte Typ der Teleportation, den wir implementieren wollten, war eine kurze Teleportation mit nur einer Spielerkoordinatenänderung innerhalb einiger Puzzle und wenn Spieler fallen und respawnen.Im Gegensatz zu den vorherigen zwei Arten der Teleportation fordert dieser Typ nicht explizit asynchrone Streaming an.

Scripting

Skripte ermöglichten es uns, auf spezifische Spielmechaniken auszuführen, wie verschwindende UI-Elemente, Trigger-Volumen für Schlüssereignisse zu erstellen und Objekte hervorzuheben, wenn sie mit dem Cursor des Spieler:inim Fokus waren.Viele dieser Systeme basierten auf der Markierung von Objekten, um benutzerdefiniertes Verhalten auszuführen, und verwendeten dann eine Vielzahl von Client- oder Serverskripten, um spezifische Workflows zu enthalten, abhängig davon, welche Aktion an bestimmten Stellen im Erlebnis ausgeführt werden musste.Für weitere Informationen darüber, wie wir diese Systeme implementiert haben, siehe Grundlegende Spielsysteme und Unterstützende Systeme.

Benutzerdefiniertes Verhalten mit Tags

Wir wollten einen Weg, um benutzerdefiniertes Verhalten für Objekte hinzuzufügen, wie das Feststellen von Türen, damit Spieler sich im Raum aufhalten müssen, bis sie die aktive Mission abgeschlossen haben.Um dies zu implementieren, entschieden wir uns, Tags für bestimmte Objekte zu verwenden, dann verwendeten wir CollectionService, um diese Objekte zu finden und jedes entsprechende Scripts zu verbinden, um benutzerdefiniertes Verhalten hinzuzufügen.Wir hatten eine Script für jede Tagkategorie, die als Manager fungierte, um alle mit dieser Kategorie versehenen Objekte zu verwalten, so dass wir die Script in einer einzigen Position behalten konnten, anstatt sie mehrmals in DataModel kopiert zu werden.Für weitere Informationen, siehe DoorManager , MasterAnimator , DrawerManager , KillVolumes , PlayerMissionRespawn und PianoManager.

Der "Manager" Script verwendet eine Init Funktion, um alle Objekte zu finden, die bei Beginn der Erfahrung markiert wurden, und verbindet ein benutzerdefiniertes Verhalten mit ihnen.Zum Beispiel findet DoorManager jedes Objekt, das mit Tür gekennzeichnet ist, und fügt dann dem Türobjekt das richtige Verhalten hinzu (bewegt die Tür beim Klicken hin und spielt einen Türschwing-Soundeffekt, etc.).Jedoch, alle Objekte, die während der Laufzeit hinzugefügt oder entfernt werden, wie jedes Objekt, das in einen beschädigten Raum hinzugefügt wird, nachdem ein Spieler mit einem beschädigten Siegel interagiert, verfehlt diese erste Anruf und erhält nie das erwartete Verhalten.Um dies zu lösen, verwenden wir CollectionService.GetInstanceAddedSignal und CollectionService.GetInstanceRemovedSignal, um den gleichen Verhalten für neue Objekte zu gewähren, die jeweils markiert und nicht markiert sind.

Client- und Server-Skripte

Wir wollten die Bandbreite für verschiedene Aspekte des Spiels reduzieren, die bei der Erfüllungteuer wären.Wir haben beschlossen, dass, wenn die Funktionalität eines Objekts Auswirkungen auf die Simulation für andere Spieler haben kann, wie das Bewegen eines Objekts durch Kollision, würden wir dies auf dem Server ausführen, aber wenn etwas mehr mit der Umgebungsgestaltung zu tun hat, wie Lichter, Umweltanimationen, die das Gameplaynicht beeinflussen, spezielle Effekte und Audiodateien, würden wir sie auf Clients ausführen.Dies würde die Bandbreite reduzieren und die Bewegung und Umweltänderungen auf den Geräten des Benutzers glatter halten.