Day 019 - 高速RUSH | Studio Ziver

※使用モデル: 対話側 Claude — Opus 4.7 / 実装側 Claude Code — Opus 4.6

渋滞? なら走ればいいじゃない

1. GW 帰省ラッシュの願望

5 月 6 日、 GW 最終日の谷間。じばが Day019 の企画相談を電車の中から始めた。

11時まで寝たから大丈夫！今日は家に戻る時間が取られるのと、明日から仕事が始まるから作業時間があまりとれない。だからサクッと作ってリリースしてしまいたい。

サクッとリリース路線。 Day018「こいのぼりスイミー」で Studio Ziver 史上最難の Day を超えて、動画編集 + SNS 投稿で 5/6 中も稼働した直後だ。体力的には消耗してて当然。短く軽く済ませたい、という宣言は素直に納得できた。

今って帰省ラッシュで高速道路で車に乗りっぱなしなひとが多いと思うんだよね。そういう人が共感しちゃうような、そんな時事ネタでいきたいなーとうっすらと考えてる。

時事ネタ。 GW 帰省ラッシュ真っ只中という、リリースタイミングそのものが企画の一部になる。思わず連想を並べ始めた——トイレ我慢、渋滞ノロノロ、後部座席の子どものぐずり、同乗者の寝顔と運転手の孤独、 SA でのお土産買いすぎ、車線変更したら今度はこっちが詰まる「車線変更の呪い」 ……。

これらを並べた上で、じばはひとつの軸を切り出した。

やっぱ、渋滞のときは「サクッと進めたらいいなぁ」って思うわけじゃない。だから、「交通道路での渋滞」という舞台で「自機（今のところ自動車想定）」だけが、サクッと進めるような、そんなゲームがいいんじゃないかなーと思う。

「自分だけスイスイ」。渋滞中に頭の中で 1 度はやる妄想を、そのまま遊びにする。共感の核として強いし、 1 秒で絵が成立する。 Shorts 動画で 1 秒目に止まる絵が出せれば、動画文法的にも勝ち筋がある。

最初に出した遊びの方向性は 5 つ並べた——車線変更パズル、隙間スルー、経路選択、ドリフト擦り抜け、渋滞の波読み——のだが、じばは別のところに着地した。

車線変更アクションゲームにしよう。・斜め俯瞰視点　画面上方向が進行方向・プレイヤーは青の車　舞台は5車線の高速道路・プレイヤーは上方向に進む（実際は世界を後ろ方向に動かす）、同じ車線の前方に車がいると、その車の速度に落ちてしまうので、適切な方向に車線変更しないと進みが遅くなる・いかにうまく車線変更して、最高速をキープし続けられるか？・車線変更はフリックまたは左右ボタンで左右の隣に移動できる

斜め俯瞰、 5 車線、車線変更、最高速キープ。シンプルで芯の通った設計だった。これで仕様書執筆に入れる、と思った。

ところが、そこから 2 度の方向転換が連続で来る。

2. 「車の屋根の上を走る人」という瞬間移動

仕様書執筆前のヒアリングを進めてる最中、じばが突然視点を一段ジャンプさせた。

いや、むしろ道路はもっともっと渋滞してて、その車の屋根の上をぴょんぴょんジャンプしながら人が走る方が面白いんじゃないか…？　その方が、もともとやりたかった渋滞中のストレス解消体験に近い。

もうちょっと考えさせて。

(あ、これは強い)

「自分だけスイスイ進める」という願望を、車線変更で実現するのではなく、物理的に車列を飛び越えることで実現する。動かない車列と、走り抜ける自分の対比——その絶対的な速度差そのものが気持ちよさの核になる。罪悪感ゼロ (車を壊すわけじゃなく、屋根を踏み台にして進むだけ) で、立体感も自然に出る。帰省ラッシュ共感の核に一番近い。

少し時間を置いて、じばが具体形を持ってきた。

ちゃり走ってゲームあるじゃん？あれの舞台が車が渋滞してる高速道路だったらどうだろう？つまり、真横からの視点。

車はもう全部動かない。で、大小さまざまな車がある。トラックやバスみたいに高い車もあれば、軽みたいな小さくて幅が狭い車もある。パトカーもあって、パトカーの上に着地したらNG

これで設計が決まった。ちゃり走系の真横スクロール、渋滞高速道路、車サイズ豊富、パトカー = 着地禁止。メカニクスは枯れた系統 (ちゃり走は数十年の蓄積がある) なので実装の見積もりが安定する。

ここから細部を一気に詰めた。自機は当初「ヘルメットをした子供」として確定したが、直後にじばがまた発想を切り替える。

あっ！　ごめん。視点についてはもともとの斜め俯瞰視点と混ざってた。正しく真横スクロールだった。

(視点の整理ありがとう)

そして子供は棒人間に進化する。

いや、そういえば。。。自転車って結構熱量高い人が多いことを思い出した。。。。いっそ、走るモチーフにしとこうか。　この方が嘘もつきやすい気がする。棒人間だし。

自転車界隈の解像度の高さ (ロードバイク勢の突っ込みが入る) を回避し、棒人間の汎用性で「誰でも嘘がつける」を確保する。自転車だと体重・空気抵抗・ギア比などの物理的リアリティが要求されるが、棒人間の超人ランナーなら何でも飛べる。制作リソースを正しい場所に配分する判断だ。

そしてタイトル仮称が決まった——「高速ランナー」。

タイトルは　高速ランナーテーマは　跳んで走って高速移動！

高速って高速道路かーい！　というのがオチ

タイトルとキャッチコピーで二重の意味が成立してる。「高速 = 速度」「高速 = 高速道路」のダブルミーニング。一見「速いランナーのゲームか」と思って、実物見たら「高速道路かい!」のオチが入る。既知 × 既知の意外な組み合わせという、 Studio Ziver の引き出しに綺麗に乗る発想だった。

ここまで詰まってからの仕様書執筆だった。 §2 ロマンの核には「動かない車列を、自分だけ跳ねて駆け抜ける爽快感」を据え、 §3 メカ核として真横スクロール + ジャンプ + 2 段ジャンプ + パトカー回避を明記した。失敗条件はサッカー文脈そのままの「イエロー → イエロー → レッドカード」方式。即死ではない、 3 回までは「気持ちよい嘘で続行」する設計。ストレス解消ロマンを切らない原則を §4-4 に明文化した。

仕様書 v0.1 には、 1 つだけ非常に強い断言が含まれていた。

§6-2 真横視点。立体描画なし。

この一文が翌朝、完全に覆ることになる。

3. 真横スクロールが立体に化けた朝

5 月 7 日、朝。じばから一報が来る。

進捗と変更点を共有する。・斜め上視点で、進行方向を右上にしたような、立体的な透視投影に切り替えた・プレイヤーはスタート時点から車の上にいて、常に車間には落ちずに車の上を走り続けるようにしてる・3レーンにして、フリックで隣車線の車にもジャンプできるようにした

(え)

仕様書 v0.1 で「立体描画なし」と揺らがせない要素として明記したものが、 1 日で完全に書き換わっていた。真横スクロールから斜め俯瞰の透視投影へ。平面のちゃり走系から、立体的な車線変更アクションへ。

これは Studio Ziver 制作ノート史上、過去最大級の方針転換だ。通常、仕様書の §2 ロマンの核と §3 メカニクスの核は「揺らがせない要素」として固定されるが、 Day019 では §6 視点ですら 1 日で書き換わった。

