Technische Erklärung: Mit Startrampen auf Touren kommen

Hallo zusammen! In unserem zweiten technischen Erklärpost werden wir unsere Philosophie der Zusammenarbeit anhand eines Schlüsselfeatures von Hytale beleuchten: Startrampen.

Mein Name ist Anna und ich bin Ingenieurin im Gameplay-Team. Unser Bereich ist besonders interessant, weil er die perfekte Mischung aus Problemlösung und Kreativität bietet. Wir sind für Features wie Crafting, Bewegung, UI und seit neuestem auch für Startrampen verantwortlich.

Wie viele andere Entwicklerteams arbeiten auch Hypixel-Teams remote und bestehen aus Menschen mit unterschiedlichem Hintergrund. Um gemeinsam erfolgreich zu sein, müssen wir einen Weg finden, zusammenzuarbeiten. Deshalb ist eine Kultur der Zusammenarbeit so zentral für uns. In diesem Artikel möchte ich Ihnen einige Strategien vorstellen, die auf Zusammenarbeit und Feedback ausgerichtet sind, und Ihnen zeigen, wie diese für die Entwicklung unserer Launchpad-Funktion entscheidend waren.

Warum arbeiten wir zusammen?

Softwareentwickler müssen bei der Problemlösung oft in ihrem eigenen Bereich arbeiten, aber die Entwicklung eines Spiels ist ein kreativer Prozess, der die Zusammenarbeit mit Teammitgliedern aus verschiedenen Disziplinen erfordert. Unsere Designer arbeiten vielleicht an ganz anderen Aspekten des Spiels, aber ohne den Austausch mit ihnen wüssten wir nicht genug über die Tools, die wir entwickeln. Wir sind auch auf Künstler, Audio, VFX und Produktion angewiesen, und die aktive Zusammenarbeit mit ihnen verschafft uns den unschätzbaren Vorteil ihrer Sichtweisen. Wir Ingenieure stecken auch voller kreativer Ideen, und wenn wir diese teilen und unsere Ideen austauschen können, hilft uns das dabei, unser ultimatives Ziel zu erreichen, Inhalte zu erstellen, die den Spielern dienen.

Das Feature-Team

Das Gameplay-Team besteht aus 3 Ingenieuren, 2 technischen Designern, 2 Qualitätsanalysten und 1 Produzenten. Wir sind für das Gameplay rund um das Spielerlebnis in der Haupthauptstadt von Hytale und auf den Spielerinseln verantwortlich. Dieser Bereich erfordert aktive tägliche Teamarbeit, wobei das technische Design ein wichtiger Verbraucher der Ingenieursarbeit für das Team ist. Sie erstellen Prototypen, iterieren an kleineren Funktionen und geben Feedback.

Ein multidisziplinäres Team mit integrierten Ressourcen ermöglicht uns schnelle Reaktionszeiten, schnellere Iterationen und einen vertrauensvolleren kreativen Prozess. Und die enge Zusammenarbeit mit anderen Disziplinen beim Brainstorming und Erstellen während des Designprozesses ist das wertvollste kollaborative Tool – und die beste Vorbeugung gegen Fehler und technische Schulden. Wenn wir bei der Erstellung von Funktionen und der Entscheidungsfindung nicht auch die anderen Disziplinen des Ingenieurwesens einbeziehen, verlieren wir schnell die gewünschte Vision aus den Augen. Wenn nicht beide Seiten aktiv zusammenarbeiten, bleiben wir möglicherweise auf Annahmen sitzen oder arbeiten nur Aufgabenlisten ab, anstatt unsere kreative Denkweise optimal zu nutzen, um das beste Spielerlebnis für die Spieler als Ganzes zu schaffen.

Bei den ersten Kontaktpunkten für ein neues Feature geht es nicht nur darum, Klarheit zu schaffen, sondern auch darum, die Frage „Warum?“ zu beantworten. Aus diesem Gespräch können wir alle darauf vertrauen, dass wir auf dasselbe Ziel hinarbeiten: einen Ausgangspunkt für die Iteration eines hervorragenden Features für das Spiel.

Startrampen

Im Kern sind Startrampen Akteure in einer Welt mit einem Trigger-Collider . Wenn sich Objekte (z. B. Spieler) mit dem Trigger überschneiden, wird ein Ereignis ausgelöst, das einen konfigurierbaren Impuls auf das Ziel ausübt. Dadurch fliegt das Objekt – das Ziel – durch die Luft. Mit anderen Worten: Sie wurden gestartet .

Eine einfache Startrampe

Bau von Startrampen

