Confused about servers
I'm confused about servers. I thought they would just be placeholder chunks to store data for game instances that my players would be joining. Like data only. Watched the video on the servers from the docs, completely lost. Showed a build being uploaded, spun up via PlayFab's EC2 stuff, etc...do I need all that stuff? I can't just have a server as a place to store data for instances of a game or...?
Best Answer
The core PlayFab services run in servers that we manage, and do take care of many of the things you're referring to - in addition to authentication, we have multiple forms of data for you to use depending on the purpose, a full economy system with integrated receipt/entitlement redemption and payment providers (to ensure that it's a full end-to-end system that gets players the digital goods they pay for, but blocks the various hacks that players use to get things without paying for them), automated live operations with Segmentation and A/B testing, and more. None of that requires you to do anything involving a server in any way - you just use our API calls.
So if all you need to do is store data, then you're set - no need to create or run any servers.
The custom game server docs and videos are specifically talking about our server hosting (though now, you can also hook externally hosted servers up, so that you can use our matchmaker with them). That's if you need to run some deeper custom logic, and potentially in many regions. This is common for all multiplayer realtime action games, for example, as well as online card games.
Ahhh OK, so I guess TitleData is what I'm looking for then? I'm using Corona, so I was hoping to upload some basic player info, such as location (x,y), maybe some hitpoints, etc. via JSON to the server. That's it.
All the other stuff I tinkered with (currencies, items, user registration, cloudscript) seems really straight forward, so I'm pretty stoked on that front.
Appreciate the help!
Mario
If you mean default values for all players, then yes, Title Data would be the way to go - that's data which is written to rarely, and which is readable by all players.
If you mean information which is specific to players, then User Data, User Read Only Data, and User Internal Data would be the way to go. Which one would depend upon the use case. Regular User Data can be written to by the client - meaning a hacked client could write anything, so it's only for things that need no security. User Read Only Data can only be read by the client, while User Internal Data cannot even be read by the client. You would use Server API calls (either via Cloud Script or a custom game server) to write to those (and read Internal).
But since you mentioned position and hit points, it's also important to note that you shouldn't be using this for data that changes frequently. If your title has a need to update data in realtime (like position info for a shooter), a custom game server would be the way to go, updating the user data only at key points (or the end of a session).
Hmmmm, I was thinking about async turn based options for saving game states to title data. Have a chunk issued as a savedgame-state each turn uploaded. I mean, I could keep the data super small and compressed, if that would help out. Is there a efficiency issue I'd need to worry about using titledata?
I don't have the skills to "roll my own server", so I might just use DynamoDB on my AWS to store the game states on and push the data out thataway, and use the PlayFab end for the user management, currency and items then.
For async games, that shouldn't be an issue, and you may want to have a look at this thread: https://community.playfab.com/questions/515/207129407-Persistent-turn-based-games-.html. The real question you'll want to think through is what kind of cheat protection you need (and so, how much server authority).
The key for optimizing your title is both the size of the updates and the frequency. Fewer, larger writes are generally more efficient for two reasons: One is that in our current data model, anything under 1,000 bytes is inefficient (and so should be aggregated with other data if possible). The other though, is that there's packet overhead for any send, meaning that if you're sending only 100 bytes of data, a large percentage of your packet cost is the overhead. Packet rates are particularly important for mobile titles to think about, as a high send rate equals more battery drain - which can be noticeable (and annoying) to users.
So now, I noticed that there's no dashboard access to shared group data. Is there no way to query all instances of shared group data created on a server? What happens if I lose the group ID I created it with?
Shared Group Data isn't bound to a single server or player. The recommendation is to store the group IDs for any active games the player has in their User Read Only Data, so that you can access it later. Since there could potentially be millions of Shared Group Data IDs for a game, a query to scrape all of that data would be extremely inefficient. It's possible we may redesign the SGD model in future to provide for this, but right now, it would not be viable.
OK, so I was thinking of a per-customer listing of group data but that's OK. No big. So there's no best practices recommended for housekeeping these group data chunks floating around at the end of the day then? They just kinda end up floating ad-infinitum out there? I can deal with that. Guess the important take-away here is to keep track of the ID of the group data that I create and that's that.
Thanks for the in-depth explanation, and that other article as well. That turn-based method was pretty much line for line of how I was going to implement my logic, so I'm glad to hear I'm on the right track.
-Mario
Yes, the best practice is specifically to use a fixed naming pattern for specific-purpose shared groups, or else record the IDs in user data for the users who need them. Please bear in mind that Shared Group Data was designed for a very narrow need - sharing data between a few players, usually for a fairly transient need.
Yep, I understand the transient nature of the data. In my case it'll be data from a multiplayer game, containing basic data about players locations in a multiplayer game.
Thanks again!
-Mario
