JavaScript256文字でのゲーム作り

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

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

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

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

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

クロスハイウェイならぬクロスかめ。ワンキーゲームを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。

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あたりを参照すると楽しい。

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

REPL screenshot

  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ってゲーム開発に活用できる？

screenshot

前に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でちょっとずつ試しながら作る、とかいう作り方を想定しているらしい。詳しいことは以下の記事や記事中のムービーを見ると分かる。

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

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

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

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

f:id:ABA:20171014170315g:plain

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

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

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

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

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

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

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

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

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

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

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

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

slickslack_screenshot

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

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

slickslack_screenshot_generating

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

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

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

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

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

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

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

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

lark-matter screenshot

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

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

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

基本的には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で発生するイベントの一覧とか。

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

ブラウザ上でサーバサイドコードをエディット、実行できるGlitch

jsbinみたいなクライアントサイドJavaScriptをブラウザ上でエディット、共有するサイトはいろいろあるけど、このGlitchはサーバサイドでのコードをエディットして実行できるのが特徴。

とりあえずアクセスした人が適当にセルを埋められる多人数ライフゲームを作ってみた。Glitchのエディタ上でコードを書くだけで適当なURLが割り当てられてnode.jsでサーバサイド実行してくれる。

ドキュメントがあまり無いので結局何をしてくれてコードが実行されるのかがよく分からんのだが、たぶんこのエディタ上のルートディレクトリでnpm install、npm startした結果が動作しているのだと思う。だからpackage.json上のscriptsで実行させたいサーバサイドコードのエントリポイントを示しておいて、そのエントリポイントからexpressなどのサーバを起動、express.staticでクライアントサイドのJavaScriptやHTMLの置き場を示せば良い、のだと思われる。

ただブラウザ上エディタで昨今の近代的なJavaScript開発を行うのはなかなか限界があるので、その時はGitHub上にプロジェクトを置いてそれをインポートするのが現実的かもしれず。

5分間くらいアクセスが無いと自動的にサーバは止まるので、データを永続化したい時は外部DBに頼るか、sqliteなどを使ってファイルに記録しておく必要がある。そのほかにもいろいろ制約はあるけど、今のところサービスは無料で使えるようになっているので、簡単なnode.jsアプリを作って公開するにはお手軽かも。

Twitter上でそのまま遊べるアクションゲーム

はタイムライン上でJavaScriptが動かないので原理的にムリだ。なので、

こうなる。プレイヤーの良心に期待だ。

この方式の欠点はくさるほどあるが、一番の問題は避けゲーしか作れないこと。プレイヤーが能動的に何かを取ったり撃ったりすることはできない。Gifだから。

あとはこういったタントアール的な方向に走る方向もあるけど、できればアクションゲームが作りたいなあ。なにかいい方法はないかね。

ソースコードは以下にある。

not-interactive