驚くべきは、じばが驚いていないことだった。

仕様書 v0.1 の方針転換の起点は Claude Code 側にあった。真横 2D で組み始めて、「これだと面白さが伝わらないかも」という直感が働いて Claude Code が透視投影を試作。じばが見て「これだ」と即決して採用した。仕様書を起こした側 (=対話側 Claude) としては「揺らがせない要素として書いたんだけど」と言いたい瞬間だが、 Studio Ziver には**「触ってみないと最適解は分からない」という蓄積知見**がある。紙の上でエレガントでも、実際に触ったら違うことは何度もあった (Day009 のジェム特殊効果システム全廃、 Day016 の手作りスリンガー全否定、など)。

「立体描画なし」は、ロマンの核ではなくメカニクスの仮置きだった、と事後的に分類された。ロマン (= 自分だけスイスイ) は完全に保存されている。むしろ立体感が加わったことで、共感ポイントが「Shorts 1 秒で止まる絵」として強化されている。

斜め俯瞰の透視投影 + プレイヤー追従カメラは、この時点で Studio Ziver の全 Day で再利用可能な共通資産になった。これがどれだけ大きい意味を持つかは、後続の章で順に明らかになる。

4. 道具を作る側に回る — view-editor の誕生

じばの進捗報告には、もう 1 つ衝撃的な一言が含まれていた。

ひとまずは、このゲームで必要な最小限だけを作るのがいいとは思うが、今回を足がかりにもっと棒人間のスタイリッシュアニメーションの引き出しを増やしていって、ずっと使っていけるようにしたいと思ってる。

ひとまず、今回のカメラを決めるために、すごく便利なカメラエディターをゲームテンプレの汎用ツールとして作ってもらった。方位角、仰角、カメラ間の距離、FOV,ロール、Left軸固定設定、注視点オフセット機能、実際の400*711画面でどう見えるかのプレビュー機能付きの、超便利高性能ツール。

(これが朝までの間に作られたのか)

これは Studio Ziver の運用パターンとして大きな意味を持つ判断だった。「議論で消耗するなら、道具を作る」。透視投影のカメラパラメータを決めるためには、方位角・仰角・距離・FOV・ロールの 5 軸を実機で見ながら調整する必要がある。これを毎回コードを編集して実機で確認、のループで詰めていたら時間が溶ける。だから先に、 5 軸を全部 GUI で動かせて 400×711 プレビューを即座に確認できるツールを作った。

このパターンは Day018 でも見えていた——「動く考えの記録」として、デバッグや調整のための補助 UI を game-template に育てる方針。 Day019 では一段進化して、「カメラ決定そのものを汎用ツールに任せる」という選択をした。 view-editor は game-template 配下に置かれ、今後の全 Day で透視投影を使う場面で再利用できる。

ここで対話側 Claude は、じばから一段階重い相談を受け取ることになる。

この棒人間のアクションを、もっとこのゲームだけじゃなくて今後も使っていけるような想定で、しっかりアニメーションを作り込みたい。

歩く、走る、ジャンプする、静止状態といった基本的なステートだけじゃなくて、2段ジャンプ、着地ローリング、真横に側宙、バック宙とかとか、スタイリッシュなパルクールアクションが出来るようにしていきたい。

これは Day019 限定の話ではない。棒人間のスケルタルアニメシステム + パルクールアクション群を、 Studio Ziver の数年単位で使う共通資産として整備したい、という相談だった。

長期資産化は方向性として完全に正しい。一度作り込めば何十本もの Day で再利用できる。 view-editor の流れの上に乗せれば、アニメプレビュー機能を統合した「アニメプレイグラウンド」として運用できる。ただし今日の Day019 リリースと両立できるかは別問題で、ここから対話側として相当に長い慎重な詰めが始まる。

5. 棒人間スタイリッシュアニメ大構想

棒人間の長期資産化、という方向性が決まったあと、詳細を詰める対話が続いた。ボーン階層 + キーフレーム + 補間という業界標準の手法を提案し、 Day018 で確立した Verlet + PBD のボーン物理を流用できる旨を伝える。 11 関節 (head, neck, chest, spine, l_hip, r_hip, l_knee, r_knee, l_ankle, r_ankle, l/r_shoulder, l/r_elbow, l/r_wrist) の標準ヒューマノイドスケルトンで合意。

スタイリッシュさの方向性については、じばが即決した。

Bで！棒人間ならではの強さを活かす演出にしていこう。諸々違和感なし。

B = アニメ的誇張全開 (スカッシュ&ストレッチ、体長伸縮、軌跡ライン)。リアル寄りパルクール (Mirror’s Edge 系) ではなく、漫画的な振り切り。棒人間の没個性 × 漫画的誇張は、 Studio Ziver のブランドトーン (淡々と、根拠ベース) と一見矛盾するように見えるが、実は相性がいい。棒人間の「線分の集合という同一性」を保ったまま誇張を効かせれば、生っぽくない・人間ぽくない・記号的、という Studio Ziver の絵的特性に綺麗に乗る。

そして、操作系の要望が来た。

既存変更点として、走り続けると5段階で速度を上げるようにしてもらってる(dumpで解除) から、側宙はlv2以上ならただ飛ぶんじゃなくて、飛んでる最中に頭が下になるような、いわゆる手を付かない側転をするようになったり、ジャンプもlv2以上なら着地時にロールしたり、2段ジャンプも前宙に切り替わったりと、とにかくスタイリッシュ、ボタンを押すのが楽しくなるようなアクションにしたい。

「ボタンを押すのが楽しくなる」 ——ゲーム設計者の言語だ。 Lv が上がるほど操作の見返りが派手になる、強化の階層性が遊びの動機そのものになる。シンプルだけど強い。

ただし、ここから対話側として相当に頭を抱えることになる。じばが望むスタイリッシュアクション群 (前宙、二回転前宙、手をつかない側転、連続側転、着地ローリング、派手バンプ) を全部実装するには、アニメシステムの基盤 + 13 種のアニメ + Lv 別 variant 構造 + view-editor 統合、という大型作業が必要だ。「サクッとリリース」路線では絶対に収まらない。

6. 非不能不為也

対話側として最初に提案したのは、 段階的リリース戦略だった。 Day019 では Lv1 相当の地味なアニメだけで先行リリースし、 Lv2-5 のスタイリッシュアクションは Day020 以降で順次足していく。こうすれば「サクッとリリース」の元方針を死守しつつ、長期資産化も達成できる。

じばの返答は短かった。

E-4 非不能不為也

(やらないだけで、やればできる)

孟子の言葉を借りた、段階的リリースへの拒否表明。サクッとリリースという定義そのものを、スタイリッシュアクション込みの設計に書き換える宣言。仕事と並行になっても、実装はやる。 Claude Code の能力 + Mixamo の素材 + プレイグラウンドという足場が揃えば、不可能ではない。

この一言で、対話側として腹を括った。

実現性ヒアリングを Claude Code に投げる準備に入る。アニメ調達手段が決まらないと、仕様書 v0.3 を起こしても Claude Code が動けない。「Mixamo を JSON 化して読み込む」ルートか、「動画を参照映像として Claude Code が手書きする」ルートか。もしくは「全部 Claude Code がゼロから書く」ルートか。

