RE ENGINE開発者＆エンジニア座談会。カプコンの文化を体現した「自分たちが最も使いやすいゲームエンジン」の設計思想を聞く

伊集院 勝氏

カプコン基盤技術研究開発部 テクニカルディレクター

佐々木 瞬氏

アンリアルエンジンに詳しい

rita氏

描画ライブラリやゲームエンジン開発経験が豊富

▼大阪会場のイベントレポートはこちら

佐々木：カプコン オープンカンファレンス RE:2022、非常に楽しく体験させていただきました。座談会の前に、改めて自己紹介をお願いします。

伊集院：カプコン基盤技術研究開発部 テクニカルディレクターの伊集院です。1993年にカプコンに入社し、RE ENGINEの前身にあたるMT FRAMEWORKのディレクターを務めたあと、コンシューマハードのGPUやCPUなどチップメーカーとの渉外や折衝役などを行っておりました。現在の所属は基盤技術研究開発部で、研究開発やR&Dを中心にハードメーカーとの折衝やイベントの責任者を務めることもあります。

カプコン基盤技術研究開発部テクニカルディレクター 伊集院 勝氏

rita：早速お聞かせいただきたいのが、「RE ENGINEがどの方向を向いているか」という点です。タイトル特化型のエンジンや、自社のみで開発を完結できることを目指した内製エンジン開発事例は多いですが、RE ENGINEはどのくらいの規模感のゲームまで想定されているのでしょうか。

伊集院：RE ENGINEはマルチプラットフォーム＆マルチジャンル対応の内製ゲームエンジンですので、自社タイトル開発に向けて最適化されています。限界まで広い空間を表現するという意味では、エンジン機能で言えば少なくともオープンワールド系のタイトルは問題なく作ることができます。それが何km四方かはタイトルにもよるので直接的にはお答えできませんが、少なくとも一般的なオープンワールドは開発可能というのが規模感への解答になるかと思います。

佐々木：シーン1個の広さには限界があると思いますが、どういった仕組みでシーンを管理しているのでしょうか。

伊集院：細かい仕様を全てお話するわけにはいかないですが、少なくともワールドを分割して管理する仕組みにはなりますね。

佐々木：オープンワールドのような大規模タイトルを作るとき、アセットの量産が課題のひとつになると思います。規模をスケールするための工夫があれば教えてください。

伊集院：ひとつは「共通化」です。そもそも、RE ENGINEが開発の主流になった段階で、カプコンでの開発は原則としてRE ENGINEで行うことを決めています。この結果、RE ENGINEで作成したアセットは全てタイトル間で共有できる形となりました。前作からの継承、あるいは他タイトルからの継承など、アセット自体を引き継いで使用できるということです。

岩や草といった、どのタイトルでも使用する自然物についてはアセットを共通化しています。タイトルが増えていけば積み上げも増えますので、RE ENGINEを軸としたライブラリ化は積極的に行っています。

アセットの配置はカンファレンス内で体験可能。シーンの読み込みも速く、ツール内に日本語でメモが残せるなど、アーティストでも扱いやすい

rita：自然物というと、SpeedTreeやQuixel Megascansなど外部のアセットライブラリも利用されていますか？

伊集院：もちろん使っています。その意味では、外部アセットの使用を制限するような考えはありません。

佐々木：ランタイムについてお聞きします。アーティスト自身が豊富なアセットを自由に配置できることは素晴らしいですが、一方において処理負荷の管理も必須になると思います。そこはどのように管理する思想なのでしょうか。

伊集院：どのデータを扱うかはプロジェクトごとに管理されていますが、パフォーマンスについては当然プロファイリングツールや管理ツールを用意しています。これはエンジンレイヤーで開発されているものが多いですね。エンジン側で開発して、プロジェクトにお渡しする形式になります。

例えば、描画に与えるインパクトを色分けして表示するようなツールなどがありまして、「このシーンの描画はかなり処理が掛かっているけれど、どうして？」というところがビジュアライズできるようになっています。

