テキストゲームの失敗状態：物語上の挫折か、入力や配信の問題かを見分ける方法
チャット形式のテキストゲームにおいて、ターンがうまくいかなかったとしても、プレイヤーの選択が間違っていたとは限りません。シーン内で妥当な物語上の挫折に直面したのかもしれませんし、ゲーム側がその表現に対応していなかったり、キャラクターに行動に必要な知識が欠けていたり、あるいはメッセージ自体の配信に失敗した可能性もあります。これらの状況には、それぞれ異なるフィードバックと再試行（リトライ）の効果が求められます。まずは原因を分類し、何が変化して次に何ができるのかをプレイヤーに伝えましょう。
まずは「何が失敗したのか」を問いかける
実用的な第一の問いは、「ゲームは意図された行動を理解し、物語の中で処理（解決）したか？」です。イエスであれば、その結果は挫折（セットバック）かもしれません。ノーであれば、問題が入力にあるのか、キャラクターの持っている情報にあるのか、あるいはシステムによる配信にあるのかを見極めます。この4つの分類は、インタラクティブフィクション（IF）システムが構文解析（パース）、ワールドルール、ストーリーフロー、そして取り消し（Undo）の挙動をどのように分離しているかから導き出された設計上の指標であり、万人に共通する技術標準ではありません。たとえばInformのドキュメントでは、パーサーとシミュレートされたワールドモデルをゲームの別個の要素として説明しており、そのパーサーはコマンドが一致しなかった理由を複数に分けて報告できます。（Inform 6 Designer’s Manual: Introduction、Inform 6 Designer’s Manual §33: Helping the parser out of trouble）
メッセージは、ゲームの「応答契約（レスポンス・コントラクト）」の一部として扱いましょう。それは次の3点に答える必要があります。「何が起きたか」「物語の状態が変わったか」、そして「プレイヤーは今何ができるか」。たとえば、「紙の船は対岸に届く前に転覆してしまいました。折りたたまれたメモはまだあなたの手の中にあります。もっと川幅の広い場所を試すか、別の渡り方を選ぶことができます」といった短い一文があれば、挫折の内容、手元に残ったアイテム、そして次のステップが明確になります。
1. 妥当な物語上の挫折
挫折が適切なのは、ゲームが行動を理解し、現在のシーンと照らし合わせて検証したうえで、作中世界の結果を意図的に生み出した場合です。たとえば、プレイヤーが一度に運ぼうとした図書館の本が多すぎて、1冊が近くの椅子に滑り落ちてしまうようなケースです。あるいは、浅い小川の向こう岸に届く前に紙の船が浸水してしまうような場合です。その結果が不都合や意外な展開であったとしても、やり取りをプレイヤーに対する判定・批判にしてしまう必要はありません。
決定的な特徴は「状態の変化」です。シーン内で船が沈んだと告げられたなら、その結果は物語の中で事実でなければなりません。回収できるのであればその方法を説明し、船が失われたのであれば、同じ文章を再試行しても巻き戻せないことを示します。再試行とは、別の船を作るか、別のルートを選ぶか、あるいは変化したシーンから再開することを意味するかもしれません。正確な選択肢はゲームのルールによって決まります。
有益な挫折メッセージは、試みた行動、その結果、そして選択可能な続きの手順を示します。結果が好ましくなかったからといって、正しくサポートされている行動を入力エラーのように見せかけてはなりません。逆に、ゲームがストーリーの状態を実際に変えていないのであれば、何らかの結果が生じたかのように装うべきではありません。この区別があることで、プレイヤーは自分が新しい状況から続けているのか、それとも未処理のコマンドを修正しているのかを理解できます。
2. 未対応の入力：ゲームが表現を解決できなかった場合
未対応の入力とは、プレイヤーのメッセージをゲームがサポートする行動にマッピングできない状態を指します。ゲームが少数のボタン選択肢しか受け付けないシーンでプレイヤーが「パン屋にアプリコットについて尋ねる」と入力したり、パーサーが認識しない名前を使用したりした場合がこれに当たります。これはインターフェースのカバー範囲を示すものであり、プレイヤーのアイデアの良し悪しを意味するものではありません。
インタラクティブフィクションのパーサーは、なぜ具体的で有益なフィードバックが必要なのかを示してくれます。Informでは、認識できない動詞、あいまいな指示、入力不足、視認できないオブジェクトなどに対して個別のエラーが用意されています。またそのマニュアルには、ゲームが一般的なパーサーエラーをより情報量の多いメッセージに置き換える方法も示されています。（Inform 7 §18.35: Printing a parser error）チャットゲームであれば、「ここでは『アプリコットについて尋ねる』を処理できません。配達について尋ねるか、カウンターから話題を選んでください」といった簡潔な応答が考えられます。
修復への道筋を提示しましょう。インターフェースに応じて、認識可能な選択肢を表示する、焦点を絞った確認を1つ尋ねる、あるいはプレイヤーに言い換えを促すといった対応が可能です。サポートされていないコマンドを物語上の失敗として描写してはなりません。行動が実行されなかった場合は、そのことを明確に伝えます。以前のシーンをそのまま維持し、修正された入力を送信することは、ストーリーイベントを巻き戻すのではなく、同じ瞬間をやり直すことなのだと明確にしてください。
3. キャラクターの知識不足：まだ答えがない妥当な質問
入力内容は理解できるものの、キャラクターがそれに基づいて行動するのに十分な知識を持っていない場合もあります。たとえば、店員のアシスタントが領収書を見る前に、プレイヤーが小包がどこに配達されたかを尋ねるようなケースです。ゲームは質問を認識しつつ、確定的な回答を適切に保留することができます。
これは未対応の入力とは異なります。トピックや行動自体は妥当であり、制約は作中におけるキャラクターの情報にあるのです。その境界を明確に示しましょう。たとえば、「ミナは配達伝票を見ていないため、通りの名前を言えません。小包のラベルはまだカウンターの上にあります」といった具合です。ラベルを調べる、他の人に尋ねる、後で戻ってくるといった行動が可能なら、そのルートを示します。そうでない場合は、ヒントをでっち上げたり、質問が不適切であるかのように扱ったりせず、実際に知られていることだけを伝えてください。
この応答によって時間が経過するのか、あるいは状態が変わるのかを決定してください。その質問をすることが作中の通常の行動であるなら、ゲームはその会話を記録したり、後のキャラクターの反応を変えたりするかもしれません。ゲームが知識に関する質問を「コストなし（手番消費なし）」にしたい場合は、シーンを維持して別の質問を続けられるようにします。情報のリクエストによって密かにチャンスが消費されたのかどうかを、プレイヤーに推測させてはなりません。
4. 技術的な配信の失敗：行動がストーリーに到達していない可能性
配信の失敗は物語の外側で発生します。応答がタイムアウトしたり、2重に表示されたり、文章の途中で途切れたりする場合です。ゲームは、行動が処理されたことを把握できない限り、キャラクターが行動した、あるいはストーリーが進んだと断定することはできません。これは、「配達員が住所を見つけられなかった」といった作中のメッセージ（物語上の結果）とは明確に異なります。
平易なステータスの言葉を使い、確認済みの状態を報告してください。ターンが処理されなかったことをゲーム側で確認できるなら、そう明記してプレイヤーに再送信を促します。ターンが処理されたかどうか判断できない場合は、同じ行動が2回実行されてしまう可能性があるため、やみくもな再試行を促すのは避けてください。不確実であることを手短に説明し、現在のシーンを確認するか、最後に確認された時点から再開できる手段を提供しましょう。これらは、失敗した入力一致とストーリーの結果を区別する必要性から導かれた設計上の推奨事項であり、前述のフィクションシステムがチャットの配信失敗に関する共通プロトコルを定めているわけではありません。
配信が復旧したら、最後に確認されたメッセージを復元するか、シーンおよび完了が確認された最新の行動を簡潔にまとめたリキャップ（要約）を表示します。要約には、新しいストーリーのターンではなく要約である旨を明記してください。プレイヤーが再送信を選択した場合は、それが新たな試みとして扱われるかどうかを明確にします。そのわずかな透明性があるだけで、重複した行動が意図的な再試行と誤解されるのを防ぐことができます。
再試行（リトライ）、取り消し（アンドゥ）、再開（レジューム）の意味を使い分ける
これらの言葉はそれぞれ異なる状態効果を表すため、混同して使用しないようにしましょう。「再試行（リトライ）」は、現在の状態のままもう一度行動を送信することであり、すでに確定した結果を密かに消去してはなりません。「取り消し（アンドゥ）」は、以前の状態を復元することです。「再開（レジューム）」は、中断の後に最後に確認された状態から続行することです。「最初からやり直す（リスタート）」は、ストーリーを最初から開始することです。
TwineのHarloweマニュアルでは、「undo」を前のパッセージに戻り、現在のパッセージで行われた変数の変更を破棄することと定義しています。また、「restart」はページをリロードしてストーリーを最初から始めることと説明されています。アンドゥの履歴が制限される場合があることにも言及されています。これらの仕組みは、曖昧な「もう一度試す」というラベルに頼るのではなく、コントロールがその適用範囲を明確に伝えるべき理由を示しています。（Harlowe 3.3.8 Manual: undo and restart）
簡潔な判定シーケンスを用意することで、インターフェースの一貫性を保つことができます：
ゲームはその行動を理解し、解決しましたか？ イエスなら、物語上の結果と残された状態を報告します。
システムは表現をサポート対象の行動にマッピングできませんでしたか？ 解決できなかった内容を説明し、修正への道筋を示します。シーンは維持してください。
行動は理解されたものの、キャラクターに情報が不足していましたか？ 知識の境界線と、作中で詳細を知るための手段があればそれを説明します。
処理や配信が不確実ですか？ 確認できている内容を伝え、安全に確認または続行できる手段を提供します。
プレイヤーが前に戻りたい場合は、コントロールに「取り消し（アンドゥ）」と名付け、どの時点またはどの変更が復元されるかを明記します。「最初から（リスタート）」は最初からやり直す場合のみに使用してください。
各失敗メッセージのための簡単な一貫性チェック
応答を実装・リリースする前に、ストーリーの状態と照らし合わせて確認しましょう。挫折を描写している場合、作中の世界は実際に変化しましたか？ 未対応の入力を描写している場合、ゲームはその行動が発生したかのように装っていませんか？ キャラクターの知識不足の場合、コマンドの欠落と明確に区別されていますか？ 配信が失敗した場合、ターンが処理されたかどうかをプレイヤーは把握できていますか？ そして、再試行や再開のコントロールは、そのラベル通りの挙動をしていますか？
テキストゲームのフィードバックが、キャラクターが体験したこととインターフェースが対応できなかったことをプレイヤーが区別できるよう支援していれば、ゲームは公平に感じられます。明確な結果はストーリーを保ち、具体的な入力ガイダンスは再挑戦を可能にし、誠実な知識の限界は物語の整合性を守り、定義された復旧手順はプレイヤーに進むべき確かな道筋を与えてくれます。