F2P Design Rules

f2p-design-rulesOver the weekend I read Design Rules for Free-to-Play Games by Nicholas Lovell and Rob Fahey from Games Brief.  It’s a quick little ebook that I was able to read sitting around on short airport layovers.  The business model of the pamphlet itself is kind of interesting.  It’s essentially a cleaned-up, extended collection of some of their blog posts on the topic, with which they’re trying ot hook in more regular readers as well as purchasers of some of their extravagantly priced other material.  At $3 though this one is pretty reasonable.  You could get the same content trawling through their website, let alone others, but it doesn’t seem like a ripoff to have a polished, extended production in a convenient package.

These are the basic rules they establish:

  • Make it fun.  This should be obvious, but a lot of F2P designers are clearly not really thinking about making games, let alone fun games, as much as they trying to create the minimum possible engine for extracting the maximal possible cash from a player.
  • The Starbucks test.  Players should be able to do something engaging and complete within just a couple minutes.  Jump in, play, get a rush, get hooked.
  • Come for a minute, stay for an hour.  Make the core game last just a few minutes—the Starbucks test—but wrap it in longer loops of complexity, challenges, and/or appointments to keep people playing and returning.
  • Complexity in layers.  Give players of all types something with which to engage: Achievers, Explorers, Socializers, Killers (the Bartle types).
  • The importance of never ending.  Figure out a game design without finite duration so people can just keep playing endlessly.
  • Be generous.  Giving people things and not being tight with game rewards will make them like you more, keep coming back, and spend generously in return.
  • Be free-to-play forever.  Throwing up a paywall is booting players unnecessarily, after you’ve gone to all the trouble to acquire and retain them.
  • The no-brainer first dollar.  Have an in-app-purchase that people would be crazy to not purchase, some kind of great deal.
  • Make it possible to spend $100.  Don’t impose an upper bound on how much people can spend.  If they want to drop a ton of money, let them!
  • Have pizzazz, not polish.  You don’t need to nail down every little detail that players won’t notice.  You do need to give lots of feedback and rewards—animations, sounds, and so on.
  • Kill the tutorial.  Don’t waste time before showing players the good stuff and getting into the engrossing action, they’re not going to give you the benefit of the doubt as they might for a paid product.
  • I must not fail.  Avoid killing off players or otherwise blocking their progress.  You want them to always be able to see some way to continue moving forward.
  • Sell emotion, not content.  Players don’t care how much things cost to make.  They care about buying a better experience.
  • Experiment and learn.  Run principled experimentation, collecting data from well instrumented games, to figure out what’s working and what’s not.
  • Game development never ends.  Continually tweak and tune.

There is also a small but reasonable glossary, with a small selection of key F2P terms and concepts explained.

I think it’s misleadingly tempting to declare these design rules “obvious.”  To me, pretty much all of them make intuitive sense upon being presented.  But the opposite are in many cases also intuitive and more traditional.  A good example is imposing a paywall, having a player pay for more content.  Clearly that’s a viable approach to monetizing a game, and has a long history.  But Lovell and Fahey argue quite a bit, I think convincingly so, that this is not actually a Free-to-Play model, it’s just a rehash of demos and shareware of years past.

Many of these also seem hard to achieve, which is fascinating.  A leading example is enabling players to spend up to $100/month.  Caveat devoting a lot of effort to generating large new content like level packs, that seems really challenging.  Even if you’re generating and selling a lot of small content (hats!), how do you get a particular player to keep buying variations?  If you’re not selling content, what kind of gameplay and purchases do you need such that they can keep spending money but you’re not just shilling for extra lives or such?  It’s actually quite a challenge to think up game designs that meet many of these guidelines, which to me says that there’s probably some thought and value to them.

There’s more explication and rationale in the book, so I encourage those interested in these kinds of things to either pick it up or go trawling through the Games Brief blog for the original source posts.

Gold Leader @ 50,000

