The Future Of All Gaming Is Facebook?

Great post on Facebook's upcoming gaming strategy by Bruno Haid:

The way game development usually works today is that you license an engine (e.g. CryEngine) and a platform (e.g. Playstation). Facebook most likely wants to commoditize these basic building blocks by creating an entire open-source ecosystem, but with Facebook as a central social (and most likely monetization) layer baked right in.

The Future Of All Gaming Is Facebook?

Great post on Facebook's upcoming gaming strategy by Bruno Haid:

The way game development usually works today is that you license an engine (e.g. CryEngine) and a platform (e.g. Playstation). Facebook most likely wants to commoditize these basic building blocks by creating an entire open-source ecosystem, but with Facebook as a central social (and most likely monetization) layer baked right in.

Facebook Seeding Accounts with Credits

In advance of the public launch of Facebook Credits, it appears that Facebook are seeding users' accounts with free Credits. This is another way to get people used to the idea of buying and spending Credits. Straight out of the drug dealer's playbook.

Facebook Credits and Lower Conversion

In a recent blog post, Jambool makes the reasonable statement that the two-step purchase mechanism required when using Facebook Credits will lead to lower conversions:

Imagine if the Mexican government required that all of its citizens get paid in Pesos, but make purchases in US Dollars, requiring them to exchange their Pesos for US Dollars at “conveniently-placed” ATMs at various retail locations. You can imagine how inconvenient that would be, however simple the ATM interface is, or how close the ATM is to their place of business.

Jambool is (surprise surprise) a maker of a widely used virtual currency platform Social Gold.
My guess is that because of the huge potential of having its own virtual currency platform, Facebook will include in Credits the deep integration required to allow smooth in-game purchases and custom sales, just as Social Gold does today.

What's in it for Facebook

As quoted in a recent BusinessWeek article, Mark Zuckerberg said in an interview to Bloomberg TV that "there's just going to be one currency that people use", referring to Facebook Credits, the Facebook virtual currency.

People are still debating what exactly Zuckerberg meant, but here's a calculation to show what Facebook stands to gain:
According to the same article, Zynga's revenue in 2010 will surpass $450 million. Assuming 70% of that is made by selling virtual goods - Zynga stands to make $315 million from virtual currency. Further assuming Zynga pays its current payments partner a 20% share, that's $393 million dollars revenue before sharing.
Facebook takes a %30 cut of payments and that would mean a potential revenue of $118 million a year on Zynga alone! Not too shabby.

I don't have doubts that Facebook will indeed force Credits as the only virtual currency method on Facebook.
Do they have anything to lose? Not really, as the chances of a large developer like Zynga ditching Facebook are an absolute zero.

Credits is still in beta and is only available to a small number of large developers. There's no date for when Credits will be launched. My guess: pretty soon...

Offerpal Media Launches Display Network

Offerpal Media, a provider of monetization systems for social and mobile game developers announced the launch of a display ad network.
The network will allow developers to monetize their games by displaying in-game ads. That's in addition to existing solutions Offerpal Media is... offering (pun not intended) like a payments platform and a virtual currency system.
There are also specific features for advertisers who are game developers, like a "cost per install" program where you can set your bid on a user installing your app instead of CPC or CPA.

Problems with the .NET Facebook Developer Toolkit

Many .NET developers creating Facebook applications are using the Facebook Developer Toolkit (http://facebooktoolkit.codeplex.com/) and most tutorials for .NET Facebook development are based on this library.
This library is definitely useful and contains great wrappers around the Facebook API, however if you're new to .NET Facebook development - note that it is not very well written.

In particular - do not use the session classes (e.g. IFrameCanvasSession) with their session state management functionality.

Classes deriving from Facebook.Session do two things:
1. Make necessary API calls to establish a Facebook session for your application.
2. Save the state of the Facebook session in your application. This state basically consists of the Facebook user id, the session key and the session expiration time.

The way this is done is buggy. A few examples:

Even though the class IFrameCanvasSession contains a public property UseHttpSession which is supposed to cause the session state to be stored in the ASP.NET session - this is, in fact, not done: the state is always stored in cookies.

The constructor of the class contains this code:

public IFrameCanvasSession(string appKey, string appSecret) : base(appKey, appSecret)
{
this.UseHttpSession = true;
}

Which may lead you to believe that the class indeed uses the ASP.NET session as storage, until you realize that the whole loading/storing is called from that base constructor code which renders the statement this.UseHttpSession = true; useless.

Another quirk is in the way the session expiration time is stored. Facebook returns that value as Unix time. IFrameCanvasSession converts this to DateTime using this code:

DateTime time = BaseUTCDateTime.AddSeconds((double) secondsSinceEpoch);
int num = time.IsDaylightSavingTime() ? -7 : -8;
return time.AddHours((double) num);

which converts it to Pacific Time (??) in a hard-coded way.
This value is later exposed via the ExpiryTime property and gets stored in the cookie which is bound to give you a hard-time understanding things and may cause really nasty bugs when you start using that value in your own code.


Unfortunately, the problematic session classes are used as parameters to the various API wrapper classes. These are useful and will save you the time you would spend writing code to call Facebook API methods directly.

So I recommend to use the session classes without their session-establishing and state-storage functionality.

This means you need to pass false to the readRequest parameter of the constructor:

new Facebook.Session.IFrameCanvasSession(FACEBOOK_APPKEY, FACEBOOK_SECRET, false);

This instructs the class to not do any session establishing code and not attempt loading its state from cookies.

This means you will have to establish the Facebook session yourself and set the properties of the session class to the correct values (that's the user id and session key). I will describe how to do that in another post.


In addition to the above problems, the whole documentation of the library itself is not good, relying 100% on some sample projects that use it.
I encourage you to only use the library after carefully inspecting the code with Reflector and understanding exactly what it does.