テキストからゲームを作るAIは何を返し、何を返さないのか

テキストからゲームを作るAIは、文章と遊べるものの間にある距離を一気に縮める。画面で何が起きるかを書くと、それを成立させる規則をAIが組み立て、絵と音を用意し、ブラウザのタブで開く形にして返してくる。シーンエディタも、スクリプトファイルも、素材フォルダの管理も要らない。代わりに受け取るのは、一行ずつ自分が把握しているプロジェクトではなく、動くゲームそのものだ。修正は毎回、文章に戻って行う。

この記事は、絵を描く技術がなく、アイデアだけを持っている人に向けている。道具を選ぶ前に、作業の形そのものを先に知っておくほうが判断が速い。どこが消えて、どこが逆に難しくなり、何を確認してから時間を投資すべきかまでを扱う。

テキストからゲームを作るAIが実際に渡してくるもの

出力されるのは遊べる成果物であって、ソースの木構造ではない。具体的には、AIが推論したルール一式、生成されたグラフィック、サウンド、そしてそれをウェブページの中で動かすための包みだ。渡されないのは、手で並べ替えられるシーングラフ、条件を書き込むスクリプト層、二つの版の差分を教えてくれる比較画面になる。

この違いが、その後の判断をほとんど決める。ゲームエンジンではプロジェクトファイルが真実で、ビルドはその副産物だ。ここでは文章が真実で、それ以外はすべて副産物になる。自分が今遊んだゲームも副産物に含まれる。同じ段落を二人が書けば、段落は満たし、段落が空けた部分では別物になる二本が返ってくる。

BinkBinkはこの方式で動く。書いた説明が入力になり、ブラウザで遊べる形が出力になり、リンクで共有できる。面白いのは動くことではなく、残しておく価値のある結果にするために、文章がどこまで具体的でなければならないかという点だ。

文章から遊べる形になるまで、何が起きているか

工程には、見えなくても区別できる段階がある。AIはまず文章を読み、実体を抜き出す。プレイヤーが操作するもの、邪魔するもの、何を勝ちとするか、何を負けとするか。次にそれを一つか二つの操作に落とす。ブラウザの短いセッションでは五つのボタンを覚えられないからだ。続いて難易度の曲線を選び、書かれた舞台に合う画を生成し、ブラウザが読み込める形にまとめる。

ここから二つの帰結が出る。先に押さえておきたい。

具体性は熱意よりはるかに効く。「楽しいプラットフォームゲーム」と書けば、決めるべきことは全部開いたままで、AIは無難で記憶に残らない初期値で埋める。「配達員が工事中の三本の通りを自転車で抜け、二十秒ごとに速度が上がり、一度の衝突で走行が終わる」と書けば、開始、失敗、テンポが同時に決まる。後者のほうが短いのに仕事量が多い。節が一つ増えるたび、決めることが一つ減るからだ。

もう一つは、結果が決定的でないことだ。二回頼めば、説明は満たすが頭の中の絵とは違う二本が返る。これは報告すべき不具合ではない。段落を版管理する対象とし、返ってきた一本をその草稿として扱う理由がここにある。変更で良くなったなら、文章も同じだけ変える。変えなければ次の生成で改善は消える。

H5ゲームジェネレーターが買うのは届く範囲で、規模ではない

H5とは、ゲームがブラウザで動くという意味だ。インストールなし、ストア審査なし、プラットフォームの承認なし。スマートフォンでもノートPCでも同じリンクが開く。得ているのは配布だ。遊べる試作をチャットに置ける。投稿に置ける。サポートのやり取りに置ける。文書に置ける。アプリを出すより基準が低く、ブラウザで遊べるゲームとして手元に届くまでの時間が短いほど、感想が返ってくる確率は上がる。

代価は下にある。ブラウザは固定の予算を課す。論理と描画を一つのプロセスが扱い、WebGLのコンテキストがページと並んでメモリに収まり、最初の遊べるフレームまでに素材が届いていなければならない。中位のスマートフォンではこの予算がすぐ尽きる。大きな3Dシーン、密度の高いパーティクル、同時に動く多数のキャラクター、リアルタイムの対戦に近いものは、どこからでも天井を押す。

ジャンルの相性は好みではなく算数だ。見える物体が少なく、ループが明快な短いセッションのゲームは無理なく収まる。無限走行、アーケードの生存、単純なパズル、合体させる盤面、挿絵付きの分岐する文章がここに入る。持続する世界、同期するプレイヤー、何百もの単位を同時に動かすゲームは収まらない。文章の技量では天井は動かない。

静かな制約も一つある。ブラウザの一本はURLに住んでいる。端末をまたぐ保存、アカウント、ランキング、キャッシュを消しても残るものは、後ろにサーバーを要求する。説明から生まれた一本は、そのサーバーを持ってこない。

説明が設計図として通用しなくなる場所

段落から必ずこぼれるものが四つある。先に知っておけば数週間が浮く。

一つ目は曖昧さだ。楽しい、洗練された、気持ちいい、没入できるといった形容詞は感覚を指していて、感覚は実行できない。AIゲーム生成は書かれていないことを推測しない。評価できる条件にしか作用できない。プレイヤーが何を押すか、接触で何が起きるか、いつ終わるか、それぞれがどの速さで動くか。検査に変換できない節は、変換の途中で消える。

二つ目は操作の精度だ。フレーム単位の手触り、ジャンプの正確な弧、被弾後の復帰の幅、ダッシュの加速曲線は、ミリ秒で繰り返せるビルドに対して数値を動かして詰める。ここでは節を書き換えて再生成するしかなく、道具としては粗い。ジャンプを浮遊感から重量感へ移すことはできる。プラットフォーマーを公平に感じさせる十一フレームの猶予を詰めることはできない。

三つ目は状態の複雑さだ。「鍵を持っていて扉が開いているなら」という規則はひとりでに書ける。「店は三日目に在庫を補充し、価格は評判で上がり、希少品は二体目のボス以降にしか出ない」は仕組みであり、仕組みは明示的な状態と実行順序と保存を要求する。説明はループをよく運び、シミュレーションをうまく運べない。

四つ目は分量だ。画面一枚を生成するのは安い。繰り返さずに強くなる二十面を作るのは生産工程の問題になる。キャンペーンが必要になった時点で、文章は目次に変わり、生成に手伝わせながら手で書く作業に戻る。

最初の一本は一晩で公開できる

本当に動くものへの最短経路は、工程だけが変数になるまで範囲を削ることだ。一気にやる。

1. テキストファイルに三つの文を書く。十秒ごとにプレイヤーが何をするか、何が終わりにするか、時間とともに何が難しくするか。合計四十語未満に収める。
2. その三文から生成する。四つ目は足さない。
3. 五分遊び、欠点を一つだけ選ぶ。手が止まったもの。スクリーンショットで一番悪く見えるものではない。
4. 原因の節を書き換え、再生成し、もう一度遊ぶ。書き換えても欠点が残ったなら、その節は原因ではなく、原因はループのほうにある。
5. 三文を読んでいない三人にリンクを送る。質問は一つだけ。続けたい気持ちが消えたのはどの瞬間か。面白かったかは聞かない。

四番目でほぼすべての初回が崩れる。二つ三つの節を同時に変えると、ビルドは良くなり、どの変更が効いたかを誰も学ばない。一巡につき一節なら、原因と結果がつながったままで、一晩に五巡まわせる長さに収まる。

テキストからゲームを作るAIから始めるべきでない人

手触りが商品であるゲームなら、エンジンから始めたほうが速い。そこでは調整のループそのものが製品で、説明は結果を見ながらつまみを動かす作業の代わりにならない。

アイデアがループではなく世界である場合も、いったん止めたほうがいい。設定、人物、勢力、地図は書くだけで数か月を吸う。その間、遊べる核は未定義のままだ。仕組みは舞台に沿った何かを喜んで生成し、二度目にやることが何もない一本を返す。誰も警告してくれない失敗の型がこれだ。

コードの所有権が要るチームも別の例だ。レビューし、差分を見て、他人が拡張し、何年も維持する必要があるなら、成果物はプロジェクトでなければならない。生成された一本では務まらない。

アカウント、経済、対戦を設計する人は、この経路を試作の段階として扱うべきで、公開の手段にはしない。足りないサーバーは見た目の問題ではなく構造の問題だからだ。

一か月を渡す前に確認する四つ

まとまった時間を投じる前に、すでにある一本で四つを試す。

ループを三回続けて遊べるか？　この問いは仕上げではなくループを測っていて、次の一か月に値するかを予測する。

次に変える変数を一つ名指しできるか。答えが漠然としているなら、設計はまだ気分の段階で、生成を重ねても直らない。

説明なしで他人が開けるか。誰も開かない一本は私的な実験で、私的な実験からは次の版を良くする感想が出てこない。

まだ画面一枚か。正直な答えが「画面一枚と地図と店」になった瞬間、ここまでの工程は正しい選択ではなくなっている。明示的な状態を持つ道具へ移る判断は、早すぎるのではなく遅すぎる側になる。

段落が設計図だ。十秒で読み返せて、他人が質問なしに実装できる程度に具体的であればいい。残りはAIが運ぶ。