作者：David Xicota

当你最终发行了你的游戏并足够幸运吸引了一定用户下载了游戏后，他们将陷在第8个关卡并且很难通过它。

Improve player retention reacting to behavior(from gamasutra)

根据你的分析服务，他们到目前为止似乎都很喜欢游戏，但是现在用户的登录频率大大下降了。你正在失去这些活跃用户。到底发生了什么？

毫无疑问他们是喜欢你的游戏。那他们为什么会止步于第8个关卡？关键在于你可能高估了用户对于游戏的精通能力。第8个关卡可能对于大多数用户来说太复杂了，这也是为什么他们不再登录游戏。你也因此会失去这些用户。

存在许多方法能够解决这一问题。你可以在玩家到达第8个关卡之前减少敌人数量，提高玩家的体力，改变游戏时间或添加更多游戏关卡，从而让玩家在面对第8个关卡时能够更擅长游戏。

提交到商店花费了太长时间

是的，你已经决定优化游戏参数让用户能够更容易进行体验，从而让他们能够继续游戏并留在这里。假设你是个非常厉害的程序员，所以你能够在一天内快速调整代码并成功测试游戏机制。这当然很棒，但即使如此你也需要等待Google Play或App Store的审核才能发行更新内容—-前者需要1天，而后者则需要7天。

缺少对于游戏内容修改的回应时间的掌控会阻碍你去创造游戏进程。我并不想成为懒汉，但事实是在这期间我一直会失去用户。

在通过审核后，用户仍然需要去下载最新的游戏版本。有些人会马上采取行动，有些会之后再下载，也有些人永远都不会去下载最新版本。尽管你匆忙激活最新版本，但要想知道改本是否有效还是取决于用户的态度。

是的，你仍在继续失去用户。

我们总是很难从用户那获得有效的反馈，因为并不是所有用户都拥有最新版本的游戏。

适应

越来越多游戏开发者在使用外部服务器去储存游戏机制数据。提供灵活性和快速回应是适应用户需求的关键。想象一个服务器将你的回应时间压缩到最短，并能够提供给你的用户不间断的游戏体验，如此你便能够同时测试不同的方法了。

为什么要将参数储存在外部服务器

1.不要让别人主宰你的回应时间

你的回应时间不应该比你调整代码的时间还长。修整它让改变能够同时发挥作用，你便能够快速回应用户的需求并留住他们的注意力。快速获得用户数据让你能够判断改变是否发挥功效或者你是否需要对改变进行新的迭代。

2.不要让用户因为游戏更新下载而感到厌烦

让你的用户可以轻松体验更新内容，避免他们手动下载任何游戏更新。如此他们便会去体验游戏的最新版本，你也能够够获得可靠的用户数据，因为将不会出现不同版本同时运行的情况。

3.不断寻找解决方法

在同一个问题中使用不同的解决方法去同时测试哪个方法更有效。分开测试代码差异能够带给你更多数据，这意味着你将缩减用户寻找最适合游戏的调整方法的时间。

服务器脚本等于最大可配置性

以此为例。你可以在服务器端创造一个配置集合去保持一个简单的配置JSON。以下是相关代码：

{
“levels”:
{
“1″: { “difficulty”: 1, “time”: 60 },
“2″: { “difficulty”: 3, “time”: 70 },
“3″: { “difficulty”: 5, “time”: 80 },
“4″: { “difficulty”: 7, “time”: 90 },
“5″: { “difficulty”: 9, “time”: 100 },
},
“adsplatform”: “iads”,
“coinseveryday”:
{ “1”: 10, “2”: 20, “3”:30, “4”: 60, “5”: 100 }
}

每次当用户打开一个新游戏回合时，你便能够检测这一配置是否发生改变。如果发生改变，它便会开始下载全新游戏配置，并马上开始使用它们。

此外，你也可以轻松地使用一个定制脚本去执行A/B测试。

在集合中创造2个或3个JSON配置样本。

定义一个名为getGameParameters的定制脚本（全新服务器功能）。

每当用户登录游戏时便调用这一功能。

这一功能将是一个简单的JavaScript（游戏邦：使用一个循环技术），它将决定该发送哪个JSON：A，B或C。基于这种方法决策点便取决于服务器端，并且能够轻松做出改变，你将能够同时测试不同配置而得到更好的结果。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转发，如需转载请联系：游戏邦）

