C言語を使ったPlaydate向けゲーム開発（エア実装編）

screenshot

crisp-game-lib-portableのポータビリティを検証するために、Playdate用実装を作ることにした。実機を持ってないのに。

Playdateは黄色い筐体と横についたクランクがキュートなコンパクトなゲーム機だ。日本からもプレオーダーできるが今から頼んでも届くのは2023年となかなか手に入らない。でもSDKはあるので、シミュレータを使った開発はできる。

Arduinoではないデバイスでもcrisp-game-lib-portableが動くかどうかを確かめるにはちょうど良い。

まずC言語でPlaydate用ゲームを作る環境を整える。オフィシャルページにやり方が載っているが、Visual Studio入れて、 GNU Arm Embedded Toolchain compiler入れて、CMake入れてと結構面倒。以下のページの情報が役に立つ。

SDKの中にあるサンプルなどを参考にCMakeLists.txtを作ってVisual Studio用のソリューションファイルを作る必要がある。あとは.slnファイルを起動すればVisual Studio上でコードが書ける。構成マネージャーを見るとZERO_CHECKというよく分からんプロジェクトができているが、それはビルドから外して、それじゃない方をスタートアッププロジェクトに設定してみたが、これが正解かは分からない。

環境ができたらコードを書く。今回書いたコードは以下。

コードの作りとしては、イベントハンドラにPlaydate用の全てのAPIが生えたポインタが渡ってくるので、そこからさまざまな機能を呼び出す。

APIリファレンスに関数は書いてあるが、いくつかの機能はLua用のドキュメントを読んでおかないと分かりにくい点も多い。

FPSはplaydate->display->setRefreshRateで指定できるが、どうも上限が50のようだ。ぜひ60にしたいのだが、性能上の制約だろうか。

グラフィックライブラリ用の機能はplaydate->graphics以下に一通りそろっているし、ビットマップキャラクタもLCDBitmapを使えば簡単に扱える。playdate->graphics->pushContextでビットマップを指定すれば任意のグラフィックスをビットマップに書き込める。

Playdateは白黒画面だが、それを補うために8x8のパターンで矩形などを塗りつぶす機能がある。そのためにLCDPatternを使うのだが……なんの説明もない。どうも16個あるuint8_tの前半8つが白黒のパターン、後半8つがマスクパターンのように思える。今回はこれを使ってRGBから無理やりパターンを作るロジックを作った。

音回りはよく分かってないのだが、playdate->sound->synth->newSynthでPDSynthインスタンスが取れれば、playdate->sound->synth->playNoteで任意の周波数の音を、期間と開始時間を指定して鳴らせる。ちゃんとオーディオタイマーがあってスケジューリングしてくれるのは助かる。

コードが書ければVisual Studio上で「ローカルWindowsデバッガー」ボタンを押すだけでシミュレータが立ち上がってデバッグできる。この辺はとても楽で良い。ビルドもそれほど時間かからない。

次は実機向けのビルドだ。cmakeにArmターゲット用のオプションを付けてビルドすれば、実機に転送可能なバイナリができる。

ここに一つ罠があって、実機用ビルドではsprintfやtimeなどいくつかの関数が使えない。なのでそれら関数はPlaydateのAPIで補わないといけない。しょうがないので今回はCMakeLists.txtでPlaydate実装向け定数を定義して、ライブラリ本体の実装を変えた。こうしてライブラリ本体は機種依存しない、という建前が崩れていく。まあブラウザ向けにEMSCRIPTEN_KEEPALIVEが必要な時点でそれは崩れてはいたのだが。

次は実機上でのテストだが……もちろんできてない。実機が無いから。何か実機固有の問題を踏んだり、パフォーマンス上の問題が出たりしそうだよなあ。

とりあえずシミュレータを使った開発の範囲だと、Visual Studioとシームレスに連携してくれることもあり開発体験は良い。ドキュメントはまあまあ充実しているが、LuaとCの間で情報が分散していたりして分かりにくい点もある。音回りはだいぶリッチな機能がありそうなのだが、全貌がよく分からない。だれかにWeb Audio APIとの対比で説明して欲しい。

