如何在服務器端完善游戲的用戶體驗
當你最終發行了你的游戲并足夠幸運吸引了一定用戶下載了游戲后，他們將陷在第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?；谶@種方法決策點便取決于服務器端，并且能夠輕松做出改變，你將能夠同時測試不同配置而得到更好的結果。
