Killbook3D is a first-person whodunnit you play in a browser tab. Everyone wanders a school at night searching cupboards and desks for a hidden book. Whoever finds it is told — privately — that they are now the Killer. From then on they take name tags off the walls and write names in the book, while everyone else searches, guards their own tag, argues at meetings and votes.
Games like this live or die on one thing: the secret has to stay secret. And a browser is a terrible place to keep a secret.
Anything you send to a browser can be read
If the server tells every client who the Killer is and trusts the interface to hide it, someone will open the developer tools and find it within a match. The same goes for where the book is hidden, where other players are standing behind walls, or what was said in a private message.
So we started from a rule: the server knows everything, and each browser knows only what its player could know.
The server is the game
Every rule lives in the server's room logic. Clients send intentions — move, search, take a tag, write a name, ring the bell, vote — and the server checks each one against the same speeds, ranges and timers before anything happens.
What comes back is filtered per player:
- Your own role, and nobody else's.
- Positions of players in range and in line of sight — not everyone on the map.
- Only the messages you are allowed to read. Even the chat history you receive on joining is filtered for you.
Opening the developer tools shows you exactly what your character can see. There is nothing else there to find.
The minute of searching
The opening is a good example. A bell rings on a dark screen: find the Killbook to become the Killer — you have one minute. Whoever opens the right container is told on their own screen, and nobody else learns anything until the minute is up. Then everyone sees the whole cast and their own role at the same moment. If nobody found the book, someone is made the Killer anyway, and the reveal looks identical — so you cannot work it out from timing either.
Bots that play fair
We wanted people to be able to play alone or fill empty seats, which meant bots. The easy way to write a bot is to let it read the server's internal state. That would make it a cheater with perfect information, and it would feel like one.
Instead, a bot is just another player:
- It acts only through the same public actions as a human, with the same validation.
- Its brain is fed exactly the messages a human's browser would get — so it does not know who the Killer is unless it sees them at it.
- It only notices what is in front of it, about the width of a player's camera, and turns to look around when it stands still.
- The Killer bot blends in: it searches like everyone else, takes tags only when nobody is watching and turns its torch off to do it.
A nice side effect: because bots make every decision on the server's clock, a whole match can be fast-forwarded inside a test.
Testing a game you cannot see
The rules engine has its own test suite, and there is a headless test player that can join a room by code alongside any number of others — searching, answering meetings, voting and playing the Killer — so a full match can be exercised without opening a browser.
What we took away
Fairness in multiplayer is mostly about what you don't send. Putting every rule on the server and filtering each player's view made cheating pointless, made bots honest, and made the game easier to test.
We bring the same server-first thinking to our SaaS platforms — where the "secret" is usually someone else's data. Have a multiplayer or real-time idea? Let's talk, or play a round.