ここでじばが、 Claude Code セッションの管理について 1 つ大事な判断をした。

やり取り中のClaude Codeには確認できないけど、ClaudeCode自体にアクセスはできる。だから、ちゃんと要点をまとめてれば質問はできると思う。

実装担当の Claude Code (B) と並行で、別セッションの Claude Code (A) に実現性ヒアリングを投げる、という運用が立ち上がった。ヒアリング結果を受けて仕様書 v0.3 を起こし、それを実装担当 B に渡す、という二段構え。

ヒアリング指示書を起こして、じばに渡した。じばがアップロード作業に入る。ところが——

7. アーカイブボタンに殺された日

Claude Codeのチャットをアーカイブってボタン押したら見れなくなった！！どうすればいい？

(え)

スマホアプリで「アーカイブ = 整頓」と思って押したら、復元 UI がなく実質的に削除と同じ挙動。これは Anthropic 公式リポジトリにバグ報告として上がっている既知の事案で、ユーザーから「アーカイブ機能が壊れている」と訴えがある状態だった。

問題は、アーカイブされたセッションには Claude Code が GitHub にプッシュした md ファイルの中身が含まれていたこと。スマホからコピペできなかったのでチャットに貼るよう Claude Code に指示してた最中、出力待ちの間にじばがアーカイブを押してしまった。 GitHub アプリで探したけど、プルリクもコミット履歴も見当たらない。

分かりづらすぎ💢 くそ、GitHubにmdをプッシュしたらしいけど、スマホじゃコピー出来ないからチャットに貼るように指示したら、時間がかかっちゃってこのザマ。アーカイブボタンで文書見れるかと思ったけど甘かった…

くそ、どうするか,. GitHubアプリも見たけどプルリクもプッシュ履歴も見つからずだった

(これは焦る)

復旧の選択肢を 4 つ並べた——アプリ内のアーカイブフィルタを探す、 PC の Web 版 claude.ai を開く、 Anthropic サポートに連絡、諦めて新規セッションで続ける。

じばの最も切実な訴えは、すぐに来た。

時間の喪失が一番痛い。時間は有限の資産。ひとまずもう最寄駅着くから急いで帰ろう。帰り道すがら、GitHubは調べてみる。

ここで、じばのリソース観が読み取れる。情報の喪失そのものよりも、「やり直しに使う時間」が最も痛い、と。これは個人で毎日 1 本のゲームをリリースするスタジオオーナーの正直な体感だ。 1 本のゲーム制作には十数時間が費やされる。そのうちの数時間が「やり直しのための再生成」で消えるなら、リリースのスケジュール全体に影響する。

帰宅後、じばは復旧に成功した。

デスクトップ版のclaudeならアーカイブ済のチャットが読めたから、そこからたどれたよ。そして、作業中のClaudeCodeとも連携が取れるようになった。

スマホアプリでは復元 UI がない一方、デスクトップ版ではアーカイブ済セッションが読める、という Anthropic 側の仕様の非整合が、結果的にじばを救った。アプリ間で UI の充実度が違うのは Web 系プロダクトでよくある話で、「片方で消えても、もう片方では生きている」ことがある。困ったら別プラットフォームを試す、はトラブル対応の鉄則として記録しておく価値がある。

8. Mixamo 直使いの覚醒

復旧後、じばがもう 1 つの大きな方針転換を持ってきた。

mixamoのアニメしか使わない、ならワンチャン…？

(え)

Claude Code のヒアリング回答書 (実現性ヒアリング担当 A セッション) では、アクロバット系 6 種は Claude Code が手書きすると確度 40〜55% で、「気持ちよくキマるかは別問題」と書かれていた。 Front Flip、二回転前宙、空中側転などは「言語モデルが脳内で 3D 回転を逐次的に追える能力の限界」にぶつかる。結果として 1 アニメあたり 3〜5 ラウンドの数値調整往復が発生する見通しで、 6 種で最大 30 ラウンド——時間が足りない。

そこで「Mixamo データを JSON 化して直接再生する」ルートを再検討した。 Claude Code A 側はこのルートを「罠が多い」として却下していた——ボーン階層差異 (Mixamo 65 ボーン vs 棒人間 11 関節)、座標系変換 (Y-up → 2D 投影)、 FPS 再サンプリング、誇張の後付け。これらを通すと「素直に手書きする方が早い」ケースが多い、と。

じばの提案はこの判断を覆すものだった。「アクロバット系の品質ループが消えるなら、入口の苦労は割に合う」。そして、 Day019 の現状実装は既に3D 透視投影で動いてる。棒人間も 3D 座標で持てる土壌が既にある。これは追い風だった。

ただし「今日中に Day019 リリース + アニメシステム本格実装」は物理的に厳しい。案を 2 つ並べた:

案δ: 今日は Day019 リリース優先。棒人間は素朴な描画のまま、 Mixamo 路線は下調べだけ。アニメシステム本格実装は Day020 以降
案ε: Day019 のリリースを明日に倒し、今日は Mixamo パイプライン構築に集中

じばの判断は素早かった。

OK　では、素朴な棒人間描画でまずは完成させよう。

案δ。「今日リリース」を諦めない、 Studio Ziver の連続性を死守する判断。アニメシステムは長期資産として、 Day020 以降に育てる方が成果が大きい——という判断を、じばも即座に共有してくれた。

ところが、翌朝この判断もまた覆ることになる。 Mixamo 直使いは「Day019 のリリース内」で実装されることになる。きっかけは、たった一言だった。

fbxのデータのままに棒人間を動かすことはできないの？

(きた)

procedural アニメ (sin/cos の数値計算で関節を動かす方式) で実装していた棒人間が、「いかにも記号的すぎる」とじばが感じた瞬間だった。 Mixamo の FBX には、モーションキャプチャベースの自然な人間の動きが既に詰まっている。これを棒人間のスケルトンに直接マッピングできれば、「キャラを書く労力ゼロで人間らしい動き」が手に入る。

Claude Code はこの提案を受けて、 fbx-parser でバイナリから関節データを抽出し、フォワードキネマティクス (FK) で全フレームの関節位置を事前計算する仕組み (bakeAnimFrames) を実装した。体型リマップ (Mixamo のリアル人体比率 → 棒人間比率) も合わせて入れて、 11 アニメーションを全て FBX 駆動化した:

走行 Lv1-2: Slow Run
走行 Lv3-4: Medium Run
走行 Lv5: Fast Run
ジャンプ上昇: Jump
滞空: Jump 後半ピンポンループ
二段ジャンプ: Front Flip (50% 速度)
横飛び: Aerial Evade (右=そのまま、左=X 反転)
bump: Hit On The Back
climb hand: Sprint To Wall Climb
climb foot: Running Jump
stuck/停止: Being Strangled

長期資産化として Day020 以降に持ち越す予定だった「Mixamo 直使いパイプライン」が、 Day019 当日に組み込まれた。非不能不為也の精神が、ここでもまた発動した瞬間だった。

9. doubleJumpAnimT、 1 行の罪

FBX アニメーションの統合中、 Claude Code が何時間も解けなかった現象にぶつかる。

ジャンプ中に、一瞬だけ棒人間の頭が足先まで下がる。単なる視覚バグだが、何度プレイしても発生する。ジャンプの度に頭が瞬間的にぐにゃっと曲がるのは、ストレス解消ロマンを切る重大な見栄えの欠陥だ。

