Discussion Non-Consumable products (many) - Design pattern

Hi everyone,

I'm at the process of integrating IAP, and I came across with the following case.
In my game, I have many characters (>20) which each can be upgraded (leveled up) and 3 powerUps which also can be upgraded.

In my initial designs I was thinking that I would consider as IAP with real currency only gems, and with these gems you would do any other internal transaction, without having to call external Stores(google, ios etc)

But I understand, that these kind of products need to be non-consumable, but they are a lot.
Do you have to suggest any design pattern on how to catalog them, maintain etc?
Is it as simple as having to adding all in the catalog? (example 20 characters * 5 levels would be 100 entries)

 

If you are referring to your characters in this sentence, then in fact they do not need to be of any type, since they would not "exist" in your store. They would be "virtual purchases" in your game that consume currency and not actual products.

As mentioned above, if you decide to go the "real currency only gems" route you would not add any characters as in-app purchases / products but implement your own system. You can have a look at my asset Simple IAP System for inspiration which offers real and virtual purchases.

 

Thanks for the response!

Well, the problem with characters not being of any type, and purchasing them with ingame currency, is that they cannot be restored (switching devices)
So I am not sure if this is a violation

 

That is true, at least when you are trying to do so from an App Store. You would still be able to save game states via PlayFab, Firebase (cross platform), or Google Play Games Services and similar services.

It is not, for example Crossy Roads does the same thing, but allows users persisting their characters online.

It depends a bit on your preferences. Would you want to have users buy a pack of currency and then (frictionless) in-game purchases, but offer them a login method to persist their purchases, or rather have them do multiple separate purchases all showing up on their credit cards and manage hundreds of products on the App Store? Even though the latter does sound a bit less favored, it would also allow you to have sales for specific characters at any time, without having to update your app.

 

Hi @nksG

My latest project has a similar situation. Initially it only has a few products, but over its lifetime this could increase to many dozens.

So the project has been designed to allow for future growth in the following manner...

1) Create one dummy product. This serves no purpose other than for initialisation (as Unity Purchasing needs one product to initialise successfully). It can't be purchased and unlocks nothing.

2) Initialise Unity Purchasing with this product (using the Builder)

3) Additional products are then added with FetchAdditionalProducts (using the Controller). This method is async and will work away in the background, either reporting a success or failure with callbacks.

https://docs.unity3d.com/Packages/c...al/UnityIAPFetchingProductsIncrementally.html

This means it's possible to initialise Purchasing quickly, whist the actual products are loaded\refreshed in the background. Obviously the game won't be able to process any purchases until FetchAdditionalProducts has completed.

Caveat...

I've designed the game this way, but have only tested it in the editor with a few products. So nowhere near representative of dozens of products or with an actual platform store.

But that approach (or something similar) is definitely worth looking into imo.