For example i have a game with a high volume of customers and a shop. Each customer that finishes buying has to make a call to a function so that currency can be updated depending on what he bought. That means the calls will be very often, like sometimes a couple times per second, for each customer. On top of that of course there will be other calls for other functions. I am wondering if this is ok so i can implement this, or its too often.
We apply client call rate throttling when a single client exceeds what we consider normal behavior. Normal behavior can include occasional bursts of activity (at match end, for instance). What we tend to care about is sustained high call rates.
The burst rate we allow right now is 100 client API calls in 2 minutes. If all of those are cloud script, though, you're going to run into stricter throttling, as cloud script uses additional resources that are shared between all titles. In the case you describe, I'd strongly consider consolidating item purchase-related activity into a single cloud script function and having the client provide a full list of transactions to process.
Thank you for the answer. I think i didn't explain this correctly. I am talking about an actual market with npcs, not real players. Like a supermarket tycoon.
So, an npc goes to multiple random shelves and then to the register to pay for everything he chose. And i am trying to do this in a non-intrusive way so i will not exceed some limits, considering there will be a lot npcs for high-level shops. (Take idle supermarket tycoon on play store for example). I wanted to call a script once when the npc spawns that calculates what he buys and then again when he pays for everything, so twice per npc
4 People are following this question.