Improve player retention reacting to behavior [Server Scripts]

by David Xicota

Picture this. After you’ve hardly fought to release your game and you’re lucky enough to get a pretty decent number of users downloading your game, they get tangled up in Level #8 and can’t manage to get past it.

According to your analytics service, they seemed to be enjoying the game so far, but now the users are logging in at a lower rate. You’re losing active users. What’s going on?

There’s no question they like your game. Why would they play up to Level #8 if they didn’t? The thing is maybe you overestimated the users ability to reach enough proficiency in the game to advance to further levels. Level #8 might be too difficult for most users and that’s why they’re are no longer logging in to the game. Thus, you’re losing users.

There are many solutions to the problem. You could reduce the number of enemy waves, add player stamina, change the time of the game or add more game levels before they get to Level #8 allowing users to be more game savvy by then.

Submitting to Stores Takes Too Long

Ok, you decide to modify the game’s parameters to ease it on your users so they keep on enjoying the game and choose to stay. Say you’re a programming beast and that you’re able to swiftly adjust the code and successfully test the game mechanics in one day. That’s good and all but you still need Google Play or the App Store to approve it and publish it – a day for the former and a whopping 7 days for the latter.

The lack of control over the response time for the in-game modifications hampers your ability to make the game progress. I don’t want to be a bummer, but you’re still losing users.

Having passed the period of time for the changes to go live – which seemed longer than you care to admit – users still have to accept to download the latest version of the game. Some of them do it right away, some might do it at a later time… or never at all. After all that rush to get the newest version active, it is still up to your game users having the latest version if you want to see whether the fixes have a positive effect.

Right, you continue losing users.

It’s really hard to get good feedback from the users – and react accordingly – when not all of them are running the latest version.

Adapt or You’re Done

The use of external servers to store game mechanics data is a rapidly increasing tendency among game developers. Offering flexibility and a quick response is key to be adaptable to your users needs. Imagine a service that cuts your response time to a minimum, gives uninterrupted game play to your users and lets you test different approaches at the same time.

Why Store Parameters in External Servers

#1 Never let others dictate your response time

Your response time shouldn’t be much longer than what you spend on tweaking your code. Fixing it to have the changes go live barely at the same time, you’ll be able to deliver a quicker response to your users’ needs and keep them engaged. Getting user data faster allows you to decide if the changes came to effect or if you need another iteration of changes.

#2 Don’t annoy users with a game update download

Having your users experience the updated game on-the-go, releases their need to download any game updates manually. They’ll always play the latest version of the game so you’ll get very reliable user data because there won’t be different versions running at the same time.

#3 Find solutions on-the-go

Upload different solutions to the same problem to simultaneously test which one performs better among users. Split testing subtle code differences will return twice as many data, which means reducing the time you spend to find the best adjustments for the game.

Server Scripts Equals Max Configurability

Take this as an example. You could create a config collection in the server side to keep a simple config JSON. This would be the code for it.

{
“levels”:
{
“1″: { “difficulty”: 1, “time”: 60 },
“2″: { “difficulty”: 3, “time”: 70 },
“3″: { “difficulty”: 5, “time”: 80 },
“4″: { “difficulty”: 7, “time”: 90 },
“5″: { “difficulty”: 9, “time”: 100 },
},
“adsplatform”: “iads”,
“coinseveryday”:
{ “1”: 10, “2”: 20, “3”:30, “4”: 60, “5”: 100 }
}

Every time a user opens a new game session you can check if this config has been changed or not. If it has, it’ll start the download of the new game’s config and will start using them right away.

Besides, you can also implement A/B testing with one custom script very easily.

Create two or three JSON config samples in the collection.

Define a custom script – new server function – called getGameParameters.

Call this function every time a user logs in to your game.

This function will be a simple Javascript – using a round robin technique – that will decide what JSON has to be sent: A, B or C. This way the decision point is on server side and can be easily changed and you will be able to test different simultaneous configurations to get better results.

Now you know you can improve user experience storing game mechanics in the server side, what other situations do you think you could use this for your game?(source:gamasutra)