Lobbies Examples
This section provides practical examples of using Steam Lobbies to create, discover, join, and manage multiplayer lobbies, as well as synchronize lobby and member state between players.
All examples below are shown using Blueprint nodes, with equivalent functionality available through the C++ API.
Creating a Lobby
This example demonstrates how to create a new Steam lobby.
The Create Lobby node is called with two explicit parameters: the ESteamLobbyType and the Max Members count.
In this example, a Public lobby is created with a maximum of 5 members. The lobby type controls who can discover and join the lobby, while the maximum member count defines the player limit enforced by Steam.
Lobby creation is asynchronous. When the operation succeeds, a valid FSteamLobbyID is returned through the On Success callback.
The returned lobby ID represents the newly created lobby and is required for all further lobby-related operations, such as setting lobby data, tracking members, or allowing other players to join. In most projects, this value is stored as the current active lobby identifier.
Creating a lobby is typically triggered when the player selects a “Host Game” or similar option in the game UI.
Finding and Joining a Lobby
This example demonstrates a simple and common flow where available Steam lobbies are searched and the player joins one of the results.
The flow starts by calling the Find Lobbies node with a maximum number of results and a distance filter. In this example, up to 10 lobbies are requested using the Worldwide search scope, as defined in ESteamLobbyDistanceFilter.
Lobby search is asynchronous. When the search completes successfully, an array of FSteamLobbyID values is returned through the On Success callback.
From the returned list, a single lobby ID is selected. In this example, the first lobby in the array is retrieved and passed directly to the Join Lobby node.
The Join Lobby node then attempts to connect the local user to the selected lobby. If the join succeeds, the returned lobby ID becomes the current active lobby and is typically stored for further lobby-related operations. If the join fails, the failure callback provides the reason, such as the lobby being full or no longer available.
This combined pattern is commonly used to implement quick matchmaking or simple “Find Game” functionality without requiring a dedicated lobby browser UI.
Setting and Reading Lobby Data
This example shows how to store and retrieve shared lobby-wide data.
Lobby data is stored as key-value pairs and is shared across all members of the lobby.
This data is commonly used to represent session-level information such as selected map, game mode, ruleset, or version compatibility.
All members can read lobby data, allowing each client to configure itself consistently before the game starts.
Setting and Reading Lobby Member Data
In this example, custom per-member data is assigned and queried.
Lobby member data is associated with individual users within the lobby.
This is typically used to store player-specific state such as ready status, selected character, team assignment, or loadout choices.
Member data allows clients to react to changes in other players’ selections without additional networking logic.
Reacting to Lobby Events
This example demonstrates how to react to lobby-related events using explicit event subscriptions.
In this flow, the game subscribes to the Lobby Member Joined event using the Subscribe to Lobby Member Joined node. The node returns a listener handle, which is stored for later use.
When a new member joins the lobby, the bound On Joined callback is invoked and provides both the lobby ID and the Steam user ID of the joined member. In this example, the user ID is then passed to the User subsystem to retrieve identity information, such as the player’s persona name, which is used to update the UI.
This pattern allows the game to respond immediately to lobby changes, such as updating player lists or showing join notifications, without polling lobby state.
When the event is no longer needed, for example when the lobby is left or the UI is closed, the stored listener handle is passed to the Unsubscribe from Lobby Member Joined node.
Explicitly unsubscribing ensures that callbacks are no longer invoked and prevents outdated UI updates or dangling event listeners.
Using subscribe and unsubscribe nodes together provides a predictable and controlled way to react to lobby lifecycle changes during gameplay.
Leaving a Lobby
This example shows how to leave the current Steam lobby.
Calling the Leave Lobby node removes the local user from the current lobby.
This operation is typically followed by clearing local lobby state and returning the player to a menu or matchmaking screen.
Leaving a lobby also triggers the appropriate lobby events for other members.
Important Notes
- Steam lobbies are not game servers and do not provide network transport
- Lobby and member data should be kept small and lightweight
- The lobby owner is responsible for updating most shared lobby state
- Event subscriptions should always be unsubscribed when no longer needed