ボスラッシュのルールを定義して最初の試作へ進む

ボス一覧ではなくルール契約から始める

ボスラッシュ用プロンプトは、各攻撃に合図、合法な対処、失敗時の結果、明確な隙を用意すると制作や確認がしやすくなります。まず遭遇一つ分のルールを書き、その後、焦点を絞った初回ビルドを依頼して状態を確認します。後続ボスやラン全体の資源はその後に設計しましょう。

以下のBellvault Trialsは、この手順を説明するオリジナルの教材用設計です。ランナー一人、ボス三体、区切られた戦闘ビートを使います。これは手計算で解決した例であり、プロンプト実行、生成ゲーム、プレイ、バランステストではありません。すべての値は応用可能な提案ルールとして扱います。

設定や演出を考える前に、一体のボスの一つのフェーズについて、同じ六項目を埋めます。

この小さな契約があれば、「手ごわい」「公平」「反応がよい」などの表現でルールの不足が隠れません。メーカーが詳細を異なる形で解釈する可能性は残るため、見えるフィードバックと各遷移を確認する方法を契約で指定します。

各合図を一つの防御行動に対応させる

各フェーズに意図した防御を一つ用意し、資源を使う代替案は別に定義します。この設計では、Tell中にFocusを1消費すれば対応防御の代わりになりますが、二度目のStrikeができるわけでも、後続ボスのルールが変わるわけでもありません。

ボス三体は体力2で開始します。Opening中の正しいStrikeは体力をちょうど1減らし、そのOpeningを消費します。体力1でPhase Bの合図を表示し、体力0でボスを倒して合図を消します。Tell中のStrikeなど不正な行動は、体力、Focus、フェーズ、結果のどれも変えません。

たとえばTide CantorのPhase Aの合図が表示され、ランナーが弾に正しくParryした直後です。弾をそらした表示がParry成功のフィードバックになり、よろめくボスが次に使える安全な行動を示します。ランナーはまだStrikeしていないため、Cantorの体力は2のままです。

このルール順をプロンプトで見えるようにします。Tell → 対応防御またはFocusを一つ → Opening → Strikeを一度 → 次のフェーズまたは遭遇終了。複数の合図が同時に出たり追加Strikeが許されたりするなら、教材用契約と一致しません。

範囲を限定した最初の遭遇を依頼する

三体すべて、強化ツリー、追加武器から始めないでください。まずAsh Regentだけを依頼します。プレイヤーの行動、正確な体力、入力タイミングのモデル、不正または誤った行動への応答を指定します。派手な戦闘だけでなく、ルールを確認できる状態表示も求めます。

プロンプト1：ルールとイベント順に合意する

Turbine Vaultという一部屋の一人称ボスラッシュ遭遇を作る計画を立ててください。
ビジュアルを提案する前に、以下のルールを状態表にまとめ、矛盾があれば示してください。
不足する値を作らず、この遭遇がプレイ可能だと主張しないでください。

操作開始時はt=0、体力=4、Focus=1、ハート=3、ボス体力=2でPhase A。
プレイヤー行動はEvade、Guard、Parry、Strike、およびTell中に対応防御の代わりとしてFocusを1消費すること。
Focusの上限は2、下限は0。

Ash RegentのPhase Aはハンマーを頭上に上げる予告で、Evadeが正解。
Phase Bは床の噴出口が火の噴射前に光り、Guardが正解。
誤った防御はハートをちょうど1減らし、同じ合図を繰り返す。
Tell中にFocusを1消費すると攻撃を無効化し、Openingへ移る。

正しい防御もダメージを防ぎOpeningを作る。
Opening中、ボスは攻撃せず、プレイヤーは一度Strikeできる。
Strikeはボス体力をちょうど1減らし、Openingを消費する。
体力1でPhase Bを表示、0でボスを倒し、合図を消してVictoryを表示。
Tell中のStrikeなど不正行動は状態を変えない。

現在のボス体力、プレイヤーのハート、Focus、名前付きのフェーズ合図、Tell/Opening状態を読みやすく表示する。
Restartを用意し、遭遇をボス体力2、ハート3、Focus 1に戻す。
アリーナは小さく歩きやすくする。攻撃、体力、資源、二体目のボスを追加しない。

