Codexのみを使ってPCブラウザゲームを3時間で作った

Codexのみ、58タスクでゲームを3時間で開発した

Devinに似たCodexが使えるようになっていたので、Codexのみでゲームを開発するという縛りで1本開発してみた記録です。
自分でコードは一才書かず、ローカルで触ってはタスクを追加していたのみ。
1つのタスクは2-5分くらいでPRが生まれてはマージを繰り返していた。
Devinと違い研究プレビュー中で追加費用一切かからないのでひたすらタスクを投げていた。

思ったよりうまくいったので開発の記録を書きます。

Codexのタスク一覧

Codexで作られたPR一覧。Codexのタグが自動で振られる

終わらないバグ潰しを終わらせるシューティングゲーム『Bug Shooter』

こちらから遊べます。
https://bug-shooter-game.pages.dev/

• バグを潰したらデグレする
• 大きなバグを放置すると新たなバグが生まれる
• バグが多い中で実装しているとバグにぶつかる

中でバグを潰しまくり、バグを全て潰すゲームです。
普通にバグを潰していると、バグは減るどころか増えていきます。
バグを効率よく潰すのには、技術書をちゃんと読んで勉強するの大事だよね。

Codexのみで0->1で開発する上で大事なこと

Codexで0->1の開発は難しいと言われていることがある。
これはよくある誤解の1つだと思っていて、「バグ潰しをコンセプトにしたシューティングゲームを作って」みたいな雑な依頼をしてもCodexに限らず上手くタスクを処理することはできない

これは人間のエンジニアでも同じはず。
ある程度空気読んで作ることは行うが、指示が曖昧であれば曖昧なものを作るし、プロフェッショナルとして得意なのは決まったものを精度高く開発することのはずである。

CodexはPdMではなく1実装エンジニアとしてコミュニケーションすべきである。

作りたいもののコンセプトを明確に言語化する

業務であれば、PdMがまずプロダクトのコンセプトおよび仕様書を作成し、エンジニアに共有して開発がスタートするはず。
これはCodexでも同じで、「なんかいい感じのシューティングゲーム作って」とPdM業務を放棄した状態で依頼してもプロダクトは完成しない。
LLMを頼りながらでいいので、今作ろうとしているものがどんなコンセプトでどんな機能を有するべきなのかは明確に定義して、レポジトリ内にドキュメントとして配置すべきである。

技術要件は事前にLLMと対話して決める。Codexに託さない

「いい感じに選定して環境構築して」とCodexに投げることは出来るが、出力の幅が大きくぶれてしまう。
今回のPCブラウザゲームで言えばUnityで作ることもできるし、ブラウザのライブラリで実装するとしても、Kaboom.js、Kiwi.jsなど複数の選択肢が出てくる。

(ChatGPTで事前に対話、出力したもの)

エンジン／ライブラリ	特徴	向き・不向き
Kaboom.js	- わかりやすい API（add(), sprite(), onCollide() など） - 組み込みのアセットローダー／アニメーション／サウンド - TypeScript 型定義同梱 - 軽量＆ホットリロード対応	◎ スプライト主体のシューティングを最短距離で作りたい △ タイルマップ機能は不要
Kiwi.js	- フル機能のシーン管理／物理エンジン - TypeScript サポートが充実 - モジュール設計でカスタマイズしやすい	◯ 少し大規模なコード構造をきっちり組みたい場合 △ 学習コストはやや高め
Kontra.js	- js13kGames 由来の超マイクロライブラリ（<10 KB） - ゲームループ・スプライト・入力・当たり判定を必要最小限で提供	◯ とにかく軽量かつ最小限で自前実装したい場合 △ アセット管理やシーン管理は自前で組む必要あり

ChatGPT等と事前に利用技術について議論し、環境構築する技術スタックを事前に明確に決める必要がある。
今回は

• Kaboom.jsを使う
• Viteを使ってローカルでホットリロードできるようにする
  • Codexが実装してマージした際、mainをpullすれば最新版が遊べるように
• 静的ホスティングする前提でビルド環境を整える

要望をChatGPTになげ、出力されたものを元に環境構築をさせた。

具体的に開発で行ったこと

ここからは実際に実装にあたり行った手順を記載する。

①作りたいゲームのコンセプトを人間が事前に定め、READMEに記載させる

ゲームの仕様がブレるとCodexに依頼する中で仕様がブレるため、最初にしっかり決め切った。

