協力プレイの契約を定義する

協力型プラットフォーマーには、共有条件を明確にする必要があります。各プレイヤーの役割、行動が一緒に数えられる時点、片方が失敗した場合の挙動です。長いステージを頼む前に小さな循環を定義します。以下のTwinspan Relayはオリジナルの紙上設計例で、既存のビルドやプレイテストではありません。1.5秒のペア成立時間と4秒の橋はルールを確認しやすくするための設定値で、バランス測定値ではありません。

協力プレイの契約を定義する

「プレイヤーを協力させる」という雰囲気ではなく、操作の循環を状態の順序として書きます。Twinspan Relayでは配達人2人が同じ走る・跳ぶ操作を使います。各リレーでAは青い足場、Bは琥珀色の足場に着地します。最初の正しい着地で共有タイマーが始まり、2人目も時間内に対応する足場へ着地すると短い橋が現れます。橋が引っ込む前に両者が渡り、そろって到着したときだけチェックポイントが進みます。

この契約は失敗状態も定義します。違う足場への着地、落下、タイマー切れで両者を最後の共有チェックポイントへ戻し、橋を消します。この説明用設計では、片方だけを待たせたりライフを失わせたりしません。一人が先に着いても、もう一人が渡っている間はチェックポイントを無効のままにします。進行をチームの状態に結び付けます。

表により、タイミングと回復が両プレイヤーから見えるようになります。景色や追加仕組みを足す前に、各行にトリガー、状態変化、次の状態があるか確かめます。「橋が開く」だけでは、いつ閉じるか、チームがどう復帰するかが足りません。

プロンプト1：共有ルールを書く

プレイヤー数、画面範囲、共同目標、回復規則を決める短い契約プロンプトを使います。未解決の前提をビルダーに黙って補わせず、質問するよう求めます。

共有画面1つのローカル協力プラットフォーマーを2人用に計画してください。両者は同じ走る・跳ぶ操作を使い、固有能力はありません。共同目標は足場のペアを使うリレーを3つ越えて出口へ一緒に着くことです。

各リレーではAが青い足場、Bが琥珀色の足場に着地します。最初の正しい着地で1.5秒のペア成立時間が始まります。2人目が時間内に担当足場へ着地すると、連続して歩ける橋を4秒間作ります。橋が閉じる前に2人とも次の共有チェックポイントへ行く必要があります。間違った足場、落下、ペア成立時間切れ、橋の時間切れでは両者を最後の共有チェックポイントへ戻し、進行中のタイマーと橋を消します。2人とも到着した場合だけチェックポイントを進めます。両者が最後の対応足場に着いた後だけ出口を開きます。再起動でスタート地点に戻し、すべてのタイマーを消します。

両プレイヤーの位置、担当足場、ペアタイマー、橋タイマー、共有チェックポイント、出口状態の状態表を返します。残る前提を列挙します。ローカル同画面の計画にし、オンライン接続、非対称な能力、ライフ、ランダムイベントを追加しないでください。

このプロンプトは実行記録ではなく設計テンプレートです。確認したい状態をビルダーに見える形で出すよう求めます。実際の操作が2つのコントローラーで異なるボタンを使うなら、両者の行動が同じであること、最初の穴の前に各入力を説明していることを確認します。

一つの穴だけのプロンプトを書く

契約を開始、操作、認識できるチェックポイントを備えた小さな遭遇にします。穴と足場の組を一つにすれば、問題の原因候補が減ります。ジャンプ前に見える情報、最初の着地が計時を始める時点、橋に残り時間をどう示すかを指定します。

Twinspanの例では色の異なる二つの足場が向かい合う縁にあります。最初の対応着地で1.5秒が始まり、2人目の対応着地で橋ができます。一時的な道は経路だと分かる幅にし、その先のチェックポイントは配達人2人が着くまで無効にします。

プロンプト2：リレーを一つ依頼する

最初のビルド依頼は狭く保ちます。移動操作に加えて、リセットと見える状態表示も求めます。どちらも協力循環の一部だからです。

このルール契約から小さなローカル2人用プラットフォーマー試作を作ってください。共有画面1つ、コントローラー2つを使い、両者に同じ走る・跳ぶ能力を与えます。安全な開始足場、A用青い着地足場、B用琥珀色の着地足場、向こう側の共有チェックポイントがある、渡れる穴を一つ作ります。

両プレイヤー、担当足場の色、最初の正しい着地後の1.5秒ペア成立時間、両方の足場が埋まった後の4秒橋タイマーを明確に示します。橋は途切れない歩行可能な面にします。橋が閉じる前に両者が触れた場合だけチェックポイントを進めます。プレイヤーが落ちる、違う足場に着地、ペア時間後に着地、橋タイマーを逃したら、両者を前のチェックポイントへ戻して進行状態を消します。両者をスタートへ戻すRestartを加えます。

両者と穴全体が見える広さにカメラを保ち、簡潔な操作説明を含めます。他の穴、収集品、敵の攻撃、固有能力、ランダムイベント、オンラインプレイを加えないでください。依頼した規則のうち、実装したものと未検証のものを分けます。依頼だけでビルドの成功を前提にしないでください。