見た目を追加する前に、操作割り当てと状態遷移のチェックリストを返してください。
要求した挙動のうち表現できないものは黙って変更せず明記してください。

拡張前に、返答された操作と状態順を契約と比べます。反応を受け付ける前に予告が出るか、失敗時に合図が繰り返されハートを一つ失うか、正しいStrike一回でボス体力がちょうど一つ減るか。結果でこれらの状態を確認できない場合、遭遇を増やす前にプロンプトまたは確認計画を修正します。

最初のループを確認してから連戦を拡張する

ボスを追加すると、リセットされる値と持ち越される値という二種類目の状態が生まれます。Bellvaultでは各戦闘がハート3で始まり、Focusは戦闘間で持ち越されます。ボス1または2を倒すと一度だけFocusを1得ます。上限は2です。ボス3は追加報酬なしでランを終了します。

最初の遭遇を実際に確認した後で、別の拡張プロンプトからTide CantorとPrism Wardenを追加できます。ビルドがまだなければ、これは計画のままです。確認したとも、架空の状態を製品の主張に流用したとも報告しないでください。

確認済みの一体ボス遭遇に、以下の正確な表からTide CantorとPrism Wardenを追加してください。
既存の行動名、Tell/Openingの順、ダメージルール、Restart動作は変えないでください。

Tide Cantor：Phase A—三つの音叉が並んで明るい弾を一発放つ。Parry。
Phase B—水の刃を引き、広い横なぎを予告する。Evade。
Prism Warden：Phase A—プリズムレンズに光が集まり持続ビームを予告する。Guard。
Phase B—ビームが二つ目のレンズでプレイヤーへ反射するのが見える。Parry。

各ボスは体力2、二つのフェーズを持つ。誤った防御でハートを1失い、同じ合図を繰り返す。
正しい防御またはTell中のFocus1消費でOpeningを一つ作る。そこでStrikeを一度行うと体力を1減らしてOpeningを消費する。
新しいボスはハート3で始まりFocusを持ち越す。ボス1と2の撃破で、それぞれ一度だけFocusを1獲得し、上限は2。
ボス3は報酬を与えず、ランをVictoryで終了する。各引き継ぎ時に古い合図とOpeningを消す。

ボス撃破、引き継ぎ、Restart、最終勝利の状態遷移表を返してください。
ボス、攻撃、報酬、資源リセットを追加しないでください。ルール間に矛盾があれば変更前に指摘してください。

この連戦は四つの予測可能な段階から成ります。開始時にFocusを確認し、二つのフェーズを解決し、一度だけ報酬を得てから、ハートを戻し古い合図を消します。引き継ぎチェックリストで確認するのはこれです。別のボスモデルが表示されるだけでは不十分です。

固定した行動列で状態変化を確認する

ルールが正しいかどうかと、戦闘が公平に感じるかを別々にテストします。まず期待値を設定した短く再現可能な行動列を使います。以下は将来のビルド向けに計画した確認項目で、観察済みの結果ではありません。

手計算した行動列でラン全体の状態を確認できます。ボス1はハート3、Focus1で開始。Evade、Strike、次にGuard、StrikeでRegentを倒し、Focusは2になってボス2がハート3で始まります。Focusを1消費してTide Cantor AをOpeningにしStrike、次にBでEvade、Strikeします。一度だけの報酬後にFocusは2へ戻ります。Prism Wardenでは一度誤った行動を取り、その後Guard/Strike、Parry/Strike。提案された最終状態はハート2、Focus2でVictoryです。この計算は架空ルールだけに従っています。

実際のビルドを確認するときは、開始状態、正確な行動、見えた応答、結果値を記録します。結果が異なれば、複数のボスルールを同時に調整せず、最初に失敗した遷移を特定してください。

不明瞭な挙動を一度に一つずつ修正する

確認に失敗しても、原因が自動的に分かるわけではありません。ルールの不一致と、読みづらい合図、理解されない操作、予告を隠すカメラを分けます。プロンプトを変える前にプレイヤーが何を見て、何を選び、何を期待したか記録します。

