変数が多いほどプロらしいわけではない：関係・証拠・リソース・世界の状態をどう階層化するか

変数の価値は数ではなく、プレイヤーの行動を説明できるか、その後のコンテンツを変えられるか、チームが確実に保守できるかにある。制作を管理できるインタラクティブ映像ゲームには、通常、関係・証拠・リソース・世界の事実という四つの状態レイヤーがあればよい。各変数には、一意の意味、明確な書き込み箇所、目に見えるフィードバック、最終的な回収が必要だ。それを満たせない変数は統合するか削除すべきである。

関係の状態は「誰が主人公をどう見ているか」に答える。疎遠、協力、信頼といった離散的な段階でも、狭い範囲の数値でも表せる。証拠の状態は「プレイヤーが何を入手し、理解したか」に答え、真偽値や集合が適している。リソースの状態は「プレイヤーがまだ何を費やせるか」に答え、時間、お金、回数、重要アイテムを含む。世界の状態は「客観的に何が起きたか」に答える。たとえば、警報が作動したか、ある人物が退場したか、といったことだ。

この四つのレイヤーを互いの代わりにしてはいけない。録音を入手したことは証拠であり、相棒が主人公をより信頼するようになったことを意味しない。匿名電話の機会を一回使うことはリソースの変化であり、世界ですでに警報が出たことを意味しない。レイヤーを分ければ、脚本家は因果関係を説明でき、プログラマーも一つの万能スコアが物語全体を支配する事態を避けられる。

0から100までの関係値は精密に見えるが、説明できない閾値を生みがちだ。プレイヤーには59と60の違いが分からず、脚本家も一点ごとの意味を設計しにくい。撮影するコンテンツでは、通常、三〜五段階の関係があれば十分だ。敵対、警戒、協力、信頼などである。多くの小さな行動を積み重ねる必要があり、インターフェースやフィードバックによってプレイヤーが傾向を感じ取れる場合に限り、連続的な数値を設ける価値がある。

『零点回拨』では、記者との関係を三段階の reporter_trust、重要な録音を真偽値の evidence_recording、匿名送信の機会を整数の burner_uses、警察署の封鎖の有無を世界の状態である station_locked で表せる。名前で意味を直接示し、flag7 や scoreB は使わない。

変数表には少なくとも六つの列を書く。名前、型、初期値、変更できる主体、読み取るノード、プレイヤーがどう認識するか、である。さらに「廃止条件」の列を加え、役目を終えた後も誤用されることを防ぐ。

たとえば、station_locked の初期値は false で、4Aの警報または5Cの追跡でのみ true に書き換えられ、6Aと6Bで読み取る。プレイヤーはシャッターが下りることとマップの封鎖によって認識する。最終章の開始後にすべてのルートが封鎖状態になるなら、章の入口で状態を統一し、以前の分岐で同じ判定を繰り返さないようにする。

十か所で書き込まれる変数が、一か所で無関係な台詞を一行生むだけなら、保守コストが価値を上回る。逆に、一度しか書き込まれなくても、ルート、人物の反応、結末の説明を変える重要な事実は費用対効果が高い。レビュー時には、各変数の書き込み数、読み取り数、目に見えるフィードバック数を集計する。読み取りがゼロなら死んだ変数、フィードバックがゼロなら幽霊変数であり、書き込みが多すぎる変数は役割が混乱している可能性がある。

分析用のイベント計測のために、すべてのクリックを物語の変数にしてはいけない。分析データは別途イベントとして記録できる。その後の物語に影響する必要がある内容だけを、セーブする状態に含める。

ノードへの進入条件が「信頼が63を超え、AまたはBがあるがCはない、あるいは二周目」と書かれていたら、誰も安全に変更できない。複雑な条件は、can_confront_director のように名前を付けた派生判定に分け、どの基本状態から導かれるかを設計ドキュメントに説明する。基本値が変わった後に両者が矛盾しないよう、派生判定を重複してセーブしない。

同じ事実には、唯一の正とする情報源を置く。「人物が録音を知っているか」をすでに知識マトリクスで管理しているなら、heard_recording、knows_audio、audio_seen という似た意味の変数をさらに三つ作ってはいけない。

すべての数値を表示する必要はないが、プレイヤーは演技、インターフェース、新たな機会から変化を理解できるべきだ。関係が良くなれば呼び方や視線を変えられる。入手した証拠は手がかりボードに追加できる。リソースの消費にはカウンター表示やアイテムの消失が必要で、世界の状態の変化は環境を映すショットで確認させる。フィードバックが遅いほど、回収時にきっかけとなった原因を思い出させる必要がある。

「好感度＋1」のポップアップで写実的な雰囲気を壊すことも、完全に無反応にすることも避ける。人物の一瞬の間、スマートフォンのプロフィール画像の変化、次のシーンで相手からかかってくる電話でも、同じ情報を伝えられる。スタイルが表現を決めるが、システムは読み取れるものでなければならない。

四つの状態レイヤーは組み合わせを増やすため、各章にはその章に本当に影響する変数だけを残す。「ノード×変数」のマトリクスを作り、読み取り、書き込み、無関係を記す。一つの行が五〜六個を超える状態を読み取るなら、章の入口で状態を集約することを検討する。一つの列が全編にまたがるのに、ほとんど効果を持たないなら、削除を検討する。

セーブデータの移行も事前に考えておく必要がある。変数名や型を変えたり、初期値を調整したりした後、古いセーブデータをどう解釈するのか。正式リリース後は、すべてのプレイヤーが最初から始めると仮定できない。状態表にバージョン番号を付け、古い値から新しい値への変換ルールを残す。

次のステップ：既存の変数をすべて関係・証拠・リソース・世界の四つのレイヤーに分類し、状態の契約を完成させる。分類できない変数や、読み取るノードが見つからない変数は、そのまま脚本に持ち込まず、まず削除候補にする。