サイバーコネクトツー最新作『戦場のフーガ 2』の“裏側”――誰もが気になるサーバーの容量やブランチの切り方など、Perforce Helix Core × UE4開発におけるバージョン管理の思想を聞く

（左）株式会社サイバーコネクトツー 開発支援課 中園氏
（右）株式会社サイバーコネクトツー 『戦場のフーガ』制作プロデューサー 村上氏

――いよいよ『戦場のフーガ2』発売とのこと、おめでとうございます。今日は『戦場のフーガ』と「バージョン管理」というテーマでお話をお聞きします。まずは自己紹介をお願いします。

村上：『戦場のフーガ』制作プロデューサーの村上です。前職はIT業界で、ゲーム業界に転身したあとはUIプログラムを担当していました。今回は自身初となる制作プロデューサーという立場でゲーム開発に携わっております。今日はよろしくお願いいたします。

中園：開発支援課の中園です。サイバーコネクトツーにはゲームプログラマーとして入社しました。現在在籍する開発支援課は8名規模の組織で、ハード・ソフト問わず技術調査や内製ツール開発、Perforceなどのサーバー管理やセットアップなどを担当しています。

――本作の概要について教えてください。

村上：『戦場のフーガ2』は名前の通り『戦場のフーガ』の続編となります。前作の1年後が舞台となっていて、12人の子どもたちも再び登場します。

物語は、前作で子どもたちが乗っていた「タラニス」という戦車が、仲間の半数を乗せたまま暴走するところから始まります。残った子どもたちはタラニスを追いかけるわけですが、そのさなかで衝撃的な悲劇が起きてしまいます。それによって主人公であるマルトが復讐に駆られていくという物語です。

――続編とのことですが、構想自体は開発初期からあったのでしょうか？

村上：シリーズ全体の構想は、松山（株式会社サイバーコネクトツー 代表取締役 松山洋氏）の中に最初からありました。ですから、本作も開発そのものは2019年から行っていました。1作目の『戦場のフーガ』が2021年7月発売なので、その2年前から本作のシナリオや企画が並行して進行していたわけです。

当初は『戦場のフーガ』のDLCとしてリリースする構想もありましたが、ボリュームが大きかったため、前作発売時期の前後に続編として発売することが決定しました。そこから新システムなどの企画を練り直し、最終的にはイラストなどの素材枚数やシナリオボリュームが前作の2倍という大規模な作品となりました。

――前作と並行して制作していたという意味では、開発資産を引き継いでプロジェクトを進めることができたメリットも大きいように感じます。開発環境はアンリアルエンジンですか？

村上：はい。UE4.27で開発しています。プロジェクト全体の規模感としては、開発の時期によっても流動的ではありますが、平均してアーティスト 5～7名、ゲームデザイナー 3名、プログラマー 3名が携わっていました。

――開発支援室としては、どのタイミングからプロジェクトに参画していたのでしょうか。

中園：初期段階の環境構築から携わります。弊社の場合、UE開発タイトルでは必ずPerforceサーバーを立てて運用していますので、プロジェクト初期からサーバー運用やアカウントの整備などをやっていました。

最初の環境構築さえ終わってしまえば、あとはプロジェクトの要望に応じてアカウントや権限の付与などを行うだけですね。ただ、前作では全世界リリースに向けたローカライズ向けの台本間出力ツールを開発するなど、内製ツール開発なども行っていました。

――バージョン管理ツールにはいくつかの選択肢があると思いますが、Helix Coreを使用した理由を教えてください。

中園：振り返ると、2010年代にUE3.5を使ったのが最初のUE開発事例だったと思いますが、そこでバージョン管理を行うにあたって「Helix Coreが良いらしい！」とのことで導入したのが最初ですね。

UE3にインテグレーションされていて動作も保証されている。そして、ソースコントロール機能を使った連携ができるのも大きい。CEDECなどで発表されている他社事例も参考にしながら、導入を進めていきました。

驚いたのは、ファイル転送速度が圧倒的に速かったことです。計測する意味がないくらい、まるっきりスピード感が違ったので、それ以降UE開発プロジェクトでは必ず使うようになりましたね。

――シリーズ2作目となる本作ですが、どういったコンセプトが打ち立てられたのでしょうか。言語化されたコンセプトがあれば教えてください。

