近年のライブ型オープンワールドRPG（例：原神）では、

ストーリーは基本ソロ進行
宝箱や探索は個別管理
マルチでは世界が部分同期

という設計が一般的です。

しかし構造を分解すると、

技術的に同期が難しいのではなく
「永続状態を持ちすぎている」ことが問題

本記事では、

体験を損なわず、開発コストを抑えた同期フラグシステムの最小構成テンプレ

を提示します。

設計原則

原則1：世界は1本線にする

int story_progress_id;

永続分岐を持たない

NPCの生死フラグを持たない

世界状態はprogressから導出

bool isNpcVisible(int progress_id) {
    return progress_id >= 3020;
}

保存しない。導出する。

原則2：宝箱は「点」でなく「面」で持つ

❌ NG（フラグ爆発）

bool chest_100234_opened;
bool chest_100235_opened;

✅ 推奨（エリア単位ビットマスク）

struct RegionChestData {
    uint64_t bitmask[2]; // 128個まで
};

エリア単位管理
ONのみ（OFFに戻さない）
データサイズ固定

原則3：存在と取得を分離せよ（重要）

宝箱同期で最も多いバグ：

マルチ後に宝箱が復活する問題

原因は
「存在」と「取得」を同一視していること。

🔹 宝箱の存在（セッション依存）

if (host_region_bitmask[target_bit] == 0)
    spawn_chest();

→ ホスト基準

🔹 宝箱の取得（プレイヤー依存）

if (player_region_bitmask[target_bit] == 0)
    allow_loot();
else
    disable_loot();

→ 個人基準

なぜ復活しないのか？

ビットはONのみ
OFFに戻らない
永続データはプレイヤー単位

セッション終了後は
自分のbitmaskから世界を再構築するだけ。

クラス設計（最小構成）

永続層（保存対象）

story_progress_id
region_bitmask[]
boss_kill_time[]

以上のみ。

セッション層（揮発）

SessionWorld
visible_objects

セッションシーケンス

1. 参加

PlayerA → Server : Join
Server   : buildFrom(host.progress)

2. 宝箱インタラクト

PlayerA → Server : ChestInteract(region, bit)

Server:
    if A.bitmask == 0:
        giveReward()
        setBit(A)

セッション世界は変更しない。

3.セッション終了

PlayerA:
    world = rebuildFrom(A.PlayerWorldData)

宝箱は復活しない。

「参加者未取得宝箱」問題

ケース：

ホスト：開封済み
参加者：未取得

解決策は3パターン。

A：取得不可（低コスト）

仕様：
ホストが開封済みなら不可。

B：個別可視（推奨）

if (player.bitmask == 0)
    showChestToPlayerOnly();

未取得者にだけ表示
UX自然
永続増加なし

C：完全個別インスタンス（高コスト）

MMO型。今回は不要。

ワールドボス管理

撃破フラグを持たない。

int64_t boss_last_kill_time;

if (now - boss_last_kill_time > respawn_time)
    spawn();

データ肥大対策

NPC状態は保存しない
ワールドはprogressから導出
宝箱はビット圧縮
ボスはタイムスタンプ

保存は最小限。

セーブ改竄対策（最低限）

bitmaskはサーバー保持
報酬判定は必ずサーバー側
クライアントは参照のみ

この設計のメリット

✔ 管理フラグの増殖を防ぐ
✔ QAコストを抑えられる
✔ ライブ拡張に強い
✔ データサイズが固定化できる

適用可能なゲーム

✔ 直線型ライブRPG
✔ 分岐が少ない探索型
✔ ホスト制マルチ

✖ 分岐型ADV
✖ 大規模MMO

結論

同期が難しいのではない。

永続状態を持ちすぎていることが問題。

保存は最小限に。
あとは導出する。

それだけで
原神型ライブRPGの同期はテンプレ化できる。