最初のバージョンは3分だけ：インタラクティブ映像ゲームの最小閉ループをどう完成させるか

インタラクティブ映像ゲームの最初のプレイアブル版は、第一章の半成品ではなく、3分程度の完全な閉ループであるべきだ。動画に入り、一度の選択を理解し、差異を見て、一度の合流または結末が起こり、再び開始できる。それは同時に、ナラティブ、撮影、編集、再生、入力、状態、テストの問題を露呈させなければならない。

プロトタイプを書く前に、最も危険な三つの仮説を列挙する：動画は黒画面なしで切り替えられるか？プレイヤーは選択肢を理解できるか？俳優は状態の差異を演じられるか？そして3分のサンプルでそれらを集中的に検証させる。まずログイン、ストア、美しいホームページ、または二十個の空章を作ってはいけない；これらは核心体験の成立を証明できない。

『零点回拨』のプロトタイプは、一つの部屋、一人の俳優、二つの着信動画、一度の二択だけでよい。プレイヤーはまず改ざんされたタイムスタンプを発見し、応答か録音を選び、二つの短い分岐が異なる手がかりを生み、再び同じドアの外のノックという結末に入る。それはすでに観察、決定、フィードバック、状態、回収を含んでいる。

第一に、明確な開始目標；第二に、再生可能なメイン動画；第三に、出現タイミングが合理的なインタラクション；第四に、少なくとも二つの真の結果；第五に、保存される一つの状態；第六に、状態を確認できる後続フィードバック；第七に、再開始または再プレイの入口。いずれかが欠けると、重要な問題を本制作まで先送りする可能性がある。

素材は最終画質に達する必要はないが、リズムは本物でなければならない。スマートフォンで撮影してもよいが、静的テキストで動画読み込みを装ってはいけない；臨時俳優を使ってもよいが、選択肢の前後の演技のつながりを省略してはいけない。プロトタイプは安くあるべきだが、検証すべきリスクを回避してはいけない。

デフォルトで物語の冒頭を切り取ってはいけない。冒頭はしばしば世界紹介を担い、インタラクションが最も弱い。演技、分岐、状態回収、メディア切り替えを含む中盤の场景を選ぶ方が、制作ラインを検証できる。テスターが背景を理解できないのを避けるため、短い状況カードで必要な情報を提供する。

3分は厳格な制限ではなく、チームにフィードバックループを短縮させるためのものだ。テスターは10分以内に二つの異なるルートを完了すべきで、そうして初めてチームは素早く観察し比較できる。

プロトタイプは実際のファイル命名とノードデータから始める：ノードID、動画パス、選択肢、条件、書き込み、出口。プレイヤーは次の候補クリップをプリロードする必要があり、入力層はマウス、タッチ、またはゲームパッドを処理し、状態層は少なくとも一つの変数を保存し、ログはノード進入、選択肢表示、選択、退出を記録する。

クラウドセーブ、多言語パック、複雑な暗号化は一時的にしなくてよいが、インターフェースには場所を残す。ロジックをすべてボタンスクリプトに書くと、後の拡張と状態チェックの保守コストが増える；プロトタイプ段階でも明確なノードと変数定義を保つべきだ。

理解：プレイヤーは目標と二つの差異を復述できるか？テンポ：どこで注意が逸れ、読み終える時間はあるか？技術：黒画面、カクつき、音量の跳び、入力失效はあるか？感情：選択後に結果を期待するか、すぐにもう一方を試したいか？

テスト時はまず観察し、解説しない。完了後に「ボタンが何をすると思ったか」「どの変化に気づいたか」を尋ねる。「楽しいか」とだけ聞いて終わってはいけない。実際の行動と原話を記録し、個別の好みと繰り返し現れる問題を区別する。

まずプレイヤーに一度の選択を完了させ、それから尋ねる：「その時どの情報を知っていたか？」「このボタンが何をもたらすと思ったか？」「結果が出た後、どの変化に気づいたか？」行動前の予期と行動後の理解を分けることで、問題が選択肢、フィードバック、物語因果のどこで起きたか判断できる。

開始前に役割と現在のタスクだけを伝え、いつでも一時停止できると説明する。設計意図を事前に説明せず、プレイヤーに理解を証明するよう求めない。最初のルート終了後に別の選択を探索したいか尋ね、それが自発的か招待によるものかを記録する。

以下は架空の記入例であり、行動と原話は記録方法の演示に用いるもので、実際のプレイヤーフィードバックではない。

推測を観察として書いてはいけない。間は真剣な判断から来ることも、文案が不明瞭なことから来ることもある；まず何が起きたかを記録し、質問を通じて原因を区別する。単一プレイヤーの好みは原話のまま残し、直接すべての人の需要に一般化しない。

問題を整理する時、経路を完了できない、核心選択を理解できない、個人的な美的好みをそれぞれ処理する。各修正に担当者、対応ノード、再確認タスクを書き；同じ情境に戻って変更を確認し、「新版はより良くなったか」とだけ聞かない。

例えば五名の目標プレイヤーのうち、少なくとも四人が選択意図を明確に言える；初回再生で知覚できる黒フレームがない；両ルートが結末に到達できる；状態が再起動前に正しく保存される；少なくとも三人が自発的にもう一つの結果を見たい。基準は必ずしもそのまま使う必要はないが、テスト前に書き下ろし、チームが事後に結果に合わせるのを避ける。

未通過の時は、まず閉ループを直してから拡張する。3分の選択肢さえ理解させられないなら、五万字を書いても自動的に解決しない；二つの動画の切り替えさえ不安定なら、百本撮っても手戻りを拡大するだけだ。

実行可能ビルド、ソース素材、ノード表、変数表、テストスクリプト、問題記録、決定結論を保持する。どれが一時案で、どれが正式パイプラインに入るかを明確にする。プロトタイプは見て捨てる宣伝映像ではなく、最初の検証済み制作規範である。

知人のテスターは題材と俳優を好んでも、黒画面、誤タッチ、理解できない選択肢を経験しているかもしれない。「物語が好き」と「閉ループが信頼できる」を分けて集計する；完了を阻害する技術的問題は平均評価より優先すべきだ。テスト現場で製品を代わりに説明してもいけない。説明の成功はインターフェースの成功ではない。

サンプル通過後に、未知のデバイスでもう一度テストする：コールドスタート、初回ダウンロード、低ディスク容量、ヘッドホン切り替え、途中の画面ロック。3分の閉ループが開発PCでしか動かないなら、それは演示環境を検証したのであり、生産方案ではない。

プロトタイプ段階は絶えず磨き続けやすい。事前に規定する：核心基準が連続二回通過し、阻害問題がなく、パイプラインコストが估算できるなら、プロトタイプを終了しプリプロダクションに入る。視覚的瑕疵と追加機能は待ちリストに入れ、サンプルで無限に延伸しない。逆に、最も危険な仮説が未検証である限り、「本制作ではもっと良くなる」で飛ばしてはいけない。

次のステップ：一场景、一度の選択、二種類のフィードバックのために受け入れ質問を書き、同じ試玩タスクとインタビュー記録表を準備し、目標プレイヤーを招待して体験してもらう。上記のプレイヤー人数と通過基準はプロジェクト例であり、汎用統計標準ではない；小規模観察は問題発見に用いるもので、市場規模や成功確率を推測する根拠にはできない。