当你最终发行了你的游戏并足够幸运吸引了一定用户下载了游戏后，他们将陷在第8个关卡并且很难通过它。
根据你的分析服务，他们到目前为止似乎都很喜欢游戏，但是现在用户的登录频率大大下降了。你正在失去这些活跃用户。到底发生了什么？
毫无疑问他们是喜欢你的游戏。那他们为什么会止步于第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。基于这种方法决策点便取决于服务器端，并且能够轻松做出改变，你将能够同时测试不同配置而得到更好的结果。
