設計を見直そう15、コマンドの書式。

コマンド、コマンド・・、コ↓マン↑ドゥー!!
ん?
「こいよベネット!銃なんか捨ててかかってこい!」
いや、そっちのシワルツネガーさん風の話題は置いておいて。
コマンドのお話なのです。

前回イベント・ハンドラの中身はコマンドだよという話題が出てきました。
だいぶ前回から日が空いているけれど。
へんだな・・えーっと?
ああ、そうか。
先週は絵を描いてたんだった。うひ。

ゲームつくるよー。

さて、コマンドのお話だよね。
TRPGさん1号で値を入れておく入れ物はいくつかありますが、それらの値を操作する仕組みをまとめてコマンドと呼びます。

えーっと。
ちょっとわかり難いよね。

コマンドとは以下の内容。
・イベント・ハンドラ内に書く手続きのこと
・決められた書式に沿って書く手続き言語のこと
・コマンドには実行する内容を示す「命令」と、状態を示す「値」がある
・値には定数(固定された値)と、変数(入れ物)の2種類がある
・変数にはあらかじめ用意されるもの、追加で用意できるものの2種類がある
・追加で用意する変数には名前と用途を定義できる
・変数は中に入る値を指定して更新できる
・条件に一致した時に変数を更新する仕組みがある

並べてみると、うん。
コマンドとは値を更新する仕組み、という最初のお話であってる。

えーでも値を更新するだけでゲームがうごくのー?という疑問も出てくるよネ。
大丈夫。

うごくよー。

例えばですね。
以下のような順番でゲームが動いていた場合。

1. マップ番号の背景を表示
2. 人物番号の人物を表示
3. セリフ番号のセリフを表示
4. プレイヤーの行動を選択
5. プレイヤーの選択に沿ってマップ番号、人物番号、セリフ番号を更新
6. 手順1へ戻る

上のような処理だった場合、イベント・ハンドラは5にあたる処理を行います。
マップ番号、人物番号、セリフ番号をいくつにするの?という条件をコマンドで書くという流れです。

値のみの更新によってゲーム(であったり何か)の動作が実現できるのは、その「値の意味」が別の場所で定義されているからです。
例えば、その値が色を指していたり、音色を指していたり、文字を指していたり。

値が色を指しているのなら、それをビデオ出力に送ればディスプレイに絵が表示されます。
値が音色を指しているのなら、それをサウンド出力に送ればスピーカーから音楽が流れます。
値が文字を指しているのなら、それをキャラクタ出力に送ればディスプレイに文字が表示されます。

または、それが押されたキーボードのキー番号やマウスの移動情報なら、それはプレイヤーの操作情報になります。

値に意味を持たせて、値を変化させる条件を定義し、加工された値をいつ、どこに出力するのか決めることがプログラム。
それによって異なる結果を生み出す機械がコンピュータ。

ちょっと(だいぶ?)端折って説明していますが、プログラムの役割は値を操作すること。
なので、今回用意するコマンドも、値の操作ができるだけですがTRPGさん1号は動くのです。

何となく、伝わった・・かな?

 
コマンドの書式も考えないとですが、例えばそう・・うーんと。
手続き型でメジャーなタグ形式だとこんな感じかな。

(ラベル)
説明:
場所に名前を付けて、ジャンプなどの移動先として利用します。
いくつでも作ることが可能。
例:
<label name=”TOWN1″>
<label name=”shop1″>

(ジャンプ)
説明:
移動先としてラベルを指定することで、次の処理まで移動させる。
例:
<jp label=”shop1″>
<jp label=”TOWN”, eventLevel[1]> ※固定文字列とイベントレベルを合成した名前をラベルとして扱う

(条件一致ジャンプ)
説明:
条件が一致した際にはラベルへ移動する。
例:
<jeq label=”shop1″>eventFlag[1], 13</jeq>
<jeq label=”shop1″>eventFlag[0], eventFlag[1], eventFlag[2], 1</jeq> ※全ての値が同じであれば成立

(条件不一致ジャンプ)
説明:
条件が不一致の際にはラベルへ移動する。
例:
<jne label=”shop1″>eventFlag[1], 0</jne>