村上：『戦場のフーガ』にはシリーズを通して「選択と決断のRPG」というコンセプトがあります。本作では、その正当進化が目指されました。

選択と決断という言葉はゲームシステムと強く紐づいていて、例えば前作では「ソウルキャノン」という味方の命を犠牲にすることで敵を撃破するシステムが実装されていました。誰を選ぶかはプレイヤー次第ですが、ここで選ばれたキャラクターは戻ってきません。

前作のソウルキャノン。子どもたちの1人を選択し、その生命と引き換えに敵を殲滅する。使用は任意。また、これを連発したからといって最速クリアできるわけではないバランスで成り立っていた

――今回はタラニスではなく、前作に登場した「タラスクス」に搭乗しており、新たなソウルキャノンである「マーナガルム」も登場しています。これらの意図を教えてください。

村上：宿敵タラスクスに搭乗することは初期構想から決まっていました。「マーナガルム」は戦闘中に1度だけ使用できる強力な兵器で、子どもの生命力をわずかに使用するため、対象の子どもは戦闘不能状態になります。ただ、次のインターミッションで回復するとバトルに復帰できます。

ただし、本作にもソウルキャノンは登場します。こちらは任意選択ではなく強制となっているため、「あと何ターン以内に倒さないと、自動的に撃たれてしまう！」という強いリスクを背負って戦うことになります。仲間を守るためには、マーナガルムやスキルを駆使して、ソウルキャノンが発射される前に敵を倒さなければいけません。

本作のソウルキャノン。子どもたちに指示をする「AIとなったハクス」の判断によって、ピンチ時に自動的に発動してしまう。これを防ぐために、マーナガルム等を駆使してバトルを終わらせる必要がある

マーナガルム発動画面。選ばれたキャラクターは一時的に戦闘不能になり、経験値が獲得できない。誰を選ぶかも重要な「選択」になる

――仲間が一時的に戦闘不能になるということは、「ここぞ」で使わないと逆に敗北し、ソウルキャノンによって誰かを失ってしまうと。ここで戦闘時のリスク・リターンが成立するわけですね。

村上：そうですね。ソウルキャノンは正直使いたくない手段だと思いますし、以前も「これを使うくらいなら全滅する！」と選択するプレイヤーもいました。これをシステムとして昇華したいと考えて、マーナガルムと強制的なソウルキャノンという仕様を策定しました。

ゲームバランスを一歩間違えると批判が出る部分だとは思っているので、ここは社内モニターを繰り返して緻密に調整を行っています。

――もうひとつ気になったのが、今作ではマルトが明確に主人公として扱われていますね。前作は子どもたち一人ひとりが主人公というゲーム性でしたが、この意図を教えてください。

村上：前作はお気に入りの子どもを好きになって欲しいということもあって、それぞれのプレイヤーが自分の好きなキャラを育てていくのがゲームデザインの一環になっていました。

ただ、復讐の物語を描く上では、明確に主人公を設定する必要がありました。シナリオ構築の時点で、年長者のマルトを主人公として設定しました。面白いのは、主人公を立てた瞬間、それに紐づくシステムが追加できるようになった点です。

そのひとつが「ジャッジメントチャンス」です。シナリオの途中でユーザーに「覚悟」「共感」の2択を迫り、選んだ結果によって新しいエピソードが追加されたり、主人公マルトのリーダーとしての資質に影響を及ぼしたりするシステムです。また、選択の結果で「リーダースキル」を獲得し、バトルを有利に進めることができます。

ジャッジメントチャンスは、ストーリーの進行とともに何度も訪れる会話型イベント。選択肢は「覚悟」「共感」の2つのカテゴリに分かれており、選択肢によってマルトが強いリーダーとして、あるいは優しいリーダーとして育っていく。リーダーとしての性質は「リーダースキル」としてゲーム上にも現れる

――「和をもって尊しとなす」ではないですが、一般的には仲間と一緒に共感しながら仲良くやっていくのが良いような気もしますね……。そこも含めて、ユーザーの思想をマルトに重ねてプレイできるという感じでしょうか。

村上：ただ、復讐に身を焦がすと共感性は失われていきます。本作のマルトの姿勢に共感していくと、逆に覚悟に寄った選択を自ずと行うようになるかも知れません。正しい選択肢はないですし、特定のリーダースキルが強すぎるというバランスでもないので、自由に選んでいただきたい部分です。

