談這個話題之前，首先要讓大家知道，什么是服務器。在網絡游戲中，服務器所扮演的角色是同步，廣播和服務器主動的一些行為，比如說天氣，NPC AI之類的，之所以現在的很多網絡游戲服務器都需要負擔一些游戲邏輯上的運算是因為為了防止客戶端的作弊行為。了解到這一點，那么本系列的文章將分為兩部分來談談網絡游戲服務器的設計，一部分是講如何做好服務器的網絡連接，同步，廣播以及NPC的設置，另一部分則將著重談談哪些邏輯放在服務器比較合適，并且用什么樣的結構來安排這些邏輯。
服務器的網絡連接
　　大多數的網絡游戲的服務器都會選擇非阻塞select這種結構，為什么呢？因為網絡游戲的服務器需要處理的連接非常之多，并且大部分會選擇在Linux/Unix下運行，那么為每個用戶開一個線程實際上是很不劃算的，一方面因為在Linux/Unix下的線程是用進程這么一個概念模擬出來的，比較消耗系統資源，另外除了I/O之外，每個線程基本上沒有什么多余的需要并行的任務，而且網絡游戲是互交性非常強的，所以線程間的同步會成為很麻煩的問題。由此一來，對于這種含有大量網絡連接的單線程服務器，用阻塞顯然是不現實的。對于網絡連接，需要用一個結構來儲存，其中需要包含一個向客戶端寫消息的緩沖，還需要一個從客戶端讀消息的緩沖，具體的大小根據具體的消息結構來定了。另外對于同步，需要一些時間校對的值，還需要一些各種不同的值來記錄當前狀態，下面給出一個初步的連接的結構：
typedef connection_s {
??? user_t *ob; /* 指向處理服務器端邏輯的結構 */
??? int fd; /* socket連接 */
??? struct sockaddr_in addr; /* 連接的地址信息 */
??? char text[MAX_TEXT]; /* 接收的消息緩沖 */
??? int text_end; /* 接收消息緩沖的尾指針 */
??? int text_start; /* 接收消息緩沖的頭指針 */
??? int last_time; /* 上一條消息是什么時候接收到的 */
??? struct timeval latency; /* 客戶端本地時間和服務器本地時間的差值 */
??? struct timeval last_confirm_time; /* 上一次驗證的時間 */
??? short is_confirmed; /* 該連接是否通過驗證過 */
??? int ping_num; /* 該客戶端到服務器端的ping值 */
??? int ping_ticker; /* 多少個IO周期處理更新一次ping值 */
??? int message_length; /* 發送緩沖消息長度 */
??? char message_buf[MAX_TEXT]; /* 發送緩沖區 */
??? int iflags; /* 該連接的狀態 */
} connection_t;
　　服務器循環的處理所有連接，是一個死循環過程，每次循環都用select檢查是否有新連接到達，然后循環所有連接，看哪個連接可以寫或者可以讀，就處理該連接的讀寫。由于所有的處理都是非阻塞的，所以所有的Socket IO都可以用一個線程來完成。
　　由于網絡傳輸的關系，每次recv()到的數據可能不止包含一條消息，或者不到一條消息，那么怎么處理呢？所以對于接收消息緩沖用了兩個指針，每次接收都從text_start開始讀起，因為里面殘留的可能是上次接收到的多余的半條消息，然后text_end指向消息緩沖的結尾。這樣用兩個指針就可以很方便的處理這種情況，另外有一點值得注意的是：解析消息的過程是一個循環的過程，可能一次接收到兩條以上的消息在消息緩沖里面，這個時候就應該執行到消息緩沖里面只有一條都不到的消息為止，大體流程如下：
while ( text_end – text_start > 一條完整的消息長度 )
{
??? 從text_start處開始處理;
??? text_start += 該消息長度;
}
memcpy ( text, text + text_start, text_end – text_start );
　　對于消息的處理，這里首先就需要知道你的游戲總共有哪些消息，所有的消息都有哪些，才能設計出比較合理的消息頭。一般來說，消息大概可分為主角消息，場景消息，同步消息和界面消息四個部分。其中主角消息包括客戶端所控制的角色的所有動作，包括走路，跑步，戰斗之類的。場景消息包括天氣變化，一定的時間在場景里出現一些東西等等之類的，這類消息的特點是所有消息的發起者都是服務器，廣播對象則是場景里的所有玩家。而同步消息則是針對發起對象是某個玩家，經過服務器廣播給所有看得見他的玩家，該消息也是包括所有的動作，和主角消息不同的是該種消息是服務器廣播給客戶端的，而主角消息一般是客戶端主動發給服務器的。最后是界面消息，界面消息包括是服務器發給客戶端的聊天消息和各種屬性及狀態信息。
　　下面來談談消息的組成。一般來說，一個消息由消息頭和消息體兩部分組成，其中消息頭的長度是不變的，而消息體的長度是可變的，在消息體中需要保存消息體的長度。由于要給每條消息一個很明顯的區分，所以需要定義一個消息頭特有的標志，然后需要消息的類型以及消息ID。消息頭大體結構如下：
type struct message_s {
??? unsigned short message_sign;
??? unsigned char message_type;
??? unsigned short message_id
??? unsigned char message_len
}message_t;
服務器的廣播
　　服務器的廣播的重點就在于如何計算出廣播的對象。很顯然，在一張很大的地圖里面，某個玩家在最東邊的一個動作，一個在最西邊的玩家是應該看不到的，那么怎么來計算廣播的對象呢？最簡單的辦法，就是把地圖分塊，分成大小合適的小塊，然后每次只象周圍幾個小塊的玩家進行廣播。那么究竟切到多大比較合適呢？一般來說，切得塊大了，內存的消耗會增大，切得塊小了，CPU的消耗會增大（原因會在后面提到）。個人覺得切成一屏左右的小塊比較合適，每次廣播廣播周圍九個小塊的玩家，由于廣播的操作非常頻繁，那么遍利周圍九塊的操作就會變得相當的頻繁，所以如果塊分得小了，那么遍利的范圍就會擴大，CPU的資源會很快的被吃完。
　　切好塊以后，怎么讓玩家在各個塊之間走來走去呢？讓我們來想想在切換一次塊的時候要做哪些工作。首先，要算出下個塊的周圍九塊的玩家有哪些是現在當前塊沒有的，把自己的信息廣播給那些玩家，同時也要算出下個塊周圍九塊里面有哪些物件是現在沒有的，把那些物件的信息廣播給自己，然后把下個塊的周圍九快里沒有的，而現在的塊周圍九塊里面有的物件的消失信息廣播給自己，同時也把自己消失的消息廣播給那些物件。這個操作不僅煩瑣而且會吃掉不少CPU資源，那么有什么辦法可以很快的算出這些物件呢？一個個做比較？顯然看起來就不是個好辦法，這里可以參照二維矩陣碰撞檢測的一些思路，以自己周圍九塊為一個矩陣，目標塊周圍九塊為另一個矩陣，檢測這兩個矩陣是否碰撞，如果兩個矩陣相交，那么沒相交的那些塊怎么算。這里可以把相交的塊的坐標轉換成內部坐標，然后再進行運算。
　　對于廣播還有另外一種解決方法，實施起來不如切塊來的簡單，這種方法需要客戶端來協助進行運算。首先在服務器端的連接結構里面需要增加一個廣播對象的隊列，該隊列在客戶端登陸服務器的時候由服務器傳給客戶端，然后客戶端自己來維護這個隊列，當有人走出客戶端視野的時候，由客戶端主動要求服務器給那個物件發送消失的消息。而對于有人總進視野的情況，則比較麻煩了。
　　首先需要客戶端在每次給服務器發送update position的消息的時候，服務器都給該連接算出一個視野范圍，然后在需要廣播的時候，循環整張地圖上的玩家，找到坐標在其視野范圍內的玩家。使用這種方法的好處在于不存在轉換塊的時候需要一次性廣播大量的消息，缺點就是在計算廣播對象的時候需要遍歷整個地圖上的玩家，如果當一個地圖上的玩家多得比較離譜的時候，該操作就會比較的慢。
服務器的同步
　　同步在網絡游戲中是非常重要的，它保證了每個玩家在屏幕上看到的東西大體是一樣的。其實呢，解決同步問題的最簡單的方法就是把每個玩家的動作都向其他玩家廣播一遍，這里其實就存在兩個問題：1，向哪些玩家廣播，廣播哪些消息。2，如果網絡延遲怎么辦。事實上呢，第一個問題是個非常簡單的問題，不過之所以我提出這個問題來，是提醒大家在設計自己的消息結構的時候，需要把這個因素考慮進去。而對于第二個問題，則是一個挺麻煩的問題，大家可以來看這么個例子：
　　比如有一個玩家A向服務器發了條指令，說我現在在P1點，要去P2點。指令發出的時間是T0，服務器收到指令的時間是T1，然后向周圍的玩家廣播這條消息，消息的內容是“玩家A從P1到P2”有一個在A附近的玩家B，收到服務器的這則廣播的消息的時間是T2，然后開始在客戶端上畫圖，A從P1到P2點。這個時候就存在一個不同步的問題，玩家A和玩家B的屏幕上顯示的畫面相差了T2-T1的時間。這個時候怎么辦呢？
　　有個解決方案，我給它取名叫 預測拉扯，雖然有些怪異了點，不過基本上大家也能從字面上來理解它的意思。要解決這個問題，首先要定義一個值叫：預測誤差。然后需要在服務器端每個玩家連接的類里面加一項屬性，叫latency，然后在玩家登陸的時候，對客戶端的時間和服務器的時間進行比較，得出來的差值保存在latency里面。還是上面的那個例子，服務器廣播消息的時候，就根據要廣播對象的latency，計算出一個客戶端的CurrentTime，然后在消息頭里面包含這個CurrentTime，然后再進行廣播。并且同時在玩家A的客戶端本地建立一個隊列，保存該條消息，只到獲得服務器驗證就從未被驗證的消息隊列里面將該消息刪除，如果驗證失敗，則會被拉扯回P1點。然后當玩家B收到了服務器發過來的消息“玩家A從P1到P2”這個時候就檢查消息里面服務器發出的時間和本地時間做比較，如果大于定義的預測誤差，就算出在T2這個時間，玩家A的屏幕上走到的地點P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再繼續走下去，這樣就能保證同步。更進一步，為了保證客戶端運行起來更加smooth，我并不推薦直接把玩家拉扯過去，而是算出P3偏后的一點P4，然后用(P4-P1)/T(P4-P3)來算出一個很快的速度S，然后讓玩家A用速度S快速移動到P4，這樣的處理方法是比較合理的，這種解決方案的原形在國際上被稱為（Full plesiochronous），當然，該原形被我篡改了很多來適應網絡游戲的同步，所以而變成所謂的：預測拉扯。
　　另外一個解決方案，我給它取名叫 驗證同步，聽名字也知道，大體的意思就是每條指令在經過服務器驗證通過了以后再執行動作。具體的思路如下：首先也需要在每個玩家連接類型里面定義一個latency，然后在客戶端響應玩家鼠標行走的同時，客戶端并不會先行走動，而是發一條走路的指令給服務器，然后等待服務器的驗證。服務器接受到這條消息以后，進行邏輯層的驗證，然后計算出需要廣播的范圍，包括玩家A在內，根據各個客戶端不同的latency生成不同的消息頭，開始廣播，這個時候這個玩家的走路信息就是完全同步的了。這個方法的優點是能保證各個客戶端之間絕對的同步，缺點是當網絡延遲比較大的時候，玩家的客戶端的行為會變得比較不流暢，給玩家帶來很不爽的感覺。該種解決方案的原形在國際上被稱為（Hierarchical master-slave synchronization），80年代以后被廣泛應用于網絡的各個領域。
　　最后一種解決方案是一種理想化的解決方案，在國際上被稱為Mutual synchronization，是一種對未來網絡的前景的良好預測出來的解決方案。這里之所以要提這個方案，并不是說我們已經完全的實現了這種方案，而只是在網絡游戲領域的某些方面應用到這種方案的某些思想。我對該種方案取名為：半服務器同步。大體的設計思路如下：
　　首先客戶端需要在登陸世界的時候建立很多張廣播列表，這些列表在客戶端后臺和服務器要進行不及時同步，之所以要建立多張列表，是因為要廣播的類型是不止一種的，比如說有local message,有remote message,還有global message 等等，這些列表都需要在客戶端登陸的時候根據服務器發過來的消息建立好。在建立列表的同時，還需要獲得每個列表中廣播對象的latency，并且要維護一張完整的用戶狀態列表在后臺，也是不及時的和服務器進行同步，根據本地的用戶狀態表，可以做到一部分決策由客戶端自己來決定，當客戶端發送這部分決策的時候，則直接將最終決策發送到各個廣播列表里面的客戶端，并對其時間進行校對，保證每個客戶端在收到的消息的時間是和根據本地時間進行校對過的。那么再采用預測拉扯中提到過的計算提前量，提高速度行走過去的方法，將會使同步變得非常的smooth。該方案的優點是不通過服務器，客戶端自己之間進行同步，大大的降低了由于網絡延遲而帶來的誤差，并且由于大部分決策都可以由客戶端來做，也大大的降低了服務器的資源。由此帶來的弊端就是由于消息和決策權都放在客戶端本地，所以給外掛提供了很大的可乘之機。

?

總結

以上是生活随笔為你收集整理的小谈Online-game服务器端设计（1、2）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。