Micropayments

BlitzMax Forums/BlitzMax Programming/Micropayments

Bremer(Posted 2012) [#1]
I have been thinking about micropayments lately as in where you provide people with the game for free and if they are happy with whatever content is there they can play as much as they like for free. But if they want more or want advantages that will make the game more enjoyable for them they can do so by paying a small fee. This is heavyly used on the mobile platform, but I am thinking about this for pc/mac/linux games.

So lets say that you have a game where you wanted to let people expand the content of the game by way of micropayments, or even just gain advantages within the game like items, lives or whatever could be relevant to make them enjoy the game more, how would you implement this into a game made with Bmax?

How would you handle get the actual payments, how would the player get the additional content within the game?

Have anyone done this using Bmax and if so how did you go about it?


SystemError51(Posted 2012) [#2]
Team Fortress 2 does this now. Which it's why it is free-to-play.

I'd say one possible way to achieve this is by splitting the game up into a server and client, where as the server would be linked to a database (and secure bank transaction module of some sorts) that would handle the micro-transaction stuff.

Doing this would not necessarily make your game an MMO - but you will have to have some form of user login and management, so that they will always get the upgrades/items they purchased on top of the free client.

Brucey made MySQL modules that you could use for that purpose. How to go about payments... I'm not sure yet, but I'm pretty sure you could do this by calling php pages that are stored on the server, and supplying parameters... not sure, but something like that.

I have implemented a client-server system where the server does its request by using php pages stored on the same server and evaluating the results of the "$echo".

These are just some pointers... I'm sure it can be done.


ima747(Posted 2012) [#3]
There's plenty of ways to implement this, what is appropriate is highly dependent on the game and how you handle your billing system.

Simple solution, as used in Tribes: Ascend (I've got a post in general about the game if anyone's interested http://www.blitzbasic.com/Community/posts.php?topic=97628) Is to implement a web view in the game to handle purchases. Everything is just handled through a web interface, when the purchase is complete your account syncs with the master servers (it's an online only game so there's always a connection to the servers) and you get your digital goods delivered.

I believe TF2 takes a more sophisticated approach by integrating the purchasing and payment handling system into the game client directly... but then it's written by Valve who wrote steam, which handles the payments so it's not that big a leap for them. While this is nicer for users it's a LOT more work to maintain the store etc. and you have to validate clients more carefully etc.

In the end the things you will need:
1) A server managing accounts. This is used to manage what users have. It would be foolish to skip this and put everything in the users machines, if it's at all popular it would be hacked instantly and bye bye profits.
2) A payment managing service. You could use PayPal, Google, any number of services, it's just a web store in essence.
3) A web server to handle the store. This NEEDS to be secured and encrypted or you could be liable for stolen credit cards and various other things.
4) A web front end for the store. You need to integrate your account server, your payment system and a store front to glue it all together.
5) A way to display the store securely in your game. This could be as simple as bouncing users to a web browser, better would be an embeded web view so it's more natural.
5) A way to communicate between your game and your account server. Your game will need to find out when users have made purchases, notify the server when they want to spend in game currency, etc. This should NOT be done with a direct SQL connection, that requires embedding your security credentials in the app itself which is a huge risk, and also means if there's a glitch somewhere very bad things can happen without you being able to fix it. Always interact with databases through an interface (such as a series of scripts that handle your queries and response output) unless speed is more important than security and reliability (very rare).

That's a basic check list of concepts that need to be addressed. Most of it is server side, and some of it has some potential legal implications (such as liability). It's certainly doable but quite a lot of infrastructure has to be built (or sourced from somewhere else) to make it happen.


Bremer(Posted 2012) [#4]
Thank you for the pointers, they have all been noted. I wonder still if anyone has done something like this with games on the non-mobile marked without using some form of third-party payment api.