AIとゼロから作る脱出ゲーム開発日記 第9話:「隠しアイテムを追加するだけ」のはずが、本編より大掛かりになった話

Claude Codeのターミナル画面と、おもちゃ箱から現れる隠し扉、星付きの小物アイコンが並ぶデスクのイメージ画像。 開発日記

前回までのあらすじ

前回は、釣り・プール・虫取りの3ルート本編が完成した一方で、これまで「問題なし」としてきたアセットに想定よりずっと根深い透過バグが潜んでいたと判明し、検証方法そのものを見直す回でした。

今回は、その第8話の「まとめ&次回予告」に残した持ち越し事項(bug-net.pngの判定食い違い、ガラス瓶の半透明表現、QAツール未レビュー、旧素材の整理、git未コミット問題)を片付けるところから始まります。ついでに軽い気持ちで「隠しアイテムと隠し部屋も追加しよう」と決めたのですが、結果的にこのおまけ機能のほうが、持ち越し事項の解消より大掛かりな作業になりました。

第1章:持ち越し事項の総整理と、丸ごと未コミットだったgit問題

第8話の時点で明らかになっていた通り、escape-game-templateはサイクル22以降の変更が一切コミットされていませんでした。まずここから手を付けています。

実データを確認したところ、直近コミットは本当にサイクル22のままで、それ以降のすべての変更が未コミット状態でした。あわせてassets/images/をconfig.jsの参照一覧と突き合わせたところ、画像38点・音声3点が使われていない「おでかけ素材の混入」だったことも確定し、削除しています。tools/asset_pipeline/は相変わらずGitHub上に存在せず、レビューできない状態が続いていました。meta.debugはすでにfalseに戻っていたので対応不要でした。

ついでにodekake-game/index.htmlのタブタイトルと見出しが「密室からの脱出」時代のまま残っているのも見つけましたが、調べてみるとgame.js起動時にdocument.titleと見出し要素はGAME_CONFIG.meta.titleで上書きされる実装がすでにあり、実際のプレイヤーにはほぼ見えていなかったと判明しました。「実バグ」と最初に言ったのは言い過ぎで、その場で訂正しています。

未コミット分は、機能単位で5つのコミットに整理しました。サイクルごとの粒度までは分解できず、「decorative/flipXオブジェクトの追加」「関連CSS」「ルートスコアリングと容量制限」「door.png更新」「バージョン番号」という機能単位が実用上の限界でした。作業のたびにコミットしておけば本来こんなことにはならなかった、という反省が残ります。

第2章:隠しアイテム・隠し部屋の実現性検証と、次の選択肢の洗い出し

持ち越し事項の整理と並行して、次の展開として挙がっていた「隠しアイテム・隠し部屋」が実際に作れるかを検証しました。

escape-game-template自身にすでにある「木箱を調べると秘密のメモが出てくる」という仕組みが、examineタイプにsetFlagを組み合わせたものだったため、これがそのまま流用できると分かりました。同じく、zoomタイプのオブジェクトにも全オブジェクト共通のrequiresFlag可視性フィルタが使えるので、「特定のフラグが立つまで扉自体が存在しない」隠し部屋も無改修で作れると判定しています。

このタイミングで、隠しアイテム・隠し部屋以外の展開候補も一覧化しました。ルート別BGM出し分け(既存のAudio_.startBgm(id)が任意ID対応済みで小さな追加)、4つ目のルート追加(無改修〜小さな追加)、タイムアタックや周回ごとのランダム配置(どちらも構造変更が必要)などです。判断材料として提示するにとどめ、実装の優先順位はこちらで決める形にしています。

第3章:odekake-gameのgit初期化と、独自透過QAツールの実装

odekake-gameはここまで一度もgit管理下に置かれていなかったので、独立リポジトリとしてgit initしました。あわせて、その場しのぎのPythonスクリプトで済ませていた透過チェックを、tools/transparency_qa.pyとintentional_transparency.jsonという再利用可能な形にまとめています。

