RE ENGINE Philosophy 日本語版

RE ENGINE Philosophy それではこれよりRE ENGINE Philosophyの講演を始めさせていただきます。 ---Microsoft, Windows, and Microsoft Teams are trademarks or registered trademarks of Microsoft Corporation in the United States and other countries. Screenshots of Microsoft products are used with permission from Microsoft. Python® is registered trademarks or trademarks of Python Software Foundation. ©CAPCOM 1

もくじ • RE ENGINEの歴史 • RE ENGINEの開発体制 • Managementユニットの役割 • RE ENGINE開発ワークフロー • 最後に この講演の内容は、このようになっています。 2 ©CAPCOM 2

RE ENGINEの歴史 では、まず始めにRE ENGINEの歴史を簡単に振り返ってみます。 3 ©CAPCOM 3

RE ENGINEのこれまでの歴史 コ ロ ナ 禍 順調に採用タイトルを増やす 2023 2022 2021 外 部 協 力 会 社 の 開 発 サ ポ ー ト 2020 Git 拠 点 を 跨 い だ 開 発 サ ポ ー ト 2019 SVN RE ENGINE 理コ をー ド の かバ らー ジ にョ 移ン 行管 2018 2017 2016 2015 2014 開 発 ス タ ー ト 複 数 タ イ ト ル の サ ポ ー ト 開 始 サ 20 ポ以 ー上 トの プ ロ ジ ェ ク ト を RE ENGINEの開発は2014年に始まりました。 それより前はMT FRAMEWORKというゲームエンジンを開発・運用していましたが、2012年に次世代ゲームエンジンとして 4 Panta Rheiの開発に着手しました。しかし開発効率が悪かったため開発を中断、その資産を流用しつつRE ENGINEを作り始めました。 当初からバイオハザード7で使用することは決まっていたので、バイオハザード7に必要な機能を最優先で実装していました。 その後2015年には他にもタイトルが立ち上がり、複数のタイトルをサポートする体制が始まりました。 2017年にはコードのバージョン管理をSVNからGitに移行し、ツールとしてはGitLabを採用しました。それまでもコードレビューは 行わていたものの、ツールによるサポートでコードレビューがやりやすくなりました。これによりコードレビューを経て機能を リリースする文化が根付きます。 ©CAPCOM 4

RE ENGINEのこれまでの歴史 コ ロ ナ 禍 順調に採用タイトルを増やす 2023 2022 2021 外 部 協 力 会 社 の 開 発 サ ポ ー ト 2020 Git 拠 点 を 跨 い だ 開 発 サ ポ ー ト 2019 SVN RE ENGINE 理コ をー ド の かバ らー ジ にョ 移ン 行管 2018 2017 2016 2015 2014 開 発 ス タ ー ト 複 数 タ イ ト ル の サ ポ ー ト 開 始 サ 20 ポ以 ー上 トの プ ロ ジ ェ ク ト を またこの年からRE ENGINEの利用形態が多様化します。 社内では大阪と東京拠点で連携し始めました。拠点が離れていることでアセット取得時に東京側から大阪側にあるサーバー 5 アクセスに時間がかかる問題が発生しましたが、ミラーサーバーを用意して解決したりもしました。また外部協力会社でも 使っていただくようになり、本格的な外部サポートが開始します。それまでもアセット作成を目的として外部協力会社に RE ENGINEを提供していましたが、ゲーム開発そのものを外部委託し始めたのがこのころです。 その後順調に採用タイトル数を増やしますが、2020年ごろからコロナ禍によってエンジン開発にも影響が出始めます。 特にそれまでは対面でのコミュニケーションを多く行ってきましたが、オンラインでのコミュニケーションにシフトしていきます。 そして2023年現在、同時に20以上のプロジェクトをサポートするまでに成長しています。この数は社内研修や検証などの ゲーム開発ではないプロジェクトも含みますが、それだけの数をサポートできる状況にあると言えます。 ©CAPCOM 5

RE ENGINEのこれまでの歴史 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014 行数 ファイル数 12,000,000 35,000 10,000,000 30,000 25,000 8,000,000 20,000 6,000,000 15,000 4,000,000 10,000 2,000,000 5,000 0 0 Gitに移行した後のリポジトリーの推移を見てみます。 2017年と2023年時点を比べてみると、コードの行数は約460万行から960万行へ、ファイル数は約11,000から25,000と 6 なっています。6年でコードの規模が倍以上に増えていることが分かります。 ©CAPCOM 6

RE ENGINEのこれまでの歴史 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014 160 開発者数の推移 140 120 100 80 60 今では約150人の大所帯に 最初は約20人でスタート 40 20 0 次にエンジン開発者の人数の推移を簡単に見ていきます。 最初は約20人ほどで開発をスタートしました。このころはMT FRAMEWORKもまだ現役でその開発にも人員が必要だったため、 7 あまり多くの人数を割けませんでした。当時はエンジン開発者が独立してエンジンを開発していたわけではなく、 バイオハザード7の開発チームの1セクションとして同じフロアで開発をしていました。タイトルのマイルストーンに合わせて 機能開発を進め、随時進捗を共有するなどして密接にかかわっていたのです。 そこからMT FRAMEWORKを使ったゲーム開発が終了していくのと、エンジン開発人員の新規採用に伴い徐々に人数が 増えていきます。今では約150人ほど、7倍以上に増えました。 以前はほとんどのエンジン開発者が一つのフロア内で開発を進めていましたが、人数が多くなって収まりきらなくなったため、 今では複数の場所に分散しています。よりクオリティの高いゲームを開発するための高機能化・効率化対応のために、人数は もっと増えていくのではないかと思います。 ©CAPCOM 7

