プレイヤーの好奇心を損なわずに自由質問型のゲームシーンを破綻させない方法
プレイヤーがNPCに何でも質問できるシーンを構築するインディーナラティブゲームデザイナーにとって、質問とストーリーの進行を切り離して処理することでストーリーの一貫性が保たれます。プレイヤーには自由に質問させつつ、世界で確定していること、このNPCが知っていること、そしてそのシーンで変更が許可されている正確なゲーム状態をあらかじめ決めておきます。その上で、多様な質問を用意された少数の結果に結びつけます。すなわち、確定した事実から答えるか、NPCが答えられないことは保留するか、会話を既知のルートに戻すかです。プレイヤーは、誤って手がかりを捏造したり、意図しない展開を引き起こしたりすることなく、会話を誘導できます。
シーンの事実と状態から始める
灯台での静かな架空のシーンを想像してみてください。灯台守のマーラは、真鍮の鍵を持った配達人を待っています。このシーンの目的は、なぜ灯台が消えているのかをプレイヤーに知らせ、港へ合図を送るマーラを手助けするかどうかを決めさせることです。これは設計例であり、リリースされたゲームのレポートではありません。
対話を書く前に、3つの独立したリストを含むコンパクトな「シーンシート」を作成します。
**世界の事実：** ランプのレンズが修理のために取り外されているため、明かりが消えている。鍵は配達人が持っている。港は合図を待っている。
**マーラの知識：** 彼女はレンズが出払っていることと、配達人が日没前に到着する予定だったことを知っている。配達人が今どこにいるのか、なぜプレイヤーがやって来たのかは知らない。
**許可された状態変更：** `lens_explained` を true にできる。`player_offered_help` を true にできる。そして `signal_route_open` は、プレイヤーが手助けを申し出てマーラが同意した後にのみ true にできる。いかなる質問も、それ単体で合図を送信済みにしたり、鍵を見つけたり、配達人の居場所を変更したりすることはない。
もっともらしい回答が、意図せずして世界の新たな事実になってしまう可能性があるため、この分離は重要です。もしマーラが「配達人は北の橋の近くで見かけられた」とアドリブで答えた場合、プレイヤーはそれを手がかりとして受け取るのが自然です。その橋が設計されたシーンの一部でない限り、その回答は勝手にコンテンツを作り出し、場合によっては新たなクエストの義務を生じさせてしまいます。シーンシートは、何を話してよくて何が起こりうるのかについて、ライターと実装者に共通の基準を提供します。
質問の幅を広げつつ、結果を限定的に保つ
自然言語には、同じことを尋ねる多くの方法があります。プレイヤーは「なぜ明かりが消えているの？」「灯台に何があったの？」「まだ船を誘導できる？」と尋ねるかもしれません。これらの異なる言い回しはすべて、用意されたレンズの説明へとたどり着くことができます。しかし、すべての質問に直接答える必要はありません。シーンの事実や目的との関係によって質問を分類します。
台本外の質問：「誰が灯台のレンズを盗んだの？」 — 分類：**回答** — 応答と効果の例：「誰も盗んでいないよ。修理に出しているんだ。」 `lens_explained = true` を設定する。犯人の名前は挙げない。
台本外の質問：「配達人は今どこにいるの？」 — 分類：**保留** — 応答と効果の例：「わからないわ。日没前には来るはずだったんだけど。」 状態の変更はなし。プレイヤーが尋ねたからといって、NPCが知識を得ることはない。
台本外の質問：「ランプを使って港に合図を送ることはできる？」 — 分類：**既知のルートへ戻す** — 応答と効果の例：マーラはレンズがまだ戻っていないことを伝え、別の方法で港に合図を送るのを手伝うという用意された選択肢を提示する。プレイヤーが応じ、マーラが同意した場合にのみ、そのルートを開く。
これらのラベルは設計上の結果を表しており、固定された応答テンプレートではありません。回答では、既知の事実を伝える前にプレイヤーの言葉遣いを認めることができます。保留では、配達人が到着するか確認するなど、有益な次のステップを提示できます。ルートへ戻すということは、質問をシーンの設計された選択肢へと結びつけ直すことを意味し、会話を打ち切ったり同じ台詞を繰り返したりする必要はありません。重要なのは、事実の主張や状態への影響をあらかじめ定義したまま、応答の言い回しを柔軟にできる点です。
台詞を作成する前に意図と状態を解決する
寄せられた質問ごとに、まずは確定されたシーンの状態を読み取ります。それが確定した事実を尋ねているのか、NPCが知り得ない事実なのか、あるいは許可されたアクションを実行する要求なのかを判断します。1つの質問が複数のカテゴリにまたがることもあります。ランプに関する回答と手助けの申し出は別々の結果になり得ます。次に、応答のパスを選択し、そのパス内で台詞を組み立てます。生成された言葉遣いは決定を表現したものであり、決定を下す主体ではありません。
この順序は、プレイヤーが未来の出来事について尋ねるときに特に重要です。「配達人は到着した？」という質問に対する回答は、配達人が到着している場合と、シーンがまだ配達人を未着として記録している場合とで異なります。自信に満ちた口調であっても、プレイヤーの思い込みであっても、その状態が覆るべきではありません。必要な状態が利用できない場合、シーンは開発段階で目に見える形で失敗すべきであり、カノニカル（公式）な主張を出すのを避ける必要があります。やり取りを完結させるために、配達人が到着したと勝手に仮定したり、橋での目撃情報を捏造したりしてはいけません。
許可される状態変更は、小さく明示的なものにとどめてください。例えば、手助けの申し出は、既知の `player_offered_help` への遷移を要求できます。ゲームは、`signal_route_open` が変更される前に、プレイヤーがそれを選択し、マーラがそれを受け入れたことを検証できます。単に「手助け」という言葉に言及しただけの質問は、申し出としてカウントされるべきではありません。プロトタイプでは、レビューのために応答と確定した遷移を並べてログに記録できます。
意図しない早期の情報開示からシーンを守る
プレイヤーは、その根拠を発見する前に、最終的な答えについて直接尋ねてくることがあります。ストーリーの現時点でマーラが共有できる情報を決定しておきます。「配達人は見かけていない」といった嘘偽りのない保留は、キャラクターの知識とプレイヤーの探索意欲の両方を維持できます。手がかりが見つかったかのように装うべきではありませんし、単にシーンを長引かせるためだけに確定済みの事実を隠すべきでもありません。
Ubisoftの[NEO NPCプロトタイプの手記](https://news.ubisoft.com/en-us/article/5qXdxhshJBXoanFZApdG3L/how-ubisofts-new-generative-ai-prototype-changes-the-narrative-for-npcs)では、自発的なプレイヤーの入力に対する、ライターが形成したキャラクターの経歴とシナリオの制約について説明されています。これは実験的なプロトタイプに関する当事者の手記であり、特定の境界線設計がリリースされたゲームで成功しているという測定された主張ではありません。このシーンにとって役立つ教訓は、モデルに台詞のアドリブを求める前に、キャラクターの知識と役割を書き出しておくことです。
[Jamin Smith氏による『Acolyte』の手記](https://www.gamedeveloper.com/design/deep-dive-designing-for-spontaneity-and-non-linearity-in-alternate-reality-games-with-i-acolyte-i-)では、自然言語による質問の利点と、熟練したプレイヤーがあまりにも早く情報を暴いてしまうというペース配分の問題が語られています。これは1つのゲームに関する1人のデザイナーの考察です。灯台の例において検討すべき問題は、配達人について尋ねることで、ゲームがそれを確立する前に後のプロットの事実が明かされてしまわないかということです。もしそうなら、回答の文言だけでなく、その状態において許可される事実のセットを変更します。
台本外からの復帰を単調にせず有益なものにする
未知の質問に対して、常に同じ「それには答えられません」という文を返す必要はありません。マーラは質問の妥当な部分を認め、限界を示し、用意された選択肢の1つを指し示すことができます。配達人がどこへ行ったのか尋ねられたら、彼女が最後に知っていることを説明し、港の合図を確認することを提案できます。ランプを修理できるか尋ねられたら、レンズがないことを説明し、分かっている代替案を説明できます。回答はシーンの範囲内に留まりつつ、プレイヤーの実際の関心にも応答します。
復帰は、プレイヤーができることへの道筋であるべきであり、正確なフレーズの使用を要求するものであってはなりません。複数の自然な質問や、チャット以外の目に見えるインタラクションを通じて、同じ設計されたアクションを提示します。これにより、会話をやめたプレイヤーも進行できるようになり、デザイナーは自由な質問が隠されたパスワード探しのパズルになるのではなく、キャラクター性を高めているかどうかをテストできます。任意のフレーバーテキストは幅広く変化させて構いませんが、必須の手がかりには、世界の中に安定した調べられる場所が必要です。
記録されたストーリーに照らし合わせて自由質問をテストする
テスターにシーンとシンプルな目的（なぜ明かりが消えているのかを理解し、手助けするかどうかを決めること）を与えます。どの質問をすべきかは教えないでください。テスターがどの主張を手がかりとして扱うか、いずれかの回答が次の行動を変えるか、特定の文を再現することなく意図した選択肢に到達できるかを観察します。その後、会話の内容をシーンシートおよび実際の状態変更と比較します。
捏造を誘発するような質問を含むネガティブテストを追加します。「配達人はどの橋を渡ったの？」「誰がレンズを盗んだの？」「もう合図は送ったっけ？」初期状態において合格となる応答は、橋での目撃情報、盗難、合図の完了を主張しません。修理に関する既知の事実で答えるか、配達人の居場所が不明であることを認めるか、許可された合図の選択肢へとプレイヤーを誘導します。テキストと保存されたフラグの両方についてログを確認します。`signal_route_open` は申し出が受け入れられるまで false のままであるべきであり、`signal_sent` は設計された別個のアクションが発生するまで false のままでなければなりません。
生成された台詞が裏付けのない手がかりを作り出してしまった場合は、シーンシートに事実の記載漏れがあったか、NPCに過度に広範なコンテキストが与えられたか、応答が明示的な制限を無視したかを追跡します。プレイヤーが自由に質問できるのに次の意味のあるアクションを見つけられない場合は、設計された選択肢へ戻るルートを改善します。首尾一貫した自由質問シーンとは、世界の事実、キャラクターの知識、そして実際の結果を明瞭に保ちながら、プレイヤーの言葉遣いを多様にできるシーンのことです。