ランごとに変化するバッグから始める
バッグ構築ゲームは、ドローによって今後の確率が変わると面白くなります。小さなプール、各ドロー後の選択、プレイヤーが読み取れる結果から始めましょう。Skyline Relayでは、プレイヤーは安全なBearing 4個と危険なCinder 2個から引き、毎回ドローを止めるか選べます。ランの間にアップグレードを一つ購入できます。このオリジナルの紙上シミュレーションは制作もプレイテストもされていません。
表紙は一つの局面を描いています。Cinderの後にBearingを引き、ルートの2マスが進み、Heatの2目盛りのうち1つが点灯しています。Bearingが3個、Cinderが1個残っています。2コインの配達報酬を確保して止めるか、残りのCinderを引く確率が4分の1で荷物を失うリスクを取って続けるかを選びます。

この選択が設計のエンジンです。プレイヤーが止めた理由を説明できるよう、最初の版は小さく保ちます。
バッグ、ドロー、リセットのルールを定義する
この記事ではバッグ構築を、内容が時間とともに変化する共通プールから再利用可能なトークンを引く仕組みとします。デッキ構築ゲームでは通常、カードのデッキを整え、そこから手札を引きます。手札、捨て札、シャッフルを管理する場合もあります。呼び名だけでルールが決まるわけではないため、確率を計算する前に、物理またはデジタルの対象物と戻すタイミングを明記してください。Schmidt Spieleが公開するThe Quacks of Quedlinburgの公式ルールのルールは、個人バッグから材料チップを引き、途中で止められる具体例です。爆発のルールや材料の効果はそのゲーム固有であり、すべてのバッグ構築ゲームに当てはまるわけではありません。
AIゲームメーカーに場面を作らせる前に、簡潔なルールカードを使いましょう。以下の例では各トークンに役割を一つずつ与え、状態遷移を明確にします。
| ルール項目 | Skyline Relayの教材用ルール | プレイヤーに必要な理由 |
|---|---|---|
| 初期プール | Bearing 4個とCinder 2個、合計6個。 | 個数が既知なのでリスクを計算できる。 |
| ドロー順 | 1回にトークンを一つずつ、戻さずに引く。1ランで最大3個。 | ランをリセットする前に同じトークンは重複しない。 |
| プレイヤーの選択 | 各ドロー後、まだ3個引いていなければ停止するか続けて引く。 | リスクが自動タイマーではなく判断になる。 |
| トークンの効果 | Bearingはルートを1マス進め、Heatを増やさない。Cinderは1マス進め、Heatを1増やす。Steady Coreは2マス進め、Heatを増やさない。 | 引くたびに進捗またはリスクが目に見えて変わる。 |
| 失敗と報酬 | 停止前にCinderを2個とも引くと荷物を失い、報酬はゼロ。それ以外は安全に配達し、到達したルート1マスにつき1コインを得る。 | リスクと報酬を同じルールで解決する。 |
| リセットと強化 | ランの後、引いたトークンをすべてバッグに戻す。その後3コインを払い、次のラン用にCoreを1個追加できる。 | 戻すタイミングと購入タイミングが次回の確率を決める。 |
早めに停止しても、ランが終わるまでは引いたトークンをバッグに戻しません。市場での購入はトークンを戻した後にのみ行います。このタイミングなら、ルート途中でアップグレードが確率を変えることはなく、次のランで数えられるプールが明確になります。
停止するか引くかのリスクを見えるようにする
プレイヤーが選ぶ瞬間にリスクを読み取れるようにします。初期バッグではCinder 2個だけが失敗トークンです。早く止めず必ずちょうど3回引く場合、Cinderを両方引く確率は可能な3個組20通り中4通り、つまり20%です。残り1個はBearing 4個のどれかです。これは定義した架空バッグから3回引き切る場合の確率であり、停止戦略すべてに対する失敗率ではありません。
Coreを1個購入すると、バッグには安全トークン5個とCinder 2個が入ります。同じく戻さずにちょうど3回引く条件では、35通りの3個組のうち5通りにCinderが両方含まれ、確率は5/35、約14.3%です。安全なトークンを加えたため割合が下がります。しかし、アップグレードがバランス調整済みとは証明されません。Coreは引いたときに運び手を2マス進め、早く停止するプレイヤーは別のリスク経路を取るためです。
| バッグの状態 | トークン総数 | 3回ドローの組合せ | Cinderが2個とも含まれる組合せ | 3回引き切る場合の確率 |
|---|---|---|---|---|
| 初期:Bearing 4個 + Cinder 2個 | 6 | C(6,3) = 20 | 4 | 4/20 = 20% |
| Coreを1個追加:Bearing 4個 + Cinder 2個 + Core 1個 | 7 | C(7,3) = 35 | 5 | 5/35 ≈ 14.3% |
これらは手計算した教材用の値であり、プレイテスト統計やバランス調整結果ではありません。この比較が答えるのは、プレイヤーが3回とも引くと決めた場合、最初の3回でCinderを両方引く頻度だけです。期待報酬、1回引いた後に止まる価値、最も強い購入は計算していません。自分のルールをテストするときは、それらを別々に記録しましょう。
購入一つで次のバッグを変える
市場での選択は画面上の数字を大きくするだけではなく、後の判断を変えるべきです。この例では、運び手が安全に3マス進む基準ランを終えて3コインを獲得し、トークン6個をすべて戻してから、そのコインでSteady Coreを追加します。Coreはバッグに加わり、Bearingを置き換えたりCinderを取り除いたりしません。次のバッグは7個になります。

