question

nforss avatar image
nforss asked

Thunderhead architecture best practice

We're building an online multiplayer game, where short games will be played one-on-one, and in the future we are planning on also adding three player and four player game modes. I've implemented match making on a separate server, which when a match is found, requests a playfab server and sends the IP address to the connected players, who are then supposed to reconnect there.

We're using Unity and C#, and I'm hoping you might help me out with some architectural/API pointers. As we will have 1-on-1 games, we'll want a single server instance to handle hundreds (if not thousands) of matches concurrently, and only scale out when CPU, memory or other such constrains become a problem. How should I go about implementing this?

Right now, I call PlayFabMultiplayerAPI.RequestMultiplayerServerAsync when a match is made, and that seems to mark the instance as "unavailable" or something to that effect, since after two requests, the method returns "MultiplayerServerTooManyRequests - NoHostsAvailableInRegion". Or is this due to something else?

Any ideas, suggestions or links to resources I could use would be much appreciated.

Ps. The match making and game play works well when testing locally through the MockAgent.

apisMatchmaking
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
Andy avatar image
Andy answered

You effectively have two options since you're managing your own matchmaking.

The way PlayFab's Multiplayer Servers are meant to work is you run many game servers per VM. If your games are just 1v1 with minimal server usage, you could run many server instances on a low-spec VM. If you do it this way, you'd call RequestMultiplayerServer for each match and get back a distinct server instance for each.

If, on the other hand, you want to plumb multi-match capabilities into your server you'd set fewer servers per VM and probably use a beefier VM type. Doing this, though, you'd only call RequestMultiplayerServer once per server instance. Then, while keeping track of how many players had been placed in matches on that server, you'd assign new matchmaking requests to the same server (though maybe a different port or some other way of denoting a different match).

Personally, I prefer the first option, though there is a bit of overhead from the containers that may lead to the second being overall more efficient with VM resources.

4 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

nforss avatar image nforss commented ·

Thank you very much for your answer!

Since the match making is running on a separate server that acts like a lobby, with other concerns such as providing in-game shop functionalities too, I think the first approach seems to be the correct one for us. I guess in that case I'd just ratchet the Maximum Servers setting up to [some big number] and see where the VM's capacity starts to deplete (through load testing). Or is there some automatic functionality that allows a new VM to be set up, or the current one to be given more resources, as needed?

0 Likes 0 ·
Andy avatar image Andy ♦♦ nforss commented ·

Currently, yes, you would have to do some performance testing of your server to know how well they deal with 'n' instances per VM. You want to tune 'n' to be as high as possible before you see degradations in the client experience. We'll automatically scale up the number of VMs as the needed number of servers increases, but we'll use your pre-determined 'n' as our scale factor..

0 Likes 0 ·
nforss avatar image nforss Andy ♦♦ commented ·

Ok, cool. Do we need to inform playfab support about our performance testing ahead of time? I wouldn't want to lose our indie status because of a sudden influx of fake users. :)

0 Likes 0 ·
Show more comments

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.