Seid gegrüßt, Abenteurer!
Wir werden unser altes Kampf- und Animationssystem aufrüsten, um in Bereichen mit vielen Spielern die Leistung zu verbessern. Dieses Update wird gemeinsam mit Season of the Guardianveröffentlicht. Dank dieses neuen Systems (das wir liebevoll „Slayer Script“ nennen) wird es zukünftig auch leichter für uns, unsere Kämpfe zu verbessern. Wir haben unser Möglichstes getan, das Feeling des Spiels beizubehalten. Deshalb freuen wir uns schon sehr auf eure Rückmeldungen. Vom Entwicklungsprozess bis hin zu Herausforderungen – Tech Lead Kevin Christensen gibt euch einen Einblick in die Bedeutung dieses Systems für die Zukunft von New World.
Slayer Script
Slayer Script ist eine Skriptsprache, die auf C++ basiert. Es wird nativ kompiliert und von New World dynamisch geladen, um hervorragende Leistung zu bieten und Live-Updates an Skripten zu ermöglichen. Es kann Ereignisse starten (Gegner spawnen, Geräusche abspielen usw.), auf Ereignisse reagieren (wenn ein Gegner stirbt, wenn ein Spieler einen Raum betritt usw.), Animationen abspielen, Bewegungen steuern und mehr. In ein paar Codezeilen kann eine ganze Menge Arbeit stecken.
Entwicklungsprozess
New World enthält eine riesige Menge an Objekten, die häufig aktualisiert werden, weshalb herkömmliche Skriptsprachen wenig effizient sind. Eine Skriptsprache wie z. B. Lua wird interpretiert und profitiert nicht von Hardwareoptimierungen. Zwar bietet Lua eine gute Ausführungsleistung, doch müsste sie in New World für Hunderte von Objekten verwendet werden. Der damit verbundene Overhead und der Arbeitsspeicherbedarf machten diese Lösung untragbar. Wir benötigten eine Lösung, die die höchstmögliche Geschwindigkeit mit akzeptablen Auswirkungen auf die Entwicklungsiteration bot.
Unser ursprüngliches Skriptsystem für Charaktere lief in der Entwicklungsphase gut, konnte jedoch hinsichtlich Leistung, Arbeitsspeicher und Laufzeitzuweisung nicht mit dem Wachstum von New World Schritt halten. Da begannen wir in einem Nebenprojekt, Slayer Script als Alternative zu entwickeln. Slayer Script verringerte diese Kosten auf einige wenige Zuweisungen. Sein nativ kompilierter Code ist sehr kompakt, was den Arbeitsspeicherbedarf zur Laufzeit erheblich reduzierte.
Ursprünglich war Slayer Script für die Steuerung des Spielers vorgesehen. Der Spieler ist die mit Abstand aufwendigste Spielfigur in New World. Ein Großteil des Designs war darauf ausgerichtet, die Spielereingaben zu interpretieren und die entsprechenden Animationen zu steuern. Diese Aufgabe sollte viel Zeit in Anspruch nehmen. Allerdings wurde Slayer Script als Erstes von unserem Expeditionsteam verwendet, das keine Spielereingaben oder Animationen benötigte. So verwandelte sich Slayer Script in eine Universal-Skriptsprache. Erst vor Kurzem wurde Slayer Script erstmals für den ihm zugedachten Zweck verwendet.
Zielsetzungen
Über 400 Aktionen wurden von Hand in das neue System übertragen, um sicherzustellen, dass das Spielerlebnis 1-zu-1 übernommen wird. Wir haben folgende Ziele verfolgt:
Verwendung von nativ kompiliertem C++ für maximale Geschwindigkeit.
Senkung der Arbeitsspeicherkosten durch Verringerung der Statusmengen, die gespeichert werden müssen.
Verbesserung der Skalierbarkeit durch Nutzung einer Architektur, die bei neuen Verhaltensweisen die Ausführung weniger stark beeinträchtigt.
Das Spiel sollte zur Laufzeit ladbar sein, um die Laufzeitentwicklung zu unterstützen.
Einfacheres Debugging.
Die Senkung der Arbeitsspeicherkosten war am einfachsten umzusetzen. Slayer Script ist so konzipiert, dass es den Status zentral an einem Speicherort aufbewahrt. Alle Verhaltensweisen wurden so erstellt, dass sie von allen Instanzen eines Skripts gemeinsam verwendet werden können.
Um die Skalierbarkeit werden wir uns weiterhin bemühen. Selbst C++ kann auf ineffiziente Weise verwendet werden. Beim Hinzufügen neuer Funktionen muss sorgfältig vorgegangen werden, aber C++ bietet umfangreiche Lösungen, um die Leistung und Vorgangsausführung zu überwachen.
Beim vorherigen System gestaltete sich die Fehlersuche als schwierig. Es wurden Tools erstellt, doch leider war es nicht möglich, die Programmausführung schrittweise zu untersuchen. Jetzt können Designer mit einem Debugger Programmstopps setzen, den Arbeitsspeicher analysieren und die Skriptausführung schrittweise untersuchen. Prozessbedingt war die Fehlersuche beim vorherigen System äußerst zeitaufwendig. Bei komplexen Skripten ist das Debugging nach wie vor schwierig, doch nun ist zumindest die Methode einfach anzuwenden.
Herausforderungen
Die größte Herausforderung war es, weiterhin schnelle Iterationen zu ermöglichen. Designer müssen die Ergebnisse ihrer Arbeit schnell sehen können. Bei einer kompilierten Sprache müssten sie allerdings das Spiel schließen, Änderungen vornehmen und das Spiel erneut kompilieren und ausführen, um die Ergebnisse zu begutachten. Slayer Script hingegen ist in ein Modul eingebaut, das bei laufendem Spiel geladen werden kann. Ein Modul dynamisch neu zu laden kann knifflig sein. Bezugnahmen auf Objekte im Modul müssen daher vor dem Entladen des Moduls freigegeben und nach dem erneuten Laden des Moduls neu abgerufen werden. Wird dies nicht korrekt gehandhabt, kommt es zu einem Absturz des Spiels oder der Tools.
C++ bietet hinsichtlich Speicher- und Leistungskosten anfänglich großes Potenzial. C++ ist für höchstmögliche Effizienz bei der Entwicklung von High-Performance-Apps ausgelegt. Es handelt sich um eine ausgereifte Sprache mit zahlreichen Tools für die Entwicklung und Leistungsmessung.
Eine weitere Herausforderung bestand darin, die Komplexität von C++ vor den Anwendern von Slayer Script zu verbergen. Die Verwendung von C++ kann schwierig sein. Wenn die Sprache jedoch als Skriptsprache benutzt wird, muss sie nicht komplexer als andere Skriptsprachen sein. Diesbezüglich lässt sich noch vieles verbessern. Wir werden weiter darauf hinarbeiten.
Wir freuen uns auf eure Rückmeldungen im öffentlichen Testbereich von Season of the Guardian. Vielen Dank für eure Unterstützung und wir sehen uns in Aeternum!
