Fork
edit以下RDGC Ver0.2に向けてのメモ書きです
* GameMasterクラスとDungeonクラスとBoardクラスの関係の整理
* Boardを実質Dungeonに変更し、ActorやTimerの管理をGameMasterが行う
* Visibleの情報もGameMasterが持つかは考慮が必要
* Dungeon（旧Board）が管理した方が楽だけど、意味からするとGameMasterの気も・・・
* Timerクラスの管理手法変更
* DungeonクラスでのTimer管理を引き上げてGameMasterに
* GameMasterが全Timerを管理
* ActorにTimerをincludeするのではなく、TimerからActorをcallbackする関係に
* 現状、ActorのターンにならないとTimerが発動しない
* これだと例えば、自分の番が来るまでBuffの効果が切れなかったりする
* よって、このままだとAGIの値が小さいほどTimerの発動・消滅が遅れることになる
* Actorと無関係にGameMasterが時間管理すれば、この問題を解決できる
* なにより、名前と管理するもののイメージが一致する
* そもそもGameMasterがTimerとActorを一つのリストで管理すればいろいろ解決？
* GameMasterクラスのプラグイン化
* 要するに、GameMasterクラスの管理する各要素について、外部クラスに委託するようにする
* その結果、外部クラスの差し替えだけで動きが変わる
* Strategyパターン化するということ
* Ver0.1でもやってはいますが・・・
* 戦闘ロジックのプラグイン化
* GameMasterが渡されたロジックにしたがって戦闘結果を管理する
* メッセージ周りの変更
* GameMasterが管理？
* いろいろ検討が必要
* 「画面が変化するとき」を1フレームの単位に
* 現状、1フレームで内部1ターン、つまり1キャラ動作する
* これだと、敵の数が増えるとどんどんプレイヤーの処理が遅れる
* そこで、画面に描画する情報が変化するまで、どんどんターンを進める仕組みに変える
* プレイヤーの見ている範囲で敵が動く
* パラメータに変化がある
* 不可視エリアで敵が動いてもスルーする
* そう考えると、不可視エリア情報はGameMasterが保持すべき？
* ただし、これでも「画面内に敵がたくさん」という状況（例：MH）での処理遅れはどうしようもない
* ただ、「フロアに敵が多い」よりは「画面に敵が多い」の方がユーザが納得しやすい
* MAP分割/Room生成ロジックを変更
* 現状は再帰的に奥まで行って、戻ってきてまた進むのを繰り返している
* これをQueueみたいな感じに変更する
* Queueから分割/生成対象を取り出し、処理をして、MAXに達したら終了
* これでMAPの生成パラメータに対応可能になる・・・はず