Devlog
Launch week diary: what broke when real players arrived, and how I fixed it
Sandeep Sahu
· 6 min read
Chalo Jantar Mantar went live on 18 October 2026. Within a day, more than fifty people were playing at the same time, and the server that had felt fast in testing was suddenly struggling. This is the honest story of the first two weeks: what broke, what I changed, and what it felt like to run a live game on my own.
Day one: the server hit its limit
The game's server is written in Node.js with the Colyseus multiplayer framework. It is the referee of every match: it moves the crowds, the traffic and the police bots, and it decides who joined whose kafila. A Node.js program, though, uses only one CPU core, however many the machine has.
On the first day, at around twelve matches at once, that one core hit 100%. Every room shared it, so every match got slow together. The menu even showed "Server offline" right next to "53 players online", because it gave up waiting for a server that was simply too busy to answer in time. Watching that happen, with real people waiting, is not a feeling I will forget soon.
Making every match cheaper
A bigger machine was one answer, and later the server did get more cores. But measuring first showed that the biggest problem was in my own code:
- A grid that was cleared too often. To find who is near whom, the server sorts the crowd into a grid of about 12,000 cells. It was emptying every one of those cells twice on every tick, in every room, and that alone was about a third of the server's work. Now it only empties the cells that were used.
- Shorter walks and drives. Passers-by now stroll to a spot they can see, so most walks need no path search at all, and cars and autos pick destinations nearer to them.
- Sending less. Players are still sent on every tick, but the crowd and the traffic are sent 15 times a second instead of 30. Your phone smooths the movement in between, so it looks the same, and it uses less data.
With these changes, one step of a match's simulation went from about 3.2 milliseconds to 1.3.
Using the whole server
The next fix was to stop leaving most of the server idle. The game now spreads its matches over all of the server's cores instead of just one, so one busy room no longer slows down every other room.
The rooms grew at the same time: first to 10 players a side, then to 15. Bots fill a side up to six, so a quiet room still has a proper match, and a busy room is all real people. Bigger rooms also mean the city's crowd and traffic are shared by more players, so the server does less work for each one.
Updating without kicking anyone out
In the first days, every update cut every match short. People who were about to win a round were suddenly back at the menu, which is a terrible way to thank them for playing. Now an update rolls through the processes one at a time. A process stops taking new players, lets its matches finish (for up to 15 minutes), and only then restarts, while the others take everyone new. When a match ends on an old process, the game tells you and quietly joins you to a fresh one.
I also learnt that players don't enjoy a game that changes every few hours. Now several features go out in one update and switch on by themselves, one a day, so there is something new to find without the game shifting under anyone's feet.
The day the server came back wrong
On 24 October I ran a routine system update on the server. It restarted the game along with it, and only part of the game came back up. I brought the rest back, and changed the settings so that a system update can no longer restart the game behind my back. Since then, checking that everything really came back is the first thing I do after any update.
Scripts and strangers
A public game attracts more than players. Within the first week, someone ran a script that asked for a seat in the same room every second, enough to make the room look full to everyone else. Now there is a sensible limit on how often anyone can ask for a seat, far more than a real player ever needs, and scripts like that are turned away before they reach the game. Others tried sending junk to the server to see what would break. Every part of it now checks what it receives very strictly, and nothing got through.
The lag that wasn't my server
On 31 October, right after an update, my own phone showed a ping of over 500 ms. My first thought was that the update had broken something, but it hadn't. The real cause was the route: some Indian networks were sending players' connections all the way to Europe and back before they reached the game. I changed how a match connects, so it now takes a much shorter way. Your ping now shows in the map's title, so you can see this for yourself; the phone guide explains what the colours mean.
The part nobody sees
Most of this diary is about code, but most of those two weeks wasn't. There is the cost: a server ready for hundreds of players, the domain and the tools around them all cost money, and the game is free to play. There is the checking, day and night, playing matches myself to see what players see, reading every message, and fixing what they found. There is the sharing, telling people about the game wherever I could, one post and one friend at a time. And every time more people came, the happiness came with a small fear: will the server hold this time?
It has held, mostly, because each problem taught me something. If you enjoy the game and want to help keep it running, the ❤️ Support button on the menu goes only towards the game, meaning its servers and its development. It buys nothing inside the game, and the game stays free for everyone either way.
What I learned
- Measure before you buy. The biggest win on day one was a fix in my own code, not a bigger machine.
- Use every core. One Node.js process is one core, and the rest sit idle unless you plan for them.
- Never end a match for an update. Let it finish, then restart.
- Check the boring things. After every system update, make sure everything really came back.
- Lag isn't always your server. Look at the route between the player and you, too.
- For anyone building a game alone: ship it small, watch real people play, and fix what hurts them first. And sleep sometimes; the bugs will still be there in the morning.
The longer story of how the game itself was built is in my developer's diary. If you have a question about any of this, ask me on the contact page.
