Coding and Testing In-App Purchases in Corona – Part 1

Recently, I spent some time updating one of my apps, and spent a lot of time looking over my in-app purchase (IAP) code. Corona makes this very easy to implement, but there are some minor things to watch out for, especially if you are publishing to multiple stores. This page on the Corona site is a valuable resource, and hopefully this post will give you additional information.

Testing, on the other hand, is not as easy as you would think, since each store has their own way of handing this.

In this two part blog, I will outline my recent experiences in coding and testing IAP in Corona. Part one is all about coding IAP using Corona. We will cover testing in Part 2.

Coding for Various Stores
Three Stores, Three Libraries

Let’s configure the Apple, Google, and Amazon stores. First, we need to determine which library to use.

local store = nil
local platform = system.getInfo("targetAppStore")

if platform == "apple" then
    store = require ("store")
elseif platform == "google" then
    store = require("plugin.google.iap.v3")
elseif platform == "amazon" then
    store = require ("plugin.amazon.iap")
end

Easy enough, find the target app store and load the library. Of course, make sure your build.settings file includes the Google and Amazon IAP plugins.

Next, we need to initialize the store library.  If using Composer, the scene:show or scene:create function is probably a good place for this.

if platform == "amazon" then
    store.init(StoreListener)
else
    store.init(platform, StoreListener)
end

Notice the difference?  The Amazon store does not require the store name.

That’s really all you need for set up. Next, let’s cover making purchases. This is also not too hard to code in Corona, but you need to be aware of what is returned to your listener for each store, since it is different. To get you started, we’ll build a simple store listener below.

When a user attempts to make a purchase, you need to let the store know, and you also need to listen for the store’s response.  The following code does this.

local function StoreListener(event)
    local transaction = event.transaction

    if transaction == "purchased" then
        -- successful purchase. Give user what they paid for

    elseif transaction == "cancelled" then
        -- User decided to cancel purchase

    elseif transaction == "failed" then
        -- D'oh, something went wrong. User could not purchase item.
    end

    store.finishTransaction(transaction)
end

-- Enter your purchase string here
local itemToPurchase = "com.mydomain.item"

-- make a purchase
if platform == "apple" then
    store.purchase({itemToPurchase})
else
    store.purchase(itemToPurchase)
end

Notice that the Apple store expects a table of items… even if there is only one. Amazon and Google do not support purchasing multiple items, so we pass in the actual string of the item we wish to purchase.

In the store listener, we are listening for a successful purchase, a cancel, or a failure. It’s up to you to code what you want to do when these events come in.

Notice that we must call finishTransaction to clean up, otherwise the store will not know that the transaction is complete. This is required for Apple, but no harm calling this for all other stores.

Restoring A Purchase

In the event a user had to reinstall your app, or in the event a person upgrades their phone, it’s a good idea to allow a user to restore their purchase. This is usually done when a user taps on a “Restore Purchase” button, and it’s as simple as calling store.restore() and listening for the “restored” event, with one exception. Google does not have a “restored” event. When restoring on the Google Play store, a “purchased” event is returned. So, how do you determine whether the “purchased” event is from a purchase or a restore? Let’s look at our modified store listener:

local function StoreListener(event)
    local transaction = event.transaction

    if transaction == "purchased" then
        if isGoogleRestore then
            -- Restore purchase code goes here
        else
            -- successful purchase. Give user what they paid for
        end

    elseif transaction = "restored" then
        -- Apple or Amazon restore code goes here

    elseif transaction == "cancelled" then
        -- User decided to cancel purchase

    elseif transaction == "failed" then
        -- D'oh, something went wrong. User could not purchase item.
    end

    store.finishTransaction(transaction)
end

-- define this variable 
local isGoogleRestore

-- place this in your restore button handler
if platform == "google then isGoogleRestore = true else isGoogleRestore = false end
store.restore()

Here it gets a bit tricky. For Apple and Amazon, you handle a restore by listening for a “restored” event. For Google, you can set a boolean value (isGoogleRestore) during your restore purchase code and listen for a “purchased” event. In the purchased event of your store listener, determine whether this is a Google restore or a normal Google/Apple/Amazon purchase by checking isGoogleRestore, and handle appropriately.

A Couple of Other Events

Amazon can send a “revoked” event, and Google can send a “refunded” event in cases where refunds were applied. If you listen for these, it’s again up to you to decide how to handle, but it basically involved removing the features that were previously purchased.

Consumables

Consumables are items that can be purchased over and over again (coins, power-ups, etc). You should not and can not restore consumables via the store, but a user can buy these as many times as they want.

Google treats all items as non-consumable (Apple and Amazon allow you to create these items and identify them as consumable in their dashboards). Since non-consumable items can only be purchased once, how do we allow a consumable item to be purchased again?  Easy, with this piece of code:

if platform == "google" then
    -- call this for every consumable item you have in the store
    store.consumePurchase(myConsumableItem)
end

This call may take some time, so I like to place it in my scene:show event (in Composer). You can listen for a “consumed” event in your store listener if you need to do some post-processing. If the user now decides to purchase a consumable item, Google will allow it.

Conclusion

This is the basis of coding IAP in Corona. I did not cover everything (such as loading products), but this should get you going. In a future blog post, we will discuss how to test IAP on each store.

Object Pooling in CoronaSDK

Creating and removing game objects is a very expensive operation. Couple that with enabling and removing physics properties on these objects during game play, and it is no wonder you will notice your game stuttering and lagging during these operations. As more objects are added to the screen, the situation gets worse.

The concept of Object Pooling is something that every new game developer needs to understand. With Object Pooling, you create a set of game objects and configure them as much as you can before the game starts, usually during scene load. During game play, you use and reuse these previously created objects.

