Währung

Fortnite Ecosystem v41.10: Quest API, Camera Components und was das für UEFN-Creator bedeutet

Fortnite Ecosystem v41.10: Quest API, Camera Components und was das für UEFN-Creator bedeutet

Epic veröffentlichte Fortnite Ecosystem v41.10 am 25. Juni, und während die Battle-Royale-Seite neue Sprites und ein zweiwöchiges Sommerevent bekam, ist die eigentliche Geschichte für alle, die in UEFN bauen, das, was gerade in Verse gelandet ist. Zugriff auf die Quest API, programmierbare Kamerasteuerung über Scene Graph, antippbare HUD-Widgets, eine Star-Wars-Droidenarmee und 71 neue LEGO-Steine wurden alle im selben Release ausgeliefert, und zusammen bewegen sie UEFN weiter weg vom Zusammennähen von Geräten und näher daran, die Systeme eines echten Spiels in Code zu schreiben.

Quest API bringt endlich natives Fortschrittstracking nach Verse

Das Hauptfeature ist die Quest API, die in Verse als experimentelles Feature erscheint und es Creators ermöglicht, Quests, Ziele und Belohnungen vollständig im Code zu definieren und sie in Fortnites eigener Quest-UI und im Pausenmenü anzeigen zu lassen, also genau an den Stellen, an denen Spieler bereits nach verfolgten Zielen auf jeder Insel suchen. Das klingt nach einer kleinen Bequemlichkeit, bis man tatsächlich versucht hat, Erfolgstracking, Tutorials oder Sammelsets ohne sie zu bauen: Jede Insel, die diese Art von Fortschritt wollte, musste ihre eigene Tracking-UI von Grund auf bauen, was bedeutete, entweder UMG-Widget-Arbeit zu lernen oder sich mit einem ruckeligen Bildschirmzähler zufriedenzugeben, der überhaupt nicht wie der Rest des Spiels aussah. Die API sendet außerdem Events für Beitritte, Fortschrittsaktualisierungen, Abschlüsse und Belohnungsvergaben, sodass Insel-Logik und HUD-Elemente in Echtzeit auf den Quest-Zustand reagieren können, statt ihn abzufragen.

Der Teil, der Creators am meisten interessieren wird, ist, dass Quests global über jeden Spieler auf einer Insel mit synchronisiertem Echtzeitfortschritt geteilt werden können, was die Tür für kooperative Ziele öffnet, die sich für die ganze Lobby auf einmal aktualisieren, statt den Zustand für jeden Spieler separat zu verfolgen. Der Haken ist im Moment, dass Inseln, die dieses Feature nutzen, noch nicht veröffentlicht werden können, da es noch experimentell ist, sodass jeder, der diese Woche einsteigt, für ein zukünftiges Release prototypisiert, statt sofort auszuliefern. Epic sagt, dass Publishing-Support verfügbar wird, sobald die Quest API die experimentelle Phase verlässt, aber bisher wurde noch kein Release-Zeitraum genannt.

Scene-Graph-Kamerakomponenten legen die Linse in Verse

Scene Graph nimmt weiterhin Bereiche auf, die früher ausschließlich zu Geräten gehörten, und dieses Update gibt Creators direkte Kontrolle auf Code-Ebene über die Kamera selbst. Die neuen experimentellen Komponenten, camera_director_component, perspective_camera_component, orthographic_camera_component und physical_camera_component, lassen dich eine Kamera an jede Entity anhängen, zur Laufzeit zwischen Kameramodi wechseln und Körper- und Linseneigenschaften direkt aus Verse anpassen, statt sich auf feste Geräte-Presets zu verlassen. Das ist deutlich wichtiger, als es klingt, weil Kameraverhalten historisch eines der schwierigeren Dinge war, die in UEFN tiefgehend angepasst werden konnten; eine filmische Zwischensequenz, ein Fahrzeug mit einer richtigen Verfolgerkamera oder ein Puzzlespiel, das eine orthografische Top-down-Ansicht braucht, erforderten früher alle Workarounds. Jetzt geht es darum, die richtige Komponente anzuhängen und die Logik zu schreiben, wobei Creators trotzdem daran denken müssen, dass diese Kamerakomponenten experimentell sind und noch nicht für veröffentlichte Inseln bereit sind.

