コード読解演習 Step 5【実戦解読】：巨大オープンソースリポジトリ実地読解（Box2D編）

### 巨大OSS・初見コードベース読解の「3段階トップダウン・スキャン法」

1. **第1段階：最小サンプル（Samples/Examples）からエントリポイントを逆引き**:
- ドキュメントを読む前に `samples/` や `examples/` を探す。
- 「たった30行で立方体が落下する最小コード」を見つけ、呼び出されているAPIの順序（初期化 → 登録 → 更新）を特定する。
2. **第2段階：公開ヘッダ（include/）から「中核データ構造」を特定**:
- 内部実装（src/）には一切立ち入らず、外部向けヘッダだけを見る。
- 大抵のエンジンには全体の親玉となる「World」や「Engine」クラスが存在する。
3. **第3段階：毎フレームの心臓部（Step() / Update()）のパイプライン解読**:
- 「時間の経過（dt）」を受け取る中核関数の内部処理順序を箇条書きにする。
- 例: 入力処理 → 外力適用 → 衝突判定 → 拘束解決 → 座標積分。

• 内部実装（src/）から読んではいけない: 内部の細かい数学計算やメモリ最適化から読むと確実に迷子になります。まず「外部からどう使われているか（Usage）」を把握するのが鉄則です。

#include <iostream>
#include <vector>
#include <memory>
#include <string>

// 2次元ベクトル
struct Vec2 {
    float x = 0.0f;
    float y = 0.0f;
    Vec2(float _x, float _y) : x(_x), y(_y) {}
    Vec2 operator+(const Vec2& o) const { return {x + o.x, y + o.y}; }
    Vec2 operator*(float s) const { return {x * s, y * s}; }
};

// 剛体定義（生成用パラメータ）
struct BodyDef {
    Vec2 position{0.0f, 0.0f};
    Vec2 velocity{0.0f, 0.0f};
    float mass = 1.0f;
    bool isStatic = false; // 地形などの静的剛体か
};

// 剛体オブジェクト（Body）
class Body {
    friend class World; // World からのみ生成・管理される設計（ファクトリパターン）
private:
    Vec2 m_position;
    Vec2 m_velocity;
    float m_mass;
    float m_invMass; // 逆質量（計算高速化のため事前計算）
    bool m_isStatic;
    std::string m_userData; // ユーザーがゲーム側オブジェクトと紐付けるフック

    Body(const BodyDef& def)
        : m_position(def.position),
          m_velocity(def.velocity),
          m_mass(def.mass),
          m_invMass(def.isStatic || def.mass <= 0.0f ? 0.0f : 1.0f / def.mass),
          m_isStatic(def.isStatic) {}

public:
    void applyForce(const Vec2& force, float dt) {
        if (m_isStatic) return;
        m_velocity = m_velocity + (force * (m_invMass * dt));
    }

    const Vec2& getPosition() const { return m_position; }
    const Vec2& getVelocity() const { return m_velocity; }
    void setUserData(std::string tag) { m_userData = std::move(tag); }
    const std::string& getUserData() const { return m_userData; }
};

// 物理空間全体を統括する中核クラス（World）
class World {
private:
    Vec2 m_gravity;
    std::vector<std::unique_ptr<Body>> m_bodies;

public:
    explicit World(Vec2 gravity) : m_gravity(gravity) {}

    // 剛体の生成は必ず World を経由する（所有権の集中管理）
    Body* createBody(const BodyDef& def) {
        auto body = std::unique_ptr<Body>(new Body(def));
        Body* ptr = body.get();
        m_bodies.push_back(std::move(body));
        return ptr;
    }

    // 物理シミュレーションの1ステップ進行（心臓部）
    void step(float dt) {
        // 1. 重力と外力の適用（速度更新）
        for (auto& b : m_bodies) {
            if (!b->m_isStatic) {
                b->m_velocity = b->m_velocity + (m_gravity * dt);
            }
        }

        // 2. 座標の更新（オイラー積分）
        for (auto& b : m_bodies) {
            if (!b->m_isStatic) {
                b->m_position = b->m_position + (b->m_velocity * dt);
            }
        }
    }

    size_t getBodyCount() const { return m_bodies.size(); }
};

• なぜ new Body ではなく world->createBody なのか？: Box2Dのような高性能エンジンでは、内部のメモリプール（メモリアリーナ）から一括で高速アロケーションし、衝突判定やキャッシュの局所性を保つために、生成窓口を World に一本化する設計を採用しています。

• 1. src/ ディレクトリの中にある最も行数の多い .cpp ファイル
• 2. samples/ や examples/ にある「最小の動くサンプルコード」
• 3. CMakeLists.txt やビルドスクリプトの全行
• 4. ヘッダファイルに含まれる数学アルゴリズムの導出式

正解と解説を見る

正解：samples/ や examples/ にある「最小の動くサンプルコード」
正解です！最小サンプルコードを見ることで、「初期化→オブジェクト生成→毎フレーム更新」というライブラリの意図されたAPI呼び出し手順が一瞬で把握できます。

• 1. C++の文法上の制約で、クラス外でコンストラクタを呼べないから
• 2. World が全剛体のメモリ所有権を一括管理し、メモリプールによる高速化や衝突ペア登録を一元的に行うため（ファクトリパターン）
• 3. メモリ使用量を半分にするため
• 4. マルチスレッドを禁止するため

正解と解説を見る

正解：World が全剛体のメモリ所有権を一括管理し、メモリプールによる高速化や衝突ペア登録を一元的に行うため（ファクトリパターン）
正解です！物理エンジンが空間内の全剛体をリストやアロケータで確実に追跡・管理できるようにするため、ファクトリメソッド経由でのみ生成を許可する堅牢なカプセル化設計です。

• 1. CPUにおいて重い割り算命令を避け、高速な掛け算命令で加速度（F * invMass）を算出でき、静的剛体（固定地形）を invMass = 0.0f でゼロ除算なく扱えるから
• 2. 変数のメモリサイズが小さくなるから
• 3. 負の質量を表現できるようになるから
• 4. 浮動小数点数の丸め誤差が完全にゼロになるから

正解と解説を見る

正解：CPUにおいて重い割り算命令を避け、高速な掛け算命令で加速度（F * invMass）を算出でき、静的剛体（固定地形）を invMass = 0.0f でゼロ除算なく扱えるから
正解です！除算は乗算に比べてCPUクロックを多く消費します。さらに質量無限大（動かない地面）を `invMass = 0.0f` と定義することで、特別な if 分岐なしに `velocity += force * 0.0f` で静止状態を維持できます。

• 1. 物理エンジンのコードを難解にしてリバースエンジニアリングを防ぐため
• 2. 物理エンジン側がゲーム側の Player や Enemy などの具象クラスに依存することなく、ゲーム側オブジェクトと紐付ける疎結合フックを提供するため
• 3. 剛体のテクスチャ画像を物理エンジン内で描画するため
• 4. セーブデータを暗号化するため

正解と解説を見る

正解：物理エンジン側がゲーム側の Player や Enemy などの具象クラスに依存することなく、ゲーム側オブジェクトと紐付ける疎結合フックを提供するため
正解です！物理エンジンはゲーム固有のロジックに依存すべきではありません。userData フックを持たせることで、依存性を逆転させずに衝突相手がどのゲームキャラかを判定できます。