Idem directly integrates with Steams Lobbies to enable friends to join matchmaking together in player-based architectures.
Integration with Steam lobbies is a beta feature. Reach out to match@idem.gg if you are interested in joining the beta.
Conceptual approach
Parties in player-based architectures are based on a concept called waiting_rooms. These allow players that are submitted independently (like it is the case in the player-based setup) to wait for each other before being submitted to the matchmaking together.
waiting_rooms are identified by the Steam lobbyId and a custom sessionId. If an addPlayer action includes these two values, Idem will verify the lobby exists on Steam, check which players are part of the lobby on Steam, and create a waiting_room for it. For each following player being submitted with the same lobbyId and sessionId, Idem will check if they are expected members of the session and then add them to the waiting_room. Once all expected players have arrived, the players are submitted to matchmaking as a party.
Setup
There are two parts to setting up player authorization via Steam.
- Implementation on the game client side
- Configuration on the Idem side
Game client implementation
addPlayer request
Submitting a player for a party using the Steam lobby integration is as simple as adding a Steam lobbyId and a sessionId to the addPlayer request.
{
"action": "addPlayer",
"payload": {
"gameId": "2v2",
"players": [
{
"playerId": "11111111111111111", // <- steam_id
"servers": {
"Frankfurt": 1,
"London": 1
}
}
],
"lobbyId": "109775242834215384",
"sessionId": "07b22b47"
}
}
It is important that you use the steam_id of the players as the playerId. This is used to verify that the player is actually a member of the lobby.
The sessionId is used to distinguish between different sessions when multiple games are played from the same lobby. It can be any value but has to be the same for all players.
It also has to be set as a LobbyData element on the Steam side. Idem is checking this value when verifying the lobby.
Since some frameworks handle capitalization for Steam LobbyData entries incorrectly, the check for sessionId is case insensitive. So LobbyData values for sessionID, sessionid or the like on the Steam side will work as well.
We recommend that once the game should start, you configure your game client so that the lobby owner sets the lobby to non-joinable , then generates a random sessionId and shares it with the other members via SetLobbyData.
Idem will respond to the addPlayer request with the default addPlayerResponse. But that response will include the lobbyId and sessionId to show that the player was submitted to a waiting room.
{
"action": "addPlayerResponse",
"payload": {
"gameId": "2v2",
"lobbyId": "109775242834215384",
"sessionId": "07b22b47",
"players": [
{
"playerId": "11111111111111111",
"reference": null
}
]
}
}
Once all players of the party have been added, all game clients receive a partySubmittedToMatchmaking message of the following shape:
{
"action": "partySubmittedToMatchmaking",
"payload": {
"gameId": "2v2",
"lobbyId": "109775242834215384",
"sessionId": "07b22b47",
"players": [
{
"playerId": "11111111111111111",
"reference": null
},
{
"playerId": "22222222222222222",
"reference": null
}
]
}
}
If the connection of a game client is interrupted before the party is submitted to matchmaking, the game client can rejoin again to take his place in the waiting room. The party will not be submitted to matchmaking if not all players are present, i.e. a WebSocket connection to them is active.
After this, the matchmaking will behave exactly the same as for individual player submissions in the player-based architecture.
This means the next step will be receiving a matchFound message.
Individual players can of course still be submitted to matchmaking when the Steam lobby integration is enabled. Simply don't inclde the lobbyId and sessionId in the addPlayer request.
Waiting room expiration
Waiting rooms expire out after two minutes if not all expected players are joining. In that case a message like the following is sent to each connected client and they are removed from the waiting room.
{
"action": "requeueRequired",
"payload": {
"gameId": "2v2",
"sessionId": "07b22b47",
"reason": "waitingRoomExpired"
}
}
Error responses
Due the multiple game clients and Steam as an external service being involved, there are a couple of error scenarios outside of Idem's control that can happen. Theses are identifed by the following error messages.
| message | code | description |
|---|---|---|
lobby_not_found | 404 | The lobbyId could not be found for your game on Steam |
lobby_information_request_failed | 502 | Idem could not retrieve the lobby information from Steam |
no_sessionId_found | 404 | sessionId not found in the lobby's LobbyData |
player_not_part_of_lobby | 403 | The playerId in the addPlayer request was not part of the player list for the Steam lobby |
sessionId_mismatch | 403 | The sessionId in the addPlayer request does not match the sessionId in the LobbyData |
waiting_room_expired | 410 | More than 120 seconds have passed since the first player was added to the waiting room. A new session has to be started. |
waiting_room_already_completed | 410 | All expected players have joined the waiting room already and it has been submitted to matchmaking. |
Idem configuration
To be able to retrieve the lobby data from Steama using the Steam Web API, a publisher API key and the appid of your game needs to be configured within Idem.
You can find more information about creating a publisher API key in the Steam documentation.
To configure these parameters and turn on Steam authorization, please reach out to match@idem.gg. They ability to do so yourself will be added to the Idem console for self-service soon.
Steam specifies a rate limit of 100,000 requests per day for their Web API. If you expect to exceed this limit with your game, we recommend you request an increase of the limit at Steam