Learning about Free-to-Play from Devil May Cry


The first 20 minutes of Devil May Cry are really clever.  What happens is this: you breeze through several rooms, chopping evil marionettes left and right and flicking that silver hair around like you own the world.  After the second or third room the game offers you the option to switch to “Easy Automatic Mode,” in which the game becomes easier.  It’s pretty easy at that point, so you probably ignore the offer.  But a few minutes later Devil May Cry throws you at the first boss (a giant lava spider) and you die.  I mean, you die.  You get your butt handed to you on a platter.  The giant lava spider is way, way tougher than anything you’ve seen in the game so far.  It’s not even clear how to damage the thing at first.  You get beat down, hard.  You try again, but it’s futile. The lava spider is too difficult.  At this point you have four options:

It's hard to find a better arrogantly androgynous fashionista super hero.

It’s hard to find a better arrogantly androgynous fashionista super hero.

  1. Quit playing,
  2. Turn on Easy Automatic Mode and try again,
  3. Step up and become much more skilled to beat the boss, or
  4. Figure out that you can go back and keep killing marionettes to grind for items which you can then use in a shop to power yourself up to make the boss more reasonable.

This is a genius little bit of manipulation because what the game is really doing is forcing you to identify, early on, the kind of experience you want.  If you quit, well, you probably do not have the patience required to enjoy the rest of this game.  If you turn on Easy Automatic Mode, you’ve identified yourself as somebody who wants to play but isn’t interested in a pride challenge.  If you skill up, you’re a hardcore mofo and the game should throw everything it’s got at you.  The last option, the one that I think most players choose, is to go back and grind.

But grinding serves a purpose.  It forces you to learn about second- and third-order game systems, like controlling your combos to increase the number of style points you get.  It is here that you unlock the real meat of the game design: you’re not just supposed to button mash through dudes, you’re supposed to control your combos to destroy the opposition as stylishly as possible.  Doing so increases your style score, which increases the payout of each felled enemy, which lets you upgrade to become even more badass.  This is a much more interesting (and difficult) challenge, and adds a lot of depth to the moment-to-moment gameplay.  Devil May Cry uses its first boss as a forcing function to figure out what kind of player you are, and it compels you to unwittingly select a play style that you prefer.

Why does it do this?  Because the rest of the game is even harder than that lava spider boss, and becoming skilled enough to make progress requires that you be really invested in the core game mechanic.  Button mashing isn’t enough to sustain most players’ interest through the incredibly demanding difficulty curve that Devil May Cry employs, but by tricking you into learning about the extra depth in the combo system, the game is actually ramping you up for a more interesting experience.

Easy Automatic Mode pop-up in Devil May Cry 3.

Easy Automatic Mode pop-up in Devil May Cry 3.

It’s really quite manipulative if you think about it.  The system is designed to carry the maximum number of people through the level content, and hopefully make them feel good about it.  It’s a carefully constructed trick, aimed right at the psychology of the player who feels that he has something to prove.  Going a step further, we might even see the offer to switch to Easy Automatic Mode as a challenge: “hey, if you can’t take the heat, there’s always training-wheels mode over here.”  Players who aren’t putting their pride on the line will see Easy Automatic Mode as a welcome way to reduce frustration.  Players who want bragging rights for their skills see it as a personal insult.  The game uses this form of manipulation to ensure that both types of players are put on a path to having a good time.

This is the type of design that a good free-to-play game should pursue.  One of the many complaints about free-to-play games is that the addition of purchases leads to manipulative game design.  But manipulative design is not limited to attempting to extract money from wallets.  As with Devil May Cry, it can be used to improve the game experience, and widen access to players with different play preferences.  If you want to get technical about it, contemporary free-to-play experts would probably call Devil May Cry’s lava spider a retention system.  The lingo might make you feel yucky, but the concept is sound: it’s a way to get more people to give the game a second or third chance, to identify what kind of game they want to play, and prepare them for the dramatically deeper content ahead.

DMCs core loop supports different play styles, but it identifies which you prefer early.

DMCs core loop supports different play styles, but it identifies which you prefer early.

There’s no question that the addition of real-money purchases changes the emotional tone of the game for some players.  There’s no question that many of the mechanisms used by free games to make money could be considered manipulative.  Certainly there are games that are designed without respect for their audience, but what of games that manipulate out of respect?  But what if the purpose of that manipulation was to improve the fun factor?  What if the purpose was to force the player to choose between a skill-based challenge or content tourism?  What if we could use the emotional impact of a real-money purchase to manipulate some players into enjoying the game more?  Traditional games do this all the time; should free-to-play games be any different?

We think that in-app purchases can be put to better use than just fishing for a small fraction of the audience that likes to spend big.  We think they can be used as a way to increase the quality of the game, both for those who purchase things and for those who do not.  In the next post I’ll write about how we’re trying to do that with Wind-up Knight 2.

Posted in game design, mobile games, wind-up knight | Leave a comment

Playing Wind-up Knight 2 with a Guitar (and why it matters)


Yesterday we posted this silly video about playing Wind-up Knight 2 with a variety of funny controllers.

Nothing in this video is faked; we used a converter box (like this one) to convert our various console controllers to USB, then a OTG USB-to-Micro USB adapter (like this one) to connect the box to an Android tablet (in this case, a Sony Xperia Z, though this should work with any modern Android device).  Most standard controllers will just work, but this collection of weirdo devices requires a little bit of button mapping (usually just two keys), which we have a simple setup screen for.

We had fun making this video, but it also forced us to ensure that our controller support was complete.  If you can play Wind-up Knight 2 with a Guitar Hero controller, I’m pretty confident that you’ll be able to play with any standard mobile controller that might be released in the future.  And because we had this infrastructure in place for Android devices, adding support for iOS7 controllers took us about five minutes.

Controller Madness

Controller support is important to us because there are entire genres of game that are difficult to translate from fingers-on-a-button to fingers-on-glass.  We’ve worked hard to make Wind-up Knight have tight, reliable touch screen controls, and there are plenty of games on mobile devices today that could never be made with a traditional controller.  But there’s also 30-odd years of game design behind sticks, d-pads, and buttons, not to mention a generation or two of people who know how to play games this way.  Our interest isn’t in competing with console games–we love our PlayStations and Xboxes.  Rather, we want to leverage the extreme ease of development and distribution that mobile platforms enjoy to make crazy controller-based games.

