Skip to main content

Steam Lobby Lifecycle

The Steam lobby is the party. Understanding this lifecycle explains 90% of how SPM works.

The Golden Rule​

There is no traditional replication in the party menu; every player runs the menu level locally. All shared state travels through the Steam lobby data (key/value strings on the lobby) and lobby member data (key/value strings per member). When any value changes, Steam notifies every member via On Lobby Data Update, and each client updates its own screen.

The keys used for this data are defined centrally in PM_SettingsData.

Startup​

  1. Game launches into the PartyMenu level with BP_SPM_PartyGameMode and BP_SPM_PartyController.
  2. BPC_PartyManager (on the controller) runs Begin Play with Party Manager Type = Menu:
    • The SIK Bindings graph binds all Steam delegates (lobby created/enter/data update/chat/invite/join requested).
    • Setup PartyMenu Level finds the 4 BP_PartySpot actors, spawns the local avatar and creates WB_PartyMenu.
    • Create SPM Party creates a fresh Steam lobby for the solo player.

Creating a Party​

Create SPM Party macro (host):

  1. Calls SIK Create Lobby with the saved lobby type.
  2. HandleOnLobbyCreated fires → the Lobby ID is stored in BP_SPM_Gameinstance (via GI_SetLobbyID), so it survives level travel.
  3. Initial lobby data is written from the player's saved preferences: party size, game mode, map, joinability, Game Server State = NoServer.
  4. HandleOnLobbyEnter fires (the creator also "enters") → the host writes its member data: member index (spot), skin type, skin variation, ready status.

Joining a Party​

Three entry paths, all ending in the same place:

  • Invite accepted → HandleOnGameLobbyJoinRequested → Join SPM Party
  • Steam friends list / social menu → Join SPM Party directly
  • Looking for Party tab → Find LFP Parties → Join SPM Party

After Join Lobby succeeds, HandleOnLobbyEnter runs on the joining client:

  1. FindLastJoinedMemberIndex picks the first free spot index and writes it to the member's lobby data.
  2. The member writes their skin data (validated by Validate Skin Type against this project's characters).
  3. Everyone else receives On Lobby Data Update → spawns the new member's avatar on the right pedestal via SetMemberAvatar.
  4. HandleOnLobbyChatUpdate fires on all members → SendSystemMessage posts "X joined the party" and OnPartyMemberCountChange updates UI.

Reacting to Changes​

HandleOnLobbyDataUpdate is the central reactor. Any change to lobby or member data lands here, and it:

  • Updates avatars/skins (Character Data Update)
  • Updates ready status display (OnPartyMemberReadyStatusChange)
  • Updates the match settings box (Update Play Box Settings)
  • Checks Game Server State: if the host started a server, clients run Join Game Server (if available)

When you add your own shared feature, follow the same pattern: define a key in DA_PM_Settings, write with Set Lobby Data/Set Lobby Member Data, react in HandleOnLobbyDataUpdate.

Leaving & Host Migration​

When a member leaves (or disconnects):

  1. HandleOnLobbyChatUpdate reports the state change.
  2. Handle Leaving Player resets their pedestal (Set Pedestal State), removes their avatar, frees their member index and posts a system message.
  3. Steam automatically migrates lobby ownership if the host left. Check Host Crown Ownership re-resolves who displays the host crown and gains host powers (kick, match settings, starting the game).

Kicks work cooperatively: the host writes a kick entry into lobby data and the kicked client leaves the lobby itself when it sees it.