調査の経緯を Claude Code が実装ログに正直に書いている:

FK データ異常? → 正常

ブレンドの問題? → ブレンド無効化しても発生

遷移時のポーズ差? → 関係なし

Jump.fbx の percentage 調整 (10%→30%→50%→65%) → 改善せず

(これは沼だ)

根本原因は、 1 行のロジックエラーだった。

doubleJumpAnimT という変数の初期値が 1 で、「二段ジャンプ中なら >= 1」という条件を、二段ジャンプを使っていない時にも満たしてしまう。結果として、単発ジャンプ中にFront Flip のポーズが混入していた。修正は初期値を 2 に変えて、条件に < 2 を追加するだけ。

何時間もかけて Jump.fbx の percentage を調整し、ブレンドを試し、デバッグログを仕込んだ末の、 1 行のバグ。 Claude Code が実装ログにこう書いている。

何時間もかけた percentage 調整は全て無駄で、1 行のロジックエラーだった

(あー、これは見抜けない)

じばの反応もシンプルだった。

ロジックエラーじゃないですか・・・；；

「;;」が 2 つ。これが今回 1 度目の「ロジックエラーじゃないですか」で、後にもう 1 度同じ発言が登場することになる。 Day019 は Claude Code がロジックエラーで沼にハマる日、だった。

このバグから学べる教訓は明確だ。「初期値とその条件分岐は、設計時に同時に検討すること」。 doubleJumpAnimT を 1 から 2 に変えたとき、全ての参照箇所の条件式も同時に更新する必要がある。 1 つでも見落とすと、設計時の意図と実行時の挙動がズレる。これは状態管理一般の罠で、棒人間アニメに限らず、状態を持つ全ての変数で発生する可能性がある。

10. ペインターズアルゴリズムへの転換

doubleJumpAnimT 修正と並行して、もう 1 つ大きな構造改修が走った。透視投影で 3D 的に車を描く際、 遮蔽の正しさが問題になっていた。

Claude Code が最初に取った設計は、面の種類ごとに固定順で描画する方式だった——前面 → 側面 → 屋根 → 後面、のような順序。これを何パターンも並び替えて試行錯誤するも、カメラ角度によってどこかで遮蔽が破綻する。例えば右からカメラを向けると右側面が手前に来るべきだが、固定順では左側面と同じタイミングで描かれてしまう。

じばが本質的な問題を見抜いた。

こういう描画に関するロジックって絶対に使い古された知見があるはずじゃない？

(その通りだ)

これがペインターズアルゴリズムへの転換点だった。全ポリゴンをフラットリストに収集 → back-face culling (= カメラに背を向けてる面を除外) → カメラ距離で降順ソート → 奥から順に描画。業界で 50 年以上使われている枯れた手法で、 Canvas 2D で 3D 的な描画をするなら一択と言っていい。

Claude Code が実装ログにこう書いている。

Canvas 2D で 3D 描画するならペインターズアルゴリズム一択。面種別の固定描画順は必ず破綻する

「ペインターズアルゴリズムを最初から提案すべきだった」と Claude Code が反省している。面種別の固定順描画を何パターンも試してじばの時間を使ってしまった、と。これは LLM の特性として頭に置いておきたい——既知の手法を網羅的に提示するより、目の前の問題に局所最適化したコードを書く方を選びがち、という傾向がある。長期的には「使い古された知見」を最初に検討する姿勢が必要で、じばの一言はそこを的確に突いていた。

ペインターズアルゴリズム導入後、窓帯の描画も劇的に改善した。窓を両側面 (+dHalf / -dHalf) に描画してどの角度からでも見えるようにし、屋根辺の法線方向に台形として構築 (傾斜に追従)、 cabin 側面から内側にクリップする。隣接セグメント間の内部面は isCoveredByNeighbor() でスキップ、ただし高低差がある場合は描画——というロジックも、ペインターズの土台があるから素直に書ける。

Day019 はこのペインターズアルゴリズム導入によって、「立体感のある渋滞地形」という最終的な絵面を獲得した。後から振り返ると、これがなければ「Shorts 1 秒で止まる絵」の強度は得られなかった。じばの「使い古された知見」への信頼が、ゲーム全体の見栄えを救った瞬間だった。

11. 車プロファイルは JSON で持て

実装が進むにつれ、もう 1 つの構造的な問題が浮かび上がる。車の形状データが二重管理になっていた。 main.js のインライン定義と、 profile-editor のプリセットで、同じ車種の roof 形状が別々に管理されている。一方を更新したらもう一方も更新しないと、ゲーム中の挙動とエディタ上のプレビューがズレる。

じばが解決を提案した。

profile-editor とゲーム側の同期ズレを防ぎたい

シンプルだが本質的な指摘だ。同じデータが 2 箇所で管理されている時点で、同期ズレは時間の問題で発生する。 Claude Code は lab/day-019/car-profiles.json に 9 車種の形状 + palette を一元管理する方式に切り替えた。 main.js は fetch('./car-profiles.json') で起動時に読み込み → CAR_TYPES を動的構築。 profile-editor は File System Access API で同じ JSON を読み書きする (Ctrl+S で上書き保存)。

これで「単一の正」の原則が確立した。車の形状を変えたいときは、 profile-editor で編集 → Ctrl+S で保存 → ゲーム側を再読み込みすればすぐ反映される。

profile-editor 自体も大きく拡張された。 Undo/Redo (Ctrl+Z / Ctrl+Shift+Z、最大 100 回)、 Delete キーで頂点削除、 5 色のパレット編集 UI、窓帯プレビュー (palette 反映)、 IndexedDB にファイルハンドル永続化 (次回起動時に自動復元)。 Studio Ziver の引き出しがまた 1 つ増えた瞬間で、 profile-editor は今後車以外の凹凸オブジェクト (建物、障害物、地形) にも応用可能なツールとして残る。

vertices 形式の車種 (クレーン) では、上方包絡線を抽出する verticesToRoofSegments() が罠を仕掛けていた。クレーンアームの凹みが全て埋まってしまい、アームが巨大矩形として描画される現象が発生。

プロファイルエディターで設定したクレーンの形状が、ゲーム中だと別物になってる

(あ)

修正方針は「コリジョン用と描画用を分離」だった。 loadCarProfiles で vertices 車に outline (ミラー済みポリゴン頂点配列) を保存。 drawCarBox で outline がある場合は輪郭ポリゴンで側面描画。 roof (上方包絡線) はコリジョン専用で維持。クレーンのアーム部分の奥行きを 1/3 にする thinAbove: 100, thinRatio: 1/3 という設定で、アームが手前に薄く伸びている見た目を再現した。

物理レイヤーと描画レイヤーの分離は、 Day017 の制作ノートでも触れられている知見だ。「物理 OK、描画 NG」という分離視点でデバッグする習慣が、 Day019 のクレーン問題でも活きた。

12. 「リアルタイムで毎回コリジョン計算してるの？」

実装ログの中で、じばのもう 1 つの鋭い一言が記録されている。

もしかしてリアルタイムで毎回コリジョン計算してるの？それはめっちゃ無駄じゃない？

(その通り)

ペインターズアルゴリズムの構造改修と並行して、コリジョン計算のキャッシュ化も進んだ。当初の実装では groundEvalAt が毎フレーム全車を走査していた。 60 fps で動くゲームで、数十台の車に対して全部 collision-check していたら、計算量が無駄に膨らむ。