RE ENGINEの開発体制 では次にRE ENGINEの開発体制を紹介します。 8 ©CAPCOM 8

RE ENGINEの開発体制 AI CI DCC Editor Effect GUI Motion Network Physics Rendering Runtime Security Sound Timeline Tool 一つ一つがユニット Management RE ENGINEでは各分野ごとのまとまりを「ユニット」と呼んでいます。 直接ゲームに必要な機能を開発するユニットやアセット編集のためのエディターを開発するユニット自動化や各種webサービスを 開発するユニットなど、様々なユニットが存在します。 9 また、それらのユニットとは毛色のことなるManagementユニットも存在します。 各ユニットの人数は様々で、少ないユニットだと3～4人程度、多いユニットだと20人くらいです。 ちなみに一番人数が多いユニットはレンダリングユニットです。レンダリングはゲームの見た目のクオリティに直結するので 機能実装の需要が高く、それだけ人数をかけて開発をしていく必要があるためです。 ©CAPCOM 9

RE ENGINEの開発体制 AI CI DCC Editor Effect GUI Motion Network Physics Rendering Runtime Security Sound Timeline Tool Title A Title B Title C Title etc… Management 各ユニットはゲーム開発者と直接コミュニケーションをとって開発を進めています。直接担当者間で相談し仕様策定から 実装までを行うことで、スピード感のある開発を実現しています。 10 このようにユニットごとに運営を行っており独立性の高く、上下関係のないフラットな体制になっています。 Managementユニットは開発を行いませんが、ユニットやゲーム開発者の困りごとを解決したりする「何でも屋」として 活動しています。 ©CAPCOM 10

RE ENGINEの開発体制 AI CI DCC Editor Effect GUI Motion Network Physics Rendering Runtime Security Sound Timeline Tool 次に各ユニットがどんなことをやっているか、簡単に紹介していきます。 11 ©CAPCOM 11

RE ENGINEの開発体制 AI • ゲームAIの実現に必要な機能の提供 • AIの知見を利用した開発支援 AIユニットでは、Navigation、FSM、BehaviorTreeといったゲームAIに必要な機能の提供や、点群情報の配置を補助する 機能などの、AIの知見を利用した開発支援などを行っています。 12 ©CAPCOM 12

RE ENGINEの開発体制 CI • 各種自動化 • QA支援ツール開発 • 見える化 • 外部協力会社向け機能開発 CIユニットでは、エンジンの作成・配布や、タイトルのプログラマーがスクリプトをコミットした際のビルドチェックシステム などの各種自動化、QAチームが運用する、各プラットフォームへのパッケージの自動インストールツールやクラッシュ検知などの 支援ツール開発、またそれらのシステムで得られる情報をWebやツールを用いて情報を可視化する対応などを行っています。 13 他にもCIとは直接関係ありませんが、外部協力会社でRE ENGINEを使っていただくためのシステム開発なども行っています。 ©CAPCOM 13

RE ENGINEの開発体制 DCC • RE ENGINE向けツール開発 • DCCツール向けツール開発 DCCユニットでは、RE ENGINEで動作するツールの開発や、アーティストが使用するSDM（Scene Data Manager）と呼ばれる アセット管理ツールや、各種DCC向けのツール・プラグインを開発しています。 14 ©CAPCOM 14

RE ENGINEの開発体制 Editor • グラフィック制作用の各種エディター開発 Editorユニットでは、レベルデザイン、背景アート制作、マテリアル編集など、グラフィック制作に関わる幅広いエディターの 開発を担当しています。 15 ©CAPCOM 15

RE ENGINEの開発体制 Effect • エディターや各種表現のための機能開発 Effectユニットでは、ゲームで使われるEffectを作成するためのエディターや、各種表現のための機能開発を行っています。 16 ©CAPCOM 16

RE ENGINEの開発体制 GUI • エディターや各種表現のための機能開発 • 言語ごとのテキスト管理システム GUIユニットでは、ゲーム中のUIを作成するためのエディターとその機能開発や、言語ごとのテキストを管理するシステム 開発などを行っています。 17 ©CAPCOM 17

RE ENGINEの開発体制 Motion • キャラクターアニメーション • モーションキャプチャーのリアルタイムプレビュー Motionユニットでは、モーションのブレンドやIKを用いた姿勢制御などキャラクターのアニメーション周りの開発を行ったり、 モーションキャプチャーされたデータをRE ENGINEでリアルタイムプレビューするための機能開発などを行っています。 18 ©CAPCOM 18

RE ENGINEの開発体制 Network • マルチプレイのための機能の開発 • オンラインで利用できる機能の開発 • 開発や分析で利用するための ネットワーク機能の開発 Networkユニットでは、マルチプレイで必要となるマッチメイキングやフレンド機能などに加え、ランキングやネットワーク ストレージなどのオンラインで利用できる機能、HttpClientやWebSocketClientなどの開発やプレイデータの分析で利用するための 機能などを開発しています。 19 ©CAPCOM 19