(サブルーチン・コール)
説明:
ラベルへジャンプ後、リターン・コマンドが見つかるまで処理を実行。
リターン・コマンドが見つかった段階で、ジャンプの次のコマンドへ戻ってくる。
例:
<subcall label=”shop1″>

(リターン)
説明:
サブルーチン・コールによって移動してきた場合、ジャンプ元の次のコマンドへジャンプする。
あるラベル配下に一連の処理を書き、最後にリターン・コマンドを置くことでサブルーチン・コールで呼び出せる処理としてまとめることができる。
例:
<return>

(代入)
説明:
更新可能な値を入れ替える。
例:
<store calc=”eventFlag[1], 20″>
<store calc=”eventLevel[3], 100″>
<store calc=”eventLevel[1,12], 0″> ※eventLevelの1から12までに0を入れる
<store calc=”eventLevel[], 0″> ※eventLevelの全ての要素に0を入れる

(加算)
説明:
更新可能な値に指定値を加算する。
例:
<add calc=”eventLevel[3], 100″>
<add calc=”eventLevel[1,12], 3″> ※eventLevelの1から12までに3を加算する
<add calc=”eventLevel[], 8″> ※eventLevelの全ての要素に8を加算する

(減算)
説明:
更新可能な値に指定値を減算する。
例:
<sub calc=”eventLevel[3], 100″>
<sub calc=”eventLevel[1,12], 3″> ※eventLevelの1から12までに3を減算する
<sub calc=”eventLevel[], 8″> ※eventLevelの全ての要素に8を減算する
 
 
代表的なコマンドを考えてみたけれど・・。

むむう。
ちょっと使いにくそう。

配列を扱える前提で書いてしまっているけれど、配列は数字が使えると間違いが起きやすいからあまりよくないよね。
ただゲームという性質から配列は使いたいかなって。
ベースはアセンブラで考えているけれど、BASICライクでもいいかも?
わたしはあまりBASIC詳しくないけれど、MSXあたりで触ったような気もする。

あ、PB-100がBASICだったよね?確か。
ちょっとマニュアル引っ張り出そうかな。

コマンドを書く場所はイベント・ハンドラ内に限定されるので、フリーライタブルなものよりはとっつきやすくできたらいいなって。
もうちょっとプログラム、プログラムしていた方が完結で見やすいかもだから、もう少し検討だね。

だって。
<sub calc=”eventLevel[3], 100″>
って、書くよりも。

eventLevel[3] = 100;
とかの方が見やすいよね。

ううーんでも。
使いやすさと、あとは解析のしやすさにも配慮しないと。

解析のしやすさというのは、えーっと、チェッカー関係。
ユーザーが自作したルール・シートの採点?というか自動でミスを見つけてくれる機能のこと。
この部分でユーザーの作業負担を大幅に減らしたいなって。
特にルール・シートの書き方を間違えてしまってゲームがクリアできない、回収できないフラグが残る関係は検知して「ココ直さないとダメだよ!」って警告できるようできたら。

がんばってルール・シート用意してみんなで遊んでみたのに、あれ?なんかクリアできなくない?ってなっちゃったら悲しいし。
そういったことがあったら、やっぱり気軽に遊んでって言えなくなっちゃうし。
せっかく、ぶあーって盛り上がって作ったのに、うまく動かなかったら怒られちゃう、笑われちゃうって気持ちがしぼんでしまうのは絶対ダメだよね。

なので、チェッカー関係のためにシステムをあげてサポートが必要!なのでした。
多少コマンドがカッコ悪くても。
 
 
コマンドの整備はまとめページの方で続けるとして。
これで一通り要素が揃っている気がするので、事は大分むかーしっぽく感じる「今用意している仕組みでゲームが動くのか」の検証に戻ろう。
・・戦闘パートと文章ジェネレータは引き続き置いていおいて。

安倍総理辞任で、にほんおしまいだー、もうだめだー、なご時世ですが。
海外にプレイベート口座を用意して。
「支払いはいつものスイス銀行に」みたいなオシャレ会話で乗り切ってください。

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

あと、よい週末をね。