今回でいえば、

• 100件のバグを潰し切るまでの時間を競うシューティングゲームであること
• 敵には3種類あり、それぞれ振る舞いが違い増殖すること

をコアにぶれさせないようにした。

なお、最初にREADMEを書いておくと、Codexへの他のタスクを実行する際も「READMEを読んだ上で実行して」といえば作っているゲームの概要を手軽に把握させられて良い・

ChatGPTに最初に与えたプロンプト

静的ビルドでwebブラウザゲームを作ります。
2Dで見た目も楽しいシューティングゲームです。エンジニアがバグをシューティングしながらプロダクトの完成を目指すゲームです。
なのでコードエディタライクな世界観で、流れてくるソースコードっぽいオブジェクト群に対してシューティングしていくわけだけど、バグの修正点を的確に打ち取る必要がある
・間違って修正する(正しいところを攻撃してしまう):バグがまた発生。減点
・デグレ：打ちどころが悪くて他のところが壊れてしまって減点
のように、実際のバグ潰しでよく起こるシチュエーションを打ち取っていきたい

READMEに記載したもの（対話しながら追加要素を入れた）

## ゲーム概要

エンジニアがコード空間に潜むバグを銃で駆逐するタイムアタック型シューティングです。マップ上には合計100個のバグが点在しており、すべてのバグをゼロにするまでの時間を競います。画面は固定マップでスクロールはありません。プレイヤーは小さなロケットを操作し、遅めの移動速度でマップを行き来しながらバグを撃破します。

### バグの種類

- **赤 (シンプルバグ)**: 小さいバグ。1発で倒せます。
- **黄色 (デグレバグ)**: 大/中サイズがあり、倒すとさらなるバグを生成します。
  - 大サイズを倒すと中サイズの黄色バグ3体がランダムに出現。
  - 中サイズを倒すと赤バグが近くに1体、遠くに2体ランダムで湧きます。
- **紫 (大きなバグ)**: 特大サイズで複数回攻撃が必要。5秒ごとに赤バグを1〜2体発生させ、倒すと中サイズの黄色バグ2体を生み出します。

バグを倒す順番や移動ルートを工夫しないと、連鎖的にバグが増殖してしまいます。いかに移動を最小限に抑え、効率良く全滅させるかがポイントです。

### 操作方法

 - **移動**: WASD または 方向キー
 - **攻撃**: スペースキーで射撃（押し続けて連射）

### クリア条件

残りバグ数が0になった瞬間にタイマーが停止し、その時間がスコアとして記録されます。短いほど高スコアです。

　

②環境構築だけを行うタスクの実行

事前にChatGPTと会話して決めた技術セットを元に環境構築をやらせた。
ローカルに落として動かしてみたが問題なく初期化が行えていた。

Codexのタスク

PRの内容

# 技術選定一覧

## プログラミング言語
- **TypeScript**
- **Node.js LTS** (例: Node 18 以上)

## パッケージマネージャ
- **npm** もしくは **yarn**（お好みで）

## ビルドツール / バンドラ
- **Vite**
  - HTML / CSS / TypeScript をまとめて簡易ビルド
  - ローカル開発用の高速サーバ機能 (ホットリロード)

## ゲームライブラリ
- **Kaboom.js**
  - 2D シューティングに必要なスプライト管理 / 衝突判定 / アニメーション / 入力 / サウンド等

## リンター / フォーマッター
- **ESLint + Prettier**
  - コード品質・コーディングスタイル統一

## 開発用サーバ / テスト実行
- **Vite の Dev サーバ**（ホットリロード付き）
- （ユニットテストが必要なら）**Vitest もしくは Jest**
  - 簡易テストを入れる場合にのみ導入

## 静的ホスティング
- 任意で **GitHub Pages / Netlify / Vercel**
- `npm run build` or `yarn build` → `dist` ディレクトリのアップロード

---

# フォルダ構成（例）

my-kaboom-game/
├─ package.json
├─ tsconfig.json
├─ vite.config.ts (または js)
├─ .eslintrc.js (または .eslintrc.json)
├─ .prettierrc
├─ public/ # 画像・音声など静的ファイル
└─ src/
├─ main.ts # エントリーポイント
├─ scenes/
│ ├─ titleScene.ts
│ └─ gameScene.ts
└─ assets.ts # loadSprite(), loadSound() などまとめ

