遭遇ルールを検証可能な形にする

タクティカルシューターのプロンプトは3段階で作ります。遭遇ルールを定義し、プレイ可能な部屋を1つ頼み、将来のビルドを期待状態と比較します。簡潔なルール仕様で追加武器、敵、マップにループを覆われる前に、位置取りとタイミングを見えるようにします。

Relay Roomは手計算で解決した独自の架空例です。プロンプトひな形は未実行で、ゲームビルド、プレイテスト、測定結果を主張しません。以下の追跡表は将来確認用の期待状態で、観測済み挙動ではありません。

このプロンプト集をステルスやジャンル概説に混ぜない

この記事はタクティカルシューター案があり、実装・確認できる焦点概要が必要な設計者向けです。成果物は、1つの決定的な部屋に基づくルール、遭遇、将来検証のプロンプトです。タクティカルシューター全般の幅広いガイドより狭く、行動受け入れ、射線、敵タイミング、後のテストで記録する状態に紙幅を使います。

ステルス用プロンプト集とは別の問題も扱います。Relay Roomには巡回、騒音、隠密、検知メーター、脱出カード目標はありません。プレイヤーは警備ドローンが1レーンを予告するのを見てそのタイルから離れ、1行動の窓を使って射撃します。救助目標、マップ再構築、キャンペーン経路、キャラクター選択、シナリオ編集も追加しません。それぞれ別のルール仕様が必要です。

範囲を意図的に小さく保ちます。オペレーター1人、ライフル1丁、機械の脅威1体、接続位置4つ、ラウンド5回。ジャンルの唯一の設計法を主張するのではありません。何が合法か、受け入れられた行動の後に何が変わるか、拒否後に何を維持すべきかをプロンプトで明確にする方法を示します。

ビルドプロンプト前にRelay Roomを定義する

架空の目的は、ラウンド5終了までに敵警備ドローンRookを無力化し、オペレーターを生存させることです。部屋の接続経路はEntry Cover → Center Lane → East Cover → North Cover。各位置でプレイヤーからRookへの射線（LOS）は固定されています。遮蔽形状は、その場所から撃てるかとは別です。

LOSは指定射撃位置から確認します。しゃがみ、覗き込み、追加照準行動はこの例に含みません。露出するのはCenter Laneだけです。EastとNorthではプレイヤーはRookを見られますが、バリアが直接射撃を遮ります。

初期状態はプレイヤーがEntry Cover、体力2/2、ライフル弾2/2、Rook体力2、センサーシャッター閉、ラウンド1です。毎ラウンドに認められるプレイヤー行動は1つ。隣接場所へ移動、1回射撃、その場を保つ。Rookは受け入れられた行動後に動きます。マークラウンドは1と3で、次ラウンドに撃つタイルとしてCenterを塗ります。射撃ラウンドは2と4。マークされたCenterにいる時だけ斉射で体力1減少。空のタイルへの斉射成功後、Rookのセンサーシャッターは次に受け入れるプレイヤー行動1回だけ開きます。

Rookへの射撃が合法なのは4条件すべてが真の時です。Rook有効、弾あり、シャッター開、現在位置からLOS明瞭。合法射撃でRook体力1と弾1を減らします。開いた間に受け入れられる射撃・移動・待機はいずれも窓を消費し、次の敵フェーズ前にシャッターを閉じます。移動と待機で弾は使いませんが行動は消費します。窓で撃つか、位置取りに使って閉じるかが意味のある選択になります。

拒否入力は受け入れられた移動と異なります。Entryから遮蔽射撃、閉じたシャッターへの射撃、弾切れ射撃、無効な移動は、行動枠、ラウンド、弾、シャッター、敵予定を変えません。簡潔な拒否合図を出し、同じ枠内で修正できます。Rookの体力0で即時無力化し遭遇終了。プレイヤー体力0で敗北、ラウンド5終了時にRookが有効でも敗北。再開で正確な初期状態を戻します。

安全ルートと失敗ルートを追う

