ゲームのフラグ管理を考える　その２

前回

https://pepophilia.com/2021/09/25/%e3%82%b2%e3%83%bc%e3%83%a0%e3%81%ae%e3%83%95%e3%83%a9%e3%82%b0%e7%ae%a1%e7%90%86%e3%82%92%e8%80%83%e3%81%88%e3%82%8b/

前回はシングルトンでグローバルなDictionaryフラグ管理クラスを作った。

グローバルフラグ管理
└┬ 始まりの塔に到着 true
　├ 鍵Aを取得 true
　├ 扉Aを開けた false
　├ ボス城に到着 false
　└ ボスを倒した false

小さなゲームを作る場合は手っ取り早く作れて便利かもしれないが、規模が大きくなってくると大変そう

例：

グローバルフラグ管理
└┬ 始まりの塔に到着 true
　├ 鍵Aを取得 true
　├ 扉Aを開けた false
　├ 第2の塔に到着 false
　├ 鍵Bを取得 false
　├ 扉Bを開けた false
　├ 第3の塔に到着 false
　├ 鍵Cを取得 false
　├ 扉Cを開けた false
　├ 第4の塔に到着 false
　├ 鍵Dを取得 false
　├ 扉Dを開けた false
　├ 第5の塔に到着 false
　├ 鍵Eを取得 false
　├ 扉Eを開けた false
...
　├ ボス城に到着 false
　└ ボスを倒した false

こうなると1つのクラスでの管理が非常に大変になってきそうなので、
グローバルフラグ管理クラスを物語の大まかなシナリオの記録に使い、
新たにサブフラグ管理クラスを作って特定のダンジョンやクエストのフラグ管理をするといい感じ？

例：

グローバルフラグ管理クラス
・現在のシナリオ
└ 第1の塔
・シナリオフラグ
└┬ 始まりの塔 true
　├ 第1の塔 true
　├ 第2の塔 false
　├ 第3の塔 false
　├ 第4の塔 false
　├ ボス城 false
　└ ボスを倒した false
・クエストフラグ
└┬ 任意クエストAを受注 true
　└ 任意クエストBを受注 false

始まりの塔のサブフラグ管理クラス
└┬ 始まりの塔に到着 true
　├ 鍵Aを取得 true
　└ 扉Aを開けた true

第1の塔のサブフラグ管理クラス
└┬ 第1の塔に到着 true
　├ 鍵Bを取得 true
　└ 扉Bを開けた false

任意クエストAのサブフラグ管理クラス
└┬ クエスト受注 true
　├ 村人を助けた true
　└ 報酬を受け取った false

・・・

グローバルフラグ管理クラスのフラグの肥大化を抑えられるし、
物語の進行に合わせて処理を分岐させる際に
グローバルフラグ管理クラスの現在のシナリオ変数の値を使うとシンプルに制御できそう。