構建基於回合的多人遊戲服務器

Question

我開始製作多人遊戲，但由於我沒有經驗，我嘗試過不同的方式，但有些東西對我來說並不合適。 所以，我真的需要一個關於我應該使用哪種平臺/工具/語言/技術的建議。 我必須說我不相信諸如：Photon，AppWrap，Skiller，Gamooga等等。我不認爲他們的規模很大，不會太貴，或者他們太大（我不是指大小，我指的是他們有多少東西，我不需要）滿足我的需求。

首先，我將描述簡化的遊戲會話過程。

1. 三名球員在開始遊戲會話
2. 每個玩家收到的問題，應該在10秒鐘內應答。
3. 當玩家回答時，他應該能夠看到任何其他玩家已經給出的答案（如果有的話），並且他應該能夠在給出答案時立即看到答案。基本上，任何答案都應該由其他客戶實時接收，但只有在我們回答之後（以避免作弊）。如果時間到了，那麼沒有回答的人將不會收到分數，下一個問題就會發生。
4. 決定勝利者並進入下一個問題。 N輪結束後進行遊戲。

其次，我會解釋一些我考慮過的要求。

• 遊戲應該在iOS/Android/Web上運行。這讓我別無選擇，只能使它基於HTTP。
• 我尋找了我真正喜歡的Google Cloud Endpoints。它有iOS/Android/JS SDK，Google Cloud Platform有Google BigQuery，還有很多其他很棒的東西。 但，因爲我需要實時答案交付我不知道是否適合（有渠道API，但沒有客戶端SDK的iOS和人們說它不是很好）。
• 然後我查找Node.js和長輪詢（客戶端的AFNetworking），但它很難管理。我需要爲客戶端提供遊戲狀態更新（並且我需要發送增量）。這樣我需要爲每個玩家分別跟蹤所有更改。當玩家連接時，我應該檢查是否有任何改變;如果它立即發送;如果不是，那麼聽'改變'事件然後發送。在最後的代碼看起來很尷尬，很難理解，我不知道如何做正確的。有socket.io應該使服務器端的東西變得更好，但又沒有客戶端的iOS SDK。

我不知道該從哪裏出發。任何幫助將非常感激。

Answer 1

基於回合的體系結構實際上並不複雜，因爲滯後並不是一個大問題，數據也不會經常發送。

我會創建兩個Web服務，一個用於配對，另一個用於處理實際的遊戲。

配對只會讓隊員排隊，當比賽足夠時，服務會選擇一組隊員併爲他們分配一個sessionID並將隊員傳遞給遊戲服務。

對於遊戲服務，重要的是要區分可以在客戶端和服務上處理的內容。

遊戲服務將存儲每個sessionID的所有遊戲信息，包括客戶端。這將允許一個服務輕鬆管理數百個遊戲。當一個玩家回答一個問題時，它會通過sessionID向服務器發送請求。服務器會迭代會話中的客戶端並將信息發送給他們。

客戶端可以處理隱藏問題直到用戶回答。 （如果您擔心黑客攻擊，您甚至可以加密其他問題信息）。

服務器還會跟蹤會話的計時器，當計時器到期時，它會向所有客戶端發送響應，並且忽略任何後面的答案。一個圓整數可以存儲在會話中，並與sessionID進行通信以區分過去問題的答案。你可以在客戶端有一個預測計時器，但服務器需要是計時器的權限以避免作弊。

Answer 2

使用安全的ssl https協議使用您自己的驗證令牌來防止作弊者。

客戶需要跟蹤每個玩家的時間跨度，而不是實際的時間。在每個客戶端的輪次結束之後，單個時間跨度被髮送到服務器。

想想這樣吧。有3個客戶端，當他們開始這輪時，所有客戶端都在輪詢服務器。由於三者可能有不同的網絡速度，因此您不知道誰將首先啓動。因此，當每個客戶端最終收到綠燈時，計時器將啓動該設備，該設備上的計時器將在該客戶端設備上接收。你等到所有3都回報服務器，並用他們的時間跨度來確定誰贏了這一輪。

這裏有一些關於遊戲邏輯的話題。這裏有些例子。 用戶身份和授權。 （Game Center） 遊戲數據持久性和存儲。 （雲數據庫，如AWS DynamoDB） 遊戲匹配隊列。 （AWS SQS）請勿使用悲觀併發來嘗試使用數據庫。 Match Players的通知已準備就緒，可供睡覺的客戶使用。 （AWS SNS到APNS到端點（此移動設備）） 輪詢或通知下一步移動。 （AWS SQS或SNS）我不會輪詢數據庫。 這些服務只是示例建議。我不爲亞馬遜工作，他們是最容易起牀和運行，但有更好的服務。

基本上我得到的是你想要比一個基本的託管網站上的傳統MySQL數據庫更多。與在專用服務器上創建所有基礎架構相比，這些雲服務中的一些已經變得非常實惠。 也是成倍增加可擴展性。 您可以使用雲服務完成上面列出的每月15美元起價。最好的情況是，如果你的想法開始起作用，只需輕輕一切從管理門戶切換即可輕鬆搞定門檻。 這將是一個很好的問題。