モンスターの体を描き直したら、先週作ったばかりの演出が飲み込まれて見えなくなりました

（実況中継 No.5）

かずゆきです。

前回の記事です。

前回までで、アイテムとインベントリが入りました。ここまではモンスターが1種類だけで、「どう気持ちよく倒すか」の話でした。今回から「どれから狙うか」が入ります。

• モンスターを1種類から5種類に増やしました

• その5種類の体を、まとめて描き直しました

• 実機で触って、作ったものを自分から取り下げる判断が続きました

やり方は前回と変わりません。設計書を Claude Code に書かせて、Codex にレビューさせて、実装させて、またレビューさせます。私はコードを読みませんし、書きません。実機に入れて遊んで「なんか違う」と言うのが私の主な役割です。

フェーズ6を3つに割りました

6A でランナー（速い）とタンク（大きくて硬い）、6B-1 でジグザグ（蛇行する）とチャージャー（溜めてから突進する）、6B-2 で5種類の体を描き直す、という順です。

振る舞いと見た目を同時に触ると、おかしくなったときにどちらが原因か分かりません。前回アイテムを 5A / 5B に割ったのと同じ理由です。

タンクが弱かったのは、硬さでも遅さでもありませんでした

タンクは HP 2.4倍・サイズ 1.55倍・速度 0.55倍で作りました。数字の上ではミニボスです。

実機で遊んで「タンクは遅いし弱い」と伝えました。このときは私も数字の話だと思っていて、頭にあったのは「HP をもっと大きくするか、速度を上げるか」くらいです。

返ってきたのも速度の案でした。0.55 は遅すぎてこちらに時間を与えるだけになっている、という説明で、0.75 に上げました。そこは良くなりましたが、まだミニボスにはなりません。

もう一度遊んで、今度はこちらから言いました。原因は硬さでも速さでもなく、頭に当たれば一発で消えることではないか、と。

このゲームは頭に当てると会心の一撃になって、相手はそこで倒れます。タンクはサイズが 1.55倍なので、頭も 1.55倍の大きさです。しかも遅いので狙う時間もたっぷりあります。HP をいくら積んでも「大きくて狙いやすい的」のままでした。数字を動かしても手応えが変わらないので、数字ではないところに原因があると考えるしかありませんでした。

そこからは早くて、タンクへの会心だけ、一撃で倒すのをやめて3ダメージにしました。Wave 7 なら HP 7 なので、会心3回で倒せます。設計書には「会心が入れば一撃」と書いてあったので、そこへ唯一の例外として書き足してもらいました。

ここで、先に作ってあった別の案が要らなくなりました。タンクだけ頭の判定を 0.42 から 0.27 へ絞る、という案です。実装もテストも通っていましたが、一撃で消えなくなった時点で頭を狭くする理由が消えます。丸ごと戻しました。HP バーをタンク限定にする案も、同じ日に実装して戻しています。実装してテストまで通してから戻したものが、この回だけで2つありました。

あと、会心が入っても倒れないときは金色の輪を小さく短く出すようにしました。何も出ないと「当たっていない」と誤解されるので。

バランス調整は結局3往復です。速度 → 会心の扱い → HP バーを出す条件、の順で、1回に1つの軸だけ動かしたので、どれが効いたのか切り分けられました。

ただ、この3往復でバランス調整の難しさを思い知りました。数字はいくらでも出してもらえますが、その数字が「ちょうどいい」かどうかは遊んだ人にしか言えません。しかも1つ動かすと別のところの理由が消えます。頭の判定を絞る案がまさにそれで、会心の扱いを変えた瞬間に要らなくなりました。正解を先に決めてから直す、という進め方ができないので、作って、遊んで、戻して、をひたすら繰り返すことになります。

結局 HP 倍率の 2.4 は一度も触らないまま「ちょうどよいミニボス」に着地しました。最初に私が疑っていた硬さは、最後まで関係なかったことになります。

タイプの名前を画面に出す実装を、出してから取り下げました

5種類に増やすとき、頭の上に「はやい子」「みまわり」のような名前を出す案が計画に入っていました。文言まで用意して、多言語対応の仕組みにも登録して、実装は終わっていました。

実機で見て「名前は要らない」と言いました。形が違うので、読む前に分かります。文言の出来の問題ではなくて、そもそも要りませんでした。

そのかわり、判別が形の差だけに乗ることになります。この後の 6B-2 で体を全部描き直すので、そこでシルエットの差を削ると判別できなくなります。設計書に書き残してもらいました。

