DEV Community: Erol

How I Sync Real-Time Multiplayer Game State with Socket.io and Node.js

Erol — Wed, 01 Apr 2026 13:46:23 +0000

I built a multiplayer board game that runs in the browser. Keeping everyone's screen in sync was the hardest part by far.

Here's how I did it in TileLord.

Server owns everything

Never trust the client. The client sends what the player wants to do. The server checks if it's valid, updates the game, and tells everyone what happened.

// Client
socket.emit("placeTile", { x: 3, y: -1, rotation: 2 });

// Server
socket.on("placeTile", (data) => {
  const result = game.tryPlaceTile(player, data);
  if (result.valid) {
    io.to(roomId).emit("tilePlaced", result.state);
  } else {
    socket.emit("actionRejected", { reason: result.error });
  }
});

Even for a chill board game, people will try to mess with the payloads.

One room per game

Each game gets its own Socket.io room. Players join when they enter, and updates only go to that room.

socket.join(`game:${roomId}`);
io.to(`game:${roomId}`).emit("gameStateUpdate", sanitizedState);

Don't send everything though. If your game has hidden info (like a tile deck), strip that out before sending. Each player should only see what they're allowed to see.

Log every action

I store every move as an event instead of just keeping the current state:

actionLog.push({
  type: "TILE_PLACED",
  playerId,
  position: { x, y },
  rotation,
  timestamp: Date.now(),
});

You get a lot from this:

Replays - play the log forward
Reconnects - rebuild what a player missed while offline
Debugging - replay the exact sequence that caused a bug

The replay feature took about a day to build and players use it all the time. Worth it.

Disconnects are normal

People lose wifi. Their phone locks. Their laptop sleeps. Handle this from day one.

Turn timeouts: if someone doesn't move in time, a bot takes their turn so the game keeps going.

const turnTimer = setTimeout(() => {
  botPlayer.takeTurn(game);
  io.to(roomId).emit("botMove", game.getState());
}, TURN_TIMEOUT_MS);

Reconnects: when they come back, send them the current state.

socket.on("rejoinGame", ({ roomId, playerId }) => {
  const room = rooms.get(roomId);
  if (room) {
    socket.join(`game:${roomId}`);
    socket.emit("fullState", room.game.getStateForPlayer(playerId));
  }
});

Spectators are free

Once you have rooms, spectators just join without being able to send game actions. They get the same updates as players.

TL/DR

Server decides everything. Clients just ask.
Socket.io rooms, one per game.
Log every action. Replays and debugging come for free.
Handle disconnects early. They will happen constantly.

Get the sync layer right first. The rest falls into place after that.

I'm building TileLord at tilelord.com, a free Carcassonne alternative you can play with friends or bots online.

Why Letting Piscina Spin Up Workers Dynamically Broke My Game Server

Erol — Sun, 08 Feb 2026 08:07:30 +0000

First, the background: I'm running a Carcassonne alternative web game called TileLord. It also supports singleplayer mode, so you play against bots.

Bots are CPU-heavy, as they calculate heuristics for each possible move the bot could make, so an obvious way is to use threads on the server side, otherwise, your whole server will "lag" each time a bot is calculating a move (which happened when I first launched the game).

Worker threads and Piscina

As mentioned, it was obvious to add threads, and chatgpt suggested that I use Piscina. On Github, this is their repo description:

A fast, efficient Node.js Worker Thread Pool implementation

So it makes total sense to use it. Gpt suggested using this configuration, based on the VPS I was running my server on (8 cores):

const minThreads = 2;
const maxThreads = 6;

I rebooted the server, and.. the lag was gone! It worked perfectly. Until... my game got more users, and bots started getting slow-ish again. 3 seconds for a bot move instead of 1.5s.

I ran htop on my server, and saw random spikes of 800% cpu utilization (all 8 cores at 100%) for a few seconds, then back to 0%.

Which doesn't make any sense. There should be max 6 worker threads, and nothing else should consume much cpu, right?

Wrong! Spawning a worker in very heavy in Nodejs, as it needs to:

