理想のマイコン機械語開発環境を夢見て

PC-6001やMSXの機械語開発時代にREPL (Read-Eval-Print Loop)環境があったらという妄想のもと、Z80のREPLを作った。

ブラウザ上でZ80ニーモニックを実行できるREPL。実用性は無い。LDIRがメモリを埋める様子がたまらん人向け https://t.co/Q3lLMNn7Cq pic.twitter.com/Y2r2QzYO7H

— ABA (@abagames) 2018年9月8日

ブラウザ上で遊べる。

ソースはGitHubのabagames/z80-replに置いた。

コマンドラインからZ80ニーモニックを書いてEnterを押せば、それが機械語に変換されてPC（プログラムカウンタ）が指すメモリに書き込まれ、そのまま実行される。実行結果は画面上のメモリマップやレジスタリストに反映される。すぐJR -2とかいう悪さをする人がいるかもしれんが、64回ループを回った時点で一時停止する。Enterを単に押せば現在のPC上の機械語がそのまま実行される。ブラウザから開いてそのまま連打すればNOP, NOP, NOPだ。TABを押せばニーモニックの候補も出る。レジスタを直接操作する手段はないので適宜LD、PCを操作する手段も無いので適宜JPすること。

ツイートに書いたように多分これ単体ではあまり実用性はなく、アセンブラのエディタの脇でChrome DevToolsかのようにこのREPLが開いて、動作検証ができるようになっていれば、当時相当楽できたのではないかと思える。ブレークポイントなどのデバッガ機能と統合されていればなお良い。

実際の当時の機械語開発環境といえば、ハンドアセンブルだ。ノートとかにニーモニックを鉛筆で書いて、

LD DE,D0H
LD HL,80H
LD BC,0AH
LDIR
RET

インストラクションセット表を見ながら機械語に手で変換し、BASICのDATA文として書く。

1000 DATA 11,D0,00,21,80,00,01,0A,00,ED,BD,C9,//

DATAを読み取りPOKEで書き込み、EXECだ。

10 RESTORE 1000
20 A=&HE000
30 READ V$
40 IF V$="//" THEN 70
50 POKE A,VAL("&H"+V$)
60 A=A+1:GOTO 30
70 EXEC &HE000

MSX-DOS時代はアセンブラがあったからまだだいぶマシだが、それでも前記のJR -2のようなコードが混入した時点でコードは暴走、プログラムはおしゃかだ。マイコンをリセットし、テープからプログラムを読み直さないといけない。

これらの時代と比べれば今はChrome DevToolsのような超高度なREPL、デバッガ、プロファイラが付いてくるのが当たり前で、とてもいい時代になったものだ。でもたまに昔のアセンブラやBASICを思い出して古き良き時代を思い出したくなることもある。そういったノスタルジーを簡単にちょっとだけ満たすためのツールでした。ノスタルジーを通り越して現役の血が蘇った人は組み込み勢やレトロPC現役開発勢になだれ込むと良いかと思います。

256文字ゲームくらいならコンピュータが作って欲しい

最近作った256文字ゲームを見ながらこんくらいコンピュータ様が自動的に作ってくれないかと思っている https://t.co/JeRvlRwzqc

— ABA (@abagames) 2018年3月6日

あとは2つのゲームのメカニズムを適当に混ぜ合せるっていうアプローチもあるけど、混ぜてゲームとして成り立つ組み合わせってほとんど無いのではという気もする

— ABA (@abagames) 2018年3月6日

でも物によっては混ぜられないこともない。

例えば

と

を混ぜて

というゲームにしたり、

これ

と

を混ぜて

というゲームにしたり、だ。

混ぜ方としては、ゲームを2つのパーツに分ける。マウス操作が反映されるプレイヤー側パーツと、それ以外の物を動かすパーツ。で、2つのゲーム間でそれらを入れ替える。そうするとたまに新しいゲームになる。

もちろんうまくいかないパターンの方が多くて、

と

を混ぜると

車が無限に落ちる虚しいゲームができる。