たとえば将来のプレイヤーが反射ビームの合図をGuardだと誤認したと報告した場合、制作者は合図のシルエットだけを変更し、同じ行動列を再実行できます。これは仮定上の観察への仮定上の対応であり、現在の設計でプレイヤーが混乱した証拠でも、変更が理解を改善した証拠でもありません。

ビルド版、開始値、行動列、期待遷移、観察した遷移、提案する変更一つを小さな記録に残します。ビルドや実際の観察がない場合、行を「計画した確認」と記し、観察結果欄は空欄のままにします。

最初の焦点を絞った試行にボスアリーナメーカーを使う

SEELEの現在のBoss Arenaページは、アリーナ一つ、ボス一体、読みやすい攻撃ループから始めることを推奨しています。プレイヤーの技、ボスのパターン、戦闘の終了条件を指定し、範囲を広げる前にタイミング、カメラ、フィードバック、操作を確認する流れを説明しています。Ash Regentのプロンプトを試す出発点として適切ですが、Bellvaultの連戦やFocus引き継ぎが記述どおり動作する証拠ではありません。

遭遇契約、意図した操作割り当て、受け入れ質問を一つ持ち込みます。焦点を絞った初回結果があれば、実際の出力で合図、対応、Opening、ダメージ、終了状態を確認してください。一般的なゲームメーカーの流れでも結果と表示コストを確認するよう案内されています。これはプロンプト主導の最初の遭遇を支えますが、特定の戦闘ロジックや複数ボスのセーブシステムは記述していません。

目標を小さく保ちます。合図一つと対応一つが読みやすい遭遇を作るか確認します。次のボスを加えるのは、最初のループを見て確認し、残りのランルールを明記してからです。

次の反復ではボス一体と確認一つを選ぶ

役立つボスラッシュプロンプトはロスターではなく状態契約から始まります。合図、対応、失敗時の結果、Opening、ダメージ、遷移、リセットを指定し、遭遇一つを依頼してから値を確認します。Bellvaultの一連の例は架空の紙上設計です。プロンプトの各ブロックや最終状態は実際のプロトタイプに使う材料であり、ビルドが存在する主張ではありません。

最初のビルドではボスのフェーズを一つ選び、狭い問いを設定します。プレイヤーは対応を選ぶ前に予告を見ているか。ボスアリーナメーカーから始め、焦点を絞った遭遇と表示コストを確認し、ボスを増やす前に状態を検証しましょう。

最初のプロンプトにボスは何体含めるべきですか？

ボス一体と攻撃ループ一つから始めます。合図が出るか、意図した対応が機能するか、遭遇が明確な結果に達するかを最初に確認できます。最初のループを確認してからボスを増やしましょう。ロスターが長くなると引き継ぎや資源が加わり、基本ルールの欠陥を特定しにくくなります。

すべてのボス攻撃に異なる合図を使うべきですか？

プレイヤーが期待する対応を見分けられる合図にしますが、新しさだけを目的に変えないでください。Bellvaultの例では各フェーズに名前付き合図一つと対応防御一つがあります。合図の説明は作者が設計したもので、読みやすさのテスト基準ではありません。実際のプレイヤーが合図と行動を認識できるか確認してください。

戦闘間で資源をどう引き継ぐべきですか？

リセットか持ち越しか、一度だけ付与か、上限があるかを書きます。BellvaultではFocusを持ち越し、1から開始し、上限2。ボス1と2の後だけ1チャージを付与します。これは教材用の数値で、推奨バランスではありません。各ボス後の引き継ぎを確認し、報酬が二度発生しないか試してください。

AIゲームメーカーは複数ボスの連戦全体を保証できますか？

特定の連戦が生成またはテストされた証拠としてプロンプトを扱わないでください。SEELEのBoss Arenaページはボス一体に焦点を絞った開始範囲を説明しています。提案した連戦ルールを計画に使い、生成結果を信頼する前に実際の合図、操作、資源引き継ぎ、敗北、勝利を確認してください。