Early in 2009, Monty Kerr and I went out to GDC to do a little research.  We’d both built multiple game development startups, often for new media or new channels (e.g. mobile phones in 2002 or Windows in 1994).  We’d been watching Facebook expand as a platform and wanted to pursue the space, but we hadn’t found an angle we thought was compelling.  Were we too late?  Was the ocean too red?

By the time the show was over, we had what we thought was a key weakness in the social ecosystem and a way to address it.

First, a clarification of terms.  Social network and social graph have been used almost interchangeably the past few years, and not without some confusion.  It doesn’t help that Facebook and other sites are called social networks in the online service sense, which is distinct from the actual social networks they may utilize.  For the purposes of this post, I’ll stick with the current Wikipedia definition of social network:

“A social network is a social structure made up of individuals (or organizations) called “nodes”, which are tied (connected) by one or more specific types of interdependency, such as friendship, kinship, common interest, financial exchange, dislike, sexual relationships, or relationships of beliefs, knowledge or prestige.”

Put more simply, it’s a set of relationships we have with others based on a specific, shared context.   We are each part of many different social networks based on various contexts, such as family, classmates, a book club, or a sport we play.  Some of them overlap.   And while much of the time we spend with these connections may have nothing to do with the what brought us together, that context is the reason for the network’s existence and is the always available fallback for any future interaction (i.e. if we cannot find anything else to talk about we can always talk about the one thing that clearly interests us both).*

A social network service, like Facebook, is not a social network.  More important, it doesn’t provide the context to create a social network.  All a social network service does is improve access to pre-existing social networks already developed by the user and help new services (like games) seed their products with users.  That’s tremendously valuable, but makes all added interaction secondary instead of primary.

Why is that a problem?  Because secondary interaction is wholly dependent on a pre-existing (primary) social network.  If you stop playing a game, you don’t lose contact with the individuals you were playing with – you already had an established bond with them beforehand.  The game has a tenuous hold on you because it’s not the reason for your friendship with those you play with.

The same could be said about Facebook as a whole:  if it went away tomorrow, all your social networks would continue to exist despite greater friction of communication within them.  In other words:  Facebook doesn’t own your social networks.

Another problem with being dependent on pre-existing social networks is that the number of users you can play with is artificially capped.  Only a small subset of friends from your pre-existing social networks will have any interest in the same game as you.  That means fewer people validating your interest, fewer people to share it with, and fewer reasons to keep playing.  The result:  less engagement and poor retention.

A game, however, is a context just like any other shared interest.  A new social network can be built for the user based on players they come to know while playing.  A game-centric social network has several advantages:

• It’s primary in the user’s mind.  If the game goes away, so does their connection to everyone they know because of it.
• It’s self-reinforcing.  The more people I know playing, the greater the validation that what I’m doing is worthwhile.
• It’s uncapped.  There’s no limit to the number of friends I can play with (other than natural limits, in the Dunbar sense).
• It’s platform independent.  Because the game is the primary context, any platform it resides on – a web portal, a social network service, a hardware device – has less power over the game’s audience and, by extension, the game itself.  If the platform goes away, or the developer would like to leave the platform, being the primary context for a user’s social network goes a long way towards moving them to other platforms.

A game-centric social network helps engage and retain users for much longer periods of time.  I’m not talking about gains measured in weeks or months but years and decades.  Think about all those pre-existing social networks you have – those are based around interests you’re likely going to be involved with for the rest of your life.  That’s why a game-centric social network is so much more powerful than sitting on top of a pre-existing one.

Just to clarify again, because the terms are annoyingly close:  a game-centric social network is not a game-centric social network service (building such a service would make the service primary not the games on it, although that would still be one up on Facebook in terms of owning their audience).**

We raised some seed capital against this concept in the fall of 2009.  Since we rolled the business up into a larger company shortly thereafter I can’t say whether we were right or wrong, but in almost three years I’ve yet to see anyone really push this model.  To me that still smells like an opportunity, particularly as increasing engagement has become more important for those still building games for Facebook’s red ocean.

Footnotes:

*A social graph, by contrast, is really just a tool for mapping a social network. You could, to some extent, use this interchangeably with social network, except that social graph has actually come to mean the entire mapping of your relationships within a social network service.  So I’ll yield to the more popular interpretation (which is interesting in a business sense but not terribly useful in understanding the reason for people’s relationships to each other).

**We also now have interest graphs, which are related to but not the same thing as a game-centric social network.

I find it odd that traditional game developers take a dim view of those who work on smaller platforms like mobile, handhelds and the web.  These games do tend to be simpler on the whole than their console and pc counterparts, and they lack the same level of production values.  Therefore, the argument goes, making a small game for a limited platform does not afford the developer the same quality job experience as working on a mainstream title.

I’m going to make the case it’s just the opposite.

I used to do a fair bit of sailing.  I even lived on a catamaran for about nine months.  One question that sometimes came up, if you needed crew for a longer trip, was what sort of experience you’d look for.  Sure, some open ocean experience was nice, and a guy who’d sailed everything from Olympic Solings to 65′ Swans was great.  But given a choice between someone with mostly big boat experience vs. someone with mostly small boat experience, which would be better?

Small boats are light and nimble.  They turn on a dime.  But they have fewer conveniences and tools to make them easier to sail.  They are extremely susceptible to the smallest variances in the water and wind, and every little change the crew makes — trim the sails, point slightly higher, whatever — can be felt instantly on a small boat.

Big boats are large and cumbersome.  They move and respond slowly.  As a result, they conceal many of the little changes going on around you.  If you haven’t already acquired a feel for the environment and how a boat behaves in it from sailing smaller vessels, the mistakes you make will be harder to recognize and resolve.

You can see where I’m headed with this.  Consoles and PCs have become large, bloated systems.  They have so many resources available that developers are spoiled.    Yes, more resources enable grander games and new play styles.  But there are so few limitations that developers don’t gain the necessary experience for recognizing and dealing with many problems that do arise.

Developers of mobile, handheld and web games are far more constrained.  Every little detail of these platforms matters, and resources are limited.   When we were making mobile games six years ago, we were trying to squeeze full NFL teams, rosters and playbooks onto devices with 100k-400k of RAM, 1 inch screens, keypads with 200ms latency to the OS, buggy JVMs, untested firmware updates,  and absent documentation.  Uphill in the snow both ways.

It wasn’t Madden, but it was far more challenging to produce a quality, fun experience on, say, a Motorola T720 than a PS3.  And the project’s developers learned far more about the fundamentals of game development because they were constantly made aware of, and forced to deal with, the limitations of the platform.