Three ways I've watched hobby game builds go sideways, and each one teaches you what the right setup actually looks like by leaving a mess behind.
Mistake one: trusting the browser to keep score
The most common one, and the most avoidable. Someone builds a leaderboard game, wires up a WebSocket for the multiplayer bits, and lets the client compute the final score before POSTing it to the server. No validation on the way in. I watched this happen firsthand — took a bored player about four minutes to open DevTools, find the network tab, and start submitting nine-digit scores. Not because they were a hacker. Because the game handed them the pen and asked them to grade their own test.
The fix isn't clever, it's just tedious: never trust the client, full stop. Every action gets re-validated server-side, every physics tick gets reconciled against what the server thinks is true, and you eat the latency cost of round-tripping state instead of rendering locally and hoping nobody looks under the hood. That's why server-side authority isn't a nice-to-have line item here — it's the bar. A game that can be beaten from the browser console gets treated as broken, same severity as a crash, because functionally it is one.
Mistake two: a canvas element and a beep, called a game
This one demos beautifully and falls apart in ninety seconds of actual play. Some CSS transitions, a collision check, a sine wave standing in for a punch sound — it screen-records fine, and then the first real player says the movement feels wrong and can't tell you why. It's the physics. Hand-rolled "if overlapping, bounce" code never gets mass, friction, and collision response quite right, and players feel the gap even when they can't name it.
Game builds here use real engine rendering instead:
- Physics and rendering — three.js with actual physics simulation for the web stuff, genuine Unity 6 in the lab for anything heavier.
- Art — comes from the design director, not a stock asset pack.
- Audio — sampled instruments, not an oscillator doing its best impression of a footstep.
The longer case for why this isn't optional is in Real engines, real builds.
The verifier chain catches the failures a screenshot won't:
- Presses keys.
- Checks that score actually changes.
- Listens for audio output.
Sounds almost too basic to be useful, until you realize how many builds render a perfect first frame and then silently lock up because an event listener never got attached. A static image can't tell you that. A verifier that has to survive three rounds of play can.
Mistake three: making your friend run a server to play your game
Good multiplayer prototypes die at this step constantly — not because the game's bad, but because "first, npm install the server, then set these three env vars" is too much to ask of someone on a Tuesday night. You built something fun and buried it behind a setup guide.
Solo games here publish the same way any site does — one click to a live subdomain, no separate flow to learn. Multiplayer's different because there's an actual server process that needs to stay running somewhere, so those publish to a public play page with hosting handled for you. The whole point is narrow: "want to play?" should be a URL pasted into a group chat, not a README.
What the contrast leaves you with
Notice what's missing from all three mistakes above: local two-player. One keyboard, two people, usually WASD versus arrow keys, elbows bumping — it's the mode people underrate because it has zero distribution problem. No link, no server, no friend who has to click something at 11pm. Just someone sitting next to you and thirty seconds of "no wait, you're player two, use the arrows."
| Local two-player | Online multiplayer | |
|---|---|---|
| Onboarding | "No wait, you're player two, use the arrows" — thirty seconds | Matchmaking, empty "waiting for opponent" screens |
| Distribution | Zero — no link, no server, nobody has to click anything at 11pm | Needs a public play page and someone else online at the same time |
| Conversion | Basically 100% — the friction is "turn your chair" | Drops off waiting for an opponent |
The air-hockey and arena-brawler builds in the showcase lean on exactly this.
Put the three fixes together — server-side authority, real engines, hosted public play pages — plus local two-player's built-in advantage, and you get the actual range this thing supports:
- Single-player — the baseline.
- Local two-player — the free win.
- Online multiplayer — built to survive a bored teenager with DevTools open.
Every game collects in a My Games library with per-game publish status, so you're not digging through old chat threads to find which build was the good one. And if you've packaged something for Android, it continues straight into the store path instead of starting a second process from scratch.