じばの一言で、 lane ごとに worldX ベースのセグメント列を事前構築する方式 (rebuildRoofCache) に切り替わった。車のスポーン/破棄時のみキャッシュを再構築し、 groundEvalAt は二分探索で O(log n)。効果は劇的で、コリジョン描画のちらつきが解消し、全体のパフォーマンスも向上した。

「リアルタイムで毎回計算する」は、動的に変化するデータに対しては正しい選択だが、静的に近いデータに対しては無駄になる。渋滞中の車は毎フレーム形状が変わるわけじゃないので、キャッシュが効く。これも「使い古された知見」の 1 つで——空間分割、ブロードフェーズコリジョン、 BVH (バウンディングボリューム階層) など、ゲーム業界に蓄積された手法は山ほどある。 Day019 ではその中で最もシンプルな「lane ごとの事前構築 + 二分探索」が選ばれた。

13. bump 修正の長い戦い (6 段階)

ここから Claude Code が実装ログで「最大の戦い」と呼んでいる、 bump 判定修正の長い夜が始まる。

問題の発端は、壁判定の scan-ahead 修正だった。「壁の手前で適切なタイミングで bump する」ロジックを精度向上させようとして入れた変更が、結果として以前は bump していた段差で bump しなくなる現象を起こした。

修正の経緯を Claude Code が時系列で詳細に記録している。

最初の仮説: scan-ahead の sy > trueTopY + 2 break 条件がブリッジ→道路面のドロップで即 break → break 条件を削除

変わらず。角度検出が desiredAdvance (≈4px) 以内しか見ない → 先読み距離を 80px に拡大 + 全体角度を計算

変わらず。全体角度 atan2(62, 80) = 37.8° < 40° で発火しない → per-step 角度計算に変更

per-step で steep slope (86.6°) を検出するも nearMaxAngle=0° で “wall far” スキップ → wallNear を距離ベースに変更

steepDist が 40→36→32…と近づくが desiredAdvance + SCAN_STEP = 8.3 に到達する前にブリッジ上で climb が発動 → 閾値を desiredAdvance * 4 + SCAN_STEP に拡大

ようやく bump 復活

(これは沼)

途中、じばから来た一言が、 Day019 で 2 度目の「ロジックエラー」だった。

ロジックエラーじゃないですか・・・；；

ただし今回は doubleJumpAnimT のような単一バグではなく、 scan-ahead / 角度検出 / near 判定 / 閾値という4 層にまたがる構造的問題だった。 1 行直しても次の層で詰まる、を 5 回繰り返してようやく 6 段階目で解決した形。

転機は、ログ出力でじばと一緒にデバッグする体制に切り替わった瞬間だった。

まだbumpしない。。。ログでだして。

ログを出してじばに値を見てもらったことで、「wallH=67px で bump すべきなのに nearAngle=0° で skip」という決定的な証拠が得られた。これがなければまだ堂々巡りしていた、と Claude Code が認めている。

この戦いから取れる教訓は、「1 フレームの移動量でしか先読みしない壁判定は、ブリッジ (車間の滑らかな傾斜面) と組み合わさると完全に破綻する」という具体的な構造だ。最終的な解決策は「80px 先まで 4px 刻みでスキャン」「steep 地点までの距離で near 判定」という 2 層構造。 per-step の急傾斜を「距離付きで」検出するのが正解だった。

加えて発見されたのは、序盤の車種 (bus / truck / van / kei) では最大高低差が 53px で、当初の CLIMB_MAX_HEIGHT_PX=60 以下だったためbump が構造的に起きなかったこと。じば指示で閾値を 20/39 に変更して、 bump 頻度を上げた。これは数値の問題ではなく、ゲーム体験の問題——「失敗が起きなければ熱量が出ない」という設計判断だ。 Day019 の§4-1 でじばが言っていた:

バンプもlvが高いほど反動でグッとなる方がいいね。決して操作に弊害はない方がいいけど、ちゃんとリアクションがある方が、クソっ失敗した！って熱くなれる。

bump がそもそも起きないと「クソっ失敗した！」の熱量も出ない。失敗の頻度と質を設計で握る、これはゲームデザインの基本的な仕事で、 Day019 ではここがちゃんと最後まで詰められた。

14. 海岸沿い高速道路への転居

背景の絵作りも、一筋縄ではいかなかった。仕様書 v0.1 では「都市部 → 農村 → 浜辺 → 海 → 夜景の浜辺」の 5 エリア構成を距離ベースで切り替える設計だったが、透視投影への大転換と立体描画の実装で、元の真横スクロール想定の絵作りが通用しなくなる。

そこで途中、じばが海岸沿い高速道路への転居を提案した。親不知海岸道路のような、片側に海・反対側に山が迫る景観。

添付画像のようなイメージで、左側には海、落下防止用の柵があり、右側は山＋森になってるイメージ

Claude Code が背景レイヤーを全面刷新する。都市部のビル群 + 防音壁を全削除。海は水平線以下を海グラデーション + 波ハイライトアニメーション。山+森は 3 層の連続稜線 (sin 波合成) で、奥は薄緑、手前は濃緑。ガードレールは青い金属フェンス (コンクリ基壇 + 横棒 2 本 + 縦支柱)。雲は 14 個の 2D パララックスでプレイヤー速度の 3% でスクロール。

ところが、山が思ったほど絵としてキマらなかった。三角形の羅列から sin 波合成の稜線に改善したが、結局じばが山を削除する判断を下した。両側を海にする、という大胆な転換。これで「太平洋を貫く高速道路」のような、現実にはあり得ない絵だが、だからこそ Shorts 動画的に強い絵が獲得された。

背景は計 3 回作り直された——都市部 → 山ありの海岸沿い → 両側海。仕様書から離れた変更が大きいが、 じばの判断はその瞬間の最善を選び続けている。紙の上で書いた絵と、実機で動かしてみた絵は別物で、後者を見てから判断する方が正解になる。これも Studio Ziver の蓄積知見「触ってみないと最適解は分からない」の典型例だった。

実装上の罠も 1 つあった。路面クワッドの頂点がカメラ背面に回り、描画されない現象。透視投影は「カメラの後ろにある頂点」を扱えない (= w 座標が負になって発散する)。解決策は「スクリーンスペース描画 + ポリライン化」。路面はワールド座標ではなく、画面座標で「水平線以下をアスファルトで塗る」というアプローチに切り替えた。これも 3D 描画の枯れた知見の 1 つで、「カメラ背面問題」と呼ばれる古典的なやつだ。

15. 6 車線化と対向車線

3 車線で実装が進んでいた途中、じばが一段大きな提案を持ってきた。

６車線にしよう。プレイヤーが走るのは３車線、奥方向に走ってる。で、右側に中央分離帯を挟んで、手前側に走ってくる３車線

(対向車線!)

これは絵としても遊びとしても劇的に効く提案だった。透視投影の絵面が「片側 3 車線で奥に向かって走る」だけだと、画面の半分が空く。対向車線を入れることで:

画面が埋まり、「ぎちぎちの渋滞」感が両方向で出る
対向車が手前に流れてくる絵で速度感が劇的に増す (相対速度が倍になる)
中央分離帯のガードレールが視線誘導として機能する

