.NET Tools
Essential productivity kit for .NET and game developers
Wargaming utilise Rider for Unreal Engine pour développer son nouveau jeu
Depuis un an et demi, nous proposons le programme d’accès anticipé à Rider for Unreal Engine, notre nouvel IDE pour le développement de jeux en C++ avec Unreal Engine. Le programme a déjà attiré des dizaines de milliers de développeurs indépendants, ainsi que de nombreux studios et entreprises de développement de jeux de toutes tailles. Nous étions curieux de découvrir ce qui leur était le plus utile dans ce produit, ce qu’ils appréciaient le plus, et ce qui pouvait y manquer. Nous en avons pu en apprendre plus en échangeant avec Viacheslav Dubikovsk, Directeur technique chez Wargaming RED, un studio de développement de jeux récemment ouvert à Moscou et faisant partie de Wargaming Group Limited. L’entretien a été conduit par Anastasia Kazakova, Responsable Marketing Produit pour les outils .NET et C++, et Alexander Pirogov, Chef de Projet de Rider for Unreal Engine.
Bonjour Viacheslav ! Pouvez-vous nous parler du projet sur lequel vous travaillez actuellement ? De quel type de jeu s’agit-il ?
Nous n’avons pas encore annoncé le titre du jeu, je ne peux donc pas vous en dire plus pour des raisons de confidentialité. Ce que je peux dire c’est qu’il s’agit d’un jeu de tir de science-fiction, à la troisième personne et en session.
Et vous utilisez Unreal comme moteur de jeu ?
Oui, c’est exact. Nous développons le jeu en C++ et nous utilisons Unreal Engine 4.26 pour le moment, mais nous sommes en train de migrer vers la version 4.27. Je ne pense pas que nous utiliserons Unreal Engine 5 pour ce projet car cette version a un rendu différent et migrer pourrait avoir pour conséquence de devoir refaire tous les graphismes déjà créés.
Comment le projet est-il organisé ? Quelles technologies utilisez-vous ?
Comme je le disais, le projet est écrit en C++ et est développé sur Unreal Engine. Nous utilisons beaucoup le mécanisme de réflexion d’Unreal Engine, ainsi que la métaprogrammation de modèles en C++. Nous avons deux référentiels Mono, un pour le jeu lui-même et un pour le moteur. La logique de jeu principale est stockée dans le module partagé.
Lorsqu’on utilise des éditeurs de code, le mécanisme de réflexion de UE présente généralement les plus grands défis. Il est difficile de travailler avec du code qui est entouré de tant de définitions de macro qui, du point de vue du langage, n’ont pratiquement aucune signification. Très peu de développeurs peuvent gérer cela. C’est là que Rider for Unreal Engine nous sauve la vie !
Combien de développeurs sont impliqués dans le projet ? Quels sont les principaux outils qu’ils utilisent ?
Notre équipe comprend environ 25 programmeurs. Un tiers d’entre eux utilisent Rider for Unreal Engine et les autres travaillent avec différentes versions de Visual Studio. Avant d’utiliser Rider, nous utilisions Visual Studio, soit la version basique, soit en combinaison avec Visual Assist ou ReSharper C++. Mais avec ou sans plugins, l’éditeur VS rencontrait souvent des problèmes de performance. Avec Visual Assist, les fonctionnalités du langage n’étaient pas assez précises pour nous (bien que je pense que les choses doivent être différentes maintenant). Rider for Unreal Engine, en revanche, a fait preuve d’une excellente performance, du moins en ce qui concerne le traitement du code UE.
La migration vers Rider for Unreal Engine a-t-elle été facile pour vous ?
Ma première impression a été : « Waouh, ça prend en charge les raccourcis clavier de VS ! Toutes mes connaissances de VS vont m’être utiles ». En ce qui concerne l’interface utilisateur, celle de Visual Studio a l’air plus facile à utiliser pour certains aspects, comme le débogage, sûrement parce que j’y suis plus habitué. Mais je dois admettre que l’interface utilisateur de Rider est très attractive visuellement.
Néanmoins, il peut être difficile de se défaire d’un outil que l’on utilise depuis des années, c’est pourquoi certains de nos collègues restent fidèles à Visual Studio.
Quelles fonctionnalités de Rider for Unreal Engine vous ont été les plus utiles dans votre projet jusqu’à maintenant ?
Je dirais la navigation, trouver les utilisations, passer à la déclaration de symbole, accéder aux symboles dérivés et de base. Nous utilisons ces éléments tout le temps, à la fois dans notre propre code et dans le code de Unreal Engine (car le code du moteur est la principale source de documentation pour les développeurs). L’un des points clés pour bien utiliser Unreal Engine est de pouvoir trouver rapidement les liens vers les champs et les fonctions et de naviguer dans le code, et Rider for Unreal Engine est particulièrement efficace pour cela.
Ensuite, il y a l’analyse du code statique, avec les inspections qui signalent les erreurs dans votre code. Quand vous pouvez voir les erreurs directement dans l’éditeur, avant même de compiler, vous gagnez beaucoup de temps. Si ces erreurs arrivent jusqu’à l’étape de la compilation, cela peut générer des heures de « ping-pong » entre le compilateur et le développeur. Bien sûr, nous ne détectons pas toutes les erreurs de cette manière, en particulier dans les modèles de code. Mais Unreal Engine n’utilise quasiment pas de modèle, il ne reste donc qu’un faible pourcentage d’erreurs à trouver et à corriger. Les inspections qui suggèrent l’ajout automatique de directives include manquantes aident également à gagner du temps : grâce à Rider, vous n’avez plus à vous demander quels fichiers d’en-tête sont inclus et lesquels ne le sont pas.
C’est qui est génial aussi avec Rider est sa connaissance du mécanisme de réflexion implémenté dans Unreal Engine et sa capacité à compléter automatiquement les identificateurs de réflexion et les macros. Généralement, on ne de mémorise pas de telles informations, les conseils de Rider aident donc vraiment à accélérer le codage.
Je dois également mentionner l’analyse des actifs et la liaison des Blueprints avec le code source C++. Cette fonctionnalité n’est pas la plus utilisée, mais quand elle l’est, elle s’avère très utile. C’est particulièrement le cas quand on refactorise et que quelque chose change dans le code source en C++ : il est alors très utile de voir les utilisations dans les Blueprints. Idem avec les fichiers INI et les valeurs par défaut des propriétés de classes : vous pouvez souvent voir les valeurs directement dans le code, sans avoir à rechercher dans les fichiers INI.
Le dernier élément, et non des moindres, c’est l’intégration avec Unreal Editor, c’est-à-dire les plugins RiderLink/UnrealLink. Généralement, nous lançons Unreal Editor depuis le débogueur Rider pour y programmer en direct. La possibilité de voir les journaux lorsque nous mettons en pause et reprenons le jeu, sans quitter Rider, peut parfois apporter une aide significative. Par exemple, si nous utilisons des plugins tiers (pour intégrer Steam ou des chats externes, créer le pipeline du jeu, etc.), nous n’avons même pas à basculer sur l’éditeur : voir les journaux et mettre en pause/reprendre l’éditeur est suffisant.
D’ailleurs, j’ai quelques suggestions pour améliorer le journal d’Unreal :
- Ajouter des options de filtrage supplémentaires. Il existe une multitude de journaux, parfois des centaines ou plus, il peut donc être difficile de choisir les bonnes catégories.
- Mettre en évidence plusieurs correspondances dans le journal en même temps – il s’agit d’un cas d’utilisation vraiment courant.
Merci pour ces idées ! Que pensez-vous du débogueur de Rider, l’utilisez-vous ?
Bien sûr. Aucun éditeur sans débogueur ne peut prétendre être un véritable outil de développement ! Au début, nous avons rencontré quelques problèmes avec le débogueur de Rider, qui ne s’arrêtait pas aux points d’arrêt, mais il semble que cela a été corrigé. La fonction de débogage que nous utilisons le plus est définitivement le code pas à pas. Parfois, nous utilisons des points d’arrêts conditionnels. Et nous apprécions la manière dont le débogueur affiche les contenus des objets Unreal Engine.
Vous déboguez principalement sur le bureau ?
Pour l’instant, oui. Nous envisageons de travailler avec des consoles à l’avenir, mais nous ne sommes pas encore prêts.
Remarque : malheureusement, Rider ne permet pas le débogage sur console pour le moment. Nous sommes en discussion avec les principaux fabricants de consoles à ce sujet. Ces processus peuvent prendre beaucoup de temps, avec parfois des obstacles administratifs.
Nous voulions aussi parler des systèmes de contrôles de versions. Lesquels utilisez-vous ?
Nous utilisons principalement Git, avec de nouvelles fonctionnalités développées activement en branches. Nous utilisons l’intégration de Git avec Rider. Pour le rebasage, cependant, nous utilisons le client Tortoise, car il nous permet d’avoir une meilleure vue d’ensemble. Le rebasage est sûrement l’opération de Git la plus complexe. Nous avons essayé de l’automatiser et de la rendre plus facile à utiliser, mais nous n’y sommes pas arrivés pour le moment.
Dans certains de mes autres projets, j’ai aussi travaillé avec Perforce et PlasticSCM.
Profilez-vous votre code ? Si c’est le cas, utilisez-vous des outils de profilage tiers ?
Oui, nous analysons notre code avec Unreal Insights. Lorsqu’il s’agit de recueillir des informations de profilage, l’outil natif d’Unreal Engine est difficile à battre. Mais en matière de visualisation, des améliorations sont certainement possibles. Nous utilisons notre propre outil pour tracer des graphiques d’utilisation de CPU. Unreal Insight est bien pour inspecter les contenus des frames, mais il n’aide pas à voir toutes les dynamiques, c’est pourquoi nous avons décidé de concevoir notre propre outil.
Merci de nous avoir consacré du temps pour cet entretien, Viacheslav ! Bonne chance pour votre projet de jeu !
Nous avons hâte de recevoir vos idées d’améliorations pour Rider for Unreal Engine.
Auteur de l’article original en anglais :
Subscribe to a monthly digest curated from the .NET Tools blog:
