これはEsolang Advent Calendar 2011 3日目の記事になります。
「参加者==執筆者」ということに気付かず,大幅に遅れてすみません。
私が書くのは、MMF2というゲームオーサリングツールを使うことによって得た新しい言語パラダイムです。
「新しい言語パラダイム」とか壮大なことを言っていますが、単に私が無知なだけで、既に似たようなものやそれを上回るものが幾らでも転がっている可能性は高いです。
もし、そうならお気軽にツッコんでください。
近親相姦気味のEsolang界に新しい血を注ぎ込むことができれば幸いです。
Multimedia Fusion(MMF)2の大雑把な説明
海外製汎用ゲームツクール
イ゙ェアアアアで有名な「呪いの館」を作ったKlik&Playの後継ソフト
売り文句:プログラム不要!コードを書かずにクリックだけでゲームが作れるよ!
現実:クリックと限られた記述力のコードでガリガリ書かないと作れないよ!
MMFそのものの紹介記事やテクニック集ではないので詳細は省きます。
あくまでMMFを使うことによって得た言語パラダイムとしての側面から紹介していきます。
Esoteric Language だろ? 趣旨わかってんの?
はい。ごもっともです。
もちろんツールなので厳密には言語ではありません。
変態が変態の為に知恵を絞って作った難読言語ではなく、秀才が凡人の為にサルでも使える簡単さを目指して作られたゲーム作成ツールです。
難読化とは真逆のベクトルを向いています。
しかし、そんな制作者の想いに反して、難読言語化している部分もあります。(後述)
敢えて逆から攻める
セキュリティを知るには、クラックを学ぶべきなのと同様に
成功するためには、失敗から学ぶべきなのと同様に
難しさを知るには、簡単さとは何かを学ぶべきなのです。
究極の簡単さを目指す開発環境の紹介によって、言語にとって何が難しいのかを浮き彫りにしていきます。
嘘です。
こじつけです。
ただ、奇妙な言語であることは確かです。(言語じゃありませんが)
esoteric
1 (選ばれた少数者にだけ伝えられる)秘儀の; 奥義に達した
2 秘儀的な,秘密の; 深遠な,難解な.
用例: esoteric Buddhism 密教
(excite辞書より)
はい。必ずしも難しい必要はありませんね。
どちらかというと、隠れ家レストラン的ニュアンスなので問題有りません。きっと。
ご容赦ください。
ですが、このソフトを使うことによって私は幾つかの言語パラダイムを得ることができました。
それが題記の「衝突駆動式」「スプレッドシート型」
それと「クラス指定用タグ」「コレクションの簡易走査」です。
(※私が勝手にそう呼んでいるだけで誰にも通じません)
Esoteric Languageに手を出すような高度な変態クラスタでは、一生手に取ることはないであろう凡人向けツールMMFから得たパラダイムを凡人の視点からお届けしたいと思います。
スプレッドシート型言語とは?
サンプルとしてゲームを1本完成させてみました。
トップビュー2Dアクションで自機うさぎが弾を進行方向に発射して敵を倒すゲームです。
全部倒せばクリア。自分のHPがゼロになるかライオンに噛まれれば死亡でゲームオーバーです。
これが実際のMMF2のコード編集画面です。(※説明簡略化の為、一部加工、改竄しています)
画像をみれば雰囲気は掴めるかと思います。
3つあるシーンのうち、ステージシーンのコードを開いて編集しています。
左端の列が条件(以下 when列とします)を記述する列です。
左端以外の列はそれぞれの対象オブジェクトの処理を記述する列になります。
when列の条件を満たすとき「それぞれのオブジェクトに何が起きるか?」を記述することでプログラムを書いていきます。
同一行内でどのオブジェクトの処理から実行されるか?
は書いた順です。(チェックマークをクリックすれば、あとから順番を編集できます)
マス目のチェックマークにはなんらかの処理が記述されていることを示し、クリックすることで処理を編集することができます。
基本的には、上から下に条件を満たすか否かを秒間約60回チェックして、グルグル周ることでプログラムは進行します。
1行目の「ステージシーンが開始」という条件は、まんまの意味なのでシーンに突入した最初にしか実行されません。シーンのコンストラクタに相当すると解釈できます。
クリア条件の行は、さしずめデストラクタといったところでしょうか。
で、
このコード編集画面って、なにかに似ていると思いません?
そう、スプレッドシートです。Excelとかで書く表のことですね。
実際のMMFはGUI上でポチポチクリックするツールなので、残念ながらプレーンテキストでコードを書いて走らせることはできません。
ですが、もしスプレッドシート上でプログラムコードを書ける言語があったら素敵じゃね?…という着想を私は得ました。
編集しやすいし、一覧性高いし、日本人Excel大好きだし。
というわけで、今考えた適当な擬似コードで再現してみます。(※IEだとテーブルの表示が崩れます)
when | StageScene | Soud | tag Animal | Rabbit | tag Enemy | Wolf | Lion | Bullet | |
1 | StageScene() | Play("hunt.mp3") | |||||||
2 | always | Update() | Upadate() | Update() | |||||
3 | // Collision | ||||||||
4 | Animal HIt Wall | Bound() | |||||||
5 | Rabbit Hit Enemy | Play("bite.wav") | |||||||
6 | Rabbit Hit Wolf | Damage(wolf) | Damage(rabbit) | ||||||
7 | Rabbit Hit Lion | Damage(lion) | Damage(rabbit) | ||||||
8 | Bullet Hit Enemy | Play("hit.wav") | Delete() | ||||||
9 | Bullet Hit Wall | Delete() | |||||||
10 | // Rabbit Death | ||||||||
11 | rabbit[ Hp <= 0 ] or rabbit Hit Lion | ReStart() | Paly("death.wav") | Die() | |||||
12 | // Enemy Death | ||||||||
13 | enemies[ Hp <= 0] | Play("kill.wav") | Die() | ||||||
14 | // Launch Bullet | ||||||||
15 | Z Key PushDown | Launch(bullet) | |||||||
16 | // Clear Scene | ||||||||
17 | rabbit[ Hp >0 ] and enemies.Empty | NextScene() | |||||||
18 | EscKey PushDown |
どうでしょう?
全体像を把握しやすくてなかなかよくないですか?
(※あまり細かい仕様は考えず即興で書き殴ったので、細かい矛盾とかバグは目を瞑ってください)
※メソッドっぽく書きましたが、実際のMMF2はユーザー定義関数やメソッドを定義できないので、あらかじめ用意された命令群を組み合わせてメソッドに相当する処理を実現することになります。クラスに相当するオブジェクトにはpublicなメンバ変数だけが設定できます。
スプレッドシート上で編集する言語を私は今のところ知らんないんですけど(あれば教えて下さい)、
CSV形式で保存したらパーサが楽でトークン分割とか「,」をみるだけでいいんで楽なんじゃないでしょうか?
いえ、本を斜め読みしただけで、パーサとかちゃんと書いた事ないので適当言ってます。棒で叩かないでください。
クラス指定用タグ
「クラスタグ」って呼ぼうかと思ったんですが、CSSにクラスタグって名の機能があるようです。ググッてみたら全然別物で紛らわしいので、便宜上「クラス指定用タグ」と呼んでおきます。
MMFでの正式名称はオブジェクトグループと呼びます。
これはそれぞれのオブジェクト(クラスに相当)に検索、指定用のタグを付与するようなものです。
サンプルプログラムで言うと
うさぎ :動物タグ
オオカミ :動物タグ :敵タグ
ライオン :動物タグ :敵タグ
となっており
動物インスタンス.鳴く();
敵インスタンス.襲う();
といった感じで指定します。
(※本当はメソッドの定義は出来ないのですが、説明が面倒なので出来るものとします)
MMFに継承はありませんが
class ライオン :動物, 敵{ }
といった多重継承や多態の代わりになるかもしれまん。
もちろん内容は継承していないので、あくまで呼びつけるときの利便性の話になりますが。
基底クラスのインスタンスにツッコんでどうこうとか菱形継承がどうこうとか
小難しいことに頭を痛める必要もありません。
継承は基本的にフォルダのような階層構造による管理だと思います。
階層による管理はどっちに入れるべきか判らない兼任者の扱いには苦労しませんか?
タグによる管理の方が容易だと愚考しますがどうでしょう?
コレクションの特筆すべき記述法
13行目のwhen列に 「敵.Hp <= 0」、サウンドと敵のオブジェクト列にそれぞれ処理が書かれていますが、
これは
「敵クラス(この例では敵タグ)のインスタンスでHpが0以下の者が居たら、kill.wavを鳴らして.Delete()メソッドで自害せよ」
といった意味です。
プログラムコード風に書くとこんな感じでしょうか。
foreach e in 敵
{
if(e.Hp <= 0)
{
Sound::Play("kill.wav");
e.Delete();
}
}
敵のインスタンスで条件を満たす者が居れば、そのインスタンスのみが指定対象となり処理が実行されます。
8行目の「弾と敵が衝突したら」の敵オブジェクト列の処理は、弾と衝突したインスタンスのみに作用します。
で、これ書いていて思ったんですが、
プログラムでイテレータだのforeachだのいちいち書くの面倒なので
enemies[ Hp<=0 ].Delete();
みたいにサクっと1行で書けたら便利なんじゃないでしょうか?
この辺、言語マニアの方のご意見を聞いてみたいです。
and と or
17行目のwhen列は条件が2行に渡っていますが、これは
if ((うさぎ.Hp > 0) && (敵.Empty()))
という意味です。and は書く必要がありません。ってかありません。
1行に複数の条件を記述することが勝手に and になります。
11行目のwhen列は
if ((うさぎ.Hp <= 0) || (isHit(うさぎ, ライオン)))
といった感じです。
こちらは or を記述します。
ちなみにifは書かなくても条件さえ書けば、暗黙的にifになっていますが、elseはありません。
これ結構不便。
実は難読言語 いつからコードは上から順に実行されると錯覚していた?
とってつけたようですが、実はMMFは難読言語です。
when列は上から順に実行されるとは限りません。
1行目の「ステージシーンが開始」という条件は文字通りの意味なので、
ひねくれ者が、たとえ最終行に書こうと最初に実行されてしまいます。
要するに各条件にはプライオリティが設定されていて、高いものから実行、同格なら上の行が優先的に実行されます。
「シーンが開始」はプライオリティの高さが比較的判り易いですが、使っているとどっちが先に実行されるのかよく判らない事態にしょっちゅう遭遇します。
この辺の厳密な仕様が公開されていないので、厄介なバグに遭遇した、想定通りに動いていない…と思ったら大抵このプライオリティが原因です。直感に反したプライオリティであったことが度々ありました。
(最近、全然触っていないので詳細忘れました)
MMF雑感
いくつか実際にゲームを作った感想ですが、
兎に角、売り文句とは裏腹にコードを書きまくる羽目になります。
一般的なプログラム言語にくらべと記述力は貧弱なので、あらゆる場面で痒いところに手が届かず、トリッキーな対策と謎仕様の調査に追われ、作り込めば作り込むほどにスパゲッティでメンテナンス性の低いコードになりがちです。(もちろん書き手次第と言ってしまえばそれまでですが)
楽するためにツールを使い始めたのに、結局C++でガリガリ書いた方が早いじゃなですかー!
と憤ったものです。
衝突駆動 絶対にコードは書きたくないでござる!
MMFはこれが衝突したら~、重なったら~ など衝突関係の条件機能が充実してます。
MAPエディタの使い勝手もいいので、ビジュアルにオブジェクトをマウスとドラッグで配置していく作業が向いています。
貧弱なMMFのコード記述力を補う為にLuaスクリプトを取り込むプラグインを導入したり,色々ちょこざいな手を駆使してコードをガリガリ書く方法もあるんですが、折角のビジュアルベースツールを使う意義が薄れます。
なので、なるべくコードを書かずに「~が衝突したら~するという」衝突駆動で作っていくのが効率の良い使い方になります。
…ってテクニック集を書く気はないって言っときながら、Tips臭くなっちゃいましたね。
でも、この何もかもオブジェクトの衝突を起点にイベントが起こる―という組み方はMMFだけではなく、プログラム言語でゲームを作る際にも応用できます。
例えば、敵オブジェクトの方向転換や行動変化を非表示オブジェクトへの衝突によって記述する―とか、「ボスが出る」アイコンを踏めばボスが出るとか。それなりに使い勝手のいいMAPエディタを自分で組んでいれば、コードを編集せずに、何もかもをオブジェクトの配置だけで修正、変更できます。
デバッグしやすいように表示非表示をゲーム中に切り替えられるようにすると便利です。
兎に角コーディング能力に乏しい自分は、最近もっぱらこの衝突駆動でゲームをホイホイ作っています。
思考ルーチンまでもを、バックグラウンドで思考の迷路を配置して歩かせたり。
本来不可視のあらゆるロジックをモノとモノが衝突することがきっかけで動くようにしてます。
ってあれ?これEsolangの記事でしたね。色々とスミマセン。
Esolangと私が衝突したことをきっかけに、思い付いたことを延々と書くエントリになっちゃいました。
コメント