Architecture of a multiplayer lobby and matchmaking system?

Question

I am looking to design a system where a player can

1. Run the game, hit a button to enter the arena, which will send his IP Address/player profile/network stats up to the server.

2. The matchmaking/lobby server will maintain a collection of all available players. It will continuously look for pairs of players that are a "match" (algorithm not important right now).

3. When it finds two queued players that are a "match", based on the player profile data it will pick one of the players as the server and will then notify the game clients that a match has been found. Based on the notification the client receives, the client who was selected as the server will launch a server and the other player's client will connect to that initialized server when it's ready.

What is a good way to set this up? My first thought was to send the player stats up via an HTTP POST. But it could be minutes in some cases before the server finds a match and responds with what type of connection the player will have and who their opponent will be. Would HTTP be appropriate for this? Or should this be a lower level customized socket based approach? Or am I completely off here?

P.S The game is a being developed in Unity. I'd prefer answers that weren't just, "here's a link to a plugin that works" as I'm interested in understanding the architecture behind how this is typically implemented.

Any guidance would be appreciated.

Answer 1

I've done quite a bit of work with these types of systems. If I was you, I would already have a http end point setup to handle situations like this. In game http post/get is a terrible idea, but in user interface it's really not bad. You could poll every 5 seconds, or have the server tell the client when to ask again.

You could also use UDP and send pings back and forth to determine if a client is connected instead of falling into the TCP well with timmy(It feels so safe, but don't let that hair fool you). The nice thing about this is the overhead is way less than http post/gets, the down side is fragmentation and order(of course if you have a proper state machine going the order isn't going to matter much).

So, taking all that into consideration, here are my suggestions using http(the same could be applied using udp with a few tweaks, but I'll go with http because then I don't have to get into the fragmentation stuff).

Set up and IIS server with a hosted {insert framework here (WCF, WebAPI, aspx pages, php even)}.

To make life easier, create a wrapper class with every possible api call you need.

I would imagine the calls you'd want would be something like this(-> Means to the server, <- is the http response from a get/post).

• 1 -> Hello (player data. This is an initial arena handshake)
• 1 R.1. <- Welcome (If the server likes the player, this tells them they're accepted)
• 1 R.2. <- Error (This player was banned for lude behavior, no games for you)
• 2 -> FindMatch (Matchmaking starts looking as soon as they say 'Hello', this is asking the server if it found anything yet. You can also bundle in stats like 'Expected Wait Time' etc. This acts as a ping to check if the client is still alive. The response to this will act as a ping to the user to tell them they're still connected to the server. You could implement a separate 'ping' call as well, it's really up to you)
• 2 R.1 <- NothingYet (We found nothing, chill out and wait)
• 2 R.2 <- GotOne (We found a match. You would tell the client if they should start up a server or connect at this point.)
• 3 -> Leave (Wave goodbye to matchmaking)

Hopefully this helps. Also like I said, you could accomplish the same with UDP. I really wouldn't go into TCP though(from experience).