STRIDE-Entwickler Joy Way teilt plattformübergreifende VR-Mehrspieler-Praktiken

Handhabung mehrerer Plattformen auf einem Betriebssystem

Beim Entwickeln von STRIDE standen wir vor der Herausforderung, dass einige VR-Zielplattformen (Pico & Meta Quest) beide auf Android liefen. Dies führte zu Problemen: Nun konnten wir die Configs der Unreal Platform nicht mehr verwenden, um Pico- und Quest-übergreifende Config-Werte zu unterscheiden. Im Code lässt sich normalerweise nicht klären, auf welcher Plattform man ist. Unsere Lösungen sahen wie folgt aus:

Das Konfigurationsproblem lässt sich mit einer Argument-Injektion per -ini im Unreal Buildwerkzeug lösen. Sie können sie in CI/CD-Build-Skripten implementieren und -ini-Konfigurationen ans Unreal Automatisierungswerkzeug senden, um Configs aufzuheben. Übergabe im Format:

Mehr zu Konfigurationsinjektionen hier. Injizierte Config-Werte sind auf gepackte Spiele durch Modifikation des Unreal-Automatisierungswerkzeugs anwendbar. Mehr dazu hier.

Nun können Sie Config-Werte ans UAT senden und sehen, auf welcher Plattform Sie sind.

Nächster Schritt: Plattformdefinitionen für Pico- und Quest-Geräte ergänzen. Man beachte den Unterschied bei GlobalDefinitions aus Zielregeln und PublicDefinitions aus Modulregeln. Normal erstellt UAT zwei Builds: einen für den Editor (um Commandlets während des Builds auszuführen), einen für die Zielplattform. GlobalDefinitions sind Definitions für das Gesamtziel. Das heißt: Eine Plattformdefinition für Pico/Quest in GlobalDefinitions enthält die unerwünschte Plattformdefinition im Editor-Build (zur Ausführung von Commandlets erforderlich). Sie möchten also eine Plattformdefinition in den PublicDefinitions der Modulregeln platzieren. So gehen Sie dabei vor:

Nun zeigen Präprozessor-Direktiven, auf welcher Plattform Sie im C++-Code sind, und nutzen BlueprintFunctionLibrary zur Bereitstellung von Plattformchecks für Blueprints.

Wir fingen damit an, API-Aufrufe mit Lambda-Funktionscallbacks für Antworten zu implementieren. Bald hatten wir jedoch einen Haufen verschachtelter Aufrufe, und die Codepflege wurde zunehmend schwierig. So machten wir jede Anforderung zur eigenen UBlueprintAsyncActionBase.

Es ist recht einfach, automatisch generierte UBlueprintAsyncActionBase-Knoten in Blueprints zu verwenden. Hier ist der Programmier -Guide.
 

Jetzt entzaubere ich die UObject-Erweiterung und gebe ein paar weniger bekannte Tipps.

In erster Linie wollen Sie nur eines erweitern. GetWorld, um globale Funktionen mit WorldContext aufzurufen. Hier ein Codebeispiel für den Worker GetWorld-Override.

Achten Sie auf die erste Kontrolle bei CDO. Das ergibt dann später Sinn.

Hier ist das Code-Beispiel zur Erstellung von Worker.

Ich fasse zusammen. Sie sollten von UObject ableiten, GetWorld übergehen, dann vom C++-Worker ableiten und final das richtige Objekt im Lebenszykluskern Ihres Workers instanziieren. So erhält man eine Klasse aus Blueprints als Instanz eines korrekten Objekts.

Nun zu CDO: Wie Sie sehen, weisen wir die TSubclassOf-Variable beim Bau von GameInstanceSubsystem zu. Und da könnten Sie Probleme kriegen, es sei denn, Sie prüfen auf CDO. Wir hatten es ohne CDO-Check mit Editor-Crashs und Problemen im Assetsystem zu tun. Das könnte bei Ihnen also vielleicht auch auftreten.

Die Trennung der Anforderungen und die Offenlegung der Anforderungsketten in Blueprint-Graphen halfen uns, „Spaghetti-Code“ loszuwerden, und erleichterten die Wartung des Backend-Codes, was für kürzere Iterationen und weniger Bugs sorgte.