AIテキストアドベンチャーの第一ラウンドの書き方:プレイヤー身分、リソース、行動、フィードバックのテンプレート
第一ラウンドでは、プレイヤーが自分が誰で、目の前に何を達成すべきで、どのような行動を取れるのか、そして行動によって何が変わったのかを理解できるようにする必要があります。初期状態を用意し、1回の行動の結果をナラティブ、状態、ログ、次のステップに分解すれば、開始が完全なターンを形成しているかを確認できます。

ガイド
第一ラウンドでは、プレイヤーが自分が誰で、目の前に何を達成すべきで、どのような行動を取れるのか、そして行動によって何が変わったのかを理解できるようにする必要があります。初期状態を用意し、1回の行動の結果をナラティブ、状態、ログ、次のステップに分解すれば、開始が完全なターンを形成しているかを確認できます。
以下では架空の物語『雨港失物処』を使ってデモンストレーションします。これはDramaForkが提供する設計テンプレートであり、例示された数値とターン結果は作者が設定したもので、実際のプレイやモデル出力を表すものではありません。
プレイヤーに今すぐできるタスクを与える
プレイヤーは夜勤の相棒で、閉館前に時間が異常な受け取り票を見つけます。開始時の目標はその出所を検証することであり、プレッシャーは閉館まであと20分あることです。この3つを伝えるだけで、プレイヤーは行動する理由を持てます。
「秘密に満ちた都市で運命を探索する」は第一ラウンドの目標の代わりにはなりません。目の前の対象を説明しておらず、「記録を調べる」と「落とし主に連絡する」がそれぞれ何を解決するのかも判断できません。背景は後で展開してもかまいませんが、第一ラウンドでは行動に必要な情報を提供しなければなりません。
プレイヤープロフィールの名前と才能にも用途があるべきです。「記録の直感」を選んだなら、照合時に番号形式に追加で注意を払えます。ただし、才能がすべての真実を自動的に明かすべきではありません。作者はそれがどの観察を改善し、どの手順を飛ばせないのかを明記する必要があります。
このラウンドで実際に読み取られる状態だけを表示する
ステータスバーは職業、装備、10種類の属性で埋め尽くす必要はありません。まず行動が読み取る、または変更するフィールドを列挙し、各フィールドの意味を定義します。
| フィールド | 初期値 | 現在の用途 |
|---|---|---|
| 閉館までの時間 | 20分 | このラウンドで行える検証作業を制限する |
| 有効な手がかり | 0件 | すでに検証済みの事実を記録する |
| 相棒の信頼 | レベル1 | 許嵐が追加記録を共有するかどうかを決める |
| 現在の目標 | 受け取り票の出所を検証する | このラウンドのタスクをプレイヤーに思い出させる |
| 完了済み行動 | なし | 重複した照会を新しい発見とみなすのを防ぐ |
「信頼レベル1」はあくまで例示的な尺度であり、アップ条件を明記しなければなりません。明確な用途のないフィールドは当面表示しないでかまいません。プレイヤーが装飾的な数字を操作可能なルールだと誤解するのを避けられます。
さらに「異常を1箇所見つけた」と「受け取り票が偽造であると証明した」を区別する必要があります。前者は手がかりであり、後者は判断です。状態表がこれらを混同すると、以降のストーリーは未検証の結論の上に築かれてしまいます。
選択肢に前提、代償、情報利益を書く
第一ラウンドでは3つの行動を提示できます。原本の登記簿を調べる、票に書かれた番号に連絡する、まず許嵐に尋ねる。選択肢の文言は動作を説明し、必要なら既知の代償を示し、完全な結果を事前に漏らしません。
たとえば「5分かけて登記簿を照合する」は「真実を探す」よりも判断しやすいです。プレイヤーは時間が減ることを知りつつ、それだけの価値があるかを決める必要があります。番号への連絡が同じ所要時間なら、それは異なる情報をもたらすべきで、単に修辞を変えるだけではいけません。
同時にプレイヤーの自由入力を許可する場合、まずこのシーンで合理的に処理できる行動範囲を列挙します。プレイヤーが「近くのカメラを探す」と言えば検証フローに入れますが、「未来を直接知る」と言えば、現在の人物にはその能力がないと説明する必要があります。自由入力の詳細な処理は別途行動表にできますが、第一ラウンドではまず主経路の完全性を確保します。
照合可能な完全なターンを書く
プレイヤーの行動:「5分かけて原本の登記簿を調べ、まず受け取り番号を見る。」
ナラティブ例:「あなたは番号七三一を見つける。登記時間は物品の入庫時間より早いのに、横に補記の説明がない。許嵐は別の登記副本を押し出し、先に署名を照合するよう提案する。」
この結果は動作を確認し、新しい観察も与えますが、誰が嘘をついているかを独断で宣言してはいません。対応する状態更新は以下のとおりです。
| 項目 | 行動前 | 行動後 | 理由 |
|---|---|---|---|
| 残り時間 | 20分 | 15分 | 登記簿の検証を1回完了した |
| 有効な手がかり | 0件 | 1件 | 説明が欠けた時間異常を発見した |
| 相棒の信頼 | レベル1 | レベル1 | このラウンドではまだ関係変化の条件を満たしていない |
| 完了済み行動 | なし | 番号七三一を調査済み | 同じ手がかりを重複取得するのを防ぐ |
ログはこう書きます:「七三一の原本記録を照合:登記時間に異常、補記説明が欠落、署名照合待ち。」これは観察済みの事実と未完了タスクだけを保持し、ナラティブ全体を繰り返さず、作者の秘密をプレイヤーに書いて渡すこともありません。
次のステップでは「署名を照合する」「受け取り人に尋ねる」「補記記録を追跡する」を提示します。これらの行動はたった今得た情報に応答し、前のラウンドが可能なことをどう変えたかをプレイヤーに見せます。
3種類の異常入力で開始をチェックする
まず通常の行動を入力し、ナラティブ、状態、ログが一致しているか確認します。ナラティブでは5分かかったと言っているのに状態が変わらないなら、ターンが信頼できる形で整合していないことを示します。
次にリソース不足の行動を入力します。残り3分しかないのに5分の検証を要求する場合です。作者は拒否するか、簡略化した方法を提供するか、明確な結果を伴う超過を許可するかを事前に決めるべきで、同じシーンで規則を勝手に変えてはいけません。
最後に曖昧な行動を入力します:「この票を処理しておく。」プレイヤーが照合したいのか、修正したいのか、他人に渡したいのかを問い返す必要があります。曖昧な入力をそのまま最も代償の高い行動に解釈すると、プレイヤーは表現していない選択を負わされます。
DramaFork テキストゲームカタログはテキストアドベンチャーの入口を提供しますが、設計時にはモデルが生成したナラティブと検証済みの状態結果を依然として区別する必要があります。プロンプトがリソースの一致を要求しても、すべての演算が決定論的ルールで保証されているわけではありません。信頼できる数値が必要な場合は、重要な変更を個別に確認すべきです。
第一ラウンドを通過してから世界を拡張する
設定を知らない人に開始部分を読んでもらい、現在の身分、目標、選択肢の代償、たった今起きた変化を尋ねます。作者が補足説明しないと答えられないなら、まず情報とフィードバックを修正します。
納品時には初期状態、プレイヤーの行動、ターン結果、異常入力の処理を保持します。この4つの資料により、後続の書き手はどの事実がすでに成立しているかを知り、第二ラウンドが第一ラウンドを忘れていないかも確認できます。まず1つのターンをしっかり照合してから、章、アイテム、結末を増やします。


