設計を見直そう19、イベントハンドラと優先順位。

夕飯を食べ損ねてそわそわしている土曜日。うーん、この時間はアウト。
だだん!朝までのサバイバルが始まった!!

はふん。

というわけで設計の見直し19回目。
これ、100回行ったりしないよね?

前回は段階的な抽象化と、項目ごとに処理をまとめることを考えて、出力シートの生成フローを項目化した。
まずは「新規スタートができる」ことの確認なのだけれど、新規スタートはアクションの実行などがすっぽり抜けているので、ロードスタートでも同じような項目分けでいけるのかを先に確認。

ゲームつくるー。
 
 
前回まとまった項目がコレ。

[新規スタート]
———-
・起動モードの判定
  ・入力ファイルの判定
・外部ファイルの読み込み
  ・ルール・シートの読み込み
  ・キャラクタ・シートの読み込み
  ・ライブラリの読み込み
・入力ソースの準備
  ・セーブ・データ作成
  ・空アクション生成
・内部データの準備
  ・プレイ・メモリの初期化
・アクションの判定
  ・なし
・ソースの生成
  ・プレイ・メモリからセーブ・データの生成
  ・現在の状況の文章の生成
  ・次回向けアクションの生成
・出力シートの生成
  ・ソースの合成
  ・ファイルの出力
———-

ロードスタートを考えてみるとこんな感じかな?
★マークの所が新規スタートとの差異。

[ロードスタート]
———-
・起動モードの判定
  ・入力ファイルの判定
・外部ファイルの読み込み
  ・ルール・シートの読み込み
  ・キャラクタ・シートの読み込み
  ・ライブラリの読み込み
・入力ソースの準備
  ・セーブ・データのパース ★
  ・空アクション生成
・内部データの準備
  ・プレイ・メモリの初期化
・アクションの判定
  ・なし
・ソースの生成
  ・プレイ・メモリからセーブ・データの生成
  ・現在の状況の文章の生成
  ・次回向けアクションの生成
・出力シートの生成
  ・ソースの合成
  ・ファイルの出力
———-

ロードスタート時は実は殆ど差が無くて。
もともとセーブ・データから出力シートを復元するためだけの機能なので、新規の時はデフォルトのデータから作るだけだったセーブ・データを外部から入力されたセーブ・データ使って組み立てる形に。

今回気にしているのはアクションの実行を伴う継続スタートのケース。
書いてみるとこんな感じかも。

[継続スタート]
———-
・起動モードの判定
  ・入力ファイルの判定
・外部ファイルの読み込み
  ・ルール・シートの読み込み
  ・キャラクタ・シートの読み込み
  ・ライブラリの読み込み
・入力ソースの準備
  ・セーブ・データのパース ★
  ・アクションのパース  ★
・内部データの準備
  ・プレイ・メモリの初期化
・アクションの判定 ★
  ・プレイヤーアクションの実行
    ・アクション系イベント・ハンドラ実行
     ・アクション系イベントの結果をプレイ・メモリに反映
  ・チャプターの更新
    ・チャプター系イベント・ハンドラ実行
    ・チャプター系イベントの結果をプレイ・メモリに反映
  ・アクション結果の文章作成
・ソースの生成
  ・プレイ・メモリからセーブ・データの生成
  ・現在の状況の文章の生成
  ・次回向けアクションの生成
・出力シートの生成
  ・ソースの合成
  ・ファイルの出力
———-

で、更に項目を分解する形でもう少し検討したのが以下の処理。
検討の材料みたいな感じの。

たぶん、優先順位と更新場所を限定しないとロジックが破綻しそう。
ルール・シートを書く時に。

[共通処理]
———-
・アクション系イベント・ハンドラ実行
  ・提案アクション用イベント・ハンドラ
  ・共通アクション用イベント・ハンドラ
  ・戦闘アクション用イベント・ハンドラ

・アクション系イベントの結果をプレイ・メモリに反映
  ・地図・場所の更新
  ・キャラクタの更新
  ・イベント情報の更新

