インタラクティブ映像ゲームをゼロから形にする：全工程・役割・成果物マップ

インタラクティブ映像ゲームを作るうえで本当に難しいのは、「動画を1本撮って、ボタンを2つ置く」ことではありません。物語、選択肢、素材、プログラム、テストが、常に同じプロジェクトを指している状態を保つことです。最も堅実な方法は、制作を明確な成果物を持つ10の段階に分けることです。企画立ち上げ、コア体験、物語、分岐システム、プロトタイプ、制作管理、撮影、ポストプロダクションと実装、テスト、リリース後の振り返り。前の段階のアウトプットは、次の段階でそのまま使えるものでなければなりません。

本記事は、初めてインタラクティブ映像ゲームを担当する脚本家、監督、インディー開発者、小規模チームの責任者に向いています。読み終えたあとには、自分たちの制作ルートを描き、各ステップを誰が担当し、何を納品し、どの時点で先に進んではいけないのかを判断できるはずです。

DramaFork は、インタラクティブコンテンツの制作・配信プラットフォームです。本記事では、プラットフォーム内の企画案『零点回拨』を例として使いますが、プロセス自体は特定のツールに依存しません。

企画立ち上げ段階で答えるべき問いは4つあります。誰が遊ぶのか、その人はなぜ今遊びたいのか、プレイヤーは物語の中で何をするのか、チームはその規模を引き受けられるのか。成果物は1ページのプロジェクト・ポジショニングカードで、少なくともターゲットプレイヤー、配信プラットフォーム、想定プレイ時間、プレイヤーの中核動詞、登場人物とロケーションの上限を含めます。

『零点回拨』を例にすると、物語のフックは「夜勤のカスタマーサポートが24時間後からの電話を受ける」です。しかし、遊びとしての約束はこの一文ではありません。プレイヤーは限られた時間の中で、電話を信じるべきかを判断し、味方を選び、午前0時以降の結果を変える。この後者の文だけが、選択肢設計とプロトタイプ検証を導くことができます。

企画立ち上げの受け入れ基準もシンプルです。チームが、プレイヤーが繰り返し実行する行動を一文で説明できるか。そして初版でやらないことを明確にできるか。答えがまだ「没入型のストーリー体験」であるなら、スコープはまだ具体化されていません。

1回目は、テーマを葛藤に翻訳することです。たとえば「信頼」は人物のセリフに出てくるだけでは不十分で、プレイヤーが結果を引き受けなければならない決断になっている必要があります。

2回目は、葛藤を選択肢に翻訳することです。各選択肢には、入口となる情報、理解できる選択内容、状態変化、見えるフィードバックが必要です。状態変化のない選択肢はキャラクター表現として残してもかまいませんが、それが本筋を変えるかのように見せてはいけません。

3回目は、選択肢をデータに翻訳することです。チームは、ノード番号、遷移先、出現条件、変数の書き込み、必要な映像、あり得るエンディングを統一する必要があります。脚本家が使う「第2場の口論」、プログラムが使う scene_02、ポストプロダクションで使うファイル名が、互いに対応していなければなりません。

4回目は、データを制作タスクに翻訳することです。ノード表は、シーンマトリクス、出演者日程、小道具、ヘアメイク、カット、音声、字幕、テストケースへ展開する必要があります。ここまで来て初めて、アイデアは見積もり可能なプロジェクトになります。

段階 必須成果物 次へ進む条件 企画立ち上げ ポジショニングカード、スコープのガードレール プレイヤー、プラットフォーム、時間、中核行動が明確 コア体験 コアループ、インタラクション密度表 3分以内に1回の完全なフィードバックが発生する 物語・キャラクター ビート表、キャラクター間の情報差マトリクス 主要な葛藤をプレイヤーの行動で変えられる 分岐システム ノード表、変数辞書、エンディングマトリクス すべての遷移を追跡でき、孤立ノードがない プロトタイプ 遊べる3分版 少なくとも1つのルートが開始からエンディングまで到達できる 制作管理 シーンマトリクス、予算、スケジュール 独立素材量が予算内に収まる 撮影 番号付きの映像・音声素材 素材をノード表に沿って項目ごとに照合できる ポストプロダクションと実装 配信用映像、字幕、UI、セーブ 選択の切り替えが安定し、状態保存が正しい テスト ルートカバレッジとデバイスレポート ブロッカーがゼロになり、主要エンディングに到達できる リリース後の振り返り ストアページ、Build、データダッシュボード 宣伝上の約束と実際のバージョンが一致している

Steam のリリースフロー自体も、ストアページと製品 Build それぞれのチェックと審査を求めます。そのため、「ゲームが完成してからリリースを考える」進め方は、たいてい手戻りを生みます。公式の Steamworks 入門ガイドでは、Build を制作するのと並行してストアでの見せ方を準備することが推奨されています。

3人のチームでは、脚本家がナラティブデザインも担当し、監督が制作管理も担い、プログラマーがテストツールも担当することがあります。それ自体は問題ありません。本当に危険なのは、同じ人が2つの仕事を担当しているからといって、その2つの仕事の間にある成果物を省略してしまうことです。

たとえば脚本家兼プログラマーであっても、ノード表は必要です。3週間後には、自分自身でも記憶だけで特定の変数がどこで書き込まれたのか判断できなくなるからです。監督兼編集者であっても、スクリプト記録とアセット番号は必要です。そうでなければ、撮り直した素材を旧分岐と正しく差し替えられません。役割は統合できますが、インターフェースは消してはいけません。

多くのプロジェクトは、10万字の脚本を書き終え、場合によっては全素材を撮り終えてから、初めてプレイヤーに操作させます。その時点で「選択肢に判断材料がない」「選択肢の意味が理解できない」「映像の切り替えがテンポを壊す」と分かっても、修正コストはすでに書き直し、撮り直し、再編集になっています。

よりよい順序は、まず3分のプロトタイプを作ることです。5つのノード、2回の選択、3つのエンディング。仮テキストでも低コストの映像でも構いません。プロトタイプで検証すべきなのは画面品質ではなく、プレイヤーが自分は何を決めているのか分かるか、選択後に変化を感じられるか、チームが状態を追跡できるかです。

新しく1ページのプロジェクト・ポジショニングカードを作り、ターゲットプレイヤー、利用シーン、プレイヤーの中核動詞、プラットフォーム、時間、キャラクター上限、シーン上限、初版でやらないことのリストだけを記入してください。まだ完全なストーリーを書き始める必要はありません。

次の記事では、まずインタラクティブ映画、FMVゲーム、インタラクティブ短編ドラマ、ビジュアルノベルを区別します。プロダクト形態を選び間違えると、その後の脚本、撮影、技術方針が根本から衝突します。