使用node.js作爲遊戲服務器來跟蹤遊戲狀態

Question

我正處於移動多人遊戲實時遊戲的規劃階段，我正在考慮實施哪種體系結構以跟蹤遊戲中的狀態大廳。

我已經考慮過讓遊戲成爲點對點，其中同一遊戲大廳內的所有設備（最多4名玩家）將在遊戲進行時將其位置發送給其他玩家。我還考慮讓玩家連接到服務器和服務器，以跟蹤遊戲狀態並將狀態發送給每個玩家。

如果我確實走這條路線並使用節點來實現服務器，那麼我需要考慮哪些問題？

我有一個預測，可擴展性將是一個主要問題，因爲服務器必須跟蹤名義上以60 fps運行的每個遊戲大廳的狀態。如果我有100個活躍的遊說團隊，我可以預見可能出現的問題。這是否會是這種情況，我應該看看不同的網絡架構嗎？還是可以在服務器達到最大值之前獲得大容量？

Answer 1

高度依賴於這種遊戲。 點對點解決方案可能比較棘手，而且作弊行爲很容易，除非您在每個客戶端上驗證它，但是因爲您想在移動客戶端上運行它，這會讓遊戲變慢。

驗證中央服務器上的數據併發送驗證數據更有意義。

一般情況下，FPS根本不關心服務器。 每個客戶端只向服務器發送用戶輸入，而不是每個幀 （按下按鈕 - 釋放按鈕）。 服務器使用所有這些信息並計算需要發生的情況並定期向客戶端發送更新。 然後，客戶端將過去的所有事情呈現爲200ms（真正取決於遊戲的種類），並「預測」服務器將在下次更新中發送的內容，以使其看起來流暢。 剛剛閱讀這篇文章，它比我所能解釋的更好：https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

但是，是的，它會比普通網站需要更多的權力。 然而，單個大廳不需要相互通信，所以你可以超級簡單地並行使用3臺服務器。 與大多數可選方案相比，Node可以很好地執行，因爲它可以很好地處理併發連接。只要確保你不會運行CPU繁重的東西，因爲這會消除Node（如果你只是接收狀態更新並使用基本數學來驗證它並再次發送它 - >完美選擇）。

希望幫助

Answer 2

您將遇到的最大問題是Node並不是用來處理像實時模擬一樣對延遲敏感的應用程序。

HTTP是一個臃腫的協議，它是基於文本的。它不適用於大多數人會考慮多人遊戲的類型。它可能適用於高延遲並不是諸如臉書遊戲等問題的遊戲。