IAP
Monkey Forums/Monkey Programming/IAP
| ||
| Han anyone dabbled with IAPs? It there a multi-target module somewhere? Any guide on how to implement it? I'm thinking about this for a quick game I'm doing, but I really don't want to take ages to implement this kind of stuff... just to see that I need a version of this for every store my game will be (one for google play, another for amazon, another for samsung...) it screams headache for me =/ I have also seen some games that sells 'coins + no ads'... how come? Shouldn't you implement separately consumables from 'one-time' purchases? I'm completely lost on this subject :( |
| ||
| *double clicked update* :) |
| ||
| Yeah there are implementations around but probably not for all stores, and you probably will need to do and test each IAP target individually. Only testing and setting things up is quite a project. If we count the hours it would take to learn about the IAP system and then implement it - you'll probably find that you can make several games in the same time. So unless you are really skilled at IAP programming and terrible at game programing it might be a good idea to stack up on painkillers ;) However if you have many years of publishing apps and adding IAP for each of the stores then doing it in monkey will probably not be much of an overhead, should be simple. Apple require you to allow users to "restor" IAPs if the IAP is not consumable, goggle has an API that takes care of this that they released 2013 (v3). And so consumable IAPs are usually easier to deal with, I could only guess that could be one of many reasons why someone would bundle them together. It is said in a really good game you can get a few % higher monetization using IAP then other forms such as video/ads. However if you do a smaller game and spend 70% of the development time adding IAP instead of adding quality value it is probably not a very good, at least that is my experience! :) |
| ||
| I work on a module but that will still need some more time. |
| ||
| However if you do a smaller game and spend 70% of the development time adding IAP instead of adding quality value it is probably not a very good, at least that is my experience! :) That's not the issue :) I'm planning how the game will be (I'm actually prototyping it), so I need to decide if I'm going for IAP or not. I tried looking at Google play's IAPs yesterday and it's a *lot* of text to read. And I expect things on Apple's side to be even worse :( The worst part is I don't even know how to start to interface those things with Monkey - as in a new target or a module - adding it after "the code is done, on the generated translation" isn't an option :/ |
| ||
| I do it. I'll start with Android which looks way more straightforward and is more natural for me. |
| ||
| You could try the payment module from bono framework. That is what I am using right now for a game that needs in-app purchase on android and iOS, and it works very nice and it's simple to use. |
| ||
| bono of course takes some finagling to get working, and don't even think about trying it on v67 or higher unless you modify the native code. Nope, it's been a month without so much as a commit.... |
| ||
| I've used it for a project with v69 and it works pretty good. You don't need to modify mojo or your app's native code, just including some libraries and importing StoreKit.framework on the XCode Project. Of course it's not a clean way but It will save you a lot of time, al least it did for me. |
| ||
| What is the difference between the bono framework and Anawiki's IAP Module which is used in New Star Soccer and which Si posted an in-depth guide/how-to for here. Do both methods still work, and does one have any advantages over the other? Without testing either I think I would go with Anawiki's module as it has been used in such a succesful game without any major issues, and I assume still works without problems in NSS for it's IAP stuff. |
   |