あとはWindows上のシミュレータと実機の挙動の差が少ないのであれば全体としてよくできた開発環境であると思うのだが、そこが分からんので総合的な評価はできないね。その辺が書いてある記事とかネット上にあるかなあ。ちょっと検索した範囲だと、実機があまり出回ってないせいもあって、私と同じエア実装勢が多いような気がする。

移植性の高いミニゲームライブラリを目指すぞ

PyBadge crisp-game-lib-portable screenshot

ミニデバイス向けミニゲームライブラリcrisp-game-lib-portableがM5StickC PLUSに加えてAdafruit PyBadgeでも動くようになった！２つのデバイスで動くので移植性が高い！完成！

とは言えないのは分かっている。そもそもM5StickC PLUSもPyBadgeも同じ Arduino IDEでビルドできるし、画面周りも LovyanGFXが両デバイスに対応しているので、移植自体難しくないんだよね。せめてArduino IDEを使わないほかのデバイスで……とか考え始めるとマイコンボード沼に片足突っ込みそうで怖い。実機は無くともPlaydate SDKに移植・ビルドできるか、くらいはやってみても面白いかも。

crisp-game-lib-portableはライブラリ本体とゲームのコードはブラウザを含むすべてのデバイス向けで共通、デバイス向けには最小限の個別コードを書けば対応できる、というのを目指している。M5StickCPlus向けはcglpM5StickCPlus.ino、PyBadge向けはcglpPyBadge.inoがそのコードに当たる。

デバイス個別コードで書かないといけない処理は、

  • デバイスの初期化処理（Arduinoならsetup()）とそこからのinitGame()の呼び出し
  • フレームの更新処理（Arduinoならloop()）とそこからのsetButtonState()呼び出しによるボタン状態の通知とupdateFrame()の呼び出し
  • machineDependent.hで定義された描画や音周りの処理

だけ。なので両デバイスとも必要な実装はC言語で250行程度だ。

音回りの実装はmd_playTone(float freq, float duration, float when)で特定の周波数を、特定の期間、特定の開始時間で鳴らすことを要求していて、これが一番面倒かもしれない。PyBadgeみたいなブザー音量をanalogWrite()で設定できるだけ、みたいなデバイスだと、音のタイミング管理をしつつ、矩形波を自力で生成しないといけない。まあ面倒だったら全部Not Implementedで音が出ないようにしてしまえばいいんだけど。

md_drawCharacter(unsigned char grid[CHARACTER_HEIGHT][CHARACTER_WIDTH][3], float x, float y, int hash)でドット絵を表示して、もちょっと面倒かも。最後にハッシュ値が付いているのは、毎回ドット絵のパターン定義をパース・描画するのではなくて、ハッシュ値でキャッシュしておいてそれを使ってね、という要求なので、そのロジックを書かないといかん。LovyanGFXがあるならLGFX_Spriteとハッシュ値をペアで保存しておいて、それを取り出してpushSprite()するだけなので比較的簡単。

どちらかというと各デバイス固有の開発環境を整備するほうが面倒だよね。Arduino IDEがかなり広範なマイコンボードをサポートしてくれているのはとてもありがたいが、Arduino IDE自体の使い勝手がいまいちな気がする。ビルドに必要なファイル一式が同一ディレクトリに入っていることを要求するところとか、ビルドが遅いところとか。ビルドスピードはCcacheの導入か、PlatformIO IDEへの乗り換えで改善されるようだ。

こういった移植性を考えながらコードを書くことは、いろんなデバイスを相手にしたライブラリでないとできないことなので、なかなか楽しい経験ではある。あまたあるマイコンボードに対して、Arduino IDEなどの共通な開発環境、Adafruit ArcadaやLovyanGFXなどの多デバイス対応ライブラリを駆使しつつ独自のゲームライブラリを作るのは、PCやスマホをターゲットとしたゲームライブラリとはまた違った面白さがあり、おススメします！

いや、いにしえの教えを思い出したぞ！ライブラリを作るなゲームを作れ！やっぱりおススメしません！

