{"id":204798,"date":"2021-11-17T13:22:00","date_gmt":"2021-11-17T12:22:00","guid":{"rendered":"https:\/\/blog.jetbrains.com\/dotnet\/2021\/11\/09\/wargaming-uses-rider-for-unreal-engine-to-develop-its-new-game\/"},"modified":"2021-11-24T10:32:50","modified_gmt":"2021-11-24T09:32:50","slug":"wargaming-uses-rider-for-unreal-engine-to-develop-its-new-game","status":"publish","type":"dotnet","link":"https:\/\/blog.jetbrains.com\/de\/dotnet\/2021\/11\/17\/wargaming-uses-rider-for-unreal-engine-to-develop-its-new-game\/","title":{"rendered":"Wargaming entwickelt neues Spiel mit Rider for Unreal Engine"},"content":{"rendered":"\n

Seit anderthalb Jahren ist unser Early-Access-Programm f\u00fcr Rider for Unreal Engine<\/a> aktiv. Diese neue IDE erm\u00f6glicht die Entwicklung von Spielen in C++ unter Verwendung der Unreal Engine. Zehntausende Indie-Spieleentwickler*innen sowie zahlreiche Entwicklerstudios und Unternehmen aller Gr\u00f6\u00dfen nehmen inzwischen am Programm teil. Wir wollten gerne erfahren, was sie an dem Produkt am meisten sch\u00e4tzen, was ihnen daran gef\u00e4llt und was sie vielleicht noch vermissen. Dazu baten wir um ein Gespr\u00e4ch mit Viacheslav Dubikovsky, Technical Director bei Wargaming RED, einem Entwicklerstudio, das k\u00fcrzlich in Moskau als Teil der Wargaming Group Limited gegr\u00fcndet wurde. Das Interview f\u00fchrten Anastasia Kazakova, Product Marketing Manager f\u00fcr .NET- und C++-Tools, und Alexander Pirogov, Project Manager f\u00fcr Rider for Unreal Engine.<\/p>\n\n

\n
\n
\n
\n \"\"\n <\/div>\n
\n

Viacheslav Dubikovsky<\/h4>\n

Technical Director bei Wargaming RED<\/p>\n <\/div>\n <\/div>\n <\/div>\n <\/div>\n\n\n

Hallo Viacheslav! K\u00f6nnten Sie uns etwas \u00fcber das Projekt erz\u00e4hlen, an dem Sie gerade arbeiten? Um was f\u00fcr ein Spiel handelt es sich?<\/em><\/strong><\/p>\n

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.<\/p>\n

Und Sie verwenden Unreal als Game-Engine?<\/em><\/strong><\/p>\n

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\u00f6glicherweise alle bereits erstellten Spielgrafiken neu erstellt werden m\u00fcssten.<\/p>\n

\"WG<\/p>\n

Wie ist das Projekt strukturiert? Welche Technologien verwenden Sie?<\/em><\/strong><\/p>\n

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\u00fcr das Spiel selbst und eines f\u00fcr die Engine. Die zentrale Spiellogik wird im gemeinsamen Modul gespeichert.<\/p>\n

Bei der Verwendung von Code-Editoren stellt der UE-Reflexionsmechanismus in der Regel die gr\u00f6\u00dfte 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\u00f6nnen nur die wenigsten Entwickler*innen etwas anfangen. Und genau hier bringt uns Rider for Unreal Engine die Rettung!<\/p>\n

Wie viele Entwickler*innen sind am Projekt beteiligt? Was sind die wichtigsten Tools, die sie verwenden? <\/em><\/strong><\/p>\n

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\u00fchrung 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\u00e4ndert). Rider for Unreal Engine hingegen hat eine hervorragende Leistung gezeigt, zumindest im Umgang mit UE-Code.<\/p>\n

War die Migration zu Rider for Unreal Engine einfach f\u00fcr Sie? <\/em><\/strong><\/p>\n

Mein erster Eindruck war: \u201eWow, die VS-Tastenk\u00fcrzel werden unterst\u00fctzt! Ich kann meine VS-Kenntnisse einsetzen.\u201c In Bezug auf die Benutzeroberfl\u00e4che scheint Visual Studio in einigen Aspekten benutzerfreundlicher zu sein, z. B. beim Debuggen \u2013 wahrscheinlich habe ich einfach nur mehr Erfahrung damit. Aber die Benutzeroberfl\u00e4che von Rider ist optisch sehr ansprechend, das muss ich zugeben.<\/p>\n

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.<\/p>\n

Welche Funktionen von Rider for Unreal Engine waren in Ihrem Projekt bisher am n\u00fctzlichsten?<\/em><\/strong><\/p>\n

Das w\u00e4ren die Navigation, die Verwendungssuche, das Springen zu Symboldeklarationen, zu abgeleiteten und Basissymbolen \u2013 wir verwenden diese st\u00e4ndig, sowohl in unserem eigenen Code als auch im Unreal-Engine-Code (da der Engine-Code die Hauptdokumentationsquelle f\u00fcr die Entwickler*innen darstellt). Ein weiterer Schl\u00fcssel zur effektiven Nutzung der Unreal Engine besteht darin, Links zu Feldern und Funktionen schnell zu finden und durch den Code zu navigieren \u2013 und Rider for Unreal Engine ist besonders gut darin.<\/p>\n

Dann gibt es noch die statische Codeanalyse \u2013 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 \u201ePingpong\u201c zwischen Compiler und Entwickler kommen. Nat\u00fcrlich 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 \u00fcbrig bleibt, der gefunden und behoben werden muss. Inspektionen, die das automatische Hinzuf\u00fcgen von fehlenden include<\/code>-Direktiven anbieten, helfen ebenfalls, Zeit zu sparen: Dank Rider m\u00fcssen wir nicht mehr \u00fcberlegen, welche Header-Dateien inkludiert sind und welche nicht.<\/p>\n

Erstaunlich ist auch, dass Rider den in Unreal Engine implementierten Reflexionsmechanismus kennt und Reflexionsbezeichner und Makros automatisch vervollst\u00e4ndigen kann. Normalerweise merkt man sich solche Dinge nicht, sodass die Hinweise von Rider das Programmieren wirklich beschleunigen k\u00f6nnen.<\/p>\n

Zu erw\u00e4hnen 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\u00fctzlich. Insbesondere wenn sich beim Refactoring etwas im C++-Quellcode \u00e4ndert, ist es sehr n\u00fctzlich, die Verwendungen in Blueprints zu sehen. Gleiches gilt f\u00fcr INI-Konfigurationsdateien und Standardwerte f\u00fcr Klasseneigenschaften: Oft sind die Werte direkt im Code zu sehen, ohne in den INI-Dateien nach ihnen suchen zu m\u00fcssen.<\/p>\n

Nicht zuletzt ist noch die Integration mit dem Unreal Editor zu erw\u00e4hnen, also die Plugins RiderLink\/UnrealLink. Normalerweise starten wir den Unreal Editor aus dem Rider-Debugger, um live darin zu programmieren. Die M\u00f6glichkeit, Protokolle direkt in Rider einzusehen, w\u00e4hrend wir das Spiel pausieren und fortsetzen, bietet manchmal einen echten Geschwindigkeitsschub. Wenn wir beispielsweise Plugins von Drittanbietern verwenden (f\u00fcr die Integration mit Steam oder externen Chats, f\u00fcr die Erstellung der Game-Pipeline usw.), m\u00fcssen wir nicht einmal zum Editor wechseln \u2013 es gen\u00fcgt, die Protokolle zu sehen und den Editor anzuhalten\/fortzusetzen.<\/p>\n

Da wir gerade beim Thema sind, h\u00e4tte ich einige Verbesserungsvorschl\u00e4ge in Bezug auf das Unreal-Protokoll:<\/p>\n