We fondly remember the short-lived Dreamcast golden era, when all kinds of wacky, innovative titles were readily available, when the cost of development was still low enough that experimentation was abundant.  These days, if you want to play a jaw-droppingly beautiful FPS, you should probably do it on a console.  If you want to kill five minutes while you wait in line for coffee, your phone’s got you covered.  But what if you want to play something like Power Stone 2, or Jet Grind Radio, or Cannon Spike?  Some games from that era have actually been released for mobile platforms and while they look great, they are neigh-unplayable.

I believe that controller-based games distributed as apps to devices based on mobile hardware could give us access to that sort of golden era again.  I don’t know if controller-based mobile games will gain enough traction to become a big deal, but I sure hope that they do.  Whether it’s controller peripherals for phones and tablets, TV-based devices with mobile hardware like the OUYA, or dedicated portable gaming devices like the SHIELD, we want to be prepared to deliver the best possible play experience.  And after playing Wind-up Knight 2 with my old Dreamcast controller, I am happy to report that it feels pretty rad.

Posted in Android, controllers, game design, game engineering, iOS, mobile games, wind-up knight | Comments Off

Checkpoints in Unity


One of the new features in Wind-up Knight 2 is checkpoints.  They work the way you  expect: if you die after passing a checkpoint you will restart at the checkpoint location with the game world restored to its previous state.  This sort of system is easy to implement if you plan for it from the beginning of development, but it can be tricky to retrofit to an existing game engine because entities tend to change their state subtly as the game is played.  What animation frame was the character on when the checkpoint was hit?  What was his velocity?  His collision contacts?  If you didn’t plan on saving this sort of state when you wrote your entity behaviors, adding it in later could represent a pretty major code change.


We didn’t have checkpoints in the original Wind-up Knight, and when we decided to add them for the sequel I realized we were looking at a potentially massive change to the codebase.  Our requirements for checkpoints were as follows:

  • Flexible.  Need to be able to serialize all the entities in levels we already built.
  • Instant.  No hitching when saving the checkpoint, and restarting after a death should be instantaneous.
  • Repeatable.  We only store one checkpoint at a time, but a level can have any number of checkpoints in them.
  • Efficient.  We can’t use too much runtime memory.

At first, my main concern was Flexibility.  We have a lot of entities that change their state in a lot of different ways.  Coins that are collected.  Enemies that animate, attack, and turn around.  Rocks that fall only once.  Gates that open and close.  I wanted to make a system that would deal with all of those things without having to make code modifications to each.

My first attempt was to use C# reflection.  I figured that if I walked the object tree and recorded all of the public fields and properties, I could restore those values on checkpoint reset and be 90% done.  Turns out that this isn’t so hard to do in C#, and I was able to knock out a prototype in a couple of hours.  But immediately there were problems: the number of fields to serialize was so large that there was a visible framerate hitch, and properties on many Unity objects have side-effects when set (e.g. rigidbody asserts if you try to write to velocity while isKinematic is true), making deserialization difficult.  I also noticed that most of the data getting serialized was not really information needed for a checkpoint restore.  Most fields never change.

This lead me to try the opposite extreme.  I would serialize only specific objects, and only a few parameters of those objects, and anything that wasn’t sufficiently covered would require custom code.  For this second attempt I decided only to record the following information:

  • Object transform
  • Whether or not the object was destroyed since the last checkpoint

That’s it.  Any other state would have to be dealt with on a per-script basis.  I figured that this method would get me about half way there and then I’d spend a lot of time modifying entity code to deal with state storage and loads.  Sort of a lame solution, I thought, but one that probably would meet all of the requirements above.

I implemented this in three parts:

  1. CheckpointRegistry, a singleton that maintains a record of all objects that are tracked for checkpointing.
  2. CheckpointAware, a script that marks an object (and all of its children) for tracking, and
  3. CheckpointBehavior, a child of MonoBehaviour that adds two virtual methods for dealing with checkpoint saves and loads.

CheckpointRegistry contains a HashSet of objects that have been marked for tracking.  When a new object is registered, all of its children are automatically registered as well, and top-level objects are called when save or restore events occur.  The Registry also provides methods for destroying objects; CheckpointRegistry.Destroy() makes an object inactive and adds it to another set, to be reactivated on the next checkpoint restore or actually deleted on the next checkpoint save.

The real work occurs in CheckpointAware.  This script, which is dropped on any object that should save its state when a checkpoint is hit, records the transforms of itself and all of its children.  CheckpointAware adds its object to the CheckpointRegistry when it is allocated, and waits to be told to save or restore its state.  When a call from the Registry comes in, CheckpointAware reads or writes all of the transforms in its subgraph and calls the appropriate method on any CheckpointBehaviors therein.

Bask in the warmth of the checkpoint's light.

Bask in the warmth of the checkpoint’s light.

To sum up the algorithm: CheckpointAware stores position, scale, and rotation of subsets of the hierarchy.  CheckpointRegistry stores references to all of the objects in all of those subsets, and manages object destruction from within those subsets.  A checkpoint is saved by calling CheckpointRegistry.SetCheckpoint(), which calls a similar method on each CheckpointAware instance.  CheckpointAware records the transform of itself and its children to a simple struct and calls CheckpointBehavior.SaveState() on any children with CheckpointBehavior-derived components.  Restoring the checkpoint is the same, but reversed: CheckpointAware walks its list of stored transforms and writes the cached values back into them, and then calls CheckpointBehavior.RestoreState() on any children that need it.  Whew.

In any given Wind-up Knight level there are thousands of objects that need to be serialized for checkpoints. Fortunately this method is very fast; there’s no visible hitch on saving or restoring the state, even on fairly low-end devices.  It’s also pretty efficient, as only the minimum amount of data required to restore a checkpoint is saved.  So there’s two of our four requirements right off the bat.  It’s also easy to manage multiple checkpoints with this system, so we can mark off Repeatable as well.

Which leaves us with one last requirement: Flexibility.  The weakness of this approach is that it’s only storing positional and lifetime information; nothing about entity state is recorded by default.  I thought it was only going to get me half way.  But once I had it up and running, I found that it is almost a complete solution.  For Wind-up Knight, storing position and lifetime alone proved to be about 90% of the final solution.

