DEV Community: Shreyash Tripathi

Building a real-time multiplayer drawing game with Socket.IO: rooms, timers, scoring (and the bugs I'd fix)

Shreyash Tripathi — Sat, 26 Sep 2026 08:38:51 +0000

SketchRace is a multiplayer drawing and guessing game: one player draws a secret word, everyone else races to guess it in the chat. A teammate and I built it; I worked on the game server, a Node.js + Express app with Socket.IO, and my teammate built the Next.js frontend.

This post walks through how the server works, with the real code, and ends with the bugs I'd fix if I built it again.

The whole game lives in memory

There's no database. One Node process keeps all game state in four plain objects, keyed by room id:

const rooms = {};          // players, owner, round, current drawer, current word
const points = {};         // points[roomId][playerName]
const correctGuessers = {};// who has already guessed this turn
const activeTimers = {};   // the running setInterval handles per room

const wordSelect = 7;  // seconds to pick a word
const wordGuess = 45;  // seconds to guess
const maxRounds = 3;
const hintTime = 20;   // reveal a hint when 20 s are left

For a game where a match lasts a few minutes and nobody needs history, that's enough, and it keeps every read and write instant.

Rooms

Each match has its own URL (/room/[roomId]). Joining puts the socket into a Socket.IO room and creates the room state the first time:

socket.on("join", ({ roomId, name }) => {
  socket.join(roomId);
  if (!rooms[roomId]) {
    rooms[roomId] = {
      users: [],
      ownerId: socket.id,
      gamestarted: false,
      currentDrawerIndex: 0,
      currentRound: 1,
      currentWord: "",
      hintRevealed: false,
    };
  }
  rooms[roomId].users.push({ id: socket.id, name });
  io.to(roomId).emit("user-list", { users: rooms[roomId].users, ownerId: rooms[roomId].ownerId });
});

When the last player disconnects, the room, its guessers and its timers are deleted, so nothing leaks between matches.

Live drawing: send strokes, not pictures

Sending the canvas as an image after every stroke would be slow and heavy. Instead each client sends tiny line segments, and the server relays them to everyone else in the room:

socket.on("drawing", ({ roomId, prevX, prevY, x, y, brushColor, brushSize }) => {
  socket.to(roomId).emit("drawing", { prevX, prevY, x, y, brushColor, brushSize });
});

socket.to(roomId) broadcasts to the room except the sender, who has already drawn the line locally. Each segment is a handful of numbers, so the other canvases keep up in real time.

The server owns the clock

If every browser ran its own timer, clocks would drift and players would see different time left. So the server runs the only clock and broadcasts a tick every second:

activeTimers[roomId].selectionTimer = setInterval(() => {
  timeLeft--;
  io.to(roomId).emit("word-selection-time", timeLeft);
  if (timeLeft === 0) {
    clearInterval(activeTimers[roomId].selectionTimer);
    wordGuessingTime(roomId);
  }
}, 1000);

A turn is: 7 seconds for the drawer to pick a word, then 45 seconds of guessing. After each turn the pen moves to the next player, and after everyone has drawn, the round counter goes up. After 3 rounds the server sends the final scores:

// proceedToNextTurn, simplified
room.currentDrawerIndex = (room.currentDrawerIndex + 1) % room.users.length;
if (room.currentDrawerIndex === 0) {
  room.currentRound++;
  if (room.currentRound > maxRounds) {
    io.to(roomId).emit("final-scores", points[roomId]);
    io.to(roomId).emit("game-ended");
    return;
  }
}
io.to(roomId).emit("clear-canvas");
wordSelectionTime(roomId);

Hints, sent only to guessers

When 20 seconds are left, the server reveals two random letters of the word. It sends the hint per player, skipping the drawer, using each socket's own id as a room:

room.users.forEach((user) => {
  if (user.id !== currentDrawer.id) {
    io.to(user.id).emit("word-hint", { hint: maskedWord });
  }
});

Scoring that rewards both sides

The scoring tries to be fair to guessers and the drawer:

Guesser: 10 points + a time bonus of up to 10, reduced by 20% if the hint was already shown.
Drawer: +5 for every correct guess, +10 more if everyone guesses it.
End of turn: the drawer also gets a bonus proportional to the share of players who got it.

If every guesser gets the word before time runs out, the server stops the timer and moves to the next turn after a 3-second pause.

What I'd fix if I built it again

Reading the code again with fresh eyes, four things stand out.

1. The time bonus is almost always 0. Time left is calculated from the timer's _idleTimeout, which is the interval (1000 ms), not the time remaining. So timeRemaining works out to about 1 second, and the "up to 10" bonus rounds to 0. The fix is to store when the turn ends and compute from that:

room.turnEndsAt = Date.now() + wordGuess * 1000;
// on a correct guess:
const timeRemaining = Math.max(0, (room.turnEndsAt - Date.now()) / 1000);

2. Every player receives the secret word. word-selected broadcasts word-to-guess to the whole room, so anyone with dev tools open can read it. The word should go only to the drawer, with guesses checked on the server.

3. The server trusts the client's correct-guess. A client can claim a correct guess without typing the word. With the word kept on the server (fix 2), the server can compare each chat message itself and award points only when it matches.

4. State in memory means one server. Everything lives in one Node process, so a restart ends every game, and it can't scale across instances. The Socket.IO Redis adapter plus Redis-backed room state would fix both.

None of these broke the game for friends playing together, but they're exactly the things that matter once strangers join.

What I learned

Make the server the single source of truth for time, turns and scores; clients just render what they're told.
Send the smallest possible update (a line segment, a tick) instead of whole states.
Never trust the client with anything that decides who wins.

You can play the game at sketchrace.vercel.app, and read the project case study on my portfolio at shreyashtripathi.in/projects/sketchrace. I'm a Frontend Developer and UI/UX Engineer in Noida. Questions about real-time games with Socket.IO are welcome in the comments.

tags:

cover_image: https://direct_url_to_image.jpg

Use a ratio of 100:42 for best results.

published_at: 2026-09-26 08:38 +0000

How I made my React portfolio 2x faster (Lighthouse 30 to 80) by prerendering a Vite app

Shreyash Tripathi — Sat, 26 Sep 2026 08:15:28 +0000

My portfolio is a Vite + React single-page app with a cyberpunk terminal theme: matrix rain, a live terminal, mini-games, easter eggs. It looked great on my laptop. Then I ran Lighthouse on mobile:

Metric (mobile)	Before
Performance	30
Largest Contentful Paint	8.1 s
Total Blocking Time	3,390 ms
Words a crawler sees without JavaScript	134

Two problems in one: the site was slow, and search engines and AI crawlers that don't run JavaScript saw an empty <div id="root"></div>. Here's what I changed, in order of impact.

1. Prerender the page at build time

A Vite SPA sends an empty shell, then builds the page in the browser. Instead, I render the React tree to HTML during the build and inject it into index.html, so the first byte already contains the real content.

First, an SSR entry that renders the same tree as the app, with StaticRouter instead of BrowserRouter:

// src/entry-server.tsx
import { renderToString } from "react-dom/server";
import { StaticRouter } from "react-router-dom";
import { AppShell, AppRoutes } from "./App";

export function render(url = "/"): string {
  return renderToString(
    <AppShell>
      <StaticRouter location={url}>
        <AppRoutes />
      </StaticRouter>
    </AppShell>
  );
}

Then a small Node script builds it and writes one HTML file per route:

// scripts/prerender.mjs (simplified)
const { render } = await import("../dist-ssr/entry-server.js");
const template = await readFile("dist/index.html", "utf8");

for (const page of pages) {
  const html = template.replace(
    '<div id="root"></div>',
    `<div id="root">${render(page.url)}</div>`
  );
  await writeFile(`dist/${page.file}`, html);
}

"build": "vite build && vite build --ssr src/entry-server.tsx --outDir dist-ssr && node scripts/prerender.mjs"

On the client, hydrate instead of rendering from scratch, so React reuses the HTML that's already painted:

// src/main.tsx
const container = document.getElementById("root")!;
if (container.hasChildNodes()) hydrateRoot(container, <App />);
else createRoot(container).render(<App />);

Result: crawlers now get 1,007 words instead of 134, and the text paints before any JavaScript runs.

Hydration gotchas I hit

Animated text started empty. My "decrypt" name effect initialised its state to "", so the prerendered <h1> was blank. Fix: start from the real text and scramble inside useEffect.
React error #419. renderToString can't wait for React.lazy, so a lazy chart inside <Suspense> made React bail out to client rendering. Fix: only render the lazy component after mount (see step 3), so server and client both render the fallback first.
Server and client trees must match exactly. Toasters and providers from App.tsx have to be in the SSR tree too, or hydration fails. I split App into a shared AppShell and AppRoutes used by both.

2. Load the fun stuff after the page is visible

The terminal, games, confetti and cursor effects were all in the main bundle and mounted immediately. Nobody needs a Snake game in the first second, so they now load when the browser is idle:

const InteractiveLayer = lazy(() => import("@/components/InteractiveLayer"));

const useIdleMount = () => {
  const [ready, setReady] = useState(false);
  useEffect(() => {
    const ric = window.requestIdleCallback;
    if (ric) {
      const id = ric(() => setReady(true), { timeout: 2500 });
      return () => window.cancelIdleCallback(id);
    }
    const t = setTimeout(() => setReady(true), 1200);
    return () => clearTimeout(t);
  }, []);
  return ready;
};

// in the page
{interactive && (
  <Suspense fallback={null}>
    <InteractiveLayer />
  </Suspense>
)}

I also removed an auto-playing boot screen that covered the page for ~3 seconds on every first visit. It was fun. It was also my LCP.

3. Load heavy libraries only near the viewport

The skills radar chart pulls in recharts (~354 KB). It now loads only when its section is within 400px of the screen:

const { ref, isVisible: near } = useReveal<HTMLDivElement>({
  threshold: 0,
  rootMargin: "400px 0px",
});

<div ref={ref}>
  {near ? (
    <Suspense fallback={<RadarSkeleton />}>
      <SkillsRadar />
    </Suspense>
  ) : (
    <RadarSkeleton />
  )}
</div>

4. Fix the image nobody noticed

My profile photo was a 1.5 MB PNG displayed at 288px. Converted to a 600×600 WebP it's 12 KB, and explicit width/height stop layout shift. The Open Graph image went from 275 KB to 89 KB.

5. Make the animations run on the GPU

Lighthouse's "non-composited animations" audit found two culprits:

A background grid animated with background-position, which repaints the whole screen every frame. I moved it to an oversized layer animated with transform:

'grid-pan': {
  '0%':   { transform: 'translate3d(0,0,0)' },
  '100%': { transform: 'translate3d(40px,40px,0)' },
},

A pulsing ring animated with box-shadow. It's now a pseudo-element that animates transform and opacity.

I also replaced three huge blur(130px) glow blobs with radial-gradient backgrounds, which look nearly identical but cost almost nothing to paint on phones.

6. Stop fonts from blocking the first paint

Three Google Font families were a render-blocking stylesheet. Now they're preloaded, applied from a small async script, and display=swap shows fallback text immediately.

The results

Metric (mobile)	Before	After
Performance	30	80
Largest Contentful Paint	8.1 s	3.4 s
Total Blocking Time	3,390 ms	240 ms
Cumulative Layout Shift	0.014	0
SEO / Accessibility / Best Practices	100 / 100 / 100	100 / 100 / 100
Words visible without JavaScript	134	1,007

(Lighthouse 12, mobile emulation, lab data.)

And the interactive terminal, games and easter eggs all still work — they just wait their turn.

Bonus: once pages are real HTML, SEO gets easy

Because every route is prerendered, I could give each project its own case-study page with its own title, description, canonical URL and JSON-LD structured data, all generated at build time from the same data file the UI uses. Add a sitemap and an llms.txt, and search engines and AI assistants can actually read the site.

You can see the result at shreyashtripathi.in — try the terminal (it loads after the page does). I'm a Frontend Developer and UI/UX Engineer in Noida; if you have questions about prerendering a Vite app, ask in the comments.