Besitz-Abfragen lösen ein echtes Multiplayer-Problem

Zusammen mit der Kameraarbeit liefert Scene Graph auch eine neue possessable_component aus, mit der dein Verse-Code abfragen kann, welche Charakter-Entity ein Spieler zu einem bestimmten Zeitpunkt tatsächlich kontrolliert und welche Entities ein bestimmter Spieler kontrolliert, wenn er mehrere Dinge gleichzeitig steuert, etwa einen Charakter, der auch ein Fahrzeug fährt. Das löst ein wirklich nerviges Problem für alle, die Eliminierungstracking, kosmetische Anwendung oder Logik zur Eingabeneuzuordnung bauen: Die Spieleridentität bleibt jetzt über Respawns hinweg konsistent, auch wenn die zugrunde liegenden Entities ausgetauscht werden, sodass ein Skript, das einen Kill gutschreibt oder einen Skin anwendet, nicht mit Entities kämpfen muss, die sich mitten im Match still im Hintergrund geändert haben. Charaktere erhielten außerdem grundlegende Unterstützung dafür, auf Scene-Graph-Mesh-Komponenten als Bewegungsbasis zu stehen und sich darauf zu bewegen, was bedeutet, dass bewegliche Plattformen Spieler jetzt korrekt mitnehmen können, statt sie abrutschen oder zurückbleiben zu lassen.

Antippbare HUD-Widgets schließen die Lücke zwischen PC und Mobile

Benutzerdefinierte HUD-Buttons, die entweder mit dem Custom Button-Widget in UMG oder mit Verse Buttons gebaut wurden, können jetzt zusätzlich zu ausgelösten Eingabeaktionen für Gamepad- und Maus-und-Tastatur-Spieler auf direkte Berührungen auf Touchscreens reagieren, und bemerkenswerterweise funktioniert das ohne einen TouchActionWrapper. Für Inseln, die mit Mobile-Spielern im Blick gebaut wurden, schließt das eine echte Nutzbarkeitslücke: Ein benutzerdefinierter HUD-Button, der für einen Controller-Spieler gut funktionierte, brauchte zuvor zusätzliche Verdrahtung, um sich für jemanden, der auf einen Handybildschirm tippt, genauso zu verhalten. Die Einrichtung ist auf beiden Seiten von UEFNs UI-Tooling unkompliziert: Weise einem Custom Button in UMG eine Triggering Input Action zu und binde einen Verse-Handler an sein On Clicked-Event, oder füge direkt in Verse UI ein Button-Widget hinzu und abonniere seine OnClick-Eigenschaft, und dieselbe Interaktion funktioniert jetzt identisch über Eingabetypen hinweg. Wie die Quest API und die Scene-Graph-Kamerakomponenten sind Custom HUD Widgets jedoch noch experimentell, und Projekte, die sie nutzen, können noch nicht veröffentlicht werden.

Star-Wars-Droiden und LEGO-Steine für seitliches Bauen erweitern die Toolkits

Star-Wars-Inseln erhielten in diesem Release mehr als 30 Droiden, darunter B1-Kampfdroiden, B2-Schwere Droiden, die BB-Serie, die R-Serie, BDX-Entdecker und Gonk-Droiden, jeweils mit einem animationsbereiten Control Rig und einige mit anpassbaren Lackfarben. Eine reitbare Berg-Tauntaun-Variante erschien daneben als neuer NPC-Charaktertyp und gibt Star-Wars-Inseln ein nutzbares Reittier statt nur einer Hintergrundkreatur. Für ein Toolkit, das seit seiner Einführung stetig gewachsen ist, ist das ein großer Charakter-Drop, und die enthaltenen Control Rigs sind besonders wichtig, weil sie bedeuten, dass Creators diese Droiden tatsächlich für Zwischensequenzen oder geskriptete Sequenzen animieren können, statt sie als statische Setpieces zu behandeln.