佐々木：素晴らしいですね。プロファイリングと最適化はどのタイトルでも重要なファクターなので、エンジンに改良が加われば加わるほどすべてのプロジェクトが効率化されていく思想は美しいと思います。

テストツールという意味合いでは、会場内では「シーンメモ機能」と「DIP」が体験できた。特にテストツールは非常に使い勝手がいい印象を受けた

データ容量に関する展示も。プラットフォームや言語に合わせた絞り込みなど、低容量パッケージを実現するための工夫が書かれている

佐々木：タイトルごとに必要な機能やカスタマイズの要望などに応えることも必須の業務かと思います。RE ENGINEの拡張機能はどのように開発され、そしてどういった場合に本流に統合されるのでしょうか。

伊集院：タイトル側で出された要望に対して、エンジン側（※）で「機能開発を行うのか」「既存機能で実現可能か」を判断します。その上で、開発するのが妥当と判断されれば、どういう形で実装するのが理想的かをタイトル側と相談して決めていきます。実際に機能として開発し、タイトルで使ってもらい、使ってみた感想をフィードバックとして頂き、それを踏まえて更に機能として洗練していくイメージです。
※以降、タイトル側とは「実際にゲームタイトルを開発するプロジェクト」、エンジン側とは「RE ENGINEを開発する基盤技術研究開発部」を指す

それらの機能はRE ENGINEで担保されているので、他のタイトルでも使用可能です。自分たちのタイトルで必要とされ実装された機能が他のタイトルでさらに拡張され、より多機能化されることもあります。

佐々木：エンジンのカスタマイズなどの要望については、タイトル側のエンジニアではなく、エンジン側のエンジニアが対応するという形になっていますか？

伊集院：そうです。原則として、エンジンに関する部分は我々が対応します。RE ENGINEのコア部分はC++で、タイトル側はC#になっています。言語で切り分けを行っています。機能追加はC++で行いますので、エンジン側がエンジン機能開発を担保するというのをお約束にしています。

佐々木：言語で分けているというのは、つまりタイトル側のメンバーがC++を触ることはないのでしょうか？

伊集院：ありません。これはRE ENGINEを作る時の基本的なお約束にしています。C++をタイトル側で触ると、不測のエラーが発生し、何らかのトラブルを発生させる要因を残してしまうことになります。これはMT FRAMEWORKの時代に、私自身が嫌というほど痛い目を見てきましたので……。タイトル側が独自実装したものが原因不明のクラッシュを起こして、それを「エンジン側で調査してくれ！」という流れも多くて、それってこちらはもう「自分で作ったんだから自分で調べてよ！」と言いたくなるじゃないですか。ですから、この時の経験を踏まえて、C++で作るものがあれば（タイトル用の機能も）私たちエンジンコアチームが担保します、というお約束を作ったんです。

佐々木：極限まで最適化が求められる大規模のコンソール開発において、ゲームロジックがC#のみで完結していることに驚きました。この話題はかなり画期的だと思っていて、それはつまりC++が使えなくても、C#さえ使えればプロジェクトに参画できるわけですよね？

伊集院：そうなります。極論ですが、C#だけ使えればプロジェクトで仕事をすることは可能ですね。個人的には、プログラムスキルという意味ではC++も使えたほうが良いだろうとは思いますが、少なくとも実務ベースではC#のみで遂行できる状態です。

話題とは関係ないが、箸休めとしてアイルーの画像を挟んでおく。これも体験ブースでの一枚

rita：エンジンだけを開発し続けていると、「エンジンの開発保守に関する効率は良いが、タイトル側にとっては使いにくい」という状況に陥りがちです。その点、言語で切り分けて、タイトル側で必要な機能をエンジン側で開発するという仕組みは「タイトル側の知見がまるごとエンジンチームにも入っていく」ということでメリットが大きいように感じます。

