ゲームエンジン・描画基盤

このプロジェクトでは、Wikipediaの記事をそのまま表示するのではなく、記事の構造をゲームプレイに使える形へ変換するところを中心に実装しました。API取得、テキスト描画、構造解析、コース生成を1本の流れとしてつなぎ、記事ごとに異なる地形が自然に立ち上がります。

1. 記事構造をコース要素へ変換するマッピング

IDWriteFactory と ID2D1Factory1 を使って記事をオフスクリーンの ID3D11Texture2D に描画し、その途中でレイアウト情報を拾っています。見た目を作るための描画処理を、そのまま地形生成の入力にも使う設計にしたことで、HTML解析用の別経路を増やさずに済みました。

• HeadingRegion（見出し）による起伏生成: H1〜H6 の位置を拾ってハイトマップへ反映し、見出しの密度が高い記事ほど地形の変化が増えます。記事の構成差がそのままコースの難しさに出ます。
• ImageRegion（画像）によるハザード配置: 記事中の画像領域を障害物の候補として扱い、バンカーやウォーターハザードに割り当てています。テキスト以外の要素もコースに反映されるため、地形のパターンが単調になりにくくなりました。
• LinkRegion（リンク）による遷移先生成: <a> タグはカップや次ステージの入口として扱い、リンク先の記事へ動的に遷移できます。記事のリンク構造をそのままステージ遷移に使うことで、ゲームの進行とWikipediaの探索が切り離されない構成になっています。

2. 地形ごとの差を出すための摩擦計算

コース生成だけではゲームとしての差が出にくいため、ボールの転がり方も独自に実装しました。test_physics_friction.cpp で挙動を固定しながら、摩擦、重力、斜面上での停止判定を順に検証しています。

// 摩擦と重力の影響を計算し、ボールの減速をシミュレート
void ApplyRollingFriction(Entity e, float deltaTime) {
    auto& phys = registry.get<PhysicsComponent>(e);
    float gravity = 9.8f;
    // 地形材質に応じた摩擦係数 (Fairway: 0.35, Green: 0.15)
    float friction = GetSurfaceFriction(phys.position);
    float deceleration = gravity * friction;

    // 静止摩擦判定 (微小斜面での安定化)
    if (CanStaticFrictionHold(phys.velocity, phys.slopeAngle)) {
        phys.velocity = Vector3::Zero;
    } else {
        phys.velocity -= phys.velocity.Normalized() * deceleration * deltaTime;
    }
}

この計算を入れたことで、平坦な地面と傾斜地で止まり方が変わり、生成コースごとの手触りを出せるようになりました。あわせて test_tangent_generator.cpp で法線マップ計算も固めており、見た目の起伏と物理挙動がずれにくい状態を保っています。

このタイトルでは、プレイ感の調整とチーム開発の両方を成立させるために、ゲームロジック側の処理負荷とエンジン側の使いやすさを同時に詰めました。特に衝突判定、設定反映、描画パス分離の3点は、手触りと開発速度の両方で実際に差が出ています。

1. Spatial Hash Grid による衝突候補の絞り込み

SpatialHashGrid.h では、3D空間を cellSize 単位のグリッドに分け、std::unordered_map<int64_t, std::vector<Entity>> にエンティティを登録しています。全組み合わせを毎フレーム調べるのではなく、近傍セルだけを見る形にしたことで、ギミックや弾が増えても処理量が急に跳ねにくくなりました。

この構成にしておくと、部屋ごとの密度が高いステージでもロジック側の負荷を読みやすく、レベルデザインの自由度を下げずに済みます。

2. ビルダーAPIと Config Manager による調整の回しやすさ

12人規模の開発では、基盤の都合でゲームロジック実装が止まる状態を避けたかったので、エンティティ生成はビルダーAPIで統一し、設定値は ConfigManager.cpp でTOMLからホットリロードできます。

// クライアント（プランナー・プログラマ）が直感的にエンティティを構築できるAPI
auto player = world.Create()
    .With<Transform>(Vector3(0, 5, 0))
    .With<MeshRenderer>(ModelCache::Get("Player.gltf"))
    .With<Collider>(BoundingSphere(1.0f))
    .With<PlayerController>()
    .Build();

保存監視には fs::last_write_time を使い、移動速度や演出パラメータを再起動なしで反映できます。本番時は --bake で config.bin にまとめることで、運用時は読み込み負荷を抑え、開発時は調整を速く回せる構成にしました。

3. 役割ごとに分けた描画パス

描画は単一の関数にまとめず、ECSのSystemとしてパス単位に分離しています。描画順と責務を分けておくことで、演出追加の影響範囲を追いやすくし、デバッグの見通しも上がりました。

• ShadowRenderSystem: シャドウマップ生成を独立させ、ライティング調整時に影響範囲を切り分けやすくしました。
• EmissiveRenderSystem: Emissive を持つエンティティだけを集めてブルーム用ソースを作り、発光表現を通常描画から分離しています。
• PostProcessSystem: 被ダメージ時の色収差や画面揺れなど、画面全体にかかる演出を最後段へ集約しました。

このプロジェクトでは、後続のゲーム基盤で採用するデータ構造を判断するために、更新効率と安全性を分けて検証しました。焦点を置いたのは、反復処理の速さを左右するメモリレイアウトと、エンティティ再利用時も整合性を保てるID管理です。

1. AoSからSoAへ切り替えた反復処理の検証

従来のAoSでは、更新に不要なデータまで一緒に読み込むため、コンポーネント数が増えるほどキャッシュ効率が落ちやすくなります。そこでEnTTの view を使い、必要なコンポーネントだけを連続アクセスする形に切り替えて、反復処理の特性を確認しました。

// EnTTによるSoAアプローチのイテレーション
auto view = registry.view<const Transform, const Velocity>();
view.each([&](const auto entity, const auto& transform, const auto& velocity) {
    // 必要なデータだけがメモリ上で連続しているため、
    // CPUキャッシュに乗りやすく、反復処理の効率が安定する
    UpdatePosition(transform, velocity);
});

この検証により、更新系システムではデータ配置がそのまま処理時間に効くことを確認できました。後続の自作ECSで、どのコンポーネントを連続配置すべきか判断する材料になっています。

2. Generational ID による参照の安全性確保

生成と破棄が頻繁なエンティティでは、古い参照が残ると不具合の追跡が難しくなります。なので、単純な数値IDではなく世代情報を含む Generational ID を使い、再利用されたスロットへの古いアクセスを弾けます。

3. 描画側で確認した転送コストの扱い

描画ではHLSL 5.0での法線マップ計算やライティングに加え、定数バッファ更新時の Map/Unmap の使い方も整理しました。CPU側の更新頻度とGPU転送量のバランスを見ながら、どこで更新をまとめるべきかを確認しています。

• オブジェクトごとの行列データはできるだけまとめ、転送単位を必要最小限に抑えました。
• ImGui による統計表示を併設し、描画とロジックの各フェーズでどこに時間がかかっているかを確認できます。