Codexでブラウザゲームを作る準備｜AGENTS.mdと最初の実装範囲

最初の完成範囲は、一つの操作と一つの結果

たとえば落ちてくる物を避けるゲームなら、左右移動、障害物一種類、接触で終了、再挑戦の四つを最初の範囲にします。ショップやランキングを先に足すと、動かなかった原因が入力なのか通信なのか判断しにくくなります。まず一回のプレイが成立する土台を作り、その後に要素を増やす順番を決めましょう。

対象端末も先に書きます。パソコンの矢印キーだけで始めるのか、スマートフォンの左右ボタンも必要なのかで、画面と入力処理が変わります。「スマホ対応」という短い言葉だけでは、縦画面、横画面、画面の回転、指を離したときの扱いまで伝わりません。初期版で確認する条件を具体的に選びます。

ゲームの難しさについては、敵の速さや残り時間を編集できる場所を一つにまとめるよう依頼すると、後から調整しやすくなります。完成条件を「面白いこと」だけにすると確認が曖昧です。三十秒間操作できる、接触で結果画面が出る、再挑戦で得点が戻る、という観察できる条件を添えます。

AGENTS.mdには、毎回必要な約束を残す

OpenAIのAGENTS.mdの資料では、プロジェクトに関する追加指示をファイルで与える仕組みが説明されています。ここから先の内容は当ブログの書き方の提案です。使っている言語、起動方法、変更してよい場所、確認方法を短く書けば、別の日に作業を再開したときも前提を共有しやすくなります。

長い企画書をすべて入れる必要はありません。ゲームの全ステージや台詞は別の仕様書に置き、AGENTS.mdにはその場所を記します。たとえば「入力とゲーム状態を分ける」「新しい素材は出典を記録する」「変更した操作をブラウザで確かめる」といった、作業をまたいでも必要な決まりを選びます。

起動やテストの命令は、実際のプロジェクトで使えるものを書きます。存在しないコマンドを一般的な例から写すと、確認できたように見えてしまいます。また、公開前の確認が必要な制作なら、ローカルでの修正と公開作業の範囲を区別します。権限の設定と制作上の約束も、それぞれ確認します。

# 制作の約束の例
- 起動方法と検証方法は package.json を確認する。
- 入力、ゲーム状態、表示の責務を分ける。
- 初期版は一画面と再挑戦まで。
- 素材の出典と利用条件を記録する。
- 変更した操作を画面で確認し、未確認の条件を報告する。

依頼文に、既存コードと受け入れ条件を添える

途中まで作ったゲームを修正するときは、作り直しなのか既存機能への追加なのかを明記します。現在の入力処理や画面構成を確認してから変更するよう依頼し、使っているライブラリを無断で入れ替えない方針も必要に応じて添えます。コードの量より、今回の変更範囲が読み取れることを重視します。

依頼の例は「左右移動の速度を調整できるようにしてください。現在の再挑戦と得点処理を確認し、入力を押し続けた場合と離した場合を確かめてください」です。変更する対象、引き継ぐ振る舞い、確認する操作が入っています。追加したい演出の画像があるなら、機能の参考か見た目の参考かも伝えます。

返答では、何を変更したかだけでなく、どの確認を実行したかを読みます。ビルドが通ったことはコードをまとめられた証拠ですが、スマートフォンで指を離した後に停止する証拠にはなりません。確認していない部分が分かれば、次に行う検証を狭く決められます。

動いたら、境界と再挑戦を確認する

最初の画面が表示できた後は、端まで移動する、開始を連続で押す、結果画面でキーを押す、再挑戦を続ける、といった境界の操作を試します。通常の一回だけでは、タイマーが重複したり、前回の敵が残ったりする不具合を見落とします。失敗した操作は順番を記録し、同じ条件で修正を確かめます。

AIへの追加依頼も、一つの観察結果に絞ると説明しやすくなります。「三回再挑戦すると敵が速くなる。各回の設定値は同じ。再挑戦時に更新処理が重複していないか確認してほしい」という形です。原因を決めつけず、再現手順と期待する状態を渡します。修正後は同じ三回を試しましょう。

遊び心地は、自分で触って選ぶ工程を残します。移動の軽さ、失敗した理由の分かりやすさ、次の挑戦までの待ち時間は、仕様を満たしただけでは決まりません。本記事は特定のモデルの速度や完成率を測定した比較ではありません。まず小さな完成を見て、足したい体験を判断するための制作手順です。