使用Google App Engine的實時多人遊戲是否可行？

Question

我目前正在開發一款實時多人遊戲，並且一直在評估各種基於雲的託管解決方案。我不確定App Engine是否符合我的需求，並會很感激任何反饋。

從本質上說，我希望系統是這樣工作的：玩家A計算n輪，並在該回合結束時生成一個散列出來的遊戲狀態。然後，他將他的命令發送到服務器，並將散列作爲http POST發送到服務器。玩家B並行執行相同的操作。

的服務器，而從球員處理POST，首先將所接收的散列碼的內存緩存。如果來自其他玩家的散列尚未存在於內存緩存中，它將等待並定期檢查其他玩家散列的內存緩存。只要這兩個哈希都在memcache中，它就會比較它們是否相等。如果它們相等，則服務器將每個播放器的命令作爲http響應發送給另一個播放器。

像那樣的一輪談判應歷時約半秒，這意味着每秒每名球員兩個請求。

當然，這樣做只會如果有應用程序運行的至少兩個實例工作，因爲兩個要求必須用並行處理的這種方式。此外，內存緩存必須在所有實例中保持一致，相當可靠，並立即更新。

我不能使用XMPP，因爲我希望我的比賽才能夠限制網絡中運行，所以它必須被限制在HTTP端口80上

有沒有辦法強制執行該應用程序的兩個實例總是在跑？我的設計中是否有明顯的缺陷？你認爲像這樣的架構可能適用於App Engine嗎？如果不是，您會建議哪種基於雲的解決方案？

Answer 1

我相信這可以工作。您瞭解/測試的關鍵API可能是Channel API。這就是允許客戶端和服務器之間的來回通信。

下一個需要擔心的問題是memcache。一般來說，它是可靠的，但從最嚴格的意義上講，我們應該假設memcached數據可能隨時消失。

如果你決定，你不能冒失去這樣的數據，那麼你需要堅持它在數據存儲，這意味着你必須進行試驗，以確保您能夠維持每回合2個移動。我認爲這是可能的，但並不平凡。如果你說每3秒鐘移動一次，我會說「沒問題」。但是，每秒對多個實體進行多次更新開始與每秒寫入的實際限制相沖突，特別是如果它們是事務性的。

有運行將不會是一個問題的多個實例 - 你可以支付，如果要保持實例溫暖。