・チャプター系イベント・ハンドラ実行
  ・チャプター更新イベント・ハンドラ
    ・日付時刻の更新
    ・チャプターの更新
      ・ゲームクリアへ移動(意味は次のチャプターと同意義)
      ・ゲームオーバーへ移動(意味は次のチャプターと同意義)
      ・次のチャプターへ移動
  ・チャプター初期化イベント・ハンドラ
    ・地図・場所の更新
      ・地図の更新
      ・場所の更新(施設・NPCなど)
      ・環境ステータスの更新(天候・視界・風向きなど)
    ・キャラクタの更新
      ・ステータスの更新
      ・アイテムの更新
    ・イベント情報の更新
      ・イベント・レベルの更新
      ・イベント・フラグの更新

・チャプター系イベントの結果をプレイ・メモリに反映
※地図・場所などアクション系と重複する更新はまとめられない?
  ・日付時刻の更新
  ・チャプターの更新
  ・地図・場所の更新
  ・キャラクタの更新
  ・イベント情報の更新

・地図・場所の更新
  ・地図の更新
  ・場所の更新(施設・NPCなど)
  ・環境ステータスの更新(天候・視界・風向きなど)
・キャラクタの更新
  ・ステータスの更新
  ・アイテムの更新
・イベント情報の更新
  ・イベント・レベルの更新
  ・イベント・フラグの更新
———-

イベント・ハンドラは大きく分けるとアクションを更新するためのイベント・ハンドラと、チャプターを更新するためのイベント・ハンドラの2種類に。

むう。
それぞれの定義はこんな感じ?

アクションを更新するというのは、
キャラクタの行動がキャラクタに反映されること。
キャラクタの行動が世界に反映されること。

チャプターを更新するというのは、
世界で起きたことがキャラクタに反映されること。

うーん。
言葉にしてみるとしっくりこないかも。

やりたいことは、アクションの更新ではキャラクタの更新「だけ」を行い、チャプターの更新では世界の更新「だけ」を行うこと。
何がいつ、どこで更新されるのかを定義したくて。

複数のキャラクタでパーティーを組んでいる時に、別のパーティーから戦闘を仕掛けられたといったケースがあったとして。
キャラクタごとに場所の移動判定を行った場合、あるキャラクタまでは戦闘を回避して、あるキャラクタからは戦闘に巻き込まれるといったプレイヤーにわかりにくいケースが生まれるような気がする。

たぶん、まず想像するのはパーティーで行動しているのだから、移動は全キャラクタ一括だよねって。
でも一括で移動する場合は何を基準にしてほかのキャラクタやパーティーのアクションと比較して早い遅いを決めるの?って。

このあたりの「プレイヤーの選んだ行動に対して納得できる結果」にならない要素はよくないと思う。

また遠回りになりそうだけれど、
アクションとチャプターの更新はルール・シートを記述する上でも避けては通れない要素なので、ちゃんとしないと。

ええと。

ちょっと違うけれど、例えばゲームオーバーとゲームクリアの判定があったとして。
判定の順番が違うと色々感触が変わってくる。

ゲームオーバーの判定が最初だと、まず死なないことに気を付けるゲームになるし。
ゲームクリアの判定が最初だと、捨て身の行動を選べるゲームになる感じ。

きっと景色が変わる気がする。
やっぱり、ロマンチストさんなら後者がいいよね。
 
 
ぷしー。
あまり煮込んで手が止まるのはダメなので、今回はこのあたりで。
コンパクトに、コンパクトに。

んー。

てくまくまやこん、てくまくまやこん、って、なんだっけ。
いや、そもそも字にしてみるとスゴい。
てくまくまやこんって、どこから出てきた言葉なんだろう。

らみぱす、らみぱすっていうのもあった気がする。
ジャパン国危険!マジ怪しげな力がだだ洩れ。

とりあえず主人公とお友達になっておけば、爆死しても生き返らせて貰えたりするとか。
あれ、なんたらフレンズとか名乗っておけばいい感じ。
いけるいける、へーきへーき。のけものでもフレンズ名乗ってる大人がいたくらいだから。

大丈夫。
内緒でよいので、はっぴーでいて下さい。

よい日曜日をね。