遊戲引擎剖析（七）

原文作者：Jake Simpson
譯者： 向海

第7部份: 網路和連線遊戲環境

網路遊戲
　　我記得一些年前坐在GDC（遊戲開發人員大會）聽負責開發X-Wing Vs TIE Fighter的傢伙們題為“淹沒在Internet” 的演講，全是關於讓網路遊戲即時地在Internet上工作的東西。他們選擇那個題目是多麼的正確啊。當它開始處理資料包的丟失，亂序，潛伏（一個資料包發送到它的目的地所花的時間）等等時，它確實淹沒了。然而它是可能的。對於Internet需要一些聰明和經驗，但它是肯定可能的。看看今天大量的連線遊戲，從Quake III，Unreal Tournament，Counter Strike一直到EverQuest和Ultima Online。

　　如今大多數真正有長久生命力的遊戲都至少有一些連線成分。最純粹的單人遊戲容易玩一次，也許兩次，或者甚至三次如果它是非常好的遊戲，但一旦遊戲結束，就被束之高閣了。如果你想要有任何長久生命力，那麼多人連線遊戲就是形勢的核心所在，並且那意味著和Internet打交道，為編碼者開啟了那個潘多拉的盒子。

　　那麼跟Internet打交道包括些什麼呢？首先是要理解Internet是怎麼工作的，和點對點與客戶機/伺服器體繫結構的快速討論。點對點就是你在兩台機器上運行遊戲，並簡單地在它們之間共用輸入。每個單獨的遊戲假定它是正確的，並僅僅在它一幀接一幀的重新整理中合并來自另外一台機器的輸入。客戶機/伺服器是一台機器有效地運行遊戲，別的機器僅僅是一個終端，接受來自玩家的輸入，並渲染伺服器讓它渲染的任何東西。

　　客戶機/伺服器的優點是每台機器都將會展現相同的遊戲，因為所有的處理都在一個地方完成，沒有跨越多台機器，你可以不用考慮每台機器相互之間的同步問題。不足之處是，伺服器本身需要有一些重要的CPU可用時間來處理每一個串連的客戶機，和一個合適的網路連接來確保每一個客戶機及時地接收到它的更新。

瞭解IP
　　我們都已經聽說過TCP/IP（傳輸控制通訊協定/網間協議）和UDP（使用者資料包協議）， 在Web網路上有大量關於這些協議的深奧的技術資訊。實際上，在Cisco網站上有一些極好的TCP/IP指導。我們將在較高層面上介紹一些TCP/IP的基本知識，目的是讓你更好地瞭解使用這些標準協議的網路遊戲設計者面臨的挑戰。

　　TCP/IP和UDP/IP是兩層的通訊協定系統。IP層負責網際資料包的傳輸。UDP或者TCP層將大的資料包傳給IP，IP將資料包分割為小的子資料包，為每個資料包加上一個信封，計算出目的地的IP地址，應該如何到達那裡，然後將資料包發送到你的ISP，或者不管怎樣你串連到網路。 這實在象是在一張明信片上寫下你要發送的，貼上郵票，寫上地址，塞進一個郵箱，它就送走了。

　　UDP和TCP是從你編碼者或者遊戲接收資料包的高層協議，並決定該如何處理這些資料包。UDP和TCP的區別在於TCP保證資料包的傳送和有序，而UDP不保證。UDP是一條直接和IP對話的小路，而TCP是在你和IP之間的一個介面。它像是在你和你的郵件之間有一個管理員助手。使用UDP你會自己為你的信打字，把它們放進一個信封等等。使用TCP你會僅僅向你的管理員口授信稿，管理員會做全部的工作並追蹤確認信件送到了。

　　然而，所有這些令人驚奇的為你完成的工作伴隨著代價。為了確定資料包通過Internet完好無損地送到了目的方，TCP期待從目的方為它發送的每個資料包發回一個應答包（網路用語是ACK）。如果它在一定時間內沒有收到ACK，它就停止發送任何新的資料包，重新發送丟失的資料包，並且將繼續這樣做直到收到目的方的回應。當你訪問一個網頁時，我們都已經看到了這種情形，在半途中下載停止了一會然後又重新開始了。可能是一個資料包在什麼地方丟失了（假定不時ISP的問題），在任何更多的資料包被發送以前TCP要求重新發送它。

　　這一切的問題是，在認識到出了差錯的寄件者和實際上正在送達的資料包之間出現了延遲。有時這能花上數秒鐘，如果你僅僅只是下載一個檔案或一個網頁，這不是什麼大礙，但如果這是一個遊戲資料包而且每秒至少有十次，那麼你真的是遇到麻煩了，尤其是因為它停止了其他一切事情。實際上就是這個問題所以幾乎沒有遊戲選擇使用TCP作為它們主要的Internet協議，除非它不是一個即時動作遊戲。大多數遊戲使用 UDP--他們不能保證有序或可靠送達，但它確實很快—或者結果是至少通常比TCP/IP更快。現在我們瞭解這些了，接下來呢？