RE ENGINEの開発体制 Physics • キャラクターなどの当たり判定・位置補正 • 各種シミュレーション Physicsユニットでは、キャラクターなどの当たり判定と判定結果による位置補正などのシステムや剛体やClothなどの シミュレーションに関する機能の開発を行っています。 20 ©CAPCOM 20

RE ENGINEの開発体制 Rendering • ジオメトリ • 照明とシェーディング • マテリアル • ポストエフェクト Renderingユニットでは、ジオメトリ、照明とシェーディング、マテリアル、ポストエフェクトなどの様々なレンダリング機能の 開発を行っています。また他のユニットが利用するレンダリングシステムの基盤の提供も行っています。 21 ©CAPCOM 21

RE ENGINEの開発体制 Runtime • エンジンのコア機能の開発 • 各プラットフォームの動作のラップ • プロファイラー、デバッガー、パッケージ作成などの ツール開発 Runtimeユニットでは、各ユニットが利用するエンジンのコア部分の開発や、各プラットフォームで異なるAPIをラップして 使いやすくしたり、プロファイラー、スクリプトデバッガー、パッケージ作成などの各種ツール開発も行っています。 22 ©CAPCOM 22

RE ENGINEの開発体制 Security • PCゲームにおけるチート・海賊版対策のシステム開発 • クラッシュレポートツールの開発 Securityユニットでは、PCゲーム・DLCなどのコンテンツのチート及び海賊版対策の各種システム開発を行っています。 またユーザー環境でクラッシュが発生したときに情報を収集・調査するための、クラッシュレポートツールの開発も行っています。 23 ©CAPCOM 23

RE ENGINEの開発体制 Sound • 内製サウンドエンジンの開発 • オーディオミドルウェアの対応 • 各種エディター開発 Soundユニットでは、ゲームサウンドを実現するための内製サウンドエンジン開発やオーディオミドルウェアの対応、SEなどを 編集するためのエディター開発を行っています。 24 ©CAPCOM 24

RE ENGINEの開発体制 Timeline • キーアニメーション機能開発 Timelineユニットでは、主にカットシーンなどで利用するキーアニメーション機能開発を行っています。機能はモジュール化 されており、他ユニットのエディターでキーアニメーションを扱う際にも利用されています。 25 ©CAPCOM 25

RE ENGINEの開発体制 Tool • RE ENGINE全体のUIを開発 • UIパーツの開発 • ゲーム開発者に向けたツール開発の仕組み提供 • アセットのバージョン管理システム開発 Toolユニットでは、RE ENGINE全体のUIを開発したり、各ユニットが作成するエディターで利用する、UIパーツの開発などを 行っています。またゲーム開発者がPythonを使ってRE ENGINE上でツールを作ったり、エンジン上の操作を自動化したりする ためのマクロ機能の提供も行っています。アセットのバージョン管理システム開発も、このユニットのメンバーが行っています。 26 ©CAPCOM 26

RE ENGINEの開発体制 各ユニットごとに研究・検証も行っている 以上が簡単でありますが、各ユニットの主な活動内容となります。 便宜上エンジン開発者はどこかのユニットに所属していますが、ユニットを跨いだ開発を行うこともあります。 他にもユニットごとに研究・検証なども行っており、その成果が新たな機能として提供されています。 27 全ユニットではありませんが、各ユニットの成果についてはこのカンファレンスの他の講演を是非ご覧ください。 ©CAPCOM 27

Managementユニットの役割 ここからはManagementユニットについて詳しく紹介していきます。 28 ©CAPCOM 28

Managementユニットの役割 エンジン開発者、ゲーム開発者が 滞りなく開発を行うためにできることをする 先ほどManagementユニットは「何でも屋」と表現しました。 その目的は、「エンジン開発者、ゲーム開発者が滞りなく開発を行うためにできることをする」ということです。 29 ©CAPCOM 29

Managementユニットの役割 • 相談の受け皿 • 各種事務的な業務 • RE ENGINE開発の文化の形成 主な活動としては、相談の受け皿となり、各ユニットやゲーム開発者の困りごとを聞いて解決に向けて動いたり、取り纏めなど 各種事務的な業務を行ったり、そしてRE ENGINE開発の文化の形成のための活動も行います。 30 次はこのRE ENGINE開発の文化について、詳しく紹介します。 ©CAPCOM 30

RE ENGINEの開発の文化 • オープンな環境 • エンジン開発者が主役 • ゲーム開発者との関係性 RE ENGINE開発ではこれから挙げる3つのことを重視しています。 オープンな環境、エンジン開発者が主役、ゲーム開発者との関係性です。 31 ©CAPCOM 31

オープンな環境 普段のコミュニケーションにはチャット（Microsoft Teams）を活用 雑多な相談 自動処理結果の通知 まずはオープンな環境です。 カプコンではコミュニケーションツールとしてMicrosoft Teamsを使っていますが、エンジン開発においても専用のチームを 32 作り目的に合わせて各種チャネルを運用しています。例えば各ユニットごとの相談チャネル、Managementユニットへの 相談チャネル、自動処理結果を通知するチャネル、エンジン開発者全体向けだと、全体連絡や全般的な開発相談を行う チャネルなどがあります。 ユニット個別のやり取りはユニットごとのチャネルで行いますが、全体向けのチャネルでも日々活発にチャットのやり取りが 行われています。 ©CAPCOM 32

