Virtual Currencies – a primer

Holding real money value in games is either extremely simple, some what complex, or You Are Asking For Trouble. One of the three.

The extremely simple paradigm is allow people to buy a virtual currency, and that virtual currency does not a) shift in value and b) can ONLY be used to purchase in game items. B) is obvious – you can buy skins in the hunting game and with those skins, you can buy ammo and binocs and better weapons and so on.
In terms of a), that’s slightly more complex, because if you shift the cost of an item for a period of time, you are actually changing the value of the currency they bought. So if on day 1 Binocs cost 10 skins, then you decide to run a discount on day 2 for the Binocs to cost 5 skins, then what you’ve actually done is change the value of what the skins currency will buy you.
Now it doesn’t strictly speaking matter, because the transaction is done, and even tracking this devaluation can get very very complicated if you have 20 things that you can buy with this currency and you run specials on 3 of them – tracking exactly how much you’ve devalued the currency can get tricky. It can get tricky anyway if you have several currency value packs to buy – e.g. $1 gets you 10 skins, $2 gets you 25 and $5 gets you 150. At that point the real money to virtual currency relationship is not constant anyway.

And, like I said, it doesn’t really matter anyway – there’s no use to which you need or can put that information anyway.

Then there’s the slightly more complex version of this – and that’s where you share currency across different games. This kind of currency needs to stored at a server level. The idea being the currency is stored at the account level, and you can use it across different games. Gree has this functionality and DeNA is working towards it.

The problem with this approach is it means your currency value needs to be maintained and balanced in scale across all games. For example, if game A uses 10 skins to buy Binocs but game B uses 7000 to buy ammo, then your scale is completely out of wack.

Then it gets more complicated still if you can earn currency in game or by 3rd party portal. Earning currency in game is pretty obvious – I shoot 5 animals, I get 5 skins. You can also earn currency by 3rd party portals. This works basically by you going into an ad portal like Tapjoy, and assigning value to users clicking on ads in your game – so if they click the ad in game, they are awarded X skins for doing so. Obviously you are just awarding those skins on your end for nothing, but remember the ad portal is paying you real money for the click through. Most ad portals that offer this feature allow you to set the currency value at their end, and they offer an API that communicates with your game to tell you that a user has done something that generates in game currency, and you can add to it.
NOTE – Apple does NOT like this functionality and will ban you if you implement it on a game on Itunes. We have to comment out this ability on our IOS games.

There’s also the relatively complex issue of deferred cost liability that can arrive here. Most of the time video games such as the like we make will never have this problem, but the larger you are, and the larger you fan base, the more this actually becomes something you have to track.
So what is “deferred cost liability”? Well, its like this. If I buy virtual currency, I, the gamer, pay you, the developer $1 for 10 skins. Now that transaction is done. You bank the money and we are done. But, those 10 skins are now out there, and have not been redeemed against anything. What if it costs you, the developer, when I do redeem them? That average cost of that redemption is “deferred cost liability” – the act of me buying those skins created this, whether or not it’s ever incurred.

To put it another way, think or Virtual Currency as Olive Garden Gift cards. When I buy the card, I give Olive Garden $30 for the gift card. They bank the money, thank you very much. But when I _use_ that gift card, it’s going to cost Olive Garden the cost of my meal I use it for. Now, the cost of that meal isn’t costing Olive Garden $30 – more like $15. $30 is what they’d charge me, not what it actually costs to put it on my plate. So the deferred liability for that gift card is $15. When I bought that card from Olive Garden, they made $30, but they also generated a $15 cost that may well happen down the line. But what makes it more complex still is that a percentage of gift cards will NEVER be redeemed. Lets say only 80% of gift cards bought are used. That means the deferred liability cost per gift card is now 80% of $15.
However, you cannot _really_ know either what meal someone is going to buy with the gift card – to know that the deferred cost _is_ actually $15, nor can you know what the percentage of redemption is going to be. Both are estimates and as such, prone to being wrong.

In video game terms, you have to look at what it costs a video game developer if someone uses some of their virtual currency. If they simply buying Binoculars, well, that’s zero cost to you. Indeed, most IAP is going to be that way. But if they are now downloading DLC data from your server, well, now you have the cost of them using your server – downloads are not free. So how do you calculate that? If you have a large enough user base, it starts to get easier (or at least more predictable), but for smaller games, well, it’s harder. Not that most games will even care – you pay for the dlc server in a bulk amount, it comes out of the games profits, you move on. But for larger corporations, deferred costs can be large and scary and you generally want them to be predicted to be as low as possible – there are tax implications from having a large amount of unsecured debt coming down the line that you aren’t aware of.

You can also usually do things like either gift currency or items bought with the currency to other players. This generally doesn’t affect currency value and is just a nice feature – but the next feature you can offer does affect value.

