I am currently writing a matchmaking server application for a 5vs5 UDK game.
Here is the scenario on which I built my code:
- The player starts the game and authenticate
- The player clicks an huge "Play" button and asks the server for an open lobby
- The server searches for a lobby and adds the player to the lobby found, and sends back lobby informations to the player so it can react accordingly (lobby id, players in lobby). Note that if no lobby is found (all lobbies are full, or there's no lobby at all) then a new one is created.
- The player (now in a lobby) selects a character and hits a "Ready" button.
- Once all players are ready, the server searches for an opposing team
- Once an opposing team is found, the server sends match infos (udk server ip and port) to all of the concerned players
I have written my matchmaking server with the C# Web Api template. This RESTful webservice can at the moment take care of steps 1, 2 and 3 as they are transactions between the frontend (player in UDK game) and the backend (the C# matchmaking server). The player asks for something, the server replies with JSON data. I have done so because having many HTTP requests seemed less foolish than having all authenticated players on a constantly alive TCP connection.
However, for the next steps (particularly the steps concerning what happens inside the lobby), I am undecise on what approach I should take. How can the server notify the players of new events (disconnections, new player, character chosen by a player, player ready...)? Should the players poll the server on a (very) regular basis for new events? Or would it be better to have a pool of threads to keep a TCP connection alive with the players in order to broadcast new events? Or something else? (UDP?). I'm kinda lost.
This is my first post so I hope it's not poorly phrased. Thanks.