Create a new v8 isolate
Parse + execute your worker's js bundle
Run module initialization (require/import)
JIT-compile hot code paths
Maybe it triggers garbage collector activity

And these operations are parallelized internally, so when Piscina is spawning a new worker it can hit all cpu cores at once, causing the whole server to lag for a second or two.

After hard-coding both min/max threads to 6 (so the other 2 cpu cores are available to the server), my cpu consumption didn't go above 200% (I added the fix 4.2):

Lesson learned

Worker creation can be far more expensive than actual worker execution (bot move compute, which atm is 50-500ms). In such case, it might make sense to pre-allocate threads:)

Sometimes the bug isn’t in your algorithm, it’s in how your workers come into existence.

I also wrote about how How I Built a Free Online Carcassonne Game Alt You Can Play in the Browser

How I Built a Free Online Carcassonne Game Alt You Can Play in the Browser

Erol — Thu, 09 Oct 2025 10:44:41 +0000

I’ve always liked the board game Carcassonne — simple mechanics, but surprisingly deep strategy.
A while back I started tinkering with the idea of building something similar that could be played easily in a browser with friends. That side project eventually turned into TileLord — a small web game where you can play Carcassonne online free with bots or friends, no installs needed.

Why I wanted to build it

There aren't many online versions, it's either old Desktop apps or pay-up-front official apps. So I started building an open, Carcassonne game alternative that follows the same core rules

It’s not the official game (and isn’t affiliated with it), but it scratches the same strategic itch.

Under the hood

Frontend: React + PixiJS for tile rendering and UI
Backend: Node.js + Socket.io for multiplayer state sync
Hosting: Cloudflare, curretnly still on free tier:)

Hard things

Extending game engine

The base rules are simple, but once you start adding expansions (like Inns & Cathedrals, River, Abbots, Farmers, etc.), the logic tree gets messy.

Each feature can affect multiple parts of the scoring or tile-placement rules. I ended up refactoring the entire engine 3 times to add abstraction layers one on top of each other (eg. multi-tile buildings instead of per-tile features).

AI Bot heuristics

Deciding where to place a tile, and where to place a follower, isn't as simple as eg. tic-tac-toe solver. You have to account for how many followers you still have, how many open edges of a building, defensibility of your buildings, trying to merge (attack) with other larger buildings, trying to "trap" enemies so they can't complete their cities, calculate what's the chance required tile will be drawn, etc. Many rules/weights that need to be tuned, and additional complexity arises when you add expansions into the base game.

Bot optimizations

At first it just brute-forced every legal move, deep-copying the full board to estimate the diff in value (which can be score, trapped follower, etc) for each move. But after >50 placed tiles, such algo takes quite some time, up to a point where you are waiting 20+ seconds for a bot move.

By adding just a state diff and rollbacks (placing/removing followers or tiles), bots required an order of magnitude less compute time.

Current state & whats next

Right now, TileLord supports all the base rules plus several expansions. Multiplayer, Replay mode, AI bots, and mobile browser play are all working.

I plan to add additional expansions (major and mini ones), beginner tutorials, game/turn analysis, better difficulty tuning for AI, and more!

PS. We're hiring!

Looking for Senior Fullstack Developer

Erol — Fri, 26 Sep 2025 10:04:07 +0000

About Us
At TileLord we’re building a free, web-based alternative to Carcassonne. We’re a small startup with a fast-paced culture and ambitious goals.

Role
We’re looking for a Senior Fullstack Developer (remote, CET timezone) with 5+ years of experience. You’ll work across frontend, backend, and database, with a big focus on PIXI.js for gameplay. Game dev experience is a plus.

Requirements
• 5+ years fullstack experience
• Strong FE/BE/DB skills
• Proficiency in TypeScript
• PIXI.js or similar rendering/game framework experience
• Remote-friendly, CET working hours

Why Join
• Startup culture with real ownership
• Fully remote
• Competitive pay + possible equity
• Build something fun and free for the gaming community

Apply
Send your CV + GitHub link to erol@tilelord.com.