I did end up having to go through a bit of entity code to save and restore internal variables.  But even that turned out to be simple; most objects just need to record an int or a bool, and can cache them right in the script instance.  I spent a day converting existing scripts to CheckpointBehaviors and adding SaveState() and RestoreState() implementations, usually only three or four lines of code each, and then I was done.

Retrofitting a mass of existing code to perform new tricks isn’t fun (even when it’s simple and easy), but the payoff was worth it.  Now dying in Wind-up Knight 2 (which happens a lot) hardly slows you down; you’re sent back a bit and get to try again without missing a beat.  It’s a huge improvement in the general flow of the game compared to its predecessor (which required a full scene reload on every death–ugh).  The architecture of this checkpoint system occupies a nice middle ground between general purpose serialization and script-specific logic, and I’m glad (and a little surprised) that the design worked out so well.

Oh, and if you’re one of the hardcore group of folks that wants to play the game without checkpoints, never fear: you can turn them off.


Posted in game engineering, wind-up knight | 3 Comments

Leveling Up the Wind-up Knight Design Process


When we built the original Wind-up Knight, Robot Invader was only three people: Casey, our intrepid designer / animator, Mike, our one-man art machine, and me, the code guy.  We hired contractors (the mighty Jordan Fehr for sound design and intrepid Josh Whelchel for music) and an intern (Patrick Wagner, now at Arachnid Games), and went from founding the company in April of 2011 to shipping in October of the same year.  We managed this by leveraging Unity (though none of us had any prior experience with it) and by staging our releases (the iOS version came out slightly after the Android version).  Subtracting about a month of time spent buying computers and getting office space and generally spinning up the company, Wind-up Knight was developed from scratch in about five months.

Of those five months, two were spent prototyping.  We’d build out a game idea in a day or two, play with it, make improvements, and then move on to something else.  Almost nothing from this stage survived in the final game; if an idea didn’t work, or just wasn’t fun enough, we chucked it aside and tried something else.  Wind-up Knight went through a number of crazy iterations before it settled on the platformer that we eventually shipped.

WUK1 Alpha Shot

A very early shot of the original Wind-up Knight.

Two months of prototyping and three months of production work to make a platformer with over 50 levels in it, each with a completely unique look and feel, was a lot of work.  We do our level building in “blue-box rooms,” levels that have blue collision regions but no real art.  The levels are designed, tested, and polished in this state, then “skinned” with art as the very last step.  The skinning process is a bit like building unique structures with odd-shaped legos: we snap together bits of geometry provided by Mike to give every level a unique look while sharing lots of texture and mesh between levels.  But the hardest part is the actual blue-box phase, the creation of the core level geometry.

Casey, who designed every level in Wind-up Knight, spent pretty much all of August of that year in the office, working his fingers to the bone.  At the end of it he had produced 52 awesome levels.  He had also developed a level design workflow that included specific metrics for jump distances, spike placement locations, and wall slide heights.  Casey came out of that month of hell with a head full of rules about how to make a fun Wind-up Knight level.

Fast-foward to 2013 and Robot Invader is a little different.  We’re four people now (the fourth is Jonny, our seasoned design director), and have shipped a couple of games.  This year we split our team of four into teams and developed two games in parallel, one of which turned out to be (after a number of experiments and prototypes) Wind-up Knight 2.

WUK2 Blue Box

A shot of an unused Wind-up Knight 2 level at the “blue box” prototype stage of development.

WUK2′s development has been very different than its predecessor.  Rulebook in hand and a complete game at their disposal, Jonny and Casey spent several months developing levels for a new Wind-up Knight game.  The prototyping phase was much more focused, as the core mechanics were already established and implemented as production-quality code.  Furthermore, these levels were designed without the crazy time pressure of the first game; Casey and Jonny have been able to experiment with lots of ideas and then keep only the very best.  They produced almost 100 levels, then cherry picked the most fun of the lot.  When Mike and I joined their team to work on WUK2 full time, the game was already playable from beginning to end.

In total, Wind-up Knight 2 will probably take slightly longer than its predecessor for us to complete.  But the manpower is being spent in very different ways; this time around there’s a lot more space for pushing the content envelope and polishing the design.  We’re still working hard to get everything finished by the time we ship, but the core game has been rock solid for months.  It’s a design process that feels very different, probably one that only works when building upon an established game.  It feels good.



Posted in game design, prototyping, wind-up knight | 3 Comments

Wind-up Knight 2


We’ve been pretty quiet lately.  It’s been almost a year since our last game, Rise of the Blobs, and other than a few blog posts here and there (and an award or two) we’ve kept a pretty low profile.  But don’t take that to mean that we’ve been lounging around; the truth is that we’ve been working so hard that we haven’t had time to come up for air.


Today I am excited to be able to finally tell you about one of the things we’ve been working on: Wind-up Knight 2.  Wind-up Knight was Robot Invader’s first game, and since its release in late 2011 nearly 10 million people have played it.  Fans have contacted us from around the globe (the US represents only 1/4th of our user base!) to ask for new levels and expansions.  But we’ve done better than that: Wind-up Knight 2 is an entirely new game.  We’ve put so much insane stuff into it that even our most veteran players, the folks who beat Turnover’s Fair Play without rotating their phone, will be surprised.


We have a lot more to tell you about Wind-up Knight 2, but we’ll save it for the coming weeks.  Wind-up  Knight 2 will be gracing phone and tablet screens around the globe early next year.  Keep up to date with our progress by following us on Twitter or Facebook.


Posted in Android, iOS, mobile games, Uncategorized, wind-up knight | 5 Comments

Porting Wind-up Knight to OUYA


Wind-up Knight has just shipped for OUYA. It runs great on the console and is really fun to play with a controller. If you have an OUYA, go check it out! If you don’t have one, $99 is totally worth the price of admission for a cheap, hackable, indie-focused Android game console.

Despite the title of this article, Wind-up Knight isn’t really a port.  The binary we ship is almost identical to the one we distribute on Google Play.  It’s trivially easy to take an existing Android game and boot it up on an OUYA, especially if you already have support for controllers. That said, getting Wind-up Knight ready to ship for the platform took a bit longer than I anticipated, so I thought I’d document some of the work required.

