question

Hi. i am reviving this thread because I still does not understand the shared group limit :) the 100 key/pair values are obvious. However the limit of 10 shared groups per player ... you said the limit is you create no more than 10 shared groups data object for each player. What the "shared group data object" actualy is? Does that mean that the player can be member of only 10 shared groups? If so it is easily bypassable by using cloudscript to modify data in shared group, isnt it? You does not have to be a member for than.

I am also trying to figure out how many shared groups can a Title have? Can I create a limitless number of shared groups?

What I am trying to figure out is a creation of a game mechanics where players can group up in small groups(like 5-20 players) , attack an enemy(so shared group will contain only amount of damage done be each player) and then after the enemy is dead( the combined amount of damage done by players are higher than enemy health) the players can claim their reward based on damage done. This is all doable new. The only tricky part is the creation of shared groups which should be created on the fly also destroyed/re-cycled once players defeated the enemy. The whole process of killing an enemy could take anything from minutes to days. Also the number of shared groups could be very high, maybe in hundreads. Is this possible to be made using the shared groups and cloudscript?

Well first, I don't recommend adding a player to a Shared Group for most scenarios. Adding a player gives him write access to the SGD, meaning that a hacked client could write whatever it wants. Not all titles are concerned about security on the data, but most do tend to be.

The limit of 10 SGDs per player is actually not tied to players being member of SGDs - rather, it's that the design of the title should be such that each player doesn't generate more than 10 on average. Also, could you let me know where you got the 100 Key/Value pair limit from, though? The default limit for free tier titles is actually 5. To be very transparent, those two limits are not strictly enforced currently. However, they will be in future, so it's best to design for them (though to be clear, we don't make changes that break live titles - we'll work with folks over the limits to get them in compliance). The risk would be a title that exceeds those limits excessively - if that were to be the case, we would have to throttle or otherwise restrict the title, in order to make sure it could not impact others or cause undue costs on the service (again, we'd reach out to work with the developer, in that case).

But that said, your design sounds like it's quite workable in our current system. What I would recommend is starting a ticket with us (using the option on this page), so that we can work through the implementation details with you.