ゲーム物理エンジンにJolt Physicsが選ばれる理由｜Bulletとの違い

ゲーム開発やシミュレーション基盤の技術選定で物理エンジンを検討するとき、多くの C++ エンジニアが同じ壁に突き当たります。「Bullet の後継として何を選ぶべきか」「PhysX は使えるが GPU 前提の設計は今回の要件と合わない」「マルチプレイでの決定論性を担保できる OSS はどれか」といった疑問は、ドキュメントを個別に読み比べても即座には答えが出ません。

近年、その選択肢として名前が挙がるのが Jolt Physics（jrouwe/JoltPhysics） です。Guerrilla Games の『Horizon Forbidden West』や Kojima Productions の『Death Stranding 2』といった AAA タイトルで採用実績があり、MIT ライセンスで公開されている C++ 製の剛体・衝突検出ライブラリです。

とはいえ「AAA で使われている」だけで自プロジェクトへの採用を決めるわけにはいきません。機能スコープ、内部アーキテクチャ、対応プラットフォーム、そして Bullet Physics や NVIDIA PhysX との比較優位性が明確に見えないと、意思決定には踏み込めないはずです。

本記事では、Jolt Physics の公式 README・アーキテクチャ資料・類似リポジトリを一次情報として整理し、「自プロジェクトに Jolt を採用すべきか」を1回の読了で判断できるように解説します。本記事は動作検証を伴わないドキュメントベースのレビューであり、記載内容はすべて公式リポジトリと公式ドキュメントの記述に基づきます。

Jolt Physicsとは — マルチコア対応のゲーム物理エンジン

Jolt Physics（jrouwe/JoltPhysics）は、ゲームや VR アプリケーション向けに設計されたマルチコア対応の剛体物理・衝突検出ライブラリです。開発者は Guerrilla Games の元テクニカルリードである jrouwe 氏で、C++ で実装され MIT ライセンスで公開されています。

「ゲーム物理エンジン」というカテゴリには Bullet Physics や NVIDIA PhysX といった先行 OSS が存在しますが、Jolt が近年注目される理由は次の 3 点に集約できます。ひとつはマルチコア CPU を前提とした設計、もうひとつはマルチプレイでの巻き戻し・巻き直しを想定した決定論性、そして商用利用に制約が少ない MIT ライセンスです。

リポジトリの基本情報（スター数・言語・ライセンス・最終更新日）

公式リポジトリのメタデータは次のとおりです（本記事執筆時点、GitHub API 経由で取得した値）。

スター数は 1 万を超え、フォーク数も 800 以上に達しています。archived=false かつ fork=false であることから、本家リポジトリで現在も開発が継続されているプロジェクトであると確認できます。最終プッシュ日も直近であり、メンテナンス状況は健全な水準にあると判断できます。

想定される用途と代表的な採用事例

README の説明では、Jolt Physics は「ゲームおよび VR アプリケーションに適した、マルチコアに親和的な剛体物理・衝突検出ライブラリ」と位置付けられています。具体的な採用事例として README に明記されているのは次の 2 タイトルです。

• Guerrilla Games『Horizon Forbidden West』
• Kojima Productions『Death Stranding 2』

いずれもコンソール向け AAA タイトルであり、Jolt が商用ゲームの本番運用に耐える実装であることを示しています。本記事ではこの 2 タイトルのみを事実として引用し、それ以外の採用状況について断定的な言及は行いません。

より詳しい機能一覧・使い方・アーキテクチャは公式リポジトリの README を参照してください（jrouwe/JoltPhysics）。

Jolt Physicsの主要機能

Jolt Physics はゲームで必要とされる物理シミュレーション機能を一通り備えています。README およびアーキテクチャドキュメントに記載されている主要機能を、目的別に整理します。

剛体シミュレーションと制約システム

剛体（rigid body）シミュレーションは Jolt の中核機能です。球（Sphere）、立方体（Box）、カプセル（Capsule）、凸包（Convex Hull）、メッシュ（Mesh）といった標準的な衝突形状に対応しており、複雑な形状を凸包の集合として構成するコンパウンドシェイプもサポートされます。