Controller Support

Wind-up Knight has had support for physical controllers since its initial launch. It supports the Xperia Play and is playable with Bluetooth HID controllers like the Nyko PlayPad Pro or MOGA.  This support is based entirely on standard Android APIs, so even controllers that we never had access to during development, like the Japanese SMACON, work great.  As an aside, the absolute best device to use for controller development is the NVIDIA Shield.

Because we already had support for controllers, Wind-up Knight was playable on our OUYA immediately.  We just pushed our existing executable (the one distributed on Google Play) to the device with adb install and it ran almost perfectly.  Though OUYA provides a library to help with controller support, there’s no need to use it: the OUYA controller reports as a standard HID controller, and can be supported with existing Android KeyEvent and MotionEvent APIs.  We ended up only using the OUYA SDK to do OUYA-specific things, which is pretty much just the billing API for in-app purchases.

Though Wind-up Knight was playable right off the bat, it wasn’t ready to ship.  There were a number of controller-related issues to solve.  First of all, two of the buttons on the controller were swapped, and the DPAD wasn’t working.  After a lot of research, we tracked this down to a bug in Unity.

In order to support older devices, Unity’s Android controller implementation uses low-level Linux APIs to read button states.  However, the mapping of buttons to Unity inputs is not guaranteed by these APIs.  You can specify a Unity button called “joystick 1 button 1,” but there’s no guarantee that this button will be the same one that generates the Android key event for KEYCODE_BUTTON_X, which is what we would expect.  You might have two controllers with identical button layouts that report identical key codes, and Unity may still map them to different buttons in its Input system.

To work around this we need to ensure that Unity is looking at the key code rather than actual hardware information.  We do this by overriding Activity.dispatchKeyEvent() in our Java layer.  This function is called as keys are delivered to the application, and provides a spot where we can transform (or even consume) key events before they reach Unity.  In this function I look for KEYCODE_BUTTON_* and DPAD_* events and transform them into new events that map to keyboard buttons (e.g. WASD).  This forces all controllers into a standard key mapping, which we can easily manage with Unity’s Input API.  Synthesizing KeyEvents also clears the hardware reference information that comes with controller key presses, thus preventing Unity from using unreliable lower-level APIs to read the hardware.

With this change our controller mapping for all controllers, including the OUYA’s, is the same.  Fortunately, the mapping of MotionEvents to analog sticks appears to be reliable across all controllers, so using standard Unity Input APIs for analog axes works fine.

Apparently there is some Unity plug-in specifically for OUYA controller support, but I don’t really see the point; I want a solution that works for all controllers and isn’t device specific.  Our approach didn’t require any changes to our Unity game at all–it’s confined to Java land.

User Interface

Once our controller support was sorted, the next step was to make all of our UI controller-capable.  This is actually a lot more work than I expected.  Though we use standard Android APIs for most of the menus in Wind-up Knight (I wrote about that system a few years ago), I still needed to go through all of them and ensure that buttons could be selected, that focus moves through multiple buttons in predictable ways, and that screens without obvious buttons (such as the Armory) had special case code to allow complete manipulation without a touch screen.  Furthermore, in the bits of UI that are done within Unity (such as the level select screen), I needed to add code to support focusing in on things that one would normally just touch.  I budgeted a week to do this work and it ended up taking me two; even with a relatively UI-light game like Wind-up Knight, going from a touch interface to a controller interface is a lot of work.

OUYA’s controller also supports a mouse pointer, and I assumed that I’d be able to fall back on that if absolutely necessary, but that plan didn’t work out.  The pointer doesn’t actually simulate touch events at the Activity level, so while it can be used to click on buttons in normal Android UI, Unity doesn’t see it at all.  I suspect this is implementation is the standard Android pointer implementation, and not something that OUYA invented, but either way it is unfortunately restricted.

Also important to shipping on OUYA was removal of most things that link to web pages.  For example, we have links to Facebook, Twitter, and Google+ on the Wind-up Knight main menu.  This makes sense on a phone or tablet, but not on a TV game console: the user probably isn’t interested in tweeting from his OUYA.  Those buttons had to go, as did links to things that require Google Play (such as the Google Play game services button and links to Tapjoy offers).

Our first submission to OUYA was rejected because we had neglected to move some UI elements away from the side of the screen.  The size of the visible area of the screen varies greatly from TV to TV, and to ensure nothing is cut off it is important to leave a 10% buffer of open space on all sides of the display.  Fortunately it was pretty simple to pull all of the UI in (I just inserted a FrameLayout with a 10% margin into the root of my Android UI when running on OUYA), so this didn’t keep us down for long.  But it’s definitely something to consider when developing for TVs.

Finally, the in-game HUD was hidden for the OUYA version.  Normally the HUD indicates buttons where the player will place their fingers, and is completely unnecessary when playing with a controller on a TV.  On the OUYA version of Wind-up Knight, we only show the buttons during tutorial sequences, and even then we show controller button images rather than the icons that are displayed on phones and tablets.

One last gripe about UI: the OUYA buttons themselves are annoyingly named “O U Y A” rather than the standard “A B X Y” format specified by Google.  We had to create special  graphics to indicate the correct buttons, which widened the size of our otherwise small OUYA-specific footprint.

Other Things

The other bits required to finish off the OUYA version of Wind-up Knight, such as integration of the OUYA billing system and minor additions to the Android manifest, were extremely simple and straightforward.

One strange aspect of OUYA development is that the launcher requires an internet connection to correctly show development builds.  If your internet goes down, you’ll get an error (and a nice exception in logcat) when trying to launch your game.  We worked around this by using the adb shell am start command to launch our development builds from the command line.


Bringing an existing Android game to OUYA requires almost no OUYA-specific work.  There is work to support controllers, and significant work to convert touch-based UI to a controller UI, but none of this work is specific to the OUYA itself.  Considering the plethora of other controller-based devices running on mobile hardware that have been announced this year, adding support for controllers and TVs to our games seems to make a lot of sense.  For Wind-up Knight, we were able to make our game run great for OUYA with changes that are applicable to all kinds of other potential future devices.

