本質(zhì)上，這樣一個系統(tǒng)跟網(wǎng)絡(luò)包驅(qū)動的方式?jīng)]有區(qū)別；但是從編碼表現(xiàn)形式上要自然很多。正如 C 語言也可以實現(xiàn)面向?qū)ο螅珔s沒有 C++ 實現(xiàn)的自然一樣。在這個系統(tǒng)中，引擎封裝了對象管理的部分，使得邏輯編寫的時候不再需要處理討厭的對象數(shù)字 id ；還隱藏了消息發(fā)送或廣播的問題。

我把玩家控制的角色，和服務(wù)器上你的角色分做兩個東西。即，你控制的你，和服務(wù)器認為的你就分開了。服務(wù)器認為的你，你看見的服務(wù)器上的其他人是一類東西。操作自己的角色行動時，你通過 client 上的控制器的遠程方法向服務(wù)器發(fā)送指令；而服務(wù)器通過遠程調(diào)用每個角色的遠程方法讓 client 可以收到感興趣的所有角色的行為。

這樣，client 永遠都是通過一個控制器調(diào)用其遠程方法來告訴服務(wù)器"我要干什么"，而服務(wù)器的邏輯層則通過調(diào)用其上所有邏輯對象的遠程方法來改變每個對象的狀態(tài)。而引擎就根據(jù)每個鏈接的需要，廣播這些消息，使得每個 client 上對應(yīng)的影子對象可以收到狀態(tài)改變的消息。

這些，就是半個月來我跟同事一起做的工作。當然，由于我們用腳本編寫邏輯層，這樣，腳本接口可以比 C 接口實現(xiàn)的漂亮的多。

首先是自定義格式的接口描述文件，用自編寫的工具自動編譯成對應(yīng)腳本代碼。我們只需要在腳本中編寫對應(yīng)的類，就可以自動響應(yīng)遠端調(diào)用的方法了。而調(diào)用遠程方法，也跟本地方法保持同樣的形式，寫起來跟本地函數(shù)調(diào)用沒有區(qū)別。這在以前用 C/C++ 編寫邏輯的時候是很難做到的。

其次，引擎內(nèi)部做好對象的管理工作，負責把通訊協(xié)議上的 id 轉(zhuǎn)換成邏輯層中的對象傳遞給邏輯層使用。

再次，enum 這樣的類型再也不需要用一些數(shù)字的常數(shù)了，也不需要在腳本額外的定義出來。可以在接口文件中定義好，經(jīng)過引擎的處理后，邏輯層可以直接用更為友好的字符串代替，而不失去效率。

編寫邏輯的程序員不再需要關(guān)心網(wǎng)絡(luò)的問題后，就可以把心思放在細節(jié)上。

最后，對于實現(xiàn)行為預(yù)測來補償網(wǎng)絡(luò)延遲的特性上。在先前的版本中，我們?yōu)榱藢崿F(xiàn)這個，花了不少的氣力。主要是將時間戳信息放在基礎(chǔ)通訊協(xié)議中來輔助實現(xiàn)。具體的消息包收到后，再計算延遲時間來推算當前的狀態(tài)。現(xiàn)在，可以把時間信息封裝到 RPC 中，讓每個遠程方法自動帶有延遲時間，方便計算。按模擬程序的實際效果上看，單單位置同步的預(yù)測策略，可以讓延遲在 8 秒之內(nèi)的玩家可以忍受；而延遲小于 1 秒的時候，幾乎不會受到滯后的影響了。

關(guān)于每個鏈接感興趣的信息的問題，決定了每個邏輯對象的狀態(tài)改變要通知哪些人。目前的想法是獨立到單獨進程去處理，我們在處理連接的服務(wù)器和處理邏輯的服務(wù)器之間設(shè)置單獨的服務(wù)器來管理每個鏈接感興趣的對象，這個任務(wù)相對單一且責任重大，獨立出來可以大大減輕邏輯服務(wù)器的復(fù)雜度。