The pricing of economy writes is 100x times more than the read, or a cloud save / code write.
I guess its atleast one typo, eventually 2.
[https://unity.com/de/solutions/gaming-services/pricing
If this would be the real pricing we rather use cloud code and cloud save to store the currency.
1 Like
Just for information. The pricing is confirmed to be correct.
We will use Economy for premium currencies only.
And other resources the player can gather / collect, as cloud saves since its cheaper and good enough.
The visible main benefit of of currencies is to use them in conjunction with virtual purchases, which will make purchases simple and save. This might be a good solution for shop like situations but not for price scaling ingame upgrades, as the purchase price and output is fix.
Hi David,
The Economy âwriteâ pricing is not a typo, it is correct, but your calculation on the difference is out by an order of magnitude, it isnât x100, more like x14 on Cloud Save writes.
If you want to handle all the currency and inventory via CloudSave, with your own bespoke methods, in order to save cash, thatâs an entirely viable solution.
However, you wonât have the ability to add these currencies to virtual purchases as well as the âmanagementâ portion of the currency support such as incrementing/decrementing/automatic initialization of currencies etc.
1 Like
Ah right I was taking the free writes as another factor 10x , which isnât correct, your right!
It is 10 times faster to charge you, as it has 10x less free write calls compared to cloud save.
Regarding:
If you want to handle all the currency and inventory via CloudSave, with your own bespoke methods, in order to save cash, thatâs an entirely viable solution.
However, you wonât have the ability to add these currencies to virtual purchases as well as the âmanagementâ portion of the currency support such as incrementing/decrementing/automatic initialization of currencies etc.
Virtual purchases dont fit our needs.
We would need something like âvirtual upgradeâ, as we develop an idle game. Where you do a lot of upgrading / purchasing and the pricing and outcome has to be able to scale. (array of prices or equation based on other cloud save values). And only to use currency for having the increment / decrement build in, is not worth the extra call within our cloud functions. Since we can get up to 20 cloud save values in one api call, having the resource ( âwoodâ in our current example) beeing part of that get / set call appears to be better than doing another economy get / set just for this one value.
This obviously may vary in other projects.
1 Like
Hi David,
Thanks for sharing the additional context and your thoughts, this is great feedback.