AIゲームマスターの設計
AIゲームマスターには構造化出力と文章のどちらが必要？
RPGで構造化出力が役立つ場面、物語の文章が必要な場面、ダイス・権限・保存状態をゲームエンジンが検証すべき理由を解説します。
構造と物語に異なる役割を与える
AIゲームマスターは、プレイヤーが何を試みたかを理解し、何が起きたかについて魅力的な物語を語らなければならない。これらは関連する役割だが、同じ段落がルールと保存済み状態の唯一の情報源であってはならない。構造化出力は、モデルが提案した決定をプログラムが検査しやすくする。物語の文章はプレイヤーに雰囲気、対話、明確な次の選択肢を与える。どちらの形式も単独で生成された主張を真にすることはできない。
例示的な場面を想像してほしい：盗賊が封じられた宝物庫に到達し、「小さな鏡を使って、鍵に触れる前に魔法の紋様を調べる」と言う。ゲームは調査の試行を識別し、ダイス判定が必要かどうかを判断し、ダイスを解決し、盗賊が何を知ったかを描写するかもしれない。モデルが解決前に「解放の印を見つけ、宝物庫を開ける」と書けば、描写がルール上の処理を先取りしている。これは設計上の例であり、Playworldsの本番動作の記録ではない。
提案する判断には小さなスキーマを使う
構造化された提案には、試行されたアクション、対象オブジェクト、必要かもしれない判定、関連するルール参照、決定を要する不確実な点を含められます。宝物庫の場合、鏡による検査を試行されたアクションとして識別し、知覚または調査の判定を提案するかもしれない。ダイスの値を断定したり、アイテムを与えたり、キャラクターを移動させたり、宝物庫を開いたとマークしたりすべきではない。
OpenAIは、モデルをアプリケーションのツールに接続する関数呼び出しと、モデルが返すものを形作る構造化応答形式を区別している。そのStructured Outputsガイドは、サポートされている厳密なスキーマがスキーマの遵守を強制すると述べるが、構造化された結果に依然として誤りを含む可能性があると警告している。ゲーム設計において、それは「check_required: false」のような有効なフィールドも、ルールと状態に対してレビューすべき主張であることを意味する。パーサーの検証を通ることは最初の関門にすぎない。
ダイスと状態をゲームの管理下に保つ
エンジンは、結果を決定する事実を所有すべきである：キャラクターの能力、所持品、利用可能なアクション、ダイス、目標値、および承認された世界状態の変更。提案されたワークフローにおいて、モデルは判定を要求したり、それが重要かもしれない理由を説明したりできる。アプリケーションはその要求を検証し、ダイス判定を実行または記録し、解決された結果を返す。その後にのみ、ナレーションが結果を描写する。仲間は、別のダイス判定を作り出したり、既存の結果を書き換えたりせずに、完了した判定に反応できる。
承認された結果がダイスの目が11で修正値2を加えた13で、目標値16を下回ったとしよう。ナレーターは、鏡の中で印がぼやけ、鍵は封じたまま、盗賊はスケッチを参照したり、仲間に尋ねたり、別のツールを試したりできると言うかもしれない。13を静かに成功に変えてはならない。ルールが部分的な結果を許可する場合、エンジンは物語の文章がそれを事実として提示する前に承認すべきである。
結果が判明してから物語の文章を書く
ナレーションは、構造化された提案とは異なる確認基準を持つ。試行された方法を認め、解決された結果を尊重し、NPCの知識を保持し、有用な決定点で終わるべきである。状態更新が許可しない限り、新しい傷、状態、またはアイテムが追加されたとは主張せずに、盗賊の手元の真鍮の冷たさを描写できる。エンジンはメカニクスの権威でありながら、場面は生き生きと保たれる。
この分離により修正が容易になる。提案された判定が間違っていた場合、解釈またはルールマッピングを変更する。判定と状態は正しいが場面に物足りなさがある場合、ナレーションブリーフを改善する。物語の文章がダイスの結果と矛盾する場合、ナレーション入力と後処理を検査する。同じ保存済みの場面を使って出力を比較する。
無効および不確実な応答の処理
スキーマには、不確実性に対する明確な扱い方が必要である。モデルは、プレイヤーがルールの質問をしているのか、作中で行動しているのか、複数のアクションを一度に説明しているのか判断できないかもしれない。自信のあるルール選択を強制するのではなく、定義された範囲の「確認が必要」または「判定の提案なし」の結果を返すようにする。参照されたキャラクターIDと場面オブジェクトを現在の状態に対して検証し、許可されたアクションを超える変更を拒否する。スキーマは、オブジェクトが実際にアドベンチャーに存在することを証明できない。
拒否、不完全な応答、非対応のスキーマ、ツール結果の欠落、または古い場面バージョンは、そのまま物語の確定イベントとして扱ってはいけません。安全な理由を記録し、定義された制限内で再試行する；そうでなければ、より明確なアクションを要求するか、やり直せるエラーを表示する。
実用的な受け入れ前のチェックリスト
生成されたターンを受け入れる前に、確認する：(1) 提案されたアクションはプレイヤーの言葉と一致したか？ (2) 参照された各キャラクターとオブジェクトが現在の場面に存在したか？ (3) エンジンはダイス判定が必要かどうかを決定し、結果を記録したか？ (4) 状態変更は検証され一度だけ保存されたか？ (5) 物語の文章はそれらの承認された事実と一致し、次の選択肢をプレイヤーに残したか？ (6) リロードで同じ場所、ダイスの結果、結末を再現できるか？ これらのチェックは設計の手順であり、Playworldsの測定済みの性能の主張ではない。
プレイヤーは、自分のキャラクターが何を試みたか、ルールがどのように解決したか、そしてどのような選択肢が残っているかを視認する必要がある。Playworldsは、世界、キャラクターシート、ダイス、継続的なアドベンチャーを一つのゲームで扱います。小さなアクションを試み、その後、表示されたゲーム状態と応答を比較してみよう。私たちのアクションガイドはその動きを具体的にするのに役立つ。