Interviews News

Wargaming、新ゲーム開発に Rider for Unreal Engine を採用

Read this post in other languages:
English, Français, 한국어, Deutsch, Русский, 简体中文

Unreal Engine を使った C++ ゲーム開発用の新しい IDE である Rider for Unreal Engine では 1 年半前より早期アクセスプログラムを展開しています。 この製品はこれまでに数十万に及ぶインディーゲーム開発者だけでなく、あらゆる規模のゲーム開発スタジオや制作会社からの関心を寄せてきました。 JetBrains は、このようなユーザーがこの製品について最も重視している点、満足している点、不足していると考えている点を把握したいと考えています。 そこで、Wargaming Group Limited グループの一拠点としてロシアのモスクワに最近開設されたゲーム開発スタジオである Wargaming RED でテクニカルディレクターを務める Viacheslav Dubikovsky 氏にお話を伺うことにしました。 このインタビューは、.NET および C++ ツールのプロダクトマーケティングマネージャーを務める Anastasia Kazakova と Rider for Unreal Engine のプロジェクトマネージャーを務める Alexander Pirogov が担当しました。

Viacheslav Dubikovsky

Wargaming RED テクニカルディレクター

 

Viacheslav さん、こんにちは! 現在作業中のプロジェクトについてお話しいただけますか? どのようなゲームですか?

NDA を結んでいる関係上、タイトルがまだ発表されていない時点ではあまり詳細を話すことはできません。 ただし、SF 系のセッション式サードパーソンシューティングゲームとだけお伝えしておきましょう。

ゲームエンジンには Unreal が使用されているのですよね?

その通りです。 ゲームは C++ で開発しており、今のところは Unreal Engine 4.26 を使用していますが、徐々に 4.27 への移行を進めています。 このプロジェクトは Unreal Engine 5 には移行しないと思います。そのバージョンではレンダリング方式が異なっているため、移行するとこれまでに制作したゲームアートをすべて作り替えなければならない可能性があるためです。

WG team

プロジェクトはどのように編成されていますか? どんなテクノロジーを使用していますか?

先程述べたように、このプロジェクトは C++ で記述されており、Unreal Engine で構築されています。 Unreal Engine のリフレクションメカニズムや C++ テンプレートメタプログラミングを大々的に使用しています。 モノリポジトリには、ゲーム自体用とエンジン用の 2 つを用意しています。 メインのゲームロジックは、共有モジュールに保存されています。

コードエディターを使用する際には、UE リフレクションメカニズムがいつも最大の問題になります。 言語自体の観点では実質的な意味を持たない大量のマクロ定義でラップされているコードを操作するのは困難です。 この問題に対処できる開発者はほとんどいません。 こんな場合に Rider for Unreal Engine が大きく役立っています!

このプロジェクトには何人の開発者が関わっていますか? どんなツールを主に使用していますか?

チームには約 25 名のプログラマーが在籍しています。 その 3 分の 1 は 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 のほうがデバッグなどの観点では使いやすいように思えました。そちらのほうが使い慣れていたからでしょうね。 でも、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 はまだコンソールでのデバッグに対応していません。 JetBrains はこの件について主なコンソールメーカーと協議しているところです。 このようなプロセスは時間を要し、形式的な手続きを何度も行なう必要がある場合があります。

WG brand

バージョン管理システムについても伺いたいのですが、 どれを使用していますか?

主に Git を使用しており、新しい機能を精力的にブランチで開発しています。 また、Git の Rider 統合機能を使用しています。 ただし、リベースには Tortoise クライアントを使っています。全体像を把握しやすいからです。 リベースは、Git 操作の中で最も複雑な操作だと思います。 自動化して使いやすくしようとしましたが、まだうまくいっていません。

他のプロジェクトでは、Perforce や PlasticSCM も使用したことがあります。

コードをプロファイリングしていますか? その場合、サードパーティのプロファイリングツールを使用していますか?

はい。コードの解析に Unreal Insights を使用しています。 プロファイリング情報を収集するのであれば、ネイティブの UE ツールを使用するのが一番です。 ただ、視覚化について言えば、改善の余地は絶対にありますね。 CPU 使用率グラフの作成には独自のツールを使用しています。 Unreal Insight はフレームコンテンツの検査には最適なのですが、あらゆる動的変化を把握するには機能不足であるため、独自のツールを作ることに決めました。

Vichaeslav さん、インタビューへのご回答ありがとうございました! ゲームプロジェクトの成功を祈っています!

Rider for Unreal Engine の機能強化に関するアイデアを募集しています。

オリジナル(英語)ブログ投稿の作者:

Elizaveta Semakova

Anastasia Kazakova