不會飛的鳥

2010年12月10日 ... 不鳥他們！！！我要用自己開發的分布式文件系統、分布式調度系統、分布式檢索系統，做自己的搜索引擎！！！大魚有大志！！！ ---楊書童

統計

隨筆 - 89
文章 - 1
評論 - 18
引用 - 0

常用鏈接

留言簿(4)

隨筆檔案

文章檔案

2006年4月 (1)

搜索

閱讀排行榜

評論排行榜

游戲引擎基礎（七）（網絡和連線游戲環境）

第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部分中，我們將會看看游戲腳本系統的趣味世界，根據游戲過程中出現的事件來渲染或使能預先定義的場景和行為，協助故事敘述。

夢在天涯 2007-12-04 13:24 發表評論

posted on 2009-04-10 10:44 不會飛的鳥閱讀(139) 評論(0) 編輯收藏引用

只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品