設計を見直そう14、Active領域とコマンド。

前回までのトワナナさん。

地図を表す方法を検討しているところで、地図には場所が含まれるけれど、地図はゲームが進むにつれて変化したり更新したりする。
その時に地図に含まれる場所が沢山作られるのは大変そう。
ん?それなら階層構造にして重複するデータを統合しよう。
その管理の仕組みとして「Play領域(Play Chapter)」「Active領域(Active Chapter)」「Library領域」を設けてみようかな・・。

みたいな風な感じが前回まで。
あってる?

まぁ大体そんな感じで。
ゲームつくるよー。
 
 
整理から。
上であげた3つの領域はチャプターを構成する要素になるため、チャプター構造(Chapter Structure)に所属します。

チャプター構造とは。
ゲームの一定期間を区切る単位のことをチャプターと呼び、チャプターは期間内で必要な情報を全て内包する。
チャプターが内包する情報を定義したものをチャプター構造と呼ぶ。
チャプター構造内にはLibrary領域、Active領域、Play領域の3つの領域がある。

チャプター構造のLibrary領域とは。
ライブラリやルール・シート内に定義される要素のデータをエンジン実行時に利用可能にするための領域。
主なデータとして「地図」「場所」「アクション」「イベント」が格納される。
この領域に格納されるのは「地図」「場所」「アクション」「イベント」のオリジナルの情報。
エンジン実行時にはチャプターに必要な情報がLibrary領域へロードされる。

チャプター構造のActive領域とは。
プレイ・メモリ内に配置される。
チャプター内で利用する「地図」「場所」「アクション」「イベント」のコピー情報。
チャプターが更新されたタイミング(初期化)で入れ替えを行う。
各データにはカテゴリ毎にインデックス用の番号が割り振られる。

チャプター構造のPlay領域とは。
プレイ・メモリ内に配置される。
同チャプター期間の間はセーブ・データに保存され、更新が可能な情報として扱われる。
Play地図、Playアクション、Playイベント・ハンドラの情報を持つ。
Play地図はActive領域の「地図」へのインデックスを指定する形で「地図」間のつながりを定義する。
「地図」情報のコピーや実体は持たずにインデックスによる関係図のみで構成される。
PlayアクションにはActive領域の「アクション」へのインデックスを指定する形で現在選択可能な「アクション」を定義する。
Playイベント・ハンドラにはActive領域の「イベント・ハンドラ」へのインデックスを指定する形でチャプターで利用する「イベント・ハンドラ」を定義する。
「イベント・ハンドラ」がPlayイベント・ハンドラという動的な領域に定義されるのは、エンジン実行中に(つまりイベント・ハンドラ自身によって)「イベント・ハンドラ」の切り替えを可能にするため。

まとめると、
Library領域とはデータの原版を置いておく場所。
Active領域とは今使うデータのコピーを置いておく場所。
Play領域とは今利用できる地図、アクション、イベント・ハンドラを置いておく場所。

んー。
Active領域もLibrary領域へのインデックスにできたりするかな。
1つのデータを表現するのに1つのデータのインデックスで完結しない(場所や施設など)情報が多いので、どこかで結合状態になっていた方がよい気もしたり。
一部のデータは更新されるので動的領域扱いで考えてはいるのですが、その部分だけをPlay領域に移動するのがよいのかな。

ううむ。
 
 
Active領域がなぜ必要なのかの説明もしないとですね。
順番が後ろにまわってしまいましたが、まずイベント・ハンドラの定義のお話を先に。

イベント・ハンドラとは。
チャプター内の条件や更新内容をコマンドで定義する仕組み。
エンジン実行時に決められたタイミングで実行され、情報を更新する手続き。
イベント・ハンドラは以下の5種類。
・提案アクション用のイベント・ハンドラ
・共通アクション用のイベント・ハンドラ
・戦闘アクション用のイベント・ハンドラ
・チャプター初期化イベント・ハンドラ
・チャプター更新イベント・ハンドラ

コマンドとは。
条件を指定して情報を更新する仕組み。
「対象」が「条件を満たした」ら「実行する」という3つの要素の組み合わせで記述する。
「対象」に含まれるのは「イベント(フラグ・レベル)」や「日時時刻」や「ステータス」など。
「条件を満たしたら」には一致や不等号などを用いて比較対象として数値を設定する。
「実行する」には「場所」「イベント(フラグ・レベル)」の情報を更新するなどの更新内容を設定する。
例えば〇〇という「イベント・フラグ」が120と一致したら「場所」を△△に切り替えるといった内容をコマンドと呼ぶ。

ここまでの説明でやっとこActive領域が必要になった理由のお話。
イベント・ハンドラはコマンドを使って情報を更新します。

上で書いているコマンドの構成。
「対象」が「条件を満たした」ら「実行する」という3つの要素。
3つの要素がチャプター構成内の情報を指す場合、インデックスを使い指定できるようにするため、Active領域を経由する形にしています。

表現を変えると、
ライブラリやルール・シートのどこかに定義されていたLibrary領域にある「ほにゃほにゃ」ではなく。
Active領域のアクションの1、Active領域のイベント・ハンドラの2、といった指定の仕方ができるようにしたよという意味です。
こうすることで、中身が入れ替わっていても同じコマンドで実行ができたり、中身が何であるかの確認をする必要がなくなります。
勿論、あらかじめ中身を入れておく必要がありますが(Active領域をセットアップするという意味)それはチャプター構成という手順化をすることで漏れを防げないかなと考えました。

えーっと、アセンブラ的に表現してよければレジストリ的な概念?と言えるのかも。
レジストリは中身を自由に入れ替えることが出来るのだけれど、レジストリの数は決まっていて、動作はレジストリへの指定になり、命令の数が少なくて済むみたいなイメージ。

むーむむ。それよりもええと。
例えば絵を描く時に道具として筆を使います。
で、色はパレットから自由にもってこれるけれど、筆は1つだから、どのように線を引くか、であったり、塗るか、であったりは「筆」という1つの対象に限定できるので「何を」「どうする」の「何を」の部分は常に同じ。
つまり省略できる。
すると、動作を指定する場合に「どうする」だけを伝えればよくなって、1つの情報だけで何をすればいかが指定できるようになる。

あれ?
余計わかり難いかな。
うーん。

あ、ゲーム機のコントローラーみたいな感じというと分かり易いかも。
ボタンやキーに割り当てる内容って、ゲーム毎に自由じゃないですか。
だけどボタンやキーの数は決まっていて、ボタンやキーの使い方も決まっている。
だから、プレイヤーが覚えなければいけないのはボタンやキーに割り当てられている内容だけでよいよねって仕組み。
これなら、ちょっとだけイメージし易いかな。

うん。
そんな感じ。
 
 
んー。

コマンドはちょっとわかり難いですよね。
唐突だし。
もうちょっと掘り下げないとダメな感じ。

できるだけコマンドみたいなものは作りたくなかったのですが、条件分岐の仕組みを作らないと自由な部分が持てないかなって。
作りたい「それ」は形にならないのではないかなって。
できるだけ難しくない形で実現する設計のコマンドにできたらいいなって。

この流れだと、次回はコマンドまわりの整理かもだね。
色々とっちらかってきたので他の整理もしながら。
 
 
そいえば最近「電力が足りないから順番で電気没収ね」みたいな話題を聞かなくなったけれど、エアコンとかごーごーって使って平気なのかなーって。
そんなことをぼやんと心配する日々。
まずは生き延びて、そこから色々後回しにしたことを心配する順番でよいのかもです。
ごーごーしちゃっていいみたいだよ(小声。

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

おさしみなさい。