For now, the OUYA is really the only device in its class, and Wind-up Knight is really awesome on it.  Our hope is that it is the canary in the coal mine, and that it will usher in a new class of microconsoles that are easy to develop for and ripe for independent games.  I’m really happy to be able to support this effort so easily with Wind-up Knight.

Posted in Android, game engineering, wind-up knight | 2 Comments

Free-to-Play is A-OK


Let’s talk about free-to-play games.

I mean, really talk about them.  Pick them apart. Analyze them.  Maybe even learn a few things.

Because sometimes I feel like talking to game developers about the topic of free-to-play games is like talking to a brick wall.  ”I don’t play free-to-play games,” one developer, who’s work I really respect, told me smugly when he learned that our games cost nothing to try.  His game, an XBLA title, costs nothing to try either.

I don’t think we even agree on what “free-to-play” means.  I think it means “a game that you can play for free that also has things you can choose to buy in it.”  But when I floated that definition on Twitter, a number of people disagreed.




(thanks to Teut and Raph for humoring me on this point.)

I’ve noticed that developers tend to get themselves worked up over a specific free-to-play implementation and then, rather than take that particular design to task, turn around and blast all “free-to-play” games.  You hate Farmville because you see it as a Skinner box thinly disguised as a game, created for the express purpose of extracting money from its player’s wallets.  Fine.  But what does Farmville have to do with Temple Run 2?  Or Real Racing 3?  Or The Walking Dead?  These are all free games with in-app purchases built into them, but they have very little in common.  Too often the conversation ends before it starts with arrogant platitudes like “I don’t play free-to-play games.”

Welcome to the Dark Side

Thankfully some developers are willing to dive deeper.  Charles Randall’s post on this subject is incisive because he captures the essence of what bothers many game developers about free-to-play games.

Charles manages to side-step a big red herring: the mechanics commonly used in free-to-play games.  It’s not energy systems or grinding or unlocking content or wizard hats or consumables or in-game currency that bothers him.  After all, every one of those mechanics can be found in traditional paid games, and thus can be justified absent monetization.

Rather, it’s the idea that a game that asks for purchases in the midst of play just might be designed to manipulate you into paying.  Charles sums up this general uncomfortableness well:

Beyond these issues, there are the questions that F2P games raise in my mind while I play. How can I know that I am not being manipulated? If I am playing the game, but it gets grindy, and there are purchases which will alleviate the grind, what were the reasons for the grind in the first place? Did the designer believe that the grind was the optimal path for the game to be engaging, or was the designer making conscious decisions based on conversion metrics?

The problem, according to this point of view, is that even if a particular game element (say, grinding) has real game design utility, the very existence of in-app purchases causes players like Charles to wonder if the element was inserted just to make money.  The design has been tainted, or “corrupted,” as Charles would say, by the need to monetize.  This is, I think, a very common view amongst traditional developers.

I also think it’s a pretty weak argument, for several reasons.

First, the basic premise of the “f2p corrupts game design” argument is that paid games are different.  It assumes that traditional games do not include elements that have no purpose other than increasing the developer’s bottom line.  This is, of course, completely false.  Why do so many console games feature women in skimpy armor?  Why would a developer ever bother making a game featuring somebody else’s intellectual property?  Why does Alan Wake have ads for Verizon, why does Peter Parker’s camera say CyberShot on it, and why does the loading screen of Wipeout 2 feature the Red Bull logo?  Heck, why do we need better graphics in our game devices?  Developers may not think about it this way, but traditional games are designed from the ground up to be financially successful.


Game design: corrupted!

Of course, there are some games made without any concern for future profit.  I’m a big fan of Tale of Tale’s work, for example.  But this is probably not what developers have in mind when they are thinking about the general merits of paid games compared to free games.  The truth is that all commercially produced games are influenced by the need to be profitable.  Whether it manifests as a character design (would God of War have been successful without Kratos?), superfluous sex appeal, reliance on a licensed character, or graphics tech to meet customer expectations, it’s always there.

And because it’s always there, it’s better thought of as a design restriction than as a problem.  If your publisher tells you that market research has shown that the your new PS4 game must include elves, gangbangers, and a nail gun, you do your best to figure out how to make the best game you can within those restrictions.  And guess what, that’s what goes into making a free-to-play game too.  If your market research shows that paid apps on the iTunes App Store and Google Play are dead (they are, but let’s debate that point in a future post), your challenge is to make the best game you can within the format that the market accepts.  Your monetization scheme, much like your control scheme, is a design restriction that you must work within.  That there are restrictions that relate to your bottom like is a fact of life for all game developers, regardless of platform or price tag.

Importantly, this doesn’t mean that you must trade fiscal viability for quality.  Many games do make that trade–I’ve worked on enough licensed character games to know exactly what that entails–but it’s not a requirement.  Many developers are able to create financially successful games that are also quite good.  The fact that money must somehow be made, and that the need to make money will inevitably influence design, is nothing new.  It’s just one more design restriction within which a designer must operate.  A mark of a good designer is one that can make a fun game given numerous restrictions.

Let’s take this a step further.  It’s better to think of free-to-play mechanics as a design restriction because it results in a specific player behavior: strategizing.  The folks playing free-to-play games are not the Pavlovian dogs we sometimes portray them as, listlessly clicking their way through CSR Racing and happily plunking down cash for the privilege of clicking faster.  Playing a f2p game seriously is all about figuring out how to get as far as possible by spending as little as possible.  It becomes a hardcore min/max strategy game, and figuring out the strategy is really fun.  Games like The Sims boil down to a mundane operation loop within a progression arc that the player is attempting to optimize; it is figuring out the parameters of that optimization that provides most of the enjoyment.  The same is true for free-to-play games: adding purchases into the mix gives the player an axis to strategize upon, and when it works it’s really fun.

Of course it doesn’t always work, and not all free-to-play games are fun.  But the point is that the monetization aspect of these games is absolutely a participant in the greater game design balance.  In fact, in my experience it’s by far the most difficult part of a free-to-play game to design.  The restrictions imposed by f2p are dramatic.

Winner Take All

Speaking of balance, Charles goes to some length to make his complaint specific to games that have purchases that “affect the balance of the game.”  That is, games that allow the player to somehow get ahead by buying stuff.  I appreciate the point; Charles is actually drilling down into the things he doesn’t like rather than writing everything under the f2p banner off.  But his complaint hinges on a couple of assumptions that seem pretty rickety from where I sit.