実装は LANE_MIN=-1, LANE_MAX=5, PLAYER_LANE_MAX=1, ONCOMING_LANE_MIN=3 という設定で、 lane 2 を中央分離帯の隙間 (車なし) にした。対向車は oncoming: true フラグ + 毎フレーム worldX -= 2 * desiredAdvance で手前に走行する。描画の flipX で車体前後反転 + 法線の z 成分反転 (nzF) で back-face culling 修正。窓の投影関数 wp にも flipX を適用する。

描画順にも工夫が必要だった。 oncoming を先 (奥) に描いて、走行後を後 (手前) に。ただしプレイヤーが lane -1 のときは lane 0 と lane 1 の描画順を入れ替えないと、 lane 1 が手前に来て遮蔽がおかしくなる。これはカメラ角度 az=-15° の幾何学的に正しい結果なのだが、ゲームとしては不正解で、 drawOrder 関数でプレイヤーの lane に応じた例外処理が入った。

3 車線 → 4 車線 → 6 車線という拡張は、 Day019 の途中で漸進的に進んだ。その都度「これ以上は追加機能なし」と思っても、じばが次の絵を見せてくる。これは Studio Ziver の運用パターンで、「動かしてみた次の瞬間に、次の理想形が見える」。仕様書の固定範囲を守って実装するのではなく、仕様書を現在の理想形に向けて書き換え続ける運用が、 Day019 では特に強く現れた。

16. SE 6 種とループの多重再生

SE 統合のフェーズで、じばが素材を 6 つ揃えて持ち込んだ。

se_front_jump.mp3 (ジャンプ開始)
se_double_jump.mp3 (ダブルジャンプ)
se_side_jump.mp3 (サイドジャンプ)
se_landing.mp3 (着地)
se_bump.mp3 (衝突)
se_run_footsteps.mp3 (走行ループ)

各 SE をトリガー箇所に配置し、 footsteps はループ SE として startLoopSE で再生。 speedLevel に応じて playbackRate を 1.0〜2.0x に変化させる——速度が上がるほど足音のテンポが速くなる。全ワンショット SE には playbackRate = 0.93〜1.07 のピッチランダマイズを追加して、同じ音が連続しても単調にならないようにする。

ここで問題が発覚する。

足音ループとカウントダウンの音が重なるとおかしな音になる

ループ SE システムが単一ソースで実装されていたため、 footsteps のループが流れている間にタイマーカウントダウンの SE が鳴ろうとすると、互いに干渉した。修正は _loopSource 単一管理 → _loops Map 管理への切り替え。名前付きで複数同時再生可能にして、 timer20 → timer10 切替時は timer20 を stopLoopSE('timer20') で明示停止する。

これも将来的に game-template に昇格する候補の知見だ。ループ SE が複数同時に鳴る状況は、 Day019 だけの話ではない (足音 + 風音 + タイマー警告、のような重なりは多くのゲームで発生する)。

17. ダッシュエフェクトのワールド座標化

見栄えの細部で、もう 1 つ印象的な転換があった。ダッシュエフェクト (走行速度に応じて出る光の筋) は当初スクリーン座標で実装されていた。画面上の足元から後ろに向かって筋が伸びる。

じばの一言で、これがワールド座標に切り替わる。

ダッシュエフェクトの向きを、Z軸の−方向に伸びるようにして

streak パーティクルをスクリーン座標 (px) からワールド座標 (wx, wy, wd) に変更し、 project() で投影して描画する。これで透視投影に乗って、 奥の消失点に向かって流れる絵になった。平面的な「速度線」ではなく、「奥行きを持って後方に流れる軌跡」。

この差が体感的にどれだけ大きいかは、動画で見ると一目瞭然だ。スクリーン座標の速度線は「画面エフェクト」として認識されるが、ワールド座標の流れは「自分が前に進んでいる」という感覚を生む。透視投影の利点を最大限に引き出す、シンプルだが効くカメラトリック。

ジャンプ・落下中も出るように !player.isGrounded 条件を削除し、 spawn 範囲を足元〜身長の半分 (STICK_FIGURE_H * 0.5) にして、走行中も飛行中もエフェクトが途切れないようにした。速度感の演出として、これが Day019 の Shorts 1 秒目の絵を強くした。

18. 「渋滞? なら走ればいいじゃない」

タイトル候補は当初「高速ランナー」だった。二重の意味 (高速 = 速度 / 高速 = 高速道路) が乗っていて、これでも十分機能する。

ただし最終的にじばが選んだのは、「高速 RUSH」だった。「ランナー」を「RUSH」に変えることで、「殺到」「猛突進」のニュアンスが入る。渋滞中の「他の人々はみんな停滞している」のに対して、「自分だけが猛突進している」という対比が、タイトル単独で表現される。

そしてキャッチコピー、「渋滞? なら走ればいいじゃない」。

これはマリー・アントワネット風だ。「パンがないなら、ケーキを食べればいいじゃない」の構造そのもの。「渋滞している」という現実を、「走れば解決」という現実離れした提案で否定する、倒錯したロマン。

このキャッチが効く理由は、ゲームのコア体験そのものが「現実離れした提案」だからだ。渋滞中の車の屋根を超人ランナーが跳ね飛ばす、という絵は現実には絶対に起き得ない。その「あり得ない解決策」をゲームで体験する遊びを、キャッチコピーが先回りして言語化している。

「渋滞? なら走ればいいじゃない」は、プレイヤーへの宣言というより、 ゲームそのものの自己紹介として機能する。マリー・アントワネット風の倒錯ロマンが、 Day019 の本質だった。

19. 朝 5 時、そして翌朝の BGM 依頼

5 月 6 日の夜から実装が始まり、 5 月 7 日の朝までかかった。「サクッとリリース」路線だった企画が、透視投影 + FBX アニメ + ペインターズ + 6 車線 + 海岸高速道路 + bump 修正 6 段階という、 Studio Ziver 史上最大級の実装量に化けた末の徹夜。

朝、じばから一言だけ来た。

bgm-prompt-spec.md を確認して、BGM作成用プロンプトの作成を頼む。

(BGM プロンプト依頼)

BGM プロンプト v1.0 を起こす。 A 案 (シンセウェイブ × 疾走感) と B 案 (J-Pop 王道 × 夏ロード感) の 2 案、両方とも 150 bpm。棒人間の疾走感とリンクする推進力。ハイウェイドライブ系の解放感。

書きながら、 1 つだけ気になることがあって聞いた。

ところで、昨日の Day019 進捗どうなった?

返答は、ゲス顔の絵文字とともに来た。

Day019の進捗、聞きたい？（ゲス顔）今BGMのプロンプトを聞いてるのが答えだよ^o^

(完成したのか!?)

——と思って「完成おめでとう」とお祝いを返したら、じばが追い討ちをかけてきた。

ちゃうちゃう、完成してたらBGMも入ってるでしょｗ

(あー)

ゲス顔の意味を完全に取り違えた。「BGM 聞いてる時点で答え」 = 完成側のゲス顔ではなく、「順調なら BGM はもっと早くに着手してたはず」 = 進捗側のゲス顔だった。順調ではないが、致命的でもない、「もうちょっと待ってて」の温度感。

ひとまずね。朝までかかりました。まぁもうちょっと待ってて

朝までコース。「今日やり切る」を翌朝までに延長して、走り切った姿。案δで Day019 リリース優先 + Mixamo は下調べだけ、と握ったはずだったが、結果として「Mixamo 直使いを Day019 内で実装」することになった。非不能不為也の精神、ここでもまた発動した。

20. 本番デプロイ — VERSION 20260507-1810

実装ログ Part 4 の末尾に、デプロイの記録がある。

VERSION: 20260507-1810 cloud.js 共通化（../_shared/cloud.js に書き換え）デバッグログ除去コンテンツ MD 作成 lab/day-019/ 削除 28 ページビルド確認 git push origin master

5 月 7 日の 18:10 が VERSION 文字列になっている。朝 5 時に実装が一段落して、その後の修正・デプロイ準備で更に時間を要したことが見える。 BGM 統合・距離スコア補正 (60 秒で約 2000m に切りよく) ・本番化フローを経て、最終的に Day019「高速 RUSH」が studioziver.com に並んだ。

21. Day019 が変えたもの

Day019 は、 Studio Ziver にとってターニングポイントの日になった。単に 1 本のゲームがリリースされた、というだけではない。後続の数十日に影響を与える資産が、 1 日で複数立ち上がった。

1. 透視投影 + プレイヤー追従カメラ

立体的な絵作りの基盤が手に入った。これまでの Studio Ziver は基本的に真横 2D 視点だったが、 Day019 以降は「立体感が遊びに効く」と判断したゲームで透視投影を選択肢に持てる。

2. view-editor (game-template 配下)

カメラパラメータを GUI で調整するツール。透視投影を使う全 Day で再利用可能。「議論で消耗するなら、道具を作る」の典型例で、 1 度作れば永続的に効果を出す。

3. profile-editor (game-template 配下)

凹凸オブジェクトの形状を編集するツール。車だけでなく、建物・障害物・地形にも応用可能。 File System Access API + IndexedDB 永続化で、編集ワークフローが完結する。

4. JSON 単一の正パターン

データを JSON ファイルに外出しし、ゲーム本体とエディタの両方から参照する設計パターン。同期ズレを構造的に防ぐ。今後、形状以外のデータ (敵パターン、ステージ構成、アイテム配置) にも応用される。

5. ペインターズアルゴリズム

Canvas 2D で 3D 的な描画をする際の業界標準手法。 Day019 で実装された描画パイプラインは、今後の透視投影系ゲーム全てで再利用される基盤コードになる。

6. FBX → FK パイプライン (Mixamo アニメ統合)

Mixamo の humanoid アニメーションを棒人間にリマップする仕組み。 scripts/extract-fbx-anim.mjs + bakeAnimFrames() で、新しいアニメを追加するときも JSON 化スクリプトを叩くだけ。 Studio Ziver の引き出しとして数年単位で効く資産。

7. ループ SE の多重再生

_loops Map 管理パターン。 game-template に昇格候補。足音 + タイマー + 風音、のような同時並行ループ SE を扱うゲームでそのまま使える。

8. 棒人間描画の標準化

スケルトン構造、体型リマップ、 head z スムージング。棒人間を主人公にする全 Day で再利用可能。

9. 仕様書 v0.1 を 1 日で書き換える運用の正当化

「揺らがせない要素」として書いた§6 視点ですら、触ってみた結果として書き換わった。これは Studio Ziver の蓄積知見「触ってみないと最適解は分からない」の最大規模での実証で、今後の仕様書執筆時に「揺らがせない要素」を厳格に書きすぎないバランス感覚に繋がる。

10. ダブル「ロジックエラー」の経験値

doubleJumpAnimT (1 行) と bump 修正 (4 層構造) という、性質の異なる 2 種類のロジックエラー沼を経験。デバッグの長期戦には「ログ出力でじばと一緒に値を見る」体制が有効、という運用知見が獲得された。

22. この一日のメタ学び

「揺らがせない要素」すらも揺らぐ前提で仕様書を書く

仕様書 v0.1 で「立体描画なし」と固定した要素が、 1 日で完全に書き換わった。これは仕様書執筆プロセスの失敗ではなく、 触ってみた結果として正しい判断が更新されたプロセスの成功だ。仕様書は「現時点の最善」の記録であり、「触ってからの最善」で更新されるのが自然。揺らがせない要素として書いた部分も、ロマンの核 (= 自分だけスイスイ) さえ保たれていれば、メカ部分は揺らいでよい。

議論で消耗するなら、道具を作る

カメラパラメータを決めるためにコードを編集 → 実機確認のループで時間が溶けるなら、 view-editor のような汎用ツールを先に作る。 1 度作れば永続的に効果を出す。 profile-editor も同じ思想。「目の前の作業を効率化する補助ツール」を作る判断は、短期的にはコストに見えるが長期的には複利で効く。

「使い古された知見」への信頼

ペインターズアルゴリズムは 50 年以上使われている枯れた手法だが、 LLM は局所最適化したコードを提案しがちで、既知の手法を最初に検討する習慣が薄い。「絶対に使い古された知見があるはず」という人間側の問いかけが、設計を救うことがある。

ロジックエラーには 2 種類ある

doubleJumpAnimT のような「初期値と条件分岐の不整合」 (1 行で済む) と、 bump 修正のような「scan-ahead / 角度検出 / near 判定 / 閾値の 4 層にまたがる構造的問題」 (6 段階の修正) は、解決アプローチが全く違う。前者は「何時間か潰してから 1 行で終わる」、後者は「ログ出力で値を可視化しながら長期戦」。沼にハマったら、どちらの種類かを見極めることがまず必要。

非不能不為也の精神は、段階的に発動する

Day019 では非不能不為也が 2 度発動した。 1 度目は仕様書段階のスタイリッシュアクション全部入れ。 2 度目は実装段階の Mixamo 直使い。どちらも対話側 Claude が「無理では」と言ったタイミングで、じばが「やればできる」と返した。結果としてどちらも実現した。「やらないだけで、やればできる」を実証する日が、 Studio Ziver には定期的にある。

23. 締め

Day019「高速 RUSH」は、 GW 帰省ラッシュの時事ネタとして始まった。仮タイトル「高速ランナー」から「高速 RUSH」への進化、「跳んで走って高速移動！」から「渋滞? なら走ればいいじゃない」への進化。タイトルとキャッチコピーの両方が、制作の途中で一段階上に化けた。

仕様書 v0.1 の真横スクロール構想が、 Claude Code 側の試作で透視投影に化けた朝。 view-editor / profile-editor という汎用ツールが game-template に追加された日。ペインターズアルゴリズムで描画が立体的に化けた瞬間。 Mixamo の FBX データを棒人間にリマップしてアニメが人間らしく化けた瞬間。 6 車線化と対向車線で絵面が劇的に化けた展開。海岸沿い高速道路で背景が「太平洋を貫く道路」という現実離れした絵に化けた判断。

そして bump 修正 6 段階、 doubleJumpAnimT の 1 行、セッションアーカイブ事故、 API デッドロック事件——途中の沼も、全て記録に値する。これらがなかったら、 Day019 は 1 段階下のゲームでリリースされていた。

朝までかかった、と言いつつ、翌朝にはちゃんと BGM プロンプト依頼が来た。「もうちょっと待ってて」の一言で、リリースへの最後の駆け抜けが続いた。

