I just came across this post by Nicholas Lovell in response to Dave’s talk at the GameHorizon conference. I don’t want to get into debating all of it (obviously I disagree on the “epic fail” bit!!), but item #2 really got me thinking:
My view: different business models require different gameplay. A subscription business needs a very different set of hooks to a microtransaction business or an advertising-funded business. Trying to shoe-horn a business model onto a game not designed for it is very very hard and is likely to cause huge difficulties in the future.
I think this is very much missing the point. I wouldn’t dispute that “shoe-horning” a business model onto a game not designed for it is hard, but it doesn’t logically follow that you should build your game around a business model. I’ve no idea what Dave actually said, still less what meaning he intended to convey, but I think there are two key reasons why Dave was right (and this is all just my personal opinion rather than RTW’s).
#1 Basic economics of consumer software
Here are the variables in how much profit you make from software:
- Development cost
- Number of users
- Pricing and payment model – how much each user pays you
- Operational costs, if your software is a service (online game, website, etc)
It’s a tricky equation because they’re all intertwined (pricing affects the number of users; number of users could affect the price you think you should charge; spending extra development cost could allow you to reduce running costs, increase price or increase users; etc etc). But, a few simple observations help to clarify:
- Number of users is incredibly important. The beauty of consumer software compared to other products is its ability to scale. It costs you nothing to produce copies of the software, and the number of users has enormous scope for increase: this is the variable with the leverage in the equation, and if you want to be really successful, this is the key.
- Development cost is less important than you think, because it’s a one-off cost. I’m not saying it doesn’t matter, but it doesn’t scale. There’s a limit to what you can do by trying to play with that variable, particularly as any significant reduction is going to hurt quality so much that you fail entirely.
- Operational costs are far more important, because they do affect your ability to scale. It would obviously be a mistake to price your software below its running costs unless you had a plan to change that relationship over time.
- Pricing isn’t something you can tweak to cover your costs. Correct pricing strategy has nothing to do with your costs; it’s all about value to the consumer. So this factor is critically important, but it’s not a variable in the sense of a number that you can just play with in a spreadsheet to get the profit you want (incidentally, this fact about pricing has nothing to do with software specifically … as you’d expect, Joel Spolsky has a good article and book recommendation here). In a creative endeavour like an online game, you typically don’t know in advance exactly what the customer’s experience will be like; you don’t know what aspects of your game will be most fun. So you can’t possibly know what the perceived value will be, and it’s therefore very hard to think up-front about how you charge the consumer.
I would suggest that these four factors imply that your main “business model” concerns early in development should be, in order:
- Making a great product that lots of people want to play. Without this, you stand no chance, whereas with this, you’ll find a way to make money from it.
- Operational running costs, as these are the main thing that could prevent a great product from being profitable.
Although I have no idea how Dave and the board approached APB’s business model, I do know for sure that the development team has paid close attention to both of these.
#2 Development (creative and engineering) considerations
Naturally, you may need to build software features to support the business model, but as an engineer, I’d say these features are always likely to be more straightforward (read: lower risk) than the creative/gameplay/fun features. I would much rather focus on the creative stuff early on the project, when the time is right for heavy iteration and exploration of design space, and then build the business features near the end when you know what you’ve got. I suspect this is part of what Dave was getting at: he’s a creative person and wants to nail that part of the project above all. He understands that you can’t just plan a game design up front and implement it from a spec. You have to iterate, you have to experience what you’re building to guide further decisions.
Finally, whichever route you take, this isn’t a binary decision. There’s a continuum between the extreme positions of building a game entirely around a business model, and the opposite extreme of building a game with absolutely no thought to the business model. I would expect either extreme to be a bad idea, and I’d personally interpret Dave’s position as leaning toward one end of the scale, rather than not caring at all about the business model. The fact that we’ve managed to raise $80m of VC, and the fact that the engineering team have paid close attention to things like bandwidth, suggest that we haven’t been completely blase about the business model during development!