制作前に「やらないことリスト」を書く:最初の作品が制御不能になるのを防ぐには
初めてのインタラクティブ映像ゲームで最もよくある失敗は、創造性の不足ではなく、よいアイデアをすべて最初のバージョンに入れてしまうことです。キャラクター、シーン、分岐、ゲームプレイ、プラットフォームが増え続け、最後にはどの部分も完成しません。対策は、脚本全体を書く前に「やらないことリスト」を作り、それぞれの上限に対応する条件を設定することです。

はじめに
初めてのインタラクティブ映像ゲームで最もよくある失敗は、創造性の不足ではなく、よいアイデアをすべて最初のバージョンに入れてしまうことです。キャラクター、シーン、分岐、ゲームプレイ、プラットフォームが増え続け、最後にはどの部分も完成しません。対策は、脚本全体を書く前に「やらないことリスト」を作り、それぞれの上限に対応する条件を設定することです。
やらないことリストは、消極的に削るためのものではありません。プロジェクトがプレイヤーに約束する最も重要な体験を守り、限られた予算を本当に検証すべき部分に集中させます。
まず六つの厳格な上限を決める
一つ目は完成映像の尺です。ここには、プレイヤーが一度のプレイで見る長さだけでなく、重複しない映像の総量を記録します。一度のプレイが15分でも、完全に独立したルートが三つあれば、40分以上の素材が必要になる可能性があります。
二つ目は主要キャラクターです。一人増えるたびに、出演者との調整、衣装やメイク、台詞の組み合わせ、字幕、ローカライズ、テストする状態が増える可能性があります。
三つ目はシーンです。シーンには場所だけでなく、同じ場所でも時間、セット、損壊状態が異なることで生じる制作上の変化が含まれます。
四つ目は重要な選択とエンディングです。選択の数は品質と同じではありません。最初のバージョンでは、少数の選択に情報、代償、フィードバックがあることを優先すべきです。
五つ目はシステムです。関係、証拠、リソース、QTE、手がかりの探索、自由入力、AI会話をすべて同時に中核にはできません。主となるシステムを一つ選び、補助システムは多くても一つにします。
六つ目はプラットフォームです。PC、Web、モバイルでは、入力、動画形式、性能、ストレージ、配信に違いがあります。最初のバージョンは主となるプラットフォームを一つにするのが望ましいです。
「後でやる」にも明確な行き先が必要
単に機能を延期すると言うだけではいけません。すぐに別の名前で戻ってくるからです。最初のバージョンに必須のもの、検証に成功したら取り組むもの、明確にやらないものという三つのリストを作ります。
「検証に成功したら取り組むもの」には、実行条件も書く必要があります。例えば、3分間のプロトタイプで少なくとも四人のテスターが証拠システムを理解できた場合にのみ、二種類目の手がかりを追加します。低スペックの端末で動画の切り替えが安定した場合にのみ、より高い解像度を追加します。メインストーリー全体に到達できるようになった場合にのみ、隠しエンディングを追加します。
実行条件のないタスクは、感情に任せた要件の追加につながります。
プレイヤーへの約束を基準に削るものを判断する
《零点回拨》が約束するのは、未来からの電話とキャラクターの証言の信頼性をプレイヤーが判断し、午前0時以降の結果を変えることです。そのため、最初のバージョンには、検証可能な予言、立場の異なる少なくとも二人のキャラクター、範囲が限定された時間変数一つ、信頼と証拠の両方で決まる複数の結果が必要です。
自由に移動できる3Dのカスタマーサービスセンターも、プレイヤーが任意の質問を入力する機能も、会社の業務全体のシミュレーションも必要ありません。これらは面白い機能かもしれませんが、中核となる約束を直接証明するものではありません。
チームがある機能をめぐって議論するときは、三つの問いを投げかけられます。それを外しても、プレイヤーは中核となる動作を実行できるか。それを外しても、エンディングはプレイヤーの行動を反映できるか。それを外しても、3分間のプロトタイプで最大のリスクを検証できるか。三つの答えがすべて「できる」なら、最初のバージョンに入れるべきではありません。
スコープを数えられる指標に落とし込む
「規模を大きくしすぎない」だけでは実行につながりません。スコープ表を使います。
| スコープ項目 | 最初のバージョンの上限 | 現在の数量 | 上限を超えた場合の対応 |
|---|---|---|---|
| 重複しない映像の分数 | 20 | 分岐を合流させるかテキストノードに変更 | |
| 主要キャラクター | 4 | 役割が似たキャラクターを統合 | |
| 主要シーン | 3 | 同じシーンの異なる状態として書き直す | |
| 重要な選択 | 8 | 結果に影響しない選択肢を削除 | |
| 正式なエンディング | 4 | 一文しか違わないエンディングを統合 | |
| 中核となる変数 | 5 | タグに変更するか削除 | |
| 主となるプラットフォーム | 1 | 他のプラットフォームは検証後のリストへ移す |
数字はプロジェクトに合わせて調整できますが、上限を超えたら、予算、日付、または他のスコープも同時に調整しなければなりません。チームの残業で吸収することを前提にしてはいけません。
最も危険な四種類の「ついでに追加」
一つ目は、コンテンツだけを増やし、新しい理解をもたらさない分岐です。プレイヤーは異なる台詞を見ても、新しい情報、関係、能力を得られません。
二つ目は、宣伝のために、作品全体を通して使えない仕組みを追加することです。冒頭で一度手がかりを探すだけでは、作品を調査ゲームとして宣伝することはできません。
三つ目は、素材をすでに制作したために削除をためらうことです。サンクコストはコンテンツに価値があることの証明にはなりません。
四つ目は、技術的な可能性をプロダクトの必要性とみなすことです。モデルが任意の台詞を生成できるからといって、物語が任意の台詞を許容すべきとは限りません。
毎週一度スコープを監査する
監査で見るのは四項目だけです。何を追加したか、なぜ追加したか、何と置き換えるか、追加のテストを誰が担当するかです。削除する項目も、予算やスケジュールの変更もない新しい要件は、ひとまず制作に入れません。
スコープ監査では「隠れた増加」も確認する必要があります。同じキャラクターを追加していなくても、四つの状態でまったく異なる演技と映像が必要なら、制作量はすでに増えています。同じオフィスでも、昼間の状態から停電、火災警報、損壊という三つの状態に変わるなら、一つのシーンとして数えることはできません。重複しない素材の量を表に記載し、同じ名前で実際のコストを隠さないようにします。
プロジェクトが本当に上限を超える必要があるときは、明確にスコープを交換します。例えば、エンディングを一つ追加するなら、独立したサブストーリーを一つ削除するか、あるプラットフォーム版を延期します。誰が承認したか、なぜその価値があるか、新しい受け入れ確認の日付を記録します。そうすればチームは、制御不能な状態を黙って受け入れるのではなく、プロダクトについて選択できます。
やらないことリストが完成したら、個人のメモではなくプロジェクトのホームページに置きます。次の段階で横画面か縦画面か、PCかWebかを選ぶ際にも、このリストを使って、どのリリース形態が最初のバージョンの制作能力に最も合っているかを判断します。


