Handling server-side accounts

Hello,

I'm looking to add the back-end networking to my game and I'm completely lost. I can do match-making via Photon, however when it comes time to create accounts and store global game information, as well as potentially creating a true middle-man in matching players via rating and such I am just kind of lost as to where to start. I have a bit of experience in mysql from doing access databases for work, but that's about it.

So a few questions:
#1, Do I need to use photon as well as some master-server for logins? Is that a bad practice?
#2, What's a good host for a master-server for testing if I don't need major bandwidth?
#3, What are best practices, etc, especially on security end? I know you're supposed to make a PHP post to the masterserver, but I do not know like how I'd store in-game currency, decklists/library (its a card game), etc other than just making a new category within that table. Is it really that straight forward?

Any tutorials on the subject (especially on game-design) would be great!

 

First get your facts straight by doing research. The Master-server does not handle logins.
If you do need a master-server togheter with Photon ( I have no clue why ) just compile it and run it on your own computer for testing.

Eh no, a server instance needs to announce that it hosts a game to the master-server.
So start reading in the Manual what a master-server can and can not do.

 

I don't think he was talking about the Unity master server, just master servers in general...

The bottom line is that if you need a central server tracking player IDs and attributes, then you need a host and some server software to run on it. You could write the software yourself (e.g. a web service running on a regular web host), or use something like Gamespy or Player.IO, both of which support scalable server-side storage and also provide the servers, so you don't have to.

 

What are master servers in general ? A central server tracking transforms or whatever is just a server since all others are clients.

 

gfoot was right -- my terminology is wrong. I'm using photon at the moment instead of unity's master server. I'd like add to that system now by having a way to hold information globally rather than locally in playerprefs. However, information past "well this is how you do a login-server!" is quite thin -- I understand how to send/retrieve logins from a mysql database hosted elsewhere, and maybe basic information that's just tied to your login info, but after that point I'm just overwhelemed.

@gfoot, I'm checking out Player.IO now, it seems to be like a good solution (and even better, free for my small-scale tests) at least to start with. Thank you!

 

I am quite new to Photon/network programming as well but I recently went through some of the same thoughts you are having. In the end I created a SubServer that talked to my MasterServer. When ever the game detected that the user was in account creation/login state, the Master server handed off the client to the Subserver(Login Server). That Subserver was the one handling all the account creation and login information. It sent the information to a MySQL database for storage and retrieved what ever information was necessary. When finished, the relevant information would be handed back to the MasterServer along with the client, then communication between the servers would be terminated.

I personally went this route due to concerns about people trying to hack the login with repeated attempts. If this was happening on a larger volume, it could potentially slow down the game and cause lag for the players who were already logged in. Everything being said, I am not sure myself if everything is done correctly as this is my first time building something of this size.

-Dane