游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

发行商谈游戏发行过程中需要着重关注的层面

发布时间:2017-05-08 09:34:31 Tags:,

本文原作者:Mike Herron 译者ciel chen

尽管手游开发市场的潜在回报丰硕,但对于开发者和发行商而言该市场始终具有很大的挑战性。从拥挤的app store和高昂的每用户平均成本(UA cost)看来,成功地办好一次产品的试发行变得再重要不过了。一次执行良好的试发行能够让你在做下款游戏的营销预算或者寻求投资伙伴之前对游戏的运行情况提前有一个全面的了解,然后还能提早知道游戏对玩家是否有吸引力,而重中之重的是——你会了解它有没有可能让你赚钱。这就是手游市场中的真相,F2P手游市场经济的无情意味着除非你能保证在试运行中用户获取成本要低于游戏生命周期价值,不然你就等着亏钱吧。

除此之外,因为开发者常常在还没把游戏做成型之前就耗尽了时间、花光了预算,所以试发行游戏的不了了之是个很常见的现象。还有其他情况是——开发者在试发行阶段花费的时间远超过预期,然而在这么长的时间里游戏市场和潮流早就变得物是人非了。

 Injustice 2(from gamesindustry.biz)

Injustice 2(from gamesindustry.biz)

无论你是准备一款新IP游戏的试发行,或者只是在为下款游戏进程技术的提高寻找机遇,在此我都想告诉你三点试发行中应该要避免的常见误区。

没能选对游戏的试发行地

乍一看,对于决定你下款游戏的试发行地似乎没什么可疑虑的,毕竟已经有那么多记录在案的诱人选择。然而在下决定开始在平均每用户身上花钱之前,开发者最好还是能后退一步审视思考一下自己想要达成的目标到底是什么,要相信这样的做法还是值得的。

你对游戏试发行地的选择将在很大程度上取决于游戏试发行阶段在给定时间内所测试的内容。概括地说来,这里有三个你在试发行阶段要检验的要容:

游戏要有良好的技术表现

你得知道游戏要能够在目标平台上顺利运行,对于线上多人竞技游戏来说,游戏则要能处理必要的同时在线玩家数量。这类测试对玩家质量的要求不如对玩家数量的要求来的强烈,所以你要寻找的试发行区域应该保证CPI(每安装正本)保持在较低水平,从而尽可能有效地触及到尽可能多的玩家。印度尼西亚、菲律宾和泰国都是低CPI的好选择——他们的CPI通常都低于1美元。

华纳兄弟公司(WB)和NetherRealm工作室就选择了菲律宾作为《不义联盟2(Injustice2)》的试发行地点

游戏要对玩家有吸引力

把游戏核心循环机制做得有趣很关键,这样才能让玩家持续规律地回归游戏。一般在这个阶段,你首要考虑的问题是用户留存数和用户沉浸体验——也就是说跟具体的收入指标比起来,你要更多地去关注玩家与游戏核心机制的交互方式、受欢迎或不受欢迎的游戏特点、玩家在游戏中停留的时长。所以就跟检测游戏技术表现一样,你要在玩家数目多、玩家成本低的低CPI水平地区来检验这些数据。

游戏要有盈利能力

游戏的经济与营销模式必须有效、可盈利并且要能够保证其试发行能充分地在全球市场上进行。目前为止,你已经检验出你的游戏拥有良好的技术表现和玩家吸引力,现在该测量你的游戏盈利能力如何了——这要看转化为付费玩家的玩家数量、他们所处的付费阶段与付费金额这些数据。对于这类商业测试你会需要收集到对全球全面发行具有代表性的数据,也就是说有必要选择一个跟你目标市场经济水平接近的地区作为试发行地——这样的地区通常应该具备较高的CPI。因此在这方面澳大利亚、新西兰和加拿大会是比较普遍的选择。

很多情况下你可能会要一次性同时对这几个内容进行测试,这就需要你在根据试发行结果进行改进的过程中平衡玩家的分布。然而,在游戏能够除清漏洞平稳运行之前,选择高CPI地区进行发行的代价可能会很高——因为随着玩家发现游戏初期构建中的早期漏洞,玩家流失率和app store的负面评价都会增加——因此开发者要认真思量游戏试发行的地点与时机。

没能收集到足够多的数据

所有的开发者要对试发行方法开放性思维;没什么能保证你考虑的内容就对游戏是好的,是能让游戏火起来的。因此所有的试发行都绝不能存在个人偏见,我们要让数据成为我们判断游戏可行与不可行内容的唯一凭据。

关键的一点在于:在把玩家正式带入到游戏之前,你要收集所有能让你做出进一步良好决策的数据信息。大部分分析工具都只能提供一些比如用户留存量、月活跃用户数、如活跃用户平均收益等这类的关键绩效指标(KPI),但要知道还有很多“专门针对游戏的”数据指标是你需要收集以便回答一些重要的问题的,这些数据包括:

初次用户体验聚集量

你希望你的游戏能吸引多少初次体验用户?玩家有使用你的教程吗?他们在游戏里停留的时间够长到能接触到游戏的核心机制吗?

