CodexでUnityシューティングを制作：リフレアの設計と改善記録

Claude Codeに4本のゲームを作ってもらったあと、5本目をCodexに頼みました。できたのが、敵弾を吸収して撃ち返す縦シューティング、リフレアです。

できたものを見て、私は「すごい、Claude Codeと別次元。なぜ」と聞きました。ただ、ここでAIの勝ち負けだけを言っても、次の制作に使えません。吸収反撃のルール、画面の作り方、途中で詰まった検証を記録します。公開後に見直して直した箇所もあります。

最初に渡したのは「同じジャンルで、別ゲームを」という依頼

依頼の中心は、この一文でした。

別ゲームでいいからCodexが考えるシューティングゲームを作って欲しい

参考としてムレウチのページを渡し、成果物を比べたいと伝えました。吸収やボスを作るようには指定していません。そこはCodexが考えています。

一方、開発環境、テストの回し方、公開用スクリプト、制作ログを残す約束は、先にClaude Codeと整えていたものです。「白紙からCodexだけで全部用意した」わけではありません。

同じ仕様書で作ったブロック崩しの比較とは条件が違います。今回は、題材を任せたときに何を作るかを見る試みです。後から作る側は、それまでの失敗と道具も利用できます。

敵弾を「避けるもの」と「取りに行くもの」にした

リフレアの通常射撃は自動です。プレイヤーが考えるのは移動と、吸収を使うタイミング。敵弾が来たら避けるだけでなく、近づいて取り込む選択があります。

ここには小さな損得があります。早く押すと、弾が届く前に吸収が終わる。待ちすぎると被弾する。使った直後には次の弾を吸収できません。敵本体への接触は防げないので、吸収中ならどこへでも突っ込める、というルールにもしていません。

実装の数値は次のとおりです。記事を読んだ人が、遊びのどの部分を調整したのか追えるように残します。

反撃には、同じ敵へ当たり続けて毎フレーム4ダメージを入れないための管理もあります。貫通弾ごとに「すでに当たった敵の枠」を記録し、次の敵へ進ませる作りです。2体を貫通して倒せることをテストしています。今回は敵の配列が64枠なので、ヒット済みの印は64ビットで持たせています。

素材を増やす前に、輪郭と奥行きを作った

見た目は、画像素材を集めて組み合わせたものではありません。機体も雲もコードでテクスチャを生成しています。ただし、四角や丸をそのまま並べているわけでもありません。

自機には細い胴体、左右の翼、尾の部分があります。ピクセルを塗る際に上側を明るくし、輪郭にも明るい縁を付けています。その上に白い操縦席と青緑のエンジン光を重ねています。

背景の雲はゆっくり、施設の影は速く流れます。背景そのものに明るさの差があり、その前を自機が進む。敵を倒したときは破片が広がり、被弾時には自機と画面が反応します。効果音もコードで生成しています。

「素材なし」は見た目を省く条件にはしませんでした。輪郭、陰影、光、背景の速度差を別々に用意したことが、今回の画面の具体的な構成です。どの要素が私の印象に何割効いたかまでは測っていません。

自動で遊ばせたら、最初は24秒で負けた

ゲームのルールはUnityの描画から分離し、1回の更新を1/60秒に固定しています。自動操縦もプレイヤーと同じ移動・吸収の入力を渡します。無敵にしたり、敵を消したりしてボスまで進めているわけではありません。

ところが、最初の自動操縦は途中で負けました。敵配置を決める乱数の種を3種類に変えても、全部ボス登場前に終了しています。

この変更後、標準配置では87.23秒でボス撃破まで進みました。ここで直したのは自動操縦の判断です。人が遊ぶゲームの難しさを下げて通した記録ではありません。

ただ、自動操縦は内部の座標を正確に読めます。ボスを倒せたからといって、初めて遊ぶ人が簡単にクリアできるとは言えません。使い道は、毎回同じ条件で最後まで進め、途中の破綻や変更による差を見つけることです。

数字が通っても、ボスが隠れていた

ブラウザの65秒時点の画面を確認すると、ボスが上部の情報表示、HUDに隠れていました。ルールのテストでは勝てる。けれど、肝心の敵が全部見えていない。

位置を下げると、自機の弾も敵の弾も到達するまでの時間が変わります。見た目を直すつもりでも、戦闘の条件が変わっていました。このため、位置変更後にもう一度通しで遊ばせています。画面の修正でも、結果は測り直す必要がありました。

公開後に、予告の嘘と状態の読みにくさを直した

最初の公開ページには遊び方と数字を載せましたが、制作過程の説明が足りませんでした。私は「薄くね？ 内容」と伝え、記事を書く前に改善点も見直すよう依頼しました。

この見直しで見つかったのが、ボスの照準線です。狙撃弾は2回に1回なのに、予告は毎回出ていました。実際には来ない攻撃を避けさせる表示です。

The first volley has only fan bullets
Expected: 0
But was:  0.650000036f

修正は、予告を出す条件に「次の攻撃に狙撃を含む」を足すこと。テストも、最初の扇弾のみの回には予告が出ず、次の狙撃回には予告が出て3本の弾が発射される、というところまで確認します。

敵の数や吸収の性能は、この改善では変えていません。必要な情報を信頼できる表示にする修正です。

あわせて、最後の被弾とボスへの攻撃が同じ更新で重なる条件も検査しました。これは修正前から正しく敗北になっていました。「バグを直した件数」に混ぜず、今後その挙動を守るテストとして残しています。

どこまで確かめたか、何はまだ分からないか

初版の公開環境では、次の値を記録しました。ロード時間は3回測り、中央値を使っています。ダウンロード完了から起動までの時間と、ページを開いてからの総時間は分けました。

測定環境はWindowsのChrome、画面960×720、描画領域383×682、DPR 1です。約60fpsはこの環境の値で、低性能なスマホでの余裕を示す数字ではありません。最新ビルドの容量と検証記録はゲーム紹介ページにも掲載しています。

v1.1の自動テストはEditMode 22件、PlayMode 2件が合格しました。予告の検査を追加した直後はEditModeが21/22件で、修正して22/22件になった、という順序です。既存のテストが全部通っていたことだけでは、この問題は見つかりませんでした。

スマホ幅の確認はChromeのタッチエミュレーションです。実機での指の隠れ方、発熱、長く遊んだときの疲れは未評価。難易度も、初見の人を複数集めたテストはしていません。自動操縦のクリア記録と、人が感じる遊びやすさは分けて扱います。

私は今回の出来を見て驚きました。でも、次に引き継ぐなら「Codexの方がすごい」という一行より、何を選ばせるゲームにするか、何を画面で伝えるか、最後までどう確かめるかを残したい。リフレアでは、吸収する瞬間、遠景と機体の描き分け、ボス撃破までの通し検証が、その具体例になりました。