設計書ができてから、実装は今回もいつも通り「フェーズ分け」で進めた話

かずゆきです。

前回、「ゾンビを撃つゲーム」が、気づいたら「光を届ける迷子の話」に変わっていたという記事で、設計書ができるところまで書きました。

この続きです。設計書を持ってClaude Codeに移り、実際にXcodeプロジェクトとして手を動かし始めました。今回は、その実装フェーズで何が起きたか、なるべくそのまま書いてみます。

結論から言うと、特別なことは何もしていません。普段のAI開発と同じで、「フェーズを細かく切って、一つずつ確認しながら進める」を、今回も当たり前にやっていただけです。

全部一気に作らない、が当たり前になっていた

設計書を作っている段階で、実装の順番を「フェーズ」として先に決めておきました。基盤 → 1体との戦闘 → Wave進行 → HP・ゲームオーバー → 画面遷移 → コンボ、という具合です。

これ、今回改めて「よし、フェーズを切ろう」と意識して決めたわけではありません。普段からAIと一緒に開発することに慣れているので、細かく区切って一つずつ確認しながら進める、というのがもう当たり前のやり方になっています。今回もその延長で、自然とフェーズに分けていました。

このフェーズ分けのやり方自体、実はClaude Codeのskillとして仕組み化しています。毎回ゼロから「どう分けようか」を考えるのではなく、型として持っておくことで、迷う時間を減らせています。

振り返ってみると、フェーズを細かく切っておいて良かったと感じる場面が何度もありました。

理由は単純で、1フェーズごとに「完了条件」を先に決めておくと、後から自分でサボれなくなるからです。「タップ→Wave進行→被弾→ゲームオーバー→リトライが一周する」のように、動作として確認できる条件を先に書いておく。すると、なんとなく動いている状態で次に進む、ということができなくなります。

数字が合わない、を見つけられたのはテストのおかげ

コンボのフェーズで、地味に印象に残るバグに当たりました。

コンボ倍率をスコアに反映する処理で、Double型の小数(0.05倍、みたいな数字)をそのまま掛け算していたら、特定の組み合わせ(コンボ3・Wave5)でスコアが1点だけ低く出る、という現象が起きました。

原因は、0.05という数字が2進数の小数では正確に表現できないことでした。人間の感覚だと「0.05を3回足したら0.15でしょ」と思うんですが、コンピュータの内部では微妙にズレた値になっていて、それを四捨五入すると本来より1点低い数字が出てしまう。

これ、目視のテストプレイだと絶対に気づけないやつです。「57点と58点、どっちが正しいか」なんて、遊んでいて分かるはずがありません。今回は先にテストを書いていたので、「期待値と実際の値が違う」という形で機械的に発見できました。直し方も単純で、倍率を小数のまま扱うのをやめて、「20分の何」という整数の比率で持つように変えただけです。

「見た目では絶対気づけない種類のバグは、テストでしか捕まえられない」というのを、今回身をもって理解した気がします。

均一化ロジック、数字にしてみたら想像以上だった

もうひとつ、実装して良かったと思ったのが「敵の移動速度を均一化する」処理です。

横長の画面だと、拠点(自分)から画面の上下までの距離と、左右までの距離が全然違います。何もしないと、「上から来る敵だけ理不尽に遠くて、結果的に遅く感じる」みたいな不公平が起きます。

これ自体は設計段階から想定していたんですが、実機で計測してみて初めて、その差の大きさに驚きました。補正なしだと、上下からの到達時間が11.4秒、左右が21.8秒。ほぼ倍近い差です。出現距離に応じて速度を補正するロジックを入れたら、この差は1.04倍まで縮まりました。

数字にしてみるまで、ここまで極端だとは思っていませんでした。「なんとなく不公平な気がする」で終わらせずに、実際に測ってみるとこんなに差があるんだ、というのは今回の発見です。

「後から足す」を許さなかった判断

もうひとつ書いておきたいのが、敵のタイプを増やすフェーズで決めたことです。

色覚の多様性に配慮した見た目の作り分け(色相だけじゃなく、体型や輪郭の光り方でも敵の種類が分かるようにする)を、「後から追加」ではなく、敵タイプを増やすのと同じタイミングで一緒にやる、と決めました。

