システムを増やす前にサバイバル契約を定義する

システムを増やす前にサバイバル契約を定義する

協力型サバイバルクラフトのプロンプトには、舞台とレシピ一覧だけでは足りません。各プレイヤーができること、物資が共有在庫に入る方法、消費する行動、危険が進む時点、ランの終了条件を明記します。次に短いシナリオで、両方の役割が同じ結果に必要か確かめます。

以下のReedwatch Campは、紙上で設計したオリジナルの説明例です。二人同画面、手番、資源量、暖かさの値はプロンプトの流れを説明するための提案ルールです。プロンプトは実行されておらず、プレイ可能なビルドやセッションも提示されず、実際のマルチプレイ挙動もテストしていません。数値は説明用で、バランス推奨ではありません。

まず共有目標を一文で書きます。素材を二種類集め、両方の役割の作業を組み合わせて風よけを一つ作り、共有の暖かさが0になる前に完成させる。プロンプトが認識できる結果になり、後のルールにも目的が生まれます。

この契約なら「協力」を観察できます。各プレイヤーが必要資源と工作の一部を担当します。サバイバルの圧力が結果のない飾りタイマーになるのも防ぎます。

資源の担当と共有在庫を明示する

ReedwatchではTimberhandが小さな斧を持ち、Timberを正確に2個集めるか、風よけの支柱2本を立てます。Reedworkerは手鎌を持ち、Reedsを正確に2個集めるか、遮蔽幕を編んで固定します。互いの採集や建築行動はできません。個人別在庫、追加素材、隠れた移動コストはありません。

素材2種類は空の共有サッチェルに入ります。有効な採集で指定量を追加し、建築行動は必要量を消費して持続フラグを立てます。二つの建築行動は順不同で、別ラウンドでもかまいません。両フラグが立ったときだけ風よけを設置します。役割制限行動や必要素材なしの建築を選んだ場合、その行動枠は使いますが状態は変化しません。

採集と工作をプロンプト内で分けます。一つの行動で採集も建築もできると、ラウンド記録で相手の貢献が必要だったか分かりません。1行動ルールならトレードオフを読み取れます。今集める、共有素材があれば建てる、または待つ。

寒冷前線を決まった順序で解決する

例を示す前にタイミングを定義します。Aが行動し、Bが行動し、その後に寒冷前線を判定します。そのラウンド中に風よけが完成すれば、その回の暖かさ減少を防ぎます。未完成なら1減り、0に達すると次のラウンド前に終了します。完成した避難所が、すでに失った暖かさを回復することはありません。

以下の基準ケースはラウンド1、暖かさ3、空のサッチェル、建築進捗なしで開始します。値はすべて提案ルールからの手計算で、実行観察ではありません。

採集を遅らせた場合も同じ契約で回復方法を示せます。Reedworkerがラウンド1で待つと、終了後に暖かさが1減ります。ラウンド2でTimberhandが支柱を立て、ReedworkerがReedsを集め、暖かさはさらに1減って1です。ラウンド3でReedworkerが編み、Timberhandが待てば、判定前に風よけが完成し、暖かさ1で勝利します。Reedworkerが再び待てば、ラウンド3終了時に暖かさが0になって敗北します。

判断は創作したボーナスではなく順番から生まれます。安全な基準経路として先に素材を両方集めるか、片方が遅れた後の寒冷判定を受け入れるかです。回復できる余裕を増やしたいなら、開始暖かさか減少ルールを明示的に変更して全行を再計算します。

確認できるプロンプトを書く

天候、道具、食料、戦闘、生産工程を増やす前に小さなシナリオを一つ依頼します。入力、行動上限、状態更新、失敗時、期待出力を記します。以下の貼り付け用プロンプトはReedwatchの紙上設計だけを記述し、SEELEや他のゲームメーカーでは実行していません。

Reedwatch Campという、二人同画面・手番制の小さな協力サバイバルクラフトシナリオを設計してください。これは仕様書であり、既存ビルドがあると主張する依頼ではありません。各ラウンドでA、次にBが行動し、その後に寒冷前線を一度判定します。

リセット時の共有状態：暖かさ3、Timber 0、Reeds 0、支柱なし、幕なし、ラウンド1、Aから行動。暖かさが1以上のとき風よけが設置されたら勝利。風よけ完成前にラウンド終了判定で暖かさが0になると敗北。再起動で初期状態をすべて復元。

AはTimberhand。各ラウンドに正確に一行動：Gather Timberで共有サッチェルへTimberを正確に2追加、またはSet PostsでTimberを正確に2消費しPosts Readyフラグを立てる。Reeds採集や幕編みはできない。

BはReedworker。各ラウンドに正確に一行動：Gather Reedsで共有サッチェルへReedsを正確に2追加、またはWeave ScreenでReedsを正確に2消費しScreen Securedフラグを立てる。Timber採集や支柱設置はできない。建築二行動は順不同または別ラウンドで実行可。両フラグが立ったら直ちに風よけを設置。