こういう混ぜ方でうまくいくのは古典的な避けゲーくらいな気もする。プレイヤーの動作と障害物の動作のバリエーションで新しいゲームを作る。でもそれは避けゲーのステージバリエーション的なもので、新しいゲームと呼ぶのは厳しい気もする。あと動作自体のバリエーションを新しく生成することもできない。

前途多難である。

JavaScript256文字でのゲーム作り

• Tiny Art in Less Than 280 Characters

ggplot2で280文字以内で作られた美しい幾何学模様。

• sc140

SuperColliderで140文字以内で作られた楽曲群。

• Dwitter

JavaScript140文字以内でできた作品集。

短いコードで作られた作品は情報がギュッと詰まった感じが美しい。最低限の構成要素で最大限の効果を得る工夫が詰め込まれている。

グラフィックスや音楽だけでなくて、ゲームでも同じように短いコードで書けるといいな、と思っていたらDwitter上の以下の作品を紹介してもらった。

• Crossy tortoise

クロスハイウェイならぬクロスかめ。ワンキーゲームを140字で実現しているのがすごい。でもスコアは無くて一度渡りきったらそこで終わりという潔い作り。

ゲームを名乗るからには以下の要素は入れたい。

1. スコアがある
2. ゲームオーバーがある
3. 難度が上昇する
4. できれば音も鳴る

と思ったときのショートコーディング向けの妥当なレギュレーションはどんなもんだろう、ということを考えてみた。

1. JavaScript256文字以内で毎フレームのアップデート用関数を書く

2. p5.jsの関数を使って良い。あとTone.jsとlodash.rangeをライブラリとして導入

3. p5.mouseIsPressed, p5.mouseX, p5.mouseY, p5.random(), Tone.synth.triggerAttackRelease(), _.range()に1文字のエイリアスを与える

4. Sにスコアを入れると画面上部に表示、Tを参照すると経過フレーム数が分かるでそれで難度調整

このレギュレーションに沿った開発環境とサンプルを以下のリポジトリに置いた。

jsgame256

サンプルゲームの一つ、クリックでジャンプするゲームspringcar。

clear(),T||(s=A(9).map(i=>[10*i]),y=v=0),d=1+T/999,s.map(u=>text("🔩",u[0]=u[0]<99?u[0]+d:-R(30),80)),y+=v+=(M?.1:.2)*d,get(74,y)[3]+get(82,y)[3]>0&&(v=-1,y=72,S++,N(333,.1)),y>70&&v<1&&M&&(v=-3,N(444,.2)),y>95&&(S=y=T=0,N(222,.5)),text("🚗",75,y)

まあガチ勢から見るとユルユルである。バリバリにコードゴルフ頑張ります！、みたいな感じではなくて、256文字という制約があるからこんくらいのゲームしか作れないんだよねー困ったなー今回はこれで許して、的なノリである。

ガチ勢は一切の余計なライブラリを許さずJavaScriptを含むHTML全体のバイト数226バイトのポンを作ったりする。codegolf JSあたりを参照すると楽しい。

今回は楽して短いブラウザゲームを作ろうというノリなので、ビルドツール側でもいろいろと工夫した。

1. uglify-esを使って自動的にコード短縮

2. webpack-dev-middlewareを使ったdev serverを作って、ライブリロード時に自動的にuglify、現在のコードが短縮時に何文字になるかを表示

3. 前に作ったREPL環境を導入するとともに、REPLから'//b'と入力するとビルド、単一のHTMLファイルをビルド結果として出力。ついでにその時のスクリーンショットをTwitter カードのイメージ用にも作成

uglifyは優秀でJavaScriptの一般的なショートコーディングテクニックは勝手にやってくれるのでチマチマしたところは工夫しなくて良くなる。人間はデータ管理の工夫とか重複データのコード上の重ね合わせとかもう少し広いコンテクストでの短縮を頑張れば良い。

このレギュレーションと開発環境ならばだいたい1時間くらいでなんらかのゲームを作ることはできる。もちろん256文字の制約は厳しくてちょっと凝った動きを実装しようとするとあっという間に文字数があふれる。あとellipseとか名前の長い関数を使うのがキツイ。配列とmapは神機能。