理由は、後付けにすると描画コードの書き直しになるからです。1種類だけ先に作り込んでしまうと、後から他のタイプとの見た目のバランスを取り直す二度手間が発生する。だったら、5種類まとめて造形し直したほうが、結果的に早い。

これも「今は後回しでいいや」が一番高くつくパターンだったので、記録として残しておきます。

得意なところと、そうじゃないところ

ここまで結構それっぽく書いてきましたが、正直に書いておきたいことがあります。

テストプレイ、毎回わりと真剣にやってしまいます。「Wave 10まで通しで」「速度倍率の上限・下限、体感どうか」みたいなことを、自分でも謎に集中してやっています。ただ、やっている内容そのものは、正直素人丸出しです。

一番わかりやすいのが、レベル設定(敵の強さの上がり方、出現数のバランスなど)です。ここ、感覚的にどう決めればいいのか全然わからなくて、ほぼAI任せになっています。数値をもらって、動かしてみて、「なんかちょうどいい気がする」で判断している。ここは、ゲーム開発を本業にしている人や、ゲームを遊び込んでいる人には絶対に敵わない部分だと思います。経験がものを言う領域だな、と痛感しています。

一方で、テストを先に書く、フェーズごとに完了条件を決める、設計書とコードの数値を一致させる、みたいなところは、業務アプリの開発とやっていることがかなり近いです。ここは経験があるので、迷わず進められます。

あと、AIと一緒に開発すること自体には慣れているので、細かくレビューを挟みながらコツコツ進める、というやり方は自分に合っている実感があります。ゲームデザインのセンスがなくても、「一歩ずつ確認しながら積み上げる」やり方でなんとかなっている、というのが今のところの実感です。

得意なところで支えて、苦手なところはAIに預ける。今回のプロジェクトは、そのバランスの取り方の練習でもあるなと思っています。

現在、基盤・戦闘・Wave進行・HP・画面遷移・コンボまでが完了しています。次はアイテムとインベントリ、敵タイプの拡張、そしてサウンド・IAP・広告まわりと続いていきます。

地味な作業が多いフェーズですが、進捗はまたここで書いていこうと思います。

#AI #生成AI #ChatGPT #ClaudeAI #ClaudeCode #人工知能 #AI活用 #AIツール #AI開発 #AIで仕事 #プロンプトエンジニアリング #AI時代 #AIリテラシー #壁打ち #AIと壁打ち #AIとものづくり
#プログラミング #プログラミング教育 #コーディング #独学プログラミング #プログラミング初心者 #プログラミング学習
#個人開発 #アプリ開発 #ソフトウェア開発 #エンジニア #駆け出しエンジニア #テックブログ #ノーコード #ローコード
#iOSアプリ #iOSアプリ開発 #Swift #SwiftUI #SpriteKit #アプリリリース #AppStore #スマホアプリ #個人アプリ開発 #アプリ制作 #モバイルアプリ
#ゲーム制作 #ゲーム開発 #インディーゲーム #ゲームアプリ #ゲームプログラミング #個人ゲーム開発 #ゲームデザイン #ゲームバランス #レベルデザイン #キャラクターデザイン #世界観設計 #ストーリー設計 #ネーミング #タイトル決め
#UI #UX #タップ操作 #当たり判定 #年齢レーティング #ゾンビゲーム #カジュアルゲーム #スマホゲーム #ゲーム好きと繋がりたい
#テスト駆動開発 #ユニットテスト #ソフトウェアテスト #QA #デバッグ #バグ修正 #フェーズ管理 #開発プロセス #開発フロー #仕組み化 #スキル化 #リファクタリング #品質管理
#プロトタイプ開発 #プロトタイピング #企画から実装まで #ものづくり #ものづくりの記録 #作りながら考える #試行錯誤 #トライアンドエラー #デザイン思考 #意思決定 #やらない判断
#起業 #個人事業主 #フリーランス #副業 #コンサルティング #ビジネス #働き方 #セルフブランディング
#note更新 #note毎日更新 #note #エッセイ #日記 #ブログ #コラム #ライフログ #気づき #学び #挑戦記録 #挑戦 #成長記録 #やってみた #実験 #継続は力なり #新しいことに挑戦 #テクノロジー #開発日記 #ジブンコード