オープンな環境 ビデオチャットミーティング また情報発信とコミュニケーション促進を目的として、ビデオチャットミーティングを毎週開催しています。 全員が常に参加しているわけではありませんが、それでも毎回100人以上が参加しています。参加できなかった人も議事録として 33 動画を残しているので、後から見返すことができます。コロナ前は直接集まってミーティングを実施していましたが、全員が 集まれるスペースの確保や議事録作成が問題となっていたので、オンラインにして正解でした。 議題は各ユニットから持ち寄りますが、Managementユニットが共有を依頼することもあります。 ©CAPCOM 33

オープンな環境 ビデオチャットミーティング • • • • • • • タイトル情報共有 タイトルスケジュール共有 各ユニットが開発している機能紹介 実装における注意事項・ガイドラインの共有 エンジン開発における仕様変更の連絡 自己紹介 毎年度の目標設定および中間・期末振り返り ミーティングでは様々な議題を取り上げるのですが、主だったものをいくつか紹介します。 タイトル情報共有： 34 社内でどんなタイトルが動いているかはある程度耳に入っては来るものの、具体的なゲーム内容を知る機会はあまり多くは ありません。そのためManagementユニットで得た情報を共有します。場合によってはタイトルのディレクターから直接ゲームの 内容を説明していただくこともあります。新しいゲームの話はみな興味津々に聞いて盛り上がります。 タイトルスケジュール共有： 月末に翌月の各タイトルのスケジュールを共有します。マイルストーンやQAの開始時期などが主な内容になっています。これらの イベント前はエンジン開発者への問い合わせも多くなりがちなので、あらかじめ共有しておきます。 各ユニットが開発している機能紹介： 新しい機能がどんな特徴を持っていて、実装にはどんなことに注意したかなどを共有することで、他のエンジン開発者が参考 できるようにしています。 ©CAPCOM 34

オープンな環境 ビデオチャットミーティング • • • • • • • タイトル情報共有 タイトルスケジュール共有 各ユニットが開発している機能紹介 実装における注意事項・ガイドラインの共有 エンジン開発における仕様変更の連絡 自己紹介 毎年度の目標設定および中間・期末振り返り 実装における注意事項・ガイドラインの共有： コーディングルールなど、エンジン開発を行う上で覚えておくべき基本的な事項の共有を行います。特に重要事項については 毎年定期的に共有するようにしています。 35 エンジン開発における仕様変更の連絡： エンジンの基礎部分に対して仕様変更が行われると各ユニットに影響があるため、あらかじめ仕様変更の内容を共有して 各ユニットに協力を求めます。 自己紹介： エンジン開発者の人数が多くなってきて、直接コミュニケーションしたことがない人も増えたため、多少なりとも各メンバーの ことを知れるように実施しています。内容は特に決まってないのですが、簡単な経歴や趣味などを共有することが多いです。 毎年度の目標設定および中間・期末振り返り ©CAPCOM 35

オープンな環境 目標設定 中間振り返り 期末振り返り RE ENGINE開発では年度の初めに各ユニットごとに目標を決めて、中間と期末に振り返っています。立てる目標は様々ですが、 どういった機能開発に力を入れていくか、取り組む研究内容、ユニットの運営方針などが盛り込まれています。 36 エンジン開発の現場は刻一刻と変化していくため、決めた目標が必ずしも達成できるとは限りませんが、目標を設定・共有する ことで、他ユニットの動きを知れる、コラボレーションの起点となるといったメリットがあります。 普段は自分が所属するユニットの開発に注力しているため、情報がユニット内にとどまってしまいがちです。 そのためミーティングで様々な情報を共有することで、他のユニットのことを知ることができる機会を作っています。 ©CAPCOM 36

オープンな環境 情報共有用の社内サイトの運用 デバッグTIPS 社内サイト（RE:Dev） ガイドラインページ 他にはRE ENGINE開発者専用の社内サイトがあります。 一時的な情報であればミーティングで共有するだけでも問題ないこともありますが、重要なことなどは分かりやすく残す必要が 37 あります。特にRE ENGINEの開発初期は人数が少なかったのもあり、口頭で共有を済ませてしまっていたことも多くありました。 しかし人数が増えたことで明文化されていない情報が増え問題となったため、このサイトを運用し始めました。 サイトには、前述したミーティングのビデオ、各タイトルの概要、新規参入者のためのセットアップマニュアル、コーディング ルールなどの開発のためのガイドライン、各種TIPS、各ユニットごとに自由に情報を記載するためのページなどがあります。 このサイトは誰でも編集可能で、日々活発に更新が行われています。 ©CAPCOM 37