用戶端預測
　　因為 UDP 明顯的是快速響應遊戲的方式，我們將必須自己處理資料包的丟失和亂序。邊而且這是技巧所在。不用說出太多的代碼秘密，我就能說有方法。作為開始，有用戶端預言，一個被談論得相當多的詞語。當你作為一個用戶端串連到一個大的伺服器，但是不能連貫地看見來自伺服器的更新，用戶端預言開始起作用了。正在你的電腦上啟動並執行遊戲部分看著你正給它的輸入，並在缺乏來自伺服器的任何棄絕資訊的情況下，對它認為將繼續進行的事情作出‘最好的猜測’。它將會顯示被猜測的資料，然後當它得到來自伺服器的世界的最新狀態時，改正它自己，如果需要。你可能會對這個方法的效力感到驚訝。大體而言，大部分時間資料包不容易丟失—大多數時候是一秒的幾十分之一，這種情況下遊戲沒有太多的時間偏離伺服器實際上認為正在發生的事情。偏離確實會隨著時間變的比較大，大多數遊戲裡面有一個逾時功能，當出現很長時間沒有來自伺服器的聯絡時就停止遊戲。

　　你正在創造的遊戲類型在這裡有關係 -- 第一人稱射擊遊戲不需要這樣有效用戶端預言，因為它多數情況下僅僅處理“我在哪兒，我是否要射擊？”。在第三人稱遊戲中，你必須更加精確，因此你能夠正確地預測你的角色現正播放的動畫，並且動作流暢。在這種情形中流暢的動畫是完全必要的。Heretic II在這方面有很大的問題，並且是當它開始網路編碼時Raven一直不得不處理的最困難的事情之一。

　　當然如果你有一個很不錯的網路連接，比如寬頻連線，那麼這個問題就遠沒有那麼重要。對比較大的資料包有一個更寬的管道，對你的網路連通時間更快速。事實上，寬頻對於遊戲的主要優點不比較胖的管道多，但大大減少了延遲，特別是你到ISP的第一跳上。對於56K 數據機，第一跳典型的延遲是100ms，這已經嚴重地增加了你到網路上任意一台遊戲伺服器的潛在連通時間。對於寬頻連線比如像DSL，第一跳的延遲時間多半是20ms。使用Windows中一個叫做TraceRoute（TRACERT.EXE）的命令列程式並指定一個目標IP地址或者網域名稱，你能夠找出你的第一跳的連通時間。仔細觀察第一跳，因為這幾乎總是你到你的ISP的網路連通時間。並且觀察你在你的ISP的網路內部用了多少跳直到你看見在一個給定跳上列出的一個不同的網域名稱。

　　請注意，寬頻並不總是能解決延遲問題。你仍然受最慢的路由器/伺服器和資料包從伺服器穿越網路到達你的跳數（反之亦然）的支配。有一個寬頻連線確實容易緩和這些，但不可能它們最後就消失了。當然，如果你打算要運行某種伺服器，你將會需要一個具有足夠快速的向上遊的資料速率的頻寬，因為僅僅一個數據機不能夠處理一個伺服器產生的負荷。

　　值得一提的是，如果你想要在PS2或者Xbox上面玩網路遊戲，你將需要一個寬頻連線，因為它們兩者都不支援數據機。

包大小，智能資料轉送，和反作弊
　　別的必須被處理的事情是資料包的大小。如果你在一個遊戲裡面64個人都在跑來跑去相互攻擊，從一台機器發送到另外一台機器的資料包能變得相當大，達到了一些數據機沒有頻寬處理這些資料的程度。這正在變得特別和那些有著很大的地表系統的遊戲有關。這裡增加的問題是，因為你有這個很好的地表系統，你能夠看得很遠，因此能夠看見許多其他遊戲玩家，使得你為了精確渲染所需要的來自伺服器的資料數量以很快的速率增長。我們能做什麼呢？

　　好吧，首先必要的是只發送絕對必須的東西給任何給定的用戶端，因此他僅僅得到從他的角度觀察遊戲所需要的東西。發送在他視野以外的人們的資料沒有一點意義—他將看不見這些。同時，你最好確保只發送那些每幀之間實際上發生改變的資料。如果一個傢伙仍然在播放相同的動畫，重新發送資料沒有意義。當然，如果資料包丟失時這確實帶來一些問題，但這就是為什麼好的網路程式員被支付很多金錢，來處理類似這樣的東西。

　　還有一些其他的事情也要處理。最近已經有大量的令人苦惱的連線作弊正在發生。這是某些人修改遊戲以給他們不正當利益的地方。儘管嚴格意義上這不是網路的一部分，但它確實發生了。有時人們會創作一些模組，允許他們立即瞄準進入視野的任何人，或者簡單地允許他們看穿牆壁，或者讓其他遊戲玩家看不見他們自己。大部份時間這些事情可以在網路層內部或者在伺服器上被處理。任何有100%命中率的人被簡單地踢出遊戲，因為在人力所及的範圍內那是不可能的。

　　遊戲開發人員必須盡一切可能制止作弊行為，但很不幸，人做的東西可以被人突破。所有你能做的就是讓作弊變得困難，當確實發生時去嘗試發現它。

　　好吧，現在就到這裡了。在第8部分中，我們將會看看遊戲指令碼系統的趣味世界，根據遊戲過程中出現的事件來渲染或使能預先定義的情境和行為，協助故事敘述。