DEV Community: Ren Coreball Developer

Separating the song clock from hit judgement in a browser rhythm game

Ren Coreball Developer — Wed, 23 Sep 2026 09:14:27 +0000

A note can look perfectly aligned with a target and still feel wrong when the player presses a key. In a browser rhythm-game prototype, it helps to keep three responsibilities separate: song time, note drawing, and input judgement.

This small example focuses on the judgement layer. It is not an implementation walkthrough of an existing FNF engine.

Give every note a timestamp

Represent a note as a lane and a time in milliseconds, for example { lane: "left", timeMs: 2000 }. Its position on screen is a view of that timestamp, rather than the source of truth for scoring.

For a Web Audio prototype, derive song time from the audio context and the time at which playback was scheduled:

const songMs = (audioContext.currentTime - scheduledStartTime) * 1000;

MDN documents currentTime as an audio timeline in seconds. It is separate from wall-clock time and stops advancing when the context is suspended. This makes the timeline useful, but it does not automatically compensate for speaker, display, or input latency.

Make judgement a pure function

function judge(songMs, noteMs, offsetMs = 0) {
  const deltaMs = songMs - noteMs - offsetMs;
  const distance = Math.abs(deltaMs);
  const grade = distance <= 45 ? "tight"
    : distance <= 90 ? "good"
    : distance <= 140 ? "loose" : "outside";
  return { grade, deltaMs };
}

The windows are illustrative design choices, not recommended universal values or the scoring rules of Friday Night Funkin'. Negative deltaMs means early; positive means late. With this convention, a positive offset corrects a consistently late measurement.

Keep that sign convention visible in the calibration UI. A slider named “offset” without explaining what positive values do is difficult to debug.

Test boundaries before tuning the feel

The useful cases are not just exact hits:

Song time	Note time	Offset	Result
1000	1000	0	tight, delta 0
1045	1000	0	tight, delta +45
1046	1000	0	good, delta +46
910	1000	0	good, delta −90
1141	1000	0	outside, delta +141
1080	1000	80	tight, delta 0

Nine Node assertions were run for this example, covering exact hits, both sides of the 45/90/140 boundaries, an early hit, and the offset convention. These are arithmetic checks, not a device-latency benchmark.

Keep selection and rendering separate

On input, choose an eligible unconsumed note in the pressed lane, apply judgement once, and mark a hit as consumed. Ignore keyboard auto-repeat for tap notes. An early press outside the window should not automatically consume a future note. A separate update can expire notes that are already too late.

Render note positions from remaining song time on each frame. If a frame is delayed, the next render can catch up without redefining when the note was meant to be hit. Pause/resume, held notes, overlapping hit windows, and device calibration need their own explicit rules.

For a concrete reference to the genre, FnfYa's Spanish FNF catalogue groups browser-playable Friday Night Funkin' games and mods. The timing example above is independent of those games; it makes no claim about their internal engines.

Disclosure: This article was prepared with AI assistance on behalf of the linked FnfYa project. The example was checked with the stated assertions; no original-game authorship or performance benchmark is claimed.

Preventing Double Merges in a Fruit-Drop Physics Game

Ren Coreball Developer — Sun, 20 Sep 2026 03:25:16 +0000

A fruit-drop game has a deceptively small rule: when two matching fruits touch, replace them with the next fruit. The awkward part is that a physics engine reports contacts, while the game needs to perform a single state transition.

Consider three equal fruits, A, B, and C. One collision event can contain both (A, B) and (B, C). If each pair independently schedules a replacement, B can be consumed twice. Checking whether the bodies exist only when the callback begins does not solve that problem when removal is deferred.

This note comes from the merge handler in a project I work on, SuikaGo (スイカゲーム). The snippets below are abbreviated illustrations of the implementation, not a complete physics integration.

Separate the rule from the engine

The merge rule is a pure function. It receives two tier numbers and returns one of three outcomes:

type Outcome =
  | { kind: "evolve"; resultTier: number; score: number }
  | { kind: "clear"; score: number }
  | null;

Different tiers return null. Matching ordinary tiers advance by exactly one. Two final-tier watermelons clear instead of requesting a nonexistent larger fruit. The score comes from the tier being consumed.

