question

Adam Mann avatar image
Adam Mann asked

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:

  1. City builder
  2. Each player has N maps/levels. These are proc-genned, so not just canned entities that are linked to player profiles
  3. 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).
  4. 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
Player Datadataentities
1 comment
10 |1200

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

Adam Mann avatar image Adam Mann commented ·

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.

0 Likes 0 ·

1 Answer

·
Gosen Gao avatar image
Gosen Gao answered

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.

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.

Adam Mann avatar image Adam Mann commented ·

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?

0 Likes 0 ·
Seth Du avatar image Seth Du ♦ Adam Mann commented ·

>>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.

0 Likes 0 ·
Adam Mann avatar image Adam Mann Seth Du ♦ commented ·

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?

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.

Error rendering WebPanel (widgets/consolidation-widget.ftl): org.hibernate.hql.internal.ast.QuerySyntaxException: AvailableConsolidation is not mapped [from AvailableConsolidation up where up.node = :node]