Ver0.1→0.2で変える要素 - RDGC - Ruby(Random) Dungeon Game Core Wiki - RDGC - Ruby(Random) Dungeon Ga...

以下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の生成パラメータに対応可能になる・・・はず