ゲームロジック・設計

このプロジェクトでは、1週間の開発期間で9人が並行して作業する前提だったため、状態管理の整理と負荷の読める実装が重要でした。ゲーム全体の流れは GameManager に集め、探索の緊張感に関わる視界判定はGCが出にくい形で組み立てています。

1. State Machine による進行管理の一本化

タイトル、探索、ショップ、イベントなどの状態遷移を各画面に散らさず、GameManager のFSMに一本化しました。責務を1か所にまとめたことで、担当者ごとの実装境界が明確になり、短期開発でも統合時の衝突を抑えやすくしています。

// GameManagerにおけるステート管理の簡略例
public void TransitionTo(GameState newState) {
    currentState?.Exit();
    currentState = newState;
    currentState?.Enter();
    // 状態変更をEventBus等でブロードキャストし、UI等が反応する
    OnGameStateChanged?.Invoke(newState.Type);
}

この形にしておくと、ショップUI、敵ギミック、セーブ処理といった別担当の機能が、状態遷移の契約だけを共有して独立に進められます。開発終盤に全体をまとめる際も、どこでゲームフローが変わるのかを追えるようになりました。

2. 動的ライティングと NonAlloc Raycast の組み合わせ

探索中の「見える範囲」をゲーム性に使うため、光量の扱いと視界判定をロジック側から参照できる構成にしました。視界確認では毎フレーム複数回のレイキャストが発生するため、割り当てによるGCを避ける目的で Physics.RaycastNonAlloc を使っています。

// ゼロ・アロケーションな視界判定
int hitCount = Physics.RaycastNonAlloc(lightSource, direction, results, maxDistance, layerMask);
for (int i = 0; i < hitCount; i++) {
    if (results[i].collider.CompareTag("Player")) {
        // 光源内にプレイヤーがいる場合の処理
    }
}

この実装により、暗闇と光源の境界で判定が頻発する場面でもフレーム落ちしにくくなり、プレイヤーにとって重要な「見えるか、見えないか」のルールを安定して扱えるようになりました。

短期開発のゲームでも、ロジックと演出が密結合になると調整がすぐに崩れます。そこで、責務は名前空間とイベントで分けたうえで、手触りに関わる演出だけは時間の流れを分離して扱える構成にしました。

1. ヒットストップ中も止めない演出更新

ゲーム全体を一瞬止めるヒットストップは気持ちよさに効く一方で、通常の deltaTime に依存した演出まで止まると見た目が不自然になります。そこで、カメラシェイクなどの演出は Time.unscaledDeltaTime を基準に動かし、ゲーム進行とは別の時間軸で動いています。

// 物理時間が止まっても動き続けるシェイク演出
public IEnumerator ShakeCameraRealtime(float duration, float magnitude) {
    float elapsed = 0f;
    while (elapsed < duration) {
        // Time.unscaledDeltaTime を使うことで Time.timeScale=0 の影響を受けない
        Vector3 offset = Random.insideUnitSphere * magnitude;
        cameraTransform.localPosition = originalPos + offset;
        elapsed += Time.unscaledDeltaTime;
        yield return null; // WaitForSecondsRealtimeの代わりにより細かく制御
    }
    cameraTransform.localPosition = originalPos;
}

この分離によって、プレイヤー操作は止めつつ、画面揺れやポストエフェクトは最後まで再生できます。演出の追加や調整を行っても、物理挙動に影響を出しにくい点も実装上の利点でした。

2. イベント駆動と名前空間による依存整理

Core、Player、Level、UI、Visuals の名前空間を分け、通知はEventBus経由にしています。MonoBehaviour同士の直接参照を減らすことで、短期間でも追加機能を後から差し込みやすくしました。

• UIや演出の追加がしやすい: クリア判定などのロジック側はイベントを送るだけにして、見た目の反応は Visuals 側で受けています。
• 終盤の統合がしやすい: 依存の方向をそろえておくことで、ジャム終盤の追加実装でも競合箇所が絞れました。

factoria では、生産、在庫、市場、UIが同時に状態を変えるため、処理の順序と責務を崩さないことを重視しました。そこで、状態変化の通知は EventBus に集め、表示用の統計値はシミュレーション側で別管理しています。

1. EventBus を使った層間の疎結合化

生産完了、在庫更新、市場変動といった出来事は、ドメイン層から直接UIを触らずにイベントとして公開しています。GameBootstrap.cs で依存関係を組み立て、Unity依存の処理は Presentation 側だけが受け持ちます。

// Domain層: 純粋なビジネスロジック。Unity(MonoBehaviour)に依存しない
public class ProductionFacility {
    public void Produce() {
        if (inventory.HasSufficientResources()) {
            inventory.Consume();
            var product = CreateProduct();
            // 状態変化をEventBusでブロードキャスト
            EventBus.Publish(new ProductManufacturedEvent(product));
        }
    }
}

// Presentation層: イベントを購読し、UIや3Dモデルの演出のみを担当
EventBus.Subscribe<ProductManufacturedEvent>(e => {
    // 煙パーティクルの再生やUIの更新
    visualizer.PlaySmokeEffect();
});

この構成により、ロジックの検証と見た目の調整を分けて進められます。施設数が増えたときも、どのイベントがどの層へ流れているかを追えます。シミュレーションの整合性も崩れにくくなりました。

2. 指数移動平均 (EMA) によるKPIの平滑化

KPI表示は瞬間値のままだと変動が激しく、プレイヤーが傾向を読み取りにくくなります。そこで、スループットや品質の表示には EMA を使い、短期的な揺れを残しつつ全体傾向が見える形にしました。

// Time.deltaTime に依存しない滑らかなトレンド分析
public void UpdateStatistics(float currentValue, float deltaTime) {
    // アルファ値（減衰係数）をフレームレート変動に強くする
    float alpha = 1f - Mathf.Exp(-smoothingFactor * deltaTime);
    currentEMA = (currentValue * alpha) + (currentEMA * (1f - alpha));
}

この統計処理により、一時的な詰まりや急増に引きずられすぎず、設備投資や人員配置の効果が画面上で読みやすくなりました。シミュレーションの内部値と、プレイヤーへ見せる情報の粒度を分けたことがポイントです。