Are Platform Game Lobbies the Next Social Graph?

When speaking with the larger social gaming companies and asking why mobile hasn’t been a focus (to date), the response is interesting and a validation of how fragmented the mobile device and platform landscape is. Typically, the answer is something along the lines of “…we launch an average Facebook game and we make $3M per month, we launch a hit mobile game and we make $1M per month…” – not withstanding the higher COGS with mobile because of the greater R&D costs.

A hit game on Facebook is potentially $6M+ per month (or more) and you’d be hard-pressed to find any mobile game in history that has made those kinds of dollars – I can’t think of any unless you amortized Jamdat’s acquisition of Blue Lava Wireless for the mobile Tetris license in 05 :) In any case, the reason for such a discrepancy in revenue potential is for a single reason: the size and availability of the social graph. Sure, mobile may also have greater challenges with billing but the opposite could be argued with one-click micro-transactions on iPhone and each of the platforms, operators and OEMs all caching credit cards. And yes, many mobile social games and applications have integrated with Facebook Connect but unfortunately it’s too late with the initial viral land-grab being inhibited by a new set of Facebook rules oriented around preserving the personal nature of the Facebook Wall. As one colleague over lunch put it the other day, “…Facebook is constraining the virality of new applications by introducing more and more rules whereas mobile is just finally opening-up…”

Welcome game lobbies such as the iPhone Game Center and WinMo7′s integration with Xbox. Note, I did smirk when these were first announced earlier this year – does anyone remember companies like M7 Networks which powered Sprint Game Lobby? Sprint used to mandate that each mobile J2ME game had to include the game lobby libraries to allow users to post high-scores and potentially enable head-to-head gaming. This was a grand vision but really was only the first phase – take the Sprint Game Lobby and integrate today’s viral and notification mechanics and you have the next social graph.

Little has been released about the mechanics of the new game lobbies but assuming that users can opt-into the game lobby and buddy lists can be created than a new social graph has formed. Mobile social games can then tap this social graph not to differently to how they tap the Facebook social graph using Facebook Connect. Although this social graph may be smaller (eg not Facebook’s 500M+ users but rather 50M+ iPhones or 10M+ WinMo7 est.), the reward may be greater with potentially very open virality and notification rules. Whereas social games on Facebook now rely on cross-promotion and advertising, mobile social games may be more akin to Facebook 1.0 where the Wall is saturated with application and game notifications (or SPAM to others). And as long as the platforms can continue to focus on a write-once, run anywhere paradigm (eg one way by maintaining screen geometry etc as I mentioned in a previous Venturebeat article), then this social graph will continue to expand. Couple this with the cached micro-transaction capability of mobile and you now have your next land-grab. Facebook revenue potential is going flat and mobile is about to explode!

Now assuming that publishers continue to build iPhone, Android and others, will the interoperable game lobby exist? If so, then we will have the largest potential social graph ever that is more personal than any Facebook experience through a PC.

Looking forward to playing with these game lobbies once released and selfishly hyped to be able to see my Xbox avatar on WinMo7!

Understanding PDE (Positional Determining Entity)

In the past 2 years, the industry has finally moved beyond LBS as a category to LBS as a feature. As stated previously, “What app wouldn’t be more useful with location?”! What’s misunderstood in all of this is how location is retrieved by the app and what this means.

E911 (government mandated subscriber location lookup) in the early days was the initial motivation for opeartors to introduce network-based location lookup. This location is acquired through a combination of network triangulation technologies and is delivered to the requested entity (eg person or app) via a positioning server. This approach is often referred to PDE or carrier-based location lookup.

The challenge with PDE has been in business models; operators have been charging for PDE location queries and a variety of middle-men and/or aggregators have been trying to sell this access (eg Wavemarket, Autodesk’s former mobility group, Alcatel Lucent and others). Most developers obviously can’t afford to pay 5-10 cents per location lookup and have thus resorted to the many free alterantive ways to get location such as determining location by the cell tower or getting location through WiFi or most obvious, getting location from GPS (readily available through APIs in smartphones today.

You may ask, why PDE if you can get location in other means? The challenge with the alternative solutions, is that the app can only get location for you (and you only). This is great for use cases like Google Maps but what if you wanted to get the location of your buddy or what if you wanted to send an SMS when one of your friends walked by your house – yes, that would be kind of creepy but advertisers love this scenario (proximity marketing). Unfortunately, the only way besides doing a FourSquare check-in to get the location of one of your buddies or a passerby is using carrier-based location lookup.

To entice more developers, many of the carrier location aggregators have been trying to offset the 5-10 cents per query pricing via alternative business models. For example, a developer can receive subsidized queries in exchange for sharing advertising revenue from their app. Unfortunately as much as mobile advertising is growing, it still cannot offset even a 5 cent query. The better question to ask is why is there a charge at all – if PDE was free, there would be a whole new set of apps that could be enabled built leveraging real-time location. For example, without needing an app running in the background, I could track the entire life-path of a user – an advertiser’s goldmine in terms or profiling! Well, as with most things, the reasons things are the way they are is often not the most logical:

1. Without naming operators, some can’t scale PDE. I’m pretty sure they want to open it up, assuming the right privacy features were in place but the query volume would kill the network infrastructure. Let’s see what happens as initiatives like GSMA’s OneAPI continues to push forward – this is a solvable problem.

2. Some operators are restricted by their licensors. For example, CDMA operators use Qualcomm’s QPoint to power the PDE and likely have licensing fees based on volume that inhibit their capability to open it up.

3. And of course the biggest problem is that there are a handful of developers (eg Family Locators) who are actually paying 5-10 cents per query. Unfortunately, when somebody is willing to pay, then let them pay even if it inhibits innovation. I guess we’ll have to wait for Google to make it free (somehow)!

In any case, let’s see how this evolves. Carrier-based location lookup can open-up a whole slew of new applications that cannot be achieved effectively today. It moves the problem from getting location to the larger problem of privacy which many others are trying to tackle.

The Fragmented Web

One of the interesting trends in the industry is that the browser is becoming the platform for mobile applications. Why build native apps that require significantly more engineering effort then web apps which are truly a write once, run anywhere – this is what we’ve always been evangelizing at Skyfire. I’ve always pointed to the initial IE monopoly on the PC as a good thing in that it helped standardize HTML / JS etc unlike J2ME which is highly fragmented.

Well, as part of this trend, I think we are running the risk of repeating history. When J2ME was first released, a lot of the cool functionality was not available (ie access to the camera or file-system or bluetooth etc). Given the long but necessary process of the JCP to approve additional JSRs to support this added functionality, handset manufacturers jumped-the-gun and started releasing proprietary J2ME libraries to achieve certain functionality. I remember distinctly using the proprietary Motorola file system J2ME libraries and not JSR 75 which hadn’t yet been ratified or adopted. Instantly, J2ME became quite fragmented; given that I was working on a photo-upload application, we had to port to every J2ME device using different proprietary file-access libraries.

What’s interesting is that this same trend may repeat with the mobile web. As the browser becomes the app platform on the mobile device, developers are wanting to access native functionality on the phone (ie file access, the camera etc) via Javascript. Because the W3C MWI (Mobile Web Initiative) and the Bondi OMTP are still gathering support of the ecosystem and still defining standards, OEMs have begun defining proprietary Javascript to access native features of the phone. Palm is leading the charge here with WebOS and the Mojo SDK by defining custom JS to access native features of the Pre.

Going forward, I expect that most OEM browsers will take a similar approach potentially resulting in a fragmented web. As a developer, I may now have to port once again amongst different platforms.