Der LEGO Brick Editor erhielt 71 neue Steine, die speziell für seitliches Bauen entwickelt wurden, sodass Creators Strukturen nach außen erweitern können, statt nur nach oben zu stapeln. Das adressiert direkt einen klaren Schmerzpunkt für Builder, die mehr horizontale Bauoptionen innerhalb von LEGO-Workflows wollten. Neben den neuen Steinen lieferte Epic eine Reihe von Workflow-Fixes aus, nach denen LEGO-Builder gefragt hatten: Einzelne Steine können jetzt gekragelt werden, ohne zuerst eine Gruppe zu benötigen, die Steinpalette dockt standardmäßig unten im Editor an, statt als separates Fenster aufzuspringen, und das Abbrechen eines Kragle-Dialogs wirft keinen Fehler mehr. Nichts davon ist auffällig, aber jeder, der Zeit im Brick Editor verbracht hat, wird sie als die Art von Reibung erkennen, die wiederholte Bauaufgaben langsamer machte, als sie sein mussten. Eine neue LEGO Brick Index-Seite katalogisiert außerdem jeden Stein und jede Platte nach Typ, was eine echte Zeitersparnis für alle ist, die einen Bau planen, statt durch eine unsortierte Palette zu scrollen.

Unreal Revision Control wird zu Lore

Im selben Release versteckt sich ein Rebranding, das wichtiger ist, als es aussieht: Unreal Revision Control, das Versionskontrollsystem, das UEFN-Teams nutzen, um zu verhindern, dass sie gegenseitig ihre Arbeit überschreiben, heißt jetzt offiziell Lore, ein Name, den Epic auf der Unreal Fest als Dachmarke für seine Versionskontroll- und Inhaltsspeichertechnologie für die Zukunft angekündigt hat. Bestehende Projekte, Versionsverlauf und Workflows werden ohne erforderliche Aktion übernommen, da sich in diesem Release nur der Name geändert hat, aber damit kommt eine echte technische Verschiebung: Epic wechselt von seiner proprietären Oodle-Kompression zum Open-Source-Algorithmus Zstandard, und der neu veröffentlichte Lore-Desktop-Client ist nicht mit UEFN-Projekten kompatibel, bis diese Migration in einem zukünftigen Update abgeschlossen ist. Teams, die auf Drittanbieter-Tooling setzen, sollten außerdem beachten, dass das VS-Code-Plugin vorerst noch den alten Namen Unreal Revision Control zeigt, sodass die Umbenennung noch nicht vollständig über alle Oberflächen hinweg angekommen ist.

Abschließende Gedanken

Keines dieser Systeme ist eine isolierte Ergänzung, sie sind der nächste Schritt in einem Muster, das Epic mit UEFN und Verse verfolgt: Etwas, das früher ein vorgefertigtes Gerät erforderte, nehmen und Creators stattdessen mehr direkte Kontrolle auf Code-Ebene darüber geben. Kameras, Charakterbesitz und jetzt Quest-Fortschritt sind alle weiter aus dem Geräte-Land ins Code-Land gewandert, was bedeutet, dass Inseln, die auf Verse setzen, Fortschrittssysteme, benutzerdefinierte Cinematics und plattformbewusste HUDs bauen können, die vor nicht allzu langer Zeit ernsthafte Workarounds benötigt hätten. Das experimentelle Label ist weiterhin wichtig, weil Quest API, Scene Graph Camera Components und Custom HUD Widgets vorerst nur für Prototypen gedacht sind und noch nicht in veröffentlichten Inseln verwendet werden können. Aber die Richtung ist klar genug: Die Asset- und Workflow-Ergänzungen sind jetzt live, während die größeren Verse-getriebenen Systeme genau das sind, was ernsthafte UEFN-Creators testen sollten, bevor sie veröffentlichungsbereit werden.