ビジュアルノベルのセリフを二つに分けたら、ボイス・表情・演出指示をどう紐づけ直すか

一つのセリフを二つに分けたら、まず各参照がなぜその位置にあるのかを確かめてから、どちらへ移すかを決めます。ボイスは収録されているテキストの範囲、表情は感情の変化、動作は発動の前提条件を確認し、ページ送りの表示は区切りを見直します。元のセリフが二つのページになったからといって、既存の指示も一つずつ複製するわけではありません。

ここでは「セリフ分割・統合時の移行表」を使って改稿を進めます。事例は説明のために設計した架空のものであり、実在するユーザーの事例、実測結果、DramaFork の製品機能ではありません。識別子は保守用の文書に使うもので、特定のスクリプト形式を示すものではありません。

管理人の元のセリフを「セリフ甲」とします。「通行証の確認で問題がないとわかって初めて、この扉を開けられます。待って、扉の向こうに誰かいる！」というセリフです。元の原稿では全体を収録した一つの音声を参照し、落ち着いた表情、扉を開ける動作、驚きの表情、セリフ末尾のページ送り表示が設定されています。

この例では、通行証の確認ですでに問題がないとわかっており、管理人は扉を開ける条件を説明しています。ただし、扉を開けるのは条件の説明が終わってからで、驚きは扉の向こうに人がいると気づいた時点から始まります。「条件を満たしていること」と「説明を言い終えたこと」は分けて考える必要があります。通行証の確認を通過していなければ、このセリフを言い終えただけで扉を開けてよいことにはなりません。

改稿後は「セリフ甲一」：「通行証の確認で問題がないとわかって初めて、この扉を開けられます。」と、「セリフ甲二」：「待って、扉の向こうに誰かいる！」に分けます。文言は変えていませんが、表示の区切りは変わっています。

まず、旧識別子と二つの新識別子の対応を残します。行番号を識別子の代わりにしてはいけません。行番号は追加や削除で変わります。移行の根拠になるのは、「セリフ甲二が元のセリフの警告部分を引き継ぐ」という対応関係です。旧参照も先に記録し、分割後に記憶だけを頼りに動作を探すことがないようにします。

各指示について、「言い回しだけを変えても残るか」「ページ分けだけを変えても残るか」と考えてみます。元の全文を収録した音声なら、対象となるテキストの範囲を見直す必要があります。驚きは、言い回しが変わっても異変に気づくイベントに属します。ページ送り表示は、表示の区切りに紐づきます。

以下では一行につき一つの参照を記録し、維持・移動・置換を個別に判断できるようにしています。表の確認事項は期待する要件であり、まだ確認を実施したものではありません。

記入時には識別子を統一します。表内の「台詞甲」とその派生表記は、前述の「セリフ甲」とその派生表記を指しています。正式な引き継ぎでは同じ表記に直し、別々の対象として扱わないでください。

実務で使う際は、各行に素材の保存場所、対応状況、確認記録も追加します。「該当なし」は音声参照ではないという意味であり、音声との前後関係を無視してよいという意味ではありません。ページ送り表示は一つ増えますが、開扉動作は一回のままです。両者は紐づく根拠が異なるためです。

一つの旧音声が新しい二つのページにまたがる場合、両方のページからその全体を参照させてはいけません。二つ目のページで条件の説明から再生し直されるおそれがあります。また、一つ目のページだけに音声を残し、ページを送った後にどう再生を続けるかを決めずに済ませることもできません。

音声を連続再生する形で残すことはできます。ただし、二つ目のページをいつ表示するか、ページ送りが音声を中断するか、警告がテキストの表示前に聞こえることがあるかを明確にする必要があります。音声を連続して進める演出に向く一方、ページ送りのテンポが録音に制約されます。実行環境で実現できるかは、別途確認が必要です。

自然な間で音声を分割する方法もありますが、切れ目で言葉が欠けたり、息遣いが途切れたり、後半の口調が不自然に変わったりしないかを確認します。テキストに句点があるからといって、そこで音声を切れるとは限りません。素材を聴く前に「分割可能」を確認済みとして記録してはいけません。

この例では、二つのセリフをそれぞれ再収録し、二つ目を「待って」から独立して再生する方針にします。その分、追加の収録と声の一貫性の確認が必要です。移行表では新音声の用途を先に決められますが、素材の納品と確認が済むまでは未完了として扱います。旧音声は経緯をたどるための資料として残し、二つのセリフからは直接呼び出さないようにします。

この例でボイスを再生する場合の想定順序は、次のとおりです。甲一に入り、落ち着いた表情を表示して条件の説明を再生します。音声の終了とプレイヤーの次へ進む操作の両方を満たしたら、通行証の確認を通過しているかを調べ、扉を開ける動作を一度実行します。動作が終わったら甲二に入り、驚きの表情に切り替えて警告を再生します。甲二が終わったら、後続のセリフへ進みます。

この配置では、扉を開けている間は二つ目のセリフをまだ表示しません。驚きと開扉動作を重ねたいなら、イベント間の関係を別途定義する必要があります。驚きの指示を甲一の末尾へ早めにコピーするだけでは、警告が出る前に感情を見せてしまうおそれがあります。

つながりの確認では、少なくとも三つの場合を扱います。通常どおり最後まで聴いた場合は、条件の説明が終わってから扉が開くかを確認します。途中で次へ進む操作をした場合、この例では甲一の音声終了を待つ必要があり、操作だけで開扉してはいけません。ボイスを無効にした場合は、全文の表示完了と次へ進む操作をページ離脱の条件にして、再生されない音声の終了を待たないようにします。

途中で次へ進む場合とボイスなしの場合のルールは、いずれもこの例で選んだ設計です。作品側での実装が必要であり、すでに備わっていると仮定してはいけません。スキップ、セーブデータのロード、読み返しによってこれらの位置に再び入る可能性があるなら、イベントの復元ルールも別途決めます。扉が開いている状態を再現するために、開く動作まで再生し直す必要があるとは限りません。

記録は「到達方法｜開始時の状態｜想定順序｜実際の観察｜要修正事項」といった形式にできます。この記事で示したのは想定上の検討だけで、作品を実行していません。そのため、実際の観察欄は確認時に記入し、合格と記録してはいけません。

後で甲一と甲二を「セリフ乙」に戻す場合も、二つのページの指示をそのまま連結してはいけません。まず移行表を確認します。開扉は引き続き条件の説明が終わった後のイベントであり、驚きは警告の開始に属します。一方、二つのページ送り表示は、統合後のセリフ末尾の一つにまとめる必要があります。

甲一の終了時と甲二の開始時の両方に動作が残っているなら、統合後、それらが同じ一回の開扉を指すかを確かめます。重複した実行起点だと確認して初めて、一方を削除します。物語上は別の動作であれば、同じ素材を使っていても、ファイル名だけで重複と判断してはいけません。どちらを残すかは、イベントとの関係で決めます。

統合したセリフの途中に、必要な実行位置を設定できない場合もあります。現在の実装がセリフ全体の開始時か終了時にしか指示を実行できないなら、途中で扉を開けられることにしてはいけません。分割を維持する、実装可能なイベントノードを追加する、演出を変更するといった方法から選び、その選択に伴うトレードオフを記録します。

引き継ぎでは、すべての旧参照について移行先や扱いを明確にし、すべての新参照について配置の根拠を説明できるようにします。再収録待ちや実装待ちの項目も残します。この表は、セリフを組み替えた後の参照管理に使うものです。素材を自動修復することも、未確認のスキップ、ロード、読み返しの経路が正しく動くと証明することもできません。