goldleader-iconSometime today Gold Leader crossed 50,000 unique viewers.  Together they’ve played just under 76,000 times over the two weeks it’s been released.

Of course, “unique” is not a strictly literal term.  I’m not sure how Google Analytics determines uniqueness exactly, but people coming back after some time are clearly included.  In some sense that doesn’t matter much in terms of counting eyeballs for ads and such and there’s no other real mechanism without any sort of accounts or such, so that’s the kind of number that generally gets bandied about.

As noted by the stats on the main blog, the game remains much too hard: Only about 14% of all players are beating the first mission objective.  I can only imagine what that’s doing to the repeat plays, or presumed lack thereof.  About 4000 people have loaded the game and not started a mission. I guess it just wasn’t what they’re looking for.

Almost all of the plays actually come from the last week.  The first week after launch (Jan 16) the game was getting a steady thousand views/day or so on GameShed.  Once it went viral to all the ridiculously many Flash sites around the net though, the plays spiked quite dramatically (about Jan 22).  Views are trending down now as the game falls off their front pages, but I really have no idea what the lifetime is.  Hopefully it settles on some sort of steady number of plays and doesn’t bottom out completely though it’s hard to believe that won’t happen given the steady deluge of games hitting the Web.

goldleader-players

Plot of game load events as captured in Google Analytics.

I’ve had some trouble coming up with numbers for typical Flash game plays so I’m not sure how this compares.  Many sponsors don’t allow developers to collect stats, and many developers are cagey about revealing what they do know.  Clearly it’s no Angry Birds or even a moderate hit, but it also certainly doesn’t seem to be the bottom of the barrel either.

Either way, that’s a pretty satisfying number and was actually my admittedly under-informed target: 50,000 players in two weeks.  50,000 people is a lot of people!  I guess it’s not “Internet scale,” but even accounting for some reasonable fraction being repeat players that’s still an absurd amount of people to have played my little shoot ’em up.

To put it in one perspective of interest to me, I’ve published research articles in several high profile venues, most notably in terms of numbers some of the major IEEE magazines such as Internet Computing.  An optimistic readership number I’ve heard for those higher profile venues is 5000 people, and presumably some fraction thereof reading any given individual article.  This is an order of magnitude more!  And it’s god knows how far from putting games up on the Web ten to fifteen years ago, when I was probably optimistically getting a very low couple hundred players, mostly through the Allegro community.

For the most part this is actually not as emotional as some of the early super enthusiastic reviews on FGL, but it’s still really cool and deeply rewarding.  It’s also somewhat educational.  Though fairly obvious beforehand, the data confirms that even for a lower profile game like this, the resources consumed would be pretty substantial for a single host.  If I moved the leaderboard or analytics off Mochi and Google, or provided any kind of multiplayer, online updates, or downloadable content, I would need some serious infrastructure to manage it.  Fortunately, I’m on top of it.  To the future!

Gold Leader: Early Analytics

goldleader-iconOne of the more interesting things to me about modern game design and implementation, particularly of online games, is the ability to heavily instrument them.  For example, tom5760 and I were talking the other day about Team Fortress 2 and how Valve tracks every death in great detail so they can do fancy things like plot heat maps of kill zones on levels or chart kill rates for all the weapons.  Clearly that’s critical for any sort of online, repeat play game like TF2 where you need to keep adding and continually balancing content to keep people coming back.

But it’s also really interesting and useful in general, providing great data for learning and adjusting future game design, and something that never even really occurred to me as a realistic possibility writing games for the late-90s landscape.  The technology and connectivity was only just beginning to be in place for it.

Gold Leader is only instrumented lightly, but it is hooked up with Google Analytics and it’s interesting examining the data (these numbers below are rounded slightly, for no real reason).

Players

Right now the game’s been up for about 60 hours.  Some 140 people have loaded the game a bit over 260 distinct times, and actually started playing a bit under 400 times.  Definitely not lighting the Internet on fire, but it’s still pretty cool to me at least that about 200 people have now played when you factor in FGL commenters.

