『THE FINALS』のサーバー側物理――移動・破壊・瓦礫を一つの世界として同期する設計
開発者インタビュー、技術講演、制作資料、公式更新履歴を突き合わせ、サーバーとクライアントの分担を整理する
オンラインFPS『THE FINALS』では、プレイヤー移動、環境破壊、移動床や瓦礫などゲーム結果に影響する動的状態をサーバー側の共通世界として扱う。クライアントは入力を送り、薄い予測層で操作遅延を隠しながら、サーバーが返す正しい位置・姿勢を描画する。建物は試合中にゼロから粉砕せず、Houdiniで事前に破片化し、コリジョンも自動生成する。公開資料から確認できる事実と、そこから導く構成上の解釈を分けて整理した。
| 方法 | Embark Studios開発者への2022年インタビュー、2023年の公式ポッドキャスト書き起こし、GDC Vaultの技術講演概要、SideFXに掲載された制作パイプライン解説、公式Update 7.3.0およびSeason 8ノートを比較した。サーバーの責務、クライアント予測、破壊アセットの準備、発売後の破壊改善について、複数資料で役割が一致する記述を抽出した。 |
|---|---|
| 結果 | 開発者は、破壊に関わる物理をサーバーへ集め、移動床や瓦礫の正しいtransformをクライアントへ送ると説明している。プレイヤー移動は予測を最小限にした薄いwrapperを使い、最終的な状態はサーバーを正とする。建物はHoudiniで事前に粉砕され、破片用のコリジョンハルも自動生成される。公式更新では自重崩壊、構造物同士の損傷、落下物による下部環境の破壊が継続的に改善されている。 |
| 知見 | 特徴は、破壊を各端末の視覚効果として再生するのではなく、通路、遮蔽、足場、目標物の位置を変える共有ルールとして扱う点にある。一つの権威的な状態へ移動と破壊を集めることで、床が残っているか、瓦礫がどこにあるか、落下した物体が何に当たったかを全員で一致させられる。負荷を成立させる工夫は、実行時のネットワーク処理だけでなく、事前粉砕とコリジョン自動化を含む制作工程にもある。 |
| 限界 | 公開資料だけでは、サーバーの正確なtick rate、1試合あたりのCPU使用量、帯域、物体ごとの同期精度、視覚専用の小片や粒子をどこまでクライアント側で補うかは分からない。「クライアントで物理を動かさない」という説明はゲーム結果を決める動的物体の文脈であり、映像・音・粒子までサーバーが生成するクラウドゲーム方式を意味しない。 |
調査の問い
『THE FINALS』では、壁を抜いて射線を作るだけでなく、床を壊して目標物を落とし、倒れた建物が別の構造物を壊す。破壊後の地形と瓦礫は、その場にいる全員の移動と戦術へ影響する。これだけ変化する世界を、オンライン対戦でどのように一致させているのかを調べた。
確認できた設計の骨格
Embark Studiosの開発者は、サーバー側の移動と破壊を本作の主要な技術革新として説明している。公式ポッドキャストでは、破壊に関わる動的処理をサーバーへ置き、移動床や瓦礫の正しい位置・姿勢をクライアントへ送ると、さらに具体的に述べている。
| 担当 | 公開説明から確認できる役割 |
|---|---|
| ゲームサーバー | プレイヤー移動、環境破壊、移動床、瓦礫など、試合結果に影響する世界状態を進める |
| クライアント | 入力を送り、受け取った状態を映像・音・UIとして表示する |
| 予測層 | 通信の往復を待つ感覚を弱める。ただし予測を増やし過ぎず、サーバーとの食い違いを抑える |
| 制作パイプライン | 建物を事前に破片化し、各破片のコリジョンを自動生成して実行時の計算を準備する |
なぜ一つの正しい世界が必要か
壊れた壁が単なる映像なら、各端末が別々に演出しても大きな問題にはなりにくい。しかし本作では、穴が通路と射線になり、床を失ったプレイヤーと目標物が落ち、瓦礫が移動や射撃を妨げる。プレイヤーAの端末では床が残り、プレイヤーBの端末では床が抜けている状態では対戦が成立しない。
そのため、各端末が崩壊結果を独立に決めるのではなく、サーバーが一つの結果を計算して全員へ配る。移動と破壊が同じ権威的な世界に置かれることで、落下、衝突、遮蔽、足場の因果関係を保てる。
入力から表示まで
- 入力：プレイヤーが移動、射撃、爆発物の使用などを行う。
- サーバー計算：サーバーが移動、衝突、破壊、物体の状態を進める。
- 状態の配信：移動床や瓦礫などの正しいtransformを各クライアントへ送る。
- クライアント表示：PCやゲーム機が受け取った状態から映像、光、粒子、音、UIを描く。
- 補間と予測：表示を滑らかにつなぐ。ただし最終的な正解はサーバーに置く。
これは入力を送り、完成した動画を受け取るクラウドゲームではない。開発者も、その方式は遅延のため現実的ではないと説明している。サーバーが持つのは主にゲーム世界の正しい状態であり、最終的な描画は手元の機器が担う。
操作感とのトレードオフ
クライアント予測を増やすと、押した瞬間に動いたように見せやすい。一方で、サーバーが計算した結果と食い違ったときの位置修正も増える。予測を減らすと世界の一致は保ちやすいが、通信の往復時間が操作感に表れやすい。
開発者は、この間を薄いprediction wrapperで調整し、可能な範囲でサーバーの返答を待ちながら、アニメーションやカメラなどで遅延を隠すと説明する。この方式ではサーバーが多数の動的状態を処理し、複数のプレイヤーへ配るため、サーバー負荷と通信品質が操作感へ直結しやすい。
建物は試合前に壊す準備をしている
サーバー側で物理を扱うからといって、完成した建物を試合中にゼロから細かく割るわけではない。SideFXの制作資料によると、破壊可能な建物はHoudiniであらかじめ破片へ分割される。リアルタイム粉砕は負荷が高く、予測しにくいためである。
弾丸、爆発、プレイヤー移動に必要なコリジョンハルも自動生成し、破片の形を保てる範囲で隣接するハルをまとめる。開発時に壊れ方の材料を用意し、試合中は準備済みの破片の状態を進める。大規模なサーバー側破壊を成立させる最適化は、ネットワークコードだけでなくアセット制作から始まっている。
発売後も更新される破壊
公式Update 7.3.0では、建物が自重でより自然に崩れ、倒れた建物がほかの構造物へ損傷を与える改善が説明された。Season 8ではSmooth Destructionにより、落下する吊り構造物が下の環境を破壊するようになった。
Season 8のインスタントリプレイについても、開発チームはプレイヤー移動、環境破壊、物体同士の作用を高いデータ精度で再構成する必要があったと説明している。破壊を一瞬の映像ではなく、複数の状態が結び付いた出来事として扱っていることが読み取れる。
事実と解釈の境界
サーバー側の移動と破壊、正しいtransformの配信、薄い予測層、事前粉砕、コリジョン自動生成は公開資料で直接確認できる。一方、「この構成が全プレイヤーの地形差を防ぐためである」「制作時の準備が実行時負荷を抑える」という説明は、これらの資料をネットワークゲームの因果関係として組み合わせた解釈である。
正確なtick rate、CPU使用量、帯域、物体ごとの同期精度は公表資料から確認できない。また、視覚専用の粒子までサーバーが計算するという意味ではない。公開情報から言える中心点は、壊れる世界を演出ではなく全員が共有するルールにするため、移動と破壊の正解をサーバーへ集めた、ということである。