Als wir zum ersten Mal mit der Erstellung von Startrampen beauftragt wurden, war mein erster Gedanke: „Na ja, es ist eine Startrampe! Die meisten Spiele haben sie, es wird wahrscheinlich dasselbe sein wie überall sonst.“ Trotz dieses ersten Eindrucks stützte ich mich auf unsere Werte der Zusammenarbeit und sprach gleich zu Beginn mit dem Designer, um seine Perspektive zu verstehen. Die nächsten Schritte waren das Durchlesen der Design-Spezifikationen, das Sprechen darüber in unserem wöchentlichen öffentlichen Design-Treffen, das Sammeln von Erläuterungen aus dem Design und das Erstellen eines Miro-Boards.

Dieses Board enthielt die grundlegenden physikalischen Funktionen und die API, die zum Erstellen der Startrampenfunktion selbst erforderlich waren, sowie einige grundlegende Variablen, mit denen das Design experimentiert werden konnte.

Proaktives Feedback

Dieses Board und ein Zeitplan wurden an alle Beteiligten gesendet, um vor Beginn der Entwicklung asynchrones Feedback zu sammeln. Außerdem erhielten wir Feedback von Game-Designern, Technikdesignern und kreativen Mitarbeitern. Dieses Feedback veranlasste uns, die Konfigurierbarkeit des Technikdesigns und die Funktionsweise des Triggers für die anfängliche Entwicklung zu ändern, die als Ray Cast begann und sich in die Verwendung von Trigger-Volumina innerhalb der Engine verwandelte.

An wichtigen Punkten habe ich Leute kontaktiert, die Änderungen vorgeschlagen haben, und mich mit ihnen zu Einzelgesprächen getroffen, um sicherzustellen, dass bereits in dieser frühen Phase eine Kultur der kreativen Zusammenarbeit gefördert wird und dass ihre Beiträge vollständig verstanden werden. Diese Mitwirkenden wurden in jeder Phase des Prozesses kontinuierlich eingebunden, um sicherzustellen, dass wir uns immer noch in die für sie richtige Richtung bewegten.

Unter der Haube

Der Umgang mit serverseitiger Bewegung ist ein wesentlicher Bestandteil der Entwicklung von Startrampen. Ein physikalischer Impuls muss vom Server angewendet werden, und die Geschwindigkeit und der Startvektor werden dort berechnet und aufgelöst. Der Client prognostiziert und löst seine Position durch dieselben Berechnungen. Dieser physikalische Impuls ist nur zum Zeitpunkt des Starts bekannt, da jede Startrampe so konfiguriert werden könnte, dass sie in eine andere Richtung zielt – oder den Vorwärtsvektor des Charakters benötigt, um die Geschwindigkeit zu berechnen.

Grundlegende Implementierung eines Launchpads vom Miro-Board

Server- und Client-Startanforderungen

Code zum Ausführen der Startanforderung auf dem Server und Client, einschließlich Netzwerk-Rollback.

Beim Bau von Startrampen arbeiteten wir hauptsächlich mit zwei anderen Teams zusammen, da diese über Bereiche verfügten, für die wir Fachwissen und Beteiligung benötigten.

Die Bewegung und der Impuls sind Eigentum des Teams für Charaktere, Kamera und Steuerung (CCC). Die Erstellung von Startrampen erforderte eine enge Zusammenarbeit mit ihnen, um das Rückgrat der Startrampenimplementierung zu schaffen, die sowohl auf dem Server als auch auf dem Client ausgeführt werden konnte. Die Zusammenarbeit mit ihnen führte zur Entdeckung mehrerer Netzwerkfehler, die eine umfassendere Diskussion über Netzwerkbewegung, -vorhersage und -impulse ermöglichten.

Das Netzwerk ist Eigentum des Core Tech-Teams, das die Vorhersagen des Clients sowie die Nachrichten zwischen Server und Client verwaltet. Diese werden während der gesamten Funktion stark beansprucht und erfordern die Unterstützung von Ingenieuren aller Teams, damit die Startrampen richtig funktionieren.

Dieser Prozess ermöglichte es uns auch, dem Core Tech-Team Feedback zur Vernetzung der Bewegungsvorhersage zu geben und half bei der Behebung von Fehlern, indem er in eine tatsächliche Funktion implementiert wurde. Er führte auch zu einer spielerorientierten Implementierung von Instanzen. Zu diesem Zeitpunkt wurden übergeordnete Akteure platziert und mussten dupliziert werden, um eine Variable auf Einzelinstanzbasis zu ändern. Im Rahmen der Launchpad-Entwicklung hatten wir einen Anwendungsfall, um die Instanziierung von Akteuren zu untersuchen und daher einen weiteren tangentialen Tooling-Workflow hinzuzufügen.