仕様が優れていても実装は保証されません。ビルドツールに使う場合、各トリガーで状態表示が変わるか、最初のプレイヤーが待つ間も2人目が操作できるかを確認します。後の変更と比較できるよう、実際のプロンプトとビルド版を保存します。

最初のリレー後にルートを延ばす

実際の一つ穴ビルドが同じプレイヤー・逆順プレイヤー確認に合格してから、核となるルールは変えずルートを延長します。足場の色、タイマー、橋の長さ、リセット、チェックポイントの挙動を再利用します。後の失敗を見つけやすくするため、穴の幅や着地高度など幾何学的な要素を一つずつ変えます。

延長プロンプトではこれらの不変条件を保ち、現在のリレーとチェックポイントを示すルート概要を求めます。後の穴が難しいというだけで能力を追加しないでください。課題が計時、意思疎通、移動距離のどれを試すのか先に決めます。

プロンプト3：リレーを二つ追加する

一つ穴の版を受け入れ確認に照らして調べた後に限り、同じローカル協力ルートへペア着地リレーを2つと最後の出口を追加してください。移動能力、青／琥珀の足場割り当て、1.5秒のペア成立時間、4秒の橋、共同チェックポイント規則、失敗・落下時のリセット、再起動挙動を維持します。リレー間で変えるのは穴の間隔、着地高度、景観だけです。

ペア合図が出る間、両プレイヤーが見えるようにします。共有チェックポイント、進行中のリレー、各プレイヤーが穴の手前・担当足場・橋の上・チェックポイントのどこにいるかを表示します。両者が出口の対応足場に着いた時だけ最後のゲートを開きます。簡潔なルート図と状態遷移一覧を返します。ネットワーク、新能力、敵、ランダムルールを追加しないでください。一つ穴の版を調べていなければ、これは計画中の延長として示し、検証済みと呼ばないでください。

両プレイヤーの状態を確認する

協力の展開が明確か判断する前に、再現可能な操作手順を書きます。両者の開始位置、先に着地した人、着地間の経過時間、橋が開いたか、共有チェックポイントが進んだかを記録します。以下の値はTwinspan Relayの紙上計算で、プレイ可能ビルドの観察ではありません。

最初のリレーではAがt=0に青へ、Bがt=1.0に琥珀へ着地します。1秒は1.5秒のペア時間内なので、t=1.0に橋が開きt=5.0に閉じます。両者はt=3.2に閉鎖前のチェックポイントへ着き、例の状態は進行します。2つ目のリレーではBがt=1.9に着き、t=1.5のペア時間後です。橋はできず、両者とも前の共有チェックポイントに戻ります。

これらの期待状態は後で実ビルドを確認する受け入れケースで、テスト証拠ではありません。有用な観察記録にはルール版、両コントローラー、操作、時間、プレイヤー位置、リレー状態、チェックポイント、結果を含めます。結果が異なる場合、診断中は操作順を変えないでください。

循環全体を変えずに失敗を修正する

ペアが失敗した場合、意図した順序と最初に異なった状態を特定します。担当足場が見えなかったなら、タイマーを変える前に合図かカメラを直します。正しい着地は検出されたのに橋が開かないなら、足場一致とタイマー開始を調べます。一人だけ進めたなら、ステージを増やす前にチェックポイント条件を直します。

実際の修正では一度に原因を一つ変え、同じ操作順を繰り返します。カメラ調整とペア成立時間を同時に変えません。足場を明るくしながらリセット規則も変えません。観察したこと、原因の推測、変更したことを別々に記録します。ビルドやプレイヤー観察がないなら、修正案は設計アイデアとして示し、改善を実証したと呼びません。

プロンプト4：焦点を絞った修正を依頼する

提示する実際の操作順と状態ログを使い、協力リレーが書面契約と最初に異なる地点を特定してください。実装の不一致と、視認性、カメラ、操作の問題を分けてください。小さな変更を一つ提案し、維持する挙動を示し、同じ操作順を再確認手順として記載します。

プレイヤーの感想、テスト結果、修正成功を捏造しないでください。観察ログがない場合は原因候補のチェックリストを返し、実際に起きた原因だと主張しないでください。証拠が特定の変更を示さない限り、共有チェックポイント、足場割り当て、タイマー、リセット規則を維持してください。

小さなマルチプレイヤーシナリオを引き継ぎに使う

SEELEのMultiplayer Game Makerページは、人数、役割、共有目標、操作規則、短いシナリオの計画方法を説明しています。オンラインプレイにはプロジェクト固有の実装、ネットワーク、同期、ホスティング、テストも必要としています。協力案を組み立てる参考にはなりますが、Twinspan Relayのローカル操作や指定の計時規則が動くことは検証しません。モードを広げる前に、実際の出力で両プレイヤーの状態変化を確認します。

共有目標と受け入れ手順を一つ書くことから始めます。短いマルチプレイヤー案をまとめる段階で、マルチプレイヤーゲームメーカーを使います。ページは計画の引き継ぎとして扱い、実際に作るプロジェクトで必要な挙動を確認してください。