③シューティングゲームとして最低限動作する状態を作る

まずは最低限動作する状態を作ると、あとは改善タスク依頼->確認->次の改善というサイクルに入れる。

• Codexは1回で大規模なタスクを完遂できるわけではない
• 環境構築は往々に失敗する

ことを踏まえ、スコープを大きく絞って動く状態を最初に作ることが大事。

まずはゲームコンセプトを記載の上機能実装まで依頼してみる

1回でできることはまずないだろうが、一旦依頼していみる。

画面が真っ白問題などの不具合を潰す。最小限動作するようにさせる

案の定プレイ画面どころか画面が表示されなかったので修正依頼を何本か投げた。
修正依頼文はChatGPTに補強してもらった。
10タスク弱で最小限のシューティングゲームとして動くようになった。

④ゲーム要素を1つずつ改善していく

ここからがCodexで開発する醍醐味となる。
個人開発であれば時間がかかるこだわりポイントを要件だけ投げればすぐに完了する。

プレイヤーの動作に加速度と慣性の法則を入れる

機械的な上下左右移動よりもロケットのような動きにしたかったため依頼。1発で上手くいった

バグをふよふよ浮かせる

動いている方がバグっぽいし、2Dゲームなりにリッチな見た目になる。

なお、バグの種類によって動作が異なってしまっていたので修正依頼をした。
この間、自分はローカルで動かして不具合を指摘したのみである

バグ同士を反発させる

バグが画面上に多数表示されるため、それぞれがインタラクションされていて欲しい。
ぶつかったら反発するように指示した。生成タイミングで重なってしまった場合の動作が若干期待通りではないが、やりたかったおおよその体験はできているため許容した。

バグがバグから生まれた様子が分かる演出にする

黄色・紫のバグがバグを一定間隔でうむのだが、バグが生まれるだけでは、どこからバグが来たのか分からない。
発生時に元のバグから移動する形で発生するように指示した。
自分で実装するなら割と面倒な計算なので諦めてしまっていたかもしれない。

一定時間立つと技術書が出てきて、弾幕が増える

「バグが全然潰せないけど、技術書読んで技術力上げたらバグが潰せるようになる」体験が面白いのではと思って追加してみた。
2,3タスクでサッとできたので簡単に追加できた。この間ローカルで触って、表示順序や動作について少々指摘したのみである。

最初はReadable Codeを追加して、良かったのでclean architectureも追加することにした。

⑤成果物をCloudflareにデプロイ

Cloudflareは無料で静的ファイルをホスティングできる。
完成したGitHubレポジトリをCloudflareに紐付け、ビルドコマンドを指定したら簡単に公開できる。
https://bug-shooter-game.pages.dev/

Codex全体の所感

作るもの・利用技術等は明確にテキストで指定する方がいい

要件を満たす面白い・便利な機能を考え自分で実装するのは別に得意ではないし、1タスクでやれる物量は限られている。
作るべきものを明確に与えた上ではコーディングは比較的スムーズにやってくていていた印象がいい

各タスクで環境構築、実際に実行して開発してくれているのは良い

タスク実行内容を観察していると、レポジトリの取得、環境構築、実行を一通りやっている。
よくChatGPTにコードの出力依頼だけすると動かないコードやコマンドを出力してくることがあるが、実際に実行するしエラーがあれば修正してくれるので環境構築の精度は高かった。
ただし、今回のブラウザゲームの1機能のような、コンソール上で実行・検証できないものについては人が触って指摘しないと直すのが難しいと勘いた。

(0->1で作る場合は)環境構築タスクを最初にやるのが良い

1タスクでやれる物量は限られているゆえ、機能実装まで含めて1回でやるのはやはり難しく感じた。
最初の方のタスクではまずは環境構築に集中してタスク依頼を投げ、手元である程度動作するようになってから具体の実装タスクを依頼するのが良い。

依頼するタスクを小さくする。数を依頼して目的を達成する

一番汎用的な振り返りはこれである。
Codexは作業物量が大きい作業を1回でやることはできなく、途中かつ要件を大幅に落とした状態で終了してしまう。
おそらく1タスクあたりの実行時間やステップ数に制限があるように感じる。

そもそも自立型のAIはタスク途中で方向性の確認が難しい分、意図しないタスク結果になりやすい。
小さいタスクに分解し、小さく成功を重ねて求める結果を得るのが良い。