Prospects for a service which handles parties, lobbies, and much more

[Laremere]

This issue is a starting point for solving problems that are matchmaking related but not solved with Open Match’s core components and design. The intention here is not to solve all matchmaking problems, but tackle some important and vaguely related issues. It also seems apparent that these systems would be useful for solving other problems, not just in the domain of matchmaking. We are starting this discussion within Open Match because it seems like a pragmatic location to do so, but in the future will take on whatever form we find that the problem needs. We intend for this to be a community lead discussion, so it will only progress further if others provide design input and commitments to code contribution.

Action Items

Get a feel of the gestalt of the features and solution outline here, speak up if it would solve problems you have, fail to do so, or needs tweeks to fit your requirements. Don’t focus on the details of the solution quite yet - those are easy to iterate on, but instead the high level ideas. The content here is roughly organized from most important to least.

If you want this to exist, the best thing to provide is commitments to help build it. It’s obviously too early to provide those off a single rough design draft, so please do you best to foresee what we need to do to get to that state.

Game night

Let’s begin with a simple story from the gamer’s perspective, and then afterwards dive into what needs to be happening behind the scenes for this story to work.

Alice and Bob are friends and want to try out the latest gaming hit, FPS: the Game. Alice is playing on the streaming service Arenia, and Bob is using their PlayCube console. They both have bought and loaded FPStG, and played through the tutorial.

Alice starts off by texting Bob their user details. Bob searches for Alice and sends a friend request. After accepting the friend request, Bob and Alice can now see each other in their friends list. Alice now sends Bob a similar party request, and after Bob joins their avatars are standing together FPStG’s main menu.

They briefly chat in game about which mode they want to play, and decide that they first want to try out the 2v2 Lifematch. Alice clicks the option from the menu, and “matchmaking...” appears on both of their screens. After a short wait, they find a match playing against Charlie and Dan.

The match is going well, with Alice and Bob having a fun time. However they see that Dan suddenly dropped from the game! Now they’re just playing against Charlie, which is not fun for anyone. Luckily, after a few seconds, Erin joins to replace Charlie’s spot.

The competition is fierce, but Alice and Bob win in the end, great success! This certainly was a lot of fun, so they continued playing late into the night.

Features

Even this short and simple example hit upon a large number of required features:

• The players, despite different platforms and authenticated methods, logged into the same system.
• Friends:
  • Searching for other players to friend.
  • Sending a friend request.
  • Getting notified of a friend request.
  • Accepting a friend request.
  • Seeing other friends online to play with, with their status
• Parties:
  • Sending party invite
  • Getting notification for party invite
  • Accepting party invite
  • Joining friend’s parties without invite (possibly)
  • Chat within a party
• Matchmaking:
  • Starting to look for a match, notifying everyone in the party
  • Joining a match when one is found
  • Working with parties of players, instead of just individual ones
• Backfill
  • Server starting search once one of the players exited
  • Filling a player into the match

Also very subtly, there are several matchmaking parameters that are invisible to users but must be implemented with care: Game clients need to determine the best server regions to matchmake on, and player skill (eg elo/glicko) needs to be read for all party members before starting matchmaking, and then updated after the game is finished.

Infrastructure layers

When looking across this feature set, several patterns emerge:

• A database is required. Obviously required for persisting player friends and skill, but also likely useful for most of the data here, including who’s in a party or game session.
• An authenticated front end for the game to talk to is required. This ideally accepts connections which are easy to implement in many game engines and environments, but still provides the security and flexibility required.
• Push notifications are immensely useful, as there are a large number of notifications that a game client can receive. Polling could work, but would be inferior.
• Game specific logic or customization is important here. There’s a lot of “in general this will work” for the specific calls and capabilities, but the devil is in the details and there’s lots of cases where games will want some subtle behavior change. Additionally they will often want to add additional info: In the example the players could see each other’s avatar on the main menu when they were in a party. This would require updates to the state of the player’s party to contain game specific information about the appearance of the avatars, and that to be updated if a party member changes that appearance.