安全ルートでは各斉射前に予告タイルを離れ、LOSの通る位置から開いた2つの窓を射撃に使います。フェーズ順が重要です。Rookの斉射は受け入れられた行動後に解決され、シャッターが開くのはFireフェーズ解決後です。

両射撃は受け入れられます。ラウンド3と5の開始時にシャッターが開き、Rookは有効、弾が残り、EastとNorthからLOSが通ります。命中ごとにシャッターが閉じ、次の予定フェーズへ進みます。オペレーターが先にマークレーンを離れたためCenterへの斉射は外れます。

失敗ルートでは警告の意味が分かります。ラウンド1でCenterへ移動しRookがマーク。ラウンド2にそこに留まり、斉射が当たって体力は2から1、シャッターが開きます。ラウンド3にCenterから射撃。LOSは明瞭で合法なので弾は1、Rook体力も1になります。シャッターが閉じCenterを再度マーク。ラウンド4に留まると次の斉射で体力1から0になり即敗北。ラウンド5射撃はありません。これは架空ルールの手計算で、プレイテストではありません。

ルール、プレイ、検証の3つをプロンプト化する

各プロンプトの役割を分けます。ルール段階で実装前に矛盾を見つける。ビルド依頼は余分な機能を求めず遭遇1つを記述。検証プロンプトはアクセス可能なビルドがあり、実状態を観測できて初めて有効です。以下は計画文で、モデルに送信していません。

プロンプト1：ルールを定め監査する

以下の架空Relay Roomタクティカルシューター遭遇について、決定的ルール仕様を作る。仕組みを創作しない。返答：(1)状態変数と初期値、(2)接続位置マップと各位置からRookへのLOS、(3)受け入れ/拒否行動ルール、(4)ラウンド1～5の正確なプレイヤー/敵フェーズ順、(5)勝敗と再開条件、(6)安全/失敗追跡の遷移表。
初期状態：プレイヤーEntry Cover、体力2/2、ライフル弾2/2、Rook体力2、センサーシャッター閉、ラウンド1。接続位置：Entry Cover → Center Lane → East Cover → North Cover。プレイヤーLOS：Entryは頑丈な壁で遮断、Center明瞭、Eastは側面射撃口越しに明瞭、Northは低いバリア越しに明瞭。EastとNorthのバリアはプレイヤー射線を維持しながらRookの直接射撃を遮る。
毎ラウンド受け入れられる行動は1つ：隣接位置へ移動、1回射撃、または待機。射撃にはRook有効+弾あり+シャッター開+LOS明瞭が必要。無効/遮蔽行動を拒否しても行動枠、ラウンド、弾、シャッター、敵予定は変わらない。受け入れ行動後に予定Rookフェーズを解決。ラウンド1と3はCenterをマーク。ラウンド2と4はCenterへ射撃。占有されていればプレイヤー体力1減、いなければ外れる。Fire後、次に受け入れるプレイヤー行動1回だけシャッターを開ける。受け入れ射撃/移動/待機で窓を消費して次敵フェーズ前に閉じる。移動/待機は弾を使わない。射撃はRookに1ダメージ、弾を1発消費。Rook体力0で無力化し即終了。プレイヤー体力0、またはラウンド5後にRook有効なら敗北。再開で正確な初期値。
両追跡の各遷移を手計算し、矛盾を黙って直さず指摘する。各行動と敵フェーズ後の期待状態を返す。観測ゲームプレイやテスト結果は存在しない。

返された表はフェーズ順のずれがないか確認します。修理、追加行動、2度目の斉射があれば設計が変わります。記述ルールが安全/失敗追跡と食い違うなら、ビルド依頼にする前に仕様内で解決します。

プロンプト2：プレイ可能な遭遇を1つ依頼する