制約（constraint）システムはヒンジ・スライダー・ボール・ラック＆ピニオンなど 12 種類以上の関節を提供します。乗り物の車輪や関節キャラクター、ロープ・チェーンの近似など、ゲームで頻出する連結構造をこれらの制約で構築できます。

ソフトボディとキャラクターコントローラー

ソフトボディ（soft body）は頂点ベースでシミュレーションされ、布（cloth）や変形物体の表現に用いられます。剛体中心の設計としては後発機能に相当しますが、実装済みであるため布や柔らかい物体を扱うゲームでも Jolt 単体で完結できるケースがあります。

キャラクターコントローラーは 2 種類が用意されています。ひとつは剛体を利用した簡易版の Character、もうひとつは剛体を経由せず自前でカプセル形状の当たり判定を行う高機能版の CharacterVirtual です。FPS やアクションゲームで求められる「壁を滑る」「段差を乗り越える」「傾斜で滑落する」といった挙動は CharacterVirtual 側で細かく制御できます。

クエリ機能（レイキャスト・シェイプキャスト・センサー）

シミュレーション本体とは別に、ワールドに対する幾何クエリも提供されます。特定の点から任意方向へ光線を飛ばして最初にヒットする物体を返すレイキャスト、任意の衝突形状を移動させたときの掃引結果を返すシェイプキャスト、そして衝突判定のみを行い物理応答を発生させないセンサー機能が代表例です。

センサーはトリガー領域の実装に利用でき、離散判定と線形キャストのいずれかを選択できます。ゲームロジックからワールドの状態を問い合わせる用途では、これらのクエリ API が中心的な役割を担います。

Jolt Physicsの内部アーキテクチャ

Jolt が「マルチコア対応」を掲げる根拠は、単なる並列化ではなくアーキテクチャレベルで並列実行を前提とした設計にあります。ここでは公式のアーキテクチャドキュメント（Docs/Architecture.md）に基づき、採用判断に直結する要素を 3 つの観点から整理します。

レイヤー分離設計（ObjectLayer と BroadPhaseLayer）

Jolt では衝突対象の管理に二層のレイヤーモデルを採用しています。

• ObjectLayer: NON_MOVING / MOVING / DEBRIS などの論理的な分類。ゲーム側で自由に定義できます
• BroadPhaseLayer: ObjectLayer を粗く束ねた分類。ブロードフェーズの計算効率化のために使われます

衝突ペアを制御する ObjectLayerPairFilter を介して「地形は動的オブジェクトとだけ衝突する」「破片同士は衝突しない」といったルールを宣言的に記述できます。この二層構造により、シーンにボディが大量に存在する場合でも、粗い分類レベルで無関係なペアを早期に除外できます。

マルチスレッドを支えるブロードフェーズとボディロック

ブロードフェーズは 4 分木（AABB クワッドツリー）で実装されており、各ノードが 4 つの子を持つ木構造でボディを管理します。実装はロックフリーのアプローチを採用し、複数スレッドからの同時更新に対応します。さらにシミュレーションステップ間の背景スレッドで新しいツリーを再構築する仕組みが備わっており、次のフレームでは最適化されたツリーに切り替えられます。

ボディへの並行アクセスを安全に行うため、Jolt はボディロック機構を提供します。固定サイズのミューテックス配列とハッシングを組み合わせ、BodyLockRead / BodyLockWrite / BodyLockMultiRead / BodyLockMultiWrite といった API から利用します。衝突フェーズ中は読み取り専用ロックで並列アクセスが可能で、PhysicsSystem::Update の実行中はロックが競合しない設計になっています。

これらの実装により、Jolt は「背景スレッドでの物理データ準備」「クエリと物理シミュレーションの並列実行」「アイランド（島）単位のスリープによる CPU 負荷削減」といった、マルチコア環境でのスループット向上に必要な要素を初期状態で備えています。