Allowing the user to sell items. The moment you add this feature, you’ve now created an economy that you don’t 100% control. Up till now, you, the developer, have complete control over what currency is actually worth. It costs this amount and buys that item for that amount. Done and dusted.

But the moment you allow users to sell items on their own auction block, the actual value of the item (and hence the value of the currency) is no longer in your control. The Item Costs X equation now goes out the window, because users can set their own prices (Oh, you can force them to use the same prices as your store does, but at that point, unless the item is extremely rare, all you are really doing is shuffling around who gets the money – you aren’t affecting value or giving players a _reason_ to sell anything).

At that point, currency and item speculation can start happening, and the value of your currency changes. And the only way you, as a developer, can affect this is by affecting how much currency goes into the market. But how do you do that, if people can just buy the currency in the first place? You have no bank interest rates to vary, since no one is lending anything in your game. The only way you can really do it is limiting the amount of currency people can buy and changing the ratios of what people can earn in world.

Then you’ve got the cross platform issue that you might or might not want to do – I buy virtual currency on Android, can I use that on IOS? Strictly speaking, there is no one to one correspondence on currency to dollar value, so it’s not like Apple can track exactly what 30% they missed out on by you not using their IAP system. However, while it is technically permissable right now – there are some restrictions on it, but it’s not been very clear policy wise what these restrictions are (I hear different things from different people about what their experiences have been when they ask Apple.), it’s not a wise bet to make. If you make this kind of system and then Apple suddenly decides that no, you shouldn’t be allowed to do that, what do you do? How would you split the currency value that you have as a player across two platforms? The only way to do this is to track what is bought on which platform from the start, so if you need to suddenly split currency availability based on platform – Gree does this.
It’s a very unclear situation and one fraught with Apple suddenly getting The Hump.

So it can get quite messy in terms of managing your Economy. Second Life had two full time guys doing this, with a myriad of tools at their disposal to determine what was going on in world and what they might be able to do about it.

Honestly though, at this point, unless you are farmville, it’s extremely unlikely that anyone is going to get to this point of economy manipulation.

But then we get to the really scary part. When you can take virtual currency out and convert that to real money.

This is where Second Life is above what almost anyone else does in virtual worlds and virtual currencies. At this point, you are actually a complete economy, and you have to start dealing with all the implications that come with that. For example, you have to deal with The Mob, who will use your system as a money laundering operation. This happened to Second Life, and they have a whole suite of tools to track this stuff, as well as ongoing liaisons with the FBI and the treasury. They ended up limiting the amount of money you can take out of Second Life to the same rules as an ATM – $300 a day max, and even then only if you’ve provided proved credentials.

At this point you are basically operating as a bank – carrying a balance that is transmutable into real world funds – (much like paypal does) and strictly speaking you should be under the banking authorities. But, like Paypal, banks aren’t enforcing this and neither are the feds. Another hole in the banking laws.

If you allow multiple currencies to buy into your system, you also have to deal with currency speculators. I buy virtual currency with Canadian dollars, then sell in Francs, because the exchange rate works for me. Remember, your cost to currency value has to be set externally, and you have to decide which is your anchor currency – ie which one you set the absolute Virtual Currency Value to Real Currency (e.g. 10 skins = $1) and then all the rest will fluctuate based on their currency-to-the-dollar ratio, which changes daily (or hourly in some cases).

As if that’s not enough, then you have to deal with taxation. When and where are your users taxed? Are they taxed using Virtual Currency when they buy something? In which case, how do you work out what that virtual currency is actually worth at that precise moment? And worse still, which real currency are they taxed in? If I’m in France, I do business on a server in the US, who’s tax juridstiction am I in? Both countries will argue “theirs” because both wants the revenue. What do you do then?
Do you tax someone purely on when they take money out of the virtual world? Again, am I being taxed in the country who owns the currency I take out in? If I am in Spain, and I work in Pesos, but I take the money out in Euros, who is taxing me, and where? And if the taxing is taking place outside of MY country, how is that other country going to enforce it? Or even have the mechanism to do it?

You can see how messy that gets. I built an international billing system for Second Life and ran into all these issues – the Fed in the US desperately wants to tax virtual worlds, but can’t figure out how to do it, when effectively the Linden $ is a global currency. None of the countries can, so when I left, nothing was being done. Every 2 or 3 months the Feds would come to Linden Lab with a “new Plan” for taxation, and we’d pick holes in it, send it back and they’d go back to the drawing board.

Sorry – big assed post there. For most game developers, 90% of this is not something to worry about, and if it does become important (like deferred cost liability tracking), you’ll be large enough to pay someone to do it.

This entry was posted in Game Development, MicroTransactions. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>