Somewhat more interesting is how they’re doing.  Here’s the progression of players:

  • 45 have beat the Sensor Grid (60 times).
  • 20 have beat the Assault Command and Interceptors (25 times).
  • 15 have beat the Minelayers (15 times).
  • 10 have beat the narrative mission (the whole game) (10 times).
  • 7 of them have given the survival mode a try (7 times).
goldleader-sensors-achievements

Achievements’ display on GameShed, showing the Sensor Grid.

As a fine grained input on the game design, nearly everyone is failing by missing a mission objective rather than dying.  Only 20% of the failed attempts have been at 0 lives, the rest all have lives remaining when the mission was reported as failed (missed too many Sensors, etc.).  I’m not totally sure what to make of that—is one way or the other in terms of getting players to try again? I have no idea—but it’s really cool to know and think about, and if I were going to do an update would provide a clear update on what to adjust if I wanted to make the game easier, e.g., upping the mission failure threshold but not worrying about the number of lives.

Progression

The total and unique events for the Assault Command and Interceptors are identical and it’s not possible to skip the former and go to the latter, so it seems that anybody who can beat the Assault Command “boss” can beat the Interceptors.  That’s actually really interesting to me, because I don’t consider the boss much of a challenge, it’s basically just an old school “learn the pattern and play safe” fight, and the Interceptors mission can definitely be challenging.

Similarly, most people who can get through the Minelayers can get through to and beat the final Command Group, the next mission.  That I’m happy about, the balancing seems about right.  It’s not 100%, so there is a progression in difficulty.  But, it is only about 75% so it’s not a ridiculous additional challenge.

Only one or two other players (besides myself and tom5760) have achieved a perfect run (no deaths).  Stupidly I’m not explicitly tracking this, but I can sort of figure it out.  One I know for sure because he was logged into GameShed and recorded the achievement.  He’s actually the number one player on the site (has earned the most achievement and high score awards), so that’s not too surprising.  The other is actually a friend of mine who posted such a high score to Mochi that I can’t believe he didn’t beat the mission in one run.  I’m not even sure it’s possible to do otherwise while scoring above ~2750 or so, and he’s just over 3000.

Long Game Repeats

Unfortunately I’m not really logging how far people have played into the survival mode.  I’m sure it’s too hard, even I can’t survive for long, but it would be interesting data to have.

From the data it’s hard to tell people’s behavior once they get into the late stages without putting together some analysis scripts on the raw logs.  “Unique” here means a session, so they could be coming back some time later.  Based on the scoreboard however, if they are they’re mostly not playing up to the same point, though some are.

Difficulty

In general though, the big lesson, really the confirmation, is that the game is pretty hard.  Only 25% of players have made it through the first mission, and only on about 15% of the plays.  Toward the objective of hooking people in and keeping them playing and coming back, it’s clearly too hard.  In so far as that limits the reward the sponsor is getting out of the game and the audience the game and Rocketship Games gains, that’s unfortunate.

However, beyond that concern I can’t say I’m particularly troubled or upset about it.  Many of the reviewers on FGL noted that it was fairly hard, and it was obvious from my own testing.  I’ve never been a fan of the intentionally super hard games out there now (e.g., precision platformers like Super Meat Boy), but early on in development I found myself unexpectedly adopting a definite attitude that the difficulty was part of the aesthetic of the game and its homage to classic early shooters.  To some extent that’ll cost future efforts by hampering the popularity and visibility of this one, but clearly the difficulty objective has been met: Pretty hard—too hard for “casual” gamers—but certainly accessible for more “serious” gamers.

In any event, fantastic data to collect, and this experience has really convinced me to put a lot more thought toward instrumentation in future efforts, particularly in playtesting.  I hadn’t thought I’d be able to get much data so I hadn’t worried about it much here, but in the end enough people beta-tested on FGL that I probably could have gotten a fair bit of data while still in development.  Something to consider in tuning future games.