テキストアドベンチャーの誤字対応：プレイヤーに代わってコマンドを変えない

テキストアドベンチャーで誤字らしい入力を受け取ったら、まず元の入力を残し、解釈が定まらない箇所を示す。そのうえで、確認できる候補と再入力の選択肢を用意する。修正によって行動や対象が変わる可能性があるなら、黙って実行してはいけない。作者が明確にすべきなのは「正解は何か」ではなく、「今回はどう解釈しようとしているのか、プレイヤーはいつそれに同意するのか」だ。

以下は、全体を通して架空の教材用事例であり、実在のユーザー、実測結果、実際の操作テスト、DramaFork の製品機能について述べたものではない。物語の場面には、机の上に銅の鈴と銅製の襟飾りがあり、どちらもすでにプレイヤーに紹介されているとする。文字の関係を保つため、以下では物品名をそれぞれ「銅鈴」「銅領飾」と表記する。ここでプレイヤーが「銅玲を調べる」と入力した。

「調べる」という行動は明確だが、「銅玲」が何を指すかは確定できない。「銅鈴」の誤字かもしれないし、「銅領飾」という名前をうろ覚えだったのかもしれない。そのため、誤りの可能性がある箇所として示すのは「銅玲」全体にする。「玲」を「鈴」に置き換えただけで、コマンド全体を修正できたことにしてはいけない。

ここでは、編集上の判断基準を一つ設ける。修正の前後で、行動と対象が同じだと確定できるか。できないなら、候補の提案にとどめる。字形が似ていることは提案の根拠にはなるが、意図の証明にはならない。その場で妥当に見える候補が一つしかなくても、プレイヤーが同意したことにはならない。

逆に、入力が有効な別名として成立しているなら、同義表現のルールで処理する。二つの物品がどちらも「銅鈴」という名前なら、対象の名称重複が問題だ。実行できない入力をすべて「誤字」と扱わないようにしたい。

まず、同じ机上の場面について三つの入力を用意する。次の表の候補には、プレイヤーがすでに知っている物品だけを使う。「妥当な候補なし」は、作者に修正を提案できるだけの根拠がないという意味であり、その物が物語世界に絶対に存在しないという意味ではない。

この表は作者が作る修正案内の原稿であり、自動認識の正確さを保証するものではない。最初の行には二つ、次の行には一つの解釈があるが、どちらにも断る選択肢を残している。三つ目の行では、候補欄を埋めるために適当な物品を選ぶよりも、対応づけられないと認めるほうがよい。

実際の案内で表全体を見せる必要はない。ただし、編集用の原稿には五つの欄をすべて設ける。特に重要なのが実行するタイミングだ。「確認」とだけ書いて、文字の確認なのか行動の承認なのかを示さないと、実装時に候補を選んだだけで実行済みと扱われるおそれがある。

この例では、一度の明示的な承認を受けて実行する。元の入力が送信されたら、最初にこう表示する。「入力した内容は『銅玲を調べる』です。『銅玲』がどの物品を指すか、まだ特定できません。どのコマンドを実行しますか？ この入力はまだ実行されていません。」

続いて、「実行：銅鈴を調べる」「実行：銅領飾を調べる」「どちらでもないので、入力し直す」の三つを提示する。完全なコマンドを残すのは、行動と対象を同時に確認してもらうためだ。「銅鈴」「銅領飾」だけでは、まだ単語を選んでいる途中で、後から別の送信操作があるように見えやすい。

プレイヤーが「実行：銅領飾を調べる」を選んだとする。その時点で初めて、物語を「銅の襟飾りに目を向けると、縁に浅いへこみがあることに気づいた」と続ける。これは架空の行動結果であり、修正案内に先回りして入れてはいけない。承認前に表示すると、プレイヤーは調べることに同意していないのに、調べた結果の情報を得てしまう。

入力し直すことを選んだ場合は、「今回の修正を取り消しました。行動はまだ何も実行されていません。入力し直してください」と表示する。元の文は編集用に残してもよいが、候補は承認待ちの状態から外す。続けて「銅鈴を調べる」と入力されたら、その新しいコマンドとして処理する。前のやり取りで提示した襟飾りの候補まで一緒に実行してはいけない。

「銅領式を調べる」に対する妥当な提案が「銅領飾を調べる」だけであっても、問いかける形にする。確認が一つ増えれば読む流れは途切れるが、即座に実行すればプレイヤーに代わって対象を決めることになる。この例では、作者が似た文字だけで意図を証明できないため、確認を残している。

妥当な候補がないときは、次の操作を具体的に示す。「入力が間違っています。やり直してください」より、「調べたい対象を入力し直してください」のほうが役に立つ。場面内の物品名を挙げる必要があるなら、すでに示した銅鈴と銅領飾だけにする。誤字への対応を通じて、未発見の物品を明かしてはいけない。

候補を断った場合の結果も明確にする。今回の承認待ちコマンドを取り消して入力に戻し、登場人物の反応、物品の変化、調べることで得られる手がかりを発生させない。この例では、修正のやり取りで物語上のターンを消費しないものとする。作品に別の時間進行ルールがあるなら、待機中に時間をどう扱うかを別途定義する必要がある。「まだ実行していない」という一文だけで曖昧に済ませてはいけない。

古い確認が使われることも防ぐ。承認待ちの間に新しいコマンドが送信されたら、以前の候補を無効にする。その後に「はい」とだけ入力されても、過去の提案を実行してはいけない。承認は、いま提示している今回の完全なコマンドに対応していなければならない。

原稿を渡す前に、表に沿って期待する挙動を一つずつ机上で検討する。その検討を、完了したテストとして記述してはいけない。複数候補の入力は選択の段階で止まり、単一候補は拒否でき、候補なしは再入力に戻る必要がある。三つの経路すべてで、承認前に物語上の行動が起きないことと、拒否後に実行待ちのコマンドが残らないことを確認する。

さらに、行動も不明な反例として、中国語の入力「查砍銅鈴」を加える。「查砍」は、調べることに関わる「查」と、切ることを表す「砍」を含む。対象が明確だからといって、「銅鈴を調べる」に当たる「查看銅鈴」に補ってはいけない。「查砍」は、まったく別の行動に関わる可能性がある。該当箇所を示して行動の再入力を求め、局所的な誤字対応を文全体の意図の推測に広げないようにする。

「『銅鈴を調べる』に修正しました」という書き方も失敗例だ。元の入力を上書きし、同意を得ていない解釈を確定事項として扱っている。代わりに、「『銅玲』は、銅鈴か銅領飾を指している可能性があります。対象を指定してください」と書ける。その後には、完全なコマンドと再入力の選択肢を続ける必要がある。

この表が対象とするのは、行動コマンドの一部にある、表記上の不確かさだ。パスワード、謎解きの答え、登場人物の発言そのもの、意図的に間違えて書かれた文章では、文字どおりの内容を保持する必要があるかもしれない。物品の候補をそのまま当てはめるべきではない。作者は引き渡し時に適用する入力の範囲を明記し、各確認メッセージと実行タイミングを対にして点検する。プレイヤーに示した約束と、次に物語で起こることが一致していなければならない。