Fortunately for Corona developers, creating an object pool is very easy. In this article, we’ll step through this to create a pool of reusable game objects. As an example, I will use one sprite from my game Space Mission: Survival, and I will show you how I create a pool of enemy ships.

Some things to note… for simplicity, I am going to create a pool of static images. In my games, I create my pools using sprite sheets, so I can animate these game objects, but that is outside the scope of this tutorial.

Step 0… Planning

You should determine how you want to pool your game objects. Personally, I like to pool my objects by type, and not mix them.  For example, Space Mission Survival contains an enemy pool and a bullet pool. By keeping them separate, you can manage them easier.  Further, my game contains a bullet pool for the player and a bullet pool that is shared by all enemies, even though the bullet sprite is identical.

Also note that since you are creating a pool of objects, memory will be allocated so try to determine the amount of objects you really need.  For example, if you know you need 50 enemies, create 50 objects, not one hundred.  The extra ones won’t be used, and they will consume memory. In cases where you are not really sure how many you need, you can create extra objects during times where there is little action going on (level starts, info screens, etc).

Step 1… Creation

So, what’s a pool in Corona?  It’s just a table of sprites. Let’s create a pool of enemies:

local maxEnemies = 50
local Enemies = {}

for i = 1, maxEnemies do
    Enemies[i] = display.newImage("enemy.png", 0, 0)
    Enemies[i].isVisible = false
    Enemies[i].isAlive = false

    -- if you need physics on these game objects
    physics.addBody(Enemies[i], "dynamic", params)
    Enemies[i].isBodyActive = false
end

The for loop creates and adds 50 enemies to a table named Enemies, and sets them invisible. Line 7 is a property I added which will keep track of live enemies (enemies currently on the screen).

If you need physics on these game objects, lines 10 and 11 set that up. Line 11 disables any physics checks on this object since it is not alive.

That’s it! This code takes care of the the processor intensive creation of objects that would otherwise slow your game down during game play.

You now have a table of game objects set up with physics, but they are not in the game.  How do you use them?

Step 2 – Use
-- return an available enemy, or nil if there is no enemies left
local function spawnEnemy()
    for i = 1, #Enemies do
        if not Enemies[i].isAlive then
            return Enemies[i]
        end
    end

    -- if we get here, there are no more available enemies in the pool
    return nil
end

-- upon death of enemy, back to the pool
local function killEnemy(enemy)
   enemy.isBodyActive = false
   enemy.isVisible = false
   enemy.isAlive = false
end

-- get enemy from the pool and activate it
local enemy = spawnEnemy()

if enemy ~= nil then
    enemy.x = 100
    enemy.y = 100
    enemy.isVisible = true
    enemy.isAlive = true
    enemy.isBodyActive = true
end

-- do a bunch of stuff in your game and kill enemy when appropriate
killEnemy(enemy)

In the above code, the spawnEnemy function will return a reference to an available enemy in the enemy pool, or nil if one is not available.  The killEnemy function will return the enemy back to the pool.

Step 3 – Clean Up

When done, don’t forget to clean up! Cycle through the pool to remove all event listeners and physics, and don’t forget to nil out the game objects.

Conclusion

Utilizing object pooling is a great way to keep your game responsive and allows you to mange objects by creating and using only what you need. Object reuse keeps your game from having to allocate and release memory by creating the same objects over and over.

This was a basic tutorial on how to get started with object pooling in CoronaSDK. Play around a bit… use sprite sheets to animate pooled objects, or change the sprite of an object. Create a dynamically growing pool in cases where you need more objects than you created. Or, create a generic pooler library to handle creation, deletion, spawning, and removal of all objects in your game.

My Development Shelf

I am sure I am not the only developer with a bunch of ideas, partially developed apps, or proof of concepts “on the shelf”.  For some reason I seem to have quite a few.

  • I recently played around with a few concepts that I could not roll into a game I wanted to develop.  One was a card game, another was some LiquidFun functions.  They are now on the shelf for a later day.
  • I have a game a started 4 or 5 times over the past 3 years.  I think I have the basic idea worked out, but I am still trying to figure out the finer points.  So, it’s been on the shelf for over a year without looking at it.  I really want to finish this one.
  • My recent project, the rewrite of Space Mission Survival, was recently put on the shelf.  I liked where I was in the development process, but decided a rewrite wasn’t going to be enough to get anyone to play the game on the PC or consoles.  It’s been on the shelf for about 2 weeks, but I recently dusted it off and it’s back as my project Du Jour.
Space Mission Survival Off The Shelf

My latest thought is that the rewrite of Space Mission Survival for consoles and PC will be a more high-intense, fast action game with power-ups, multiple enemy types, and multiplayer action.  This is a bit different than my original thought of developing a straight port, but I think its the way to go.  I still love the game play of the current Space Mission Survival, so I think I am going to add this “classic” mode to the new version.  Two… two… two games in one!

Since taking this project off the shelf, I yet again decided to start over (as I always seem to d0), but kept as much code as I could.  Lots of code was reused, but there were instances where new stuff I learned greatly improved ways to do things, thereby reducing code.  InvokeRepeating is awesome, and taking advantage of Mechanim for simple animations is another time saver.  Going to add some particle effects too!

We’ll See

I was planning on using CoronaSDK to develop a bunch of smaller mobile games this year.  I did release one game in January.  The Unity development of Space Mission Survival may impact the development of some Corona projects, but we’ll see.

One of the reasons why some of my apps go back on the shelf is that I am easily discouraged (due to limited feedback) and quick to change gears (finding something new, exciting, and challenging).  Right now I am into developing Space Mission Survival, but we’ll see.

Maybe I’ll pull one of the other things I mentioned off the shelf as well… we’ll see.