She probably bought upgrades for those arms.

First, Charles notes that pay-to-progress is “corrupting” in games that feature competition between players because the competition is no longer honest.  I don’t disagree in principle, but this is hardly specific to free-to-play games.  By that logic, performance-heavy multiplayer games like Far Cry 3 must also be a “corrupted” design because the player who can afford the fastest PC and the best network connection has the edge.  It also assumes that purchases that power the player up will always result in winning, while most multiplayer games I know maintain a delicate balance between skills and stats.  Not to mention the existence of intelligent match-making systems designed to pit players with similar stats against each other to maintain fun.

Second, this argument seems to have no bearing on games where the purchases are not directly related to “triumph over a player” that is playing for free.  I can pay to buy a crystal in Triple Town so that I can improve my town, but no other player is affected by that action.  Even in multiplayer games, there are many examples of purchases that are about convenience for the player rather than competition with another.  I have a friend who regularly buys World of Warcraft gold from China because he just doesn’t have much time to play and wants to go on raids as a leveled up character.  This hardly ruins the game for other players.

In fact, I think we can expand upon this idea to find the fundamental disconnect in Charles’ argument.  At the core of this discomfort that he describes is the assumption that the goal of a game is to win.  Paying to win just feels, well, like a bit of a cop-out.

The thing is, the majority of successful free-to-play games cannot be won.  They are endless.  Winning isn’t the point.  In fact, the audience for these kinds of games isn’t playing to win at all.  They are playing to have a good time.  They are playing for enjoyment of the moment.  They went to the movies instead of purchasing the Blu-ray; buying some popcorn while they’re there isn’t weird, doesn’t mean they’ve been taken advantage of, and doesn’t turn the theater into a casino.

I am the Audience

I think that some traditional game developers and hardcore gamers haven’t figured out that there’s a new audience for games yet.  An audience that doesn’t share their tastes and has a wholly different idea of what games are worth.  An audience that the traditional game industry has repeatedly failed to reach for thirty years.  An audience that likes to be able to try things out for free and then make their own judgements about whether or not potential purchases are worth it.

I also think that many traditional developers shy away from having to participate so directly in marketing.  That’s what a lot of free-to-play design is: marketing to try to get the player to want to spend money.  In the traditional game space, marketing is always handled by somebody else, usually off at a publisher somewhere, often demonized by the team.  So it’s natural that traditional devs are wary of stepping into this role, especially when it effectively becomes a part of the core game design.  But of course, marketing is a fundamental component of all successful games.


What most of us think about when we think of marketing.

The point isn’t to paper over the offensive things that some free-to-play games do.  I just don’t think that free-to-play game design is intrinsically evil, or corrupting, or actually all that much different from all the other stuff that already goes on in the game industry.  There are plenty of paid games that I find offensive as well, but I also know that they are not representative of their price point or platform.  Packaging up a bunch of games and categorically declaring them to be the online equivalent of casinos because they can be played for free is, in mind, a gross generalization.  Worse than that, it’s a meme that blinds people to the actual merits–and problems–with this type of game.  It’s a stereotype, a way for people to stop thinking about things they are not initially comfortable with, a way to casually dismiss them with “I don’t play free-to-play games.”

How’s this for an alternative theory: traditional game developers look at some popular f2p games and find them lacking.  The graphics are bad.  The game play is simplistic or almost non-existent.  It’s a knock-off of a better game from fifteen years ago.  And then they see that some of these games are making insane profits.  Inconceivable profits.  And to the seasoned developer, who has excellent taste and experience in video games, the only possible explanation is trickery.  The players must be getting duped.  It’s the only way to square the apparent popularity with apparent lack of compelling content.

But really, it’s just a matter of taste.  Traditional game developers who dismiss f2p are like hardcore wine connoisseurs complaining about the popularity of Trader Joe’s Two Buck Chuck.  By writing off the entire category these developers miss the nuance.  They miss the opportunity to learn about a different kind of game design.  They miss the opportunity to speak to an audience that does not care for traditional video games.  Worst of all, they miss out on some great f2p games that have top notch production values because they’ve decided that the problem is the price point.

I have eight different consoles connected to my TV.  I own (and have played to completion) hundreds of console games.  But I’ve also spent more on free-to-play games than console games so far this year.  Which box am I supposed to fit in?  Am I a wine connoisseur or a two-buck-chucker?  I don’t even drink!

Posted in game industry, mobile games | 6 Comments

Rise of the Blobs


Robot Invader is staffed exclusively by veterans of the console game industry.  Our team of five has shipped over 50 console games between us, and we worked together on many of those titles earlier in our careers.  When we developed Wind-up Knight in 2011, we were working within a genre that all of us had prior experience with, and as a result it was a straightforward (though not necessarily easy) game to build.  Wind-up Knight now has close to seven million total downloads, and player reviews on both Google Play and the iTunes App Store are glowing.  We’re very pleased with its success.  But for our second game, we decided to create something completely different.

Robot Invader’s second game is called Rise of the Blobs.  It’s a fast-paced arcade puzzle game, and it’s probably not what you expect.  We’ve played a lot of puzzle games on our mobile devices, and gotten completely hooked on a few.  But Rise of the Blobs is something else.  It’s easy to play but crazy challenging in the end game.  It’s got loads of depth and strategy, and we’ve added alternative game modes that change the nature of the puzzle significantly.  This is not a genre that we’ve worked in before; it’s a design that we unearthed rather than one we conceived.  Rise of the Blobs is the product of almost a year of iteration and development, which more than twice as long as the time we spent on Wind-up Knight.  It’s a puzzle game unlike any that we’ve ever seen.

You can read more about Rise of the Blobs, and it’s available now for free on iOS and Android.  Here’s a teaser video to give you a little taste of what it’s like.

Please give it a shot.  We’re very excited to finally have it available to the public.

Posted in Android, iOS, mobile games, rise of the blobs, Robot Invader | 8 Comments

The Future of App Stores (and the history of video)