変更案
| 変わること | 次の紙上チェックでの問い | 安全トークンを一つ追加 |
|---|---|---|
| バッグが増え、Cinderの割合が下がる。 | 追加トークンでドロー判断に違いが生まれるか。 | Cinderを一つ取り除く |
| バッグが減り、失敗トークン数も減る。 | ルートに意味のある緊張感が残るか。 | 安全トークンの進捗を増やす |
| Cinderの数は変えずに、引けばより多く進める。 | 報酬が増えて停止する魅力が下がるか。 | 最初の市場で3つすべてを変更しないでください。一度に一つ変えると、結果の変化を特定のルール変更に結びつけやすくなります。 |
確認できる小さな試作を依頼する
確認できる小さな試作を依頼する
SEELEの現在のAI Game Makerページは、ゲーム案を平易な英語で説明し、2Dまたは3Dのプレイ可能な結果を確認し、Workspaceで反復する一般的なプロンプト主導の流れを説明しています。また、選択中のモデル、プラン、表示される生成コストの確認を促しています。このページはバッグ構築用のテンプレートを説明しておらず、生成プロジェクトがこの例のトークンロジックを実装するとも保証しません。最初の試作は場面や見える判断を検討するために使い、実際の結果を確認するか、未確認の仕組みは文書仕様として残しましょう。
プレイヤーの行動、状態、終了条件、確認項目をまとめてツールに伝えます。このプロンプトは開始用ブリーフであり、生成やテストの証拠ではありません。
峡谷を舞台にした、短時間で遊べるオリジナルの配達ゲームを一つ作る。プレイヤーは目に見える個人バッグからトークンを一つずつ、戻さずに引く。各ドロー後に停止でき、引いたトークンはラン終了後にのみ戻す。バッグの構成、ルート進捗、Heat、残りドロー回数、停止または継続の明確な操作を表示する。安全なBearing 4個と危険なCinder 2個から開始する。各ドローでルートを1マス進める。BearingはHeatを増やさず、Cinderは1増やす。停止前にCinderを2個とも引いた場合は荷物を失い、報酬はゼロ。それ以外は安全に配達し、到達マスごとに1コインを得る。1ランは最大3回のドローに制限する。すべてのトークンを戻した後、3コインでSteady Coreを一つ追加できるようにする。Coreは2マス進み、Heatを増やさない。リセットを含める。マルチプレイ、キャンペーン、隠れたトークン効果、その他の強化は追加しない。バッグ、引いたトークン、ルート、Heat、報酬を見えるようにする。
次に、アートだけで判断せず、具体的な受け入れ条件と結果を比較します。
- 初期プールがBearing 4個とCinder 2個で、ドローしたトークンがリセットまでバッグ外にあることを確認する。
- Bearing、次にCinderを引き、進捗が2マス、Heatが1になるか確認する。停止して荷物の報酬が2コインであることを確認する。
- 停止前にCinderを2個とも引き、失敗が一度だけ処理され報酬がゼロになることを確認する。
- 安全に3マス進むランを終え、3コインの市場行動より前にトークンが戻ることを確認する。
- Coreを購入し、バッグが6個から7個に増えること、Coreを引くとHeatなしで2マス進むことを確認する。
- ランを再実行し、リセットで進捗とHeatが消え、トークンの重複や欠落がないことを確認する。
現在の結果でトークンの状態を表示できない、または戻すタイミングを確認できない場合、その不足を記録し、次のプロンプトを確認可能な判断に絞ります。確率やバランスの主張は、証拠を得るまで製品説明に含めないでください。
拡張前に閉じた例を再現する
最初の確認に使えるのは、Core購入後の安全な1系列です。Bearing 4個、Cinder 2個、Core 1個で開始します。Bearingを3個、戻さずに引き、上限で停止します。Bearing 1個、Cinder 2個、Core 1個が未ドローで残ります。Heatは0、運び手は3マス進んで荷物を配達し、3コインを得ます。この手計算の手順は記述済みルールに従います。起こりうる結果の一つであって、予測でも測定されたゲーム結果でもありません。