伊集院：単純に開発する人間を分けるだけだと、結局タイトル側で起きている事象を正確に把握できないままツールを作ることになってしまいますので、求めていたツールが「そうじゃない」という問題も発生してしまいます。

だから、私たちはエンジン側から数名をタイトル側に派遣して、”エンジン側の人間ではあるもののタイトルに入って一緒に仕事をしてもらうという仕組み”にしています。座席もタイトル側と同じ場所に移動して、物理的にもチームに合流するという形を取っています。そこで見聞きした問題や解決方法などをエンジン側に上げてもらって、統合的に解決できるソリューションがあればエンジン側で開発を進めるという流れになります。

展示のスタート地点で再生されていた動画でも、エンジン側のスタッフとタイトル側のスタッフの緊密性が語られていた

佐々木：上手いやり方ですね。タイトル側はエンジン側のメンバーをどう受け入れたらいいか悩むシチュエーションですが、「C++で実装するものを依頼する」というのは明確な指標です。ゲームの面白さを追求する気質のメンバーがC#で面白さを突き詰め、エンジンにこだわりがあるメンバーがC++でプロジェクトを支える。上手く回りそうな体制です。

伊集院：そうですね。エンジンチームから派遣されているメンバーは、決してエンジン側の代弁者になってはいけません。タイトル側の代弁者にならなければいけないんです。タイトルを面白くするためにプロジェクトに入って、タイトル側の代弁者として「もっとこうして欲しい！」ということをエンジン側に伝えるのが仕事です。

先ほどの話にもありましたが、エンジンだけを作り続けているとエンジンの理論でものを作るようになってしまいます。タイトルがどのように作られるかを知らずにエンジンだけを作り続けることは問題だと考えています。だから、エンジン側のメンバーをタイトル側に「どう使われているか見ておいで」と送り出すこともあります。そうすると、「タイトルでRE ENGINEがこんな使われ方をしていたなんて！」という気付きを得て、大きく成長して戻ってくるんです。

佐々木：私はタイトル側だけを作り続けてきた人間ですが、今の話はすごく納得感がありました。とても良い流れで開発ができている状態だと思いますが、現状の課題などはありますか？

伊集院：タイトルが増えたり、プラットフォームが増えたりすることは、解決すべき物量そのものが増えることを意味します。カプコンの全てのタイトルをしっかり支えていくことを考えると、開発ボリュームは純粋に増加傾向にあります。物量そのものを課題として認識しています。こう考えると、本当に他のゲームエンジンは凄いなあ、と肌身で感じますね。

海外スタジオなどを含めて、いわゆる「タイトル専用エンジン」も多い中で、これまでにも申し上げた通りRE ENGINEはマルチプラットフォーム＆マルチジャンルに対応した社内汎用ゲームエンジンです。AAAタイトルを目指して開発した『バイオハザード ヴィレッジ』、Nintendo Switchで動作することを目標とした『モンスターハンターライズ』、そして『カプコンアーケードスタジアム』などのレトロゲームにまで対応したエンジン。これら全ての要望に対応し続けるのは簡単なことではありません。

rita：タイトル特化エンジンと違って、汎用エンジンならではの難しさを感じますね。

伊集院：新しいジャンルに対応したい場合はこれに即した機能を網羅的に開発する必要があります。機能が増えていく一方で、人員を増やす必要もあり、人員が増えると更新頻度が上がってメンテナンスのボリュームも増える。こういった恐竜的進化にどう対応するかは常に考えています。

佐々木：これらの状況がある中で、他のゲームエンジンではなくRE ENGINEを開発の核として選択している一番の理由はなんでしょうか？

伊集院：RE ENGINEはカプコンで最も使いやすいエンジンです。私たちのワークフローに合致した、最も扱いやすく、そして社内で作られるさまざまなタイトルやジャンルに完全に対応できるエンジンです。リアルタイムレイトレーシングにいち早く対応できたり、新しい技術を必要なだけ実装できたり、そういった技術的な側面も大切ですが、私たちがゲームエンジンを内製する最も大きな理由はワークフローへの適合です。