点滅は「いつ終わるのか」を言ってくれませんでした

チャージャーは、止まって溜めてから突進します。溜めている22フレームのあいだに何か出さないと、ただ突然突っ込んでくるだけになります。

最初の実装は、不透明度を往復させる点滅でした。実機で見て、私が返したのは「光っているのは分かるけれど、意味が分からない」だけです。

そこから返ってきた説明が、点滅は「今こういう状態です」としか言わない、いつ終わるのか・終わったら何が起きるのかを伝えない、というものでした。

光の輪が外から内へ縮みながら明るくなる形に変わりました。縮みきったところで突進が始まって、輪が外へ弾けます。1回見れば、光と突進がつながります。

ここで1つ、笑えない話があります。私が実機で「前回より良くなった」と返したあとの Codex のレビューで、その弾ける光が8フレームのはずが1フレームで消えていたと分かりました。次のフレームの後片付けが、まだ再生中のアニメーションごと消していました。

つまり、良くなったと言った時点では本来の見え方をまだ誰も見ていません。直した版はもう入っていますが、これは今も確認できていない積み残しです。

引っかかっているのは、私の「良くなった」が何に対する OK だったのか、というところです。作った側は8フレームかけて弾ける演出を見せたつもりで、私はその1フレーム目だけを見て良くなったと言いました。同じ画面の話をしているつもりで、見ていたものが違います。

しかもその OK で 6B-1 は完了になって、次のフェーズへ進んでいます。Codex が拾わなければ、意図していない見え方のまま確定していました。実機で遊んで OK を出すのが私の役目なのに、その OK が何を通したのかは私には分かりません。

体を描き直したら、その光に飲み込まれました

6B-2 です。それまでのモンスターは、Web プロトタイプから移した棒人間でした。設計書には「淡い影のような体・丸みを帯びたシルエット・目や輪郭だけがぼんやり光る」と書いてあるのに、まったく沿っていませんでした。

頭と胴を一体の丸い塗りにして、下へいくほど薄くして影に溶かします。腕と脚は描きません。光るのは目だけです。

• ノーマル … 丸みのある釣鐘型。目は2つ（これが基準）

• ランナー … 細く高い。目は2つで、細長い

• ジグザグ … 裾が左右非対称。目は2つで、傾いている

• タンク … 横に広く低く、肩に装甲板。目は2つで、小さい

• チャージャー … 丸く縮こまっている。目は1つ

目を1つにするのが、5つの中でいちばん強い差でした。形の細かい違いより、数が違うほうが遠くからでも分かります。

この回で効いたのは、5タイプを並べて表示する確認用の画面を先に作ってもらったことです。起動オプションで開くと、等倍・実寸・予兆・密集が一度に見られます。ランダムな出現を待たなくていいので、スクリーンショットが返ってきて、それを見て私が注文を出して、また返ってくる、という往復で形を詰められました。溜めているあいだ目が左右を見る動きも、その途中で私が足してもらったものです。

ここからがタイトルの話です。

体が一体の大きな塗りになったことで、6B-1 で作ったばかりのチャージャーの予兆が、体に飲み込まれて見えなくなりました。6B-1 の時点では体が小さな棒人間だったので、塗りの円が縮んでも体は見えていました。大きな塗りになると、光の円が体をまるごと覆います。縮こまる動きも、目が左右を見る動きも、何も見えません。

塗りの円を輪に変えて解決しました。

この壊れ方は、6B-1 の中だけを見ても、6B-2 の中だけを見ても見つかりません。前のフェーズで作ったものと今のフェーズで作ったものを、通しで動かして初めて出てきました。フェーズに割って進める副作用でもあります。

もうひとつ、頭と胴を一体にすると「どこを狙えば会心か」が見えなくなります。当たり判定は変えられません。変えると 6A・6B-1 で実機で詰めたバランスがやり直しになるので。なので、光る目を判定の中心へ置いて的にしました。目の外端が判定半径の内側に収まることを、余裕を取ってテストで固定してあります。ここが外に出ると「目を狙ったのに外れた」が起きます。

描き方も変わりました。SpriteKit の図形は塗りが一様で、濃淡が作れません。形と縦方向のフェードを焼き込んだ画像をタイプごとに1枚だけ作って、そこへ色を乗せています。個体ごとにサイズが少しずつ違うので、個体ごとに作ると使い回しが効きません。

