tekken8-browser

The idea

Fighting games are specified in frame data. Startup frames, active frames, recovery, hitbox positions — these are numbers, and they decide what actually happens in a match. Building the game off those numbers rather than off feel means the simulation is something you can reason about, which is the precondition for the netcode below.

Why rollback

Rollback-style netcode instead of delay-based. Rather than waiting for your opponent's input, each client simulates ahead on a prediction and rewinds when the real packet disagrees. It trades CPU for latency, which is the right way round for a fighting game. This is the intended design — it is not finished, and there is no working online match yet.

Zero dependencies

Canvas 2D and plain JavaScript, nothing from npm. For a real-time game that is deliberate: every dependency is latency, and the netcode is the part that has to be exactly right. Roughly 96% JavaScript, the rest CSS and HTML.

Honest status

This is the least finished thing in this list. The direction is sound and the reasoning is real, but there is a lot between here and a game you can sit down and play — locally or online.

What I learned

• Deterministic simulation is what would make rollback possible; without it you cannot rewind to a state you can trust.
• Frame data is a specification — once moves are numbers, a fighting game can be reasoned about instead of tuned by feel.

What it doesn't do yet

Listed deliberately — a project's limits are as useful to a reviewer as its features.

• Very early prototype. Assume it is not playable yet.
• The netcode is a design, not a working feature — no online match exists.
• No live build; the repository is the only place it exists.
• Single matchup and two characters at most.