發行商談遊戲發行過程中需要着重關注的層面

本文原作者: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