Interviews News

Wargaming entwickelt neues Spiel mit Rider for Unreal Engine

Seit anderthalb Jahren ist unser Early-Access-Programm für Rider for Unreal Engine aktiv. Diese neue IDE ermöglicht die Entwicklung von Spielen in C++ unter Verwendung der Unreal Engine. Zehntausende Indie-Spieleentwickler*innen sowie zahlreiche Entwicklerstudios und Unternehmen aller Größen nehmen inzwischen am Programm teil. Wir wollten gerne erfahren, was sie an dem Produkt am meisten schätzen, was ihnen daran gefällt und was sie vielleicht noch vermissen. Dazu baten wir um ein Gespräch mit Viacheslav Dubikovsky, Technical Director bei Wargaming RED, einem Entwicklerstudio, das kürzlich in Moskau als Teil der Wargaming Group Limited gegründet wurde. Das Interview führten Anastasia Kazakova, Product Marketing Manager für .NET- und C++-Tools, und Alexander Pirogov, Project Manager für Rider for Unreal Engine.

Hallo Viacheslav! Könnten Sie uns etwas über das Projekt erzählen, an dem Sie gerade arbeiten? Um was für ein Spiel handelt es sich?

Wir haben den Titel noch nicht bekannt gegeben, daher kann ich Ihnen aufgrund von NDAs nicht viel dazu sagen. Was ich verraten kann: Es handelt sich um einen Session-basierten Third-Person-Sci-Fi-Shooter.

Und Sie verwenden Unreal als Game-Engine?

So ist es. Wir entwickeln das Spiel in C++ und verwenden derzeit Unreal Engine 4.26, sind jedoch dabei, nach und nach auf 4.27 zu migrieren. Ich glaube nicht, dass wir dieses Projekt auf Unreal Engine 5 umstellen werden, da diese Version ein anderes Rendering verwendet und bei einer Migration möglicherweise alle bereits erstellten Spielgrafiken neu erstellt werden müssten.

Wie ist das Projekt strukturiert? Welche Technologien verwenden Sie?

Wie gesagt wird das Projekt in C++ entwickelt und baut auf der Unreal Engine auf. Wir machen intensiven Gebrauch vom Reflexionsmechanismus der Unreal Engine sowie von der Metaprogrammierung mithilfe von C++-Templates. Wir haben zwei Mono-Repositories, eines für das Spiel selbst und eines für die Engine. Die zentrale Spiellogik wird im gemeinsamen Modul gespeichert.

Bei der Verwendung von Code-Editoren stellt der UE-Reflexionsmechanismus in der Regel die größte Herausforderung dar. Es ist schwierig, mit Code zu arbeiten, der von so vielen Makrodefinitionen umgeben ist, die vom sprachlichen Standpunkt aus praktisch bedeutungslos sind. Damit können nur die wenigsten Entwickler*innen etwas anfangen. Und genau hier bringt uns Rider for Unreal Engine die Rettung!

Wie viele Entwickler*innen sind am Projekt beteiligt? Was sind die wichtigsten Tools, die sie verwenden?

Unser Team besteht aus etwa 25 Programmierer*innen. Ein Drittel von ihnen verwendet Rider for UE, und die anderen arbeiten mit verschiedenen Visual-Studio-Versionen. Vor der Einführung von Rider hatten wir Visual Studio verwendet, entweder pur oder in Kombination mit Visual Assist oder ReSharper C++. Aber der VS-Editor hatte oft Leistungsprobleme, egal ob mit oder ohne Plugins. Bei Visual Assist waren uns die Sprachfunktionen nicht genau genug (vielleicht hat sich das inzwischen geändert). Rider for Unreal Engine hingegen hat eine hervorragende Leistung gezeigt, zumindest im Umgang mit UE-Code.

War die Migration zu Rider for Unreal Engine einfach für Sie?

Mein erster Eindruck war: „Wow, die VS-Tastenkürzel werden unterstützt! Ich kann meine VS-Kenntnisse einsetzen.“ In Bezug auf die Benutzeroberfläche scheint Visual Studio in einigen Aspekten benutzerfreundlicher zu sein, z. B. beim Debuggen – wahrscheinlich habe ich einfach nur mehr Erfahrung damit. Aber die Benutzeroberfläche von Rider ist optisch sehr ansprechend, das muss ich zugeben.

Trotzdem kann es schwierig sein, von einem seit Jahren verwendeten Tool zu einem anderen zu wechseln, sodass einige unserer Kolleg*innen bei Visual Studio geblieben sind.

Welche Funktionen von Rider for Unreal Engine waren in Ihrem Projekt bisher am nützlichsten?

Das wären die Navigation, die Verwendungssuche, das Springen zu Symboldeklarationen, zu abgeleiteten und Basissymbolen – wir verwenden diese ständig, sowohl in unserem eigenen Code als auch im Unreal-Engine-Code (da der Engine-Code die Hauptdokumentationsquelle für die Entwickler*innen darstellt). Ein weiterer Schlüssel zur effektiven Nutzung der Unreal Engine besteht darin, Links zu Feldern und Funktionen schnell zu finden und durch den Code zu navigieren – und Rider for Unreal Engine ist besonders gut darin.

