Turn Based Multiplayer Without A Websocket Server
Every turn based multiplayer game needs the same three things before any of the fun parts work: a way for players to find each other, a way for friends to play together on purpose, and a way for every player to see every move in the same order. Building that usually means standing up a websocket server, writing lobby logic, and keeping a long lived process alive somewhere. We wanted the version that fits on shared hosting, so we wrote one and put it on GitHub under MIT.
Why Plain HTTPS Is Enough
Turn based play has a property real time games do not: the player is thinking. Seconds pass between moves. A websocket layer buys latency nobody can perceive in that setting, and it charges you a persistent process, sticky sessions, and reconnect handling in return.
Five plain HTTPS endpoints cover the whole flow. A client joins a queue, polls until it is matched, then sends and reads moves. No socket to drop, no process to babysit, and a mobile client that gets backgrounded rejoins with the same request it always makes.
A Server That Knows Zero Game Rules
The decision that made it reusable was refusing to model games at all. A move is an action with a type and three data fields, and those fields are opaque strings the clients define. Chess notation, card plays, dice rolls, word submissions, chat lines, surrender flags: the server stores them, orders them, and hands them to every player in the match.
One instance runs a chess game, a card game, a word game, and a party quiz at the same time without a line of server code changing. Your rules stay in the client where you can iterate without a deploy.
State As An Ordered Action Log
Instead of storing game state, the server stores an append only log per match, where each entry carries a sequence number. A client asks for everything after the number it last saw, replays those actions in order, and it is current.
That collapses several problems into one. Catching up after a crash, resuming after an app switch, and a normal poll are the same operation, which removes a whole class of resync bugs. It also makes debugging concrete, since the admin view shows the full action log for any live match.
What You Still Have To Build
Matchmaking is a queue keyed by game mode and party size, where modes are strings your game invents and a player can sit in several at once. Private matches are a short join code that maps to a match ID. Expiry matters more than it sounds, so abandoned queue entries and finished matches clean themselves up and nothing accumulates.
The whole thing is one PHP application and one SQLite file, no framework and no dependency install, so it runs on shared hosting, a VPS, a Docker container, or a laptop during development.
The Takeaway
If your game is turn based, the websocket server is probably the part you do not need. Start with request and response, keep an ordered log, and let the client own the rules. The endpoint list, the demo game and the setup guide are here.