Jump to content


Photo

In-App Purchases (IAP) and content delivery

iap

  • Please log in to reply
1 reply to this topic

#1 abuzzooz

abuzzooz

    GMC Member

  • New Member
  • 2 posts
  • Version:GM:Studio

Posted 13 March 2016 - 06:02 AM

Hi all,

 

I've been trying to figure out what is the best way to deliver content that was purchased by users through my app (iOS).

 

Sorry for the long post, but I want to be as clear as possible.

 

My app is an educational tool to help users master specific mathematical ideas. It is really made up of many "mini games", divided into bundles by topic and age group. Each of these games is focused on explaining and teaching one specific mathematical idea. The users can purchase bundles of games using IAP, in which case these games will be unlocked and made accessible.

 

Googling around, I came across two ways to deliver newly-purchased content to users:

 

  1. Have all the "mini games" coded into the app in the first place (as different rooms), and locked by default.
    • When a user initiates a purchases, the state of the corresponding rooms change to "unlocked".
    • PRO: easy and straightforward.
    • CON: I will be adding new mini games regularly, which would mean that I will need to publish a new version of my main app every time I do that.
    • CON: Ever increasing app size.
  2. Code my mini games in some language-independent format (XML/JSON/etc), and write my main app as a "shell" app that can decipher these files, and build the rooms on the fly.
    • When a user initiates a purchases, the app will download the corresponding game files from my server.
    • PRO: Theoretically, I don't need to ever update my main app again (or at least, update it very infrequently)
    • CON: I need to find a way to design my games (which can be very different from one another) in GML:S, serialize them, and figure out the code to deserialize back into valid rooms.

Does anybody else have experience with the above?

Is there a better way that I haven't figured out?

 

Currently, I'm leaning towards #2. Since GM:S saves games in XML format, I'm trying to reverse engineer this XML, and write some code to read it back and re-construct my game in a separate room. This will save me from doing my own custom serialization. Creating the rooms, and the objects is easy, but reverse-engineering each object's events and actions is not straightforward, and requires lots of trial and error.

 

I looked for documentation on GM's saved gamed XML syntax, but couldn't find any. I wonder if that info can be shared.

 

Thanks everyone. GM:S is an awesome tool.

--Ala


  • 0

#2 Yal

Yal

    Even though the GMC may be gone, our love will prevail eternally

  • Global Moderators
  • 11774 posts
  • Version:GM:Studio

Posted 14 March 2016 - 03:31 PM

I would go for approach #1, personally. You could use the constant updates to improve the user experience or similar based on feedback, and also remove bugs. Getting an excuse to update more often isn't a completely bad thing if it's easy for the users to do.

 

Also, even Nintendo uses this approach in their games, so it's certainly not 'unprofessional' in any way.


  • 0

- The above is my personal opinion and in no way representative of Yoyogames or the GMC, except when explicitly stated -

 

Open this spoiler for my games:

Spoiler

Some useful game engines, music and other resources at affordable prices:

My collection of game resources at itch.io

 

New user? Can't draw but want to look unique? You can request a new avatar in this thread!






Also tagged with one or more of these keywords: iap