アマチュア向けゲーム開発環境を13年前と比較すると

昨今の自作ゲーム向けハンドヘルドゲーム機を調べたついでに、13年前の2009年にアマチュア向けゲーム開発環境について書いていたことを思い出した。

せっかくだからハンドヘルドゲーム機以外についても、ここ13年でどういう変化があったか、知っている範囲で書いておこうかと思う。

PC

王道。最先端のCPU, GPUを使ったゲーム開発が可能。言語、ライブラリもお好みしだい。欠点としては、ゲームが実行される環境があまりにバラバラなので、環境依存の問題がおきやすいことと、統一したゲーム配布プラットフォームがないこと。アマチュア向けSteamみたいのがあるといいんだが。

Unity、Unreal Engine、Godotを代表とするゲームエンジンを使うことが標準となった。DirectXを直接さわってごにょごにょみたいなことはだいぶ減ったと思う。ゲームエンジン本体の豊富な機能と、付属するアセットストアがゲームの開発効率や品質の向上にとても効くので、しばらくはこの傾向が続きそう。

アマチュア向けSteamはitch.ioがほぼ実現しているように見える。というか、一定のクオリティのゲームが作れる人は、インディーゲームとして普通にSteam上で配信してるよね。

（追記）

ゲームの実行環境と開発環境、キャラクタ・レベル・音のエディタなどを内包した軽量ゲームエンジンとしてのファンタジーコンソールが、小規模なゲームの開発では多く使われるようになってきた。作ったゲームはブラウザやRaspberry Piなどを使ったオープンゲーム機でも遊べることが多い。

ブラウザ

Flash

ブラウザゲーを作るに当たっては一番メジャーなプラットフォーム。

ああ、当時の私に伝えたかった。Flashはその後死んだ。今やブラウザ上にその再生手段は無い。作ったゲームは死蔵されるほかない。Flashコンテンツを現代のブラウザ上で動かせるようにしようというプロジェクトはいくつかあるが、複雑なFlashを再現することは難しく、完遂したものはまだない。

JavaScriptでゲーム開発はパフォーマンスや描画機能の面でいろいろと制限が多くあまり現実的ではないが、あらゆるブラウザで動作する可搬性は魅力。

その後、JavaScript周りのブラウザ機能や開発環境がこんなに強化されるとは。ブラウザ上のゲーム実行環境はJavaScript一択になり、WebAssemblyやWebGLと組み合わさることで言語の垣根を超えGPUをフル活用できるようになり、Unityなどのゲームエンジンのターゲットデバイスになった。

Google Chrome + Canvasはその制約を取っ払うポテンシャルがありそうだが、そうするとChromeにロックインされてしまうという点が残念。

でも2009年当時はやっとChrome限定でゲームに利用可能なCanvasが搭載されたくらいで、JavaScriptはまだ未成熟だったのだよ。

モバイルデバイス

黒船iPhoneではObjective-Cを使ったゲーム開発が可能。App Storeを通じた配布経路も完備。App Storeにすでに多くのゲームがある今だとそれらの中に埋もれてしまう懸念はある。マルチタッチディスプレイを使った独特のUIは利点でもあり欠点でもある。UI上の工夫はより面白く難しい。

Google Android上でもJavaによる開発が可能。Android Marketによる配布もできる。

今でもiPhoneとAndroidです。以上です。

スマホゲームそれ自体の普及度と多様性は素晴らしく、今後もしばらくこのままだろう。デバイスのカテゴリとしてみた場合、スマホに代わる新たなゲームUIを備え、全人類に普及するデバイスが今後出てくるか、それはよく分からない。

コンシューマ機

XNA

Xbox360上で動作するゲームがC#で作成できる。Visual Studio上のデバッグメニューを叩くと360上で自作ゲームが動き始めるのは感動。

XNAはだいぶ前に終わりました。

コンシューマ機の開発をオープンにアマチュアに解放する、という取り組みはほとんど聞かなくなった。一定のクオリティのゲームが作れるインディーゲームデベロッパは、直接コンシューマ機向けにゲームを開発することが当たり前になった今、そういう取り組みの必要性が薄れているのだろう。

そんななかでもSwitch向け開発環境としてプチコン4が出ていることはとてもありがたい。できれば開発環境はPC、実行はコンシューマ機、という体験ができるとより良いんだけど、それはコンシューマ機向けにリリース可能なソフトウェアの制約などのために難しいんだろうね。

ゲーム内エディタ

メイドイン俺のようにゲームが作れるゲームや、リトルビッグプラネットのようにエディタの自由度が高すぎて別ゲーが作れてしまうものなど、ゲーム内でゲームが作れるものがある。

はじめてゲームプログラミングのような教育用途とは言えそこそこ柔軟なゲーム開発ができるものや、スーパーマリオメーカー2のような柔軟なレベルデザイナーが、今だリリースされていることもうれしいね。

携帯ゲーム機向けでアマチュア向けにオープンになっている事例は少ない。

Switchという据え置きと携帯を兼用するコンシューマ機が出てきた今、この区分けはあまり意味がなくなってきた。

オープンゲーム機

最初からユーザに向けてオープンな開発環境を整備しているゲーム機もある、が多くはあまりにマイナーだ。

オープンゲーム機については以下に書いた。

DIYによる柔軟性が得られた一方、広く普及しているオープンゲーム機にターゲットを絞って自作ゲームをリリースする、ということは難しくなっているように思える。Playdateのような個性のはっきりしたデバイスが普及すれば、それに向けた開発コミュニティもある程度形成されるかも。

2022年のアマチュア向けゲーム開発環境

Unityを代表とするゲームエンジンのおかげで飛躍的にゲーム開発体験が向上したとともに、様々なデバイス向けの適用もゲームエンジンそれ自身がその役割を担ってくれるようになったため、上記のような、〇〇用のゲーム開発環境ってあるかな？ということを考えること自体、あまり意味がなくなってきているようにも思える。

それに対してDIYハンドヘルドゲーム機のように、ゲーム機とそのUIそれ自体をカスタマイズしてしまおうという、ソフトウェアの範疇を超えたゲーム開発という取り組みが出てきている。こうなると開発環境どころかターゲットのハードウェア自体が開発者ごとにユニークになり、多様性が広がる一方、ネットワークを通じてそのゲームや開発体験を共有することは難しくなりそうだ。

まあでもアマチュアのゲーム開発はその開発体験が楽しいことが重要。王道のゲームエンジンで広く多くの人に遊んでもらうゲームを作るもよし、マイナーなプログラミング言語やライブラリでの開発を楽しんでもよし、ユニークな入力デバイスを作ってその場でしか楽しめないゲームを作ってもよし、好きなことを好きなようにやるのがいいのだ。

自作ゲームが動かせるハンドヘルドゲーム機いろいろ

ちょっと前に自作ゲームを動かせる環境・デバイスとしてどんなものがあるのかな？と思ってリストアップしたことがあった。

ちょっと前じゃなかったわ。2009年だから13年前だったわ。

ちょうどスマホが出てきたところで、PDAはもう消えた頃。携帯コンシューマ機としてのWonderWitchや、オープンなゲーム機としてGP32シリーズやP/ECEがあった。懐かしすぎるな。

2022年の今、同じようなリストを作ろうとした場合、世の中はだいぶ様変わりしている。Arduinoを代表とするワンボードマイコンをコアとし、それにディスプレイやボタンを追加したハンドヘルドゲーム機をDIYで作るというトレンドになった。

自分好みのゲーム機を自由に作れるのが利点である一方、様々なデバイスが乱立するために、それらで動作するゲームも個別の作りこみが必要な部分が増えているようにも思える。

それらに対して共通的なゲームライブラリを整備しようと思った場合、周辺部品も含めてある程度パッケージ化されていて、それなりに数が出ていて入手性が高いデバイスをターゲットとしたい。

そういう条件だとM5StickC PLUSは良いチョイスかと思った。ただ画面はだいぶ小さく、ボタンはお世辞にも押しやすいとは言えない。

今回のライブラリの理想のターゲットデバイスは、

  • それなりの大きさのディスプレイ
  • 押しやすいボタン
  • 単音でいいので音程が変えられるブザー
  • 入手性が高く、できれば安価
  • C言語での開発情報が豊富
  • ダブルバッファリングや画面描画・音再生用のタイマー・割り込みが使える

もの。そういうのないかなあと聞いてみたら、いくつか情報をいただいた。

いくつか調べてみた。

Adafruit PyBadge LC

Adafruit PyBadge LC

160x128のカラーTFTディスプレイにゲーム機として必要なボタン群が配置されている。Adafruit Arcada Libraryを使えば、Arduino IDEを使った開発もできそう。APIリファレンスとかがどこにあるのかよく分からん。サンプルとを地道に見るしかないのかなあ。ダブルバッファリングとかできるのかな。

ちなみにM5StickCのまた別の優れた点として、豊富な開発情報がある。というかLang-shipブログがある。

ダブルバッファリングのやり方もここで知った。このレベルの日本語情報があるデバイスってそうそう無いと思うんだよな。

Microsoft Makecode Arcade

Microsoftが行っているオープンソースのプログラミング学習プラットフォームMakeCodeの中に、専用のゲーム機でゲーム開発ができるMakeCode Arcadeがある。上記ページにあるように多彩なゲーム機が取り揃えられていて、PyBadgeもこのラインナップ中の1つだ。

ただ、MakeCode Arcade自体はScratchやJavaScriptでのゲーム開発を主体と考えており、C言語での開発情報が提供されているかどうかは不明だ。PyBadgeのように個別にC言語ライブラリが提供されているデバイスを探す必要がありそう。Meowbitとかかわいくていいんだけどね、C言語ライブラリの所在が不明。

Wio Terminal

2.4インチLCDと筐体上部に3つのボタンが付いている。5方向スイッチという名の十字キーがあるが、ゲーム向きではないそうだ。Arduino IDEでの開発ができる。

ライブラリの情報がよく分からんがWio Terminalドキュメントガイドを見る限り、M5StickC PLUSでも使ったLovyanGFXが使えるので同じ感じでできるのかしらん。

WiFiBoy Pro

WiFiBoy Pro

2.4インチカラーTFT LCDに標準的なゲーム用ボタン群。Arduino IDEでの開発が可能で、チュートリアルページにはいろんなゲームのサンプルもある。

Playdate

黄色いボディと横のクランクが特徴的なゲーム機。ディスプレイは白黒。C言語での開発ドキュメントも整備されている。

とても良さそうなのだが、最短の出荷がEarly2023と慢性的に品不足ぎみ。手軽に手に入るようになるといいな。

Arduboy FX

ちょっと前まではArduinoのハンドヘルドゲーム機といえばArduboyだったのだが、終売したのか入手性が微妙な気がする。オフィシャルページはSold Outのまま。

ここで挙げたものは有名なものだけだと思うが、それでもかなりのバリエーションがあることが分かった。DIYのものを含めると無数のハンドヘルドゲーム機があるし、特殊なUIを実装した既存ゲーム機とは一線を画したものもいろいろありそう。そういったものを調べるのも楽しそうだけどそれはまた今後。

教えてもらった中ではPyBadgeが良さそうかなあ。その前にまずM5StickC PLUSで一通り基本機能が動くようにしないといけないんだけど。

M5StickC PLUSでミニゲームを動かそうとして久々にC言語と格闘

JavaScriptのゲームライブラリcrisp-game-libで量産したミニゲームを、PCやスマホだけでなくて、何か小さなデバイスでも遊んでみたい。そう思って、移植性の高いC言語でライブラリを再実装してみている。

画面とボタンが付いていて入手が容易な小さなデバイスとして、まずはM5StickC PLUSで動かすことを目指してみた。いまのところ、まだ機能は限定的だが、いくつかのゲームが動くようになってきた。

小さなデバイス向けと言いながら、ブラウザでも遊べるようにしてある。C言語で書かれたゲーム本体やライブラリを、EmscriptenでビルドしてWebAssemblyファイルを生成し、JavaScriptのラッパを通じて動かしている。

デバイス依存で実装しなければいけない関数は、machineDependent.hに定義してある。M5StickC PLUS向けの実装はこのヘッダファイル内の関数をC++で実装した。

ブラウザ向けの実装は、Emscriptenの--js-libraryオプションでブリッジのコードを指定してC言語側からJavaScript側の関数呼び出しを、JavaScript側からC言語側の関数はModule.ccallで呼び出している。

ブラウザで動くようにしておくと、いちいちデバイスへバイナリをビルド・転送する必要なく、PC上だけでデバッグ・動作確認できるのが、ゲーム開発の効率上も良い。Arduino IDEのビルドってなぜが非常に遅いし。ブリッジ部分でポインタのやり取りをしたり、Emscriptenのコンパイラに与える適切なオプションを模索したりという部分はそれなりに面倒だが、それでもやっておく価値はある。

crisp-game-libの主要部分のみ実装して、簡単なゲームが動作するところまではできた。まだ色関係の機能、リプレイ、各種オプションなどが実装できてない。あと、BGMとか効果音の音周りは、デバイス側にリッチな音源が期待できないため、音の高さのみ制御可能な単音のブザーを想定した、新しい生成ロジックを作った。

crisp-game-lib-portable実装にあたって久々にC言語でプログラミングしたけど、TypeScriptのリッチな開発体験に慣れまくった身にはキツイ。char *str[][7]とか、よくこんな分けわからない変数宣言とつきあっていたな。これと比較すると任意のプロパティを生やせて配列も自在に足したり消したりできるJavaScriptのオブジェクト配列が神がかって見える。ポインタ周りの謎文法の数々や、デフォルト引数の無い関数、ガベコレに頼れないメモリ管理、ヘッダファイル、貧弱なモジュール管理、整数と浮動小数点間の変換に起因するバグ、ジェネリクスや言語サーバの不在、などなど、久々の苦行は楽しくもあり、懐かしくもあり、苦しくもあり、苦しくもあり、苦しい。

M5StickC PLUS以外にもう一つくらいターゲットデバイスがあると良さそうだけど、簡単に入手できて安価なデバイス、できればもうちょっと大きな画面と押しやすいボタン付き、という条件に当てはまるもの、あるかしらん。

絵日記の絵を書くノリで、ミニゲームを作って貼る、ミニゲーム日記というのはどうだろう

カプコンアーケード2ndスタジアムを遊んでいる。2ndはかの名作ソンソンが無料でついてくるという太っ腹仕様だ。ソンソンはあえて分類すると横スクロールシューティングだと思うが、6列の床の上を上下に移動するという特殊な仕様があるため、ジャンプアクションやドットイートゲームのようなテイストも感じられる不思議なゲームだ。隠しキャラの竹の子がゼビウスのセルのオマージュだという話をよく聞くが、この話はどこで語られたものなんだろう？

カプコンアーケードスタジアムでは、初代も合わせると代表的なレトロカプコンゲームはだいぶカバーされている気がする。ローリングスイッチみたいな特殊なコンパネの再現は無理だが、リワインド（巻き戻し）ありで昔の難しいタイトルに気軽にチャレンジできるのはありがたい。

リワインドありでエグゼドエグゼスみたいな比較的テンポがゆったりなゲームを遊んでいると、いくらでも被弾可能なこともあってゲームというよりなにかの作業をしているような気持ちになってくる。それはそれで悪くない体験で、緊張感がほどよくほぐれていく感覚が心地よい。

まあでもリワインドを何度も繰り返して、難局を突破できる場面を探すことそれ自体にストレスが無いわけではないので、ものによってはスパッとゲームが終わった方が精神衛生上良いかもしれない。

スプラトゥーン３前夜祭楽しかったね。我がパー陣営はボロ負けだったが、噂に聞くチョキ陣営トリカラバトル地獄の防衛戦はしないで済んだ。

前作との差が分かるほどやりこんでないのであまり感想は無いが、新しいスペシャルウェポンはなかなか楽しいね。ショクワンダーとかグレートバリアとか、Apexからジップラインガンとプロテクトドームを輸入したのかな？みたいのもあって。N-ZAP85を撃ってるのが一番しっくりしたけど、ブラックマーケットめいたエナジースタンドの効果がちゃんと分かるほどの腕は無く。リリースが楽しみである。

仮にゲーム自動生成AIができたとして、我々はどのような文章で、作って欲しいゲームをAIに伝えるだろう

One would hope that in ten years time there's no longer static content because everything is generated on the fly.

画像生成AIであるMidjourneyのファウンダーDavid Holzが、ゲームから静的なアセットは無くなり、AIがオンザフライで作った各種アセットをそのまま利用できるような、巨大AIチップを搭載したゲーム機が10年後にはできるのでは、という話をしている。このようなゲーム機ができれば、ゲーム内のテクスチャやキャラクタは自動的に無限に生成可能になる。

なかなか野心的なビジョンだが、それでもゲームそれ自身が無限に生成可能になる、とまではいかないのかなあ。キャラクタ、エフェクト、サウンド、レベルデザイン、ストーリーなどに加えて、ゲームルールそれ自身まで自動生成可能になれば、もはやゲーム機はゲームソフトを必要としなくなり、無限のゲームをゲーム機自体が内包していることになる。

ゲームルールの生成が簡単でなさそうなことは、なんとなく分かる。

  1. ゲームルールの理解・データセット化が難しい
  2. データセット化されたゲームルールを組み合わせて新たなゲームを作るのが難しい

ちょっと思いつくだけでもこんな問題がありそうだ。

1.については、いくつかの解決アプローチがすでにありそうだ。OpenAI Gymでのゲームプレイヤー強化学習などはある意味ゲームルールの理解を行っているし、動画からパックマンを再現するGameGANもある。まあこれもプレイヤー操作と画面のシーケンスを解釈しているだけといえばそうだが、それは技術発展にどうにかしてもらおう。

そんでもってゲームルールのデータセットができたとして、問題は2.だ。絵の自動生成においては、対象となる物やアングル、画風などを文章、プロンプトで指定し、それらをなるべく違和感の無いようミックスすることによって生成することができる。

ではゲームルールにおける対象物、アングル、画風はなんだろう。登場するキャラクタ？2D・3D・横スクロールなどのアングル？シューティング・プラットフォーマー・FPS・MOBAなどのジャンル？既存のゲームの物理法則？目指すべきゴールや敗北条件？

仮にそういったプロンプトでゲームを自動生成できるAIができたとして、どのような文章でAIに作って欲しいゲームを教えるか、それを想像するのは面白いかもしれない。

じゃあここではディグダグの続編、ディグダグIIIをAIに作ってもらおう。

「武器で敵を無力化してそれを障害物でまとめて倒すゲーム」

これは多分全然ダメ。武器とは？無力化とは？倒すとはどのように？いやこの指示でディグダグとは似ても似つかない面白いゲームを作ってくれるのであれば、それはそれですごいけど。

「ディグダグとDo! Run Runを混ぜたようなゲーム。見下ろし型の2Dアクションゲーム。プレイヤーは敵を武器でふくらませたり破裂させたりできる。フィールドには長い障害物があり、転がすことができる。転がった障害物に潰された敵は倒される」

だいぶ具体化できた。ディグダグとDo! Run Runを知っている人ならだいたいどんなゲームか想像できるだろう。だがこの情報をもとにゲームを自動生成できるのであれば、それは夢のテクノロジーだなあ。単にこの2つのゲームを無理なくミックスするだけでも大変だし、さらにそこにこのゲームならではのオリジナル要素を他のゲームなどから借用できるとなると、凄腕ゲームデザイナーだ。

なのでゲーム完全自動生成コンシューマ機の夢はまだ遠そうな気はする。でもおそらく不可能では無さそう。まずは任意のATARI 2600ゲーム2つを混ぜてオリジナルゲームを作るあたりからなんとかしてはどうだろう。YAR'S COMMANDやMISSILE REVENGEの期待が高まるね。