オープンな環境 これらすべてはエンジン開発者のためのものだが、 ゲーム開発者も閲覧することができる ここまで紹介した環境は当然エンジン開発者のためのものです。しかし閲覧制限などは設けていないため、ゲーム開発者でも 気軽に見ることが可能です。 38 実際チャットには多くのゲーム開発者も参加しています。現在、エンジン開発者約150人に対してゲーム開発者は約200人 参加しているので、多くの方にエンジン開発状況に興味を持っていただけていると言えます。 ©CAPCOM 38

オープンな環境 誰でも RE ENGINE のソースコードを閲覧可能 またエンジンコードのリポジトリーも社内に公開しています。ゲーム開発者がコードを取得して、ゲームのデバッグに 利用することもあります。 39 ©CAPCOM 39

オープンな環境 誰でもタイトルの開発環境を取得可能 RE ENGINEで開発されているタイトルは、エンジン開発者・ゲーム開発者の誰でも開発環境を取得可能です。 気軽に色々なタイトルのアセットを取得できるので、ゲーム開発者が自分のゲームの参考にすることもできます。 40 ©CAPCOM 40

エンジン開発者が主役 エンジン開発者間の議論で物事が決まる エンジン開発者からの困りごとをManagementユニットが解決 • 相談対応 • アンケートの実施 次にエンジン開発者が主役であることです。 先ほど紹介したチャットでは様々な議論が行われています。エンジンの仕様についても、チャットで提案・議論を経て 41 決まることが多いです。日々様々な問題も挙がるので、Managementユニットが対策を講じることもあります。 「こういうことをしたいんだけど、どうしたらいいか分からない」という相談を受けることが多いので、それに対して対応を 行います。例えば「各タイトルのアセットを取得するとディスク容量が足りない！」という意見が出たときはSSDの購入・増設を 行いました。また隠れた問題点を把握するために、Managementユニットがエンジン開発者に向けて各種アンケートを実施する こともあります。 ©CAPCOM 41

エンジン開発者が主役 エンジン開発者間の議論で物事が決まる エンジン開発者からの困りごとをManagementユニットが解決 • 相談対応 • アンケートの実施 「各ユニットで問題となっていること」や「エンジン開発で問題になっていること」などを聞き取って、解決に向けて動きます。 例えば「気軽に相談できる場所が欲しい」という意見が出たときはMicrosoft Teamsでチャネルを作ったり、「エンジンの ビルド時間が長い」「特定のアセットのコンバートに時間がかかる」などの意見が出たときに担当するユニットに改善を 42 促したりしています。 また全体に知られていない便利機能などのノウハウを広く伝えるために、「私だけが知ってるかもしれないTIPS・この機会に 伝えたいTIPS」の聞き取りを行いミーティングで共有したこともありました。 あくまでエンジン開発の主役はエンジン開発者であり、Managementユニットではその開発を支えるのが役割となっています。 ©CAPCOM 42

ゲーム開発者との関係性 • 自社にあったゲームエンジン • 素早い対応 • 技術の蓄積 次にゲーム開発者との関係性についてです。 そもそも自社でゲームエンジンを開発するメリットはいくつかあります。自社に合ったゲームエンジン、素早い対応、技術の蓄積 43 などです。このうち2つ目まではエンジン開発者とゲーム開発者が同じ社内で近い距離間で連携できるからこそのメリットです。 このメリットを最大限に活かす必要があります。 ©CAPCOM 43

ゲーム開発者との関係性 タイトル立ち上がりから、リリースまでをしっかりサポート 立ち上げ 開発 QA リリース そのためにはゲームエンジンは機能を実装・リリースしたら終わりではなく、うまく使ってもらうためのサポートを行うことも 重要です。 44 タイトルが立ち上がり、開発を進め、リリースするまでをしっかりサポートするためにやっていることがあります。 ©CAPCOM 44

ゲーム開発者との関係性 タイトルが立ち上がるタイミングでキックオフミーティングを実施 聞くこと ゲーム内容 スケジュール プラットフォーム 技術的課題 など まず新しいタイトルが立ち上がったら、タイトルの主要メンバーとManagementユニットでキックオフミーティングを開催します。 このミーティングではゲーム内容や技術的な課題は何なのかを聞き取ったり、問題となりそうな部分に関しては事前にアドバイスを 45 行います。得た情報はエンジン開発者にも共有しますし、技術的課題によっては担当となるユニットとタイトルメンバーを 引き合わせて、より詳細な相談を促すこともあります。 ゲーム開発初期から関係を築き、その後のサポートを円滑に進めるための第一歩となります。 ©CAPCOM 45

ゲーム開発者との関係性 パフォーマンスレビュー パフォーマンスレビューの説明ページ レビュー結果の一例 続いてゲーム開発における定点でパフォーマンスレビューを実施しています。 各ユニットごとに自分たちが提供した機能に関するパフォーマンスを調査します。メモリを使いすぎている箇所やパフォーマンスの 46 ボトルネックを探し、指摘と改善案をフィードバックしています。 ©CAPCOM 46

ゲーム開発者との関係性 パフォーマンスレビュー 見つかった改善点の例 これには副次的効果もあります。 開発した機能が実際にタイトルでどのように使われているかを確認することで、エンジン内の非効率な箇所が見つかることが 47 あります。もちろん機能開発時にパフォーマンスを意識した実装を行うのですが、その時点では簡単な確認にとどまりがちです。 製品レベルで使われている機能をプロファイルすることで見つけた問題を修正し、エンジンの改善を行う機会としても機能 しています。 ©CAPCOM 47