The ideal scenario here is solving these problems in scale. If the game team only needs to implement RPC calls which include all of the input info needed in the request, infrastructure scaling issues can be moved completely away from them.

Universal Concepts

There are 5 concepts which appear to be fairly universal:

• Player - one game account with game specific attributes such as level or items
• Client - a game client logged in as a specific player, which can send requests, and receive push notifications.
• Party - a collection of players which join games together
• Lobby - a collection of parties which will play together
• Session - a single match within a lobby, often with an allocated server. Only one active session per lobby at a time.

Interactions

These primitives can allow for building up features.

Match acceptance is implementable as matchmaking into a lobby. The lobby controller accepts input that a player has accepted the match - if not all players accept the match before the timeout, the lobby closes itself and the party controllers return back to the matchmaking queue.

Lobbies which can be created by players and allow for further control and game specific customization provide a way for players to invite friends into a custom game without using the resources of a game server.

Lobbies would also be useful for building an OSS server browser - far from a matchmaking use case but often great for players, especially for games which allow custom game modes. I’d love to end the streak of all server browsers being universally clunky and slow to load.

Lobby based matchmaking is a frequent request for Open Match. Players seeing a match being formed is a compelling use case for many developers.

Having all players be a member of a party, even if they’re alone, seems like a nice simplification. The rest of the system can assume it’s working with parties and be done with it.

Clients and players /might/ be interchangeable. However it starts getting complicated if you have launcher apps, phone companion apps, or cross game accounts. It’s possible that a player should get a new message notification on their phone as well as a launcher app, for example. Also if the architecture lands on something more akin to message passing, a message passed to the client may really just be a push notification sent directly to the client.

Sessions are useful as separated from lobbies. It would allow a player to view recent games played, and definitely provide useful debugging and analytical information when split from lobbies in games where a lobby might have multiple matches - which would be very common for any game with custom lobbies to play against friends.

Moving further away from the domain of matchmaking, it seems a service like this would also be in charge of:

• any game specific item, progression, ranking, etc systems.
• As noted it is also probably a good spot for chat: Direct messaging, party chat, and lobby chat are closely tied to information which would be in this system.
• Similarly, voice chat would require a significantly different system to operate, but needs to be managed much the same way as text chat and game servers.
• Stores and in game currency purchases
• Player stats and profiles
• Reputation, reporting, and abuse prevention/reduction.
• Saving player config settings (eg, keybindings across multiple computers)
• Achievements
• Workshops / mods / custom levels

A universal director for Open Match integrating with this system would make sense. Additionally with a function to turn parties or lobbies (for backfill) into tickets, the external callers to open match would be implemented by this.

Other random choices:

Too early to get into solving some of this, but thoughts that came up while typing everything else up.

How does cross platform friending work? Do they use the respective platforms IDs? A friend code like system? Register with the game or publisher for a cross platform account? What about single platform or singleplayer first games - there it makes little sense to immediately force a player to create an additional account of first boot up. There are a lot of choices here and while I’m guessing a game or publisher account is preferred, it should be possible to do other things to meet external design requirements.

Do parties have leaders? For large parties it can be helpful to have a leader so that mischievous members don’t mess with the group, but for a well behaved group the confusion about who is the party leader and getting them to click the right buttons can be equally frustrating. Same goes for custom game lobbies.

Implementing a game to work with all of this is a massive task. It would be awesome for the developer experience to provide test beds for integrating your game with these systems. This means light instances to run client tests off of, and to quickly iterate and verify client implementations. I’m picturing a game client open on one screen, and the developer being able to, eg, click a button on a webpage which causes their client to get a friend request notification.

[syntxerror]

This would be a great sample to work along side Open Match but should not exist as part of the matchmaker or its process. This would be great for the ecosystem repo. Will move there.