270文字くらいのゲームができたときが悲しくて、小手先のテクニックでは縮めきれないのでゲームシステムの方を縮小しなければいけないことがある。せっかく作ったのに。まあでも256文字制約が無いと無限に演出を付けられるしゲームバランスもいじり放題になるし、それらを諦めるための縛りなのだから悲しくても捨てることだ。

短時間でアウトプットが得られるという点ではこんくらいの縛りでのゲーム開発はなかなか面白い。まあゲームと呼べるかギリギリみたいなものが出来上がるのでそれで良しとするかみたいなところが微妙ではある。スキマ時間でゲーム開発がどうしてもしたいというゲームデベロップメントジャンキーにはオススメ。

JavaScript向けブラウザREPLを試作した、けどREPLってゲーム開発に活用できる？

前にClojureScriptのREPL駆動開発について書いたけど、REPL駆動開発環境自体は別にClojureScriptじゃなくJavaScript向けにもあるんじゃないか、と思ったけどこれが案外見つからない。なのでちょっと試作した。

browser-repl-test

作るのは別に難しくなくて

1. webpack-dev-middlewareを使ったdev serverを立ててその横でWebSocketサーバを立てる

2. ブラウザ側のコードからWebSocketサーバに接続

3. dev server上からコードを入力、WebSocketでブラウザ側に送ってeval、結果もWebSocketで返す

4. エディタからコードをdev serverに送るのはSendToREPL VS Code extensionってのがあるのでこれでできる

とやった。

で、ここまで作っておいてなんだが、これってゲーム開発に役立つかしらん。REPLはデータの加工をいろんな関数を使って試していってうまく行ったパターンをソースコードに落とす、みたいな使い方が普通だと思う。けどゲームにおいては1/60秒ごとのフレームでどんどん更新されるデータが検証対象であって、この関数を適用すると次はどうなる、みたいな確認を単体で行ってもあまり意味が無いことが多い。

結局複数フレームでの更新を追う必要があるのであれば、REPLじゃなくて十分に速いライブリロードがあって、ソースコードを変更するたびにすぐにその動作を確認できれば十分じゃないか、という気がしている。これは関数型言語とかの他の言語を使ったとしてもあまり変わらないんじゃないかと。

なにかゲーム開発でREPLをこう活用していますというベストプラクティスがどこかに落ちてないかしらん。

WindowsでClojureScriptのREPLを整備する

結論から言えばIntelliJにCursiveプラグイン入れてfigwheelプロジェクト作るのが簡単そう。

ClojureなどのLisp系列言語では昔からREPLを使った開発がよく行われていて、REPL駆動開発とか呼ばれている。REPLと言うと対象のプログラミング言語の表記を入力するとその結果が帰ってくるシェルだけを指すように思われがちけど、REPL駆動開発においてはエディタ上から直接REPLへ特定のコード片を送って評価させるとかができる環境を想定していて、コードに新たなロジックを足す際にもその追加分をREPLでちょっとずつ試しながら作る、とかいう作り方を想定しているらしい。詳しいことは以下の記事や記事中のムービーを見ると分かる。

• What makes a good REPL?

せっかくだから自分でもREPL駆動開発を試してみたい、でもブラウザで動くものじゃないと作り気がしない、となった時に選択肢として挙がってくるのがClojureScriptだ。ClojureScriptはJVM上で動くLisp系言語ClojureをJavaScriptに変換するコンパイラだ。生成されたJavaScriptはもちろんブラウザ上で動かすことができる。

ClojureScriptはブラウザと連携して動作するREPLもあって、REPLで入力したコードの結果をすぐにブラウザ上に反映させたりできる。

さっそくそのREPLを何かのエディタと連携させて動作させたい、と思って最初は慣れ親しんだVisual Studio Codeでなんとかできないかと思ったのだが、なんかうまくいかない。もちろんClojure用のプラグインとかはあるんだけど、これと連携して動作するnREPLをClojureScriptに対応させたりブラウザと連携させたりがどうもうまくいかず。結局最初に書いたようにIntelliJに頼るほかなかった。

ブラウザでなにか画面出して遊ぼうと思ったときには定番のp5.jsを使うと楽だ。ちょうどp5.jsを使うサンプルコードもあったのでこれを参考に遊んでみた。

