我們一開始的游戲邏輯層是基于網絡包驅動的，也就是將 client 消息定義好結構打包發送出去，然后再 server 解析這些數據包，做相應的處理。
寫了一段時間后，覺得這種方案雜亂不利于復雜的項目。跟同事商量以后，改成了非阻塞的 RPC 模式。
首先由處理邏輯的 server 調用 client 的遠程方法在 client 創建出只用于顯示表現的影子對象；然后 server 對邏輯對象的需要client 做出相應表現的操作，變成調用 client 端影子對象的遠程方法來實現。
這使得游戲邏輯編寫變的清晰了很多，基本可以無視網絡層的存在，和單機游戲的編寫一樣簡單。
本質上，這樣一個系統跟網絡包驅動的方式沒有區別；但是從編碼表現形式上要自然很多。正如 C 語言也可以實現面向對象，但卻沒有 C++ 實現的自然一樣。在這個系統中，引擎封裝了對象管理的部分，使得邏輯編寫的時候不再需要處理討厭的對象數字 id ；還隱藏了消息發送或廣播的問題。
我把玩家控制的角色，和服務器上你的角色分做兩個東西。即，你控制的你，和服務器認為的你就分開了。服務器認為的你，你看見的服務器上的其他人是一類東西。操作自己的角色行動時，你通過 client 上的控制器的遠程方法向服務器發送指令；而服務器通過遠程調用每個角色的遠程方法讓 client 可以收到感興趣的所有角色的行為。
這樣，client 永遠都是通過一個控制器調用其遠程方法來告訴服務器"我要干什么"，而服務器的邏輯層則通過調用其上所有邏輯對象的遠程方法來改變每個對象的狀態。而引擎就根據每個鏈接的需要，廣播這些消息，使得每個 client 上對應的影子對象可以收到狀態改變的消息。
這些，就是半個月來我跟同事一起做的工作。當然，由于我們用腳本編寫邏輯層，這樣，腳本接口可以比 C 接口實現的漂亮的多。
首先是自定義格式的接口描述文件，用自編寫的工具自動編譯成對應腳本代碼。我們只需要在腳本中編寫對應的類，就可以自動響應遠端調用的方法了。而調用遠程方法，也跟本地方法保持同樣的形式，寫起來跟本地函數調用沒有區別。這在以前用 C/C++ 編寫邏輯的時候是很難做到的。
其次，引擎內部做好對象的管理工作，負責把通訊協議上的 id 轉換成邏輯層中的對象傳遞給邏輯層使用。
再次，enum 這樣的類型再也不需要用一些數字的常數了，也不需要在腳本額外的定義出來。可以在接口文件中定義好，經過引擎的處理后，邏輯層可以直接用更為友好的字符串代替，而不失去效率。
編寫邏輯的程序員不再需要關心網絡的問題后，就可以把心思放在細節上。
最后，對于實現行為預測來補償網絡延遲的特性上。在先前的版本中，我們為了實現這個，花了不少的氣力。主要是將時間戳信息放在基礎通訊協議中來輔助實現。具體的消息包收到后，再計算延遲時間來推算當前的狀態。現在，可以把時間信息封裝到 RPC 中，讓每個遠程方法自動帶有延遲時間，方便計算。按模擬程序的實際效果上看，單單位置同步的預測策略，可以讓延遲在 8 秒之內的玩家可以忍受；而延遲小于 1 秒的時候，幾乎不會受到滯后的影響了。
關于每個鏈接感興趣的信息的問題，決定了每個邏輯對象的狀態改變要通知哪些人。目前的想法是獨立到單獨進程去處理，我們在處理連接的服務器和處理邏輯的服務器之間設置單獨的服務器來管理每個鏈接感興趣的對象，這個任務相對單一且責任重大，獨立出來可以大大減輕邏輯服務器的復雜度。
posted on 2009-02-12 02:50
小王 閱讀(1932)
評論(0) 編輯 收藏 引用 所屬分類:
游戲服務器端開發