こんにちは。最近、ひとりで『スンビ』というモバイルゲームを作りました。済州島の海女の素潜り漁に着想を得た縦画面ローグライクです。ひと息で海に潜って海産物を採り、もう少し欲張るか、今戻るかを判断するゲームです。
7月2日に設計を始め、7月9日にGoogle Playへ最初のビルドを上げました。その後、プレイしながら気になった部分を直し続け、7月19日にはv1.1ビルドまでプロダクションにアップロードしました。
最初から気になっていたのは、単に「AIがコードをどれだけ速く書けるか」ではありませんでした。複数のAIモデルに異なる役割を与え、ひとつの開発チームのように動かしたら、実際にリリースできるゲームをどこまで作れるのか。それを試してみたかったのです。
どんなゲームか
『スンビ』は、海女が素潜り漁を終えて水面に上がり、笛のように吐く息「スンビソリ」に由来する名前です。
1プレイは10〜30秒ほどです。片手で海女を動かして、より深く潜ったり、周囲の海産物を採ったりします。無事に水面までたどり着かないと採集物をすべて持ち帰れないため、もう少し欲張るか、今戻るかを常に天秤にかけることになります。浮上したら採集物を精算し、肺活量、フィン、網袋、観察眼を強化して、また潜ります。
各プレイで3つの能力から1つを選ぶローグライクドラフト、60種類の海産物図鑑、装備と成長ツリー、海女ランクの昇格、100mまで続くスムゴルを入れました。操作はシンプルにしつつ、潜水を繰り返すほど狙う記録やビルドが変わるようにしました。
AIをひとりの万能開発者として使いませんでした
ひとつのモデルに設計から実装、自己検証まですべて任せると、自分の前提をそのまま正解として扱いがちです。そこで役割を次のように分けました。
- Fable 5：ゲーム構造と機能仕様、経済バランスの目標、完了条件の設計
- Opus 4.8：Flutter・Flame実装、テスト作成、デバッグ
- Fable 5：最初に書いた仕様と実装結果を再照合し、漏れとリグレッションを確認
- Codex GPT-5.5：コードと差分を独立してレビューし、エッジケースを指摘
作業順序はおおむね 設計 → 実装 → 元の設計者による再検証 → 独立コードレビュー → 自動テストと実機プレイ でした。
やってみると、プロンプトを巧みに書くことよりも、検証可能な完了条件を先に決めることのほうが重要でした。「成長感を良くして」ではなく、最初の10分間の購入回数、最初の昇格までにかかる時間、どの成長区間でも何も買えない時間が長く発生しないか、といったことを数値で定めました。そのうえで経済シミュレーターとテストで確認しました。
現在、自動テストは627件あり、すべて通過しています。Flutterの静的解析も、アプリコード・テスト・ツールの範囲でエラーなく通過しています。
AIがもっともらしく間違えた例
最初の設計がそのまま面白いゲームになったわけではありません。
初期バージョンでは、1プレイで採れる対象が5〜9個しかありませんでした。採集ゲームなのに海が空っぽに見えました。実際に遊んでみて、この構造は捨てました。成長するほどフィールドが豊かになり、採った場所にはまた海産物が育つように変えました。特定の成長ビルドでは、1プレイで約40個まで採れます。
成長ツリーも同様でした。ノードは290個もありましたが、実際のプレイは一直線に近いものでした。AIは「ノード290個」という要求は満たしましたが、選ぶ楽しさまで作れたわけではありませんでした。最終的に、3つの特化ルートと永続ノード構造を改めて分けました。
AIはコードを速く大量に作れますが、面白さや優先順位まで保証してくれるわけではありませんでした。実際にプレイしながら「これは面白くない」「機能は多いのに次の目標が見えない」とはっきり切り分ける作業は、今も人間の役割でした。
画像とサウンドも自前でパイプラインを作りました
海女キャラクター、海産物、装備、カードアイコンのような主要な画像アセットは、GPT画像生成APIで作りました。生成されたシートをそのまま使うのではなく、クロマキー除去、フレーム整列、サイズ統一、ピクセル量子化を行う補正パイプラインに通してから確認しました。背景や気泡、光の筋などはほとんどコードで描きました。
サウンドは外部アセットを集めるのではなく、DartコードでWAVを合成しました。潜水が終わるときに聞こえるスンビソリは、ゲーム名と1プレイの終わりが交わる中核的なサウンドとして位置づけました。
作ってから変わった考え
よく「AIはうまく指示すればうまくやる」と言われます。今回はそれ以上に、「間違えたときに見つけられる構造が必要だ」ということを強く学びました。
設計者、実装者、検証者を分け、別のモデルに計画とコードを厳しめに見てもらいました。最後の判定は数値とテスト、実際のプレイに任せました。この方法は、ひとつのモデルと長い会話を続けながらすべて任せるより、はるかに安定していました。
AIが速くなっても、ひとり開発のボトルネックはなくなりませんでした。代わりに、ボトルネックの位置がコーディングから判断へ移りました。何を残し、何を捨てるのか、なぜ今面白くないのかを決める作業に最も時間がかかりました。
Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi
まだひとりで作ったゲームなので、不足している部分がたくさんあります。面白くないのか、成長メニューが複雑すぎないか、意見を聞きたいです。開発方式やモデルごとの役割分担に関する質問も、気軽に残してください。
まだコメントはありません。