そろそろ帰ろう

3人が互いを待たない層分離

2日間の開発で最も危険なのは「Android実装が終わるまでロジックが書けない」という直列化。そこで入出力をインターフェースで切り出した。

Android層  ──IPlayerInput──▶  ゲームロジック層  ──公開イベント──▶  UI層
           ◀─IFeedbackPresenter─

• IPlayerInput（IsTurnedBack / ShutterDown）に対し、実機用のGyroInputとEditor用のKeyboardInputを用意。Android実装の完成を待たずロジックを完成まで持っていき、当日は実機実装を差し込むだけにした
• IFeedbackPresenter（SetLight / Flash / Vibrate）も同様に抽象化。実機LEDが未完成でも、Editorの白フラッシュ実装のままゲームは完成させられる
• 振り返り閾値の保持はAndroid層に置いた。閾値調整は実機を持っている担当者が自分の手元だけで完結できるべきだと判断したため
• UI担当向けにInspectorから全イベントを手動発火できるデバッグパネルを事前に用意し、ロジック完成待ちで演出制作が止まらない状態を作った

設計の重さを意図的に選ぶ

普段使っているR3・DIコンテナ・汎用ステートマシンは、今回あえて採用していない。

短期ハッカソンで求められるのは長期運用を見据えた堅牢な設計ではなく、チーム全員が同じ認知コストで触れる設計だと判断した。境界だけをインターフェースで固め、その内側の実装は各担当の裁量に任せる。設計書にも「重厚な設計を目指すのではなく、期間内で完成させるために構造として取り組みやすい環境を目指す」と明記した。

崩れてはいけない不変条件の明文化

企画が成立するために絶対に守るべき条件を、実装前にレビュー項目として言語化した。

• 正面を向いている状態では靄を表示しない（振り返る意味が消えるため）
• 靄を音の種別で出し分けない（第2判断が音から視覚に置き換わるため）
• 靄と音の強調にフェードを入れる（チラ見が最小コスト戦法になるため）
• 判定ウィンドウだけは姿勢によらず実時間で減らす（振り返っている間だけ猶予が延びるため）

特に「靄の出し分け防止」は、UIへ通知するイベントOnAimStartedにあえて引数を持たせないことで構造的に不可能にした。ルールをドキュメントで守らせるのではなく、型で守らせる判断。

当日調整を数値だけで回す

2日目の午後はバランス調整に充てる前提だったため、判断猶予・イベント間隔・抽選率・日別難度・電池消費量などをScriptableObjectへ外出しし、コードを触らず調整できる状態にした。

説明文を読ませないチュートリアル

本編前に約30秒のDay 0を置き、環境音と異常音の両方を体験させる。汎用ステージシステムは作らず、IDaySequencerの別実装（TutorialSequencer）として固定シーケンスを供給する構成にしたため、GameManager側の分岐は最小限に収まった。

初日のうちに「説明なしでルールが伝わるか」の初見実機テストを実施し、見つかった最大の問題を1件だけ直して再プレイするというゲートを設けた。