One of the most difficult balancing acts to carry out in an online game is the management and distribution of players between conceptual instances of game systems like parties, guilds, phases, and chat. Membership often depends upon several factors: the location of the player, the affiliation of the player with social groups, the player's current progression through game content, or a player's immediate functional needs; and, as a result, the population and state of these instances fluctuate wildly with time. It's useful, then, to have a system in which players - regardless of where they are in the game world - can subscribe, unsubscribe, and interact as members of a given conceptual group quickly, efficiently and in a load-balanced manner.
We call these conceptual groups Lobbies and - with customization - they can be used to facilitate a variety of game mechanics which require tracking player membership and interaction. Support is included to allow direct interaction with lobbies (via replication) from any arbitrary area server or player's client; this is useful in cases (like the traditional 'pre-game lobby') in which players are expected to immediately and directly interact with the lobby and each-other.
Behind the scenes, the Lobby System's logic is housed in a System Area. This area is responsible for storing data on all currently instantiated Lobbies as well as facilitating communication (either directly through remote calls or indirectly through replication) between clients of the Lobby System and the system itself. The system is load-balanced to prevent over-crowding of any one lobby system worker instance and allows many sparsely-populated areas/systems' lobbies to be combined into a single area instance.
Possible use cases include:
- Traditional Real-Time Strategy pre-game lobbies (e.g. players join, select their race, click 'ready' and wait for the game to begin)
- Tracking live-event membership and participation
- Facilitating regional (location-based) or global system-level interactions between players (e.g. regional/guild chat, raid participation, guild chat, regional player-tracking)
What problems does this solve?
- Provides a means of managing player subscriptions to game services like chat or live events remotely (without requiring access to the player account node)
- Provides a means of communicating between players who - for a period of time - have similar needs (e.g. trade requests, temporary groups, regional chat)
- Provides a means of offering a client-side interface to players to directly manipulate or interact with lobbies
What problems does this not solve?
- Game-specific lobby logic must be provided by developers; the choice of what to do when a player joins, leaves or interacts with a lobby may be extended or replaced by your own custom logic
- Since the lobby system is a relatively low-level system, it can be leveraged to accomplish a variety of tasks that revolve around player membership across areas; this means it is not an 'out-of-the-box' solution for all but the simplest use cases. Care must be taken to only use features of the lobby system that are needed and to appropriately extend or override functionality that is specific to your game.
Areas of Responsibility
The Lobby System is comprised of four areas of responsibility, each of which is carries out its own piece of the overall logic:
- Control Instance
- Worker Instance
- Game Area
- Player Client
The Control Instance is responsible for maintaining knowledge of all Worker Instances that exist as well as the contents of each of the worker instances. This is accomplished by responding to spin-up and spin-down events for the worker instances as well as maintaining a set of lightweight objects containing the identity of the object as well as a means of communicating with the object (this is accomplished, as will be explained below, via replication of the lightweight object from the worker instance that contains the entity to which the lightweight object points). All requests to discover or forget a lobby system entity are directed to the control instance, which - having knowledge of the identities and locations of entities - forwards the request to the appropriate worker instance.
The Worker Instance is responsible for creating, destroying and maintaining all lobby system entities. When an entity is requested to be created, the creation is delegated from the control instance to an appropriate worker instance based upon the load balancing rules defined. Discovery requests made to the control instance are routed to the worker instances, which respond to these requests by 'revealing' (i.e. replicating) the entity to the requester. Likewise, requests to forget, delete, subscribe to, unsubscribe from, or modify an entity are routed through the control instance to the appropriate worker instance, which passes the request to the appropriate lobby system entity for processing.
The Game Area is defined as any area server instance that wants to act as a client of the lobby system by making requests of it. This means the game area might be another system area, a communal hub area, or any other game area. This area is responsible for making requests of the lobby system to create, destroy, subscribe players to, unsubscribe players from, or modify lobby system entities. This is usually accomplished by - after creating an entity - discovering it and then responding to the discovery by performing specific actions upon it. Additionally, the game area may make lobby system entities available to clients who also wish to interact with the entity.
The Player Client is involved only in situations in which the game area offers an interface to the client to interact with a lobby system entity. Situations in which this would happen might include the joining of a player to a specific pre-game lobby (the appropriate response to which might be the revealing of the lobby to the client and the presentation of a lobby GUI) or the joining of a player to a specific chat channel (the appropriate response to which might be the updating of the player's chat GUI to reflect the new channel membership).
The Lobby System is comprised of three basic types of objects:
- Lobby Directories
- Logical Lobby Directories