グレースケールにして5種類を判別できることも、同じ画面で確認しました。色に頼っていないかを見るためです。密集24体で 59fps。ただし描画の呼び出しが511回と多くて、1体あたり20回以上出ています。今は60fps 出ているので触りませんが、演出が増えると効いてきます。

「テストで守っている」と思っていた数値が、変えても通っていました

6B-2 の実装レビューで、Codex から2件出ました。

• 当たり判定の比率（1.05 と 0.7）を固定しているつもりのテストが、実装から期待値を作っていました。1.05 を 1.2 に変えても通ります

• 目が判定の内側に収まるかを見るテストが、本番の計算をそのまま期待値にしていました。計算から項を落としても通ります

どちらも「当たり判定を1つも変えない」という、このフェーズでいちばん大事な約束を守るためのテストでした。証跡が実質なかったことになります。テスト側でリテラルから組み直してもらいました。

自分で仕込んだ誤実装でも1件あって、「目が届く最大の距離の計算から、振り幅を落とす」というやつがどのテストも落としませんでした。落としても余裕の内側に収まってしまうからです。あとで振り幅を広げたときに誰も気づけないので、関係そのものを縛るテストを足しています。

前回に続いて、また同じ形です。テストを書いたことと、そのテストが誤りを捕まえられることは別でした。ここは何周やっても、書いた本人（AI）とレビューする側（AI）を分けておかないと出てきません。

フェーズの外でやった細かいこと

6A の実機確認で、フェーズと関係ない操作性の問題を2つ言いました。どちらも別の作業として片付けてもらっています。

1つは、ゲームオーバーの瞬間にリトライへ連打が貫通することです。終盤は画面中央を連打しているので、リザルトが出た瞬間にその連打がリトライボタンに入って、スコアも到達 Wave も読めないまま次が始まっていました。リザルトに移った直後は45フレーム（0.75秒）ロックして、さらに20フレームのあいだ何も触られないのを待ちます。固定時間だけだと、連打が続いていれば明けた直後の1発が入ってしまうので。

もう1つは、画面の上下中央から来る子が押しにくいことです。横持ちなので親指は左右の下から伸びます。真上と真下がいちばん遠い。上下から出る割合を 50% から 30% に下げました（上下15% / 左右35%）。

これを調べているときに、設計書とコードのコメントの3箇所が「横長画面では左右が近く上下が遠い」と逆に書かれていると分かりました。800×400 で測ると、上下中央までが距離260、左右中央までが距離460です。逆です。ロジックのほうは正しくて、説明だけが5フェーズぶん間違ったまま残っていました。

あともう1つ、タイトル画面の右上に `v0.1 (1) #mpj9` と出してもらいました。実機へ入れ直したのに古いビルドが動いているのではないか、という取り違えが実際に起きたためです。末尾4文字は実行ファイルの更新時刻を36進にした下位4桁で、ビルドし直せば必ず変わります。最初は `08-12 01:15` と時刻が出ていましたが、日付として読めてしまって意味が伝わりません。要るのは「ビルドごとに変わること」だけです。

次は

音です。ここまで効果音が1つも鳴っていません。

つづきます。

#まよいびの子 #個人開発 #ゲーム開発 #iOSアプリ開発 #Swift #SpriteKit #Xcode #ClaudeCode #Claude #Codex #生成AI #AIコーディング #開発日記 #制作日記 #プログラミング #エンジニア #ものづくり #アプリ開発 #スマホゲーム #インディーゲーム #モンスター #キャラクターデザイン #シルエット #状態機械 #移動アルゴリズム #難易度設計 #バランス調整 #ゲームバランス #実機テスト #操作性 #ミューテーションテスト #ユニットテスト #SwiftTesting #コードレビュー #AIレビュー #当たり判定 #ヒットボックス #アニメーション #演出 #エフェクト #SKShapeNode #テクスチャ #描画最適化 #フレームレート #乱数 #重み付き抽選 #デバッグ機能 #UX #色覚 #グレースケール #iPhone #iOS #AppStore #ゲームアプリ #自作ゲーム #ひとり開発 #個人開発者 #週末開発 #副業 #ChatGPT #GPT5 #LLM #AI活用 #AIエージェント #AIとの共同作業 #ペアプログラミング #プロンプト #開発効率化 #失敗談 #振り返り #学び #気づき #継続は力なり #毎日note #note初心者 #創作 #親子 #子育て #中学生 #プログラミング教育 #ジブンコード