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:
