In app purchase to remove ads and unlock full game.

gfb08174

This topic has been discussed various times in different threads, but the URLs, cookbook links, downloads, videos, etc which help to answer the question have expired, been deleted, moved, or no longer exist.

What I'm looking to do for this iPhone game:

• Allow the user to play 3 levels for free, with banner ads showing on top. When it's time to move to level 4, an in app purchase will appear.

• I created a boolean, game.HideAds . When false, the banner ad will show.

• I created a 320x50 actor on the top of the page all three levels where the ad banner will show (is this the correct way to do it???). I set it up in a rule which says:

   when game.HideAds is false
            show banner (320x50, position: top)
  

• After winning level 3, I prompted the "buy item" in app purchase. The set up:

      When game.levelFour is true and game.HideAds is false
          In App Purchase - Buy Item
  

I would then like to change game.HideAds to true, when the player purchases the iap, so as to remove ads, and unlock the remaining levels. The only way to do this is in the "deprecated" in app purchase, but from what I've read in the forum I have to stay away from that.

There are 6 different in app purchase behaviors in GameSalad, and to be honest, I haven't found a thorough and clear explanation of each.

Can somebody settle this, step by step, ONCE AND FOR ALL. How do I set up in app purchases to remove banner ads, and unlock the full game? Which in app behavior do I use, and what are the steps?

Dues

Check this out

gfb08174

@Dues

Thanks for that. I set mine up differently using the he deprecated in app purchase behavior. In the video he says it no longer works. Is that right?

pHghost

@gfb08174 said:
Dues

I set mine up differently using the deprecated...

Since they were deprecated, they very likely do not work, yes.

pHghost

@GeorgeGS is that so? If yes, wouldn't it be better to remove the old behaviors from GS, so it doesn't confuse people?

The_Gamesalad_Guru

@pHghost said:
GeorgeGS is that so? If yes, wouldn't it be better to remove the old behaviors from GS, so it doesn't confuse people?

I imagine he is using an old version to get around the 15 day trial limit. There is no reason to be using a version 6 months old. apple changed their system sometime ago. I made this video because everyone needed to update their games with the new system.

pHghost

@The_Gamesalad_Guru said:
I imagine he is using an old version to get around the 15 day trial limit. There is no reason to be using a version 6 months old. apple changed their system sometime ago. I made this video because everyone needed to update their games with the new system.

Wow, that would have to be a REALLY old version. Plus, he wouldn't have access to ad behaviors as a non-pro, in the older version either, or was that different some years back?

In any case, the deprecated methods are still present in 13.30, I suppose unnecessarily, and could confuse some, especially new users whose English isn't the strongest, as they might not understand what deprecated really means.

gfb08174

@The_Gamesalad_Guru

I am using the new version with the 14 day trial, the old behavior is still available.

This is what would show when I used the deprecated iap behavior: http://imgur.com/8DIaYhH

This is what shows up when I follow the steps in the above video: http://imgur.com/a/ueiLX

I'm also confused about where I should place the "request purchase data" behavior, and the callback attribute (I made it a game attribute, not a self attribute).

The old one was easier to understand and worked fine, as far as I could tell. The newer version doesn't look right. What am I doing wrong?

This is how I coded it:

http://imgur.com/a/lv7mQ

gfb08174

@The_Gamesalad_Guru @pHghost

I'm using version 0.13.30 beta

The_Gamesalad_Guru

The only reason not to use a game attribute is becuase game attributes are always scanned and add to your code as where a self is only part of the code scan when the actor is on a scene.

gfb08174

@The_Gamesalad_Guru

This game I'm putting together has 10 "sub games", with each "sub game" having around 50 levels within.

I want to offer a free trial which allows gamers to play four levels of each "sub game". When they're done with level four, and click on the "next" button to move to level five, the iap fires up.

A self attribute would mean having to code every single "next level" actor in the "sub game". Doesn't a game attribute just make that a whole lot easier?

The_Gamesalad_Guru

You can do a prototype actor and use self attributes to monitor the level and change scene without breaking the prototype.

gfb08174

So naming the self attribute the same thing across the entire game in all the "next level" buttons will not have any negative affect whatsoever?

They're all programmed to trigger on game 4 anyways, so couldn't I just duplicate those behaviors in each actor throughout?

Another thing I forgot to mention is that this new iap does not allow me to "success" "failure" or "cancel" a purchase like the old one. How can I simulate that in the viewer?

Thunder_Child

@The_Gamesalad_Guru said:
The only reason not to use a game attribute is becuase game attributes are always scanned and add to your code as where a self is only part of the code scan when the actor is on a scene.

Learning something new today I am...

GeorgeGS

@pHghost said:
GeorgeGS is that so? If yes, wouldn't it be better to remove the old behaviors from GS, so it doesn't confuse people?

As far as I know, removing them completely would break loading of older projects that used them. We could do a better job making them harder to use in new projects though. I'll add it to the list.