どちらの役割もWaitを選べる。実行不可または役割制限行動はそのプレイヤーの行動枠を使うが、資源や建築状態を変えない。両者の行動後も風よけが未完成なら暖かさを正確に1減らす。このラウンド中に完成したら寒冷減少を飛ばす。過去に失った暖かさは戻さない。

現在のラウンド、担当役割、各自が選んだ行動、共有TimberとReeds、建築フラグ2つ、暖かさ、ラウンド終了判定、勝敗を表示。作業場所は小さく：丸太置き場、葦原、中央キャンプ地のみ。個人在庫、追加レシピ、体力、食料、戦闘、耐久度、工作キュー、生産施設、移動コスト、オンライン通信、他のサバイバルシステムは追加しない。

役割と行動表、基準経路とReeds採集を遅らせたケースのラウンド別記録、リセット、無効行動、寒冷判定順、両方の終了状態の確認リストを返す。指定ルールが曖昧または表現できない場合は黙って変更せず指摘する。

出力で操作順が維持されるか確認します。特にBの行動でそのラウンドの寒冷判定より先に避難所を完成できなければ、記載されたラウンド2勝利は起きません。タイミングが変わったらシナリオを拡大する前にプロンプトかルール表を直します。

両方の役割を固定ケースで確認する

緊張感を評価する前に、各行動が意図した状態を作ることを確認します。各ケースで同じ初期状態に戻し、行動を一つずつ変え、実ビルドができてから期待結果と観察結果を比べます。以下は提案する受け入れ計画で、テスト報告ではありません。

数値が異なるなら、資源量、行動担当、手順、建築完了、暖かさのタイミングのどの記述ルールに反するかを特定します。一度に一つのルールを変え、基準ケースと失敗ケースを再計算します。この紙上確認で分かるのは内部整合性だけです。操作が読みやすいか、実装がプロンプトどおりか、難易度が楽しいかは分かりません。

マルチプレイヤーメーカーでシナリオを形にする

SEELE公式マルチプレイヤーページは、プレイヤー数とモード、有用な役割、共有目標、操作規則、確認する短いシナリオを中心とする計画手順を説明します。オンラインプレイには実装、ネットワーク、同期、ホスティング、テストも必要としています。このページが示すのは計画方法であり、同画面・コントローラー2つのシナリオが実装または検証された証拠ではありません。

完成ゲームの主張ではなく契約を持ち込みます。プレイヤー構成、各役割の行動、共有サッチェルの使い方、寒冷判定の時点、勝利条件を指定します。状態表と結果を比較します。製品ページは計画についての説明なので、正確なルールはプロンプトと手作業の確認で担保します。

マルチプレイヤー案の概要を作る段階になったら、マルチプレイヤーゲームメーカーを開き、計画するシナリオに合わせてプロンプトを調整します。現在の流れを確認し、出力を自分で調べてください。この記事は例が生成・テスト済みとは主張しません。

次の確認を選んでから拡張する

最初は手計算できる小さな契約にします。役割限定の行動2つ、共有レシピ1つ、圧力ルール1つ、リセット1つ、終了結果2つです。整合した後、例えば「3ラウンド目は厳しすぎるか」のように次の問いを一つ選び、それを制御するルールだけ変えます。どんな選択を作る仕組みか分かるまで新システムを追加しません。

Reedwatch Campはコンセプトイラスト付きのオリジナル説明用紙上モデルです。テスト済みゲーム、SEELE生成結果、ローカルまたはオンライン協力が動く証拠ではありません。

よくある質問

Reedwatch Campはプレイ可能またはテスト済みの例ですか？

いいえ。Reedwatch Campは紙上で計算したオリジナルの説明シナリオです。行動と暖かさの値はページのルールから内部的に計算しましたが、プロンプト実行、生成ビルド、プレイセッション、ユーザーテストはありません。仕様演習として使い、自分の実装を確認してから観察済みの挙動として説明してください。

両プレイヤーに固有の作業が必要ですか？

共有目標への意味ある貢献が必要ですが、必ずしも完全に排他的な能力である必要はありません。ここではTimberhandが支柱、Reedworkerが幕を担当し、両方の素材が必要です。そのため貢献が見えます。一方の役割だけでレシピを完了できる場合、それが意図的か決め、契約と受け入れケースを更新します。

マルチプレイヤーメーカーはローカルまたはオンライン協力を保証しますか？

いいえ。公式ページは人数、モード、役割、目標、操作、短いシナリオの計画を説明しています。オンラインプレイには実装、ネットワーク、同期、ホスティング、テストが依然必要としています。計画上の説明を生成結果の特定ローカル／オンラインモード対応の証明として扱わないでください。

暖かさやレシピの数値は変えられますか？

はい。値は説明用で、推奨バランスではありません。暖かさ、採集量、レシピ費用、手番順、寒冷判定の時点を変えたら、基準ケースと遅延ケースを再計算します。結果を変えたルールが分かるよう、一つの変更を分離しつつ同じリセット状態と勝敗定義を保ちます。