ゲーム開発者との関係性 より強いパフォーマンス改善対応 パフォーマンスレビューを行い、エンジン開発者とゲーム開発者が改善に努めても、中々目標とするパフォーマンスに達しない ケースもあります。 48 その場合はエンジン開発者とゲーム開発者でパフォーマンス改善専門のグループを作り、より密に連携して改善を進めていくことも あります。いかにクオリティを落とさず目標となるパフォーマンスを出すか、一緒になって最後の追い込みをかけていくのです。 ここまでがゲーム開発の流れに沿った形のサポートの紹介となります。 ©CAPCOM 48

ゲーム開発者との関係性 チャットによるサポート 問い合わせの一例 エンジン開発者からの連絡の一例 ゲーム開発の流れや特定のタイトルに依存しないサポートも行っています。 日々のサポートにもMicrosoft Teamsを活用しています。エンジン開発者向けとは別のチームを運用しており、1300人以上の 49 ゲーム開発者が参加しています。毎日様々な職種の方から問い合わせが行われており、内容としては質問・相談・不具合報告などが メインですが、たまに雑談もします。 エンジンの機能や目的ごとにチャネルを作っているのですが、どのチャネルに投稿すればいいか迷う方もいます。その場合は 汎用的なチャネルに投稿してもらい、適宜対象ユニットに振り分けるといったこともしています。投稿の仕方も凝ったルールを 設けず、問い合わせの敷居を上げないように意識しています。 またエンジン開発者側からも各種連絡に利用していて、コミュニケーションが活発に行われています。 ©CAPCOM 49

ゲーム開発者との関係性 チャットによるサポート 600 500 400 300 200 100 0 2023/1 2023/2 2023/3 2023/4 2023/5 2023/6 月間問い合わせ推移 今年に入ってから6月末までの半年間の月間の問い合わせの推移を出してみました。大体1日平均だと20件程度の問い合わせが 来ています。 50 全般的なサポートに使っているものとは別にユニット単位で運用しているチームもありますが、そちらは件数に含めていないため、 実際にはもう少し問い合わせ件数は多いでしょう。 ©CAPCOM 50

ゲーム開発者との関係性 定期的にエンジン機能を説明するウェビナーの実施 アンケート内容 ウェビナーの一例 RE ENGINEが持つ機能は多岐にわたります。 マニュアルも用意していますが、すべてをカバーできているとは言い難い状況です。そのためウェビナーを実施して、機能紹介や 51 TIPSなどの役立つ情報を定期的に提供しています。このウェビナーもゲーム開発者なら誰でも簡単に参加することができます。 ちゃんと各回の参加人数を記録していないのですが、一番多い時だと400人以上の方に参加していただいたこともあります。 参加者に対してアンケートを定期的に実施しており、より良い情報を提供できるよう改善に努めています。 ©CAPCOM 51

ゲーム開発者との関係性 課題 • タイトル数が増え、細かな動向の把握ができていない 定期的な状況の確認・聞き取り タイトルの現場で直接コミュニケーションを行う これまで紹介してきた通り様々な形でゲーム開発者との関係性を築いていますが、課題がないわけではありません。 おかげさまでRE ENGINEを採用したタイトルの数がどんどん増えていますが、それに伴い一つ一つのタイトルの動向を 52 把握しづらくなっています。ゲーム開発者がRE ENGINEでのゲーム開発において何か問題を抱えていたとしても気づけていない ケースも出てきました。そのためより細かくゲーム開発者とコミュニケーションを取っていく必要があると感じています。 改善策として、定期的に各タイトルに状況の確認を行い、困っていることやエンジン開発者への要望などを聞き取ったり、 タイトルのフロアにエンジン開発者が在籍し、直接コミュニケーションを行うといったことを試しています。 特に若手のエンジン開発者がタイトルのフロアに行くことで、ゲーム開発の現場を知る機会にもなると考えています。 ©CAPCOM 52

RE ENGINE開発ワークフロー エンジン開発のワークフローにも触れておきます。 53 ©CAPCOM 53

開発ワークフロー エンジン開発者になったら セットアップ説明ページ まず最初に、新たにエンジン開発に加わるところから説明します。 基本的な情報やセットアップについては情報サイトにあるので、それを見ながら環境を構築してもらいます。ちなみに画像にも 54 ありますが、説明の最初にRE ENGINEの正式名称について言及しています。 全て大文字でREの後にスペースを入れるのが正しい名称となります。ちゃんと正しい名称を使ってもらうためには最初が肝心ですね。 ©CAPCOM 54

開発ワークフロー 研修の実施 研修説明ページ セットアップが終わったら、エンジン開発者専用の研修を実施してもらいます。 この研修ではランタイム・ツール・およびランタイムとツールを連携させる、基本的な実装に関する課題を行ってもらいます。 55 課題ごとにコードレビューを行っているので、指摘を受けつつ質問も行うことで、理解を深めながら進めてもらえるように なっています。 新入社員の場合、大体2～3か月くらいで終わるボリュームになっています。コードレビューは主に2～3年目の若手にも協力して もらっていて、コードを指摘する側の訓練にも役立っています。 また実際にユニットに配属されるときには、ユニットごとの分野に特化した研修を用意していることもあります。 こういった研修を経て、エンジン開発者としての経歴をスタートさせます。 ©CAPCOM 55

