Skip to content

Netplay and Rollback

DoubleGate edited this page Jun 29, 2026 · 1 revision

Netplay and Rollback

References: docs/netplay-webrtc.md

RustyNES features a robust rollback netplay engine capable of deterministic multi-player experiences. The implementation leverages UDP for native environments and WebRTC for the browser, unified by a central snapshot/restore architecture.

Architecture

The netplay engine relies on the deterministic guarantee of the RustyNES core. Because the emulator is purely functional from frame-to-frame (given the same input), we can safely "roll back" to a previous state when a remote player's inputs arrive late.

Transport Layers

  • Native: A 3-4 player UDP mesh handles direct IP connections.
  • Web (WASM): WebRTC provides peer-to-peer data channels for browser clients.
  • Signaling: The project includes a deployable WebSocket relay (with a Caddy TLS proxy and coturn STUN/TURN) to negotiate WebRTC and UDP connections across NATs.

The Rollback System

  • The frontend holds an exact .rns snapshot of the core at the "confirmed" frame.
  • When an input arrives from the future (from the local player) but remote inputs are missing, the frontend predicts remote inputs (usually holding the last known state) and advances the core.
  • When the remote inputs finally arrive, the frontend:
    1. Restores the .rns snapshot from the confirmed frame.
    2. Re-simulates every frame up to the current frame instantly.
  • Because the core is extremely fast (≤ 2 ms/frame headless), it can re-simulate multiple frames within a single 16.6ms window, making rollback invisible to the user.

Run-Ahead

Run-ahead is built on the same snapshot/restore infrastructure used for netplay. By calculating the input latency of a specific game, the frontend can instantly run the emulator ahead by N frames to hide input lag, achieving better-than-original hardware responsiveness on modern displays.

Clone this wiki locally