How Do You Write Entry Conditions, Exit Outcomes, and Cooldowns for Event Cards?
Use five traveling-market event cards to separate entry checks, outcome resolution, and reappearance, then walk through the turns to check priority, first-time rewards, and expiration at closing time.
Define Three Things First: When It Can Start, How It Ends, and When It Can Return
Small events at a traveling market can follow three rules: all entry conditions must be met before an event becomes a candidate, each execution resolves only once, and cooldowns are counted in turns after exit. Apply a shared priority order and expiration process to prevent requests from competing for attention or repeating unexpectedly.
The “Lantern Trail Market” below is a fictional teaching example, not a real user case, a tested outcome, or a product feature. Ahe travels with the market and can repair a lantern, check a scale, return a claim ticket, drink tea, and encounter closing time. All turn counts and rewards are design choices for this example.
This article addresses how independent events fit into an itinerary: which comes first when several are available, how long to wait before asking again after a refusal, and whether requests remain valid after the market leaves. This adds a layer of event scheduling beyond converting a script into node data.
Use One Card Template and Define Cooldowns Consistently
Fill in the following fields for each card. Conditions should have a yes-or-no answer; “when the mood is right” is not enough.
| Field | What to Enter |
|---|---|
| ID and content | A unique ID and a one-sentence description of what happens |
| Entry conditions | Location, time window, prerequisite facts, and incomplete-status flags |
| Priority position | Its position when multiple events are candidates |
| Exits and state updates | What completion, refusal, and failure each change, and how rewards are recorded |
| Cooldown and reappearance | Which exit starts the timer and when eligibility is checked again |
| Expiration conditions | When the request is withdrawn and what state remains |
This example starts on turn 1. Exiting an event, changing areas, or explicitly waiting each consumes one turn; reading text does not advance time. At the start of each turn, process expiration first, then check entry conditions and cooldowns. At most one card can be entered per turn. When no event is entered, the player can change areas or wait.
A cooldown of two means two full turns must pass after exit: exit on turn 1, no entry on turns 2 and 3, and check again on turn 4. Finishing a cooldown only restores candidate eligibility; it does not guarantee an appearance. Cards permanently closed after success no longer need a cooldown.
Five Event Cards: Make Every Exit Concrete Enough to Record
All five cards require that no other event is in progress; cards A through D also require the current turn to be earlier than turn 8. Events end within the turn in which they occur and never remain pending across turns. Closed cards are no longer candidates, and expiration processing does not overwrite resolved outcomes.
Card A | The Crooked Lantern Stand at the East Entrance
Entry: at the east entrance, with the lantern stand still unrepaired. Content: the stallholder asks Ahe to steady the base. Completion: record “lantern stand repaired” and close the card. Refusal: the stand remains broken; cooldown two. Failure: the tool slips and the stand remains broken; cooldown one. Failure means only that the player chose to help but did not finish. If it is still unrepaired at closing time, record “taken away on the wagon for repair”; do not grant a successful outcome retroactively.
Card B | The Dispute over the Scale Pan at the Western Covered Stalls
Entry: at the western covered stalls, with the dispute unresolved and both parties still present. Completion: both parties agree to weigh the goods again; record “dispute resolved” and close the card. Refusal or failed mediation: the dispute remains unchanged; cooldown two. If either party leaves, or if the dispute remains unresolved at closing time, record “not mediated” and close the card. Any similar dispute later becomes a separate event and does not inherit this card’s completion state.
Card C | The Claim Ticket at the East Entrance
Entry: at the east entrance, holding the claim ticket, with its owner still present and the ticket not yet returned. Completion: remove the ticket, record “returned,” and close the card. Refusal: keep the ticket; cooldown two. There is no action requiring a success-or-failure check, so no separate failure exit is needed. If the owner leaves or closing time arrives before the ticket is returned, keep the ticket, record “to be returned at the next stop,” and close the card for this market session. The continuation at the next stop references that fact.
Card D | A Cup of Hot Tea in the Courtyard
Entry: in the courtyard while the tea stall is open. First completion: record “had tea this session,” give one serving of tea snacks, record “tea snacks claimed this session,” and apply cooldown two. Later completions show only a brief exchange, retain those facts, add no more snacks, and still apply cooldown two. None of this card’s exits changes the relationship score. Refusal: add neither the tea-drinking fact nor the reward-claim fact, give no snacks, and apply cooldown one. The card expires when the tea stall closes or the market packs up. This is an everyday event card that may reappear.
Card E | The Closing Bell
Entry: turn 8 has arrived and the market has not yet packed up; location does not matter. The only exits are “leave with the market” and “stay where you are.” Record the respective destination, then record “this market session has ended.” This card has no cooldown and does not reappear. At the start of turn 8, cards A through D close according to their individual closing-time clauses; E resolves the departure choice. Both exits end the market segment, and staying behind does not allow the player to keep accepting requests.
Check Four Turns: Refusal Is Not Completion
The shared priority order is E, A, C, B, D. Filter for eligible candidates, then take the first card. Unselected cards do not join a queue; eligibility is recalculated next turn. Priority is a choice about how to structure the experience, not a measure of inherent importance.
Suppose Ahe is at the east entrance on turn 1, the lantern stand is unrepaired, Ahe holds the ticket, and its owner is still there. A and C are both candidates, so A is entered first. After refusing to steady the lantern stand, record exit turn 1 and earliest reappearance turn 4. Do not record “A completed.”
On turn 2, Ahe is still at the east entrance. A is on cooldown, so C is entered. Returning the ticket removes it and closes C. On turn 3, A is still on cooldown and C is closed. B and D fail their location conditions, while E fails its entry condition because turn 8 has not yet arrived. With no candidates, Ahe chooses to wait.
On turn 4, repairing the lantern closes A. Passing the east entrance later will not trigger repairs to the same lantern again. When time reaches turn 8, D is excluded even if its cooldown has just ended: it expires at closing time and no longer meets the “earlier than turn 8” condition. E is entered and ends this session. This is not a priority contest between E and D; the competition between A and C on turn 1 demonstrates priority selection.
Record four columns in the walkthrough: current turn, candidate cards, selected card, and facts after exit. Recording only dialogue misses the difference between refusal and completion.
Three Common Scheduling Problems, Each Fixed by One Rule
A card keeps popping back up. If, after an exit on turn 1, a cooldown of two is mistakenly interpreted as allowing reappearance on turn 2, the player will be asked again immediately after refusing. Writing down the “earliest reappearance turn” directly makes this easier to check.
An expired request still executes. C may once have been a candidate, but its ticket owner could leave after another event executes. This example does not retain an old candidate queue. If you switch to a queue, recheck entry conditions immediately before entering an event: a ticket cannot be handed to someone who has already left.
The same exit resolves twice. Create a separate execution record on every entry and mark it as resolved once an exit is confirmed. Reviewing it only reads the result; it does not remove the ticket or add snacks again. A new execution of D must still check this session’s reward-claim flag: the execution record prevents duplicate resolution within one execution, while the claim flag prevents repeat rewards across executions.
Another limitation is prolonged blocking: if higher-priority cards repeatedly become eligible again, lower-priority cards may never get a turn. Give essential scenes an exclusive time window or make them main-story nodes. Increasing their chance of selection cannot guarantee that players reach them.
When to Change Approaches and How to Check Before Handoff
Fixed priority suits a market where you want to control pacing. To create more chance encounters, draw from the eligible candidates. If freely exploring stalls is the focus, let players open a request list themselves and use cooldowns to control when requests can be accepted again. Both approaches must retain entry and expiration rules and define their selection rules separately.
Before handoff, manually walk through three paths: refuse everything, complete as much as possible, and enter turn 8 with unfinished requests. Check exit state updates, permanent closure, and closing-time cleanup. Then complete D twice: the first completion adds one serving of snacks and leaves a claim flag; the second adds no snacks, and neither changes the relationship score. Reviewing any resolved exit must not change inventory either.
This card template suits small events that can conclude within the current story segment. Tracking across stops, long-term character competition, and mysteries revealed in a fixed sequence also require stage-specific states. Walk through the boundary conditions of these five cards before adding more, so you can distinguish new story content from scheduling rules that have not yet been defined.