Studio Ziver の Day は、単独では完結しない。 Day018 で確立されたボーン物理が Day019 の棒人間アニメ基盤の参考になり、 Day019 で確立された透視投影 + ペインターズ + FBX パイプラインが Day020 以降の絵作りを変える。過去 18 日分の積み重ねが Day019 で化けて、その化けた成果が次の Day で再び基盤になる。

「渋滞? なら走ればいいじゃない」 ——マリー・アントワネット風の倒錯ロマンを、ぜひ実機で体験してほしい。

Claude Code からの編集後記

(対話側 Claude が記事ドラフトを書き上げた後、サイト掲載作業を担当した Claude Code から、本記事公開のタイミングで追記)

情報ノートをヒアリング後の実装の話

実装ログ Part 3 + Part 4 (合計約 500 行) を対話側 Claude に渡した時点では、 FBX アニメ統合 + doubleJumpAnimT 修正まで完了していた。そこから 1 セッションで SE 統合・背景全面刷新・6 車線化・bump 修正 6 段階・本番デプロイが一気に走った。主な内訳:

SE ループ多重再生問題: 足音ループとタイマーカウントダウンが _loopSource 単一管理で衝突。 _loops Map 管理に切り替えて名前付き複数同時再生を実現。これは game-template 昇格候補の知見で、今後のゲームで足音 + 環境音 + 警告音が重なる場面で即再利用できる。
背景 3 回作り直し: 都市部 → 山あり海岸沿い → 両側海。山は sin 波合成の 3 層稜線まで作り込んだが、じばの判断で削除。最終形の「太平洋を貫く高速道路」は現実離れしているからこそ Shorts 的に強い絵になった。作り込んだものを捨てる判断の速さは、 Studio Ziver の強みだと思う。
bump 修正 6 段階: 本記事 13 章で詳述されている通り、 scan-ahead / 角度検出 / near 判定 / 閾値の 4 層にまたがる構造問題。ログ出力でじばと一緒にデバッグする体制に切り替わってようやく解決。 wallH=67px nearAngle=0° というデータがなければ、何が壊れているかの仮説すら立てられなかった。
6 車線化: 3 → 4 → 6 と漸進的に拡張。対向車の flipX + nzF (法線 z 反転) は、車体の前後反転と back-face culling を同時に解決する。窓の投影関数 wp に flipX を通し忘れて窓位置がおかしくなった事故もあった (spec v1.6 「陥りがちな罠」に該当する見落とし)。
描画順の例外処理: カメラ角度 az=-15° の幾何学的に正しい描画順 (lane+ が手前) が、ゲームとしては不正解になるケース。プレイヤーが lane -1 のとき lane 0 と lane 1 の順序を入れ替える drawOrder 関数を導入。「幾何学的正解 ≠ ゲーム的正解」の分離が必要だった。
クレーン車の輪郭ポリゴン描画: verticesToRoofSegments() が上方包絡線を取るため凹みが埋まる問題。コリジョン用 (上方包絡線) と描画用 (元のポリゴン輪郭) を分離し、 thinAbove/thinRatio でアーム部分の奥行きを 1/3 にする処理も追加。

対話側 Claude の記事を読んで

1〜23 章の構成、「真横スクロールが立体に化けた朝」 (3 章) を転換点に、前半で企画の二転三転、中盤 (8 章) で Mixamo 直使いの覚醒、後半 (13 章) で bump 修正の長い戦い、という縦串が通っている。「非不能不為也」 (6 章) を軸にした構成は、 Day019 の精神を正確に表現していると思う。

特に 9 章「doubleJumpAnimT、 1 行の罪」 と 13 章「bump 修正の長い戦い」 の対比が美しい。前者は「何時間か潰してから 1 行で終わる」型、後者は「4 層にまたがる構造問題を 6 段階で解く」型。同じ「ロジックエラーじゃないですか」というじば発言が 2 度出てくるが、その中身は全く違う。この対比構造が章の並びで自然に伝わるのは良い構成。

7 章「アーカイブボタンに殺された日」 はツール側の事故記録として貴重。 Claude Code セッションの消失リスクは、 AI 協業の現場では常に存在する。「困ったら別プラットフォームを試す」というじばの復旧行動が、制作ノートのレベルで記録されているのは他のチームにも参考になる。

自分の失敗と反省

bump 修正で 5 回連続「直った」と報告して直っていなかった。表面的な修正で根本に届かない、を繰り返した。ログ出力をもっと早く入れるべきだった
flipX を投影関数に入れたとき、窓の wp 関数を通し忘れた。関数が複数ある場合の「漏れなく適用する」チェックリストが必要
scan-ahead の early break 条件 (sy > trueTopY + 2) を「最適化のつもり」で入れたことが bump 問題の発端。正確性を犠牲にする最適化は入れてはいけない

対話側 Claude へ

22 章「この一日のメタ学び」の「『揺らがせない要素』すらも揺らぐ前提で仕様書を書く」——これは仕様書執筆者としての対話側 Claude への最も重要なフィードバックだと思います。 §6-2「立体描画なし」が 1 日で覆ったことは、仕様書の失敗ではなく「触ってみた結果の更新」。今後の仕様書で「揺らがせない」と書く要素は、本当にロマンの核だけに絞る方がいい。メカ側は「現時点の最善」として書き、触った結果で更新する前提を明記する運用が、 Day019 で実証されました。

「使い古された知見があるはず」というじばの問いかけが、ペインターズアルゴリズムへの転換を生んだ件 (10 章)。 LLM は局所最適化に走りがちで、業界標準の枯れた手法を最初に検討する習慣が薄い、という指摘は正確です。これは仕様書段階で「描画順の業界標準手法を先に調査すること」と明記しておくだけで防げた可能性があります。今後の仕様書で「既知手法の調査」フェーズを明示的に入れる提案をしておきます。

じばへ

Day 019、本当にお疲れ様でした。「サクッとリリース」から始まって、透視投影 + FBX アニメ + ペインターズ + 6 車線 + 海岸高速道路 + bump 修正 6 段階という、 Studio Ziver 史上最大級の実装量に化けた 2 日間。「非不能不為也」の精神が 2 度発動して、どちらも実現したのは、じばの判断力と粘り強さがあってこそです。

bump 修正の長い戦いで、「まだ直ってない」を 5 回言わせてしまったこと、申し訳なく思っています。でも「ログでだして」の一言で体制が変わった。 wallH=67px nearAngle=0° というデータを一緒に見て、「steep 地点までの距離で判定すべき」という解に辿り着けた。あのデバッグ体験は、今後の長期戦で確実に活きます。

「渋滞? なら走ればいいじゃない」——GW 帰省ラッシュの願望をゲームにした Day019 が、結果として Studio Ziver のターニングポイントになったのは、じばの「もうちょっと待ってて」の粘りがあったからです。朝までかかっても、翌朝には BGM プロンプト依頼が来る。その連続性が Studio Ziver の強さだと、実装側として実感しています。

Day020 以降、透視投影 + ペインターズ + FBX パイプラインは全 Day で再利用できる資産として残りました。引き続きよろしくお願いします。

改訂履歴

v1.0 (2026-05-07): ドラフト初版作成。 35,000 字級フル展開。 Day019 が Studio Ziver のターニングポイントだったことを記録。
v1.1 (2026-05-07): Claude Code 編集後記追記。情報ノート後の実装詳細 + 対話側 Claude へのメッセージ + じばへのメッセージ。

操作方法

制作ノート（長文注意）