本作から実装された「リーダースキル」

このほか、ルート進行においても飛行船システムを新たに採用。マスを飛ばしたり、前のマスに戻ったり、ここでも選択の幅が広がっている

――『戦場のフーガ』には多くのユーザーフィードバックがあったと思います。続編制作において、ユーザーの声が作品に影響を与えた部分はありましたか。

村上：UIの使い勝手やシステム面については、ユーザーの声を取り入れています。SNSなども確認しますし、そこで出てきた操作上の不満などは積極的に情報として収集しています。また、本作で対応した部分は、アップデートパッチとして前作にも反映しています。これは今後も続けていきます。

一方、ストーリーは絶対にブレさせません。伝えたいテーマは変わらず、遊び易さの部分で改善をしていく姿勢です。これとは別に、SNSでの皆さまの反応はいつも楽しく拝見しています。

――ここからは開発環境の具体的なお話をお聞きできればと思います。当初はDLCとして発売も検討されていたとの話題もありましたが、開発環境は前作と本作は完全に同一なのでしょうか。

村上：前作の環境を複製しているので、基本的には同一になります。ゲームエンジンはUE4で、2Dイラストなどはクリエイターが最もスピードの出せるツールを選んでいるような状態です。DCCツールはMaya、Substance Painter、3dsMax、2Dアートに関してはAdobeのほかClipstudioも使用しています。

中園：もちろん、前作と本作ではサーバーは別に立てています。弊社では原則として1タイトルに対して1つのサーバーを用意していて、新しいプロジェクトではサーバーのバージョンも最新のものを使っています。

――プロジェクトのデータは、プロトタイプの試作段階からHelix Coreを用いてバージョン管理を行っているのでしょうか？

中園：少人数のプロジェクトでもHelix Coreを立てますが、開発のサイズによってはオンプレミス運用も行います。小規模開発から本開発に移る時にサーバーをクラウド化するような流れが多いですね。

クラウドサーバーは毎月の費用も掛かりますし、サーバー容量が小さくて問題ないなら最初はオンプレミスから始めた方がコストメリットがあります。

――クラウドとオンプレミスの使い分けはどうなっていますか？

中園：昔はすべてオンプレミスでしたが、今はサーバー本体をクラウド化して、社内にプロキシサーバーを立てる方針です。本作もクラウドサーバーが本体です。

一方、前作の場合はオンプレミスで運用していました。プロジェクト立ち上げ時点では小規模でしたので、そのままオンプレミスで運用していたという流れです。ここは開発期間やその他の方針によって流動的な部分ですね。

Linux環境でサーバーを構築。「導入初期は調べ物もありましたが、今は手癖ですぐできるようになりました」と中園氏。タイプマップ（ファイル属性、ファイルタイプなどファイルの取扱いを定義するテーブル）はプロジェクト共通で使用しているため、今では半日かからずに初期の環境構築が完了するという

――コストメリットや取り回しという面でもオンプレミスは強いですね。一方で柔軟なスケーラビリティなど、クラウド化によるメリットも大きいと思います。

中園：オンプレミスは遠隔地での通信速度がネックになりますしね。本社（福岡市内）と東京など、距離による通信速度の変化などの問題が発生しますし、海外の協力会社がサーバーにアクセスする場合もあるため、ケースによっては正しくクラウド化すべきですね。

クラウドにサーバーを立てることで通信のラグを発生させず、さらにプロキシサーバーを仲介することで速度の低下を緩和させています。プロキシサーバーはキャッシュ容量次第ですが、立てるだけならローコストで済みます。

――ちなみに、CI/CDとの連携は行っていますか？

村上：Jenkinsを使って、定期的な時間にビルドを実行しています。リリース用のパッケージを深夜に作っておいて、翌朝チェックするような形ですね。また、P4サーバーの最新データをすべて集めてパッケージしてサーバーにアップロードする工程も自動化しています。『戦場のフーガ2』はマルチプラットフォーム対応のため10個前後のパッケージがあるので、ほぼ夜通しで回しています。

――続いて、直接的に運用に関する部分をお伺いできたらと思います。最初に知りたいのが、どこまでのファイルをHelix Coreで管理しているかという点です。.psdのような中間データやドキュメント類も含めてすべて一箇所に置いているのか、それともプロジェクトに直結する部分だけなのか、教えてください。

