一、伺服器劃分原則
在現有的網路遊戲伺服器端架構中,多是以功能和場景來劃分伺服器結構的。 負載均衡和集群暫且不在本文中討論(bigworld、atlas)。 伺服器劃分可以基於以下原則:
- 分離遊戲中佔用系統資源(cpu,記憶體,IO等)較多的功能,獨立成伺服器。
- 以多執行緒或多進程的程式設計方式適應多核處理器。
- 在同一個伺服器架構下,應盡可能的複用某些伺服器(進程級別的複用,比如場景伺服器)。
- 運行時玩家資料的保存、修改及資料流程向應該是設計的焦點,它同時也決定了伺服器應該如何劃分。
- 伺服器的劃分應該適度,在保證清晰的資料流程向的前提下,根據遊戲的類型和規模儘量減少伺服器或伺服器進程的個數,以減少伺服器之間過多的複製資料、鎖衝突(使用共用記憶體進行通訊時)。
- 主要按照場景劃分進程,若需按功能劃分,必須保持整個邏輯足夠簡單,並滿足以上1、3兩點。
二、運行時的玩家資料
網路遊戲伺服器程式一項重要的工作就是根據client發過來的資料包,在伺服器端類比玩家的行為操作並把這些行為廣播出去。 那麼伺服器程式在運行時就需要一些實體來保存玩家的資料,這些實體可以是一個類,也可以是一個執行緒,設計思想不同採用的實體差別也會很大。 這裡涉及伺服器端設計的一個核心問題:運行時玩家資料的保存、修改及資料流程向。
三、伺服器底層框架skynet
我希望我們的遊戲伺服器(但 skynet 不僅限於用於遊戲伺服器)能夠充分利用多核優勢,將不同的業務放在獨立的執行環境中處理,協同工作。 這個執行環境,最早的時候,我期望是利用 OS 的進程,後來發現,如果我們必定採用嵌入式語言,比如 Lua 的話,獨立 OS 進程的意義不太大。 Lua State 已經提供了良好的沙箱,隔離不同執行環境。 而多執行緒模式,可以使得狀態共用、資料交換更加高效。 而多執行緒模型的諸多弊端,比如複雜的執行緒鎖、執行緒調度問題等,都可以通過減小底層的規模,精簡設計,最終把危害限制在很小的範圍內。 這一點,Skynet 最終花了不到 3000 行 C 代碼來實現核心層的代碼,一個稍有經驗的 C 程式師,都可以在短時間理解,做維護工作。
做為核心功能,Skynet 僅解決一個問題：
把一個符合規範的 C 模組,從動態庫(so 檔)中啟動起來,綁定一個永不重複(即使模組退出)的數位 id 做為其 handle 。 模組被稱為服務(Service),服務間可以自由發送消息。 每個模組可以向 Skynet 框架註冊一個 callback 函數,用來接收發給它的消息。 每個服務都是被一個個消息包驅動,當沒有包到來的時候,它們就會處於掛起狀態,對 CPU 資源零消耗。 如果需要自主邏輯,則可以利用 Skynet 系統提供的 timeout 消息,定期觸發。
Skynet 提供了名字服務,還可以給特定的服務起一個易讀的名字,而不是用 id 來指代它。 id 和運行時態相關,無法保證每次啟動服務,都有一致的 id ,但名字可以。
四、gate
滿足伺服器劃分原則裡的第一點:分離遊戲中佔用系統資源(cpu,記憶體,IO等)較多的功能,獨立成伺服器。
五、場景管理器
主要用于管理静态场景和动态副本，比如agent登录时查询自己所在场景对应的服务器地址。
六、場景伺服器
場景伺服器的內容我沒有從《開發筆記》中得到太多的資訊(可能level太低),更多的是以功能模組的形式寫,比如AOI。 不過其中有一點比較新穎的是雲風認為player的位置、動作狀態,戰鬥數值狀態等都是場景的一部份,應該保存在場景中而不是agent中 據我的猜測,場景伺服器應該會負責：
- 怪物行走控制,player移動更新及位置同步
- 怪物AI策略
- 區域性廣播,場景廣播
- 戰鬥邏輯
- AOI服務(Area Of Interest )
- 碰撞檢測
- 自動尋徑
- Privacy Polic - 2024-02-08
- Privacy Policy - 2024-02-07
- Ubuntu 20.04架設Minecraft伺服器 - 2022-03-25