All posts

Every Episode Ended the Same Way

The episode end guard was computing the right answer and throwing it away

5 min read
episode-system
pacing
game-systems
design

I watched a video about D&D session pacing that broke cliffhangers into five types: combat setup, dramatic dialogue, genre tease, villain cutscene, and thematic callback. Five endings a DM can reach for when the clock runs down. My first instinct was to build a system that picked from them at the end of each episode.

That instinct was wrong, and the reason it was wrong taught me something about the episode end system I had already built.

Cliffhangers Need an Enforced Gap

A cliffhanger works because of the week between sessions. The DM ends the night as enemies emerge from the treeline, and for seven days the players sit with that image. The anticipation across the gap is the entire payoff.

In async solo play there is no enforced gap. The player finishes an episode, sees the end screen, and can start the next episode from the hub in under a minute. A combat-setup ending does not build dread under those conditions. It withholds a fight the player is ready to play. The cliffhanger becomes a speed bump.

The same problem applies to any suspense-shaped ending. An NPC closing with an open question holds for a week at a tabletop. In the game, the player answers it with one click. The question is a prompt to keep playing, not a hook to think about between sessions.

Closure Works Either Way

A thematic callback works whether the player stops for three days or three seconds. It is a satisfying place to pause and a clean place to resume. A villain cutaway works the same way. The player received new information. If they sit with it, good. If they click through immediately, the information still landed.

The episode end dialog already had two slots: a DM closing narration and a "Next time on Chronicles of Terros" teaser. The narration slot is structurally retrospective. The teaser slot is structurally forward. Those two slots already split the closure and forward axes. The design question was how much weight each slot should carry, not whether to flip either one into a different mode.

The Guard That Discards Its Own Answer

The episode end system has a guard that checks whether the current moment is safe to cut. It looks for three conditions: the player just rested, combat just ended, or the ship is approaching a destination. If none of those are true, it defers the episode end and checks again next turn. After eight consecutive deferrals with no clean break found, it forces the end regardless.

That guard knew exactly why it approved each ending. A rest is a settle-point. Post-combat is an aftermath. Destination approach is the player mid-motion toward something. The forced cut after eight deferrals means the system gave up looking for a clean break and the player got walled into an ending mid-stride. Each of those moments has a different emotional shape.

The guard returned yes or no. The reason was computed internally, used for the branching logic, and then discarded on the way out. By the time the closing narration and teaser were generated, the system had no record of which condition had fired. Every episode got the same generic prompt.

The Forced Cut Problem

The default closing narration prompt asked for something "reflective, slightly ominous." That works after a rest. It works after combat winds down. It does not work after a forced cut.

A forced cut means the system spent eight turns looking for a clean break and failed. The player was mid-conversation, mid-exploration, mid-something that had no natural stopping point. The scene had not settled. When the closing narration then described peaceful reflection and quiet resolution, it was lying about what the player had just experienced. The one ending that most needed careful handling was the one most damaged by the generic treatment.

Five Endings, Five Treatments

The fix was carrying the guard's reason through to the generation step. The guard now returns which condition matched alongside whether to cut. That label flows through to the prompts that generate the closing narration and teaser.

After a rest, the closing narration carries the weight. Reflective stillness, the fire dying to embers, earned quiet. The teaser stays light because the player chose to stop here.

After combat, the narration sits in the aftermath silence. What the fight cost, not who won. The teaser can nod to consequences without re-narrating the action.

When approaching a destination, the narration stays lighter because the player is already mid-motion. The teaser carries the forward weight instead, riding the trajectory the player built.

After a forced cut, the narration acknowledges the unresolved motion honestly. No pretending the scene settled. And the teaser makes no forward promise, because there is no earned thread to pull forward from a rough landing. A forward-looking teaser after a forced cut would point straight at the system's own bad timing and call it a cliffhanger.

What It Cost

One return value widened from a yes-or-no to a labeled result. One field stored when the guard approves a break. Two prompt paths that branch on which label arrived. The guard was already computing the answer. The generation system was already producing closings and teasers. The entire problem was a single point in the pipeline where a rich decision was collapsed to a binary and the reasoning was thrown away.

The episode end system could already find the right moments to cut. It could already generate closings and teasers. It just could not tell the difference between a campfire and a crash landing.