Wie Hologlyphen SAND erschaffen hat: Raiders of Sophie für einen nachhaltigen Live-Operationsrhythmus
Für Hologryph, Entwicklung SAND: Die Räuber von Sophie Das bedeutete, eine alternative Geschichtsdarstellung einer Wüstenödnis aus dem Jahr 1910 in ein Rohstoffgewinnungsspiel zu verwandeln, das auch lange nach dem Start weiter wachsen konnte. Die Spieler bemannen und steuern Trampler – gigantische Laufmaschinen, die gleichzeitig als Basis, Beutelager und Waffe dienen – und reiten dann mit ihnen durch eine prozedural generierte offene Welt auf der Suche nach Bergungsgut und nach anderen Spielern.
Um dieses Erlebnis zu ermöglichen, waren eine strikte Trennung von Server und Client, eine prozedurale Weltgenerierung, die auf beiden Seiten identisch abläuft, die Synchronisierung der Hunderte von Entitäten, aus denen ein einzelner Trampler besteht, und ein so flüssiges Weltstreaming erforderlich, dass das Gefühl, auf einem zu reiten, vermittelt wird. Das Team benötigte außerdem eine Content-Pipeline, die schnell genug war, um regelmäßig neue Bereiche, Waffen, Effekte und saisonale Umgebungen zu veröffentlichen, ohne die Performance zu beeinträchtigen.
Wir sprachen mit Serhiy Grinets, CTO und Game Director bei Hologryph, über die langfristige Architektur des Spiels, die Aufrechterhaltung der Content-Pipeline und darüber, was nötig ist, um den Live-Betrieb eines so technisch anspruchsvollen Spiels zu gewährleisten.
Wie sieht Ihr Live-Ops-Modell aus und was beinhaltet ein typisches Update?
Serhiy Grinets: Unser Live-Ops-Modell für SAND konzentriert sich darauf, das Spiel gemeinsam mit unserer leidenschaftlichen Community weiterzuentwickeln. Unsere Priorität ist es, regelmäßig Updates zu veröffentlichen, die neue Inhalte, Verbesserungen des Gameplays, Balance-Anpassungen, Fehlerbehebungen und Verbesserungen der Benutzerfreundlichkeit beinhalten. Unser oberstes Ziel ist der Aufbau eines nachhaltigen Live-Ops-Modells, das den Titel langfristig unterstützt.
Was waren Ihre wichtigsten technischen Ziele zu Beginn, und wie haben diese Ihre Herangehensweise an die Entwicklung eines Spiels geprägt, das auf Langlebigkeit und Weiterentwicklung ausgelegt ist?
Wir hatten drei große Ziele:
- Eine strikte Trennung zwischen einem autoritativen Server und einem Client, wobei die prozedurale Weltgenerierung auf beiden Seiten identisch abläuft.
- Die Synchronisierung einer riesigen Anzahl von Einheiten – ein einzelner Trampler besteht aus Hunderten von ihnen.
- Weltweites Streaming ohne Unterbrechungen – die Welt ist wirklich groß, und um das Gefühl, einen Trampler zu fahren, zu vermitteln, braucht man einen Ort zum Fahren.
Trampler sind ein zentraler Bestandteil der Identität des Spiels. Wie haben Sie das Anpassungssystem so aufgebaut, dass Sie neue Teile, kosmetische Gegenstände und Varianten als fortlaufende Inhalte für den laufenden Spielbetrieb bereitstellen können?
Das gesamte System ist in verschiedene Abteilungen unterteilt. Ein Abteil ist ein Abschnitt eines Tramplers – ein Deck, eine Kabine, ein Stützrahmen, ein Ausrüstungsraum – und jedes Abteil ist so konstruiert, dass es mit den anderen zusammenpasst.
Die Spieler setzen ihren Trampler aus diesen Blöcken zusammen: Sie wählen das Layout, stapeln Decks, platzieren Ausrüstung und erhalten am Ende eine Maschine, die wirklich ihnen gehört – ihre Basis, ihr Tresor und ihre Waffe zugleich.
Für uns als Entwickler ist dies auch die Content-Pipeline. Um ein neues Kompartiment hinzuzufügen, modellieren und konfigurieren wir es ohne Code. Es lässt sich wie jeder andere Block in das Bausystem einbinden und die Spieler können es sofort in ihren Entwürfen verwenden. Ein Programmierer kommt nur dann zum Einsatz, wenn ein Bauteil eine neue Mechanik benötigt, und selbst dann handelt es sich um eine kleine, isolierte Aufgabe.
Genau das macht Abteile zu perfektem Live-Operations-Inhalt: Jedes neue Exemplar vervielfacht die Anzahl der möglichen Trampler-Varianten, und die Herstellung ist für uns kostengünstig.
Wie sieht die Architektur unterhalb des Kompartimentsystems aus und wie ermöglicht sie die schnelle Entwicklung von Prototypen neuer Mechanismen?
Wir verwenden einen modularen Ansatz, der es uns ermöglicht, Prototypen schnell zu iterieren. Im Inneren befindet sich ein spezieller Inversion-of-Control-Container zum Einbinden neuer Funktionen, der hervorragend zu unserem Entity Component System (ECS) passt. Darüber hinaus bedeutet unsere eigens entwickelte Netzwerk-Engine, dass wir uns beim Erstellen neuer Mechanismen fast nie Gedanken über die Vernetzung machen müssen. Die Replikation wird eine Ebene unterhalb des Gameplay-Codes gehandhabt.
Wie haben das C# Job System und der Burst -Compiler von Unity Ihnen den nötigen Leistungsspielraum verschafft, um ohne Regressionen fortlaufend Live-Ops-Inhalte hinzuzufügen?
Unsere Simulation läuft auf unserer eigenen modifizierten Version von Entitas, einem Open-Source-ECS-Framework, anstatt auf Unity Entities. Das C# Job System und der Burst Compiler sind jedoch für unsere Hot Paths unerlässlich. Die prozedurale Geländegenerierung, einschließlich der Erstellung von Höhenkarten und Biom-Sampling-Jobs, der Bewegungsberechnungen für Trampler und unseres benutzerdefinierten Occlusion Culling, werden alle als Burst-kompilierte Jobketten ausgeführt. Diese Verarbeitung läuft nicht im Hauptthread, sodass eine komplexere Welt keine Frames kostet.
Welche Rolle spielte VFX Graph dabei, Ihrem Team schnelle Iterationen bei Effekten für Live-Events, saisonale Ereignisse oder Meilensteine zu ermöglichen?
Alle unsere Effekte – Sandstaub, Rauch, Schilde, Waffeneffekte – basieren auf VFX Graph, aber der entscheidende Punkt ist, wie wir ihn einsetzen. Darüber hinaus entwickeln wir konfigurierbare Effektsysteme, wie zum Beispiel Mündungsfeuer oder Einschlag von Kugeln, die als ein flexibler Graph mit einer großen Anzahl von Parametern existieren, darunter Größe, Farbe, Zeitpunkt, Trümmer und Rauch.
Wenn also eine neue Waffe eingeführt wird, passt ein Künstler einfach diese Parameter an und erzielt so einen einzigartigen Effekt – es ist kein technischer Künstler beteiligt und es wird keine neue Grafik von Grund auf erstellt. Die Zeit der Technik-Künstler fließt in die Erweiterung dieser Systeme, anstatt jeden einzelnen Effekt für diese Waffe von Hand zu programmieren.
Das ist es, was eine ausreichend schnelle Produktion für einen stetigen Content-Rhythmus gewährleistet. Neue Waffen und Ereignisse erhalten Qualitätseffekte auf Kosten der Konfiguration, nicht der Entwicklung.
Wie hat der Unity Profiler Ihren Optimierungs-Workflow im Zuge der Skalierung Ihrer Live-Ops-Content-Pipeline beeinflusst?
Wir messen regelmäßig die Leistung sowohl auf Client- als auch auf Serverseite, um Schwachstellen zu finden und zu optimieren. Die Aufschlüsselung nach Systemen im Unity Profiler zeigt genau, wo die Zeit hinfließt, was unser ECS sehr komfortabel für die Profilerstellung macht.
Wir verfügen außerdem über automatisierte Tests, die die Leistung in festgelegten Szenarien messen, sodass wir den Trend täglich erkennen und sofort auf Veränderungen reagieren können.
Wie nutzen Sie Addressables , um Live-Inhaltsaktualisierungen, Hotfixes und saisonale Updates bereitzustellen, ohne dass ein vollständiges Client-Update erforderlich ist?
Addressables sind das Rückgrat unseres Speichermanagements. Die Welt wird gestreamt: Während die Spieler durch die Wüste reiten, werden hinter ihnen ständig Inhalte geladen und wieder entladen. Das alles läuft über Addressables, sodass der Speicher unabhängig von der Entfernung der Spieler konstant bleibt.
Eine zweite, weniger offensichtliche Rolle besteht darin, dass wir zwei separate Projekte haben, das Hauptclient-Projekt und das Server-Projekt, und wir haben eine maßgeschneiderte Lösung entwickelt, die Assets von einem Projekt zum anderen überträgt. Dadurch bleiben beide Umgebungen konsistent: Der Server sieht die gleichen Daten wie der Client, die über die gleiche Pipeline erstellt wurden, sodass Inhaltsfehler, die auf dem Client funktionieren, aber auf dem Server nicht, strukturell unmöglich sind und nicht erst getestet werden müssen.
Gab es Asset-Store- Tools, die Ihnen geholfen haben, Ihre Live-Ops-Pipeline schneller aufzubauen oder zu warten?
Aus dem Unity Asset Store rendert GPU Instancer Pro unsere gesamte Wüstenstreuung, was für die offene Welt unerlässlich ist, und Amplify Impostors kümmert sich um entfernte Objekte. Odin Inspector ist die Basis unserer Designer-Tools, die für eine datengetriebene Content-Pipeline unerlässlich sind, und Rewired verarbeitet die Eingaben zwischen PC und Konsolen. Easy Save , DOTween und I2 Localization haben uns alle Echtzeit gespart.
Welche Rolle spielte Cinemachine bei der Erfassung von teilbaren, herausragenden Momenten – Mech-Kämpfen, spektakulären Spielzügen –, die Ihre Content-Strategie beflügeln?
Unsere Nutzung von Cinemachine ist bewusst einfach gehalten. Es steuert unsere Kameras und schaltet zwischen ihnen um – der Spielkamera, dem Hangar und der Zuschaueransicht. Wir verzichten bewusst auf zusätzliche Inszenierungen und geskriptete Kameraführung. SAND: Die Räuber von Sophie Es handelt sich um ein Ego-Shooter-Spiel mit hohem Wettbewerbscharakter, und die Aufgabe der Kamera besteht darin, zuverlässig zu sein, nicht künstlerisch.
Die filmische Qualität ergibt sich aus dem Spiel selbst. Wenn zwei gigantische, wandelnde Festungen Kanonenkugeln austauschen und man selbst auf dem Deck einer von ihnen steht und eine Kanone nachlädt, kann keine noch so ausgefeilte Kameraführung das toppen. Die epische Wirkung der Simulation liegt in der Kinematografie. Cinemachine sorgt dafür, dass die Kamera nie im Weg ist.
Du hast ein Zweikanal- Vivox -Setup eingerichtet – Crew-Chat plus räumlicher Nähe-Chat. Welche Faktoren flossen in die Konzeption und Umsetzung ein?
Jeder Spieler befindet sich gleichzeitig in zwei Vivox Kanälen: dem regulären Crew-Kanal, dem „Funkkanal“, über den seine Crew ihn immer hört, und einem Positionskanal via 3D Näherungsstimme, sodass er Spieler in der Nähe aus anderen Crews in der Welt hört.
Der Positionskanal nutzt Vivox 3D Eigenschaften – Reichweite, Abfall, Überblendmodell – die in einer Konfiguration eingestellt sind. Unser ECS übermittelt die Positionen von Sprecher und Zuhörer mit einer begrenzten Frequenz an Vivox , nur etwa 20 Mal pro Sekunde und nur dann, wenn sich der Spieler bewegt hat. Die Authentifizierung erfolgt über unseren eigenen Backend-Token-Dienst.
Abgesehen von der Sprachübertragung: Welche Rolle spielte Vivox in Ihrer umfassenderen Live-Ops-Strategie und wie trug es zur Steigerung des Social-Media-Engagements und der Kundenbindung bei?
Die Sprachsteuerung in der Nähe ist für uns ein Gameplay-Feature, nicht nur ein Kommunikationsfeature. Extraction-Spiele leben von spontanen sozialen Momenten, in denen sich Teams in der Wüste treffen, miteinander reden, verhandeln, sich zusammenschließen oder einander verraten können, und das Hören der echten Stimme eines Fremden in der Nähe erzeugt eine Spannung, die kein geskriptetes System erzeugen kann. Das Funkgerät der Besatzung sorgt für die Koordination der Teams.
Was ist Ihr bester Tipp für Entwickler, die ein auf Live-Operationen basierendes Spiel entwickeln möchten?
Die Entwicklung eines Live-Ops-Spiels ist eine anspruchsvolle Aufgabe. Stellen Sie daher sicher, dass Ihr Team die nötige Belastbarkeit besitzt, um diese Aufgabe zu bewältigen, und dass Sie auf zuverlässige Partner und Tools zurückgreifen können. Bleiben Sie eng mit Ihrer Community verbunden – hören Sie Ihren Spielern zu, lernen Sie aus ihrem Feedback und lassen Sie es mitgestalten, wie sich das Spiel im Laufe der Zeit weiterentwickelt.
Mehr über mit Unity erstellte Projekte erfahren Sie auf der Seite „Ressourcen“ .