That last distinction matters: “there is no next tier” does not necessarily mean “nothing happens.” A nullable next-tier index cannot fully represent both evolution and clearing. An explicit outcome keeps the collision handler from having to rediscover that rule.

Reserve both bodies before scheduling work

The handler keeps a set of body IDs currently involved in a merge. The important ordering is:

if (reserved.has(a.id) || reserved.has(b.id)) return;
const outcome = getMergeOutcome(tier(a), tier(b));
if (!outcome) return;

reserved.add(a.id);
reserved.add(b.id);
scheduleMerge(a, b, outcome);

The reservations happen synchronously, before the deferred callback. If (A, B) is accepted first, (B, C) sees B's reservation and cannot also claim it. A later collision involving a newly created fruit can produce a legitimate chain reaction.

This enforces at most one pending merge per body. It does not make the whole simulation deterministic: when several valid contacts compete, the chosen pair can still depend on the engine's pair order. Deterministic replay would require additional work, including a stable contact-selection policy and control of simulation timing.

Revalidate when the deferred callback runs

The implementation defers world mutation with requestAnimationFrame. By that point, either source body may have disappeared—for example, because the board was reset.

Before removing anything, it collects the IDs still in the physics world and checks that both sources remain present. If either is absent, it releases the reservations and exits. Otherwise it removes the two sources and, for an evolve outcome, creates one replacement. A clear outcome creates none.

The replacement starts at the midpoint of the original positions. Its initial velocity averages the source velocities with a small upward adjustment; angular velocity is averaged as well. Those are game-feel choices, not a claim of physically accurate conservation. The merge rule remains independent of them.

There is also a lifecycle detail worth keeping explicit: requestAnimationFrame is a browser scheduling mechanism, not a physics transaction API. A game with background simulation, replay, or several physics substeps per frame may need a dedicated mutation queue flushed at a controlled engine boundary instead.

Test rules separately from scheduling

I reran the project's seven merge-logic tests for this note. They cover same-tier evolution, mismatched tiers, the final-tier boundary, terminal clearing, and score lookup. All seven passed.

Those tests validate the pure rules. They do not prove that concurrent collision callbacks are correct. For the integration layer, the useful cases are different:

A callback containing (A, B) and (B, C) must not consume B twice.
A repeated pair while its first operation is pending must not queue another merge.
Resetting the board before the callback runs must not recreate the old fruits.
Clearing the final tier must remove both sources without adding a replacement.

Keeping these two test layers separate makes failures easier to diagnose. A wrong tier or score belongs to the rule function; a duplicate body or stale callback belongs to the scheduling and world-mutation layer.

The transferable idea is to model resource ownership before deferring a state change. Physics contacts, drag-and-drop events, and animation callbacks can all describe overlapping work. Reserving the inputs first prevents several callbacks from believing they own the same object.

Disclosure: this article discusses a project I work on. AI assisted with drafting; implementation details were checked against the project code and the seven rule tests were run for this article.

Three UX Checks for a Click-to-Launch Browser Game

Ren Coreball Developer — Sat, 01 Aug 2026 10:44:32 +0000

Minimal browser games are useful UX tests because every delay and unclear state is easy to notice. I recently used Coreball as a small example: the player launches pins into a rotating core and must avoid every existing pin.

Here are three checks I use for this kind of click-to-launch interaction.

1. Make the rotation readable

The player should be able to judge speed and open space before clicking. Clean contrast and stable motion matter more than decorative effects.

2. Keep input latency out of the way

A mouse click or screen tap should trigger the launch immediately. Even a small perceived delay can make a correct decision feel like the player's fault.

3. Explain failure visually

When a collision ends the attempt, the contact point needs to be obvious. Clear failure feedback helps players adjust their next timing instead of assuming that the rule is inconsistent.

The same simple loop also works well across desktop and mobile because it does not depend on a keyboard layout or complex gestures. Difficulty can grow through rotation changes and tighter gaps while the control stays the same.

You can try Coreball in the browser. I am mainly looking for feedback on whether the timing and collision feedback feel equally predictable with a mouse and a touchscreen.