Dann gibt es noch die statische Codeanalyse – Inspektionen, die auf Fehler im Code hinweisen. Wenn wir die Fehler direkt im Editor erkennen, noch vor dem Kompilieren, spart das viel Zeit. Wenn solche Fehler die Kompilierungsstufe erreichen, kann es zu einem stundenlangen „Pingpong“ zwischen Compiler und Entwickler kommen. Natürlich finden wir auf diese Weise nicht alle Fehler, insbesondere bei Code, der Templates verwendet. Die Unreal Engine selbst verwendet jedoch kaum Templates, sodass nur ein kleiner Prozentsatz an Fehlern übrig bleibt, der gefunden und behoben werden muss. Inspektionen, die das automatische Hinzufügen von fehlenden include-Direktiven anbieten, helfen ebenfalls, Zeit zu sparen: Dank Rider müssen wir nicht mehr überlegen, welche Header-Dateien inkludiert sind und welche nicht.

Erstaunlich ist auch, dass Rider den in Unreal Engine implementierten Reflexionsmechanismus kennt und Reflexionsbezeichner und Makros automatisch vervollständigen kann. Normalerweise merkt man sich solche Dinge nicht, sodass die Hinweise von Rider das Programmieren wirklich beschleunigen können.

Zu erwähnen ist auch das Parsen von Assets und das Binding von Blueprints mit C++-Quellcode. Diese Funktion wird nicht allzu oft verwendet, aber wenn doch, dann ist sie sehr nützlich. Insbesondere wenn sich beim Refactoring etwas im C++-Quellcode ändert, ist es sehr nützlich, die Verwendungen in Blueprints zu sehen. Gleiches gilt für INI-Konfigurationsdateien und Standardwerte für Klasseneigenschaften: Oft sind die Werte direkt im Code zu sehen, ohne in den INI-Dateien nach ihnen suchen zu müssen.

Nicht zuletzt ist noch die Integration mit dem Unreal Editor zu erwähnen, also die Plugins RiderLink/UnrealLink. Normalerweise starten wir den Unreal Editor aus dem Rider-Debugger, um live darin zu programmieren. Die Möglichkeit, Protokolle direkt in Rider einzusehen, während wir das Spiel pausieren und fortsetzen, bietet manchmal einen echten Geschwindigkeitsschub. Wenn wir beispielsweise Plugins von Drittanbietern verwenden (für die Integration mit Steam oder externen Chats, für die Erstellung der Game-Pipeline usw.), müssen wir nicht einmal zum Editor wechseln – es genügt, die Protokolle zu sehen und den Editor anzuhalten/fortzusetzen.

Da wir gerade beim Thema sind, hätte ich einige Verbesserungsvorschläge in Bezug auf das Unreal-Protokoll:

• Fügen Sie weitere Filteroptionen hinzu. Es gibt Unmengen von Protokollen, manchmal Hunderte oder mehr, daher kann es schwierig sein, die richtigen Kategorien auszuwählen.
• Mehrere Suchergebnisse sollten im Protokoll gleichzeitig markiert werden – dies ist ein sehr häufiger Anwendungsfall.

Vielen Dank für diese Ideen! Wie verhält es sich mit dem Debugger von Rider – verwenden Sie ihn?

Sicher. Ohne Debugger kann sich kein Editor als echtes Entwicklungstool bezeichnen! Vor einiger Zeit hatten wir ein paar Probleme damit, dass der Debugger von Rider nicht an Haltepunkten stoppen wollte, aber das scheint behoben worden zu sein. Die Debugging-Funktion, die wir am häufigsten verwenden, ist definitiv die schrittweise Ausführung des Codes. Manchmal verwenden wir auch bedingte Haltepunkte. Und es gefällt uns, wie der Debugger den Inhalt von Unreal-Engine-Objekten anzeigt.

Debuggen Sie hauptsächlich auf dem Desktop?

Bis jetzt schon. Wir wollen in Zukunft mit Konsolen arbeiten, aber wir sind noch nicht soweit.

Hinweis: Rider ermöglicht noch kein Debugging auf Konsolen. Aber wir sind bereits in Gesprächen mit den großen Konsolenherstellern. Leider können diese Prozesse sehr zeitaufwendig sein, und es gibt bisweilen eine Reihe von bürokratischen Hürden zu überwinden.

Wir wollten auch auf Versionsverwaltungen zu sprechen kommen. Welche verwenden Sie?

Wir nutzen hauptsächlich Git. Neue Funktionen werden aktiv in Branches entwickelt. Wir verwenden die Git-Integration von Rider. Für das Rebasing nutzen wir jedoch den Tortoise-Client, da wir damit das Gesamtbild besser überblicken können. Rebasing ist wahrscheinlich der komplizierteste Git-Vorgang. Wir haben versucht, es zu automatisieren und die Verwendung zu vereinfachen, aber bisher ohne Erfolg.

In einigen anderen Projekten habe ich auch mit Perforce und PlasticSCM gearbeitet.

Profilen Sie Ihren Code? Wenn ja, verwenden Sie Profiling-Tools von Drittanbietern?

Ja, wir analysieren unseren Code mit Unreal Insights. Wenn es um die Erfassung von Profiling-Daten geht, ist das native UE-Tool kaum zu schlagen. Aber in Sachen Visualisierung wären Verbesserungen durchaus möglich. Wir nutzen unser eigenes Tool, um CPU-Auslastungsdiagramme zu zeichnen. Unreal Insight ist perfekt, um Frame-Inhalte zu untersuchen, aber es hilft uns nicht dabei, die gesamte Dynamik zu sehen – deshalb haben wir uns entschieden, unser eigenes Tool zu entwickeln.

Vielen Dank für dieses Gespräch, Viacheslav. Viel Erfolg bei Ihrem Game-Projekt!

Wir freuen uns weiterhin auf Ihre Ideen zur Verbesserung von Rider for Unreal Engine.

Autorin des Original-Blogposts: