モバイル向けエイトボールゲーム「Pool Max」を3週間で制作し、公開しました。私のバイブコーディングは、Codexに機能を説明し、実際にプレイして違和感を見つけ、修正を重ねるという流れです。今では毎日約30試合が完了しています。実際のプレイヤーが遊んでいるのを見ると、ゲームはもう自分のパソコンだけにある作品ではないと実感します。Pool Maxのサイトでも紹介しています。
Godotを選んだ理由
試行錯誤を妨げない、軽くて起動が速いマルチプラットフォームのエンジンが欲しかったからです。デスクトップで開発し、Androidで試す流れに合っていました。Godot MCPを介したCodexとの連携も良好でした。要件をシーンやコードの変更に落とし込み、ゲームを動かして問題を確認し、次の修正を頼めます。価値があったのは一度きりの魔法の指示ではなく、速いフィードバックの循環です。
まずショットを楽しくする
最初に目指したのは美しいメニューではなく、遊べる試作品でした。見た目は素朴でも、狙って打つ感触、ボールの予測しやすい動き、試合を妨げる明らかな不具合がないことを重視しました。さらに、ゲーム開始、マッチ開始、手番、結果表示、次の行動というプレイヤーの流れを整理し、初回公開に必要な画面を見極めました。
スクリーンショットから実際のUIへ
素材を作る前に、ボタン、パネル、プレイヤー情報、試合操作など必要な要素を洗い出しました。Codexで設計要件と画面イメージにまとめ、Goalモードで参考画像にできるだけ忠実なUIを実装しました。実機の画面と画像を比べ、余白や比率を何度も調整しました。
完璧になる前に公開した
粗い部分や不具合が残ったままGoogle Playへ提出しました。実際の試合から優先すべき修正が分かり、その後のバージョンを素早く公開しました。Google PlayでPool Maxをプレイできます。
低性能Android端末での課題
Godot 4版は一部の低性能端末で期待どおりに動きませんでした。そこで別の移行プロジェクトでGodot 3.6/GLES2へ移植し、Galaxy J7でテストしました。現在Google Playで公開中の製品版は、引き続きGodot 4.7.2 Compatibilityを使用しています。 3.6版はテスト済みの移行用試作で、完成した製品版を置き換えるものではありません。今後は最も性能の低い対象端末で早期に確認します。
最初からやり直すなら
UI全体を実装する前に、ボタン、カード、パネル、状態表示を共通ルールを持つ再利用可能な部品に分け、コンポーネントライブラリを作ります。そうすれば一貫したデザインをもっと早く実現できたはずです。
まとめ
3週間でPool Maxを公開できましたが、遊び心地を学び続けています。試作品はショットの楽しさを、参考画像はUIの方向性を、実機は性能の問題を、プレイヤーは修正の優先順位を教えてくれました。Pool Maxのサイトを見るか、Google Playで遊んでみてください。