Search Unity

Question Economy vs Cloud Save costs and use

Discussion in 'Unity Gaming Services General Discussion' started by danielalindan, Aug 18, 2022.

  1. danielalindan

    danielalindan

    Joined:
    Aug 15, 2017
    Posts:
    3
    The Economy cost per write operation is 14 times that of the Cloud Save (0.35 vs 0.025).

    I think that 0.035/10000 writes can become significant in a game with many item transactions, like a typical RPG, where a player continuously finds and uses items. Or imagine visiting a vendor, where the player buys, sells, and crafts items.

    What would be the downside of moving the player inventory from Economy to Cloud Save?
    (I understand that some custom logic has to be written, either on the client or in Cloud Code scripts)

    or, in other words:

    Why would anyone choose to use Economy to store a large player inventory?
     
  2. Laurie-Unity

    Laurie-Unity

    Unity Technologies

    Joined:
    Mar 5, 2020
    Posts:
    220
    Hi Daniel,

    Thanks for sharing your thoughts on this, we really appreciate and value your feedback.

    The scenarios you describe, that require large volumes of frequent Economy transactions, are challenging and it is something we have been investigating. Would the addition of Inventory batch methods that allowed you to add or remove multiple items in a single call help you? This would let you implement your own caching and lazy syncronization strategy.

    You ask about offloading the inventory storage to Cloud Save and you absolutely could do this, the downside is that you have to write a bunch of code to handle it and you end up with bits of your economy stored in one place and some of it stored elsewhere. A better option might be to use the Custom JSON data on Economy Item Instances to store the state of multiple child items (instead of Cloud Save)

    Using your RPG example. If you were to define a backpack as an item and give the player one, it could have its own custom configuration data that defined the number of slots it contained, max weight etc.. then you could store the contents and handle item stacking in the individual item instance's custom JSON data. Following this approach you could create create additional items like Large Backpack, Storage Chest etc.. with improved capabilities and even set them up as virtual purchases for the player to upgrade to. That way your player may have one backpack and a storage chest in their inventory, these each store their own contents in their instance custom JSON data, are cached locally by your code and are synched with the Economy API on game start, end and on significant ingame occurences like store visists, level changes etc.. This approach would reduce your Economy API calls significantly and still let you keep all the data within Economy and therefore benefit from other Economy features like the Virtual Purchase (storage chest example) and the ability use Game Overrides and the Dashboard to manage and refine your Economy at runtime.

    I hope that helps. I don't have anything concrete to share with you at the moment, but I will be sure to update the forum as soon as I have any news on features, documentation or samples that will help with some of these more intensive use cases.
     
  3. xjjon

    xjjon

    Joined:
    Apr 15, 2016
    Posts:
    612
    A batch API is definitely useful. We currently use this for PlayFab and it cuts down a ton of API calls for actions like opening a loot box that grants multiple items. (or opening multiple boxes at the same time).

    I do agree with the sentiment that economy API is quite expensive. The cloud code is expensive as well. To be honest I feel the APIs across the board are expensive but economy is the most useful. We currently don't use UGS but have been considering trying it out for a new game.

    The pricing models are obviously different but it's a big difference (5x~):

    Playfab economy: $0.065 / 10000 writes
    UGS: $0.35 / 10000 writes

    For APIs like cloud code it's an even bigger difference in pricing

    playfab : $0.20 / million invoke
    UGS: $1.5 / million invoke

    Things like CDN/cloud save are more expensive as well but they are less of a draw when looking at live game services it's trivial to manage your own cloud storage at much lower cost. Even though we use playfab extensively, we still offload larger player files and content to other storage on firebase and S3 as it is much cheaper.

    The biggest benefit to things like playfab/UGS is having player profile, economy, and social linked in 1 backend, but these are all high volume actions so we are sensitive to the pricing.
     
  4. Laurie-Unity

    Laurie-Unity

    Unity Technologies

    Joined:
    Mar 5, 2020
    Posts:
    220
    Hi Jon,

    Thanks for all the additional detail and validating that a batch API would be a worthwhile addition. We really value your feedback, it will help us to improve the product.
     
  5. danielalindan

    danielalindan

    Joined:
    Aug 15, 2017
    Posts:
    3
    Hi Laurie,

    A batch method for economy calls is essential. Likely a lot of developers expect that it exists.

    Thank you for taking the time to spell out the Custom JSON data example. It's a neat trick. Together with batch calls, it would cover most reasonable cases for an RPG, like chests and vendors.

    I assume that using frequent small calls to a service like find item / use item is not a good model in general to store player data.

    Overall, my feedback on UGS is this:
    I feel UGS is better structured and more accessible for beginners than playfab and gamesparks. I also like how the client code ends up looking, compared to the other services I used.

    However, Economy is nowhere near competitive and I can't imagine experienced users or studios going with it, which is regrettable because it has all those great features.
     
  6. Laurie-Unity

    Laurie-Unity

    Unity Technologies

    Joined:
    Mar 5, 2020
    Posts:
    220
    Hi Daniel,

    Thanks for confirming your thoughts on a batch method and the additional feedback, I've shared it with the rest of the team.