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

“Your problem is that you are afraid of being punched in the face”

By on August 22, 2013
Print Friendly

This was the borderline inappropriate comment that I made to a game designer at a client recently. The fact that the game designer was female didn’t exactly help my case.

Yet this is the single biggest problem facing people who move from console development to F2P development.

F2P is an early stage business. It offers something that console development, with its focus on launch day and week one sales, does not: the ability to iterate and learn from your mistakes. While the bar for a Minimum Viable Product may be rising, the concept is still valid in F2P, whereas a console game needs to have every feature and most of the content that it will ever have implemented by launch day.

This is a big change for game designers. They are used to agonising over whether a certain feature should be In or Out; now they are arguing whether it should be Now or Later.They are used to having time to debate features; now we want them in the game so that we can get metrics to inform future decisions. They are used to having to make a decision and stick to it; now they have to learn how to make a decision which might change later. They are used to having to be right; now we accept that no-one knows anything, and figure out how best to answer the pressing questions of how to make the game more fun, more sticky and more profitable by experimentation and testing.

Console developers need to do more game jams. They need to iterate faster. They need to realise that the prevarication that they think is reducing risk is in fact increasing it, by costing the studio money for every day they delay in getting the product in front of users.

Don’t get me wrong. It’s not that I think that F2P games don’t need to be polished and honed. It’s that they need that polish in different places. Above all, F2P games (and indeed any game-as-a-service, whether free or not) is an iterative experience. There will be mistakes. People will do things that don’t work out. Which brings me back to being punched in the face.

How can you fight if you won’t take a blow?


In Mark Millar’s Wanted , protagonist Wesley – a vegetarian, pacifist wimp – discovers that he is heir to one of the greatest supervillains of all time. He joins The Fraternity and (to avoid spoilers) shenanigans ensue. But before he can become a super-villain, he has to learn how to fight.

So the Fraternity lock Wesley in a room, handcuff him to a chair and get a big bloke with enormous fists to pummel him every day. Because you can’t fight if you won’t take a blow. You spend all of time trying to avoid being hit, rather than looking for the way to win.

That’s what I meant when I said to the game designer that she was afraid of being punched in the face. (To be fair to me, I had explained the Wanted analogy earlier in the day). F2P game design and agile development is about being responsive. It is not about never being wrong; it is accepting that in an creative endeavour, there will be mis-steps and you should structure your creative process around dealing with uncertainty, not pretending that it doesn’t exist.

In AAA, if there is uncertainty, money is spent to eliminate that uncertainty. More time is spent. More executives involved. Expensive consultants hire to cover people’s backsides (I appreciate the irony of this statement coming from me). The game is delayed. Operational risk may be reduced, but financial risk is increased.

In contrast, we should all just get used to being punched in the face. We run experiments. Some of them fail. We work hard to put our players first, but that doesn’t always mean spending more money; it might mean letting them show us by their behaviour what they like. We need to iterate faster, because nothing shows us the flaws in our theories like putting them into practice. We need to experiment, fail and succeed.

It’s time to stop being scared of the little failures. Ensure that a failure won’t kill you, and learn from it. Fast.

You’ll make better games. Faster. And more profitably.

About Nicholas Lovell

Nicholas is the founder of Gamesbrief, a blog dedicated to the business of games. It aims to be informative, authoritative and above all helpful to developers grappling with business strategy. He is the author of a growing list of books about making money in the games industry and other digital media, including How to Publish a Game and Design Rules for Free-to-Play Games, and Penguin-published title The Curve:
  • I don’t think it is a less of an issue for F2P designers, but this is particularly aimed at former console devs becoming F2P devs.
    And you are right, I don’t speak about core gameplay. In my experience, former console devs are excellent at core gameplay. Their weakness comes in all the retention and superfan game around it, and because they are scared, they add more and more features before launch.

  • Tavrox

    When you say : “Console developers need to do more game jams.” ; do you think it’s less valuable for f2p designers ?
    You also don’t speak about the core gameplay, you may add features over a weak core, it would never grow. Sometimes you just have to build a new game and get over the previous one. I think this is one major issue with “putting more features over time”.

  • James Young

    Great article. This shift in mentality is critical in order to have a fighting chance in the quickly evolving market of mobile f2p games.

    Part of the fear may be due to not being able to fight back. Unless a game has the foundation to be able to adjust quickly to feedback (externalizing data, event driven, etc), being able to do fast paced iteration is a non-starter. It is like trying to fight back when still bound to the chair.

    Can you recommend any f2p frameworks or 3rd party services (or combination of them) that can help studios fight back?

  • James Coote

    In principle, I agree, but in practice, and from my own experience developing on OUYA, consumers still very much consider console games as fixed products.

    Trying to sell your game as something evolving and improving (i.e. a service) against that prejudice is foolhardy at best. Especially when Sony/MS continue to perpetuate those expectations about what the “console experience” is.

    There’s other issues as well. I lose customers because downloading updates takes 30 minutes on their crappy US ISPs and they simply aren’t willing to wait that long (especially if they’re doing that once a week)

  • Oops, you are right, I would take a). Typing to fast and having an argument on Twitter at the same time.

  • Byron Atkinson-Jones

    You’d take b? I’ll admit I’m a little confused based on the context of the article.

    I prefer to go with option a, it’s how I’ve always done it in the past. However I temper it with getting a bit of play-testing first to make sure I’m not making a monumental cock-up.

  • Note that this is not a specific recommendation about when to launch, or with how much done. It is about realising that everyone has lots of assumptions, many of which turn out to be totally wrong, and that the whole of life should be about validating your assumptions and changing course if you realise that one is wrong.

    But most of us don’t like challenging our own assumptions or worldview, much as we don’t like being punched in the face. So we can never change, much as we can never win a fight, if we are so scared of challenging our assumptions that we won’t even participate.

  • I’ve got two answers to that question:
    1) This is a much broader point. It’s about learning to iterate fast and accept mistakes as inevitable. That can be entirely internal (but still a change of mindset). It can be with a soft launch. It can be with a hardlaunch. It’s a general point about failure and mis-steps being inevitable, so stop trying to eliminate them, but take advantage of them.
    2) You know we disagree on that one. Your choices: a) release early, get data, challenge your assumptions, adapt; b) release late, spend lots more money, base everything on the assumption that “you know best”, run out of money before you can adapt.
    I would take b) every time.

  • Byron Atkinson-Jones

    I get what you are saying in principle but given that you want a game to go viral through word of the game passing from person to person in a geometric progression, isn’t also true that you risk that word being “don’t play this game” if your experiment goes wrong? How often would a player who’s had a bad experience return to give your game a second chance?