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.


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!

Sponsorship of Flash Games in Haxe

haxeRecently magneticat asked on FGL about getting sponsorships for Flash games developed in Haxe. Having just gone through the process of publishing Gold Leader I’d been thinking about and dealing with those specifics quite a bit.  These are some of my thoughts (adapted from the thread).

The basic question is whether or not there’s any obstacle toward getting sponsorships when developing in Haxe.  From the sponsor’s perspective I can’t see that it would matter, provided you can integrate with their API(s) and branding.  It’s a game, it runs in Flash, users won’t know any difference, so why would the sponsor care?  Certainly Haxe probably lends itself toward some types of games and not others, but that’s no different from developing in Flex/raw AS3 rather than the Flash UI.  The latter lends itself more to very graphical, simple games that you can construct on the timeline.  The former lends itself to more programmatic, performance oriented games with a lot of reusable elements (sprites, tiles, etc.).  Haxe is no different, just higher performing and more pleasant to develop in.

From the developer’s perspective then it’s all about how possible or easy it is to incorporate sponsors’ APIs and branding assets.

Access to Adobe Flash

At the highest level, that question divides into two camps based on whether or not you have access to and/or choose to use Adobe Flash.  If you want to use Haxe but also have access to and are willing to use the Adobe UI, then you’re pretty much good to go.  You should be able to develop the game and then bring it in as an SWF or such if you really need to incorporate some elements using the actual Flash UI.

If you don’t have or aren’t willing to use Adobe Flash, the biggest concerns seem to be how rich the sponsor’s splash screen is, how they’re willing to provide it, and whether or not they have their own preloader they want you to use.  Basically, if you’re going to have to work with a .fla and you don’t have Adobe Flash, there’s essentially no workaround and you’re stuck.

Otherwise you can probably figure something out and/or integrate it all together at the end in Flash.  You could probably do this without paying, or at least not paying much, by using either the trial version or Adobe’s new cloud service to effectively rent it for just a month or whatever you need.  If you’re on Linux you should be able to do all of this in a Windows VM. Success under WINE or similar seems pretty iffy.

Integration Details

The real question then is how much you can do without access to or using Flash.

Integrating with AS3 code libraries is actually generally really straightforward.  Haxe’s whole approach to Flash makes this capability integral to the system, and there are many blog posts and other docs on it.  If the library is precompiled you can just link it in. If it’s AS3 source, you can use Adobe’s free Flex SDK tools to compile it for linking from Haxe.

There are a couple other gotchas, like a different default network security model, but they’re all easily fixed once you realize that’s what’s going on.

If the splash screen is just a movie the sponsor can provide as an SWF then you’re probably good to go.  NME has increasing cross-platform support for SWFs (read the comments for updates), though it doesn’t currently seem to support sound.  Fortunately, you can instead use the Flash API to play the SWF directly.  However, if the splash screen is some complex thing with buttons and different events that requires you work with the .fla, then you’re in big trouble if you don’t have access to the Flash tools.  Basically nothing else, even the Flex tools, will work with .fla files so you’ll realistically probably need to have access to and use Flash to hook it all up.

If the sponsor is providing their own preloader as code, you should be able to work with it somewhat like any other AS3 library, though it’s much trickier.  I wrote some AS3 preloaders for Haxe games a while back before NME’s preloader support was greatly improved, so it’s doable.  It does require a fair bit of understanding of the Flash boot process though and isn’t for the faint of heart.  It might be a lot easier now though that NME’s preloader hooks have been cleaned up.  Writing your own preloader in Haxe is really simple in the latest versions of NME.

My Experience

I personally use Linux and do not want to install a Windows VM, so I’m working without the Flash tools.  That could definitely be constraining.  Looking at some portals’ branding, you would need Flash to work with their .fla files.  Part of why I jumped on GameShed’s offer for Gold Leader was because the integration sounded straightforward (they turned out great in every way as well).

The final published Gold Leader is all in Haxe and other than whatever the artist and musician used, it was developed entirely on Linux using only free tools.  In terms of integration, it incorporates an AS3 library from Adobe for Google Analytics (my internal tracking and play instrumentation), Mochi’s AS3 libraries (MochiScore leaderboard), GameShed’s AS3 API (site achievements), and their SWF splash screen.  It definitely took some time to figure a couple of these out, but the actual code is easy so doing similar in the future will be a breeze.  GameShed provided its API as AS3 source.  Interestingly, it was essentially trivial to make a couple syntactic edits (to package, float, and for loop declarations) and compile it directly in Haxe.  That was quicker and easier to do than to compile with Flex and link against, though that also would not have been a big challenge.

rockethaxe-100x100All of the non-game-specific code from Gold Leader is open sourced and available in RocketHaxe.  The library is not super comprehensive yet, but what it does is useful and seems fairly high performance.  It also includes code showing how to incorporate Google Analytics, Flash native cursor support, and a few other platform features.  As I clean up and generalize some of the last-minute code from Gold Leader‘s final push I’ll be adding SWF player helpers, the Mochi API library, and some other bits.