- ARPDAUPosted 12 years ago
- What’s an impressive conversion rate? And other stats updatesPosted 12 years ago
- Your quick guide to metricsPosted 13 years ago
Managing a Free-to-Play Product: a Publisher’s Perspective
This is a guest post by Simon Harris, Executive Producer of Digital Entertainment and Gaming at the BBC.
Nicholas asked me to write an article on the perspective of managing Free to Play titles as a publisher, rather than a developer, so here are some of the things I have learned from my time overseeing F2P products for BBC Worldwide.
FlickrCC Cornelia Kopp
The Reality of the Development Timescale
I came from a traditional, large console title developer. I was used to working with teams on a structured development cycle that led to a product release. When I moved to BBC Worldwide, shifting those methodologies to App development seemed fairly easy. Lower development costs, shorter cycles, fewer people. It still worked on the same premise, just very (very) condensed…
Then the next step was to work out how to apply that to a F2P product. Again, initially it seemed very simple. Similar time, cost and staffing as a standalone priced app, but you just have a period of time after the release of the game where you keep a small team building out new in-game content and tweaking the systems to react to the analytics reports… Boy, how wrong was that!
Experience has taught me that you never really transition through a launch and post-launch phase. So planning defined, cost-orientated phases is probably going to get you into trouble.
Lesson 1: Plan on a much longer development timescale with a larger team than you had probably initially thought especially if you are transitioning from traditional premium apps. Probably 18 months with a full team assuming a soft launch after 6 months. The release, analyse, implement, release loop for a feature will take you longer than you think, especially if you are have to build in submission times.
The significance of soft launches
No-one really actively announces “soft launches” as that sort of defeats the purpose, but I think it’s fairly well known within the industry that companies launch their F2P titles in a single territory to allow them to test the mechanics, gather some user data and possibly even start gathering some data on purchase behaviours. I thoroughly endorse this idea. If you have never released an F2P game, you are likely to be unprepared for the deluge of information and massive list of changes, features, problems and potential solutions you will generate once you let even a small, controlled number of consumers loose on your title. Do not presume that you will be able to downsize the team during this soft launch period; you will need all of them, especially on the engineering and design side, to be reacting to what you are learning and building features and content that need to be released to this group and the impact of evaluated.
The second key point about this phase is that it takes time. A lot of time. More time than you think. Even if you have the development environment, tools and discipline to be able to make an instant change to your title. Even if this change doesn’t require a new binary to go through a publisher test and release phase.
You will not want to be making multiple changes on a daily basis. You need to make specific changes, wait, review the analytics and then determine what change is required next. How big your user base is at this point will determine whether you have to wait a couple of days, a week or longer to understand the impact a change has. If you then have to start factoring in binary reviews and releases, you can be talking a two-week turnaround… All of this means that whatever time period you were thinking of for a soft launch, double it!
Lesson 2: Pushing too many changes into each build will make it hard to see what is working, especially if things need improvement.
FlickrCC Andrew Kuznetsov
After the soft launch
Your game is released to the worldwide audience, or at least the territories you would like it in. Now’s the time to downsize the team, right? Wrong! The likelihood is not that you have a great game that is raking in the money and you are just looking at tweaking a few spreadsheet numbers here and there to maximize your revenue. More than likely, you are now looking at a feature list which is greater than the one you started with and growing every week as the analytics generate new blockers, or problems which need to be dealt with in order to improve retention or monetization.
From a planning perspective, I would suggest that you have the entire development team budgeted to carry on working for at least 4-6 months beyond launch.
All of this totalled up means that unlike a traditional 4-8 month development contract for a standard app with a funded team, you are now looking at a 12-18 month funding contract for a complete team, presuming that you are looking to soft launch after 6 months. This is obviously a massive shift in terms of the potential cost of your game as a publisher.
Pre-Production
A tight and well-evaluated pre-production phase is the most vital and the clearest indication of whether you have the right ingredients for a potentially successful F2P title. If you can’t build a fun and engaging prototype within a short period of time, then you need to take a different tack or look to a different mechanic, genre or experience.
Often you believe that although your prototype isn’t engaging right now, it’s just a matter of tweaking A, adding B, or fixing C. I do completely encourage iteration, but the best advice I can provide from a publisher’s perspective is that you need to limit the number of iterations or time spent on that phase. When people say you can tell whether the mechanic is spot on from a very early stage, they are not lying. Every title I have worked on which has been critically and financially successful has been fun and engaging as a core mechanic, right from the start.
You may believe that you are always one more feature, or one more tweak away from something that is going to be great. This situation often leads the development team into a full production phase without having nailed the core mechanics and fun, which is not a great position to be in. It’s better to kill something that is not working early and for a low cost than be faced with a product that isn’t fun at the end. With F2P, this is potentially even more important because you don’t even have the chance to recoup costs from sales and if the player isn’t enjoying your game, they are very unlikely to monetise!
Lesson 3: Pre-Production is still massively, massively important. If your early builds are not fun, then fix them or kill the mechanic before moving onward. Quick, engaging fun is a pre-requisite for a successful F2P title.
Flickr CC Håvar og Solveig
Analytics
Analytics are now regarded as a baseline requirement at all stages in F2P game development; from new “design” methods that rest on spreadsheets and metrics, to a post-launch strategy characterised by data-led tweaking and balancing.
Given the importance of analytics, it always baffles me as to how many games only build them in at the end of the development phase, plugging them into capture the data for the final stages of testing and before you unleash your product on the world, ready to gather the masses of data. Why? If it’s that important, surely this should be an integral aspect of the development process from the point of the very first prototype onwards?
There is a key distinction here that I should also mention (this distinction was given to me when I first met Chris Wright from Games Analytics) and that is that what we regard as analytics is actually two things. The first is data and the second is analytics. The bits and bytes you collect via the wonders of connected devices are data. Collecting data gives you just that, data… A raft of numbers, which on their own, don’t really give you, a great deal of information until you get to the second part. What you do with that data is analyse it and the result are analytics.
It’s that second part that will actually tell you information about your title and start to highlight things you may wish to change. The key here is asking questions of your data. For this, you should really think about how you are going to staff this as a publisher. Analysing data is a skill, there are data analysts earning very significant sums of money because of their skill at understanding what data to gather and how to interrogate it. If you are planning on having an Assistant Producer review some dashboards whilst also keeping an eye on the on-going development of the title, you are very likely to be pretty disappointed with the results. You need to have someone who really understands this, either on staff, in the development team, or at an outsourcing partner.
The other key learning I have had is that you also need to have your designer(s) intrinsically involved in and working with your analysts. Often, the questions you are asking of your data will throw up problems with your game, or how your users are interacting with the game. Data won’t tell you what the best solution is; that is still going to have to come from your designer.
Take the simple example of the fact that 80% of your players are not making it to the second level of your game. Great analysis, clear problem, but what to do about it? Your design team should be thinking about what data needs to be captured, how it is captured (so your engineers can build that in) and then working on results from the analyst right from the start. This is most likely a new skill set that they won’t have encountered before, given that if they are new to the F2P world, they potentially won’t have had anything like this level of direct consumer feedback before. The earlier you can get used to it, the better!
Lesson 4: Get your data capture in from the very early stages of the game and get the design team working with the Analyst as soon as possible, it will pay massive benefits when you come to start actually evaluating real user data and trying to establish what to do to improve your retention and monetisation.
Related Posts