玩家发展进度

玩家在你游戏中的发展进度有多快?是否存在游戏货币积累和等级提升过快导致玩家对游戏很快失去兴趣的情况?或者是否存在玩家在游戏早期碰到意想不到的瓶颈而心情沮丧,最后退出游戏的情况?

收费内容

玩家在有了怎样的具体游戏行为以后进行的第一次消费?玩家在游戏中进行到何种程度(玩了多久游戏)才转化为付费玩家的?这个转化完成的平均时间大概是多少?

收集这些数据的目的在于让开发者不仅能够辨别出表现可怜的KPI背后存在怎样的潜在根本原因;还能自己测出真实的KPI。所以如果你觉得30日用户存留量很低(举个例子),那你就应该搜集足够多有关玩家行为的信息数据来这个数据背后的原因做出一个靠谱的猜测,然后根据这个猜测对游戏做出适当的调整。

除了要搜集所需数据外,你还应该为做一个数据分析的计划,这样你才能尽快地得到所需答案。

不同的数据分析平台所提供的分析方法也就不一样;而且当你在为试发行做准备工作的时候,除了要分析实时数据,要记得把自己程序构建中的数据也纳入分析的范围中——这能避免了开发者因为突然意识到遗漏了某些关键信息数据而不得不重新搭筑程序构建的情况,这种情况有可能存在重拾流失用户的成本浪费。

没能尽快地迭代

构建-测量-了解三个内容的循环是产品开发的一项原则,这是一本叫《The Lean Starup》的书推广的概念,这本书强调了要把迭代的速度作为产品开发中的关键内容。当在做“构建-测量-了解”这个循环的时候,为了尽可能快地给市场带来最有价值的产品,开发者估测产品的表现并根据用户数据对产品做更新——通常这个循环在需要时是要重复进行的。尽管这个原则并不是针对游戏开发而言的,不过这恰恰就是游戏开发者在对新游戏进行试发行时应该习之为常的一个概念。

很多开发团队都被试发行的固定费用预算或者时间期限限制着,所以如果你能越快的做出游戏的修改更新版本(换句话说,仅在单次 “构建-测量-了解”循环的迭代后便通过了),你能搜集到的信息数据就越多。相应的,开发者也就能更了解玩家,游戏也就会在每次迭代后做得越来越好。在很多情况下,我们没法清楚地了解哪些具体的改变能让KPI的浮动最大,因此尽可能多地给自己迭代的机会就显得尤为重要了。

为了让你能尽快完成这一步,在试发行之前,你应该确保你能尽可能地通过服务器更新来进行远程游戏内容的修正,而不是重新展开新的构建。那些你想通过服务器更新做出的修改可以包括以下内容:

购买价格

可以更改展示给玩家的商品、商品价格以及商品描述。

经济平衡

变更游戏的货币价值、试购价格、游戏内奖品内容、冷却时间数。

通用游戏配置

变更游戏难度、社交提示地理位置和频率、游戏内广告出现频率、用户界面提示和通知。

理想的说来,你所用来进行游戏更新的服务器平台还要能够让你进行A/B测试——测试不同变量对同时在线的多个玩家群体的不同影响。这让开发者能通过对各组玩家同时试行不同的变更内容而更有效地利用所获玩家——举个例子,你也许会想同时测试两组不同的游戏经济,其中一组将游戏内商品价格调高了一倍,另外一组则将价格减半,然后看看这些改变对游戏KPI产生了怎样的影响。

当然了,有时你会不得不重新分配新的构建来修正漏洞、添加或删除较大的游戏特性——这确实是不可避免的。但是如果你能通过远程做出越多的更改,你在游戏试发行阶段的迭代速度就能越快。

本文由游戏邦编译,转载请注明来源,或咨询微信zhengjintiao

Despite huge potential rewards, working in mobile game development remains challenging for developers and publishers. Crowded app stores and high UA costs mean that carrying out a successful soft launch is more important than ever. Before committing a marketing budget to your next game or pitching for investment, a well executed soft launch will tell you if your game works, can engage players and, most importantly of all, is commercially viable. This is especially true within mobile; the ruthless economics of F2P mean that if you can’t prove during soft launch that the cost of acquisition is less than lifetime value, then your game is simply not going to be profitable.

Despite this, it’s still all too common for soft launches to go wrong, with time and budget running out before the developer has had a chance to get their title into shape. In some cases, the soft launch period can go on much longer than anticipated, burning cash while the market moves on and trends change.

Whether you’re preparing for your first soft launch of a new IP, or simply looking for opportunities to improve your process for your next game, here are the 3 most common soft launch pitfalls you should look to avoid.

Choosing the wrong territory

Deciding what territories to use for your next soft launch might initially seem obvious, and there are some well documented choices that developers tend to gravitate towards. However, before you pull the trigger and start spending on UA, it’s worth taking a step back to first think about what you are trying to achieve.

Your choice of territory will largely be based on what you are trying to test in any given period of your soft launch phase. Broadly speaking, there are three key points you are trying to prove during soft launch:

The game works technically

