現代のアクションやFPSのように動的なゲームジャンルにとって、最高の体験をするのに必要なフレームレートとは120fpsでしょう。圧倒的にキャラやモーションが見やすくなり、ゲームプレイのしやすさも変わってきます。モニターのリフレッシュレートの進歩、そしてコンソールやPCのスペックの進歩もあり、現代のゲームはハイフレームレートを実現することこそが最高級のゲームプレイを提供するものともいえるでしょう。
とはいえ、いまも60fpsを安定して出すのも大変なのに、120fpsを目指すのはとてつもなく難しいのも確かです。現場でそう感じているエンジニアやアーティストは少なくないでしょう。これに関して、CEDEC 2026の講演「NINJA GAIDEN 4の120FPS達成の道」は、一つのロールモデルとして興味深い内容がまとまっていました。
本講演では『NINJA GAIDEN 4』のコンソール向け120fpsモードの実現プロセスを解説しています。株式会社I.Meistersの今井星氏、プラチナゲームズ株式会社の大森亘氏、坂本拓也氏、野口容介氏によるエンジンチーム4名が登壇し、「勇気と知恵と根性」をテーマに高フレームレートを実現するための最初からの作り方や事前のツール準備のほか、最後の泥臭い最適化作業という3段構えで、描画・CPU・メモリ各領域の具体的な最適化手法までが共有されました。
120fpsモードはどのように実現したか
そもそも120fpsは1フレームあたりわずか8.3ミリ秒しか処理時間が許されないという、相当にハードルの高い目標です。『NINJA GAIDEN 4』開発プロジェクト開始時点の2024年8月では、まだ30fpsも出ていない状態から、4ヶ月でバーティカルスライスを120fps化という目標が据えられ、開発期間の残り3ヶ月で全ステージへの展開という非常にタイトなスケジュールが課されていました。
この短期間で目標を達成するため、最初に行われたのが「やらないことを決める勇気」という割り切りです。海やテレイン、ナビメッシュは動的更新をやめてベイクベースに、ストリーミングはワールドパーティション的なグリッド方式ではなくエリア単位のロードに決めたといいます。さらに動的GIやフレーム補間による疑似的な高フレームレート化も断念。あとから最適化するのではなく、最初から120fps前提でグラフィックスを作り込む方針も定められました。
さらに、すべてのシーンを一律に120fps化するのではなく、シーンの性質ごとに優先順位を分けています。アクションが最も求められるボス戦はパフォーマンスを最優先に、道中や雑魚戦は描画クオリティと120fpsの両立を目指し、バトルが発生せず見た目を魅せたいエリアの「ビューティフルコーナー」は描画クオリティを優先。カットシーンは最適化対象外とし、全編プリレンダリングで対応しています。
「達成」を客観的に判断するため、シーンの区分ごとに数値基準が設けられました。ボス戦は115fps以上、道中・雑魚戦は105fps以上、ビューティフルコーナーは80fps以上という目標値です。
さらに瞬間的な負荷と平常時の負荷を分けて評価するため、「ヒッチライン」(1フレームでも超えたらNGとなる引っかかり検知、全シチュエーション共通で20ミリ秒)、「OKライン」(安定して目標fpsで遊べることを保証)、「セーフライン」(重いと感じる割合を抑える)、「NGライン」(VFXなど数フレームの重さを検知)という4段階の判定ラインが用意されています。
実際の最適化は5つのフェーズで進行しました。2024年8月時点ではフレームレート計測結果がほぼ真っ赤(低フレームレート)という状態から、まず月末までにエンジニア主導で仕組みやグローバル設定レベルの最適化を実施。9月にはアーティストやゲームプログラマーを巻き込んだ最適化でアセット側への適用を進め、60fpsを達成しています。
10月のフェーズ3では、描画負荷の高いビューティフルコーナー、移動が速くストリーミング頻度の高いレールゾーン、CPU負荷の高いボス戦という、特に120fps達成が難しい3箇所に絞って先行して攻略。ここで見えてきたヒッチの要因(レベルストリーミング、同期生成、スレッド優先度によるコアの奪い合い、スピンロックの集中など)への対処法を確立し、11月のフェーズ4でバーティカルスライス区間全体の120fps達成にこぎつけました。
このフェーズでは、QAチームが未達箇所を報告し、エンジンチームがCPU起因かGPU起因かを一次調査したうえで適切な担当(エンジニアやVFXチームなど)に割り振り、対応後にQAチームが再確認するというイテレーションの型が確立されています。この体制が固まったことで、12月以降のフェーズ5では「ローラー作戦」として、全ステージへ自動ツールによる4ライン判定を展開し、ゲームチーム側だけで最適化が完結するフローへ移行。2025年2月、全ステージでの120fps要件達成に至りました。
描画領域の具体的な最適化手法
エンジンはAgility SDKとシェーダーモデル6.6を採用し、バインドレスリソースを積極活用してドローコール数を削減。描画パイプラインには一般的なディファードレンダリングを採用し、4K出力に対応するアップスケーラーとしてFSR2を組み込んでいます。
描画パスはオペイク・トランスルーセント・フィルターの3カテゴリを中心にGPU時間のバジェットを設定。不透明モデルの描画では、早期Zパス・シャドウパス・Gバッファーパスの3回でそれぞれ発生していたスキニング計算を事前計算1回にまとめ、各パスではUAVから結果を読み取るだけにすることで負荷を削減しています。早期Zパスも不透明・非不透明で分離し、不透明側は先にデプスを描いてピクセルシェーダーの実行自体を省略。デカールはデプス参照のみで順序を問わないため、不透明直後にまとめてインスタンシング描画する工夫も行われました。
半透明描画については、血液表現にVAT(頂点アニメーションテクスチャ)を用いることで、ビルボードのテクスチャ表現より描画面積を抑えつつ不透明描画やライティングの質も確保。ビルボードもテクスチャ形状に沿ったメッシュを事前生成することで、透明ピクセルへの無駄なサンプリングを削減しています。
このほか、通常は半透明で描画しているキャラクターの紙(和紙のような素材表現)を、120fpsモード時にはディザリング表現へ切り替えることで負荷を軽減する仕組みも用意され、マテリアル側で120fpsモードかどうかを判定するノードを追加し、アーティストが対応表をもとに細かく設定できるようにしています。
アップスケールはポストプロセス後に配置することで負荷軽減につなげつつ、FSR2の標準的なリアクティブマスク生成機能では雨粒が消えてしまう問題が発生したため、マスクの濃さをアーティストが調整できるようにする対応も行われました。非同期コンピュートによるGPUパーティクル駆動、瞬間的高負荷対策としての動的解像度、CPU側でのオクルージョンカリング(Intelのマスクソフトウェアオクルージョンカリングを応用)なども採用されています。
並列計算の活用とアイドル時間の削減
CPU側は並列計算の活用とアイドル時間の削減を基本方針とし、キャラクターロジックなどを担う「ゲームスレッド」をあえて作らず、依存関係を定義したジョブグループ単位でスケーラブルに並列実行する設計が採られています。このジョブシステムはCEDEC 2016のスクウェア・エニックスによる講演を参考に実装されたといい、依存関係のあるグループ間の順序を保ちながらも高い並列度を確保。これによりバトルシーンでもCPU使用率87%という高い稼働率を達成しました。
ロック処理は基本的にスピンロックを採用しつつ、ロック内処理を最小化。衝突発生時にランダムな待ち時間を挟むことで再衝突を抑える工夫や、スレッドローカル変数に処理をまとめてから最後にマージする手法も紹介されています。
またスレッドが動作するコアを固定する「アフィニティマスク」の活用により、メモリキャッシュ効率が8%ほど改善したといいます。ミドルウェアが内部的に独自スレッドを生成しているケースには注意が必要で、実際に音響ミドルウェアの内部スレッドがジョブスレッドに割り込みヒッチを引き起こした事例も報告され、初期化時のマスク設定によって解決されたことも共有されました。
具体的な最適化例としては、階層構造を持つオブジェクト(乗り物や装備など)についてリクエストをまとめて一括更新する手法や、破棄・生成処理といった他から参照されないタイミングが明確な処理を非同期タスク化する手法が挙げられました。特にマップやセットといったデータ構造のクリア処理は負荷が大きく、非同期化の重要な対象になったといいます。
最適化を効率よく進めるため、複数のプロファイラーが用意されました。問題箇所を自動検知し前後の状況を動画保存する「QAプロファイラー」、CPU・GPUどちらが原因か、誰が対応すべきかを判別する「CPU/GPUプロファイラー」、実際に重い要因(ポリゴン数、コリジョン、ライティングなど)を掘り下げる「確認用プロファイラー」、アセット単位まで踏み込める「詳細プロファイラー」の4段階です。
またエンジニアだけでは対応しきれないアセット側の最適化のため、アーティストが自らクオリティとパフォーマンスのバランスを調整できるスイッチも数多く用意されました。ISM・HLOD・マテリアルマージによる描画統合、近距離でもディテールを残したい箇所の個別コントロール、シーン分割によるロード時のヒッチ回避、遠景オブジェクトのアニメーション更新頻度低減などが、アーティストの手によって細かく設定されています。
まとめとして、本講演から学べるのは次のことでした。まず、最初から120fps前提で作らなければ、後からの倍速化は現実的に不可能であること。数値による達成基準の明確化が計測と判断の前提になること。エンジニアだけでなくアーティストが力を発揮できる環境とスイッチを用意することの重要性が総括されました。代表的なシーンで成功パターンを確立してから全体へ展開する進め方が、短期間でのプロジェクト達成の鍵になったといえます。
