共有目標を一つから始める

協力型ゾンビシューターには、プレイヤー2人と増え続ける敵だけでは足りません。共有目標、各自の明確な役割、弾薬、修理、進捗が競合する短い判断時間が必要です。このガイドでは前提を小さなプロンプト手順と、手計算した3ウェーブの経路にまとめます。

以下のDead Air at Beacon Fourは架空の設計演習です。プロンプトは実行されておらず、プレイ可能なビルドや協力プレイのセッションも提示されていません。数値はテスト済みのバランスデータではありません。紙上契約として調整し、結果を説明する前に実際のビルドで確認してください。

共有目標を一つから始める

「二人がゾンビを撃つ」だけでは、なぜ一緒にいるのかを生成側が考えることになります。戦闘と見える結果をつなぐ共通課題を与えます。緊急ビーコンを充電し、ゲートを保ち、同じ脱出地点へ一緒に到着する。そうすれば最初の試作で、誰が各脅威に弾薬を使うか、ウェーブ間に二人で何をするか、どんな状態がチーム勝利か、という三つを確認できます。

最初のビルド案は意図的に小さくします。雨のリレー施設、サバイバーごとの固定カービン1丁、短いウェーブ3回、ビーコン1つ、ゲート1つ、救助トラック1台。設計上は二人が同じ画面で汎用ゲームパッドを別々に使います。左スティックで移動、右スティックで照準、トリガーで発射、Interactでビーコン操作または蘇生。これは架空の操作案で、特定ツールがローカル協力やネットワークを支援する主張ではありません。

大群を説明する前に中核ルールを固定する

景色を頼む前に開始状態、コスト、タイミング、リセットを書きます。小さな表なら「緊張感」や「協力的」といった形容詞では決められないルールが見えます。

これらの数値はプロンプトを確認しやすくしますが、ゲームの公平さを証明しません。例えば20秒ウェーブでは標的が見やすく、判断に十分な時間が必要です。ただし移動速度、出現間隔、射撃応答がそのタイミングに合うかは実際のビルドでしか分かりません。

ウェーブループで充電、装填、修理を追う

休憩時間が共有目標をチームの判断に変えます。充電は脱出を進め、装填は次の射撃に備え、修理はゲートを守ります。二人が同じ行動をして進捗を二重に得ないよう、ビーコン増加を区間ごとに1点までとします。

計算は簡単に監査できます。各発射で装填弾を1発消費。ウェーブ2の残敵1体がゲートを1減らし、ウェーブ3の残敵2体が2減らし、最後の修理で1増えます。ビーコンは3回の休憩で1点ずつ増えます。この記述経路ではサバイバーが攻撃を受けないため、体力は3/3のまま、各1回の蘇生権も未使用です。紙上表は経路探索やリアルタイム照準をシミュレーションしません。動作すると主張する前に実装と観察が必要です。

段階を分けたプロンプト手順を使う

一つの巨大なプロンプトでルール、アリーナ、ウェーブのバランス、見た目を同時に決めさせないでください。工程を分ければ、欠けたルールを分かりにくい表示や操作になる前に修正できます。

1. ルールと状態の契約を依頼する

Dead Air at Beacon Fourという、架空の同画面ローカル協力型トップダウン見下ろしゾンビシューターを設計してください。アートを追加する前に、サバイバー2人、リレー施設、20秒ウェーブ3回（体力1のWalkerが2/3/4体）、固定カービン各1丁、体力3、弾倉2、予備弾4、ゲート5、ビーコン0/3、8秒の安全休憩の状態表を返してください。発射は必ず弾1発を消費、命中でWalker1体を倒す。ウェーブ境界に残った各Walkerはゲートへ一度ダメージを与え、その遭遇から退場。各プレイヤーは区間ごとに充電、予備から最大2発装填、ゲート1点修理のいずれかを選び、同時に解決。チームのビーコン充電は最大1点。ダウンと蘇生、両者の脱出、敗北、完全な再起動規則を含めてください。仕組みを黙って創作せず曖昧点を列挙します。これは設計依頼で、ビルドが存在する主張ではありません。

このプロンプトは先に明確な状態モデルを求めます。回答が1区間1充電上限を変える、予備弾を共有する、使用済み蘇生フラグで再起動する場合は、場面を頼む前に不一致を解決します。

2. 最初のプレイ可能範囲だけ依頼する

合意した表から、同画面プレイヤー2人、同一カービン各1丁、ゲート、琥珀ビーコン、段階的なウェーブ3回、8秒休憩、脱出区域1つを備えたプレイ可能なアリーナを一つ依頼します。体力、装填・予備弾、ゲート耐久、ビーコン充電、ウェーブ、残り時間を見やすく表示します。指定した同時休憩選択、10秒ダウンタイマー、2m以内で2秒蘇生し体力1回復、各サバイバー1回の蘇生制限、ゲート0で失敗、列挙した状態をすべて戻す再起動を実装します。キャンペーン、ボス、武器強化、リダイレクト、追加アリーナ、オンラインプレイは除外します。操作と状態確認の短いチェックリストを返し、観察していないテストを完了と報告しないでください。

