Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Client-side interpolation loop (requestAnimationFrame)

Open
  • Is something wrong?
#127 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
javascript, react, typescript
Domain
frontend, game-dev

Research direction

Start with ui/src/util/simulate.ts and the rAF loop in App.tsx, then read ui/src/util/playbackBuffer.ts to understand tick release and timing. Extend the existing simulation math for fractional steps and reconcile to server values on each released tick. Done means motion is smooth between ticks without accumulated drift; the issue names tests for simulation, buffering, reducer resync, and App rAF wiring.

Written by the indexing model from the issue text.

Description

enhancement priority: medium

Drive smooth motion from a requestAnimationFrame loop (extrapolating from simulate.ts) so animation stays fluid even when SSE frames arrive irregularly (e.g. behind a buffering proxy/tunnel) instead of relying on per-event CSS transitions.

Effort: M

Migrated from ENHANCEMENTS.md (§5 Polish, performance & accessibility).

Implementation notes

Priority: medium — Polish on top of an already-shipped rAF/jitter-buffer smoothing system (App.tsx + playbackBuffer.ts) — improves perceived fluidity for all spectators but doesn't fix a correctness/stability gap or unblock other work.

Purpose

Bot motion currently jumps by a whole tick's worth of movement the instant a buffered tick group is released, so even though App.tsx already paces release via requestAnimationFrame + PlaybackBuffer (ui/src/util/playbackBuffer.ts), position/rotation still steps discretely (~every NOMINAL_TICK_MS=100ms) rather than gliding every frame. Sub-tick extrapolation makes the arena visibly fluid at 60fps regardless of SSE/tick cadence, improving the core spectating experience with no server changes.

Implementation approach
  • ui/src/util/simulate.ts currently mutates full-tick deltas (position via speed, rotation via bodyOrientationVelocity, etc.) in one call from arenaReducer.ts's tick branch. Add a fractional-dt variant (or a scale/fraction param on the existing function) so the same movement/rotation formulas can be applied per-rAF-frame proportional to elapsed time within the current tick window, instead of only once per whole tick.
  • In App.tsx's existing rAF loop (~lines 279-311), after buffer.current.drain(...) releases a tick-group (authoritative resync via applyArenaEvent), extrapolate every intermediate frame forward using the fractional Simulate call, based on PlaybackBuffer's known tickMs/speedFactor — this is new logic layered on top of, not replacing, the existing jitter buffer.
  • Must snap back to server-authoritative values (bodyOrientationTarget, x/y from botTurn/botAccelerate events) on each real tick release so extrapolation error never accumulates/drifts — same reconciliation pattern already used for the discrete jump.
  • No bot-facing API or compiler.ts change; this is purely ui/ client rendering. Server util/simulation.ts math (speed/rotation formulas) must stay mirrored in the extended simulate.ts per the existing comment convention.
Key details to plan
  • No DB/service or REST/MCP contract changes.
  • No sandbox/security implications (client rendering only).
  • Determinism: extrapolation is visual-only and must not feed back into any state sent to the server; the seeded-PRNG server simulation remains sole source of truth, reconciled each tick.
  • Testing: extend ui/test/simulate.test.ts (fractional-step math), ui/test/playbackBuffer.test.ts/playbackClock.test.ts (frame pacing), ui/test/arenaReducer.test.ts (resync behavior), and ui/test/App.test.tsx for the rAF wiring.
  • Watch for interaction with bullet/path rendering (arenaBotPath.test.ts) which currently only records path vertices on discrete tick application.
  • Effort M is reasonable; risk is low-medium — mainly getting reconciliation/anti-drift right and avoiding double-counting motion already applied by PlaybackBuffer.
Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
8m
Merged PRs (30d)
8

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from LeeAdcock/robocodeJs.com

All issues in LeeAdcock/robocodeJs.com

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.