Facebook Credits becoming mandatory for games

So, Facebook announced they’re making the use of Facebook Credits mandatory.

Starting July 1st, we will require all social game developers on the Facebook canvas platform to process payments through Facebook Credits. All developers keep 70% of the revenue from virtual goods transactions using Facebook Credits. Although we are not requiring developers to use Facebook Credits as their sole in-game currency, we are offering special incentives to those who do (see below for details).

What Facebook is saying explicitly is:

  1. Starting July 1st, Facebook Credits must be supported by games, which use the Canvas Page (ie, are embedded inside Facebook)
  2. Facebook Credits does not have to be the only virtual currency used in the game
  3. There will be special promotions to developers who do use Credits as their sole currency

The statement has been worded quite carefully not to include a word about using third party payments at the same time as using the Credits. Also note the wording of always only discussing the 70% share the developer gets from the credits, and never the 30% commission that Facebook takes as part of the processing.

Facebook has however published a document about the incentives they’re putting into place to get developers fully on board. This document lists the criteria for Facebook considering the Credits integration good enough to earn their full support:

  1. Facebook Credits are the game’s premium currency
  2. All virtual goods available for purchase with premium currency are priced in Facebook Credits. However, goods can be available through earned currency
  3. Items are not priced in local currency or another in-game premium currency

Based on this criteria, I’d assume the use of third party payment processors will be allowed for the time being, but having them present will mean your app will not get any special promotion from Facebook. More on this below.

Now, the speculation regarding Facebook Credits in GDC 2010 was that Facebook’s strategy regarding Credits is roughly as follows:

  1. Work a deal with all the big players to drive the adoption
  2. Once sufficient mass is already using the credits, make Credits integration mandatory
  3. Squeeze the rules of how payment integrations are supposed to work, until Credits are the dominant payment mechanism inside Facebook
  4. Disallow the use of third party payment mechanisms for canvas apps altogether

They’ve now made two first steps towards this direction, and the announced incentives are a step into the third.

The counter-argument against Facebook disallowing third party payments has been that US government’s antitrust bodies will not let this happen. While I agree the government would be interested if Facebook did this, I can’t see regulartory bodies interfering given:

  1. The rules only govern games, not all apps,
  2. Facebook doesn’t have a dominant market position on gaming overall, and
  3. The payment mechanisms behind Credits are implemented by third parties, some of which are the ones currently integrated directly by game developers.

So what’s a developer to do? Let’s look at the currently published incentives:

  • Partners who use Facebook Credits as their in-game currency can also receive the following:
  • Drive new installs and re-engagement through increased access to our distribution channels
  • Minimum of 30M impressions on the games dashboard over a month
  • Access to new placements and premium ad targeting • Access to exclusive features such as the user’s credits balance
  • Beta testing new products throughout the year – early adopters have seen significant
  • success in the marketplace
  • Get advice and support from Facebook’s games and credits teams

Reading above, I think Facebook is saying that “if you give us a 30% cut of your revenue, we think we can give you back of some of the virality we took away from you earlier”. This might be worth it for some players, and not for some. I’d expect them to announce even more benefits in the future, where the goal of Facebook will be to embrace the games that do use Credits to the point where it’s difficult to operate in the ecosystem without going on board the Credits.

Effectively you have to choose between giving at least 30% of your revenue to Facebook (probably more like 40-50% if you also acquire users through ads) or remaining independent and operating a significantly smaller product than your competition.

The big unknown Facebook hasn’t said anything about is their strategy for allowing Credits to be used on sites that use Facebook Connect. Facebook announcing support for Connect has to be a matter of time, since the total monetization potential of sites is much greater outside of Facebook, than inside their own site. What they probably haven’t figured is, how to squeeze exclusivity deals from developers using Credits on Connect, so how that’ll be done is left to be seen.

Games that operate both as standalone games as well canvas apps are another huge question. This includes Farmville and Habbo. Offering different payment options on the canvas and the destination site might be both unacceptable from Facebook perspective, as well as too much hassle to justify the effort, but if the canvas apps are eventually enforced to go all the way with Credits, a hybrid model of some sorts will have to emerge.

Anyway, I’m eagerly waiting to discuss this with the fellow developers in GDC this year. It’ll be especially interesting to hear Dan’s comment on this, given his GDC talk tagline – How to Survive the Inevitable Enslavement of Developers by Facebook.

Update: Facebook has confirmed they will indeed require that games use Credits exclusively, and not integrate any competing payment mechanism, such as Paypal.

Automatic detection of reset OS X clock

I have a couple over 70 year old relatives using old Powerbooks which work fine, except for an annoying fluke: the computer’s clock battery seems to have died, so whenever the laptop’s battery dies, the clock resets to Jan 1st, 1970. This in turn causes OS X’s DHCP client to fail, so the computer cannot connect to the network anymore, so the NTP based network time reset fails as well.

This wouldn’t be such a problem, except I get the support calls for the network failing, and the relatives in question are old enough not to always remember to watch out the battery dying, nor checking the clock being reset.

So I created the following script today when fixing the “dead Internet”. It’s an ugly Applescript that detects if the clock has reset (year is less than 2011) and if so. resets the date to the last known one, and asks to reboot the computer to fix the network. I’d have assumed an OS X would be smart enough to do something like this on it’s own, but nope, you have to do this yourself.

If you want to use the following, save the script using Applescript Editor as an Application (without Startup Screen and Stay Open options) and add the app to the Startup Items of the user account.

if ((year of (current date)) is less than 2011) then

do shell script “systemsetup -setusingnetworktime off”

do shell script “mdls ~/Library/Preferences/RepairTime.txt | grep ‘kMDItemFSContentChangeDate’ | awk ‘/ = / {print $3}'”

if length of the result > 0 then

tell the result to set modDate to text 6 & text 7 & “:” & text 9 & text 10 & “:” & text 1 & text 2 & text 3 & text 4

else

set modDate to “01:20:2011”

end if

do shell script “systemsetup setdate ” & modDate

do shell script “systemsetup settime 13:00”

do shell script “systemsetup -setusingnetworktime on”

set answer to the button returned of (display dialog “Your computer clock seems to have reset. Press OK to restart so your network will work correctly.” buttons {“Cancel”, “Reboot”} default button 2)

if answer is “Reboot” then

tell application “Finder” to restart

end if

else

do shell script “touch ~/Library/Preferences/RepairTime.txt”

end if


On iPad 2 display resolution

The Apple rumor sites have been predicting the iPad will include a retina display, which would double the iPad’s screen resolution on both horizontal and vertical axis, to 2048 x 1536 pixels. John Gruber of Daring Fireball fame doesn’t think it’ll happen.

The rumor ties in with Apple equipping iPad with PowerVR’s SGX543 dual core graphics chipt (for 4x speedup in graphics processing), and Apple telling they’ve made a $3.9 billion strategic investment in component supply they’re refusing to detail.

I have two takes on this:

  1. Technically, the increase in resolution sounds extremely challenging, but possible. Apple could do it, but it’d be an amazing feat if they could pull this of without significantly increasing the device cost, or profitability.
  2. Increasing the resolution would gain Apple a level of product differentiation that’d be impossible to match for a long, long time. Most notably, all viable tablet competition will likely be Android based, which has a huge disadvantage in that Android doesn’t use GPU acceleration for it’s windowing. Hence it’s practically impossible for Android to drive such a high resolution screen, without significant compromises in battery life and overall system responsiveness.

Listening to Jobs and Cook talk about today’s Apple, they could probably surpass the challenges, and would consider the unmatchable resolution a strategic advantage, so I wouldn’t be surprised if they did actually pull this off.