設計を見直そう9、プレイ・メモリが必要になったわけ。

前回の設計の見直しでは、データの置き場所に関してまとめました。
今回はその中のプレイ・メモリに関してまとめ。

前回は簡単に流してしまいましたが、何故3つのデータ置き場が必要なのかのお話も含めて整理しながら進めます。

データの置き場は3つ。
1つ目は固定の共通データを置いておく「ライブラリ」領域。
2つ目は固定のゲーム専用のデータを置いておく「ルール・シート」領域。
3つ目は変化するデータを置いておく「プレイ・メモリ」領域。

「ライブラリ」と「ルール・シート」のみでも何となくボヤかして設計を進められるのですが、アクションの実行と、セーブまわりの定義をしようとすると途端に難解なお話になります。
「プレイ・メモリ」が存在すると何故、お話が難解にならないのかというと、複数の場所にある情報をまとめて今使う形にしておけることと、複数の手続き中の過程を残しておけるからです。

複数の場所にある情報というのは、例えば「場所」には複数の情報が含まれます。
「環境」であったり、「ひと」であったり、「施設」であったり、「風向」といった情報が含まれますが、その基本となる情報が保存されている場所はそれぞれ異なります。
「ライブラリ」から持ってくるのか、あるいは「ルール・シート」から持ってくるのかであったり、「施設」に含まれる「サービス」の情報も同じように「サービス」の情報が格納されている場所から持ってくる必要があります。

それぞれを必要な時に全てかき集めてくるようなことをするよりは、アクションを実行する前に入れ物を用意しておいて、あらかじめ詰め込んでおくルールにしようという考えです。
合わせてその入れ物が値を保持する必要があるのであれば、記録できるようにセーブ・データに移動できるようにしておこうという考えです。

出力シートの生成時に「プレイ・メモリ」を含めた流れを簡単に書いてみます。

1. 入力シートをゲームに入力
2.「ルール・シート」からルールを読み込み
3. ゲームは入力シートからセーブ・データをパースして[日付時刻]、[場所]、[キャラクタ]に関する情報を取得
4. ゲームは入力シートからアクション項目をパースして、[アクション]に関する情報を取得
5. ゲームは「ライブラリ」と「ルール・シート」を用いて「プレイ・メモリ」に[場所]を作成
6. ゲームは「ライブラリ」と「ルール・シート」を用いて「プレイ・メモリ」に[キャラクタ]を作成
7. ゲームはアクションを実行し、「プレイ・メモリ」の[場所]、[キャラクタ]の情報を更新
8. ゲームはアクションの内容と、「プレイ・メモリ」の[場所]、[キャラクタ]の値の変化からアクションの結果のソースを作成
9. ゲームはイベント・ハンドラを実行し、「プレイ・メモリ」の[場所]、[キャラクタ]の情報を更新
10. ゲームはイベント・ハンドラの結果と、「プレイ・メモリ」の[場所]、[キャラクタ]の値の変化から次回用の共通・提案アクションを作成
11. ゲームはアクションの結果のソースと、次回用の共通・提案アクションを使い出力シートを作成
12. ゲームは「プレイ・メモリ」の[場所]、[キャラクタ]情報をセーブ・データに変換し、出力シートに追記
13. ゲームは出力シートをテキスト・ファイルとして出力

この例では「プレイ・メモリ」には[場所]と[キャラクタ]の情報が作られ、アクションの実行時とイベント・ハンドラの実行時と合わせて2回値が更新されます。
「プレイ・メモリ」の値の状態は、「アクション前」「アクション後」「イベント・ハンドラ後」の3つの状態を持つことになります。
ゲームでは、「プレイ・メモリ」の値の他に、アクション内容とイベント・ハンドラの内容を合わせ、その時に起きたことが分かる仕組みです。

ただ、ここで書いた「起きたことが分かる」のはあくまでゲーム実行中(出力シート生成中)にプログラム上での数値のお話ですのでプレイヤーには何が起こったのかがわかりません。
そこで、プレイヤーに「起きたことが分かる」よう、出力シートには文章という形で出来事が描かれる仕組みです。

このへんはアクションとイベント・ハンドラの仕様が決まって、基礎エンジンの見通しが立った後に。
文章ジェネレータ側をチューニングできればいい感じにならないかなぁ・・とか考えているので今は横に転がしています。
ごろごろ。

 
 
たぶんネ!

がんばる。