Permission-Based Marketing and The 3 Rules of Facebook Game Design

I had a moderately-cocktail-infused epiphany during a dinner discussion at the game developers conference today that I wanted to jot down before it fades from memory.

The conference has had its share of discussions about Facebook as a game platform, whether the opportunity will crystallize to a business worthy of the hype, and about how design for Facebook as a platform would differ from games on other platforms.

During said dinner discussion, lots of examples - a few good, many bad - were cited and discussed. Out of that discussion, I extracted what I'll claim here to be the Three Rules of Facebook Game Design.

Rule #1: Facebook games must engage the player at two levels: Peripheral Notification and Invitation, and Directly Engaged Gameplay.

Directly Engaged Gameplay is the player playing your game. It might be in a flash window, it might be scattered about the facebook users page, it might be elsewhere. The point is that the player is directly spending time doing the various things you want him/her to do. All your traditional game design rules apply here.

Peripheral Notification and Invitation is all of the various feeds that the game spits into their updates (and that of their friends! More on this in a moment).

The main point here, is that there are TWO distinctly different levels of engagement. In the former, they are spending time playing your game. In the latter, they are spending time "checking Facebook" and may want to know what's going on, but that's it. Which brings me to Rule #2.

Rule #2) Peripheral Notification and Invitation == Permission Based Marketing.

If you don't get this, go read a required amount of Seth Godin and come back when you are done.

When the player is not engaged directly in gameplay, then EVERY interaction your game has with them via feeds and the like, is textbook permission-based marketing. Before they've signed up for the game, you are asking permission to have them engage with your game for the first time. Upon install, you should be asking permission to have them spam their friends (and assume the answer is no), when they are players and you feed them news about goings on in the game, you are asking their permission to have them come play your game.

ASKING not INSISTING.

Consider the two following hypothetical feed snippets:

JoeShmo just assailed your castle. Click here to defend it before all your villagers die.

vs

JoeShmo just assailed your castle. It survived but several villagers did not. Click here to survey the damage, and to stealthily plot your revenge.

The former tells someone who's logged on that they MUST go play now, whether or not they have time. The latter invites them to play, but doesn't insist on it. To someone taking a 10 minute break at work, the latter is far friendlier.

3) The game doesn't need to live on Facebook.

Perhaps the more controversion of the 3 rules during tonights discussion, I postulated that if you observe rules 1 and 2, then there's really nothing necesarily better about the "game" itself being in a window on the Facebook page of that user than in a separate window, a downloadable EXE, etc. there are certainly issues around what kind of data you are trying to export or whether you can export it, what the client tech is and whether it's as ubiquitous as Flash, etc. The point though is that there isn't anything inherently BETTER about it being on the users Facebook page. The value in the facebook element resides in the opportunity to do permission based marketing to engage with the player outside the core game, and in being able to exploit the friend relationships between friends, provided that 'exploit' still respects the permission-asking element. Once you come to that conclusion, then you can have the Facebook-game-design discussion about ANY game title (Assassin's Creed, The Sims, WoW, etc)