分岐の爆発を避ける方法:「状態を保持した合流」でインタラクティブ映像ゲームのコストを抑える
ツリー型、折り返し型、ハブ型と状態を保持した合流によって、インタラクティブ映像ゲームの映像素材、状態、テストのコストを抑えます。

はじめに
分岐の爆発を避けるとは、すべての選択肢を削除することではなく、物語の経路とプレイヤーの状態を分けることです。場面は共通の本筋に戻っても、情報、関係、資源、約束は引き継がれ、価値の高い少数の地点で再び結果として表れます。
経路が恒久的に分かれる二者択一を10回連続すると、理論上は1,024個の終端が生まれます。実際に予算を見積もるべき対象は、理論上のルートだけでなく、個別に制作する映像、状態別のバリエーション、ローカライズ、テストの組み合わせです。
3種類の構造をどう組み合わせるか
ツリー型は根幹となる立場や結末に適しており、違いが最も大きく、コストも最も高くなります。折り返し型は、局所的な探索で異なる情報を提供した後、本筋に戻します。ハブ型では、プレイヤーが複数のノードを異なる順序で調査できます。管理可能なプロジェクトでは通常、「ハブで収集—折り返しでフィードバック—少数のツリー型の結末」を採用します。
最小限の4種類の状態
knowledge:何を知っているか;relationship:信頼、敵意、または借り;resource:アイテム、時間、証拠、負傷;commitment:約束、裏切り、公にどちらの側につくか。
各変数には、書き込み地点と読み取り地点が必要です。書くだけで読まない変数は無駄な複雑さを生み、出所がないのに読み取るだけでは、テストできない隠れたルールになります。
コストの見積もり
総コスト ≈ 個別制作する映像の分数 × 単位コスト + 状態別バリエーション数 × バリエーションのコスト + ノード数 × テストコスト
これは計画用の式であり、統一された料金表ではありません。合流は個別制作する映像を減らしますが、状態設計やQAをなくすわけではありません。
| 状態 | 書き込みノード | 読み取りノード | 目に見えるフィードバック | テスト値 |
|---|---|---|---|---|
| trust_A | N03 | N07/N09 | 呼び方、援助するかどうか | -1/0/1 |
選択がアイデンティティを恒久的に変える場合、根幹となる道徳的立場を示す場合、あるいはプレイヤーに大きな代償を求める場合は、無理に合流させるべきではありません。状態を保持した合流の目的は、結果を消し去ることではなく、違いが不可欠な部分に予算を集中させることです。
予算から構造を逆算する
まず、個別制作できる映像の分数、テキストのバリエーション数、テストの実施回数の上限を決め、それから共通の幹、局所的な分岐、結末に配分します。先に完全な二分木を描き、書き終えてから素材の量が予算を超えていると気づくような進め方は避けましょう。
例えば、1回のプレイが10分で、個別制作する映像の予算が16分なら、約10分を共通の幹に、3分を2回の局所的な分岐に、3分を結末のバリエーションに配分できます。この比率は業界標準ではありませんが、その違いに個別の素材を制作する価値があるか、チームで議論する必要が生まれます。
状態変数はなぜ少ないほうがよいのか
ブール変数を1つ追加するたびに、理論上の組み合わせが増えます。状態はコストのかからない軽量な代替手段ではなく、映像のコストを執筆とQAのコストに変えるだけです。複数回読み取れ、プレイヤーが実感でき、テーマに関係する変数を優先して残します。無関係な台詞1行にしか影響しない状態は、統合や削除が可能です。
合流ノードをどう書くか
まず共通の目標を書き、その後、必ず保持するべき違いを列挙します。主となる映像は再利用できますが、冒頭の台詞、人物の立ち位置、使えるアイテム、その後の選択肢は状態に応じて変わります。前の場面で負傷した人物が、合流後に突然回復していてはいけません。プレイヤーが仲間を裏切ったばかりなのに、相手が標準の台詞で協力するような展開も避けましょう。
合流のチェックリストには、流入元の経路、引き継ぐ状態、共通のショット、差分の台詞、無効にする選択肢、次の読み取り地点を含めるべきです。これにより、脚本、編集、QAが同じルールを使えます。
3種類の構造にはそれぞれリスクがある
ツリー型のリスクは素材が指数関数的に増えること、折り返し型のリスクはプレイヤーが寄り道に意味がなかったと感じること、ハブ型のリスクは訪問順によって人物が知るはずのない情報を知ってしまうことです。ツリー型は予算の上限で制御し、折り返し型は状態を結果に反映させ、ハブ型には明確な前提条件と完了フラグを設けます。
分岐図が制御不能になっていると気づくには
チームが変数の読み取り場所を説明できない、1つの事実を修正するのに十数個のノードを検索する必要がある、同じセーブデータで結末を再現できない、1〜2行しか違わない分岐が大量にあるのにそれぞれ全区間を撮影している、ストーリーグラフに担当者のいない行き止まりがある。これらはいずれも、構造を縮小する必要がある兆候です。
縮小は、必ずしも選択肢の削除を意味しません。似た状態を統合する、価値の低い映像をテキストや音声のバリエーションに置き換える、合流を早める、あるいは複数の序盤の決定が1つの価値の高い場面に共同で影響するようにできます。
プレイヤーが陣営、アイデンティティ、核心となる関係、テーマに対する立場を変えるときこそ、本当に分岐させる価値があります。状態を保持した合流でほかの部分の予算を節約するのは、まさにこうした重要な違いをしっかり作り込むためです。
合流地点の受け入れ確認
合流ノードに入る経路を1つずつ確認します。人物が以前の約束を覚えているか、アイテムや負傷に整合性があるか、プレイヤーに違いを示すフィードバックが少なくとも1つあるか、その後の条件が重要な状態を引き続き読み取れるか。ルートの違いを長いナレーションでしか説明できないなら、合流が早すぎます。その違いを以後まったく使わないなら、その状態の削除を検討すべきです。
制作スケジュールでも、実際の分岐ごとに追加される脚本、ショット、音声収録、ローカライズ、テスト経路を反映する必要があります。テーマ上の価値がこれらの長期的なコストを負担するに足る場合にのみ、ツリーを拡張します。それ以外の変化は、まず台詞、ショット、権限、状態のフィードバックで表現し、深みをノード数ではなく、結果の密度から生み出します。