承認済みRelay Room仕様で、架空のRelay Roomタクティカルシューターを一人称の小さな試作として作る。Entry Cover、Center Lane、East Cover、North Coverが接続する固定部屋1つと小型Rook警備ドローン1体。指定された視線と遮蔽を保つ。ラウンド、プレイヤー体力、ライフル弾、Rook体力、警告タイル、シャッター状態を明瞭に表示。
各ラウンドで受け入れるプレイヤー行動はちょうど1つ：隣接空間へ移動、射撃、待機。射撃はRook有効、弾あり、シャッター開、プレイヤーからRookへのLOS明瞭の場合のみ受け入れ、ダメージ1、弾1消費。予定敵フェーズ後、ラウンド2と4のFireで次の受け入れプレイヤー行動1回だけシャッターを開く。受け入れ移動または待機は弾を使わず窓を消費・閉鎖。無効または遮蔽行動の拒否で行動枠、ラウンド、弾、シャッター、Rook予定を変えず、同枠で修正可能にする。Rook体力0で即勝利。体力0またはラウンド5後にRook有効なら敗北。正確な初期状態へ再開。
他の敵、武器、ステルス、救助目標、マップ、ランダムダメージ、リロード、記載外行動を追加しない。受け入れ/拒否への操作と見える反応を示す。これは設計依頼としてのみ扱う。検証可能な出力がない限り実行・制作・テスト済みと報告しない。

確認可能なフィードバックを求めます。斉射前にマークタイルが見え、安全移動でそれを避けられ、拒否された射撃で指定状態がすべて不変。特定エンジンやコード構造を決めつけず、何を確認するか読者に伝えられます。

プロンプト3：期待状態と将来ビルドを検証する

アクセス可能なプレイ可能Relay Roomビルドが提供された場合に限り、承認ルール表どおりに安全追跡と失敗追跡を実行する。プレイヤー行動と敵フェーズ後の実状態を記録：位置、プレイヤーからRookへのLOS、受け入れ/拒否行動、ラウンド、マークタイル、プレイヤー体力、弾、Rook体力、シャッター、予定フェーズ、終了結果。観測値を各期待値と比較。最初の不一致を記して、その遭遇が早期終了したら追跡を停止。
特に4位置のLOS、ラウンド2と4後の1行動窓、受け入れ移動/待機で窓を消費し閉じること、Entryで遮蔽射撃を拒否して行動枠、ラウンド、弾、シャッター、Rook予定を変えないことを確認。プロンプト返答やコンセプト画像から合格を推測しない。ビルド/実行証拠がなければNOT RUNとし、実観測欄は空欄。

期待状態と実状態を別列に置きます。手計算例がプレイヤーや製品の実動作として後で紹介されるのを防ぐ小さな規律です。

紙上仕様と将来ビルドを比較する

3つ目のプロンプトを使う前に、短い観察表を用意します。提供されたビルドでプレイヤーが確認できる内容だけを記録し、期待値から実際欄を埋めません。期待と最初に違う状態を比べれば、1つの失敗箇所を絞れます。

将来の実装確認では否定経路も試します。位置を変える前にEntry Coverから遮蔽射撃を試します。期待結果は拒否合図で、ラウンド、弾、シャッター、敵予定は同じです。ビルドが進んでしまうなら、最初の修正はダメージ値でなく行動受け入れにあります。

AI FPSワークフローに遭遇を焦点化して持ち込む

公式ページによるとAI FPS Game Generatorは一人称の遭遇1つに焦点を当てます。目的、脅威、プレイヤーの反応を定め、ルートと武器反応を確認し、再プレイ後に細部を調整します。サンプルプロンプトではパルスライフル、動きの遅いドローン2体、体力・弾HUD、命中フィードバック、出口条件、再開を持つブラウザFPSを記載しています。Free AI Game Makerページは平易な英語プロンプト、プレイ可能な最初の2D/3D版、ブラウザーテスト、追加プロンプトによる改良を説明します。これは製品ページの説明で、Relay Roomを検証も正確なルールを保証もしません。

AI FPS Game GeneratorとFree AIゲームメーカーのページを参照する場合は、AI FPSゲームの一般的なワークフローを確認します。