Konfiguration für Designer

Nachdem wir nun die Kernfunktionalität unterstützt hatten, mussten wir es den technischen Designern ermöglichen, einzusteigen und die Startrampen zu verwenden. Wir erstellten eine API mit Luau-Skripten, die das Senden einer Nachricht vom Client an den Server erfordert, um einen Start auszulösen. Dies bedeutete, dass die technischen Designer Zugriff auf die Skripte hatten – aber auch auf die Konfigurationen innerhalb jedes Assets für jeden in der Welt platzierten Startrampen-Akteur.

Ursprüngliches Konfigurationsdesign

Datenkonfigurationen

Diese Konfigurationen sind wichtig, da sie es dem technischen Designer ermöglichen, grundlegende Einstellungen zu ändern, ohne eine Logik schreiben zu müssen.

Beispielsweise können Sie ganz einfach einen der folgenden Werte festlegen:

• Die Richtung für die Startrampe
• Ob die Vorwärtsrichtung des Zeichens verwendet wird
• Wie stark die Startkraft ist
• Wenn die Zeichengeschwindigkeit überschrieben wird
• Schauspielerfilter
• Wenn es ein konkretes Ziel gibt, auf das man hinarbeiten möchte

Die Optionen für diese Konfigurationen und ihre technischen Implementierungen wurden mithilfe des technischen Designs erstellt und werden weiterhin weiterentwickelt, um den Designern das beste und realistischste Erlebnis zu bieten.

In-Game-Editor-Ansicht

Codeversion

Skriptkonfigurationen

Neben der Möglichkeit, bestimmte Akteurdetails zu konfigurieren, wurde auch eine Skriptfunktionalität für das technische Design geschaffen, um die Logik bei Bedarf manipulieren zu können. So ermöglichte die Funktion LaunchActor() technischen Designern beispielsweise, Startfunktionen zu verwenden, ohne zunächst eine Startrampe platzieren zu müssen.

Dieses spezielle Tool-Feature wurde ursprünglich nicht von den technischen Designern angefragt, aber nach dem Testen der Launchpads wurde es als kritisches Tool zum Backlog hinzugefügt. Dadurch erhielten die Designer sofortigen Zugriff auf Iterationen, da es parallel zur Skriptfunktion OnTriggerOverlap() funktioniert , die im Code für die Launchpads verwendet wurde, um das System zu starten, das den Akteur startet. Da dies im Skript verfügbar war, konnten die Designer Spielschleifen durch unterschiedliche Abfragen und Startverhalten erstellen.

Luau-Skript für Trigger-Überlappung mit Startrampe

Eine frühe Perspektive für das Scripting und die Konfigurierbarkeit bestand nicht nur darin, technische Designer und Kreative zu unterstützen, sondern auch Spieler, die diese Funktionen eines Tages selbst nutzen werden. Im Zusammenhang mit dieser Funktion haben wir uns viele Gedanken darüber gemacht, wie Spieler Akteure in ihrer Welt starten möchten. Wir haben so viele Diskussionen darüber geführt, wie wir sicherstellen können, dass Spieler in Hytale auf die gleiche Weise bauen und erschaffen können wie Hypixellianer.

Spielerorientierte Entwicklung

Startrampen waren perfekt darauf ausgerichtet, Möglichkeiten für Zusammenarbeit und fachübergreifendes Arbeiten zu schaffen, aber diese Möglichkeiten erschließen sich nicht immer von selbst. Es ist wichtig, sich die Zeit zu nehmen, darüber nachzudenken, wer an einer Funktion arbeitet, wer sie verwenden würde und wie – und dann direkt mit diesen Personen zu sprechen, bevor man auch nur die erste Codezeile schreibt.

Dieser Wert von Feedback und Zusammenarbeit geht über Hypixellianer hinaus. Startrampen sind ein fortlaufender Prozess und werden es auch bleiben, da das Gameplay in Hytale wächst und sich weiterentwickelt. Wir freuen uns darauf zu sehen, wie Startrampen von Spielern auf neue und aufregende Weise implementiert werden und eigene Anwendungsfälle entstehen. Und im Gegenzug werden wir diese Zusammenarbeit weiterhin nutzen, um weiterhin neue, spielerorientierte Tooling-Funktionen in Hytale zu entwickeln und zu erstellen.

Egoperspektive der Startrampe im Spiel

---

Interessiert Sie diese Art von technischen Inhalten? Wir stellen ein! Auf unserer Karriereseite finden Sie Stellenangebote und Bewerbungstipps.