素の閾値判定だけで全画像をスキャンしたところ、窓ガラスや浮き輪の穴のような、意匠として正しい切り抜きまで大量に誤検知しました(1回目の実行はPASS 9・REVIEW 10・FAIL 11という、ノイズだらけの結果でした)。これまでのセッションで目視確認済みの「意図的な透過」を許可リストに一件ずつ追加していくことで、ようやく実用的な精度(PASS 23・REVIEW 6・FAIL 1)まで収束させています。この過程で、bathroom-shelf.pngの以前の修正箇所に、境界のズレによる薄い透過の取りこぼしが1本残っていたのを新たに発見・修正しました。

このタイミングで隠しアイテム3点(examineタイプ、ルート別のボーナスフラグ)と隠し部屋(おもちゃ箱を調べると出現するzoomポータル、背景画像なしでエンジン標準のグラデーションを使用)も実装しています。tryExitのスコア判定には、ボーナスフラグが立っていればOK評価を1段階パーフェクトへ格上げする分岐を追加しました。ここだけは「無改修」では済まない、小さなコード追加が必要な箇所でした。新規アセットが未発注の状態でも、エンジンのプレースホルダー表示にフォールバックする形で、実装と動作確認まで先に済ませています。

第4章:残りのREVIEW項目を確認し、発注リストを確定

透過QAツールがREVIEWに分類していたbackpack.png・hat.png・rug.png・table-chairs.png・towel.pngの5点を、実背景色との合成で改めて確認しました。結果はすべて、家具の陰影やハイライトによる誤検知で、本物の不具合は無しと確定しています。

これで、隠しアイテム3点+隠し部屋の演出素材2点、計5点の発注リストを、画風ガイドライン(特定作品を模倣しない、丸みのある子供向けアニメ調)つきで作成できました。

第5章:自分でプレイして見つかった、”直したはず”の3件

発注が済んで一段落したところで、実際にゲームを通しでプレイしてみたところ、「洗面所の棚」「玄関の扉」「虫かご」が透けて見える、という不具合に気づきました。いずれも過去に一度修正済み、あるいは意図的な表現だと判定していたファイルです。

実際にゲーム画面をズームして確認すると、原因はどれもすっきり一つに絞れるものではありませんでした。虫かごは正面パネルが模様の無いのっぺりしたグレー一色だったせいで、視覚的に「中身が空っぽ」に見えていました。洗面所の棚は、以前の応急処置(単色での塗りつぶし)が質感の無いただのシミにしか見えていませんでした。玄関の扉は、窓ガラスの縁にピクセル単位の薄い半透明が散らばっていて、大きな穴というほどではないもののエッジがガタついている状態でした。

技術的な「アルファ抜け」と言うより、質感不足や表現の粗さが混ざっている、という歯切れの悪い評価にとどまりましたが、結論はどれも同じで作り直しを依頼しています。「透過は技術的に正しくても、実際のゲーム画面で見て破綻して見えないか」が最終的な判断基準になる、と改めて確認した回でした。ちなみにこの確認作業の途中、開いたままのブラウザタブを閉じ忘れてBGMが鳴りっぱなしになるという、以前も指摘されたのと同じミスを今回も繰り返しています。

第6章:納品8点の検証で見つかった、まったく新しいパターンのバグ

隠しアイテム3点・隠し部屋演出2点・作り直し3点、あわせて8点が納品されました。自前のtransparency_qa.pyでスキャンしたところ、secret-room-graffiti.png(落書きのデカール)が大量にFAIL判定されましたが、これは意匠として正しい「線と線の間の広い透過」で、誤検知と確認できたので許可リストに追加しています。

一方で、hidden-shell.pngだけは本当に異常でした。外周のピクセルを直接調べたところ、クロマキー背景の除去がまったく行われておらず、緑色の背景がアルファ値255の不透明のまま残っていたのです。他の7点は正しくアルファ値0で抜けていたので、この1点だけパイプラインの処理が漏れていたことになります。これは「穴が開いている」の逆パターン、つまり背景がまったく透過していないケースで、これまでのQAスクリプトの検出項目には存在しませんでした。外周の色相を見る新しいチェック(check_unkeyed_background)を追加し、他の7点は実背景合成で再確認した上で先に統合、hidden-shell.pngだけ再処理を依頼しています。

OpenMontage側からは、クロマキー抽出ツール自体は正しく修正済みだったが、納品フォルダへコピーする際に誤って修正前の古いローカルファイルをコピーしてしまっていた、という原因説明とともに修正版が届きました。いつも通り鵜呑みにせず、ファイルの更新日時とサイズが実際に変わっていること、外周のアルファ値が正しく0になっていることを直接確認してから統合しています。これで発注した8点すべてが、実際にゲームへ反映されました。

第7章:レイアウト微調整と、片方だけ取り残されたオブジェクトサイズ

最後に、配置編集モードで4シーン分(玄関・洗面所・キッチン・自分の部屋)のレイアウトJSONを作成し、そのまま反映しました。おもちゃ箱(toybox-closed)は83×78から228×250へ大きく拡大され、開いた状態の収納ボックスらしい見た目になっています。

ところが反映後、「大きくしたおもちゃ箱をクリックすると小さいおもちゃ箱になる」という報告が入りました。調べてみると、調べる前の見た目であるtoybox-closedだけが拡大されていて、調べた後に同じ場所へ出現する隠し部屋の入り口toybox-portalは、83×78の旧サイズのまま取り残されていました。requiresFlagで表示が制御されているため、フラグを立てていない通常の編集モードではtoybox-portal自体がそもそも見えず、一緒に編集されなかったのが原因です。toybox-portalのx・y・w・hをtoybox-closedと同じ値に修正し、実機でクリック後もサイズが変わらないことを確認しました。

フラグで表示が切り替わるオブジェクトは、編集モードでは「今見えている方」しか触れません。対になっているオブジェクトをリサイズするときは、両方の状態を意識的に確認しないと、今回のように片方だけ古いサイズのまま取り残されてしまいます。

🎮 今回のバージョン

隠しアイテムと隠し部屋が追加された、最新の3ルート本編です。おもちゃ箱を調べてみると、何か見つかるかもしれません。

💬 読者へのヒアリング

隠しアイテム・隠し部屋、実際に見つけられたでしょうか。ヒントが分かりやすすぎた・分かりにくすぎた、どちらの感想も参考になります。透過やレイアウトのズレなど、気になった細かい点もぜひ教えてください。

まとめ&次回予告

今回もいくつか教訓が残りました。地味な整理作業ほど後回しにすると積み上がるという話、透過バグには「応急処置が質感不足で結局透けて見える」「クロマキー抜けが丸ごと未処理」という、これまでと違う新しいパターンが2つ潜んでいたという話、そしてフラグで切り替わるオブジェクトは編集モードで見えている方しか触れないという話です。AIが「原因を特定して修正した」と報告してきても、ファイルの更新日時・サイズ・実際のピクセル値までは自分の目で見るまで確定させない、という習慣も今回また役に立ちました。

タイトル通り、「隠しアイテムを追加するだけ」のつもりが、本編の持ち越し事項の解消より大掛かりな作業になってしまいました。持ち越し事項もまだいくつか残っています。odekake-game側のmeta.debug: true(レイアウト編集用に有効のままでリセット未実施)、依然未プッシュのままのtools/asset_pipeline/、次回発注予定のまま止まっているbug-net.pngの網目線調整、そして一覧化しただけでまだ手を付けていないB案の残り選択肢(ルート別BGM・4つ目のルート・タイムアタックなど)です。次回はこのあたりから、どれに着手するか考えていきます。

コメント

タイトルとURLをコピーしました