You need to know that the game runs successfully on target platforms and, in the case of online and multiplayer games, can handle the necessary volume of concurrent players. For these types of test, player quality is not as important as player volume, and you should seek out territories with a low CPI (cost per install) in order to acquire large volumes of players as cost effectively as possible. Indonesia, the Philippines and Thailand are common choices with low CPIs, typically well under $1.

1
WB and NetherRealm opted for the Philippines when soft-launching Injustice 2
The game can engage players

It’s vital that the core loop is fun and players continue to return to the game regularly. Usually at this stage, your primary concern is retention and engagement – you are more focussed on how players are interacting with your core mechanics, what features are popular/not popular and how long players stay in your game rather than specific revenue metrics. As with a technical test, you can prove these metrics with high-volume, low-cost players in territories where CPI is low.

The game is commercially viable

The game’s economy and monetisation model must be effective, profitable, and justify a fully marketed global launch. By now, you’ve proven that you have a fun, engaging game and are measuring and refining how well your game monetises – how many players convert to payers, at what stage they convert, and how much they spend. For commercial tests you want to collect KPIs that are going to be representative of a full global launch, so it’s important to select territories that are economically similar to your eventual target market, which usually means a higher CPI. Australia, New Zealand and Canada are common choices here.

In many cases you are likely to be performing a mix of these tests at once and should therefore try to balance player distribution accordingly as you progress through the soft launch window. However, selecting a territory with a high CPI before your game is stable and bug free can be costly as initial builds are likely to see increased player churn rates and negative store reviews as early bugs are found – it’s therefore important to think carefully about where and when you soft launch.

Not collecting enough data

All developers should approach soft launch with an open mind; there’s no guarantee that what you think is right for your game will prove a hit with end players. During any soft launch it’s vital that personal bias is removed and data alone is used to determine what is and isn’t working.

It’s crucial that before you start bringing players into your game you are collecting information that will allow you to make good decisions further down the line. Most analytics tools provide common KPIs such as retention, MAU, ARPDAU, etc. but there are also many game-specific metrics you should collect that will help you answer important questions, including:

The FTUE (first-time user experience) funnel

How many first sessions are going according to your expectations? Are players making it through your tutorial? Are they playing long enough to engage with the game’s core mechanics?

Player progression

How quickly are players progressing through your game? Are they accumulating currency or finishing levels too quickly and becoming bored, or are players hitting an unexpected early pinch-point and leaving after becoming frustrated?

Purchase context

After what specific action do players make their first purchase? How far have players progressed in the game before converting? What is the average time to conversion?

The goal is to be able to identify the potential underlying causes of poor KPIs as well measuring the actual KPIs themselves. If you can see that day 30 retention is poor, for example, it’s important that you have enough information on player behaviour to make a qualified guess as to why that might be the case, so you can then make the appropriate changes to your game.

As well as making sure you are collecting the right data, you should also have a plan for analysing your data so you can get the answers you need quickly. Different analytics platforms provide different method of doing this and part of your preparations for soft launch should include using data from your development builds and analysing it just as you would with live data. This will ensure that once your game has launched, you don’t suddenly realise you are missing key information and have to distribute a new build, potentially having wasted money on acquiring players who have now left your game.

Inability to iterate quickly

The Build, Measure, Learn loop is a product development principle popularized by the book The Lean Startup that emphasises speed of iteration as a key component in product development. When using Build, Measure, Learn, the goal is to release an MVP to market as soon as possible, measure it’s performance and then update that product based on user data, repeating the loop as often as required. While the principle is not specific to game development, this is exactly the mindset that developers should adopt when soft launching a new title.

“Prior to soft launch you should ensure that you have the ability to remotely modify as much of your game as possible through server side updates rather than redistributing new builds”
Many teams will work within a fixed budget or timescale for soft launch so the faster you can make updates and changes to your game (in other words, go through a single iteration of the Build, Measure, Learn loop) the more information you will collect. In turn you will learn more about your players and your game will become better and better through each iteration. In many cases, it is also not obvious what specific change will cause the biggest swing in KPIs, so it’s important to give yourself as many chances to iterate as possible.

To help you do this quickly, prior to soft launch you should ensure that you have the ability to remotely modify as much of your game as possible through server side updates rather than redistributing new builds. Some of the changes you might want to make through server updates could include:

Purchase prices

Changing what items are shown to the players, the price of each item and item descriptions.

Economy balancing

Starting in game currency values, soft purchase prices, in-game rewards, cool down timers.

General game configuration

Game difficulty, social prompt location and frequency, in game advert frequency, UI prompts and messaging.

Ideally, the server platform you are using to provide updates should also enable you to perform A/B testing – testing different variations of a change on multiple player groups concurrently. This can help you make more efficient use of acquired players by running multiple changes in parallel on groups of players. For example, you might want to try out 2 different versions of your game economy, one that doubles the cost of in-game items and one that halves them, and then see how the changes affects your KPIs.

Of course, it’s inevitable you will have to redistribute new builds to fix bugs and add or remove larger features, but the more changes you can make to your game remotely, the faster you’ll be able to iterate during soft launch.(source:gamesindustry.biz


上一篇:

下一篇: