インタラクティブ映像ゲームを0から1へ：制作工程・役割・成果物の全体マップ
インタラクティブ映像ゲームを作るうえで本当に難しいのは、「動画を撮ってボタンを二つ置くこと」ではなく、物語、選択肢、素材、プログラム、テストが常に同じプロジェクトを表すようにすることだ。最も堅実な方法は、制作を明確な成果物のある十段階に分けること。企画立案、コア体験、物語、分岐システム、プロトタイプ、制作準備、撮影、ポストプロダクションと組み込み、テスト、リリースと振り返りである。前の段階の成果物は、次の段階でそのまま使えるものでなければならない。
はじめに
インタラクティブ映像ゲームを作るうえで本当に難しいのは、「動画を撮ってボタンを二つ置くこと」ではなく、物語、選択肢、素材、プログラム、テストが常に同じプロジェクトを表すようにすることだ。最も堅実な方法は、制作を明確な成果物のある十段階に分けること。企画立案、コア体験、物語、分岐システム、プロトタイプ、制作準備、撮影、ポストプロダクションと組み込み、テスト、リリースと振り返りである。前の段階の成果物は、次の段階でそのまま使えるものでなければならない。
この記事は、初めてインタラクティブ映像ゲームを担当する脚本家、監督、個人開発者、小規模チームの責任者に向けたものだ。読み終えたら、自分たちの制作ルートを描き、各工程を誰が担当し、何を引き渡すのか、そしてどのような場合に先へ進んではいけないのかを把握できるはずだ。
DramaForkは、インタラクティブコンテンツの制作・公開プラットフォームである。この記事では、プラットフォーム内の企画案『零点回拨』を例に使うが、工程そのものは特定のツールに依存しない。
最初の段階は脚本を完成させることではなく、企画が成立することを示すこと
企画立案の段階では、四つの問いに答える必要がある。誰が遊ぶのか、なぜ今遊びたいのか、プレイヤーは物語の中で何をするのか、チームはこの規模を担えるのか。成果物は1ページのプロジェクト・ポジショニングカードで、最低限、想定プレイヤー、リリース先のプラットフォーム、想定プレイ時間、プレイヤーの主要な行動を表す動詞、登場人物数とロケーション数の上限を含める。
『零点回拨』を例にすると、物語のフックは「夜勤のカスタマーサポート担当者が、24時間後からの電話を受ける」だ。しかし、遊びとして約束する内容はこの一文ではない。プレイヤーが限られた時間の中で電話の相手を信用できるか判断し、味方を選び、午前0時以降の結果を変えることだ。選択肢の設計とプロトタイプの検証を導けるのは、後者だけである。
企画立案の合格基準も簡単だ。プレイヤーが繰り返し行う動作をチームが一文で説明でき、初版では何をしないかを明確にできるか。答えがまだ「没入感のある物語を体験する」なら、範囲はまだ具体化されていない。
物語をシステムにするには、四回の翻訳が必要
一回目は、テーマを対立へ翻訳することだ。たとえば「信頼」は登場人物のせりふに出てくるだけではいけない。プレイヤーがその結果を引き受ける決断にしなければならない。
二回目は、対立を選択へ翻訳することだ。それぞれの選択には、選択前に提示される情報、理解できる選択肢、状態の変化、目に見えるフィードバックが必要になる。状態を変えない選択肢は人物表現として残してもよいが、本筋を変えるように見せかけてはいけない。
三回目は、選択をデータへ翻訳することだ。チームはノード番号、遷移先、出現条件、変数への書き込み、必要な動画、到達しうるエンディングを統一する必要がある。脚本家が使う「二回目の口論シーン」、プログラマーが使う scene_02、ポストプロダクションで使うファイル名が、互いに対応していなければならない。
四回目は、データを制作タスクへ翻訳することだ。ノード表を、ロケーションマトリクス、俳優の稼働日数、小道具、ヘアメイク・衣装、ショット、音声、字幕、テストケースに展開する。ここで初めて、アイデアは費用を見積もれるプロジェクトになる。
十段階で、それぞれ何を引き渡すのか
| 段階 | 必須の成果物 | 次へ進む条件 |
|---|---|---|
| 企画立案 | ポジショニングカード、範囲の制約 | プレイヤー、プラットフォーム、プレイ時間、主要な行動が明確 |
| コア体験 | コアループ、インタラクション密度表 | 3分以内に一通りのフィードバックが発生する |
| 物語・登場人物 | ビートシート、登場人物間の情報格差マトリクス | プレイヤーの行動によって主要な対立を変えられる |
| 分岐システム | ノード表、変数辞書、エンディングマトリクス | すべての遷移を追跡でき、担当不明のノードがない |
| プロトタイプ | 遊べる3分版 | 少なくとも一つの経路で冒頭からエンディングまで到達できる |
| 制作準備 | ロケーションマトリクス、予算、スケジュール | 個別に必要な素材の量が予算内に収まる |
| 撮影 | 番号を付けた映像・音声素材 | ノード表と素材を一つずつ照合できる |
| ポストプロダクションと組み込み | 公開用動画、字幕、インターフェース、セーブ機能 | 選択に伴う切り替えが安定し、状態が正しく保存される |
| テスト | 経路網羅とデバイスの報告書 | 進行を妨げる問題がゼロで、重要なエンディングに到達できる |
| リリースと振り返り | ストアページ、Build、データダッシュボード | 宣伝で約束した内容と実際のバージョンが一致する |
Steamのリリース工程でも、ストアページと製品のBuildはそれぞれチェックと審査を完了する必要がある。そのため、「ゲームが完成してからリリースを考える」と、たいてい手戻りが生じる。公式の Steamworks入門ガイドは、Buildの制作と並行してストアでの見せ方を準備することを勧めている。
小規模チームでは兼任してもよいが、引き渡しの関係は省けない
3人のチームなら、脚本家がナラティブデザインを兼任し、監督がプロデューサーも務め、プログラマーがテストツールも担当することがある。それ自体に問題はない。本当に危険なのは、同じ人が二つの仕事を担っているからといって、その仕事の間で引き渡す成果物を省くことだ。
たとえば脚本家とプログラマーを兼任していても、ノード表は必要だ。3週間後には、本人も記憶だけでは特定の変数がどこで書き込まれるのか判断できない。監督と編集者を兼任していても、撮影記録と素材番号は必要になる。そうでなければ、撮り直した素材を既存の分岐の素材と正しく差し替えられない。役割はまとめられるが、役割間のインターフェースをなくしてはいけない。
最もよくある間違いは、検証が遅すぎること
多くのプロジェクトでは、10万字の脚本を書き終え、場合によってはすべての素材を撮り終えてから、初めてプレイヤーに操作してもらう。その時点で「選択に必要な情報がない」「選択肢を理解できない」「動画の切り替えがテンポを崩す」と気づくと、修正にはすでに書き直し、撮り直し、再編集が必要になっている。
よりよい順序は、まず3分のプロトタイプを作ることだ。ノード五つ、選択二回、エンディング三つで、仮のテキストでも低コストの動画でもよい。プロトタイプで検証するのは映像の品質ではなく、プレイヤーが何を決めているのか理解しているか、選択の後に変化を感じられるか、そしてチームが状態を追跡できるかだ。
今、何をすべきか
1ページのプロジェクト・ポジショニングカードを新しく作り、想定プレイヤー、利用場面、プレイヤーの主要な行動を表す動詞、プラットフォーム、プレイ時間、登場人物数の上限、ロケーション数の上限、初版ではやらないことのリストだけを記入しよう。まだ物語全体を書く必要はない。
次の記事では、まずインタラクティブ映画、FMVゲーム、インタラクティブ短編ドラマ、ビジュアルノベルの違いを整理する。プロダクトの形式を選び間違えると、その後の脚本、撮影、技術計画が根本から衝突することになる。