決定論的シミュレーションを支える要素

マルチプレイゲームでは、同じ入力から同じ結果が得られる決定論的シミュレーションが重要です。ロールバックネットコードや観戦モードのリプレイでは、他クライアントで再現できないと成立しません。

Jolt のアーキテクチャドキュメントには決定論性を明示的に保証するセクションはありませんが、実装要素として次の点が挙げられています。

• Sequential Impulse solver による制約解決
• 固定時間ステップ（複数の衝突ステップに分割可能）
• Symplectic Euler 積分器 による安定した積分
• 制約解決順序が結果に影響する旨の明示

README では「入力の複製だけで遠隔クライアントに再現可能」と説明されており、マルチプレイ用途を意識した設計であることが読み取れます。ただし異なるコンパイラや浮動小数点設定を跨いでビット単位で同一結果を保証するかは、公式ドキュメントでは踏み込んだ言及がありません。厳格な決定論性が要件になる場合は、実プロジェクトの環境で個別に検証する必要があります。

対応プラットフォーム・依存関係・ライセンス

自プロジェクトに Jolt を組み込めるかは、ライブラリの機能以上に「動作要件・ビルド環境・ライセンス」で決まります。ここでは公式 README の記述を基にチェックリスト形式で整理します。

動作要件（C++バージョン・SIMD・コンパイラ）

Jolt Physics の主要な動作要件は次のとおりです。

RTTI と例外処理を使わない設計は、コンソール開発や組み込みに近い環境でしばしば要求される制約です。標準テンプレートライブラリ以外のサードパーティ依存がない点も、既存プロジェクトへ組み込む際の敷居を下げる要素です。

一方、コンパイラ要件は比較的新しい世代を求めます。VS 2022・Clang 16・GCC 12 は執筆時点で広く普及していますが、古いビルドツールチェーンで運用している現場では準備コストを見込む必要があります。

対応プラットフォーム

対応 OS は次のとおりです。

• Windows
• Linux
• macOS
• iOS
• Android
• WebAssembly

コンソール専用ゲームではもちろん、モバイル・ブラウザまでカバーする点は、クロスプラットフォーム展開を前提とする開発チームにとって有利な条件です。とりわけ WebAssembly 対応があるため、ブラウザ上で物理シミュレーションを提供する Web ゲームや Web シミュレーション用途でも選択肢に入ります。

ライセンス（MIT）と商用利用

Jolt Physics のライセンスは MIT です。商用製品への組み込み、改変、再配布に強い制約はなく、著作権表示とライセンス条文の同梱を守れば柔軟に扱えます。

商用ゲーム開発では、SDK やミドルウェアのライセンス条項が意思決定を左右することが少なくありません。MIT は許容度の高いライセンスの代表例であり、社内法務レビューの負担が比較的軽い点は実務的なメリットと言えます。

類似の物理エンジンOSSとの比較

Jolt を選ぶかどうかを判断する上で外せないのが、既存の代表的な OSS 物理エンジンとの比較です。ここでは Bullet Physics と NVIDIA PhysX の 2 つを比較対象として取り上げます。

Bullet Physics との違い

Bullet Physics（bulletphysics/bullet3） は、長年ゲーム・VR・ロボティクス・機械学習の各領域で使われてきた物理エンジンで、zlib ライセンスの下で公開されています。C++03 以降で動作し、Python バインディングの PyBullet が公式に提供されているため、機械学習用途では実質的なデファクトのひとつです。

一方、リリースの活動性という観点では、最新安定版は 3.2.5（2022 年 4 月）で、Issue はサポート管理のため一時閉鎖されているとリポジトリ上で告知されています。長期的な保守が必要なプロジェクトで新規採用を検討する場合、活動性の面では慎重な検討が必要です。

Jolt との差分を要約すると次のようになります。

• ライセンス: Bullet は zlib、Jolt は MIT。いずれも許容度の高いライセンスですが、条項の細部は異なるため法務確認は必要
• 設計思想: Jolt はマルチコア並列を前提として設計されているのに対し、Bullet は伝統的に単一スレッド前提の実装から発展してきた経緯があります
• Python バインディング: Bullet は PyBullet が公式提供。Jolt は主に C++ 中心（非公式バインディングは複数存在）
• GPU 対応: Bullet は実験的な OpenCL 対応。Jolt は CPU 前提

強化学習など Python から大量のシミュレーションを回す用途では PyBullet の存在感は大きく、Bullet を優先すべき局面が明確に存在します。逆に、C++ でマルチコア CPU の性能を引き出したい商用ゲーム開発では Jolt が優位に立ちます。

NVIDIA PhysX との違い

NVIDIA PhysX（NVIDIA-Omniverse/PhysX） は NVIDIA が開発する物理エンジンで、BSD-3-Clause ライセンスで公開されています。CPU に加えて CUDA による GPU 実行経路を持ち、破壊シミュレーション（Blast SDK）や流体・煙（Flow SDK）といった拡張が周辺エコシステムに揃っています。Unity Engine では 5 以降で採用されており、商用ゲームの採用実績はきわめて多いエンジンです。

Jolt との差分を要約すると次のようになります。

• GPU 対応: PhysX は CUDA を活用した GPU 実行に対応。Jolt は CPU 前提
• Python バインディング: PhysX は ovphysx が公式提供され、DLPack を介した Python エコシステム連携が可能。Jolt は主に C++
• ライセンス: PhysX は BSD-3-Clause、Jolt は MIT
• 決定論性: GPU 経路など経路依存で決定論性の担保が難しいケースが存在（PhysX 側）。Jolt はマルチプレイ用の決定論を意識した設計

NVIDIA 系 GPU を前提とした AI シミュレーションや、Omniverse 上での大規模シミュレーションでは PhysX が明確に強みを持ちます。一方、CPU 側で並列化して安定した決定論性を狙う設計や、GPU 依存を避けたいマルチプラットフォームゲームでは Jolt が有力な選択肢になります。

比較サマリ表

Jolt Physicsの採用が向くケース・向かないケース

比較表を踏まえたうえで、Jolt が向くケース・慎重に検討したいケースを整理します。

向いているケース

以下のような要件を持つプロジェクトでは、Jolt の設計思想がフィットしやすいと言えます。

• マルチプレイ FPS / スポーツゲーム: ロールバック・巻き戻しを含む決定論的シミュレーションが必要
• CPU 上の並列化でスループットを稼ぎたい 3D アクションゲーム: 静的地形と多数の動的ボディの組み合わせで、broad phase の並列再構築の恩恵が大きい
• VR / モバイル / WebAssembly を含むクロスプラットフォーム展開: 対応プラットフォームが広く、依存が薄いため組み込みやすい
• 商用製品での使用: MIT ライセンスで法務レビューの負担が比較的軽い
• RTTI / 例外を使わないコーディング規約下での開発: コンソール開発や組み込みに近い制約を持つプロジェクトと親和性が高い

向いていない / 慎重に検討したいケース

一方、以下のような要件がある場合は、Jolt 以外の選択肢を並行して検討したほうが良い可能性があります。

• GPU 物理が要件: 大規模な粒子・流体・破壊シミュレーションを GPU で回したい場合、PhysX の CUDA 経路が優位
• Python から物理シミュレーションを大量に回す機械学習用途: PyBullet や PhysX の ovphysx が公式に提供されている一方、Jolt は主に C++ 中心
• 既存の Bullet・PhysX 資産が大きい既存プロジェクト: 移植コストが Jolt の性能メリットを上回るかは慎重に見積もる必要がある
• VS 2022 未満・Clang 16 未満・GCC 12 未満の古いビルドツールチェーン: コンパイラ要件を満たすためのインフラ更新が発生する

これらは Jolt の欠点というよりも「設計上のスコープ外」に当たる領域です。用途とのミスマッチが判明した段階で早期に他のエンジンに切り替える判断ができれば、後戻りのコストを最小化できます。