焦点を絞った依頼でも、生成結果の確認は必要です。実際の流れでプレイ可能な結果が得られたら、要求した仕組みがすべて入ったと思い込まず、見える操作と状態を契約に照らします。

3. 実際の観察後に不一致を一つ修正する

実際の操作と観察状態を提示した後で、次の期待状態と比較してください：[対象ウェーブ／休憩行の正確な内容を貼る]。不一致の原因となるルールまたはフィードバックだけを変更します。もう一人の状態、ゲート、ビーコン、弾薬、タイミングは維持します。変更ルール、変更前後の期待値、再現可能な確認一つを返します。観察ログが添付されていなければ、失敗を創作したり、この確認が合格したと主張したりしないでください。

この3つ目のプロンプトは意図的に条件付きです。このパッケージには貼り付ける観察結果がないため、完了した反復ではなくテンプレートのままです。チュートリアルを公開するときも区別を保ちます。手計算例は確認方法を教えられますが、テスト結果の代わりにはなりません。

敵の数だけでなく操作を確認する

実際のビルドができたら、一度に観察可能な状態を一つ確認します。これは計画中の受け入れ確認で、結果ではありません。修正の範囲を絞れるよう入力、期待変化、観察値を記録します。

プロンプトに書かれているから、またはコンセプト画像にフィードバックが描かれているからといって「テスト済み」と呼ばないでください。テストには実際のビルド、再現可能な入力、観察結果が必要です。それまでは表を計画として示します。

一般的なサバイバルページを範囲限定の出発点にする

現在の公式AI Survival Game Generatorページは、限られた物資、読みやすい環境圧力、安全な目標、ミスからの復帰という一般的なサバイバル計画を説明しています。最初のサバイバルブリーフを作る材料にはなりますが、ゾンビ固有のルール、2人操作、同画面協力、ネットワークを確立しません。これらの仕組みは自分の設計契約に残し、現在の出力が実際に何を支援するか確認します。

広い製品の出発点としてAIサバイバルゲームページを使います。参照先のルートは現行ですが、この記事候補のBlogパスは暫定で、entry-sourceスラッグはローカルの帰属情報にすぎません。公開前に受理されるBlog URLを確認し、スラッグを整合させてください。ページがこの例を生成した、または協力システムに対応すると推定しないでください。

観察をもとに一つ修正する

プレイ可能な結果があれば、最初に異なる状態をルール表と比較します。ウェーブ終了時にWalkerが2体残るのにゲートが3回損傷するなら、敵速度、体力、ビーコンを同時に変えず、境界イベントを調べます。原因を一つ変え、同じケースを再実行し、新状態を記録します。これで反復を証拠に結び付けます。

ここではプレイ可能な結果が提示されていないので、責任ある次の手順は架空ループを紙上仕様として、確認項目を未実行と扱うことです。値を調整し、最初の範囲を絞った制作を依頼し、その後でのみプレースホルダーを実測観察に置き換えます。基準となる二人循環が見えて確認できてから、ボス、キャンペーン、武器構成を追加します。

よくある質問

最初のウェーブを協力型にするには？

両者に共有目標と意味のある選択肢を与えます。この架空例では同じゲートを守り一つのビーコンを充電し、各自が別のWalkerを狙えます。特定の操作実装を前提にせず、操作とチーム挙動は実際のビルドで確認します。

最初の3ウェーブはどう増やすべきですか？

一度に読みやすい圧力値を一つ変えます。例ではWalkerを2、3、4体と増やし、各Walkerの体力1と20秒の長さは維持します。数は提案した紙上値で、測定難易度ではありません。実際の試作では出現間隔、照準時間、ゲートへの圧力を繰り返し確認します。

両プレイヤーで弾薬を共有すべきですか？

この設計では各自に弾倉と予備弾を持たせ、片方の射撃が相手の資源を黙って使わないようにしています。発射は装填弾1発を消費し、リロードは最大2発移します。共有弾薬も設計できますが、最初のプロンプトでは一つの方式を選び、前後の値を示します。

サバイバーがダウンしたときどうなりますか？

この提案ルールでは体力0で10秒のタイマーが始まります。2m以内の相手がInteractを2秒保持し、成功すると体力を正確に1回復してタイマーを消します。各サバイバーは1ランで1回だけ蘇生でき、権利を使った後の再ダウンはラン失敗です。架空設計ルールで、テスト済み機能ではありません。

プロンプトでオンライン協力を保証できますか？

いいえ。プロンプトは依頼であり、実装の証拠ではありません。公式製品ページが示すのは一般的なサバイバル計画の文脈だけで、ゾンビゲーム、ローカル協力操作、オンライン通信は確立されていません。機能を説明する前に現在の出力を確認し、この架空例が生成・テストされたと主張しないでください。