カンファレンス内でも展示されていたモーションマッチングなど、最新機能をいち早く導入できる点も強み。だが、それ以上に「ワークフローへの最適化」が重要とのこと

佐々木：なるほど。各ゲームエンジンは、特定のワークフローを想定して機能を提供します。ゲームエンジンの選定は、機能の選定であると同時にワークフローの選定です。そして、ワークフローが変わると各職種の担当範囲が変わる。担当範囲が変わると各職種に求めるスキルや教育が変わり、採用基準にまで影響する。逆に言うと、本来は自社のメンバーが持つこだわりや過去の試行錯誤をもとにしてワークフローが作られます。他社エンジンを採用することは、他社の想定するワークフローをベースに自社文化へ近付けるということになりますが、自社エンジンだとそれをバッチリ合わせることができると。

伊集院：その通りです。ワークフローというのは、その会社の文化なんです。今までの長い開発経験の中で培ってきた大切なものです。これを変えるというのはアイデンティティの喪失に繋がりかねないと思っています。

昔はタイトルごとに開発環境が全然違いましたよね。エンジニアがゼロから環境自体を作っていました。その後、いつしか汎用エンジンが世の中に出てきて、それを使えば比較的早くゲームを作ることができたり、同じエンジンをベースとした知見を共有できたり、そういった時代が訪れました。我々はそこから一歩進んで、「社内で最も使いやすい」というコンセプトを足しました。これがMT FRAMEWORKから発展した今の私たちの答えです。

rita：自社の思う最適なワークフローを実現するための内製エンジンなんですね。歴史を積み重ねてきたゲーム会社だからこその視点かと思います。ワークフローへの最適化は、RE ENGINEのどういった部分に機能として表れているのでしょうか。

伊集院：機能として……そうですね。私たちにとっては当たり前過ぎて、なかなかお答えが難しいです。ただ、RE ENGINEはエンジン側だけが仕様を固めたわけではありません。タイトル側としっかり話をして、やりたいことを明確にして、それを最適化するにはこの方法が良いという試行錯誤の積み重ねで作られてきました。そういう意味では、「エンジンかくあるべき」で作られたわけではなく、「タイトルのために」作られたエンジンであると言えると思います。

ひとつ言えるのは、開発がRE ENGINEに一本化できていれば、社内の人材流動性が担保できるということです。タイトル開発が完了するタイミングはまちまちなので、開発の途中で別プロジェクトからメンバーが移ってくることも少なくありません。使用するエンジンが同じで、開発思想も同じであれば、開発環境を学習するコスト自体は低減できます。このことは（プロジェクトごとに人を集めて、終わり次第解散する海外と比較して）日本的な労働環境にマッチしているだろうと思います。

佐々木：ゲームを作る文化そのものが自然にエンジンに落とし込まれているということですね。

伊集院：そうです。RE ENGINEは当初『バイオハザード7 レジデント イービル』のために作られました。このときのエンジンがもととなって、『バイオハザード ヴィレッジ』、『モンスターハンターライズ』で培った知見や現場のフィードバックを取り入れながら、カプコンで一番使いやすいエンジンとして変化し続けています。今はようやくマルチジャンルかつさまざまなタイトル開発に使いやすい形まで持ってこれたという実感を持っています。

佐々木：これからもRE ENGINEで開発されるカプコンタイトルを楽しみにしています。本日はありがとうございました。

神山 大輝

ゲームメーカーズ編集長およびNINE GATES STUDIO代表。ライター/編集者として数多くのWEBメディアに携わり、インタビューや作品メイキング解説、その他技術的な記事を手掛けてきた。ゲーム業界ではコンポーザー/サウンドデザイナーとしても活動中。

ドラクエFFテイルズはもちろん、黄金の太陽やヴァルキリープロファイルなど往年のJ-RPG文化と、その文脈を受け継ぐ作品が好き。