Best way to port unity - supersocket (ws) - c# server to Playfab [SPECIFIC]

Question

question

contact-3 asked Oct 10, '16

Best way to port unity - supersocket (ws) - c# server to Playfab [SPECIFIC]

Hi,

I'd like to get into playfab to manage my users credentials, user data, monetization, matchmaking and server load balancing.

Right now we have a functional game that works with a c# custom server https://github.com/kerryjiang/SuperSocket, Unity connects to it through a custom WebSocket logic.

For now we're using a custom Mongo instance to persist players data.

We've seen Photon plugins, it seems we could easily plug our current logic into it (we solely need to matchmake players with others or IA and to send asynchronous messages), we already have a serializable gameState too.

What would be the best way to address our changes and to integrate with playfab/photon ? Is even photon necessary or could we use your own server system directly for room creation/matchmaking/load balancing ? What's the most mature in your own opinion ?

Concerning Load-balancing, is there a way to manage it without creating rooms ? I'd like to keep a list of available player looking for a match and create a room only if two of them "match". Is this a normal behaviour?

Can we create a room with only 1 player for when the player connects to deal with custom account logic without having to implement JS code or to host our own account server logic ?

Anyway it seems we at least need to add Playfab SDK to our unity project.

Lot's of questions :)

Cheers

Custom Game Servers

10 |1200

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

Answer 1 · 2016-10-21T20:41:44Z

brendan answered Oct 21, '16

Ah, I see. Yes, you can certainly use Matchmake from one client to create the game session, then have others join it. Again, setting up the Game Mode to start the game session closed would allow you to do this. However, I do need to point out that in this model, a hacked client could start new session instances via the StartGame call, without going through your matchmaker. We give you the ability to disable the client's ability to start game sessions specifically to avoid this scenario.

For slots, your game mode defines how many slots are available in a session instance. You can query for the users in sessions and the available slots via Client/GetCurrentGames. And you can get what session a friend is in via GetFriendsList. The design is so that you can control the specifics of how players join games - friends, sessions, random, or whatever else you can come up with. But the key is that you can start sessions as "closed" so that you can more specifically control who joins each session. But to be clear, the ticket our matchmaker returns actually is for a reserved slot on the server. It expires after two minutes, but during that time, that particular slot is reserved for that player. And in the scenario I described above, where you give each player a crypto token to join the server, that would also effectively allow you to reserve slots for the specific players (and would close the door to any hacks to try to join sessions, and take care of any concurrency concerns).

Our game wrangler doesn't grab the logs from servers until the server executable ends. But that said, it's valuable to "swap" the active server every now and then, to make sure that you don't run into any issues (should you happen to have a minor memory leak, and to protect you from losing all the data should the AWS server fail - which is rare, but does occasionally happen). But yes, I would definitely recommend having each instance of your game server host many "sub-games", since the games have few players.

10 |1200

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

question