60Hz or 144Hz: Give Your AI-Built Browser Game a Fair Clock

Illustrative photo by Carl Raw on Unsplash, not a screenshot of an AI-generated game.

A paddle moving four pixels per animation callback travels 240 pixels in one second at 60 callbacks per second. At 144 callbacks, it travels 576.

That is a 2.4× change in movement speed—not a benchmark, just arithmetic. It is also a useful first review question for a browser game built with an AI coding assistant: does the game measure time, or count pictures?

Small arcade prototypes are a friendly place to learn this distinction. AI can help produce the first implementation, while the creator decides what a fair, readable player experience should be. Getting something on screen opens the door to that work; it does not finish it.

Start with a measurable rule

For a simple movement system, ask for speed in pixels per second rather than pixels per frame. Keep that rule separate enough to test:

const advance = (x, speed, dtSeconds) => x + speed * dtSeconds;

function simulate(hz, seconds = 1) {
  let x = 0;
  for (let i = 0; i < hz * seconds; i++) {
    x = advance(x, 240, 1 / hz);
  }
  return x;
}

for (const hz of [60, 144]) {
  console.assert(Math.abs(simulate(hz) - 240) < 1e-6);
}

This standalone JavaScript check describes the intended arithmetic. It is not a complete game loop, a collision test or evidence that a particular generated game works on every device.

The mechanism matters because MDN documents that requestAnimationFrame callbacks generally follow the display refresh rate. Its warning is explicit: calculate progress from the callback timestamp, or another suitable time source, rather than assuming every callback represents the same fixed interval.

In the actual loop, subtract the previous callback timestamp from the current one and convert milliseconds to seconds. Use that elapsed time to advance movement. Save the new timestamp for the next callback. Ask the assistant to explain where those units change; a clear explanation makes the generated code easier to inspect.

Give the prompt an acceptance condition

Here is a small specification to adapt, not a promise that one prompt will produce a finished game:

Build a single-player browser paddle prototype. Express movement speeds in pixels per second. Use elapsed time from requestAnimationFrame timestamps. Keep movement calculations separate from drawing. Include a test showing that one simulated second at 60 and 144 updates produces the same distance. Explain the pause and resume behavior. Do not add accounts, analytics, networking or external dependencies.

That scope makes the next conversation about behavior. If the paddle feels heavy, change acceleration or stopping behavior deliberately. If it moves too far, inspect units before asking for a wholesale rewrite.

Keep a working version before each revision. Change one mechanic, rerun the check and play it again. A small project is valuable because you can still understand what changed.

Decide what happens when the tab disappears

MDN also notes that animation callbacks pause in most background tabs. On return, a naive elapsed-time calculation can include a long interval.

For a local arcade prototype, explicitly pausing when the page is hidden is a reasonable design choice. Reset the previous timestamp when resuming so hidden time is not applied as one giant movement step.

That is a choice, not a universal fix. An idle game may intentionally account for time away; a networked game needs a different approach. A delta-time clamp also discards time, so it should not quietly become the game's clock policy. More demanding collision and physics systems often need fixed simulation steps or substeps as well.

Keep the human test

Equal travel distance does not guarantee equal feel. Input handling, collision behavior and rendering can still differ. Try the actual build on available devices, return from a background tab, and restart a round. Check that restarting does not create a second animation loop.

Then ask the question no timing assertion can answer: is moving the paddle enjoyable?

The useful opportunity in AI-assisted game creation is a shorter path to an inspectable experiment. The designer still owns pacing, difficulty and the decision to share it.

Which tiny mechanic would you give a measurable acceptance test before expanding your prototype?

Read the KRI ZEK guide to AI-assisted game creation.

Download Altered Brilliance: https://play.google.com/store/apps/details?id=tech.krizek.alteredbrilliance

Global website: https://global.krizek.tech

Pre-register for Arzenal Human Health: https://play.google.com/store/apps/details?id=tech.krizek.arzenal

Join The Power Of Gaming: https://discord.gg/sbYSPcCqJn