メンテナンス状況とコミュニティ

OSS を長期プロジェクトで採用するときに欠かせないのが、メンテナンス状況の確認です。GitHub API から取得したメタデータでは、Jolt Physics は次の指標を示しています。

• スター数: 10,944
• フォーク数: 803
• 最終プッシュ: 2026-07-16
• archived: false
• fork: false

スター数は 1 万を超え、フォーク数も 800 以上に達しています。archived=false かつ fork=false であるため、本家リポジトリで開発が継続していることが確認できます。最終プッシュ日も執筆時点の直近であり、活発なコミットが続いている状態です。

ドキュメントも継続的に整備されており、公式ドキュメントサイト（jrouwe.github.io/JoltPhysics）で API リファレンスが公開されています。API リファレンスがドキュメントサイトに整備されているプロジェクトは、外部エンジニアが後追いで実装意図を追跡しやすく、内製での組み込みや拡張の障壁が低くなります。

コミュニティサポートについては、GitHub の Issues と Discussions で開発者と利用者のやり取りが継続的に行われています。商用サポート契約が必要な水準の要件がある場合は、OSS 単体で完結させるか、社内で保守能力を持てるかを別途評価する必要があります。

導入前に読んでおきたい公式リソース

Jolt Physics を実際に評価する段階に進むなら、公式が提供している以下のリソースから順に確認するのが効率的です。本記事ではドキュメントベースでの紹介にとどめ、実装コマンドや動作結果には踏み込みません。導入検証は必ず読者自身の環境で公式手順に沿って進めてください。

• README: github.com/jrouwe/JoltPhysics — 機能一覧・ビルド方法・ライセンスの一次情報
• アーキテクチャドキュメント: Docs/Architecture.md — レイヤー設計・ボディロック・ブロードフェーズの実装解説
• HelloWorld サンプル: HelloWorld/HelloWorld.cpp — 最小構成の PhysicsSystem 初期化からステップ更新までを示すサンプル
• サンプル集の解説: Docs/Samples.md — 種々の機能を試すサンプルアプリケーションの一覧
• 公式ドキュメントサイト: jrouwe.github.io/JoltPhysics — API リファレンス

「機能スコープの確認」→「アーキテクチャドキュメントで並列モデル・決定論性の設計を理解」→「HelloWorld でシミュレーションループの粒度を把握」→「Samples で自プロジェクトの要件に近いユースケースを確認」という順に読むと、採用可否の判断に必要な情報を短時間で集められます。

まとめ

本記事では、マルチコア対応の C++ 製ゲーム物理エンジン Jolt Physics（jrouwe/JoltPhysics） を、他の代表的な OSS 物理エンジンとの比較を軸に整理しました。要点は次の 3 つです。

• マルチコア前提の設計: ロックフリーのブロードフェーズ再構築、ボディロック機構、アイランド単位のスリープなど、CPU 並列化の恩恵を最大化する仕組みが初期状態で組み込まれている
• 決定論性を意識した設計: Sequential Impulse solver・固定時間ステップ・Symplectic Euler 積分器といった実装要素と、マルチプレイでの再現性を意識した README の記述
• MIT ライセンスと薄い依存: 標準テンプレートライブラリのみに依存し、RTTI と例外を使わず、対応プラットフォームは Windows / Linux / macOS / iOS / Android / WebAssembly まで広い

CPU 側で並列化して安定した挙動と決定論性を狙う商用ゲーム、マルチプラットフォーム展開を含む中規模〜大規模プロジェクトでは、Jolt Physics は有力な選択肢になります。一方で GPU 物理や Python バインディングを重視する用途では PhysX や Bullet が優位に立つ局面もあります。

自プロジェクトの要件を「並列化・決定論性・ライセンス・依存」の 4 軸で棚卸しし、本記事の比較表と照らし合わせることで、Jolt を採用すべきかを一次判断できるはずです。次のアクションとして、まず README とアーキテクチャドキュメントを読み、要件に近い Samples の項目を追いかけるところから始めるとよいでしょう。