需要相互通信的多個游戲服務器的最佳架構是什么？

Question

該游戲是一款低圖形（SVG）戰略游戲。 每個服務器及其玩家代表一個游戲域。 所有服務器都應該能夠互相通信，因為玩家可以在游戲中從一個域移動到另一個域/發送“外交使者”等。

我們之所以選擇這個主意，是因為它可以使我們不斷地擴大世界地圖，它可以使第二方將他們的游戲服務器連接到我們，從而進一步擴大世​​界。 如果一台服務器（及其備份）出現故障，游戲仍將繼續運行（真實的分布式環境）。

我們只是開始。 我們應該關注哪些平台可以幫助我們發展這樣一個世界？

Answer 1

XMPP（以前稱為Jabber）可能是一個不錯的起點。

Answer 2

這在很大程度上取決於您希望在服務器之間共享多少數據。 您希望每個服務器都處理其自己的域，但是帳戶數據庫，有關誰擁有哪些信息的數據，域的拓撲結構，這些數據是集中的和/或分布式的，以及如何使它們保持同步？ 因此，除了游戲的運作方式之外，還有另一組元數據需要服務器進行通信。 至於游戲數據，您可能會傳遞事件，數據對象以及有關數據所有權和控制權的信息。 最重要的是，必須有一些游戲中的時鍾元數據以保持域時間同步。

我可能會使用具有不同優先級的異步隊列系統來處理元數據，請求和響應消息。 交換消息之上的XMPP之類的協議可以為您帶來狀態信息，身份驗證，加密和其他優勢。 但是從一開始，傳遞協議本身並不像消息的結構和數據交換那么重要。 本質上，傳送協議是可以互換的。

示例 ： 一個玩家將游戲單元X從域A發送到域B。域A服務器將帶有事件的消息發送到域B服務器。 在處理事件隊列時，B接收消息並將請求發送到A上的請求隊列，以獲取有關單元X的數據以及控制/修改單元X數據的權限。請求隊列具有更高的優先級，將在域A上的其他事件之前處理。域A將請求的數據和控制令牌發送到具有最高優先級的域B響應隊列。 同時，域B服務器已經處理了3個其他事件，沒有在會話中等待。

• 注意： 此時A應該過時，版本化或刪除有關X單元的數據。 如果請求來自域C的數據，則應該從現在開始將此請求轉發到服務器B。
• 注意： 上面的示例可以優化為直接發送帶有相應事件的有關X單元的數據，但是我想用一個簡單的示例進行說明。

重要的是，您將必須設計數據封裝協議，可能是一些XML模式。 事件處理的協議。 事件列表，允許的響應，錯誤消息，恢復。 這些都是特定於游戲的。

Answer 3

我會認真考慮Erlang和CouchDB，或者在Google AppEngine下實現它。

Answer 4

如果它確實是分布式的，那么我猜沒有針對中央服務器的計划。 這意味着您真正要尋找的是各種服務器之間的通信機制。 REST和XML-RPC都是非常簡單的機制，服務器可以相互通信以傳達用戶需要從一個移動到另一個。

您還可以使用Daniel所說的XMPP之類的東西，但這意味着您必須將另一組服務器軟件與運行游戲本身的所有內容掛鈎在一起（從您的描述中推測，這可能是一個網絡應用服務器）。

從開發的角度來看，任何對開發Web應用程序都很有用的語言/框架都應該起作用。 Ruby on Rails，Django上的Python，眾多框架以及Java，甚至是帶PHP的Cake（ick）均可用於開發工作。

過去我曾考慮過類似的事情，但是審查各種服務器的問題（即，如何處理損壞或惡意的服務器，並讓玩家同時將同一塊移動到另外兩個或三個其他服務器上），服務器掉線（最后在那里存在的玩家會發生什么）等問題似乎非常具有挑戰性。

Answer 5

您應該查看有關p2p游戲的“興趣管理”文章，您將面對非常有趣的方法。 Google Schoolar將為您呈現非常好的論文。

但是請注意，開發分布式應用程序比簡單的單服務器方法要復雜得多。

Answer 6

我認為要回答的第一個問題是游戲是實時游戲還是事件驅動游戲，以及客戶端是否是瀏覽器。 聽起來好像是事件驅動的，但請記住，服務器無法將結果有效地推送到純HTML客戶端，而只能推送到Java applet，嵌入式Flash電影等。如果您有自定義客戶端，則無需使用HTTP服務器上的系統樣式，這意味着服務器->服務器和服務器->客戶端通信可以用相同的方式完成。