開発ワークフロー 機能実装の流れ すり合わせ 実装 レビュー チェック そしてエンジン開発者として業務をこなしていくのですが、基本的にはタイトルからの依頼を受けて機能実装を行うことが 多いので、その流れを紹介します。 56 もちろんそれ以外にも、研究・検証、エンジン開発者発案の機能実装なども行いますが、今回は割愛します。 ©CAPCOM 56

開発ワークフロー 機能実装の流れ すり合わせ 実装 レビュー チェック チャットでの相談の一例 まずはどういった機能が欲しいのかを依頼者とすり合わせします。 ただ単に必要な機能を聞き取るだけでなく、「どういったことを実現したいのか」という目的を確認することが重要です。 57 もちろん依頼者は自分がほしいと思った機能に対するイメージを持っているのですが、必ずしも目的に対して最適な機能では ないことがあるためです。 その機能をどういう目的でどんなワークフローで使うのかを聞き取ることで、もっと最適な機能が思いつく場合があります。 そういったときはエンジン開発者側から提案する必要があります。 場合によってはすでにある機能で解決できることもありますし、目的を深堀りすることで、「効率化につながらないのでやっぱり なしで！」となることも稀にあります。 ©CAPCOM 57

開発ワークフロー 機能実装の流れ すり合わせ 実装 ランタイムコードはC++ ツールコードはC# レビュー チェック 内容が決まったら、実装を進めます。 実装を進めると細かい確認事項が出てくるので、随時依頼者とやり取りを行います。開発に使用するプログラミング言語は 58 ランタイム部分はC++、ツール部分はC#で開発します。 ©CAPCOM 58

開発ワークフロー 機能実装の流れ すり合わせ コードレビュー 実装 レビュー 依頼者によるレビュー チェック そうして実装が終わったら、レビューを行います。 レビューには、コードレビュー、依頼者によるレビューの2つがあります。 ©CAPCOM 59 59

開発ワークフロー 機能実装の流れ すり合わせ 実装 レビュー チェック コードレビュー依頼画面 コードレビューは基本的には同じユニットのメンバーが行いますが、ユニットを跨いだ機能を開発した場合などは他ユニットに 依頼することもあります。 60 レビュアーはGitLabのMergeRequest機能を使い、コードや動作の指摘を行います。同じくGitLabのPipeline機能を使いビルド チェックなどを行っていますが、ユニットごとの自動チェックを組み込んでいることもあります。 ©CAPCOM 60

開発ワークフロー 機能実装の流れ すり合わせ 実装 レビュー チェック Experimental版作成ダイアログ 依頼者によるレビューは、作ったものが意図通りのものになっているかを 実際に触って確認してもらうためですが、ここに RE ENGINE独自の仕組みがあります。 61 Gitのどのブランチを使ってどのタイトル向けのエンジンを作るかを指定するだけで、チェック用のエンジンを作成・提供することが できるのです。このチェック用エンジンは「Experimental版」と呼んでいます。 Experimental版の仕組みができたのはおよそ2年前ですが、それ以前は依頼者に確認するために一度機能をリリースするしか ありませんでした。機能実装初期は動作が不安定な状態であることも多く、問題があれば何度もリリースをしなければいけません でした。また機能が全タイトルに対してリリースされてしまうので、依頼者以外の他の人が誤って使ってしまうリスクもありました。 それがExperimental版の登場により、リリースする前に動作確認してもらうことが容易になりました。そのためリリース後に 「思っていたのと違う！」といった認識の齟齬を減らし、やり取りのコストを下げることができました。 ©CAPCOM 61

開発ワークフロー 機能実装の流れ すり合わせ コードのpush エンジン生成 チェック 実装 レビュー CIによる自動生成 チェック 自動チェック ＆ 手動チェック レビューを経てコードをmasterブランチに取り込むことで、CIによってリリースするエンジンの自動作成が行われます。 エンジン作成に成功すると次にチェックが行われます。 62 このチェックは自動・手動の2通りを行っています。自動チェックでは、ゲームを最初から最後までプレイしてクラッシュや、 ゲームが進行しないといった不具合がないかチェックします。クラッシュではない、見た目の不具合などについては自動では 対応しきれていないため、QAチームの協力を得ながら手動でのチェックを行っています。 ©CAPCOM 62

開発ワークフロー 機能実装の流れ すり合わせ 実装 過去タイトルは全て最新のエンジンでゲームが動作し、 互換性を担保しなければならない レビュー チェック ちなみにこのチェックでは、過去にリリースしたタイトルを利用しています。つまり「最新のエンジンを使って過去のアセットで 作られたタイトルを動かす」のです。 63 これはRE ENGINEが「過去タイトルは全て最新のエンジンでゲームが動作し、互換性を担保しなければならない」という方針を 取っているからです。一見そんなにおかしいところはないと思われるかもしれませんが、実はこれがとても大変だったりします。 ©CAPCOM 63

開発ワークフロー 機能実装の流れ 不具合を修正する必要がある すり合わせ 実装 タイトルのアセット修正が 可能 タイトルのアセット修正が 不可能 アセット修正 LegacyFlag対応 レビュー チェック 例えば不具合が見つかったので修正するとなっても、リリース済みのタイトルはその不具合がある状態で動いており、不具合を 修正することで挙動が変わってしまうためです。 64 タイトルのプログラムやアセットを変更することでゲームの挙動を変わらないようにすることもできますが、それがかなわない 場合もあります。その場合は過去の挙動、つまり不具合を維持する必要があります。この際過去の挙動を再現するために追加する フラグをLegacyFlagと呼んでいます。リリース済みタイトルではこのLegacyFlagをOnに、開発中のタイトルはOffにすることで 挙動の切り替えをできるようにしているのです。 不具合修正だけでなく、仕様変更の場合も同様の問題は発生します。こういった手間がありますが、リリース済みタイトルが 最新エンジンでも安定して動作しています。これにより、リリース済みタイトルの内容をいつでも確認出来たり、新しいプラット フォームでリリースする際のコストを下げることに繋がっており、過去の資産の流用をしやすくしています。 ©CAPCOM 64

開発ワークフロー 機能実装の流れ 0日目 1日目 すり合わせ 実装 コードのPush レビュー CIによるビルド ＆ チェック リリース チェック そうしたチェックを経て、機能はリリースされます。 毎日夕方にその日の更新を締め切り、CIによるビルドが行われ、1日かけてチェックを行い、問題がなければその日にリリース 65 しています。小さな機能追加であれば依頼後にすぐ実装を行い、翌日にはゲーム開発者に届けることができています。 基本的なリリースフローはこのようになっていますが、時にはエンジンがクラッシュするなどの開発に重大な影響を及ぼすような 不具合が発生することもあります。その場合は即修正を行い、特例でチェックを通さずにその日のうちにリリースすることも あります。 ©CAPCOM 65

開発ワークフロー 機能実装の流れ 100 90 すり合わせ 80 70 60 実装 50 40 レビュー 30 20 10 チェック 0 2023/1 2023/2 2023/3 2023/4 2023/5 2023/6 変更件数の推移 機能追加・不具合修正、また直接ゲーム開発者には影響しない変更も含めると、大体一日平均で約40件の更新が行われています。 グラフを見ていただければわかる通り、波はあるものの日々活発な更新が行われているのが分かると思います。 66 ちなみに今回初めてこのデータを出してみたのですが、月曜日が一番更新が少なく、曜日が進むごとに件数が増えていき、 金曜日が一番件数が多かったです。 ©CAPCOM 66

開発ワークフロー タイトルごとのエンジン提供 エンジンコード Title A 用 エンジン Title A Title B 用 エンジン Title B Title C 用 エンジン Title C こうしてタイトルに対してエンジンを提供しているのですが、もう少し提供部分について紹介します。 これまでの説明に合った通り、エンジンコードは一つのブランチに集約されています。しかしタイトルごとに使う機能が 67 異なるので、タイトルごとにエンジンをビルドして提供しています。 ©CAPCOM 67

開発ワークフロー タイトルごとのエンジン提供 Title A 用 エンジン エンジンコード Title A 用のモジュール設定 これはRE ENGINEでは機能がモジュールという単位で分かれており、どのモジュールを利用するかをタイトルごとに 設定することで実現しています。 68 不要なモジュールを排除して必要なモジュールのみで構成することで、ゲーム実行中に無駄な処理を実行したり、 不要なメモリ確保が発生することもありません。 ©CAPCOM 68

開発ワークフロー Gitブランチ運用 Title A 向け機能 Title B 向け機能 Title C 向け機能 masterブランチ 不具合修正 不具合修正 Title A ブランチ Git運用の観点も見てみます。 タイトル側でエンジンに対する機能追加要望が収束すると、あとは動作の安定性を担保したくなります。しかしmasterブランチを 69 使ったエンジンの影響を受けたままだと、他のタイトル向けの機能を含んだエンジンが提供されてしまいます。 そのためタイトル開発末期になると、masterブランチからタイトルブランチを作成します。タイトルブランチは基本的には 不具合修正のみを行うことで安定度を高めていきます。 ここまでがエンジン開発の大まかな流れの紹介となります。 ©CAPCOM 69

最後に 最後となります。 70 ©CAPCOM 70

エンジン開発者がただエンジンを作り、 ゲーム開発者がそれを受け取ってゲームを作る、 という関係ではなく、 ゲーム開発者とともに二人三脚でRE ENGINEを作っている これまで紹介した通り、エンジン開発のための取り組みを色々行っていますが、一番重要なことは、エンジン開発者がただ エンジンを作り、ゲーム開発者がそれを受け取ってゲームを作る、という関係ではなく、ゲーム開発者とともに二人三脚で RE ENGINEを作っているということです。 71 日々エンジン開発者とゲーム開発者が対話を繰り返し、それによりカプコンのゲームとワークフローにあったゲームエンジンが 生み出されています。これは古くはMT FRAMEWORKから続くカプコンのゲームエンジンが培ってきた土壌であり、今後も 大事にすべきことであると考えています。 ©CAPCOM 71

おわり 以上で本講演は終了となります。 どうもありがとうございました。 72 ©CAPCOM 72