AIプロンプトで非対称協力ゲームを設計する

非対称協力ゲームが機能するのは、プレイヤーごとに異なる情報があり、互いに代わりがきかない行動を持つときです。まず共通の目標を一つ決め、各役割が見られるものと変更できるものを定義し、その結果が全員に分かるようにします。そのうえで、小さな遭遇を一つ作り、ルールを拡張する前に確認できる方法を用意します。

以下のプロンプトは、音声で連携する二人向けの洞窟救助コンセプト「Lantern Relay」を使います。これはオリジナルの教材用アイデアで、制作もテストもされていません。Keeperはルートマップを見て遠隔シャッターを一つ操作します。Delverは物理ミラーを一つ回し、自分に見える光線の区間を報告します。これらは例示のための設計上の仮定であり、SEELEの機能についての主張ではありません。

キャラクタークラスより先に依存関係を定義する

キャラクターの役割を名付ける前に、次の文を完成させます。「私たちは、あるプレイヤーが［個別の情報］を使って［行動］し、もう一人が［異なる情報］を使って［別の行動］をすることで、初めて［共通の目標］を達成できる。」どちらかの行動を取り除いても解法が変わらないなら、役割は名前だけ異なり、まだ相互依存していません。

非対称協力ゲーム用のプロンプトでは、共通の目標を先に書き、各役割の情報境界と専用行動を定義します。一方の報告が他方に必要となる瞬間と、何が変わったかを知らせるフィードバックも含めましょう。これにより「能力が違う」だけの無関係なキャラクター説明ではなく、実際のパズルの流れに結びつけられます。

情報分担の例は、Keep Talking and Nobody Explodes の公式リモートプレイガイドにもあります。Defuserは爆弾を見ますがマニュアルは見ず、Expertsはマニュアルを使いますが爆弾を見ません。Lantern Relayは別の舞台とルールを使います。設計で重要なのは、行動が成功する前に役割間でどの情報を伝える必要があるかです。

両方の役割に欠かせない仕事を持たせる

Lantern Relayでは、Keeperは固定された洞窟ルートと遠隔シャッターの選択肢を知っていますが、現在どの光線区間が点灯しているかは見えません。Delverは進行中の光線と物理ミラーを見られますが、ルートマップは見えず、シャッターも操作できません。Delverはミラーを調整して見えた区間を伝えます。Keeperはその報告を使って該当するシャッター設定を選びます。両方が正しく設定されて初めて、光線が救助ゲートに届きます。

これは役割の契約です。それぞれに個別情報、その情報に結びつく行動、相手と連絡を取る理由があります。長いプロンプトを書く前に、プレイヤーが指し示せる名詞と動詞で表を埋めましょう。「Scoutは足が速い」だけでは不十分です。「Scoutは圧力板を見つけ、押さえ続けられる」なら、もう一方の役割が利用する具体的な依存関係になります。

この表から典型的な失敗も分かります。Keeperのマップに現在の光線区間まで表示されるなら、Delverの報告は新しい情報を伝えません。Delverだけでミラーを調整して目標を達成できるなら、Keeperは観察者です。会話や追加の部屋、キャラクター成長を足す前に、こうした隙間をルールで埋めましょう。

ルールから一つの部屋へ進む3つのプロンプト

回答ごとの目的が一つになるよう、依頼を分けます。まず役割の契約を定義します。次に、小さく遊べるやり取りを求めます。選んだツールで必要な操作が表現できない場合は、構造化した設計引き継ぎを依頼します。最後に、実際の観察結果を待つ評価計画を作ります。以下は非対称協力ゲーム用のAIプロンプトのひな型です。角括弧内を置き換え、例が未テストである点を忘れないでください。

プロンプト1：役割の契約を定義する

ちょうど［プレイヤー数］人向けの協力ゲーム案を設計してください。
共通目標：［グループが達成することを一文で記載］
連絡方法：［プレイヤー同士が情報を共有する方法］

各役割について次を示してください。
- その役割だけが観察できる情報
- その役割だけが実行できる行動
- 行動後に変わる状態
- 他のプレイヤーに報告できる合図

情報、報告、相手の判断、行動、共有フィードバックの順に依存関係を示してください。開始状態、有効な行動、成功条件、失敗条件、リセット状態を含む短い遭遇を一つ作成してください。
次に各役割を一つずつ取り除き、遭遇が解けるか説明してください。ある役割を取り除いても解法が変わらない場合、依存関係を修正してください。まだ部屋、進行要素、追加システムを増やさないでください。

役割表、状態遷移表、設計判断が必要なルールを返してください。ゲームが制作またはテスト済みだとは主張しないでください。

この最初の依頼は、作り込んだ世界ではなく設計契約を求めます。すべての役割に、気づくこと、行うこと、相手の次の判断に影響する報告があるか確認しましょう。回答に未決定の実装詳細が含まれていたら、確定した挙動として扱わず、未決の判断事項として残します。

プロンプト2：最初の部屋の範囲を決める

「Lantern Relay」という洞窟救助パズルの部屋を一つ設計してください。
これは音声で連携する近くにいる二人の参加者向けの架空の教材用アイデアです。このプロンプトは実行もテストもされていません。

共通目標：ビーコンを救助ゲートまで導く。
Keeperの視点と行動：固定ルートマップと遠隔シャッターの選択肢が見えるが、洞窟のライブ映像と現在の光線区間は見えない。Keeperだけが遠隔シャッター設定を一つ変更できる。
Delverの視点と行動：光線と物理ミラー一つが見えるが、ルートマップと遠隔シャッターの状態は見えない。Delverだけがミラーを回し、点灯中の光線区間を報告できる。
ルートマップには可能な経路が示され、Delverの報告は現在の光線区間を特定する。Keeperは報告を使って対応するシャッターを選ぶ。光線が救助ゲートへ進むには、ミラーとシャッターの両方を正しく設定する必要がある。

