← Back to selected work

MULTIPLAYER INFRASTRUCTURE

LobbySystem

A custom Unity multiplayer foundation for public/private lobbies, real-time player synchronization, Relay connectivity, host migration and persistent moderation.

UnityC#Netcode for GameObjectsLobbyRelayAuthentication
REAL-TIME MULTIPLAYER FOUNDATION
RoleNetwork Programmer / Solo Developer
EngineUnity
LanguageC#
FocusLobby • Matchmaking • Sync

I built the lobby and session layer as a reusable multiplayer foundation rather than a one-off menu.

The system covers the full flow from finding or creating a lobby to synchronizing player state, starting a Relay session and handling ownership changes when the host leaves.

LOBBIES

Public & private matchmaking

Players can create discoverable or private lobbies and join active sessions through a clean matchmaking flow.

SYNC

Real-time player state

Player data, presence and status updates are synchronized so every client sees lobby changes immediately.

SESSIONS

Relay-backed game start

Unity Relay and Netcode for GameObjects handle connection setup and the transition from lobby state into the game session.

RESILIENCE

Automatic host migration

If the host disconnects, ownership can move to another player while preserving lobby state and minimizing interruption.

The useful part of the project is not the lobby screen — it is the networking and session logic underneath it.

  • Dynamic UI: Lobby UI reacts to joins, leaves, ready/status changes and session events in real time.
  • Kick & ban: Players can be removed and persistent bans prevent blocked users from simply rejoining.
  • Cloud services: The project uses Unity Lobby, Relay and Authentication together instead of treating each service as an isolated feature.
  • Reusable architecture: Session responsibilities are separated so the same foundation can be extended for different multiplayer game flows.

This project was my first complete pass at treating multiplayer as infrastructure: connection flow, player state, ownership, failure cases and UI all have to agree.

It became the base for the way I approach later multiplayer work: keep network responsibilities explicit, keep the UI reactive, and make disconnects part of the design instead of an afterthought.