Resetting a value does not revoke permission to write to it. That distinction is the heart of this bug.

Imagine a target game where one press earns one point and a separate bonus arrives after a delay. To expose the problem, request the bonus, restart before it arrives, then wait. The score should remain zero; one fresh target press should make it one. This is a constructed example, not an observation about a Rosebud game.

For an AI-assisted project, keep that sequence fixed while changing the implementation. Rosebud's first-game tutorial describes previewing, making one change, and playing again. Here the requested change is precise: a result from the previous round must not alter the current round.

The request was valid when it started

Label each round with an identity. A bonus request remembers the identity it started with. After waiting, it compares that identity with the current round. A mismatch means its result has expired, even if the result itself is correct.

AI-generated editorial illustration: an old run's late result stops at an ownership check; the new run stays at zero. Conceptual diagram, not product UI or a runtime trace.

This complete, original experiment isolates that comparison. Run it as an .mjs file in Node, or paste it into a fresh JavaScript console that supports top-level await. finishBonus(5) resolves the promise manually, so no timer or network request is needed.

let currentRun = 0, score = 0;
const restart = () => {
  currentRun += 1;
  score = 0;
};
let finishBonus;
const bonus = new Promise(
  resolve => {
    finishBonus = resolve;
  }
);
async function requestBonus() {
  const owner = currentRun;
  const points = await bonus;
  if (owner !== currentRun)
    return;
  score += points;
}
const pending = requestBonus();
restart();
finishBonus(5);
await pending;
console.log(score); // 0

For a comparison, rerun the whole experiment in a fresh scope with the restart(); line removed. It prints 5: the same result is accepted when its round still exists. Removing the identity check instead makes the restarted version print 5, reproducing the unwanted write.

The check must follow the wait. Before await, the old round is still current. After it, that may no longer be true. A real handler also needs this protection before displaying a late error or clearing a loading state in finally; an obsolete failure can overwrite the new round just as an obsolete success can.

Cancellation and permission solve different problems

The experiment discards a result. It does not stop work. JavaScript promises have no general cancellation protocol; cancellation, when available, belongs to the underlying operation.

A game therefore needs both resource cleanup and a rule for late arrivals. When retiring a run:

• Mark it inactive before releasing its resources. Also invalidate it when the round ends without a restart.

• Cancel its recorded timeout handles with clearTimeout().

• Remove its gameplay listeners. Listeners registered with an AbortSignal can be removed together by aborting that signal, as MDN's event-listener reference describes.

• Give the next run fresh state and a new identity.

Keep page-level controls, such as Restart itself, outside that per-round setup. Shared assets can survive too. The boundary follows ownership: repeatedly installing a new anonymous target handler can make one press score twice, while repeatedly destroying a shared texture cache wastes resources.

The small experiment covers only late-result ownership; it contains no input handling, timer cleanup or rendering. In an actual game, repeat the bonus/restart sequence and then try one ordinary interaction. Zero before the press and one afterward check two separate failure modes: the old result was rejected, and the new round received the input only once.

This is one place to look when a chest snaps shut just as it opens. With zero-based indices, frame 5 starts at 500 ms and remains current until 600 ms. Selecting it and finishing it are different events.

AI-generated illustration of six hypothetical frames, each lasting 100 ms. The enlarged detail shows frame 5's interval from 500 to 600 ms. Not a Rosebud export or gameplay capture.

A small standalone JavaScript sampler can return both the current picture and the completion state:

function sampleClip(
  elapsedMs,
  frameCount = 6,
  frameMs = 100
) {
  const duration =
    frameCount * frameMs;
  return {
    frame: Math.min(
      frameCount - 1,
      Math.floor(
        elapsedMs / frameMs
      )
    ),
    done: elapsedMs >= duration
  };
}

Its inputs must be finite: nonnegative elapsed milliseconds, a positive integer frame count and a positive frame duration with a finite total. After completion, the clamp keeps the index on the last frame. Replacing it with modulo would wrap the clip back to frame zero—a useful loop for a torch, but an unwanted reset for an opened chest.

The clock and the imported sheet must agree

The equal-duration assumption matters when you replace the artwork. Rosebud's sprite-animation export guide describes PNG artwork with JSON for frame rectangles, durations, pivot and playback behavior. Read those durations before connecting the export to a player. For unequal durations, choose the first cumulative frame-end time greater than elapsed time; completion occurs at their sum. Averaging away a long anticipation or recovery frame changes the animation.

The selected index chooses a source rectangle. A regular strip can use it with drawImage; a packed atlas needs its recorded rectangles and offsets. The sampler above is not an importer for either format.

Elapsed time also needs to survive late callbacks. Use the requestAnimationFrame timestamp, not a callback count. At 350 ms, the sample is frame 3, already 50 ms into its interval. Keep that remainder. Repeatedly throwing it away stretches the clip.

A jump from 400 to 650 ms can skip the last picture altogether. The sampler will report completion correctly, but it cannot make a display show pictures between callbacks. If a pose must be seen, explicitly hold it through a rendered frame rather than treating timeline arithmetic as proof that it appeared.

For pause-on-hide behavior, stop advancing the clip and reset the timing origin on resume; the Page Visibility API supplies that signal. Replay should reset elapsed time inside the existing animation loop, not create another callback chain.

A completed clip can stay visible

At 600 ms, a chest can remain open, a particle effect can stop drawing, or a character can switch to its idle clip. That choice belongs to the drawing or animation-state layer. It does not change the duration.

The done flag remains true on subsequent samples. A reward or transition should fire only when the previous sample was unfinished and the new one is finished. Reset that completion latch on a new playback, while keeping gameplay state separate: replaying a chest animation must not make collected loot available again. For damage at a particular time, detect crossing that time rather than waiting to draw a specific frame.

These boundary samples distinguish a short final hold from a bad drawing. Run them after the function above:

for (const time of [
  499, 500, 599, 600, 900
]) {
  const state =
    sampleClip(time);
  console.log(
    time,
    state.frame,
    state.done
  );
}
// 499 → 4, false;
// 500 → 5, false;
// 599 → 5, false
// 600 → 5, true;
// 900 → 5, true