.NET Tools
Essential productivity kit for .NET and game developers
Разработка новой игры от компании Wargaming с помощью Rider for Unreal Engine
Последние полтора года открыта программа раннего доступа к Rider for Unreal Engine — IDE для разработки игр на C++ с использованием Unreal Engine. На сегодняшний день в программе участвуют десятки тысяч индивидуальных разработчиков игр, a также множество студий и больших компаний, занимающихся игровой разработкой. Нам стало интересно узнать, за что эти люди ценят наш продукт, что им нравится и чего не хватает.
Мы решили поговорить с Вячеславом Дубиковским — техническим директором в компании Wargaming RED, которая совсем недавно начала свою работу в Москве. Интервью брали Анастасия Казакова, менеджер по продуктовому маркетингу инструментов для .NET и C++, и Александр Пирогов, менеджер проекта в Rider for Unreal Engine.
Вячеслав, расскажите о проекте, которым вы занимаетесь. Что за игра?
Мы еще не анонсировали проект, из-за NDA рассказать о нем подробно пока не могу. Но это будет новый сессионный Sci-Fi шутер от третьего лица.
Я правильно понимаю, что в качестве игрового движка вы используете Unreal Engine?
Да, все так. Мы пишем игру на C++ с использованием Unreal Engine (пока это версия 4.26, но потихоньку мигрируем на 4.27). На Unreal Engine 5 проект вряд ли переедет, так как в этой версии меняется рендеринг и поэтому потребуется менять весь арт, уже подготовленный для игры.
Расскажите вкратце об устройстве проекта. Есть ли какие-то особенности? Какие технологии используете?
Как я уже говорил, проект написан на C++ и построен на движке Unreal Engine. Мы активно используем как возможности рефлексии из Unreal Engine, так и шаблонное метапрограммирование на C++. Наш проект представляет собой два больших монорепозитория: собственно сама игра и ее движок. Базовая игровая логика находится в общем модуле.
Основную проблему при работе в редакторах кода представляет механизм рефлексии UE. Немногие могут работать с кодом, обернутым таким количеством макроопределений, которые с точки зрения языка, в общем-то, ничего не значат. Тут Rider for Unreal Engine, бесспорно, отлично справляется!
Сколько разработчиков участвует в проекте? Какие инструменты они в основном используют?
В команде около 25 программистов. Треть из них использует Rider for UE, остальные работают в различных версиях Visual Studio. До Rider мы пользовались Visual Studio — без плагинов, с плагином Visual Assist либо с ReSharper C++. Однако мы часто сталкивались с проблемой производительности редактора — независимо от того, подключали мы ReSharper C++ или работали без плагинов. При использовании Visual Assist нам не хватало точности языковых возможностей (хотя допускаю, что сейчас что-то уже поменялось). В то же время Rider for Unreal Engine нам кажется явным лидером по производительности — по крайней мере, при работе с кодом Unreal Engine.
Легко ли проходила миграция на Rider for Unreal Engine?
Моим первым впечатлением было: «Как классно, что тут есть поддержка раскладки клавиш Visual Studio! Теперь я могу применять здесь все знания и умения, полученные при работе в VS». Поскольку интерфейс Visual Studio мне более знаком, в ряде аспектов (например, при работе в отладчике) он мне кажется более удобным. С другой стороны, интерфейс Rider очень приятен визуально.
Менять инструмент, которым пользуешься много лет, конечно, не всем легко. Так что многие пока продолжают пользоваться Visual Studio.
Какие возможности Rider for Unreal Engine оказались наиболее полезными для вашего проекта?
Во-первых, это навигация, поиск использований, переход к декларации символа, поиск наследников и предков символа — то, что мы делаем постоянно, и не только в своем коде, но и в коде Unreal Engine, ведь код движка является основной документацией для разработчиков. Также одним из ключей к эффективной работе с Unreal Engine является умение быстро находить ссылки на поля и функции и мгновенно перемещаться по коду — тут Rider for UE отлично справляется.
Дальше, это статический анализ кода, то есть подсказки об ошибках, допущенных при его написании. Возможность увидеть ошибки в редакторе до компиляции позволяет сэкономить много времени. Ведь если мы дойдем с этими ошибками до стадии компиляции, это может обернуться часами «пинг-понга» между компилятором и разработчиком. Конечно, не все ошибки можно так выловить, особенно в шаблонизированном коде. Но сам Unreal Engine почти не использует шаблоны, поэтому остается лишь небольшой процент ошибок. Подсказки об отсутствующих директивах include и их автоматическая подстановка также помогают сэкономить время: Rider избавляет от необходимости залезать в шапку файла и разбираться, какие заголовочные файлы подключены, а какие нет.
Очень круто, что Rider знает о механизме рефлексии, реализованном в Unreal Engine, и предлагает автодополнение для идентификаторов и макросов рефлексии. Сам обычно плохо помнишь такие вещи, поэтому эти подсказки существенно ускоряют разработку.
Тут же упомяну парсинг ассетов и связывание Blueprints с исходным кодом на C++. Эта возможность используется нечасто, но от этого она не менее полезна, особенно во время рефакторинга кода: когда что-то меняется в исходниках на C++, очень полезно увидеть использования в Blueprints. Похожая ситуация для конфигурационных .ini-файлов и значений по умолчанию полей класса: зачастую вы сможете увидеть значения уже в самом коде, без необходимости копаться в .ini-файлах.
Также стоит упомянуть интеграцию с редактором Unreal, а именно плагины RiderLink/UnrealLink. Обычный подход к разработке — это запуск редактора Unreal из отладчика Rider, после чего разработка ведется непосредственно из редактора с использованием Live Coding. Возможность видеть логи, запуская и останавливая игру прямо из Rider, иногда существенно ускоряет разработку. К примеру, если мы работаем со сторонними плагинами (интеграция со Steam, интеграция со сторонними чатами, разработка пайплайна игры и т. п.), нам даже не нужно переходить в редактор — достаточно видеть логи, запускать и останавливать редактор.
Кстати, по Unreal-логу у меня есть несколько пожеланий:
- Добавить больше возможностей фильтрации. Логов очень много, поэтому тяжело выбрать нужные категории из имеющихся, ведь их могут быть сотни.
- Подсвечивать в логе сразу несколько введенных терминов (это частая ситуация).
Спасибо за идеи! Скажите, а отладчиком Rider вы пользуетесь?
Конечно. Без отладчика редактор не может стать полноценным инструментом разработки. В прошлом были проблемы: отладчик мог не остановиться в указанных точках. Но, кажется, эти проблемы были исправлены. Самая часто используемая возможность отладчика — это, конечно, пошаговая отладка. Иногда мы используем условные точки останова. И нам нравится, как содержимое объектов Unreal Engine отображается в отладчике.
Отладка происходит в основном на десктопе?
Пока да. В будущем мы планируем работу с консолями, но пока не дошли до этого.
Примечание: пока, к сожалению, отладка на консолях из Rider невозможна. Мы ведем переговоры с основными производителями консолей. Такие процессы занимают долгое время, отчасти — из-за бюрократии.
Еще мы хотели поговорить о системах контроля версий. Какие из них вы используете?
В основном это Git и активный процесс разработки новых фичей в ветках. Мы пользуемся интеграцией Git с Rider. Только для операции rebase мы используем клиент Tortoise: там мы видим больше информации об общей картине. Rebase — наверное, самая сложная операция в Git. Наши попытки ее автоматизировать и при этом сделать удобной в использовании пока что успехом не увенчались.
Что касается других проектов, то я работал с Perforce и PlasticSCM.
А вы профилируете свой код? Используете для этого какие-то сторонние инструменты?
Да, мы анализируем код с помощью Unreal Insights. Вряд ли можно сделать внешний инструмент более эффективным, чем нативный от Unreal Engine. Это если говорить о сборе информации о профилировании. Для визуализации, конечно, возможны улучшения, и у нас есть свой внутренний инструмент, который строит графики расхода процессорного времени. Содержимое кадра можно рассмотреть и через Unreal Insight, а вот картину целиком в динамике увидеть трудно, и для этого мы решили создать собственный инструмент.
Спасибо большое за разговор, Вячеслав! Удачи вам с проектом!
Мы будем рады вашим идеям по улучшению Rider for Unreal Engine.
Автор оригинальной статьи:
Subscribe to a monthly digest curated from the .NET Tools blog:
Discover more
Wargaming Uses Rider for Unreal Engine to Develop Its New Game
For the past year and a half we’ve been running the Early Access Program for Rider for Unreal Engine – our new IDE for developing games in C++ using Unreal Engine. The program has attracted tens of thousands of indie game developers as well as numerous gamedev studios and companies of all sizes. We were curious to discover what they value the most in the product, what they like about it, and what they might be missing. We decided to talk with Viacheslav Dubikovsky, Technical Director at Wargaming RED, a gamedev studio that recently opened in Moscow, Russia, as part of Wargaming Group Limited. The interview was conducted by Anastasia Kazakova, Product Marketing Manager for .NET and C++ tools, and Alexander Pirogov, Project Manager in Rider for Unreal Engine.
Hi Viacheslav! Could you please tell us about the project you’re working on? What kind of game is it?
We haven’t announced the title yet, so I cannot tell you much about it because of NDAs. What I can say is it’s a Sci-Fi, session-based, third-person shooter.
And you’re using Unreal as the game engine?
Yes, that’s right. We’re developing the game in C++ and using Unreal Engine 4.26 for now, but gradually migrating to 4.27. I don’t think we’ll move this project to Unreal Engine 5, as that version has different rendering and migrating to it could have possibly resulted in us having to redo all the game art we’ve already created.
How is the project organized? What technologies are you using?
As I said, the project is written in C++ and built on Unreal Engine. We’re making heavy use of the Unreal Engine reflection mechanism, as well as C++ template metaprogramming. We have two mono repositories, one for the game itself and one for the engine. The main game logic is stored in the shared module.
When using code editors, the UE reflection mechanism usually presents the biggest challenges. It’s tough to work with code that’s wrapped with so many macro definitions, which are virtually meaningless from the standpoint of the language itself. Very few developers can handle that. And this is where Rider for Unreal Engine saves the day!
How many developers are involved in the project? What are some of the main tools they’re using?
Our team has about 25 programmers. A third of them are using Rider for UE, and the others are working in various versions of Visual Studio. Before adopting Rider, we used Visual Studio, either vanilla or with Visual Assist or ReSharper C++. But with or without plugins, the VS editor would often run into performance issues. With Visual Assist, the language features weren’t accurate enough for us (though I suppose things might be different now). Rider for Unreal Engine, on the contrary, has demonstrated stellar performance, at least when dealing with UE code.
Was it easy for you to migrate to Rider for Unreal Engine?
My first impression was: “Wow, it supports the VS keyboard shortcuts! All my VS skills are going to come in handy.” When it comes to the user interface, Visual Studio’s UI seems more user-friendly in some aspects, like debugging, probably because I just have more experience with it. But Rider’s UI is very attractive visually, I’ll give it that.
Still, it can be tricky to migrate away from a tool you’ve used for years, so some of our colleagues are sticking with Visual Studio.
What features of Rider for Unreal Engine are turning out to be the most useful in your project so far?
That would be navigation, find usages, jumping to symbol declaration, going to derived and base symbols – we use those all the time, both in our own code and in Unreal Engine code (as the engine code is the main source of documentation for developers). Another key to using Unreal Engine effectively is quickly finding links to fields and functions and navigating through code – and Rider for Unreal Engine excels at that.
Then there’s static code analysis – inspections that point to errors in your code. When you see the errors right in the editor, even before compiling, that saves a lot of time. If errors like that ever reach the compilation stage, it could mean hours of “ping-pong” between the compiler and the developer. Sure, we don’t spot all the errors this way, especially in templated code. But Unreal Engine itself barely uses templates, so that leaves just a small percentage of errors to find and fix. Inspections that suggest automatically adding missing include directives also help save time: thanks to Rider, you don’t have to wonder which header files are included and which aren’t.
It’s also amazing that Rider knows about the reflection mechanism implemented in Unreal Engine and provides autocompletion for reflection identifiers and macros. You don’t normally memorize such things, so Rider’s hints can really speed up your coding.
I also have to mention parsing assets and binding Blueprints with C++ source code. This feature isn’t used all that often, but when it is, it’s very valuable. Especially when you’re refactoring and something changes in your C++ source code, it’s very useful to see the usages in Blueprints. Same with config INI files and default values for class properties: you can often see the values right in the code, without having to search in the INI files.
Last but not least, there’s the integration with the Unreal Editor, meaning the RiderLink/UnrealLink plugins. Typically, we launch the Unreal Editor from the Rider debugger and then do Live Coding in it. The ability to see logs as we pause and resume the game, without leaving Rider, can sometimes provide a significant boost. For example, if we’re using third-party plugins (to integrate with Steam or external chats, build the game pipeline, and so on), we don’t even have to switch to the editor – seeing the logs and pausing/resuming the editor is enough.
Speaking of which, I have a couple of suggestions for how you could enhance the Unreal log:
- Add more filtering options. There are tons of logs, sometimes hundreds or more, so it can be difficult to choose the right categories.
- Highlight multiple matches in the log at the same time – this is a really common use case.
Thank you for these ideas! How about Rider’s debugger, do you use it?
Sure. Without a debugger, no editor can call itself a true development tool! Well, earlier we did encounter a few problems with Rider’s debugger not stopping at breakpoints, but it looks like they’ve been fixed. The debugging feature we use most often is definitely stepping through code. Sometimes we use conditional breakpoints. And we like how the debugger displays the contents of Unreal Engine objects.
Do you mostly debug on the desktop?
So far, yes. We’re planning to work with consoles in the future, but we’re not there yet.
Note: unfortunately, Rider doesn’t yet allow debugging on consoles. We’re in talks with the major console manufacturers about this. These processes can take a long time, sometimes with a number of bureaucratic hoops to jump through.
We also wanted to talk about version control systems. Which ones do you use?
We mostly use Git, with new features actively developed in branches. We use Git’s integration with Rider. For rebasing, though, we use the Tortoise client, as it lets us see the bigger picture better. Rebase is probably the most complicated Git operation. We tried automating it and making it easy to use, but we’ve had no luck so far.
In some of my other projects, I’ve also worked with Perforce and PlasticSCM.
Do you profile your code? If so, do you use third-party profiling tools?
Yes, we analyze our code using Unreal Insights. When it comes to gathering profiling information, the native UE tool is hard to beat. But speaking of visualization, improvements are certainly possible. We use our own tool for plotting CPU usage graphs. Unreal Insight is fine for inspecting frame contents, but it doesn’t help you see all of the dynamics, which is why we decided to make our own tool.
Thank you for the interview, Viacheslav! Good luck with your game project!
We look forward to hearing your ideas for enhancing Rider for Unreal Engine.
Subscribe to a monthly digest curated from the .NET Tools blog:
Discover more
使用 Rider for Unreal Engine 开发新游戏，来自 Wargaming 的开发故事
Viacheslav，你好！ 可以和我们讲讲你们正在做的项目吗？ 这是一款什么样的游戏？
我们还没有宣布名称，因为有保密协议，我没办法透露太多信息。 我只能说这是一款科幻的，基于会话的第三人称射击游戏。
你们正在使用 Unreal 作为游戏引擎吗?
是的，没错。 我们目前正在使用 Unreal Engine 4.26 以 C++ 开发游戏，但将逐渐迁移到 4.27。 我觉得我们不会把这个项目移到 Unreal Engine 5，因为此版本渲染方式不同，如果迁移到这个版本，我们可能必须重做已经创建的所有游戏艺术。
这个项目是如何计划的？ 你们使用了哪些技术呢？
正如我所说，这个项目以 C++ 编写，并基于 Unreal Engine 构建。 我们正在大量使用 Unreal Engine 反射机制以及 C++ 模板元编程。 我们有两个 Mono 仓库，一个用于游戏本身，另一个用于引擎。 主要游戏逻辑存储在共享模块中。
使用代码编辑器时，UE 反射机制通常会带来最大的挑战。 处理包含如此多宏定义的代码非常困难，从语言本身的角度来看，这些宏定义几乎毫无意义。 很少有开发者能够自如应对。 这就是 Rider for Unreal Engine 大展拳脚的地方！
有多少位开发者参与了这个项目？ 他们使用的主要工具有哪些？
我们的团队约有 25 位程序员。 其中三分之一使用 Rider for UE，其他人则使用各种版本的 Visual Studio。 采用 Rider 之前，我们使用的是 Visual Studio，包括普通版本或者带有 Visual Assist 或 ReSharper C++ 的版本。 但无论是否采用插件，VS 编辑器都经常出现性能问题。 使用 Visual Assist 时，它的语言功能对我们来说不够准确（尽管现状可能已有所好转）。 相反，Rider for Unreal Engine 却展现出优异的性能，至少在处理 UE 代码方面表现出色。
迁移到 Rider for Unreal Engine 对你们来说容易吗？
我的第一印象是：太好了，它支持 VS 键盘快捷键！ 我的所有 VS 技能都变得唾手可得。在用户界面方面，Visual Studio 的 UI 在某些方面似乎更加人性化，例如调试，这可能是因为我使用 Visual Studio 的时间更久。 但不得不说，Rider 的 UI 在视觉上非常吸引人。
尽管如此，从使用多年的工具迁移出来可能会比较棘手，因此我们的一些同事仍在坚持使用 Visual Studio。
到目前为止，Rider for Unreal Engine 的哪些功能对您的项目而言最为实用？
应该是导航、查找用法、跳转到符号声明、转到派生符号和基础符号 – 我们一直在使用这些功能，无论是在我们自己的代码中还是在 Unreal Engine 代码中（因为引擎代码是开发者的主要文档来源）。 要高效使用 Unreal Engine，另一个关键之处是能否快速查找指向字段和函数的链接以及能否快速进行代码导航 – 这正是 Rider for Unreal Engine 的长项。
然后是静态代码分析 – 能够指出代码错误的检查功能。 在编辑器中直接查看错误，甚至在编译之前就能得知错误，这可以节省大量时间。 这样的错误如果进入编译阶段，可能就意味着要在编译器和开发者之间周旋数小时之久。 当然，我们不会以这种方式发现所有错误，尤其是在模板化代码中。 但 Unreal Engine 本身几乎不使用模板，因此只剩下一小部分错误需要查找和修正。 检查功能支持建议自动添加缺失的 include 指令，这也有助于节省时间：借助 Rider，用户不必思考需要和不需要包含哪些头文件。
同样令人惊讶的是，Rider 了解 Unreal Engine 中实现的反射机制，并支持针对反射标识符和宏提供自动补全。 您通常不会记住这些内容，因此 Rider 的提示着实可以加快编码速度。
我还须提到的是解析资产以及将蓝图与 C++ 源代码绑定。 这个功能的使用频率并不高，但一经使用便颇具价值。 尤其是在重构并更改 C++ 源代码中的某些内容时，在蓝图中查看用法非常实用。 与配置 INI 文件和类属性的默认值相同：您通常可以在代码中直接查看这些值，不需要在 INI 文件中进行搜索。
最后且同样重要的功能是 Unreal Editor 集成，也就是 RiderLink/UnrealLink 插件。 通常，我们会从 Rider 调试器中启动 Unreal Editor，然后在其中进行实时编码。 在我们暂停和恢复游戏时，无需离开 Rider 即可查看日志，这有时可以显著提升效率。 例如，如果我们使用第三方插件（用于集成 Steam 或外部聊天、构建游戏管道等），我们甚至不必切换到编辑器 – 只需查看日志并暂停/恢复编辑器即可。
说到这里，我有一些关于如何增强 Unreal 日志的建议：
- 添加更多筛选选项。 由于日志数量可能成百上千甚至更多，选择正确的类别较为困难。
- 在日志中同时高亮显示多个匹配项 – 这是一个十分常见的用例。
谢谢你分享这些想法！ Rider 的调试器怎么样，你们使用过吗？
当然了。 对于编辑器而言，没有调试器便不可谓真正的开发工具！ 坦白地讲，早些时候我们确实遇到过一些 Rider 的调试器在断点处未停止的问题，但看起来这些问题已经得到修正。 我们最常用的调试功能绝对是逐步执行代码。 有时，我们会使用有条件断点。 我们喜欢调试器显示 Unreal Engine 对象内容的方式。
你们主要是在桌面端进行调试吗？
注：较为遗憾，Rider 尚不支持在主机端进行调试。 我们正就此事与主要的游戏机制造商进行交流。 这些过程可能需要很长时间，有时还要应付许多繁文缛节。
我们还想聊聊版本控制系统。 你们使用了哪些？
我们主要使用 Git，它支持在多条分支上积极开发新功能。 我们使用了 Git 与 Rider 的集成功能。 但对于变基，我们则使用 Tortoise 客户端，因为它更便于掌握大局。 变基可能是最为复杂的 Git 操作。 我们尝试自动执行变基来让它更加易于使用，但目前为止还未奏效。
在我的其他一些项目中，我还使用过 Perforce 和 PlasticSCM。
你们分析代码吗？ 如果分析，你们是否使用第三方分析工具？
是的，我们使用 Unreal Insights 分析代码。 在收集分析信息方面，原生 UE 工具十分强大，几乎无可匹敌。 但谈到可视化，当然也可能会有值得改进之处。 我们使用自己的工具来绘制 CPU 使用率图。 Unreal Insight 在检查帧内容方面表现尚可，但它并不能帮助查看所有动态，这就是我们决定制作自己的工具的原因。
感谢你接受采访，Viacheslav！ 祝你们的游戏项目一切顺利！
我们期待你们在完善 Rider for Unreal Engine 方面提出更多想法。
本文英文原作者：
Subscribe to a monthly digest curated from the .NET Tools blog: