2017年1月19日（木）

【電撃PS】『バイオハザード7』インサイドレポート第9回を期間限定全文掲載。テーマは“RE ENGINE”

　PS4/Xbox One/PC用ソフト『バイオハザード7　レジデントイービル』の開発現場を作家・師走トオル氏が密着レポートする連載企画“バイオハザード7 インサイドレポート”。全14回にわたる本連載を、順番に“1週間限定”で公開します。

　今回は、2016年11月24日発売の『電撃PS Vol.627』に掲載された連載・第9回を2017年1月25日までの期間限定で全文掲載します。

File.09　RE ENGINE

　File.03でも述べたが、最新のゲームハードの性能をフルに引き出すには、そのハードを最適化し、扱いやすくする役割を果たす優れたゲームエンジンが必須となる。

　現在多くのゲームメーカーが、Unreal Engineをはじめとする“高性能かつ、汎用性の高いエンジン”を採用しているが、一方でより作品の志向や特性にマッチした自社製のゲームエンジンを開発しているメーカーもある。カプコンもその1つだ。カプコンには専門の技術開発部があり、独自のエンジンを開発してきた歴史もある。

　その代表例が“MTフレームワーク”だ。PS3やXbox 360が発売された当時、それらのゲームハード向けに、マルチプラットホームでゲームを制作することを容易にするエンジンとして独自開発された。

　MTフレームワークはその後もアップデートを続け、10年以上もの期間にわたってカプコンのゲーム開発の根幹を支え続けてきた。しかし、同エンジンもさすがに誕生してから時が経ち過ぎ、大きなアップデートを加えないことには次世代機（ここで言う次世代機とはPS4などの第8世代ゲームハードのことだ）で使用するには限界があった。まだMTフレームワークを用いてソフトを開発することは可能だったが、さまざまな問題が生じていた。次世代機のパフォーマンスを十分に引き出しきれないことに加えて、イテレーション速度――変更と確認を行うための待機時間が長くなりすぎていたのだ。

◆◇◆◇◆◇◆◇◆◇◆

　PS4用ゲームの開発は、PCとPS4専用の開発マシンによって行われる。PC上で制作したプログラム用コードやグラフィックのデータを、PS4専用開発マシンにロードし、処理させることでようやく画面に表示される。

　従来のMTフレームワークで次世代機向けソフトウェアを開発するには、このロードや処理の時間が非常に長くなっていた。処理すべきデータが大きくなったため、わずかなプログラムを修正しようとしただけで、5分以上待たされることもあった。開発末期になると1つのシーンにより多くの情報や処理が必要になる。些細な変更の確認だけで1時間以上待たされることもあったという。

　そのような環境を変えるべく、カプコンでは次世代機向けエンジンの開発が進んでいた。まだRE ENGINEの開発が始まる前のことである。新エンジンの達成目標は、次世代機のパフォーマンスを引き出す処理能力と、優れたアセットベース開発環境、そしてイテレーションの高速化だった。目指すゴールはのちに誕生するRE ENGINEに近しいものだった。

　しかしこのエンジン開発は、いくつもの大きな問題が生じ、頓挫することになる。

　「1＋1が、2どころか、マイナスになっていました」

　そう語ってくれたのは石田智史。当時はスクリプトパートのモジュール制作リーダーであり、『7』ではエンジン制作チームのリードプログラマーとなる人物だ。

　このエンジンでは求められる機能ごとに制作チームが編制されていた。各チームがベストを目指して制作した個々の機能を集合させることで、高パフォーマンスを生み出す――そんな目論見で開発を進めていたのだ。しかし、実際に各機能を組み上げてできたモノは、相乗効果を生み出すどころか互いの良さを殺してしまうようなものだった。

　「基本設計は合議ではなく、“芯”となる誰かが中心になるべきでした」

　石田はそう語った。File.03で竹内が語った思いと似たビジョンを抱いていたのだ。

◆◇◆◇◆◇◆◇◆◇◆

　また、さらに異なる問題も生じていた。

　「エンジン制作チームとゲーム開発チームとの間に、距離が生じかけていたんです」

　そう語ったのは、後に『7』エンジン制作チームのマネジメントを務めることになる田原武文だ。

　幅広い知識と高い技術を持つプログラマーが“より高い機能を”と求めるのは自然な流れだろう。その一方でゲームエンジンとは、ただ高度な機能があればいいというものではなく、多くのスタッフが使いこなせてこそ、効率的なゲーム開発につながる。しかし長い開発の過程で、当時開発していたエンジンは使いやすさよりもパフォーマンスを重視した“エンジンありき”の性能に偏りつつあったのだ。16年間、さまざまなソフトで“ゲーム開発側”として制作に携わってきた田原はその経歴を買われ、ゲームエンジン開発側とゲームソフト開発側との調整役――マネージャー的な役割でプロジェクトに参加することとなった。

　この当時、開発をサポートする職責であった竹内は、ゲームエンジンと開発に関するこれらの事情をよく理解していた。そして2014年。『7』の開発にあたっては新たなエンジンが欠かせないと考えていた竹内は、石田と田原に声をかけた。

　MTフレームワークの基本設計を行った経験を持ち、さらに新エンジン開発の頓挫を経験した石田になら、『7』のための新エンジンの“芯”を担ってもらうことができる。竹内は「イテレーション速度を上げてほしい。そのほかは好きなようにエンジンを作ってほしい」と文字どおり、エンジンの“芯”を石田に委ねた。そして“ゲームエンジンを作る側”と“ゲームソフトを作る側”という両者の中間にいた田原には、エンジン制作チームのマネジメントを任せた。

◆◇◆◇◆◇◆◇◆◇◆

　新エンジンに求められたのは、2つの性能だった。

　なによりもまず『バイオハザード7』を作るためのエンジンであるということ。　File.03で触れたとおり、竹内が目指したゲームエンジンは、他社でも使われることを前提とした汎用性の高いものではない。あくまで“『7』ありき”であり、『7』開発のために特化した尖ったエンジンであればよかった。結果的にカプコンのほかのタイトルで採用されることになったとしても、その対応は後回しで良いと考えていた。

　そしてもう1つは、竹内の言葉にもあったイテレーション速度の短縮だ。

　先に述べたとおり、旧来のゲームエンジンで次世代機向けゲームタイトルを開発するには、変更と反映を確認するための待機時間が長くなりすぎていた。それを大幅に短縮することは必然の目標だった。

　2014年4月から7月までの3カ月間、石田を中心に『7』のための新エンジンのシステム設計が行われた。そしていよいよ本格的に、後に“RE ENGINE”と名づけられることになる新エンジンの開発が始動する。技術開発室から人員が呼ばれ、チームメンバーは次第に増えていった。

　「失敗を繰り返さないためにも、RE ENGINEの開発にあたっては、メンバーの意識づけを大事にしました」

　当時のことを田原はそう語る。

　RE ENGINEは、前述した“『7』に特化した”性能ありきで設計された。また田原は、エンジン開発者よがりな“エンジンありきのエンジン”になってしまった失敗のことをよく知っていた。いずれも、過去のやり方を大きく改めねば解決できないことだ。だからこそ、マネージャーとして各メンバーの意識づけに傾注したのだ。

◆◇◆◇◆◇◆◇◆◇◆

　RE ENGINE制作チームのメンバーは、誰もが卓越した技術者である。自分のやり方に自信と誇りを持ち、それがベストだと考えている。だが、それはある危険もはらんでいる。たとえば1つの技術の運用に対し、互いに「これがベストだ」と譲らない2つのやり方が示されれば、無用の衝突が生まれる。そこでチームでは、必要な技術ごとにリーダーを立て、権限と責任が委譲された。

　また、実際に開発現場で展開されるワークフローを考慮していないような、使いやすさを軽視した機能を付け足そうするメンバーがいれば、必ず止められた。それは過去に経験した“エンジンありきのエンジン”になる愚を繰り返すことになるからだ。新しい機能を追加する際には、必ずほかのチーム（プロトタイプ制作チームや、アート制作チーム）のメンバーと綿密な打ち合わせをするようにした。

　定期的にソースコードのレビューも行われた。

　大変理解が難しいのだが、たとえばキャラクターの“手を動かすプログラム”を作ろうとしたとしよう。ゲーム中にはさまざまなプログラムが存在し、この場合はキャラクターに関するプログラムを修正していくことになる。しかし“手を動かすプログラム”の存在を知らなかった別のスタッフが、シーン全体を制御するプログラムを介してキャラクターの“手”を操作してしまうと、後々問題に繋がりやすい。キャラクター側の“手を動かすプログラム”、シーン側の“手を動かすプログラム”が干渉し合い、動作が不安定になってしまうことがあるからだ。そこで各メンバーが作ったプログラムのソースについて、作り方に問題がないかをレビューし、あわせて情報共有を徹底することで問題が生じないようにしていった。

　開発はひとまず順調に進み、この年の年末には、RE ENGINEの根幹部分がほぼできあがったという。つまり、Unityで制作されていたグレーボックスを、RE ENGINE上で動かせる目途が立ったのだ。

　間もなくUnityからRE ENGINEへの移行作業が始まった。だが、ここで多くの問題が出始めた。

　File.07で述べたように、プロトタイプ制作チームは汎用性、柔軟性にすぐれたUnityの機能を活かし、さまざまなアイデアを実装し、作っては壊すという試行錯誤を繰り返していた。そのためデータ管理上のルールが十分に徹底されておらず、でき上がったものを丸ごと移すには統一性を欠く状態だった。また、グラフィック以外はUnityで制作されたデータをそのままRE ENGINEに移すという予定だったが、こちらも想定通りにはいかず、正しく動作させるにはデータの修正や加工をする必要があった。結局、多くのデータは作り直した方が早いという結論に至ったという。このUnityからRE ENGINEへの移行は、当初の目論見では容易にできる算段だったため、ここで大幅な遅延が生じる結果となった。

◆◇◆◇◆◇◆◇◆◇◆

　さらに、この頃から別の問題が生じ始めてもいた。

　少々話は変わるが、関連のある話なのでどうかお付き合いいただきたい。

　現世代のゲーム開発を語るうえで、決して外せない概念がある。前段にも登場している単語、“アセットベース開発”だ。

　ゲームを作る場合、プログラミングやグラフィックといった専門技術に精通した専門スタッフが不可欠だ。しかもゲームハードが進化していくにつれ、必要な技術や知識は年々増している。8bitの時代ならば1人のクリエイターがプログラムやグラフィックといった複数の作業を担うこともあったが、今や分野の異なる専門技術は、分業するのが当たり前になっている。

　その結果、ゲーム開発はある段階を迎えた。たとえばプランナー（企画）がゲームバランスの調整のため、キャラクターの攻撃パターンを増やしたいと考えたとする。その場合、新しい攻撃モーションを作るにはデザイナーが、それをゲームに組み込むにはプログラマーの手助けが必要となる。

　ゲームの仕様にもっとも精通しているべきプランナーが、細かな調整すら簡単にできなくなってしまったのだ。このような状況は好ましいものではない。そこでゲーム開発の現場では、スクリプトと呼ばれる簡易プログラム言語を作るなどして、プランナーがゲームシステムに直接関与できる範囲を増やしてきた。

　『RPGツクール』を想像してもらうのが一番だろう。実際にはそこまで簡略化されているものではないが、ある程度の範囲においては、専門的な技術がなくとも特定のゲームを開発、修正することが可能な環境を作ってきたのだ。

　現世代のゲーム開発環境はその延長線上にある。サウンドや3Dグラフィックデータ、当たり判定の制御やドアの開閉制御のような汎用的に使えるプログラムを“アセット”と呼ぶが、そのアセットを追加、修正することでゲームを作っていく環境がアセットベース開発の概念だ。これはUnityやUnreal Engineなどにも共通している。

　RE ENGINEではこのアセットベース開発の概念を、よりわかりやすく形にすることを実現している。　その結果、開発者1人1人が関与できる作業の種類、領域が大きく拡大した。

　従来なら、人型の3Dキャラクターを“表示”し、モーションを“再生”させ、歩くたびに足音を“鳴らす”といった作業は、それぞれの工程でプログラマー抜きにはできなかった。

　だがアセットベース開発をより使いやすい形で具現化したRE ENGINEでは、専用のエクスプローラーにさまざまなデータが登録されたアセットブラウザからキャラクターのオブジェクトをドラッグ＆ドロップするだけで簡単に表示することができる。表示されたキャラクターに、モーションのアセットをドラッグ＆ドロップすれば簡単に動かすこともできるし、指定したタイミングで足音を鳴らすといった作業が、プランナー1人でできるようになったのだ。

◆◇◆◇◆◇◆◇◆◇◆

　ただ問題となったのは、アセットベース開発が、個々人が幅広い開発にアクセスできる環境だということだ。その環境を少人数で運用するならともかく、大人数の現場に適用するとどうなるかについては、エンジン制作チームにも未知の領域だった。

　2015年の春ごろから、それにともなう不具合が起き始めていたのだ。

　たとえば、ゲーム内にペットボトルを登場させるとする。ペットボトルという外観のモデルアセットは専門のモデルデザイナーが作成するが、中で揺れ動く液体については、エフェクトの担当者が専用のアセットを作ることになる。

　アセットベース開発が可能なRE ENGINEでは、こういった作業を2人のメンバーが並行して作業できるようになっている。ただ、問題はチェック作業だった。たとえば邸の中に置かれたペットボトルを想像してほしい。中の液体が汚くても、ペットボトルの外側だけが妙に綺麗だったら違和感を覚えるだろう。その逆もしかりだ。

　また、せっかくエフェクト担当者が中身を作り終えても、モデルデザイナーがペットボトルを作り終えない限り、いつまで経っても完成品とはならない。それぞれの目指すものと優先順位、納期をしっかり共有する必要があった。

　ちなみにこの問題について、彼らは“ライン体制”という『7』開発チーム独自の体制を生み出すことで解決している。ただその解決方法が実行されるのはもう少しだけ先の話となるので、詳しい経緯は次項以降に回すことをご容赦いただきたい。ただ言えるのは、彼らは初期のRE ENGINEだからこそ生じた問題を、チーム編制という運用手法でカバーしたということだ。

　その後もエンジン制作チームの苦労は続いた。たとえばRE ENGINEにどういう機能が必要かは、『7』のゲーム開発チームの要望を取り入れる形で進められてきた。ただ、そうなるとどうしても“エンジンの完成度＝ゲームの完成度”という構図になってしまう。つまり、エンジンの開発が進まないとゲームの開発も進められず、またその逆もしかりだった。そして今ここに詳しく書くことはできないが、『7』開発チームはもちろん、エンジン開発チームも今後も大小さまざまな紆余曲折を経ることとなる。

◆◇◆◇◆◇◆◇◆◇◆

　現段階では、RE ENGINEがどのような実績を上げたかについてのみ言及しておきたい。

　まず、フォトリアリズム――写実的で現実と区別がつかないようなクオリティのグラフィックを高フレームレートで描画できるようになった。

　また、開発メンバー1人1人が、幅広い範囲で調整に参加できるようになった。これについては象徴的なシーンがある。詳しく言及はできないが、ゲーム内で通称“ガレージ戦”と呼ばれるボス戦がある。筆者の見た限りだが、このガレージ戦は恐らく『7』開発において、もっとも変化を繰り返した戦闘シークエンスだ。その裏には妥協することなくベストを目指した担当者たちのさまざまな試行錯誤があるのだが、それが可能だったのも使いやすいアセットベース開発環境＝RE ENGINEがあったからこそだ。

　複雑なボスの動き方、ステージの多様な変化、驚きの結末。最終的に完成したガレージ戦は、間違いなくあなたをあっと言わせることだろう。筆者も一体どれだけ複雑なプログラムで動いているのかと思ったが、そのすべてが特別なプログラムを組むことなく、RE ENGINE内の機能を用いるだけで作成されたというのだ。この点はぜひガレージ戦をプレイするときまで覚えておいていただければ幸いだ。

　つまりRE ENGINEは、プログラマー以外のスタッフの使い勝手の良さと、描画パフォーマンスの双方を大きく向上させることに成功したのだ。“万人に使いやすく”と“優れたパフォーマンス”という2つのテーマはえてして相反しがちなものだが、どちらも犠牲にすることなく両立させている点は特筆に値するだろう。

　また、RE ENGINEは後にマクロ機能を実装することになる。カプコンの従来のゲーム開発では、ゲームタイトル開発側がエンジンに機能を追加してもらいたいと考えた場合、まず要望書をエンジニアに提出し、検討を経た後、スケジュールを調整してようやく反映されるというやり取りがあった。しかしRE ENGINEでは、各ゲームタイトル開発側で、ある程度自由にカスタマイズできる機能が入っている。ゲームタイトルごとに、エンジン側が修正を加えるという手間が格段に減ったのだ。

　当初の目的であったイテレーション速度の向上も多大な効果を発揮している。『7』開発が佳境に差し掛かった頃、イテレーション速度は作業感覚的にほぼゼロと言えるレベルまで短縮されたという。これは『7』の作品自体にも大きな貢献を果たした。多くの作業時間が短縮した結果、作品のブラッシュアップのための時間に充てることができ、ゲームそのもののクオリティ向上に繋がったのだ。

　「『7』が完成しても、RE ENGINEに完成はありません。今後もバージョンアップを続けていきますから」

　竹内はそう語った。

　RE ENGINEの“RE”は、“reach for the moon”から来ている。つまり、人類に到達不可能な領域に手を届かせる、不可能を実現しようという意味が込められているのだ。

　またRE ENGINEは、『7』開発の“専用”エンジンとして生まれてきた。それはただ高度な処理の高速化を可能にしただけということではない。どのような環境ならばゲーム開発がより効率的に、より自由になるかという『7』開発チームの経験値そのものが、現在のRE ENGINEには蓄積されているのだ。『7』開発の経験値を蓄えたエンジンは、もはや“専用”エンジンにはとどまらない。

　最終的に、このエンジンがこれから先にどのような進化を遂げていくのかはわからない。しかし、これからも多くのカプコン作品に採用されていくことだけは間違いない。RE ENGINEが、今後カプコンというゲームメーカーをどのように変えていくのか。そんなところに注目していくのもおもしろいかもしれない。