For the last year and a half, an early access program for Rider for Unreal Engine – IDE for developing games in C ++ using the Unreal Engine. Today, tens of thousands of individual game developers participate in the program, as well as many studios and large game development companies. It became interesting to us to find out why these people appreciate our product, what they like and what they lack.
We decided to talk to Vyacheslav Dubikovsky – technical director in the company Wargaming RED Wargaming, which recently started its work in Moscow. Interviewed by Anastasia Kazakova @ anastasiak2512, Product Marketing Manager for .NET and C ++ Tools, and Alexander Pirogov @apirogov, Project Manager at Rider for Unreal Engine.
Vyacheslav, tell us about the project you are doing. What game is this?
We have not announced the project yet, because of the NDA I cannot tell you about it in detail yet. But it will be a new session-based Sci-Fi third-person shooter.
Do I understand correctly that you are using the Unreal Engine as your game engine?
Yes, that’s right. We are writing a game in C ++ using the Unreal Engine (so far this is version 4.26, but we are slowly migrating to 4.27). The project is unlikely to move to Unreal Engine 5, since the rendering changes in this version and therefore it will be necessary to change all the art already prepared for the game.
Tell us briefly about the structure of the project. Are there any special features? What technologies do you use?
As I said, the project is written in C ++ and built on the Unreal Engine. We actively use both the reflection capabilities from the Unreal Engine and template metaprogramming in C ++. Our project consists of two large monorepositories: the game itself and its engine. The basic game logic is in the general module.
The main problem when working in code editors is the UE reflection mechanism. Few people can work with code wrapped in so many macros that, from a language point of view, don’t mean anything. Here Rider for Unreal Engine is undoubtedly doing a great job!
How many developers are involved in the project? What tools do they mainly use?
The team has about 25 programmers. A third of them use Rider for UE, the rest work in different versions of Visual Studio. Before Rider, we used Visual Studio – without plugins, with the Visual Assist plugin, or with ReSharper C ++. However, we often faced the problem of editor performance – regardless of whether we connected ReSharper C ++ or worked without plugins. When using Visual Assist, we lacked the accuracy of the language capabilities (although I admit that now something has already changed). At the same time, Rider for Unreal Engine seems to us a clear leader in performance – at least when working with Unreal Engine code.
Was the migration to Rider for Unreal Engine easy?
My first impression was, “How awesome it has support for the Visual Studio keymap! Now I can apply here all the knowledge and skills I gained while working in VS ”. Since the Visual Studio interface is more familiar to me, in a number of aspects (for example, when working in the debugger) it seems to me more convenient. On the other hand, Rider’s interface is very visually pleasing.
Of course, changing a tool that you have been using for many years is not easy for everyone. So many people continue to use Visual Studio for now.
What features of Rider for Unreal Engine have been most useful for your project?
Firstly, this is navigation, search for usages, transition to the declaration of a symbol, search for heirs and ancestors of a symbol – this is what we do all the time, and not only in our code, but also in the Unreal Engine code, because the engine code is the main documentation for developers … Also, one of the keys to working effectively with the Unreal Engine is the ability to quickly find references to fields and functions and instantly navigate through the code – this is where Rider for UE does a great job.
Further, this is a static analysis of the code, that is, hints about errors made during its writing. Being able to see errors in the editor before compiling can save you a lot of time. After all, if we get to the compilation stage with these errors, it can turn into hours of “ping-pong” between the compiler and the developer. Of course, not all errors can be caught like this, especially in templated code. But the Unreal Engine itself hardly uses templates, so only a small percentage of errors remain. Hints about missing include directives and their automatic substitution also help save time: Rider eliminates the need to crawl into the file header and figure out which header files are included and which are not.
It’s really cool that Rider knows about the reflection engine implemented in the Unreal Engine and offers autocompletion for identifiers and reflection macros. You yourself usually don’t remember such things well, so these hints significantly speed up development.
I will also mention parsing assets and linking Blueprints with C ++ source code. This feature is used infrequently, but for this it is no less useful, especially during code refactoring: when something changes in the C ++ source code, it is very useful to see the usage in Blueprints. The situation is similar for configuration .ini files and default values of class fields: often you will be able to see the values already in the code itself, without having to dig into the .ini files.
Also worth mentioning is the integration with the Unreal editor, namely the RiderLink / UnrealLink plugins. The usual development approach is to launch the Unreal editor from the Rider debugger, and then develop directly from the editor using Live Coding. The ability to see the logs by starting and stopping the game directly from Rider sometimes speeds up development significantly. For example, if we work with third-party plugins (integration with Steam, integration with third-party chats, development of the game pipeline, etc.), we don’t even need to go to the editor – just see the logs, start and stop the editor.
By the way, according to the Unreal log, I have several wishes:
Add more filtering options. There are a lot of logs, so it is difficult to choose the necessary categories from the available ones, because there can be hundreds of them.
Highlight several entered terms in the log at once (this is a common situation).
Thanks for the ideas! Tell me, do you use the Rider debugger?
Of course. Without a debugger, an editor cannot become a complete development tool. There have been problems in the past where the debugger might not stop at specified points. But it seems these issues have been fixed. The most commonly used debugger feature is, of course, step-by-step debugging. We sometimes use conditional breakpoints. And we love how the contents of Unreal Engine objects are displayed in the debugger.
Is debugging mostly done on the desktop?
So far, yes. We plan to work with consoles in the future, but we haven’t gotten to that yet.
Note: Unfortunately, debugging on consoles from Rider is not yet possible. We are in talks with major console manufacturers. Such processes take a long time, partly due to the bureaucracy.
We also wanted to talk about version control systems. Which ones do you use?
This is mainly Git and the active process of developing new features in branches. We are using Rider’s Git integration. We only use the Tortoise client for the rebase operation: there we see more information about the big picture. Rebase is probably the hardest operation in Git. Our attempts to automate it and at the same time make it convenient to use have so far been unsuccessful.
For other projects, I’ve worked with Perforce and PlasticSCM.
Are you profiling your code? Do you use any third-party tools for this?
Yes, we parse the code with Unreal Insights… It is hardly possible to make an external tool more efficient than the native one from Unreal Engine. This is when it comes to collecting profiling information. For visualization, of course, improvements are possible, and we have our own internal tool that builds graphs of CPU usage. The contents of the frame can also be viewed through Unreal Insight, but it is difficult to see the whole picture in dynamics, and for this we decided to create our own tool.
Thank you very much for the conversation, Vyacheslav! Good luck with your project!
We look forward to your ideas for improvement. Rider for Unreal Engine…