Encode a short room code in the URL, validate and expire it server-side, let the client join automatically on load, and show a clear message if the room is full or gone. Use the host platform’s native share/invite API where one exists instead of building your own.
At a glance
| Fact | Value | Source |
|---|---|---|
| Invite link should carry only a room code | not full state | playgama.com |
| Room state and expiry belong on the server | not the URL | |
| WebSockets used for live lobby sync | persistent connection | developer.mozilla.org |
A good lobby invite link is short, carries a room code as a URL parameter (not the full game state), and lets the server decide whether the room still exists, is full, or has expired before the client joins. Keep the client logic simple: read the code from the URL on load, call the server to validate it, then either auto-join the lobby or show a clear reason it failed (room full, host left, code expired).
If you publish through Playgama using the Bridge SDK, one HTML5 build adapts to 25+ platforms.
If you publish to multiple platforms, use platform-native invite and share dialogues where available so players can send room links directly through their friends lists.
What should the link itself look like?
- Use a short, unguessable room code (not a sequential integer) as a query parameter, e.g.
?room=ab12cd. - Keep secrets – host permissions, private lobby passwords – off the URL; pass them after a validated handshake.
- Set a server-side expiry on the room, not just on the link, so old links fail cleanly instead of connecting to a dead session.
- Handle the “room full” and “room not found” cases explicitly in the UI rather than leaving the player on a blank screen.
- Keep the live lobby state synced over WebSockets rather than polling, so joins and leaves show up instantly for everyone already in the lobby.
- Test the link cold: open it in a fresh browser tab or incognito window, not just by clicking “copy” in the same session.
Sources
- Playgama for developers
- Playgama wiki: Social
- MDN: WebSockets API
- MDN: Web Storage API
- Poki for developers
Related questions
Should the invite link include the player’s name or ID?
No, keep identity separate from the link. Let the client send its own player info after joining, so the same link can be reused by different people safely.
How long should a lobby invite link stay valid?
Tie validity to the room’s actual lifecycle on the server (host present, room not full) rather than a fixed timer, so links fail predictably instead of silently.
Can I store the last room code in the browser for reconnects?
Yes, the Web Storage API is suitable for remembering a recent room code locally so a dropped player can rejoin quickly, but the server must still revalidate it.
Last updated: 24 September 2026