- ARPDAUPosted 4 years ago
- What’s an impressive conversion rate? And other stats updatesPosted 5 years ago
- Your quick guide to metricsPosted 5 years ago
“Your problem is that you are afraid of being punched in the face”
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.