REPL上でrangeとかの関数の出力を確認しながらそれをmap関数でp5.jsの関数に引数として流し込んでみた例。ClojureScriptに不慣れな状態でも部分部分の動作を確認しながら進められるので、いきなり全部のロジックをコードとして書き下すよりは楽に書ける、気がする。JavaScriptの関数もjs/rectのような形で簡単に呼び出せる。

あとはClojureの作法に沿ったコーディングがどんくらいできるかが問題だなあ。個人的にはLisp系の言語にはあまり馴染みが無いし、Cursiveのエディタ拡張もかなり癖が強くて慣れるまでに時間がかかりそうだ。最初エディタ上で括弧が消せなくてなんじゃこりゃと思ったんだけど、Structural editingっていう括弧の対応をうまいこと保ちつつエディットできる機能のせいらしい。初心者に厳しい。とりあえず何か安直なゲームでも作ってみるのが良さそうではある。

倉庫番系列パズルゲームのレベル自動生成

ゲームの自動生成を目指すならばレベル、つまり面のパターンの自動生成もやっておきたい。ゲーム＆ウォッチ的な単一の画面で遊ぶゲームはともかく、大抵のゲームは複数の面があったりスクロールしたりするのでレベル自動生成が必須である。

どれだけ質の良いレベルを作れるかがゲームの出来にダイレクトに効くのは何と言ってもパズルゲームだ。特に倉庫番のようなアクション性が無いパズルゲームにおいては、いかに解くのが楽しいレベルが作れるかがとても重要。

倉庫番のレベルジェネレータはすでにいろいろある。作り方としては、

1. 箱が配置されていない空の部屋を作る
2. 箱を正解位置に置く
3. ゲームを逆にシミュレートして箱を適当な位置に散らす

というのが一般的のようだ。3.は要するにプレイヤーで箱を「引いて」ずらしていけば、その結果移動される箱はちゃんと正解位置へ移動可能であるということを保証できるという意味だ。

• sokoban

上の作り方に沿ったジェネレータ実装の一つ。プレイヤーが動けなくなったらバックトラックして他の置き方を探す。

• Procedural Generation of Sokoban Levels (pdf)

こちらは論文。プレイヤーが箱を直線方向に押す回数や、別の箱を押しに行く回数などのメトリクスを導入して正解位置からなるべく離れた、つまりプレイヤーがやることが多くなるレベルを作っている。

• Automatic Puzzle Level Generation: A General Approach using a Description Language (pdf)

この論文はさらにチャレンジングで、PuzzleScriptで作られる任意のパズルのレベルを生成することを目標としている。PuzzleScriptルールのアナライザからゲーム内オブジェクトの特性をレベルのジェネレータとレベルのエバリュエータに渡してレベルを生成させる。これは後段のエバリュエータが生成されたレベルが解けるかどうか、解けたとして楽しいものか、などを判定するアプローチなので、上記2つのような逆方向のシミュレーションをするものとはちょっと違う。

とまあ既存アプローチはいろいろあるが、せっかくだから何か簡単なパズルゲームを作って、自分でもレベル生成を試してみようと思った。

• slickslack

それがこれ。倉庫番とペンゴをつまみ食いしたようなパズルゲーム。青い四角で表示される箱をフリックでスリップさせて黄色の正解位置へ置いてください。

レベル自動生成方法は他の倉庫番ジェネレータと同様の正解から逆方向にゲームをシミュレートする方式。ただ空の部屋を最初に作るのではなくて、全て壁の部屋を作ってから箱を逆方向にスリップさせつつ壁を掘る方式にした。

1. 適当な大きさの全て壁（正確には壁か空白どちらでもいい状態）からなる部屋を作る
2. 正解位置に箱を置く
3. 箱を適当な方向に適当な距離スリップさせる
4. スリップ開始時にスリップ方向と逆方向に壁を置いてそこで止まるようにする
5. スリップした場所は空白で確定する（壁を掘る）

上記スリップ動作を適当な回数行ってレベルを作る。ただこれで闇雲に作ってもあまり楽しいレベルが出来るとは限らないのでちょっとだけ細工をしている。

このパズルはプレイヤーキャラがいないからかなり自由に箱をスリップさせることが出来てしまう。なのでパズルっぽさを出すには箱をスリップさせる順番や、別の箱にぶつけて箱を適切な場所で止めるにはどうするかを考えるような、箱と箱の間のインタラクションが多いものにしないといけないはず。あと壁が多すぎるとより制約が減ってしまってパズルっぽさが減りそう。それらを踏まえて

• スリップさせる時はなるべく壁を作らないで、すでにある壁や箱で止められる方向を優先する
• スリップさせた後になるべく他の箱に隣接させるようにする

という小細工を加えた。これら小細工がうまく効いているかはよく分からん。でも一応それなりに遊べるレベルは出来ているし、

ここまでやってクリアできない組み合わせは出なかったので、自動生成のアルゴリズム的には問題ないかと思われます(｀･ω･´)ゞ pic.twitter.com/CXlm1j9mnL

— タマネギ炒め (@tamanegi_itame) 2017年9月30日

クリアできないレベルができるということもとりあえず無さそうだ。

あとはPuzzleScript論文にあるようなエバリュエータを加えてレベルの楽しさを判定して生成したレベルを選別できると本当は良いのだろう。この論文では正解位置と箱の距離や繰り返しでないプレイヤーの操作数、適用されたルール数などを使って評価を行っている。これらのメトリクスが楽しさをちゃんと反映しているかどうかはともかく、明らかに楽しくないレベルを弾くには使えそうである。似たような仕組みをちょっとずつ試していきたいところ。

Matter.jsをプラグインで拡張する

ちょっと前にlark-matterっていう物理エンジンMatter.jsのレンダラをドット絵っぽくするプラグインを作ったんだけど、その時に覚えたはずのMatter.jsのプラグインによる拡張方法を忘れないうちにメモっておく。

基本的には以下のドキュメントを読めば良い。

• Creating plugins

プラグインの基本情報を書く所と登録する所はだいたいサンプルの通り書けばいいとして、肝心なのはエンジンへのパッチの当て方だ。

基本的にはMatter.beforeとMatter.afterという関数を使えばMatter.js内のあらゆる関数の実行前と実行後にプラグインとして実行したい処理を挟み込むことができるので、そこでゴニョゴニョすれば良い。

lark-matterの例で言えば、まずRenderを差し替えたいのでRender.createの後で独自レンダラの初期化などを行って、Render.runの後で既存レンダラを止めて新しいレンダラに差し替えている。

  matter.after('Render.create', initRender);
  matter.after('Render.run', runRender);

function runRender(render: Matter.Render) {
  matter.Render.stop(render);
  renderLm(render);
}

Render.runの引数とかはそのままフックする関数の引数にくるので、それを使ってrunしたレンダラを止めるとかいう処理もできる。

後はEngine.createの後でMatter.js内のイベントのリスナーを登録しておけば、特定のイベントが発生した時の処理を差し込むこともできる。例えば衝突発生時(collisionStart)にパーティクルを飛ばすとか。

  matter.after('Engine.create', initEngine);

function initEngine() {
  const engine: Matter.Engine = this;
  matter.Events.on(engine, 'collisionStart', e => {
    e.pairs.forEach(p => {
      p.activeContacts.forEach(ac => {
        const b = ac.vertex.body;
        const v = b.velocity;
        let ratio = (<any>p).collision.depth * matter.Vector.magnitude(v) * 0.1;
        if (ratio > 2) {
          ratio = 2;
        }
        if (ratio > 0.3) {
          ppe.emit(b.ppeTypeId,
            ac.vertex.x / LarkMatter.options.dotSize,
            ac.vertex.y / LarkMatter.options.dotSize,
            Math.atan2(-v.y, -v.x),
            { countScale: ratio, speed: 0.7 * ratio });
          if (LarkMatter.options.enableSes) {
            sss.play(b.sssTypeId, 2, null, ratio > 1 ? 1 : ratio);
          }
        }
      });
    });
  });
}

どのようなイベントが存在するかはMatter.jsのリファレンスを見れば分かる。例えばEngineで発生するイベントの一覧とか。

あとはプラグインのリストもあるので必要に応じて他の人の使ったプラグインを参考にすれば良い。