脚本をプログラムが読めるデータに変えるには:ノード、選択肢、条件と結果
脚本をプログラムに組み込むうえで重要なのは、WordファイルをJSONにコピーすることではなく、安定したナラティブデータの契約を定めることです。各ノードは何を再生し、いつインタラクションを表示するかを記述します。各選択肢は表示条件、プレイヤーの意図、状態の変化結果、遷移先ノードを記述します。テキスト、メディア、ロジックは相互に参照しながら、それぞれ追跡可能なバージョンを持ちます。

はじめに
脚本をプログラムに組み込むうえで重要なのは、WordファイルをJSONにコピーすることではなく、安定したナラティブデータの契約を定めることです。各ノードは何を再生し、いつインタラクションを表示するかを記述します。各選択肢は表示条件、プレイヤーの意図、状態の変化結果、遷移先ノードを記述します。テキスト、メディア、ロジックは相互に参照しながら、それぞれ追跡可能なバージョンを持ちます。
安定したIDから始める
章、シーン、ノード、選択肢、アセットには、すべて一意のIDが必要です。表示タイトルは変更できますが、制作で使い始めたIDは再利用しません。例えば、ノードは C02_S04_N030、選択肢は C02_S04_N030_O2、動画は C02_S04_N030_main_v07.mp4 とします。プログラム、字幕、イベント計測、不具合報告は、すべて同じ識別子を使います。
IDには俳優名、感情、最終的なセリフを含めません。これらは変わるためです。廃止したIDは変更履歴に残し、古いセーブデータやログが新しいコンテンツを誤って指さないようにします。
ノード構造の各部分に一つの責務だけを持たせる
ノードデータには id、media、entryConditions、onEnter、interactions、onExit、fallback、tags を含められます。メディアフィールドはアセット一覧を参照し、ローカルの絶対パスを直接混在させません。条件は状態の読み取りだけを行い、効果は許可された状態にだけ書き込みます。
{
"id": "C02_S04_N030",
"media": "VID_C02_S04_N030_MAIN",
"entryConditions": ["evidence_recording == true"],
"interactions": ["C02_S04_N030_O1", "C02_S04_N030_O2"],
"fallback": "C02_S04_N040"
}
この例は責務の境界だけを示しています。具体的な形式にはJSON、表からのエクスポート、ナラティブスクリプトを使えます。重要なのは、同じ事実を管理する正本の所在を一つにすることです。
選択肢には表示と結果を併せて記録する
選択肢には文言キー、表示条件、選択可能条件、時間制限のルール、状態への効果、遷移先ノードが必要です。表示されていても選択できない場合は、プレイヤーに理由を伝えます。完全に非表示にする場合は、空のボタンを残してはいけません。文言にはローカライズキーを使い、中国語の原文をロジックの判定に使わないようにします。
効果には、ブール値の設定、リソースの追加、関係段階の変更など、制限された操作を使うのが望ましいです。各選択肢に任意のスクリプトを隠せるようにしてはいけません。そうすると、脚本家のデータが監査できないプログラムになってしまいます。複雑な動作は、名前付きコマンドを通じてランタイム側で実装します。
条件は検証と説明ができるものにする
条件は変数表の正式名称を参照し、比較の型を制限します。ブール値と文字列は混用せず、列挙型は有効な値だけを受け入れ、数値には上限と下限を設定します。エディターやビルドスクリプトは、エクスポート時に未知の変数、到達不能なノード、出口のないループ、遷移先の欠落を検査します。
複雑な条件は名前付きルールに分割します。例えば can_publish_truth は、重要な証拠がすべてそろっていること、記者が引き続き協力していること、リソースが十分であることから成ります。テストログにはルールの判定結果と基礎となる値の両方を出力してこそ、プレイヤーに特定の選択肢が表示されなかった理由を説明できます。
メディア一覧とナラティブデータを分離する
ノードは論理的なアセットIDだけを参照します。アセット一覧が、そのIDをプラットフォーム、言語、画質ごとのファイルに対応付けます。こうすれば、編集版をv06からv07に変更しても分岐ロジックを変更する必要はありません。モバイルで低いビットレートを使う場合も、ノード一式を複製せずに済みます。
一覧には少なくとも、ファイル、チェックサム、再生時間、解像度、音声トラック、字幕、バージョン、レビュー状況を記録します。ランタイムは読み込み前にチェックサムと再生時間を検証でき、誤った映像や途中で切れた映像が正式な配布パッケージに入る可能性を減らせます。
明確な実行順序を設計する
ノードへの進入、メディアの準備、再生、選択肢の表示、選択の送信、効果の書き込み、ノードからの退出という順序を定めます。状態を書き込んでから遷移するか、先に遷移するかは、次のノードの進入条件の判定に影響します。選択の送信はアトミックなトランザクションとして扱うことを推奨します。まだ選択可能かを検証し、結果を書き込み、ログを記録してから遷移します。失敗した場合は状態を変更せず、復旧手段を用意します。
タイムアウト、スキップ、セーブデータの読み込み、連続クリックも、同じステートマシンを通す必要があります。送信後は直ちにボタンをロックし、ダブルクリックによる二重書き込みを防ぎます。退出して再び入る場合は、送信済みの印に基づいて復元し、報酬を再度付与しません。
データ検証と読みやすいログを整える
ビルドのたびに、IDの一意性、参照先の存在、少なくとも一つの出口、変数の型の正しさ、ローカライズキーの充足、メディアの所在を自動で検査します。警告とエラーは重大度で区別します。任意の注記の欠落は警告にできますが、遷移先ノードが存在しない場合は必ずビルドを停止しなければなりません。
実行ログは構造化イベントを使い、セッション、ノード、選択肢、変更前後の状態の要約、時刻、バージョンを記録します。ログには不要な個人情報を含めてはいけません。デバッグビルドではより詳しく記録できますが、本番の分析イベントはプライバシーと同意の要件に従います。
プログラマー以外もレビューできるようにする
機械が読めることは、人間にとって読みにくいことを意味しません。同じデータからノード表、分岐図、プレイ可能なプレビューを生成し、脚本家はセリフを、プロデューサーはアセットを、テスターは経路を確認します。手作業で作ったコピーにはすべて、元データへの書き戻し不可と明記し、複数人が複数の正本を管理する事態を防ぎます。
次のステップ:十個のノードを選んで最小限のデータスキーマを定義し、正しいサンプルを一つ、意図的に誤りを入れたサンプルを三つ作成します。ビルド検査が未知の変数、接続先のない出口、メディアの欠落を正確に検出して止めることを確認してから、脚本全体を取り込みます。


