分岐するゲームストーリーをテスト可能な状態に保つ方法
分岐ストーリーの規模が大きくなるときは、すべての可能性のあるルートを個別のエンドツーエンドのスクリプトとしてテストするのではなく、各パスの挙動を変化させる決定と状態変化をテストします。物語をグラフとしてモデル化し、各決定における条件と結果を定義し、重要な遷移、合流地点、失敗ケースをカバーする小さなテストスイートを構築します。その後、構造化されたチェックでは判断できない問題を検出するために、リスクベースのルートサンプリングと人間によるプレイテストを活用します。これにより、ナラティブデザイナーやQAチームは、網羅的なパスカバレッジを主張することなく、再現可能な方法で不具合を発見できます。
挙動を記録するグラフから始める
プレイ可能な各パッセージまたはシーンをノードとして、各選択肢を有向エッジとして表現します。エッジにはその条件と効果を注釈します。例えば、`has_key = true` によって「門の鍵を開ける」が有効になり、それによって `gate_open = true` が設定される、といった形です。エンディング、ループ、合流地点を明示的にマークしてください。合流地点とは、異なるルートが再び合流する場所です。意図しない状態を引き継ぐことなく、ストーリーが複数の過去の経緯から継続できるかを確認するのに有用な場所となります。
グラフは散文の構造だけでなく、ゲームが実際に評価する内容を反映している必要があります。選択肢がどの変数を読み取り、どの変数を書き込み、どの後続ノードがそれらに依存しているかを記録します。デフォルト値、リセットルール、単発の効果も含めます。あるフラグがある分岐で設定され、一度もクリアされない場合、それが意図的である可能性もあります。それを文書化することで、レビューやテストにおいてその結果を可視化できます。
この構造は、長いスクリプトで見落としがちな決定ポイントを見つけるのにも役立ちます。Alexey Tikhonovによる2024年の論文では、分岐型ナラティブにおけるキャラクターの決定ポイントの検出を研究し、「きみならどうする？（Choose Your Own Adventure）」ゲームグラフに基づくデータセットを提案しています。その課題は物語の決定ポイントを特定することにあり、QA手法を検証することではありません。チームが選択肢を棚卸しする際の参考にはなりますが、ここでのテストアプローチが有効であることを示すものではありません。[Tikhonov, “Branching Narratives: Character Decision Points Detection”](https://aclanthology.org/2024.games-1.8/)
シーンの到達だけでなく、状態遷移をテストする
ノードが表示されたことだけを確認するテストでは、壊れた選択肢を見逃す可能性があります。重要な選択肢ごとに、意図した条件のもとで選択肢が利用可能か、それを選択することで期待通りの状態変化が適用されるか、そして次のノードと目に見える結果がその状態と一致しているか、という3点を確認します。これらのチェックは、物語を状態遷移システムとして扱います。つまり、開始状態とアクションが与えられたときに、結果として生じる状態と遷移先を検証します。
例えば、「地図を見せる」という選択肢のテストでは、地図が表示され、`trust`（信頼度）が変化せず、ルートが共有の展望台シーンに到達することをアサートするかもしれません。対になるテストでは `has_map = false` から開始し、この選択肢が利用できないか、指定された代替案に従うことをアサートします。正確な期待される挙動はナラティブの仕様に依存します。重要なのは、パッセージのタイトルから正しさを推測するのではなく、明示的にアサートすることです。
合流地点では、単にそこに到達したこと以上のテストを行います。各ルートが保持、変更、または破棄することになっている状態を比較します。ある分岐で説得された警備員は再合流後も味方のままであるかもしれませんが、一時的な変装の効果は切れるべきです。それらのルールを合流後の期待される状態の一部とします。ルートが完全に収束することを意図している場合は共有された状態をアサートし、意味のある違いを維持すべきである場合はそれらの違いもアサートします。
架空の例を用いてカバレッジを可視化する
短いミステリー作品の資料室で決断を迫られる場面を考えてみましょう。プレイヤーは協力を求める、忍び込む、または借りた鍵を使うことができます。どのルートも同じ廊下に到達し、その後の選択によってプレイヤーが封印された手紙を取るかどうかが決まります。以下の架空のマトリクスは、コンパクトなテスト責務のセットを追跡したものです。「カバー済み」とは、特定の責務に対するテストが計画されていることを意味し、ルート全体やすべての組み合わせがテストされたことを意味するわけではありません。
**A:** `trust = high`（信頼度：高）。資料室の管理人に助けを求める。協力の選択肢が表示される。`trust` は高いまま維持される。ルートが廊下に到達する。選択肢の利用可能性と遷移
**B:** `trust = low`（信頼度：低）。助けを求める。仕様通り、協力の選択肢が非表示になるか断られる。ネガティブ条件
**C:** `has_key = true`（鍵を所持）。通用口の鍵を開ける。ドアが開く。ルートが廊下に到達する。仕様で定められている場合のみ鍵が消費される。状態効果と合流
**D:** `has_key = false`（鍵を未所持）。通用口を開けようとする。ドアは開かない。成功フラグは設定されない。ネガティブアサーション
**E:** 廊下から、封印された手紙を取る。`has_letter = true`（手紙を所持）。後の証拠シーンで手紙固有のセリフが表示される。下流への結果
**F:** 廊下から、手紙を置いていく。`has_letter = false`（手紙を未所持）。手紙固有のセリフが表示されない。結果の対比とネガティブアサーション
これは意思決定を補助するものであり、カバレッジの割合や汎用的な最小テストスイートではありません。見落としを可視化します。ここでは、信頼度が低い場合のゲートや「手紙がない」という結果は、ハッピーパスの確認だけでは検証できないため、個別のチェックが必要です。各行はグラフ内の関連するノードまたは遷移を指し示しているべきであり、これにより条件が変更された際に影響を受けるテストを追跡できます。
組み合わせが増加した際はブランチカバレッジを優先する
ストーリーに多くの独立したフラグがある場合、可能な組み合わせの数は急速に増加する可能性があります。理論上のすべてのルートを必須の完全なプレイスルーとしてリストアップすることで対応しないでください。まずは高リスクなエッジを特定します。エンディングを制限する選択肢、アイテムを消費する選択肢、持続的な関係性の事実を設定する選択肢、あるいは過去の履歴を統合する選択肢などです。これらの遷移と、それらによって引き起こされる重要な下流の結果を直接テストします。
次に、組み合わせを計画的にサンプリングします。境界条件（選択肢を変化させる最小値）、各重要条件の両面、相互作用する可能性のある代表的なフラグの組み合わせ、および異なる経緯を経て合流地点に到達するルートを含めます。最近の変更や、複雑な前提条件を持つパスを優先してください。2つの変数が相互作用する可能性がある場合は、単一の変数チェックが別々に行われたからといってその組み合わせが機能すると見なすのではなく、そのペアに対するテストを追加します。
カバレッジの単位とその限界を記録してください。チームは、すべての重要な選択肢エッジが実行されたか、関連する箇所で各条件のtrueとfalseの両方がチェックされたか、そしてすべてのエンディングトリガーに設計されたテストが少なくとも1つ到達したかを追跡するかもしれません。これらはサンプリングされた内容の有用なレポートですが、起こり得るすべての経緯、状態の組み合わせ、または表現上の問題が網羅されたことを証明するものではありません。
ゲームのプレイテストに関する研究は、関連しつつも適用範囲の限定されたアイデアを提供してくれます。Gordilloらによる2021年のarXiv論文では、複雑な3Dシナリオにおいて状態カバレッジを探索するために、新しいアクションに対して報酬を与える強化学習エージェントについて説明しています。その研究は3Dゲーム環境での探索に関するものであり、分岐する物語の選択肢や、ここで説明する特定の位置遷移テスト手法に関するものではありません。自動探索を補完的な手段として扱うことを支持してはいますが、その研究もTikhonovの論文も、この特定のナラティブテスト手法を検証するものではありません。[Gordillo et al., “Improving Playtesting Coverage via Curiosity Driven Reinforcement Learning Agents”](https://arxiv.org/abs/2103.13798)
ネガティブアサーションと人間によるプレイテストを追加する
ポジティブアサーションは、期待される選択肢や結果が存在することを確認します。ネガティブアサーションは、禁止されている事象が発生しないことを確認します。例えば、ロックされた選択肢が表示されないこと、消費された手がかりが2度付与されないこと、手紙がない場合にそのセリフがトリガーされないこと、試行の失敗によって成功フラグが設定されないことなどです。ネガティブチェックは、別のルートからの古い状態が現在のシーンに漏れ出す可能性がある共有ノードの周辺で特に役立ちます。
自動化されたチェックはルートのロジックや正確な状態変化を検証できますが、遷移が首尾一貫して感じられるか、セリフがプレイヤーの記憶と矛盾していないか、文脈の中で選択肢が理解可能かといった点を確実に判断することはできません。そのため、人間によるプレイテストでは目的を持って選定されたルートを使用すべきです。テスターに対し、あまり選ばれない分岐を進む、特定の経緯を持って合流地点に到達する、または鍵を持たない状態でエンディングへの到達を試みるよう依頼します。結果として生じる状態と、それに対するプレイヤーの解釈の両方を観察してください。
プレイテストのメモは、ノードや選択肢の識別子、さらに初期状態や実行した手順と紐付けて保管してください。これにより、報告された問題の再現性が確保され、ライティング上の懸念とロジックの不具合を区別するのに役立ちます。修正後は、影響を受けた遷移テストと、変更された合流地点や結果を通る少なくとも1つの代表的なルートを再実行します。
変化し続けるストーリーのための実践的なテストサイクル
ストーリーの更新ごとにグラフをエクスポートまたはレビューし、変更されたノード、条件、効果、合流地点を特定して、カバレッジマトリクスを更新します。まずは焦点を絞った状態遷移テストを実行し、続いて影響の大きいセクションや新しく変更されたセクションに対して、選定されたルートサンプリングと人間によるプレイテストを実施します。不具合が発生した場合は開始状態と選択手順を記録し、チームがそれを再現して関連するルールやパッセージを修正し、そのケースをリグレッションチェックとして保持できるようにします。
目標は、何を、なぜチェックしたのかについて、検証可能な記録を残すことです。グラフは構造を検証可能にし、遷移テストはロジックを明示化し、ブランチサンプリングは意味のあるバリエーションへと労力を振り向け、ネガティブアサーションは状態の漏洩を検知し、人間によるプレイテストは解釈を評価します。これらが合わさることで、パスが増加しても有用なカバレッジが提供され、同時にテストされていない部分との境界線が明確に保たれます。