小さな紙上リプレイ表を使い、ルールの正しさとゲームバランスを区別します。算術確認ではドロー順を固定し、プレイヤーがどの程度止まるか、失敗するかという別の問いを調べる段階で順番を変えます。
| 確認項目 | 入力 | 期待するルール結果 | 異なる場合に見直す点 |
|---|---|---|---|
| リスクトークン1個の後に停止 | Cinder、停止。 | 1マス、Heat 1、安全に配達、1コイン。 | 安全なランをいつ確定するか明確にする。 |
| 表紙の状態を完了する | Cinder、Bearing、停止。 | 2マス、Heat 1、安全に配達、2コイン。 | 各ドロー後に停止操作が可能か確認する。 |
| 失敗ルールを発生させる | 停止前にCinderを2個とも引く。 | 荷物を失い、報酬はゼロ。 | しきい値と失敗フィードバックを同時に表示する。 |
| アップグレード後のリセットを確認 | 安全に3マス進む。トークンを戻してCoreを購入。 | 3コインを使い、バッグが6個から7個に増える。 | ランの精算、返却、市場フェーズを分ける。 |
| 結果画像の手順を再現 | 購入後:Bearing、Bearing、Bearing、停止。 | 3マス、Heat 0、Bearing 1個 + Cinder 2個 + Coreが残り、3コイン。 | システムを増やす前に所持品または報酬表示を修正する。 |
固定した各手順が記述どおり解決できてから、バッグや報酬、停止する動機を比較します。一度に一つだけ問いましょう。プレイヤーはリスクを理解するか、購入が次のランを変えるか、報酬によって早く止まる価値が生まれるか。紙上の例をプレイテストと偽らず、試作の次の一手を明確にできます。
よくある質問
バッグ構築ゲームはデッキ構築ゲームとどう違いますか?
このガイドでのバッグ構築は、内容を変えられるプールから再利用可能なトークンを引くことです。デッキ構築では通常、カードのデッキを整えて手札を引きます。ゲームごとに異なるので、確率を計算する前に対象物がトークンかカードか、いつ戻るか、プールをどう変えるかを明記してください。
引いたトークンはドローごとにバッグへ戻すべきですか?
目的とする判断に合わせて返却時点を選びます。この例ではラン全体を通して戻さずに引き、ラン終了後にすべて戻します。各ドロー後に戻せば同じトークンを繰り返し引く可能性があり、ここで使った組合せ計算は当てはまりません。
最初の試作ではトークンの種類をいくつ使うべきですか?
中心となる選択を見せるために必要な種類だけ使います。ここではBearingが安全な進捗、Cinderがリスクとなる2種類です。リスクを下げる強化と安全なドローの価値を上げる強化のどちらがよいかなど、特定の設計上の問いを確かめるときだけ種類を増やします。
AIゲームメーカーはバッグ構築ゲームを自動でバランス調整できますか?
そうだと決めつけないでください。プロンプト型のゲームメーカーは場面や最初に遊べる方向性の検討に役立つかもしれませんが、この例のトークン数、戻さずに引くルール、停止時の挙動、確率は現在の結果で確認が必要です。該当する状態遷移を確認するまで、生成されたロジックは未検証として扱います。
強化を増やす前に何を確認すべきですか?
トークン数、戻さないドロー、停止タイミング、失敗、報酬、返却時点、リセットが記述したルールに一致するか確認します。その後、強化を一つ変えて次のバッグを比べます。正しさの確認と、プレイヤーが続けるか止めるかを考える面白い理由を持つかというバランス判断を分けてください。
検証できる最小のループを作る
見えるバッグ、ドロー一回、リスク状態一つ、停止の選択、明確な報酬、アップグレード一つから始めましょう。元のトークン数とリセット時点を明示し、範囲を広げる前に状態変化を一つずつ確認します。Skyline Relayの数値は設計演習です。テスト結果の主張ではなく、自分のゲームで何を確認するか計画するために使ってください。
最初に遊べる方向性を試したい場合は、無料AIゲームメーカーを利用してください。バッグ、プレイヤーの次の選択、確認したい状態を説明し、Workspaceで現在のモデルとコストを確認してから、生成されたルールを確認しましょう。