I grew up watching movies.  Mostly on video tapes, which came in hard plastic cases from a place called Flicks & Pics a few blocks from my house.  Flicks & Pics was something of an institution in my neighborhood; it was a mom-and-pop rental joint with about twenty thousand VHS tapes in stock, organized by genres like “Action,” “Noir,” “Cult,” “Classics,” and even “Stinkers.”  On Tuesdays you could rent any movie in the store for a dollar, and the owners refused to charge for movies that starred Brooke Shields.  I watched Akira, The Maltese Falcon, Strangers on a Train, and Blood Simple on Flicks & Pics tapes.  A Taxing Woman, Beverly Hills Cop, Drunken Master 2, City Lights–the list goes on.  You selected a video by finding its box on the shelf and taking the tag hanging under it to the register; if no tags were present, all copies were already rented.  This system meant that even minor films for which only one copy existed still got the same amount of shelf space as the latest summer blockbuster. Some films even bore small stickers with comments from employees, inviting you to take a chance on a feature you might have never otherwise considered.  It was always easy to find something new at Flicks & Pics.

Then, sometime in the early 1990s, Blockbuster arrived in town.  I visited it shortly after it opened and was impressed by its large size and volume of titles.  But upon closer inspection I noticed something strange: Blockbuster always had twenty or thirty copies of the latest hit, but every other film in the store seemed to be some Grade Z schlock that I’d never heard of before.  The oldest films in the store were made around 1982; not only did they not carry High and Low, they didn’t even have a foreign section!  Instead they focused on a narrow selection of big budget flicks and padded the rest of the store out with soft porn and “films” like Ninja III: The Domination“Who rents this crap?” I wondered.

I later learned that Blockbuster’s business model operated on deals with the movie companies.  In exchange for discounts for the big-budget, heavily marketed films, Blockbuster agreed to supplement its stock with direct-to-video movies that had been produced with almost no budget.  The theory, I guess, is that the big titles would draw people into the store and eventually they’d rent some of the schlock.  Since the schlock was so cheap to produce, Blockbuster’s guaranteed purchase of a certain amount of it was a good deal for the movie companies.  And for Blockbuster it allowed them to fill their catalog at low cost while ensuring that they always had films less than a year old in stock (this is called, apparently, “depth of copy”).

Blockbuster (and its twin, Hollywood Video) rolled into towns across America and pretty much put an end to local mom-and-pop video stores.  Several in my town gave up the ghost after the big B arrived.  But Flicks & Pics survived.  Small as it was, it catered to a crowd that was looking for films they couldn’t find at Blockbuster.  What gave that neighborhood video store staying power was the way it was curated; the selection of films, complete with staff recommendations, made it a goldmine for people who were ready for something a little more challenging than Red Shoe Diaries.  Flicks & Pics had “breadth of copy;” while not every film was good, there was always something new to find and the chances of renting a real train wreck were pretty low. When the store finally went out of business in 2007 (long after the local Blockbuster had become an empty, derelict building), it was because the VHS format was no longer viable.  Advancements in technology dealt the blow that the big chain stores could not.  When the store closed there was a sort of community vigil in the parking lot.

The lesson here is applicable, I think, to modern app stores.  We have a problem very similar to that faced by video stores in the 1990s: the volume of apps is now so immense that an unfiltered catalog is impenetrable.  iTunes and Google Play both do their best to surface the content of their catalog to users, but they don’t have the virtual shelf space to promote every high-quality app.  They probably don’t even have a good way to identify high-quality apps (especially since the Apple review board apparently spends in inordinate amount of time trying to ensure that no screenshots containing male genitals are approved).  Users have become wary of spending money on apps they haven’t tried because the crap apps are right there in the database along with the good ones.

The volume of apps has made visibility the #1 problem for developers to solve.  The rise of free-to-play isn’t just about new monetization schemes–it’s a way to lower the user’s perceived risk and thus get more people to give the game a chance.  All the social media integration in games lately serves as another way to get noticed outside of the stores themselves.  These sorts of alternate approaches are increasingly necessary because even with promotion by Apple and Google, high quality paid games aren’t being purchased anymore.  You might have built the Citizen Kane of mobile apps, but it’s unlikely to gain traction while wedged between You Got Served and Battlefield Earth on the shelf.  We need a filter.  A way to more effectively separate the wheat from the chaff.

Blockbuster’s filter was pretty simple: let the market(ing) decide.  The chain would observe which films did well at the box office and then ensure that they had enough to satisfy the high customer demand for those films immediately upon the video release.  Depth of copy: they focused on having a large number of a few recent hits because that’s what customers generally wanted.  And of course, customer demand was driven by marketing campaigns paid for by the production companies.  Money goes into marketing, marketing drives demand, demand drives investment by places like Blockbuster.  And for everything else, Grade Z apparently sufficed.

The App Store today is admittedly kinder than Blockbuster’s model.  Apple and Google make valiant attempts to promote content that they think is high quality, and this helps offset the necessity for heavy marketing.  It’s still possible for an app or game without mega marketing dollars behind it to become a hit.  But as the volume of apps increases, and as users become increasingly risk averse, mega marketing is becoming more important.  Promotion by Apple and Google is unreliable; developers with the cash are investing heavily in marketing to avoid being drowned in the stream of new releases.  As in every other medium, marketing works.  Marketing, or including an already well-marketed brand, seems to be the only way to make a paid game viable on the App Store today.

But the problem with the marketing-driven model is that it favors the developers who have giant money bags to throw at marketing.  If a huge marketing spend is required for success, only companies that are already rich will be successful.  The app stores have been a democratizing force, especially in the game industry, because suddenly small developers and independents have found themselves on equal footing with the big guys.  If Google Play and the App Store stay the way they are now, I think that the large companies will smother everybody else.

But what if we had something a little bit more like the model employed by Flicks & Pics? A breadth of copy model, where the entire catalog–not just the boxes in the window–is selected with a certain audience in mind.  Valve’s Steam seems to prove that this model can work and be highly profitable, but there is a big difference between what Valve does with its store and what Google and Apple do with theirs.  The audience for games on Steam is extremely well defined: they are PC gamers who like Valve games.  From that you can extrapolate which types of products are likely to do well and which are likely to fail and thus apply a content filter fairly easily.  Apple and Google, on the other hand, must address everybody who has a phone.  Which is to say pretty much everybody in the world.  That’s a lot harder filter to design.

