テキストアドベンチャーの同義コマンド設計：「見る」と「じっくり見る」を同じ操作にするには

「レンズを見る」と「レンズをじっくり見る」に一貫した応答を返すには、まず一回の観察で何をするのかを定義し、その定義に合う表現を同じ行にまとめます。判断基準は、対象・働きかけ方・終了時の状態です。意味の近さは候補に挙げる理由にはなりますが、それだけで同じ操作とは決められません。

以下の古い写真館は、すべて架空の教材用事例です。場面、入力、応答、判定はいずれも説明のために作成したもので、実際のユーザー体験、実測結果、試遊結果、DramaForkの製品機能を示すものではありません。本稿で扱うのは、意味がすでに明確な単一コマンドだけです。自由入力を処理する仕組み全体には踏み込みません。

机の上には、まだ分解されていない古いレンズが一つあり、その隣には閉じたレンズケースがあります。作者が解決したいのは、プレイヤーが観察の言い方を変えただけで、あるときは傷が見つかり、別のときは「その操作はできません」と返される問題です。

最初に、基準となる動作を「レンズの外観を観察する」と定めます。対象は机の上のこのレンズ。方法は、現在の明るさと位置のまま目で見ることで、動かしたり、拭いたり、分解したりはしません。終了時にはレンズの位置も構造も変わらず、プレイヤーは外周の傷と、見えているガラス面についたほこりの粒を知ります。

ここでいう終了時の状態には、物体だけでなく情報も含まれます。物体が変化していないことだけを確認しても不十分です。「レンズを見る」も「レンズの内部を調べる」も、実際には物体を動かさないかもしれません。しかし後者が求める情報は、すでに外観の範囲を超えています。

この事例では、通常の観察に所要時間の区分を設けず、詳しく見たときだけ見つかる手がかりも設定しません。そのため、「じっくり」は見るときの姿勢を表すだけで、操作を増やす必要はありません。観察にかかる時間をコストとして扱う作品なら、この前提は当てはまりません。

まず適用対象と基準動作を埋め、次に同義表現を並べ、最後に意味は近くても同じ操作にはならない反例で境界を確かめます。先に動詞を大量に集め、それをあらゆる物体に無理に当てはめないようにします。

三行目は、別の操作のための枠を設け、境界を示す行です。プレイヤーが今この場で分解を許可されているという意味ではありません。「分解する」は別の操作に属すると記録しておくことで、入力を受け付けるためだけに、作者がいつの間にかそれを観察へ置き換えてしまうのを防ぎます。本稿では分解の条件と結果を補っていないため、この行をもって分解の処理が完成したとはいえません。

表を再利用するときも、観察対象ごとにこの五列を残します。同じ行の中では応答を共有できますが、行をまたぐ場合は対象と状態を改めて確認する必要があります。レンズもレンズケースも「じっくり見る」を受け付けますが、得られる情報は明らかに異なります。

この事例で「レンズをよく見る」を受け付けるのは、「よく」が新しい接触方法、時間コスト、得られる情報を加えないからです。その代わり、ざっと見ることと詳しく見ることの段階差はなくなります。プレイヤーは、表現を強めるだけで隠された手がかりを得ることはできません。

詳しく見て初めて刻印が見つかるようにしたいなら、精査を別の操作として定義し、追加される情報と条件を明記して、表も修正すべきです。二つの表現を同等だとしながら、「じっくり見る」だけに報酬を与えてはいけません。それではプレイヤーは、依然として作者の好む言葉を推測しなければなりません。

「レンズを回して見てみる」は観察方法を変え、物体の移動も含みます。末尾に「見てみる」があるからといって、同じ操作にはまとめられません。「レンズを拭く」は表面の状態を、「レンズを分解する」は構造を変えます。「レンズの内部を調べる」は、異なる範囲の情報を求めます。それぞれが、元の動作の別々の境界を越えています。

「レンズを調べる」のように範囲が不明な表現は、この表にはひとまず載せません。その場面で外観の観察を指すのか、機能の点検を指すのかを作者が明確にしてから、対応先を決めます。語彙表を網羅的に見せるために、意味の定まっていない表現を既存の動作へ押し込む必要はありません。

机上で確認するときは、すべての入力を「レンズは未分解、位置は変わっていない、まだ観察していない」という同じ場面のコピーから始めます。そうすれば言い回しを比較でき、入力順による差を同義語の問題と取り違えずに済みます。

入力が「レンズを見る」の場合。対象は明確で、方法は目視、終了時の状態も一行目に合います。レンズ外観の応答を使い、プレイヤーが傷とほこりの粒の情報を得たことを記録します。

入力が「レンズをじっくり見る」の場合。この事例の前提では、所要時間も観察の詳しさの段階も増えないため、同じく一行目を使います。草稿に「特に気になるものはない」とあれば、先の入力で得られる情報と矛盾します。同義表現を削るのではなく、応答を修正すべきです。

入力が「レンズを分解する」の場合。構造の変化は観察の範囲外なので、分解の操作へ渡します。現段階の教材用草稿では「分解ルールは要追記」として構いませんが、観察に成功したという応答を返し、コマンドを処理できたことにしてはいけません。

入力が「レンズケースをじっくり見る」の場合。動詞は同じでも対象が違うため、二行目を使い、ケースの外側だけを描写します。応答が中の緩衝材に触れていれば、知らないうちにケースを開けるか、透視する操作を行ったことになります。範囲外の情報を削る必要があります。

最後に、連続入力を別に確認します。まず「見る」、次に「じっくり見る」。場面が変化していなければ、二回目は既存の発見を短く振り返っても構いません。ただし、言葉を変えたことだけを理由に手がかりを増やしたり、最初に見えた傷を否定したりしてはいけません。明るさや物体の状態が変わった場合は、新しい前提に合わせて結果を書き直します。応答がいつまでも同じであることを求めるべきではありません。

プレイヤーが「レンズをじっくり見る」と入力した後に、「あなたは『見る』を実行した」と機械的に告げる必要はありません。基準動作の名前は、主に作者が対応関係を管理するためのものです。本文では見えたものを直接描写すれば、たいていは何が起きたか伝わります。

境界を強調したければ、「レンズは元の場所に置かれたままだ」という一文を残せます。ただし、これは物体を動かしていないことは示せても、分解していないことまでは単独で証明できません。編集時には応答全体を読み、回す、拭く、分解するといった動作が加わっていないか確認する必要があります。

原稿を渡す前に、表にある同義表現を一つずつ同じ場面に当てはめ、情報、物体の状態、コストが一致するか確かめます。続いて意味の近い反例を入れ、誤って同じ操作として扱っていないか確認します。よくある失敗は二つです。冒頭の動詞だけを変えて古い分岐の結果を残すことと、対象の違いを無視して動詞を一括置換することです。

この表が適用できるのは、対象と単一の動作がすでに明確なコマンド文です。プログラムがどんな言い換えでも認識できることを証明するものではなく、対象の省略、複数動作の連結、曖昧な意図も扱いません。作者が渡すのは、実装と確認に使える意味上の取り決めです。どの表現が結果を共有し、どの違いを残すべきかを明確にします。