前回のスマホでもサクッと遊べるローグライトFPSがやりたかったので作った の続きで、Sector Dive を作ったときの話。
前回の記事でも言及したように、このゲームの実装は Claude Code に任せていて、自分の手は動かしていない。
( 冒頭のトレイラーも言ったら作ってくれた PR )
やったことは、出来たものをプレイして感想を返すことと、ルールやゲームの構成、作りの方針について相談しつつ決めていくこと。
ざっくりと、どのように開発が進んでいったのかを振り返ってみる。
思いつきを動く状態で実装してもらった
ふと思いついて、以下のプロンプトをClaudeに投げてみたのが始まりだった。
コーデッドアームズみたいなランダム生成のfps ブラウザ上で動く 武器種、ボスを数種、ステージのニュアンスを複数種で セーブを保持して繰り返し潜れる ルートアイテムか、持ち込み可能な強化、拠点強化の仕組みを作って繰り返しプレイ可能とか これをスマホで操作できる3Dの単ページ完結のゲームって作れるもんなの？
「作れるよ」と返ってきたので試しに作ってもらうと、15分ほどで現在のゲームの原型が出力された。
プレイしてみると思いのほか面白く、そこからは遊んで気になったことを伝えて直してもらう、というのを繰り返した。
例えば、
- 敵の硬さやアップグレードのバランスに「強すぎる」「物足りない」と返す
- ボスを倒したら進むか戻るかを選べて、ロストがある、というルールを足してもらう
- スマホ操作、全画面、ボタン配置の編集を足す
など。
ファイル分割と仕様書
フィードバックを続けて、ステージやボスの数が増えてくると、それまでの1枚の HTML に全部押し込む形では内容が追いづらくなった。指示だけで修正していると、意図しないバグやデグレが混入する。そのうえ、何が原因で壊れたのか、どう直せばよいのかも分かりづらくなってきた。
そこで、ファイルを分けて、仕様書を作ることにした。仕様書には、数値や挙動などの仕様と、該当するコードの場所を書かせている。
仕様書を起こして正しい挙動を明示する、というのはこちらの指示だけど、それを受けて Claude が勝手にスモークテストを足していたのにはびっくりした。URL に #smoke を付けて開くと、全ステージと全ボスを自動で一周して、段差で詰まらないか、部屋を行き来できるか、中断して再開できるか、などを確かめてくれる仕組み。これを変更のたびに流して、テストが落ちたら自分で原因を調べて修正もしてくれていた。
自分が遊んで見つけた不具合を伝えると、同様にスモークテストに追加されていたので、基本的に壊れることを考えずにプレイしてフィードバック、という感じで回せていた。
engine の切り出し
指示を出しながら、たまに実装を覗いたりコミットの差分を眺めたりしていたんだけど、ロジックとデータが同じファイルに配置されていたり、散らばっているものが同時に修正されているのが目につくようになってきた。
また、AIに指示を出しながら作っていく、という体験が面白かったので、別のゲームも作ってみるかもな、ということも考えていた。
そこで、以下のような変更を加えた。
- 敵キャラやアイテムの内部データ定義をデータ用のフォルダに集める
- Unityをイメージしてゲームのメインループと実行される関数を切り離し、コア部分を
engine/として切り出した - JavaScript から TypeScript と ES モジュールに移行した
engine からゲームは import しない、という向きにして、ゲーム側のデータや処理は、登録する形で engine に渡す。挙動に変更を与えずそれぞれのリファクタを行う際にも、スモークテストが通ることを確認できたので安心して進められた。
最終的には、こういう2層になっている。
人に遊んでもらう
GitHub Pagesに置いて公開し、宣伝してみたところ、何人かの人に触ってもらえた。一部のフォロワーが結構な高難度まで遊んでくれて、感想やバランスへのフィードバックをくれている。動作確認では見られていないレベルのボス戦の難易度や、強化を進めた時の挙動の不具合など。こういう報告をまたClaudeに投げ、原因を調べたり直し方を考えながら改善を進めていった。
せっかく遊んでもらえているので、実験的にこのあたりを足している。
- 結果画面から、プレイデータを記入済みの状態で開ける感想フォーム
- GA4 でのアクセス解析
- テストが通らなければ公開しない仕組み
- コミットには更新履歴用の一行を付け、更新履歴を自動生成
書き方をそろえる
最初は1つのセッションでそのまま実装を進めていたのだけど、思ったよりコードベースが大きくなってきた。そこで、計画とレビューはメインのセッションで、手を動かす作業はサブエージェントで並行して進めるようにした。
サブエージェントには Sonnet や Haiku などを使うようにしていたので、実装の質が落ちないように、仕組みの側で担保するようにした。
- 何でも入る型や
!を減らし、型をつけるようにした - 決まりは
STYLE.mdにまとめ、機械で確かめられるものは lint にして PR の CI で止めるようにした - 独自の仕組みで回していたテストを Vitest に移して、1件ずつのテストとして CI で結果を見られるようにした
読みやすさと状態の管理
書き方をそろえても、コードの読みやすさはまだ低いままだった。そこで、書式とファイルの分け方、名前を整理した。
- 書式を Prettier でそろえ、大きいファイルを役割ごとに分ける
- 人間には理解しづらい短い変数名や略称を、意味の分かる名前にする
あわせて、ゲームの状態の持ち方も見直した。データを書き換えられる入口を狭めておけば、ゲームの状態を管理したり確認したりするコストが下がる。ステージも、データを生成する部分と、それを組み立てる部分を分けておけば、テスト用のデータを差し込んで同じステージを再現できる。
- セーブを書き換えてよい場所を決めて、それ以外の箇所から書き換えると ESLint で落ちるようにする
- ステージは乱数のシードから作り直せるようにして、固定のマップも差し込めるようにする
動作や書き方についても、少しずつ機械に任せる範囲が広がっていった。最初はスモークテストを流して結果を見る形だったのが、今は PR を作ると型チェック・lint・テスト・ビルドが流れて、マージするともう一度同じ確認をしてから公開される。
作ってみて
どういう物を作りたいか、という部分は自分で考えつつ、細かい部分の調査や検討は Claude に案を出してもらい、判断を下すとゲームが出来ていく。ゲーム制作をしたことのない自分の手元でここまで動くものができる、というのは今まであまり味わったことのない楽しさがあった。
流用できそうなパーツも切り出したので、新しいゲームや別ジャンルのものもまた作ってみたいと思う。
