Shared hosting has one rule that quietly kills most multiplayer designs: you cannot run a persistent process. No WebSocket server, no daemon, no long-lived worker. Your PHP is born when a request arrives and dies when the response is sent.
I ran into this building a head-to-head word game — two players racing to guess the same five-letter word. The multiplayer part was fine. The problem was what happens when nobody else is online.
An empty matchmaking queue is the fastest way to kill a new game. So I needed a bot. And a bot, conventionally, is a process: something that wakes up every few seconds, decides on a move, and writes it somewhere. That is exactly the thing I could not have.
Here is what I did instead.
The constraint reframed
The instinct is to reach for a cron job that ticks bot games forward. That works, but it is coarse (most shared hosts cap you at one minute), it needs state, and it burns resources on games nobody is watching.
The better question is: does the bot need to exist between requests?
It does not. Nobody observes the bot except the opponent, and the opponent only observes it when they poll for status. If I can compute what the bot would have done by now, at the moment I'm asked, the bot never needs to run at all.
That turns the bot from a process into a pure function:
bot_state = f(battle_id, elapsed_seconds)
Same inputs, same output, every time. No storage, no scheduler, no race conditions.
Making it deterministic
The whole thing hinges on randomness that isn't random. Every decision the bot makes is seeded from the battle's own ID:
$seed = crc32($battle['id'] . '_bot_timing_v2');
Separate seeds for separate concerns — one for guess timing, one for which words it picks, one for chat messages:
$wordSeed = crc32($battle['id'] . '_bot_words_v2');
$chatSeed = crc32($battle['id'] . '_bot_chat_v2');
Because crc32 of a fixed string is stable, battle #4471 produces the same bot every single time it is evaluated. Two polls a second apart return a consistent world. A page refresh doesn't reroll the opponent. Two devices watching the same battle agree.
The _v2 suffix is doing real work, by the way. It is a cheap version namespace: when I want to retune bot behaviour, I bump it and every new battle gets the new personality while in-flight ones stay consistent. Changing the seed string is the migration.
Deciding the outcome up front
The second trick is that the bot's result is chosen when the battle is created, not discovered as it plays:
// bot_total_guesses: 0 = fail (6 wrong guesses), 3-6 = solve on that guess
$botTotalGuesses = (int)($battle['bot_total_guesses'] ?? 0);
$botWillFail = ($botTotalGuesses === 0);
This feels like cheating until you think about what it buys you.
It makes difficulty tunable as a distribution rather than emergent from a solver. I am not writing an AI that plays well and then trying to handicap it. I am picking a target outcome — "this bot solves on guess 4" — and then working backwards to a plausible-looking path. Balancing becomes a matter of adjusting probabilities, not rewriting logic.
It also means the bot cannot embarrass itself. A real solver has bad days; it stumbles into a lookalike trap and burns four guesses on PARER / PACER / PAPER. That is realistic and it is a terrible new-player experience.
The reveal is still honest — the bot's guesses appear over time, at human-plausible intervals, and you genuinely can beat it by being faster. What is predetermined is the ceiling, not the race.
Polling, and why it's fine here
Every few seconds the client hits one endpoint:
GET /api/battle/status.php?id=42
which returns both players' progress and any chat. On each call the server recomputes the bot from scratch:
if (($battle['is_bot'] ?? 0) && $battle['status'] === 'active' && $battle['started_at']) {
// derive bot guesses from elapsed time + seed
}
Polling gets a bad reputation it only partly deserves. It is genuinely wasteful for chat apps, live cursors, anything with high-frequency updates. But this game has a handful of state changes over roughly two minutes. The update rate is low. WebSockets would buy me latency I cannot perceive and cost me a server I cannot run.
Match the transport to the update frequency, not to what sounds modern.
What this pattern is actually good for
The general shape is: replace a background process with a deterministic function of time and a stable seed.
It works when the state is derivable from a start timestamp plus fixed parameters, when nobody observes it except on request, and when you can accept computing it repeatedly instead of once. Simulated opponents, staged rollouts, fake-but-consistent activity feeds, scheduled reveals all fit.
It breaks the moment the simulated thing has to react to something unpredictable, or when recomputation gets expensive, or when the entity must act while nobody is watching.
For a word duel it fits exactly. The bot has no free will to model — it is racing a clock, and clocks are the one thing you can always compute.
The honest trade
I would not defend this as the right way to build a multiplayer game. It is the right way to build one under this constraint, and it bought a working head-to-head mode on hosting that costs a few dollars a month.
The stack is PHP 8.3, MySQL, and no other moving parts. The game is WordlyPlay if you want to see the polling in action — open a battle and watch the network tab.
The wider lesson I keep relearning: constraints that look like they block a feature usually just block the obvious implementation of it. There is often a stateless version of the stateful thing you wanted, and it is frequently simpler than what you would have built with no constraints at all.