開始状態、有効な各行動、無効な行動へのフィードバック、成功状態、失敗または時間切れ状態、開始状態へのリセットを示す。物理ミラーは一つ、遠隔シャッターも一つにする。戦闘、インベントリ、キャンペーン進行、オンライン接続、ボイスチャットソフト、二つ目の部屋は追加しない。提案する各視点で役割ごとの情報を分ける。

利用可能なビルドツールが二つのローカル入力や別々の視点を表現できない場合、プレイ可能だと見せかけず、構造化した仕組みとインターフェースの引き継ぎを返す。判断が必要な仕組みは明示する。
状態表と短い受け入れチェックリストを返す。

回答後はアートの方向性を判断する前に状態表を読みましょう。誤ったシャッター設定で回復可能な結果が見えるか、DelverがKeeperのマップを見ずに光線の状態を報告できるか、Keeperがその報告を使って意味のある次の行動を選べるかを確認します。ツールや実行環境でこれらの制約を表せない場合、設計の引き継ぎには意味がありますが、協力ゲームが動作した証拠にはなりません。

プロンプト3：実際に集めた観察を評価する

この一部屋協力ゲームについて、私が提示する観察結果を検討してください。
プレイヤーの行動、テスト記録、成功結果を捏造しないでください。

設計契約：［合意済みの役割表と開始状態を貼る］
観察した手順：［記録した行動と応答のみを貼る］
期待した結果：［ルールに基づく結果を記載］
実際の結果：［プレイヤーまたはビルドが示した内容を記載］
最初の混乱点：［最初に生じた曖昧さを引用または説明］

観察した手順を契約と一段階ずつ比較してください。
最初の不一致を挙げ、関係するルールまたは合図を説明し、範囲を限定した修正を一つ提案してください。部屋、役割、無関係なルールは維持します。
観察が欠けている、または曖昧な場合、次に何を記録すべきか質問してください。提示された観察が裏付けない限り、設計が合格したとは言わないでください。
変更する行、これから観察できるはずのこと、次回セッションでの確認項目を一つ返してください。

「評価」という言葉より、入力内容の方が重要です。観察した手順がなければ、モデルが提案できるのは設計チェックであって、プレイヤーの振る舞いの報告ではありません。実際に観察を集めたら、期待した結果と最初に混乱した瞬間も含めましょう。両方の役割を書き直すのではなく、最小の不一致を対象に修正できます。

両方のプレイヤーが必要か確認する

役割表には意図が書かれていますが、部屋には観察可能な確認が必要です。開始状態から遭遇をたどり、各段階でそれぞれが何を知っているかを確かめます。以下は自分の設計を見直すための提案であり、Lantern Relayのプレイテスト結果ではありません。

一度に一か所だけ変更します。報告が曖昧なら、ヒントシステムを追加する前に合図を明確にします。役割が何もせず待っているなら、その観察から行動までの段階を減らします。目標が分かりにくいなら、パズルを増やす前に光線やゲートのフィードバックを改善します。範囲を絞った修正なら、引き続き評価したい部分を保てます。

実際の観察に基づいて修正する

プレイヤーと一緒に設計を観察できるようになったら、行動、期待した結果、実際の結果、最初に迷ったり誤解したりした箇所の四つを書き留めます。確認する瞬間がないまま「Keeperが退屈だった」と結論づけるのは避けましょう。「Delverの報告前にKeeperがどちらのシャッターでも選べた」という記録なら、変更して再確認できる具体的な依存関係が分かります。

修正するルール以外は部屋の状態を維持します。それから同じ開始状態を再現し、報告によって相手の判断が変わるか確認します。これで設計のバランスや幅広い使いやすさが証明されるわけではありませんが、次に確かめることを追跡できます。実際の観察を得るまでは、プレイテスト結果ではなく、確認すべきリスクとして表現してください。

目的を絞ったブリーフを制作フローに持ち込む

紙上の契約に矛盾がなければ、焦点を絞ったアイデアをゲーム制作フローに入力し、生成内容を確認できます。SEELEの現在の無料AIゲームメーカーページは、平易な英語での説明、2Dまたは3Dのプレイ可能な結果の確認、Workspaceでの反復を案内しています。また表示される生成コストとアカウントの選択肢を確認するよう伝えています。これらの一般的なフロー情報は、ローカル協力プレイ、二つの同時ローカル入力、音声連絡、この架空の部屋を検証するものではありません。

共通目標、最初のプレイヤー行動、シーン状態、フィードバックを依頼文に含めます。そして、結果が各操作と役割を実際に表現できているかを、協力ゲームの試作とみなす前に確認しましょう。使用するフローで二つのプレイヤー視点や入力を表せないなら、その出力は設計の出発点にとどめ、実装方法は別に計画します。パズルについては、AIパズルゲームメーカーのページが一つのルール、見える手がかり、解決行動、結果の組み立てに関係しますが、マルチプレイ対応を示すものではありません。

よい最初の成果は、契約に照らして確認できる最小のものです。各役割が情報か行動に貢献し、無効な選択には説明があり、成功状態が両者の行動から明確に導かれる場合だけ、部屋を残します。条件を満たさなければ、二つ目の部屋に広げる前にルールを一つ見直すか、設計の引き継ぎを依頼しましょう。