Is PlayFab (and its Player Entity Data system) able to support my city builder game?
Hi!
I've been poking around the forum for answers, but I thought that it might be easiest to lay out some high level requirements and get answers to the questions:
- What would be the best approach to fulfill these requirements?
- Can PlayFab support these requirements, or are they too taxing?
- Are there any plugins/addons (Azure or otherwise) which could make this feasible
Brendan's answer 4B seemed to be the best relevant match I could find in the forums so far:
https://community.playfab.com/answers/12288/view.html
Not sure if the 1000 Byte player entity object data size limit is a "demo-only" constraint (is it more for paying accounts?), or if it applies to each object vs all objects totalled. If it's totalled across all objects for a given player, that could be a pretty tricky constraint.
Anyhoo, here is the high level jist of it:
- City builder
- Each player has N maps/levels. These are proc-genned, so not just canned entities that are linked to player profiles
- Individual buildings on each map have timers (need to track timestamps) for when their construction is complete, and for actions that can be taken on each building (recruit, farm, etc).
- In a session, a player could view their city, and for each building that is READY (N), trigger an action which may change resource totals and set a new READY timestamp
I did a quick test via the dashboard and found that the 1000byte limit is for each object. So that mystery is solved at least.
Best Answer
To be clear, Title player account(Entity) can store up to 5 Object(s) at a size of 1000 bytes.
PlayFab has three ways to store data which are Entity Files, Entity Objects and Player Data. In the common scenario, we use Player Data for the most time. For data with big size and don’t change frequently, we suggest you to use Entity Files. For data you want to control the access policy, you can use Entity Objects.
Player Data has three different types which are Player Data, Read Only Data and Internal Data. This document describes their differences. And it has a larger value size(300000 bytes). Please navigate to [Game Manager]-[Title settings]-[limits] to check the limits' info.
>>Each player has N maps/levels. These are proc-genned, so not just canned entities that are linked to player profiles
I assume these data are generated by progress, and won’t change frequently. So you can use Entity Files.
>>In a session, a player could view their city, and for each building that is READY (N), trigger an action which may change resource totals and set a new READY timestamp
You can implement a CloudScript/AzureFunction(CSAF) to modify the data. The advantage of this is that you can verify the request and avoid cheating.
And it has a larger value size(300000 bytes)
I assume that the 300000 byte limit is the max size of the player entity, including all the different types of associated data? So to best use those 300000 bytes, we'd need to chop up and our data between public KVP's, read-only KVP's, server KVP's, data files and data objects? Let me know if I'm off here.
>>Each player has N maps/levels. These are proc-genned, so not just canned entities that are linked to player profiles
I assume these data are generated by progress, and won’t change frequently. So you can use Entity Files.
Entity Files should work for the base size and layout of maps, but the contents of maps will change frequently. It wouldn't make sense to save buildings (of various types) and their timers in an Entity File, would it?
>>300000-byte limit
It is the limit for a single value for a key. You can have multiple keys for a player.
>>contents of maps will change frequently.
We recommend storing the large and basic data as Files, while storing those upgrades, modification data in Player Data.
Wow! I didn't believe you when you said it applied per/key, but I did a quick test via the dashboard and that seems to check out.
So if I wanted to save a large amount of data (such as the dynamic parts of a map including timestamps and whatnot), it would be better to encode it and shove it in a KVP than to use a relatively shrimpy data object?
I feel like I am missing something here. Why would I ever want to use Player entity objects over saving everything in encoded KVP strings? What are common use cases and advantages of using entity objects?
