Don't miss
  • 12
  • 6468
  • 6097
  • 20

Player driven development

By on May 20, 2014
Print Friendly

In this guest post, Oscar Clark reflects on a conversation he had with Playstation Home’s Katherine de Leon at the Digital Dragons conference in Krakow.

The Lean Start-up by Eric Ries has had as much a profound effect on my thinking as a Raph Koster’s Theory of Fun. They both transformed my understanding of making games.

At its heart the idea behind the Lean movement is simple. Rather than building everything before you release, try building a smaller, self contained hypothesis and check that the audience get it. Lean asks us not just to reduce our initial exposure, but also to test our ideas on our market as early as possible and listen to the results. You can’t test if you don’t have a single measurable idea and relevant metrics. The Minimum Viable Product idea doesn’t have to mean basic or buggy. It just means that it’s a clearly differentiated proposition: a single testable idea. Perhaps we should call it the Minimum Awesome Product.

This idea of a single proposition is difficult for many games developers, especially those used to the retail model, where the principal delivery was a gold-mastered disc sold in a plastic case, and the experience had to be complete and fully rounded. The effort to break such a project into its deliverable components would self-evidently lead to more unnecessary work — wouldn’t it?

Katherine used a great analogy for that. Sending letters. If we have 300 letters to send on the surface it makes more sense to create a production line to print, then place in envelopes, then to lick stamps, send them out etc. But the trouble is we don’t know if the letter we have written will have the effect we require. If we find out it’s wrong with the 1st envelope sent, we have then have to got back and redo all of the others before we send them out. A lot of wasted work. Think of the recently rediscovered landfill of cartridges for the failed ET game.

Testing itself isn’t easy either. The answers won’t just pop out of the data; assuming we are even capturing the right things. We have to know the right questions to ask.

Qualitative analysis allows us to understand how a focus group of players feel about your game; but quantitative means you measure how much impact that emotion has on your games success. However, neither matter without good insight and game design instincts to back them up. A lot of fatal mistakes happen either when designers ignore data or let data override their instincts. We can’t afford to start treating data analysts as god-like figures; as much as I admire and enjoy working with them, they can’t guarantee success.

On the other hand, testing and iterating should be new for most game developers; we do it all the time. It’s what play-testing is all about. It’s how we find the fun. The Lean approach just asks us to keep doing it beyond the concept stage and to make each stage about single ideas we can isolate. But the hard part is that we have to put that in front of real people. The trouble is the artist in us all makes it hard to share something we feel is unfinished. Releasing the game in a simplified form even when perfectly formed can still feel incomplete. Indeed, if it doesn’t that probably means you’ve left it too long. This can just feel wrong as many designers when asked when they know the game is done will reply “When the marketing people prize it from my cold dead hands”

This I think is the problem with Lean. It may make emotional sense. It may make business sense; but it feels like you are prematurely releasing something that you know isn’t good enough (yet).

However, if you do surrender to that fear and try it anyway something magical happens. You discover that the design process is never finished and better yet; you get to continue to tinker.

You discover that having data on how people react to your designs enhances your insight and design vocabulary. You never have to “kill your darlings”, so those favourite features you really want to make need never be dropped into the bin… they just continue to be deferred to later releases.

In short Lean Methods actually gives designers more control over their creations not less. It may sound emotionally counterintuitive, but this way can free you to make better games.

About Oscar Clark

  • The lean approach as taught by Steve Blank, is by far the best way of understanding the market, I have worked with.
    We use it in all part of our Mobile Game development, to the extend of our knowledge. (really need to read “Lean Analytics” by Alistair Croll)

    Our next game “untitled” will take the lean approach to a new level. A decision made, because of the feedback and involvement we are getting from our hypothesis testing.

    Maybe Munly, you should look at it differently, as it is not about wonder and surprise. It is about asking your costumers, what they need and giving that +more to them. Often they say what they need, without knowing they said it.

    But all in all, I have to say that I am all with Oscar and Nicholas on this one.

    link to book:

  • The problem with the auteur theory is that it is hard to tell the difference between a brilliant auteur who will make great art and lots of money for thebackers, and an idealistic dilettante who will fail to deliver an artistic vision, or even a product, while bankrupting those who support him or her.

  • Munly Leong

    Nope I’m already pretty well acquainted with it. In games its hard to really validate things internally. The industry would be better served with designers who can iterate in their heads and/or on paper as much as before pushing work out to production teams. Games aren’t really products, they don’t solve problems. That’s the difference. They are entertainment.

    I agree with the Minimum Awesome Product, validating core gameplay, loops and hooks can work in a lean capacity. But validating the whole thing content wise is giving away the goose. Additionally auteur theory applies much more to games than to lean startups, in a sense this is also what players are coming for.

  • I disagree, mainly because I think your definition of lean is very narrow. Lean is a way of testing your assumptions and validating them cheaply, not expensively. It can be, and is, applied widely in games. It is most useful in service-based games but can absolutely be applied to product games too.

    I urge you to go and read The Lean Startup. Because otherwise the dislike of Lean is likely to be based on half-knowledge, such as a fear that Minimum Viable Products can’t work in games (which I think is broadly true: you need a Minimum Awesome Product, and the difference matters), rather than the Lean principles themselves.

  • Munly Leong

    The fad of lean cannot be applied everywhere, especially to games. Yes we can measure ideas and iteration etc but part of the joy of games is discovering a new world, systems and so forth. If by the time you’re “done” and you’ve exposed the prospective customer/player to all of this then there’s no wonder or surprise