I've designed online lobby systems before, however, creating one that's compatible with steam required a slightly different approach than the types of implementations I developed before, so I quickly got to work on designing the new implementation.

Steam's lobby API comes with it's own callbacks that makes it easy to hook to a lobby's OnCreated, OnEntered, and OnDisconnected.

Creating a lobby involved obtaining a Steam ID for the lobby and pairing it with the host's address. However, Steam’s generated lobby IDs are not user-friendly for direct sharing.

I used a RealTime Database hosted by Firebase to store a joinable lobby code that was easy and readable for players. What I did was generate a 6 character code, mapped it to a Steam Lobby ID, and created some functions to grab that code whenever necessary.

When a player enters a lobby code, the system queries Firebase, retrieves the corresponding Steam Lobby ID, and connects the player to the host. This streamlined the join process and made the system more accessible for players.

I implemented this using a PlayerData class, responsible for storing a player’s ClientID (identifies the client), UserID (identifies the player), TeamID (identifies the team), and ModelIndex (identifies the chosen character). The class and its attributes are serialized on the network to ensure compatibility across clients.

When a player joins, a PlayerData instance is created and assigned to the first available slot in a networked list for efficient retrieval. Since the game supports up to four players, each entry is stored sequentially and kept in sync with its corresponding player object.

When a player disconnects, their data is retrieved from a map and safely removed, ensuring the system remains consistent.

The two core systems of the game are the GameManager and RallyManager. The GameManager controls match flow—starting games, tracking scores, and beginning rallies—while the RallyManager handles ball spawning/serving, relocating players, and detecting when the ball hits the ground. Together, these managers maintain smooth gameplay cycles and include their own timer systems for match and round duration.

Part of syncing these systems across the network was first identify which elements needed to be synced on the server and which should be kept on clients. A general rule of thumb I went by was "If everyone needs to see or access it, sync it." This helped in finding which parts needed to be synced.

The more difficult task was separating overlapping responsibilities—determining what logic belonged exclusively on the server versus what should be distributed to clients. I tackled this by reorganizing systems into a clearer structure before layering the network.

After integration, came play-testing, refactoring, and more play-testing.