Start with a bag that changes each run
A bag-building game gets interesting when draws change future odds. Begin with a small pool, a choice after each draw, and a consequence players can read. In Skyline Relay, a courier draws from four safe Bearings and two risky Cinders, may stop after any draw, and can buy one upgrade between runs. This original paper simulation has not been built or playtested.
The cover shows one possible moment: after Cinder then Bearing, two route spaces are covered and one of two Heat segments is lit. Three Bearings and one Cinder remain. Stop to keep a two-coin delivery, or draw again with a 1-in-4 chance of pulling the last Cinder and losing the parcel.
That choice is the design's engine. Keep the first version small enough that a player can explain why they stopped.
Define the bag, draw, and reset rules
For this article, bag-building means the player draws reusable tokens from a shared pool whose composition can change over time. A deck-building game usually asks the player to shape a deck of cards and then draw cards into a hand; the player may manage that hand, a discard pile, and a reshuffle. The label alone does not determine every game's rules, so write down the physical or digital objects and when they return before you calculate odds. Schmidt Spiele's published rules for The Quacks of Quedlinburg are one concrete bag-draw example: players pull ingredient chips from personal bags and may stop drawing. Its specific explosion rule and ingredient effects belong to that game, not to every bag-building design.
Use a compact rule card before asking an AI game maker to sketch a scene. The example below gives every token one job and closes the state transitions.
| Rule element | Skyline Relay teaching rule | Why the player needs it |
|---|---|---|
| Starting pool | Four Bearings and two Cinders; six tokens total. | Known counts make the risk calculable. |
| Draw order | Draw one token at a time without replacement, up to three tokens per run. | A token cannot appear twice before the run resets. |
| Player choice | After each draw, stop or draw again while fewer than three tokens have been drawn. | The risk is a decision, not an automatic timer. |
| Token effect | A Bearing advances one route space and adds no Heat. A Cinder advances one and adds one Heat. A Steady Core advances two spaces and adds no Heat. | Every draw visibly changes progress or risk. |
| Failure and payout | If both Cinders are drawn before the player stops, the parcel is lost and the run pays zero. Otherwise, the courier delivers safely and earns one coin per route space reached. | The same rule resolves both risk and reward. |
| Reset and upgrade | Return every drawn token to the bag after the run. Then the player may spend three coins to add one Core to the bag for the next run. | Return timing and purchase timing define the next odds. |
Drawn tokens stay out of the bag until the run ends, even if the player stops early. The market action happens only after returning them. That timing prevents an upgrade from changing the odds halfway through a route and gives the next run a clean, countable pool.
Make the stop-or-draw risk visible
Risk should be legible at the moment the player chooses. In the baseline bag, the two Cinders are the only failure tokens. If the player commits to exactly three draws without stopping early, the chance of seeing both Cinders is 4 out of 20 possible three-token sets, or 20 percent: choose one of the four Bearings as the third token. This is a fixed-commitment probability for the defined fictional bag, not the chance of failure under every stop strategy.
After the player buys one Core, the bag contains five safe tokens and two Cinders. Under the same exact-three-draw, without-replacement assumption, five of the 35 possible three-token sets contain both Cinders, so the chance is 5/35, or about 14.3 percent. The lower fraction comes from adding a safe token. It does not prove the upgrade is balanced: the Core also moves the courier two spaces when drawn, and a player who stops early follows a different risk path.
| Bag state | Total tokens | Three-draw sets | Sets with both Cinders | Chance under a three-draw commitment |
|---|---|---|---|---|
| Baseline: 4 Bearings + 2 Cinders | 6 | C(6,3) = 20 | 4 | 4/20 = 20% |
| After adding 1 Core: 4 Bearings + 2 Cinders + 1 Core | 7 | C(7,3) = 35 | 5 | 5/35 ≈ 14.3% |
These are hand-calculated teaching values, not playtest statistics or a balance result. The comparison answers one narrow question: how often both Cinders appear in the first three draws if the player commits to all three. It does not calculate expected reward, the value of stopping after one draw, or which purchase is strongest. Track those questions separately when you test your own rules.
Make one purchase change tomorrow's bag
A market choice should alter a later decision, not merely add a larger number to the screen. In this example, the courier completes a safe three-space baseline run, earns three coins, returns all six tokens, and spends those coins to add a Steady Core. The Core joins the pool; it does not replace a Bearing or remove a Cinder. The next bag has seven tokens.
Separate an upgrade's effect on safety from its effect on progress. Adding a safe token dilutes the Cinders in the next draw pool; giving a token extra movement changes how far a draw advances the route; removing a Cinder directly lowers the number of risk tokens. These are different design levers. Compare one at a time and write down both the pool change and the player-facing tradeoff.
| Possible edit | What changes | Question for the next paper check |
|---|---|---|
| Add one safe token | The bag grows and the proportion of Cinders falls. | Does the added token change the draw decision enough to notice? |
| Remove one Cinder | The bag shrinks and the number of failure tokens falls. | Does the route still create meaningful pressure? |
| Give a safe token more progress | The draw can reach more spaces without changing Cinder count. | Does the larger payout make stopping feel less attractive? |
Do not stack all three changes into the first market. One edit at a time makes it easier to trace a changed outcome back to a changed rule.
Ask for a small prototype you can inspect
SEELE's current AI Game Maker page describes a general prompt-led workflow: describe an idea in plain English, review a playable 2D or 3D result, and iterate in Workspace. It also asks creators to check the selected model, plan, and displayed generation cost. The page does not document a bag-building template or guarantee that a generated project will implement this example's token logic. Use a first pass to explore the scene and visible decisions, then verify the actual result or keep unverified mechanics in a written specification.
Give the tool the player action, state, ending, and checks together. This prompt is a starting brief, not evidence that any output has been generated or tested:
Build one original short-run courier game in a canyon. The player draws tokens from a visible personal bag one at a time without replacement, may stop after each draw, and returns drawn tokens only after the run. Show the bag composition, route progress, Heat, remaining draw limit, and a clear stop-or-draw action. Start with four safe Bearings and two risky Cinders. Each draw advances one route space; a Bearing adds no Heat and a Cinder adds one. If both Cinders are drawn before the player stops, lose the parcel and pay zero. Otherwise deliver safely and pay one coin per route space reached. Limit each run to three draws. After returning all tokens, allow a three-coin purchase that adds one Steady Core; the Core advances two spaces and adds no Heat. Include a reset. Do not add multiplayer, a campaign, hidden token effects, or other upgrades. Keep the bag, drawn tokens, route, Heat, and payout visible.Then check the result against concrete acceptance points rather than judging only its art:
- Confirm the initial pool is exactly four Bearings and two Cinders, and that a draw removes one token until reset.
- Draw a Bearing, then a Cinder; check that progress is two spaces and Heat is one. Stop and confirm the parcel pays two coins.
- Draw both Cinders before stopping; confirm the failure resolves once and pays zero.
- Finish a safe three-space run; confirm it returns tokens before the three-coin market action.
- Buy the Core; confirm the bag changes from six to seven and a Core draw advances two spaces without Heat.
- Repeat a run to verify the reset clears progress and Heat without duplicating or deleting tokens.
If the current result does not expose a token state or cannot confirm replacement behavior, record that gap and narrow the next prompt to the visible decision you can inspect. Keep probability and balance claims out of the product description until you have evidence.
Replay a closed example before expanding
A useful first check is a single safe sequence after the Core purchase. Start with four Bearings, two Cinders, and one Core. Draw three Bearings without replacement and stop at the limit. One Bearing, both Cinders, and the Core remain undrawn; Heat stays at zero; the courier advances three spaces, delivers the parcel, and receives three coins. This hand-resolved line follows the written rules. It is one possible result, not a forecast or measured game outcome.
Use a small paper replay table to distinguish rule correctness from game balance. Fix the draw order for arithmetic checks; use varied orders only when you are ready to ask a separate question about how often players stop or fail.
| Check | Input | Expected rule result | What to revise if it differs |
|---|---|---|---|
| Stop after one risk token | Cinder; stop. | One space, Heat 1, safe delivery, one coin. | Clarify when the player banks a safe run. |
| Complete the cover state | Cinder, Bearing; stop. | Two spaces, Heat 1, safe delivery, two coins. | Make the stop action available after each draw. |
| Trigger the failure rule | Both Cinders before stopping. | Parcel lost; zero payout. | Show the threshold and failure feedback together. |
| Check the upgrade reset | Safe three-space run; return tokens; buy Core. | Three coins spent; bag grows from six to seven. | Separate run resolution, return, and market phases. |
| Replay the outcome image | After purchase: Bearing, Bearing, Bearing; stop. | Three spaces, Heat 0, one Bearing + two Cinders + Core left, three coins. | Correct the inventory or reward display before adding systems. |
Only after every fixed sequence resolves as written should you compare alternative bags, rewards, or stop incentives. Ask one question at a time: does the player understand the risk, does the purchase change the next run, or does the reward make an early stop feel worthwhile? That gives a prototype a clear next step without pretending a paper example is a playtest.
Frequently asked questions
How is a bag-building game different from a deck-building game?
In this guide, bag-building means drawing reusable tokens from a pool whose contents can change. Deck-building usually means shaping a deck of cards and drawing cards into a hand. Individual games vary, so state whether your objects are tokens or cards, when they return, and how a player changes the pool before calculating odds.
Should drawn tokens return to the bag after each draw?
Choose the return point to match the decision you want. This example draws without replacement for the whole run and returns every token only after the run ends. If tokens returned after each draw, the same token could appear repeatedly and the combination calculations here would no longer apply.
How many token types should a first prototype use?
Use only the token types needed to reveal the main choice. Two types are enough here: Bearings make safe progress and Cinders add risk. Add a type only when it tests a specific design question, such as whether an upgrade should reduce risk or make a safe draw more valuable.
Can an AI game maker balance a bag-building game automatically?
Do not assume so. A prompt-led game maker may help you explore a scene or a first playable direction, but this example's token counts, no-replacement rule, stop behavior, and probabilities still need checking in the current result. Treat any generated logic as unverified until you inspect and test the relevant state transitions.
What should I check before adding more upgrades?
Verify that token counts, no-replacement draws, stop timing, failure, payout, return timing, and reset all match the written rules. Then make one upgrade change and compare the next bag. Separate that correctness check from a balance judgment about whether players have an interesting reason to stop or continue.
Build the smallest loop you can verify
Start with a visible bag, one draw, one risk state, one stop choice, a clear payout, and one upgrade. Keep the original token counts and reset timing explicit, then inspect each state change before widening the market. The Skyline Relay numbers are a design exercise; use them to plan what to verify in your own game, not as a claim about a tested result.
When you are ready to explore a first playable direction, try the Free AI game maker. Describe the bag, the player's next choice, and the state you need to inspect; check the current model and cost in Workspace, then verify the generated rules before building further.
