Building Velodrome: A Real-Time Multiplayer Typing Race Game

I built a full-stack typing game with live multiplayer, ghost racer replays, and per-key analytics. This post covers how I solved the hard parts.

Live demo | GitHub

The Idea

Typing games like TypeRacer are fun, but I wanted to add something different. Three things mattered to me:

1. Ghost racer - your best run replays as an opponent in future races


2. Per-key analytics - figure out which specific characters trip you up


3. Real-time multiplayer - race friends live

The ghost racer was the hardest part. How do you actually record and replay a typing performance?

The Ghost Racer

Most typing games just track one number: how many characters you typed. But replaying a race means knowing when each keystroke happened. If I only store the final text, I lose all the timing info.

My solution was to record every keystroke with a timestamp:

// In useGame hook, during the race:

keylogRef.current.push({ 

  t: Date.now() - startRef.current,  // milliseconds elapsed

  len: value.length                   // cumulative characters typed

})

After the race ends, the array looks like:

[

  { t: 0, len: 1 },      // first char at 0ms

  { t: 50, len: 2 },     // second char at 50ms

  { t: 75, len: 3 },     // third char at 75ms

]

Then during a new race, every 500ms I check where the ghost should be at that elapsed time. I use binary search to find the closest keystroke:

// In the game loop while racing:

const elapsed = Date.now() - startRef.current

const ms = elapsed



// Find the keystroke that happened right before this time

let idx = ghost.keylog.findIndex(k => k.t > ms)

if (idx === -1) idx = ghost.keylog.length



// The character count at that point

const ghostLen = idx > 0 ? ghost.keylog[idx - 1].len : 0

const ghostProgress = (ghostLen / passageLength) * 100



setGhostProgress(ghostProgress)

This is O(n) per tick but the array is usually less than 5000 elements, so it's instant. No second game simulation needed, no manual interpolation, and it handles pauses and backspaces automatically.

The ghost gets saved to localStorage only if it's a personal best:

if (newWpm > existingGhost.wpm) {

  profile.ghost = { 

    wpm: newWpm, 

    keylog: keylogRef.current,

    at: Date.now() 

  }

  localStorage.setItem('velodrome.profile.v1', JSON.stringify(profile))

}

Next time you play, your ghost is there waiting. Beat it and it updates.

Per-Key Analytics

Overall accuracy is useless. You could be 98% accurate and still struggle with one specific key. You need to know exactly which characters slow you down.

I track which character caused each error while typing:

// In handleInput, when a new character is added:

if (value[i] !== passage[i]) {

  errorsRef.current += 1



  // Track which character we expected to type was wrong

  const expected = passage[i] === ' ' ? 'space' : passage[i]

  troubleRef.current[expected] = (troubleRef.current[expected] ?? 0) + 1

}

After 20 races, the data might look like:

{

  'e': 8,      // you mistyped 'e' 8 times

  'r': 5,

  's': 4,

  'space': 12  // spaces give you trouble

}

This matters because instead of seeing "98% accuracy" you see "I mess up spaces and the letter e". You can drill those specific keys.

Multiplayer with Socket.io

I had a bug where your own car wouldn't move during multiplayer races, but the opponent's car would move fine.

I was storing all racer data (you and opponents) in one state array:

const [racers, setRacers] = useState([])



// Problem: every time the players list updated, it reset progress to 0

useEffect(() => {

  setRacers(players.map(p => ({ progress: 0, wpm: 0, ... })))

}, [players])

The server only broadcasts opponent progress to other clients. Your own progress never comes back to you. So your car had nothing updating it.

The fix was to stop storing your car in state and just compute it every render from your live typing:

// Instead of storing racers in state:

const racers = players.map(p => {

  const isYou = p.id === socket?.id

  const oppData = oppProgress[p.id]  // only opponents stored in state



  return {

    id: p.id,

    progress: isYou ? progress : (oppData?.progress ?? 0),

    wpm: isYou ? wpm : (oppData?.wpm ?? 0),

    isYou,

  }

})

Now your car always reflects your live progress variable. Opponents update when the server broadcasts. No resets, no stale data.

It's a simple pattern but took debugging to find. The lesson: don't store derived data in state if it updates frequently.

Tech Decisions

Why Canvas for the race track? I could have used CSS progress bars. Canvas was definitely overkill, but it made the cars, dashed lanes, and checkered finish line look custom rather than templated. Recruiters notice that you used Canvas more than they notice CSS bars. It was 150 lines of Canvas code versus 20 lines of CSS. Worth it for a portfolio project.

Why localStorage instead of a database? For a resume project, localStorage works offline, needs no backend infrastructure, and users don't care if their stats disappear. Plus it gives me a good answer in interviews: "Currently uses localStorage for local stats. Next I'd add user authentication to sync across devices."

Why Socket.io? Real-time games need low latency. Socket.io gives bidirectional communication, auto-reconnect on network drops, and falls back to polling if WebSocket fails. It's the standard for multiplayer games.

What Could Be Better

Extract the magic strings. Room codes, phase names, event names are scattered throughout. Should be constants. End-to-end tests would help too, testing the full flow from creating a room to finishing a race. Currently I emit race progress on every keystroke which could be expensive at scale. Tournament mode with multiple rounds would be cool. The whole thing is desktop-focused when mobile would open it up more.

What I Learned

State management is subtle. Storing derived data that updates frequently leads to sync bugs. It's better to compute it. Timestamps are way cheaper than high-frequency updates. Recording one timestamp per keystroke beats sending progress updates 60 times a second. localStorage gets a bad rap but it's perfect for single-player stats and ghosts. Real-time feedback matters. Users notice lag. The 500ms update interval for opponent cars is noticeable but acceptable. And recruit for the architecture, not the UI. The ghost racer algorithm, per-key error tracking, and state machine are the resume-worthy parts.

How to Run It

Frontend on Vercel: https://velodrome-mu.vercel.app

Or locally:

cd frontend && npm install && npm run dev

cd ../backend && npm install && npm run dev

Links

• Live: https://velodrome-mu.vercel.app
  


• GitHub: https://github.com/DakshSaijwal/velodrome
  


• Frontend: React 18, Vite, Tailwind, Socket.io, Canvas


• Backend: Node.js, Express, Socket.io, Render


• Deployment: Vercel (frontend), Render (backend)