相互変換モジュール 色んなことが便利になる
過去ブログの転載です。
repeatを用いて、何か試しに作ってみましょう。
↑このような、変数1番が0のときピクチャー1番「0」を表示する命令を作りました。変数1番が1のときは「1」、変数2番が2のときは「2」、と表示されるような、いわゆる数値を画面上に表示させたい場合、このイベント命令をあと9個作らなければなりません。9個ぐらいなら簡単にできそうですが、これが100個とかになると悶絶しますよねぇ。
ということで、9個を一気に作成するために相互変換を使ってみましょう。↑このイベント命令をコピーし、receiveします。
co 1, 1, 0, 0, 0
pic 1, "0", 0, 160, 120, 0, 100, 1, 0, , 100, 100, 100, 100, 0, 5
coend
このように出てきます。coが条件分岐、picがピクチャー表示、coendが分岐終了です。なんでcoかというと、ifはHSPの標準命令ですので、conditionのcoです。ヘルプを読んで、どこが「変数1番が0のとき」の「0」に相当するのか探しましょう。
coの命令はちょっと複雑です。ちょっとずつ解釈していきましょう。いま co 1, 1, 0, 0, 0 となっていました。
まず、p1の値が1ですから、「1:変数」が選ばれます。
次に、p2の値が1ですから、「基準とする変数の番号」=1ということになります。つまり、変数1番ということですね。
次に、p3の値が0ですから、「変数と比べる値」は「0:定数と比較」となります。
次に、p4の値が0なので、変数1番と0の値と比較していることになります。つまり、p4の「0」が、「変数1番が0のとき」の「0」に相当します。(p5の「0」は「と同値」という意味ですね)
よって、この「0」が0~9まで変動するようにしましょう。このように探すのが面倒であれば、あらかじめ「0」に相当する値を例えば「999999」とかいう分かりやすい値にしておいてreceiveするというのも手です。
次に、ピクチャーの「0」と表示される部分を探します。これはファイル名「0」という所ですから、文字列として引用符が付けられている「"0"」がそうですよね。ここが「"0"」~「"9"」まで変動すれば良いわけです。
10回繰り返したいので、repeat 10を使います。
repeat 10
co 1, 1, 0, cnt, 0
pic 1, ""+cnt, 0, 160, 120, 0, 100, 1, 0, , 100, 100, 100, 100, 0, 5
coend
loop
↑変わったのは、repeat 10 から loop までで囲んだことと、coの0(p4)がcntに、picの"0"("filename")が ""+cnt になったことです。cntは初め0で、repeatで繰り返されるたびに1ずつ増えるというものでした。ですから、10回繰り返すので、cntは0~9まで変動することになります。よって、p4はcntとすればOKです。
次に、ファイル名は文字列ですから、cntとだけ入れてしまうと数値と見なされてしまいます。そのため、初めの文字列を""とすることで、これは文字列として見なされるわけです。
これでsendしてみましょう。
↑ほ~~ら、ちゃんと10個出てきましたね。こういう風な使い方が出来るわけです。
このように、基本的にはHSP側で一からプログラミングするのではなくて、既存のイベント命令をHSPに起こして、ちょっと改変してイベント命令に変換しなおしてやる、という使い方が有用です。慣れてくれば色んなことが手早く出来て、自分で作っておきながら言うのもアレですけど大変便利じゃないでしょうか。
また、次のような使い方も出来ます。
アクションゲームの基礎の所で「炎」と「ビーム」をランダムに攻撃する敵を作りましたが、そのとき作成したイベント命令は実に煩雑でした。
炎の部分とビームの部分をくっつけているので長々としたイベント命令になっていたわけですが、これを分かりやすく管理するということも、相互変換によって実現できます。
まずこの長いのをreceiveし、HSP構文にしておきます。次に、どこでどういうことをするのか、というのを把握しておいて、それぞれで分けることを考えます。構文では分かりづらいという場合は、変換前に「注釈」か何か入れておくと良いでしょう。「注釈」は「rem」になります。
そして、「炎」の部分と「ビーム」の部分を切り離してみます。このように記述することができます。
goto *@f
#deffunc 攻撃「炎」
varsel 141 : var 0, 6, 2, 1
varsel 142 : var 0, 6, 2, 2
varsel 145 : var 0, 6, 2, 3
co 1, 145, 0, 2, 0
varsel 142 : var 1, 0, 1, 0
coend
co 1, 145, 0, 4, 0
varsel 141 : var 2, 0, 1, 0
coend
co 1, 145, 0, 6, 0
varsel 141 : var 1, 0, 1, 0
coend
co 1, 145, 0, 8, 0
varsel 142 : var 2, 0, 1, 0
coend
varsel 143 : var 0, 1, 141, 0
varsel 144 : var 0, 1, 142, 0
locate_event 4, 1, 141, 142, 0
swi 21, , 1
return#deffunc 攻撃「ビーム」
swi 9, , 1
se "アップ", 100, 50, 50
char_flash 2, 31, 31, 31, 31, 10, 1
varsel 18 : var 0, 6, 2, 1
varsel 19 : var 0, 6, 2, 2
varsel 20 : var 0, 6, 2, 3
varsel 146 : var 0, 0, 20, 0
co 1, 20, 0, 2, 0
anime 1, 2, 0, 0
coend
co 1, 20, 0, 4, 0
anime 2, 2, 0, 0
coend
co 1, 20, 0, 6, 0
anime 3, 2, 0, 0
coend
co 1, 20, 0, 8, 0
anime 4, 2, 0, 0
coend
cy
co 1, 20, 0, 2, 0
varsel 19 : var 1, 0, 1, 0
coend
co 1, 20, 0, 4, 0
varsel 18 : var 2, 0, 1, 0
coend
co 1, 20, 0, 6, 0
varsel 18 : var 1, 0, 1, 0
coend
co 1, 20, 0, 8, 0
varsel 19 : var 2, 0, 1, 0
coend
get_terrain 17, 1, 18, 19
co 1, 17, 0, 1, 5
cybreak
coend
locate_save 147, 147, 148
co 1, 18, 1, 147, 0
co 1, 19, 1, 148, 0
se "しびれ2", 100, 100, 50
char_flash 10001, 31, 0, 0, 31, 5, 0
temp = {"
ジャンプ開始
180度方向転換
一歩前進
ジャンプ終了
"}
move 10001, temp, 8, 0, 0
char_hp -1, 0, -1, 0, 5, 1
cybreak
coend
coend
varsel 146 : var 2, 0, 1, 0
co 1, 146, 0, 0, 2
cybreak
coend
cyend
swi 9, , 0
return
*@// 本体はここから
pause 20
co 1, 22, 0, 999999, 5
varsel 149 : var 0, 3, 0, 1
co 1, 149, 0, 0, 0
攻撃「炎」
coend
co 1, 149, 0, 1, 0
攻撃「ビーム」
coend
coend// ここまで
↑「炎」の部分と「ビーム」の部分をこうやって分けて管理することが可能です。コモンイベントにまとめるよりもやりやすいではありませんか。
「goto *@f」は、「直後の*@まで飛ぶ」という命令です。間にある「#deffunc」は命令の定義をするもので、#deffunc 攻撃「炎」とすれば『攻撃「炎」』という命令を定義します。
内容は炎の攻撃をする際のイベント命令をコピーしてきただけのもので、最後に「return」を付けて定義完了しました。
その次にあるのは『攻撃「ビーム」』の定義です。同様に、ビームの部分だけを入れました。
そうしてしまえば、実際扱うことになるのは「// 本体はここから」以降の部分だけであり、それだけ見ると非常に簡潔なイベント命令になります。
『攻撃「炎」』や『攻撃「ビーム」』の部分でそれぞれの定義の内容が展開されます。HSPでは、日本語の命令や関数が定義できてしまうのです。もちろん変数の名前にも日本語が使えます。日本語は使いやすいか使いづらいか……人によりそうですね。
↑このように書いてsendすれば、当然もとのイベント命令が出てきます。これによって、イベント命令の管理がやりやすくなります。
HSPのこの構文をどこかに保存しておき、どこのイベントのどういう命令かをメモに残しておけば、いつでも呼び出すことができます。編集はHSPで行い、ツクールに貼り付ける、ということができます。
実際、これをやりたくて相互変換を作ったのが一番の理由です。複雑なごちゃごちゃの処理を簡潔にまとめられるので、管理がしやすいんですよね。