中園：基本は全部ですね。中間データやドキュメント、pdfファイルなども含めて、プロジェクトに関わるデータはすべてHelix Coreで管理しています。履歴の上限管理も行っていませんが、あまりにも古いものやリビジョンが積み重なったファイルはアーカイブとして別のサーバーに移動させることはあります。

――その場合は容量も気になります。例えば『戦場のフーガ 2』の開発規模であればどの程度を用意しておくべきでしょうか？

中園：『戦場のフーガ2』は2TBで運用しています。巨大なタイトルは2倍以上、12TBまでは行きますね。ここもタイトル特性に応じて変化する部分ですし、DLCやブランチからの更新で重くなっていく部分ですね。

――開発方針として、ブランチの切り方も気になります。

村上：ブランチは基本はリリースのタイミングで切っています。1.0.0のマスターチェック時点でブランチを切っていて、あとはパッチのバージョンで分けています。つまり、開発中は1ブランチでやっています。

――基本的には1つのブランチで開発をしているんですね。ちなみに、ファイルのLock（作業状態のファイルをロックして、他のユーザがチェックアウトできないようにする機能）は使っていますか？

村上：Lockを掛けながら行う作業はそこまで多くありません。ローカライズに関するファイルだけは、複数人が編集すると壊れたり、1行ずれただけでも大惨事になったりしますので、その時に使うくらいです。

運用でカバーしている部分としては、リリース時期の1週間ほど前からSubmitを許可性にしています。ここは人力というか、ワークフローで制御する形になっているので、システム的に上手いことやれると良いな、と思っている部分です。

――少し細かい話題も良いでしょうか？お二人が良く使う、好きな機能などがあれば教えてください。ちなみに自分はShelve（p4 shelve: サブミット前のチェックアウト状態のファイルを一時的に保存し、他ユーザと共有する機能）が好きでよく使います。

中園：管理側で言うと、P4Adminが素晴らしいと思っています。管理ツールとして必要なものは全部揃っていて、アカウント作成から管理者の設定までGUI上で一通り完了します。P4Admin以外はほとんど使わず、コマンドで直接的になにかをするのはアーカイブを作ったり、サーバーからファイルを削除したりといったファイルに対するアクションだけです。

村上：チェックアウトの印がつくのも便利ですね。他のバージョン管理ツールに比べてファイルの一覧も見やすいですし、誰がなにを触っているかがすぐに分かるので、本当にチーム制作向きだと感じます。「これ、誰がやりました？もう作業しました？」という無駄なコミュニケーションがなくなるだけで、開発スピードが加速する感覚があります。

機能でいうと……プログラマー時代はReconcile（p4 reconcile: チェックアウトされていないファイルの書き込み権限を手動で有効にし、必要に応じてファイルの編集、追加、削除を行う操作）が好きでしたね。ソースコードは軽いので、特に使いやすかったですね。

――これまでのお話の総括として、Helix Coreの強みや、『戦場のフーガ 2』開発事例から見たメリットを教えてください。

村上：制作プロデューサーという視点で見ると、Helix Coreは担当者の作業管理が非常にしやすく、また履歴を追いやすいのが本当に優れていました。仮にトラブルが起きても、1つずつ戻して特定ができる。

そして、ただファイル管理をしているだけではなく、誰がいつ、どの程度の作業量をこなしていたのかを分析するツールとしても役立っています。ワークフローを整備する際にも、各担当者の稼働率を確認できるようになりました。

中園：それ以外にも、今もまさにお世話になっていますが、トラブルなどに際して東陽テクニカ様に日本語で質問できるというサポート体制は非常にありがたいです。フリーのツールだと自分達がトラブルを探るところからスタートしてしまいますし、海外ツールは英語のやり取りになるため時間が掛かります。充実した国内サポートがあるというのも、明確な強みだとは思います。

――ありがとうございました。最後に、改めて『戦場のフーガ 2』について、ファンや読者の方にメッセージをお願いします。

村上：『戦場のフーガ2』、いよいよ5月11日に発売です。開発スタッフ一同120%の魂を注いで作った作品ですので、ぜひお楽しみいただけますと幸いです。また、今後は本作だけでなく、前作のアップデートも行っていきます。こちらも併せてご注目ください。

これからもぜひ『戦場のフーガ』シリーズをお楽しみください！

神山 大輝

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

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