Apple and Google do promote apps that they select based on some secret criteria.  But hand-picking content isn’t going to cut it in the long run because the process just doesn’t scale.  Back when people browsed the web with Netscape, Yahoo was little more than a directory of web pages.  A phone book of links, organized by hand into categories and sub-categories that could be easily clicked through.  Yahoo’s viability fell through the floor when Google came out because its hand-built index only represented a small portion of the web.  Google, on the other hand, could search for anything.  You know what happened to those two companies after that.

We need a an app store that operates like Flicks & Pics did, a breadth-of-copy approach that is designed to introduce new content to specific types of users.  But gone are the days when this is a task that can be performed by hand.  We need a system that suggests different apps to different users, one that considers quality metrics other than raw downloads.  A way to ensure that users can find apps that marketing has got them excited about, and a way to expose those same users to apps that have no marketing.  A system that exposes unknown gems to enough people that they have a chance to become a hit.  If Steam is a store for PC-gamers-who-like-Valve-games, we also need a store for young-adults-who-like-mysteries and middle-aged-parents-who-enjoy-travel and children-who-like-outer-space, etc, etc, etc.  Simple categories don’t cut it.  Top 10 lists don’t cut it.  There’s so much content on the app stores now that we need smarter systems to browse it.

Perhaps Apple’s purchase of Chomp will eventually cause the App Store to evolve into something smarter, something more dynamic, something less controlled by marketing alone.  I sure hope so.


Posted in Android, iOS, mobile games | 7 Comments

Playing the Story


Last week David Jaffe, the outspoken designer of tons of games including God of War and Twisted Metal, gave a speech at DICE about how games and stories are incompatible.  The coverage of the talk makes it seem pretty cut and dry: David Jaffe hates stories in games and thinks they are a waste of time.  IGN reported that Jaffe “made a compelling argument against stories in games.”  Even the transcript of the talk bears the headline David Jaffe explains why games shouldn’t have stories.

Any argument against stories in games is guaranteed to spark controversy, which Jaffe’s talk did.  There are so many examples of excellent games with great stories that it is easy to attack Jaffe for saying the two cannot be combined.  And hey, it’s an argument that has been waged across the internet tundra for years already, so it’s bound to drive hits.

But despite all the press, that’s not really what Jaffe is saying.  Rather than condemning stories in games, Jaffe is issuing a warning to game developers who dream of emulating their favorite films not to forget which medium they work in.

What Jaffe is actually talking about, I think, is a very specific group of games that are not just laden with cinematic story telling, they actually appear to be more interested in the story than the game itself.  He is complaining about developers who have been “seduced by the language of film” to such an extent that it impairs the core gameplay of their games.  I bet Jaffe isn’t a big fan of Heavy Rain or Metal Gear Solid 4.   The danger that he alludes to is the siren song of being a movie director, of having the chance to sit in the big story telling chair and then crashing into the rocks when we focus so much on narrative that we neglect the part where the player actually does stuff.

Boil this down and it’s not an argument against stories in games, it’s an argument that gameplay must take precedence over all other elements.

That’s an argument that nobody disputes.  Well, I take that back.  There are probably some “serious games” folks and some Facebook developers who place value in games that have no play.  But generally, the idea that gameplay is the core foundation of the medium is, I think, common sense.  The problem is that Jaffe seems to be casting narrative as antithetical to gameplay, and this is what causes people to bristle.  But really, the core message here isn’t “get rid of stories,” it’s “don’t trade gameplay for story,” and “don’t trade gameplay for the chance to act like a sexy Hollywood director.”  I think you could probably just generalize that and say “don’t trade gameplay for _____.”  Nobody is going to argue with you on that one.

The details, however, are full of little horned men with pitchforks.  What is “gameplay” anyway?  Are we talking about the mechanical mapping of button presses to simulated actions?  Are we talking about the formulation of tactics before the actions themselves are executed?  Is it the rules of the game, or the space for player expression within the rules?  Is the gameplay in Monopoly the act of selecting which properties to buy and develop or the art of wheeling and dealing?  Or maybe the rolling of the dice and placement of the figure?

Where is the line between the game system and its contextual content? If the gameplay of Clue is to collect enough information to reliably name the killer, why is the same operation not called gameplay in Heavy Rain?  Rock Band would certainly not be fun without its mechanical timing and rhythm challenge, but the mechanics alone wouldn’t be compelling without its excellent music catalog either.  There’s a novelization of ICO by an author that I like, Miyuki Miyabe, but ICO isn’t a story I want to read–it’s one I want to play.

Maybe these definitions are hard because we’re trying to pin a single word on a medium that is full of different kinds of interactivity and expression.

I had something of an epiphany a while back when, after years of studying Japanese, I finally figured out what the word omoshiroi (面白い) meant.  My dictionaries all defined this word as “funny or interesting,” and this definition always bothered me.  ”Funny” and “interesting” are two completely different states of mind!  I think Backus–Naur Form notation of language grammar is pretty interesting, but nobody in their right mind thinks BNFs are funny.  I had a hard time using this word until it finally hit me that omoshiroi actually means “not boring.”  Anything that isn’t boring can be omoshiroi.  In fact, the word is defined not by a specific form of entertainment, but simply by its negation of banality.

You know what?  ”Gameplay” is the same.  It’s the stuff that the player does while playing the game that is not boring.  I think where we get bogged down is in the idea that “gameplay” must mean “mechanics” or “rules” or “strategy” or any other single thing.  Gameplay is that which engages the player.  It might be timing our jumps correctly, or lining up a perfect combo, or deciphering who killed Colonel Mustard in the conservatory with the lead pipe.  Gameplay is figuring out who or what Pyramid Head represents in Silent Hill 2.  It is managing relationships in Fallout 3, aiming fowl in Angry Birds, and sword fighting with insults in The Secret of Monkey Island.  Gameplay is pounding your finger into your controller and screaming at the top of your lungs to make Old Snake crawl through an irradiated tunnel to avert nuclear war.  It’s the meat of what games are, and it’s made out of all of the bits games have at their disposal, including narrative.  If it’s good, gamers are engaged and entertained and not bored.  And if it’s bad, playing is a waste of time.

Jaffe is right: don’t trade gameplay for anything.  But don’t let that stop you from making gameplay out of stories.

Posted in game design, game industry | 8 Comments