作者：Simon Harris

以下是我从发行商角度对免费游戏运营的看法。

真实开发时间

我来自一家传统的大型主机游戏开发商。我习惯与团队成员有组织地在开发周期内制作游戏，直至推出。在跳槽到BBC Worldwide后，我似乎可以相当容易地将这些制作方法转移到应用开发领域。虽然开发成本、制作周期与参与人数相对减少，但我仍能在相同前提下完成应用制作，只不过它是主机游戏开发的超浓缩版。

接着，我们需解决如何运用这些方法制作免费游戏。起初方法似乎相当简单。同付费应用一样，相似的开发时间、成本与参与人员，然而，在推出该游戏后的一段时间内，你的小型团队需根据分析报告创建新内容，调整系统……为何情况会变成这样！

从我个人经验来讲，你无法通过发行与后期发行阶段完成免费模式的真正转变。因此，那些既定计划、成本开销会给你带来麻烦。

建议1：尤其当你正从传统付费游戏转变到免费模式时，你应制定出比原先想象中更长的开发时间与更大规模的开发团队。假如软发行为期是6个月，那么整个团队可能需要18个月的开发时间。某项性能从发行、分析、执行到循环发行所需的时间肯定会超过你的预定范围，尤其在你需要制定提交日期时应考虑到这一点。

game development management(from graphicdesignfans)

软发行的意义

没有人真正意识到“软发行”的意义，但我想，游戏行业人士均知道他们会在某个地区发行免费游戏，以此测试游戏机制，收集用户数据，甚至可能会从中获知某些购买行为。我举双手赞成这种做法。如果你还未发行过免费游戏，一旦你操控某个小规模用户体验你的游戏，那你可能还没有做好准备迎接可能产生的大量信息、转变、性能、问题以及潜在解决方案。不要认为可以在软发行期间缩减团队人员；尤其在内容制作与设计方面，你需要所有成员评价游戏内容与性能。

软发行阶段的第二大关键点是需耗费大量时间。它会超乎你的想象。即使你可以在开发环境中利用工具与原则立马调整游戏。即使这种转变不需要开发商再次测试与发行。

你当然不希望每时每刻都在更改游戏的各个方面。你应当改变某个特定元素、等待、查看分析报告，而后决定下一个必要更改元素。此时，你的用户规模会决定你了解某个转变元素产生效果所需的时长。如果你不得不考虑再次测试与发行，你可能又需要两周回旋的时间……也就是说，无论你认为自己的软发行阶段需历经多长时间，你都应将此时间段乘以2！

建议2：过多改变构造成分会增加其发挥效果的难度，尤其在需要改善的游戏中。

软发行后期

现在，你已向全世界推出游戏，或者至少在目标区域中发行，那么现在可以缩减团队规模，对吧？不对！情况不可能是，你已获得一款收益不错的出色作品，你只需坐在那不断修改数据表格，最大化自己的收益额。可能的现状是，你需要考虑一些比当前作品更加出色的性能，而后根据分析报告指出的障碍与问题，每周推出新性能，不断提升留存量或收益。

在计划上，我提议，在发行后，你至少要保证整个团队在4-6个月期间所需的预算总额。

总之，这意味着，与传统开发商可以利用投资团队在4-8月内完成免费游戏发行有所不同的是，你需要自给自足，在12-18个月内完成，假如软发行为期6个月。显然，你需要投入高昂的发行成本。

前期制作

紧凑且评估正当的前期制作属于最重要阶段，它能够最清晰地显示你是否可能获得成功。如果你无法在短期内创建出一个迷人有趣的游戏原型，那么你需要转变制作方向，或是寄希望于不同的游戏机制、题材或体验模式。

通常你会认为，即使当前的原型不具吸引力，你只要调整A元素、添加B元素，或修改C元素便能取得理想效果。我完全鼓励采用迭代方式，但从发行商的角度出发，我建议你最好限制迭代次数与时间。人们所说的可以从最初阶段判断机制是否正确其实具有一定道理。在我发行的每款成功佳作中，它们在最初都会突显出迷人有趣的核心机制。

你可能会认为，自己总是不止一次地提出新性能，或多次修改，以求最佳效果。因此，开发团队常常会进入完整开发阶段，完全忽视了核心机制与趣味性这些重点，这不是个好情况。你最好提早删除某些无用元素，投入较低成本，以免自己最终获得一款无趣作品。这在免费游戏领域更为重要，因为你没有机会利用销售收回投入成本，如果玩家不喜欢你的游戏，他们不会为此付费！

建议3：前期制作相当重要。如果你早期构造的元素并不有趣，那么你应尽早修改或删掉相关机制。记住，免费游戏取得成功的基本前提是具有富有吸引力的元素。

分析

目前，分析存在于免费游戏开发的各个阶段；从电子表格中的新型“设计”方法与指标，到根据调整与平衡数据制定发行后期战略，无不需要分析手段。

考虑到分析的重要性，我总会十分好奇，有多少游戏仅在最终开发阶段采用分析工具，以此获得最后阶段测试所需的数据，可是为何要在推出游戏前收集大量数据呢？如果该步骤十分重要，你是不是应在首次创建原型时便运用这一方法？

在此我需提到一个关键区别，即分析一般分为两部分。其一是数据，其二才是分析。通过连接设备收集的比特与字节属于数据。它们仅是一系列数字，直到你进入第二部分，你才能挖掘出其中暗藏的大量信息。研究数据并获得结果属于分析部分。

实际上，只有通过第二部分，你才能了解游戏的相关信息，并发现需要改进的地方。在此关键是，你应提出有关数据方面的问题。因此，你应从发行商角度真正思考如何着手进行。分析数据属于技术活，游戏领域有不少分析师便是通过这种方式收获了不菲收入，他们十分清楚应收集哪类数据，如何分析。如果你准备让一个制作人助理一边检查仪表板，一边关注开发进展，那你可能会获得失望结果。你应拥有真正了解这方面的人才，他可以是开发团队中的成员，或是外包合作伙伴。

同时，另一关键点是，你应让设计师参与开发阶段，并与分析师一道工作。通常，有关数据方面的问题会涉及到游戏本身，或是用户与游戏的互动方式，数据无法告知最佳解决方案；这需要设计师的帮助。

比如，80%的玩家不会进入游戏的第二道关卡。经过出色的分析明了问题后，该如何解决呢？你的设计团队应考虑捕获哪类数据，如何收集（因此你的工程师可以针对此设计方法），而后从一开始便研究分析师得出的结果。这可能是他们先前从未遇到的新型技术层面。如果设计师是免费游戏领域新手，他们可能从未获得用户的直接反馈。而更早的适应这种环境，有助你取得更棒效果！

建议4：你应尽早收集相关数据，并尽可能让设计师与分析师一起共事，当你能够正当评价真实用户数据，借此构建出提升留存量与利益的元素，你会占据极大的优势。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Managing a Free-to-Play Product: a Publisher’s Perspective

by Simon Harris

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.

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.

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.

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.(source:gamesbrief)