遊戲引擎全剖析(5-8)

第5部分: 物理,運動,效果

 


世界建造
  常常在建立一個含有任何3D成分的遊戲時,你最終要試圖建立一個將會在裏面產生遊戲動作的3D環境。 不知怎麼的遊戲開發者提供了一個建立這種環境的方,它容易修改,有效率,有較低的多邊形數量,對於遊戲既容易渲染又容易運用物理學。很簡單,對嗎?當做這個的時候我用左手在做什麼?當做這的時候 , 我對我的左手做什麼? 是的。不錯。 

  雖然那裏有許多3D結構程序,從CAD/CAM程序到3D Studio Max,建造遊戲世界是不同於建造內部或外部世界的模型的尷尬。你有三角形數量問題 -- 任何給定的渲染器一次只能渲染這麼多的多邊形,這對於天才的關卡設計師來說永遠都不夠。不知這些,你也只能每個關卡存儲預定數量的多邊形,所以即使你的渲染器能夠在視野中處理250,000個多邊形,即使你只能在合理數量的空間中存儲500,000個多邊形,那麼取決於你怎麼處理它,最後你的關卡價值像兩個房間那麼小。不好。 

  任何方法,開發者需要提出一個創作工具 -- 最好足夠靈活,允許遊戲引擎需要的各種事物 – 比如,在世界中放置對象,在進入遊戲以前對關卡的適當預覽,以及準確的光照預覽。在他們花三個小時預先處理關卡來產生一個 '引擎可消化的' 格式之前 , 這些能力允許遊戲開發者看到關卡將在遊戲中看起來怎麼樣。 開發者需要關於關卡,多邊形數量,網格數量等等的相應數據。 他們需要一個合宜而友好的方式能夠讓世界有紋理背景圖,容易存取多邊形數量縮減工具,如此等等。這個清單可以繼續列下去。 

  在先前已經存在的工具中找到這個功能是可能的。許多開發者使用Max或者Maya建造他們的關卡, 但即使3D Max需要對它的功能有一些任務特定的擴展來有效率地完成關卡建造工作。甚至可能使用關卡建造工具,像QERadient(見下圖),而且把它的輸出重新處理成你的引擎能夠解釋的格式。


不能看見它? 別煩擾…
  回想一下我們在第一部分討論的BSP (二叉空間分割) 樹,你也可能聽說過潛在可視集合(PVS)這個術語正被四處談論。兩者都有相同的目標,不去探究涉及到的繁雜的數學,它是一種把世界分解爲你能從世界任何給定位置看見的牆壁的最小子集的方式。在實現時,它們僅僅返回你能看見的那些,而不是那些隱藏在可能被遮擋的牆壁後面的。你能想象出這給軟件渲染器帶來的好處,渲染的每個像素(可能是這樣的情形)極爲重要。它們也按從後到前的順序返回那些牆壁,在渲染時這是很方便的,因爲你能夠在渲染次序中確定一個對象的實際位置。 

  大體而言,BSP 樹最近正不受歡迎,由於它們的一些古怪,而且因爲我們從當今3D顯示卡獲得的像素吞吐量,再加上Z緩衝像素測試,BSP 常常成了一個多餘的過程。它們在計算出你在世界的確切位置和正在你周圍的幾何物體方面是便利的,但常常有比BSP樹更好而且更直觀的方式來存儲這些信息。 

  潛在可視集像它聽上去一樣非常好。它是這麼一個方法,在任何給定時間,給定你在世界的位置,它決定世界的哪些表面,哪些對象實際上可以看得見。這時常用來在渲染之前剔除對象,也剔除它們來減少AI和動畫處理。畢竟,如果你實際上不能看見它們,爲什麼還要費腦筋處理呢。多半這真的是不重要的,如果一個非玩家角色(NPC)正在播放動畫,或者甚至在運行它的AI思考。


遊戲物理學
  既然我們已經在內存中得到了世界的結構,我們必須防止我們的角色從裏面掉落出去,並處理地板,斜坡,牆壁,門,以及移動平臺。加之,我們必須正確地處理地心引力,速度變化,慣性,和放置在世界裏面的其它對象的碰撞。這被看作是遊戲物理學。而且在我們進一步深入討論之前,我想現在就在這裏消除一個神話。任何時候你在世界中看見物理,或者任何人在一個複雜的遊戲環境中宣稱“真實的物理”,很好,它是BS。超過80%的建造一個有效率遊戲物理系統的精力花在簡化用來處理世界中對象的真實方程式上面。甚至那時,你時常忽略什麼是‘真實的’,並創造一些‘有趣的’東西,畢竟,這是目標所在。

  經常地遊戲者將會忽視真實世界的牛頓物理學,並扮演他們自己的,更有趣的真實版本。例如,在QuakeII裏面,你能夠立即從0加速到35MPH,並快速停下來。沒有摩擦力,而且斜坡不提供真實斜坡提供的相同類型的重力問題。身體沒有它們應該的作用在所有關節上的地心引力 -- 你看不見身體像真實生活中那樣倒在桌子上面或者邊緣 -- 而且地心引力它本身甚至可能是可變的。 面對現實吧,在真正的世界中,空間中的飛船不像二戰飛行戰鬥員在它們的表面操作那樣實行。在空中,全部是力和反作用力,力在重量點周圍作用,等等。不像 X-Wing中的Luke Skywalker那樣嘯叫。儘管那樣做更加有趣! 

  作爲遊戲開發者來說,無論我們做什麼,我們需要能夠檢測牆壁,檢測地板,在世界中處理和其他對象的碰撞。這些是現代遊戲引擎的必備 – 我們決定對它們進一步要做的取決於我們和我們的遊戲需要。


效果系統
  如今絕大多數的遊戲引擎建造有某種效果產生器,這允許我們表現出有洞察力的遊戲者期盼的所有可愛的吸引眼球的東西。然而,效果系統幕後所進行的東西能夠急劇影響幀速率,所以這是我們需要特別關心的地方。如今我們有很棒的3D顯示卡,我們能夠傳送大量的三角形給它們,而且他們仍然要求更多的三角形。並不總是那樣。 在Heretic II,使用它的可愛的軟件渲染模式,由於他們漂亮的符咒效果,Raven遇到了相當嚴重的過度繪製問題。回想當你在屏幕上繪製相同的像素超過一次時,過度繪製就發生了。當你有許多效果正在進行,按其性質你有許多三角形,多個三角形可能相互堆疊在彼此上面。結果是你有許多重複繪製的像素。加上Alpha,這意味着在重新繪製之前你必須讀取舊像素並和新的像素混合,這會消耗更多的CPU時間。 

  Heretic II的一些效果能說明這點,我們在一幀裏對整個屏幕重複繪製了四十遍。很驚訝,是嗎?因此他們在效果系統裏面實現了一個系統採樣在過去30幀的幀速率,如果速度開始減慢,它就自動地縮減任何給定效果繪製的三角形數量。這樣使主要工作完成了,幀速率保持住了,但一些效果看上去很醜陋。 

  無論如何,因爲如今絕大多數效果傾向使用大量很小的粒子模擬火和煙等等,結果你在效果代碼裏面每幀要處理許多的三角形。你必須把它們從一幀移動到下一幀,決定它們是否完成了,甚至還要在它們身上運用一些物理學以便讓它們在地板上面適當的反彈。這在PC上面都是相當昂貴的,因此甚至現在你必須對你所能夠做的有一些實際限制。舉例來說,用一個像素粒子產生火的效果可能會很好,但當你這麼做的時候就別期望在屏幕上做更多別的事情。 

  粒子被定義爲擁有它們自己的世界位置和速度的非常小的可繪製的物體。它們不同於有方向的精靈,大的粒子使用這些精靈 -- 比如噴出的一團團煙霧。它們面向照相機自動而典型地旋轉,縮放,改變它們的透明級別,因此它們能夠隨着時間淡出。我們容易看到大量的粒子,但我們卻限制精靈的數量—儘管兩者之間的真正不同如今正在模糊。將來,特別是在 DX9 和更加高級的圖形硬件表面以後,我們可能看到更多的人們使用過程shader來產生跟粒子系統相似或者更好的效果,創造非常棒的動畫效果。 

  當談論效果系統時,你可能聽說過‘圖原’這個詞。一個圖原是你的效果系統將處理的效果的最低級別的物理表現。更進一步解釋,一個三角形是一個圖原。那是絕大多數引擎最終在底層繪製的 -- 大量的三角形。當你沿着系統向上時,你對圖原的定義隨着變化。比如說,頂層的遊戲程序員不想考慮處理個別的三角形。他僅僅想說,"這個效果在這裏發生" 並讓系統以一種黑盒方式處理它。因此對於他來說,一個效果圖原就是‘讓我們在世界的這點持續這麼長時間用這樣的引力產生一束粒子’。在效果系統內部,它可能認爲一個效果圖原是它那時正在產生的每個單獨的效果,像一組遵循同樣的物理學規則的三角形—然後它傳送所有這些單獨的三角形到渲染器進行渲染,因此在渲染器層次,圖原就是一個單獨的三角形。有一點困惑,但你知道總的思想了。 

  以上就是第五部分,下一個部分是關於聲音系統,和各種不同的音頻APIs,3D音頻效果,處理閉塞和障礙,各種不同材料對聲音的影響,音頻混合等等。 

 

第6部分: 聲音系統,音頻APIs

 


聲音系統
  由於人們玩的遊戲在種類和技術上的進步,聲音和音樂近幾年來在遊戲中正逐漸變得重要起來(聲音是一個實際遊戲的可玩特點,比如在Thief和其它同類遊戲中的聽覺提示)。現在四聲道環繞系統在遊戲玩家的寶庫中是負擔得起的和平常的事。給定空間的聲音,噪音的障礙和閉塞,和動態的音樂,如今許多遊戲使用這些提高玩家情緒上的反應,更多的關注投入到這個領域就不足爲奇了。

  現在在PC競技場中,遊戲玩家實際上只有一種聲音卡可以選擇 -- PC聲卡製造商創新公司(Creative Labs)的Sound Blaster Live! 從舊的時間個人計算機聲音卡片製造業者有創造力的中心. 多年來創新公司已經爲DirectX提供了他們的EAX聲音擴展,並且他們是發起新的OpenAL(開放音頻庫Open Audio Library)的創立者。就如同OpenGL是一個圖形API一樣,OpenAL,像它起來聽一樣,是一個聲音系統的API。OpenAL 被設計爲支持大多數通常聲卡的許多特徵,而且在一個特定的硬件特徵不可得時提供一個軟件替代。

  爲了更好的定義 OpenAL,我向創新公司的Garin Hiebert詢問了其定義: 

  "這裏借用我們的 " OpenAL 規格和叄考" 的一個定義: 

  OpenAL 是對音頻硬件的一個軟件接口,給程序員提供一個產生高質量多通道輸出的能力。OpenAL 是在模擬的三維環境裏產生聲音的一種重要方法。它想要跨平臺並容易使用,在風格和規範上與OpenGL相似。任何已經熟悉OpenGL的程序員將發現OpenAL非常熟悉。 

  OpenAL API能容易地被擴展適應插件技術.創新公司已經把EAX支持加入到這套API了,程序員可以用來給他們的聲音環境增加複雜的反響,比賽和障礙效果。

  如同Jedi Knight II: Outcast 一樣,連同Eagle 世界/聲音特徵編輯器,Soldier of Fortune II 以這個新系統爲特徵。什麼是Eagle? 在介紹這個以前,讓我們討論一些其他的系統,並定義一些聲音術語。 


  另外的一個系統是Miles聲音系統。Miles是一家公司,它爲你的代碼生產插件,在充分利用每塊聲卡時處理所有必須的到特定聲音卡的說話(比如Sound Blaster Live!系列,或者老的A3D聲卡)。它非常像一個API前端,捆綁了一些額外的特徵在裏面。 在其他事物當中Miles讓你存取一些事物像MP3解壓縮。 它是很好的解決方案,但像任何事一樣,它花費金錢並是你的代碼和硬件之間的額外一層。雖然對於快速的聲音系統制造,它非常有用,而且他們有段時間了,因此他們的確精通自己的業務。


聲音術語
  讓我們開始障礙和閉塞。它們聽起來一樣,但不是這樣。閉塞基本上意謂着一個聲音在播放時聽者在他們之間有一些閉合的障礙物。 

  比如說,在NOLF2的一個屏幕鏡頭上你聽到房子裏面壞蛋的聲音。你能聽到他們,但是他們的聲音相當低沉而沙啞。障礙是相似的,但是你和聲音之間的障礙物並不是閉合的。一個好的例子就是在你和聲源之間有一根柱子。由於房間中的回聲你仍然聽得到這個聲音,但是它和聲音直接傳遞到你的耳朵裏是不同的。當然這確實依賴於知道在你的耳朵和聲源之間的直線上是什麼。而且根據房間的大小,聲源到你的距離等等,需要的處理能變得相當耗時。後面我們將會談到跟蹤--足可以說它時常是比較慢的幀速率的原因。Quake III 裏面的A3D 代碼做了這些事情,關閉這些選項通常能夠提高幀速率。Tribe 2 是這種弊病的另外一個受害者。關閉3D聲音選項則你的幀速率立即好轉,這在你考慮Tribes世界有多大和你能看見多遠時有意義。 

  接着是聲音物質的特徵。大部分聲卡可以讓你能夠用可定義的過濾器作用於聲音從而修正播放的聲音。例如,在水下,或者在一個布料遮蓋的房間中,或者在一個長的走廊中,或者在歌劇院,聽到的聲音有着很大的不同。能夠根據你所處的環境改變你聽到聲音的方式是相當不錯的。 

  我們回到Eagle… 這是一個編輯器,允許多數第一人稱射擊遊戲地圖設計者將他們的地圖導入到這個工具,然後構造簡化的幾何形體來爲實際遊戲引擎中的EAX代碼產生一個聲音地圖。其思想是你不需要一個真實的圖形地圖的複雜幾何形體來模擬聲音環境。你也能夠給產生的簡化地圖分配聲音物質,這樣聲音環境就能夠動態地改變。我親眼目睹了這在Soldier of Fortune和Unreal Tournament上的示範,確實相當引人注目。 我這在財富和 Unreal 巡迴賽和它的軍人上真的對示範是證人相當醒目. 當你跳入水中時,聽到所有的聲音改變,這是一個非常令人沉浸的經歷。 

  好,讓我們繼續吧。 

  對於遊戲機,由於靜態的硬件,你的各種可能性會更受限制 — 儘管在PlayStation 2和Xbox上,硬件相當不錯。我說的限制,僅僅是指擴展,而不是它所能夠做的。我一點也不會感到驚訝看到這些遊戲機上的遊戲很快支持杜比數字5.1(Dolby Digital 5.1)輸出。Xbox ,由於它的 MCP 音頻處理器,能夠將任何遊戲音頻編碼爲5.1,並且遊戲不需要特別編碼就能利用這個特徵。杜比(Dolby)把ProLogic II 帶到了 PS2 上,並與Factor 5合作爲GameCube遊戲實現了ProLogic II。在 Xbox 之上,Halo, Madden 2002 和 Project Gotham Racing等遊戲都有5.1杜比數字音頻內容。DTS最近也爲 PS2 遊戲開發者發佈了SDK,爲這個平臺上的遊戲帶來了降低了比特率的DTS音頻版本。


位置的聲音--一個複雜的世界
  現在有一些很少有處理的聲音空間化問題。我說的是把聲音放在一個真實的3D世界中。有四個揚聲器在你周圍是一個很棒的開始,但這仍然只是在二維方向。在你的上方和下方沒有揚聲器,你沒有真正獲得3D聲音。有一些聲音調製過濾器試圖解決這個問題,但實際上沒有真實東西的代替物。當然真實地大多數遊戲多半只是在二維方向上,因此這仍然不是太大的問題。 

  實際上任何聲音系統最重要的特徵之一是把聲音混合在一起。根據你所處的位置,空間中聲音的位置,每個聲音的音量大小,一旦你決定了實際上你能夠聽到的聲音,然後你必須混合這些聲音。通常聲音卡自己處理這些,這首先是聲音卡存在的主要原因。然而,外面有一些引擎決定首先用軟件做一次‘預混合’。直到你着眼於一點點歷史以前,這並沒有真正地帶來多大的意義。

  當聲音卡最初問世的時候,有許多不同的混合方法。一些聲卡可以混合8種聲音,一些單位16種,一些32種,等等。 如果你總想聽到16種可能的聲音,但你不知道聲音卡是否能夠處理,那麼你回到了嘗試和試驗的道路上 — 就是你自己用軟件混合。這實際上是Quake III聲音系統的工作方式,但提一個問題:"Quake III是爲A3D和Sound Blaster Live!聲卡世界發佈的,這比以前更加標準化,爲什麼還這樣做?" 這是個好問題。實際上Quake III的聲音系統幾乎每行代碼都和Quake II中的聲音系統一樣。而且Quake I,甚至Doom也是這樣。你想一想,向上直到 A3D 聲卡和 SB Live! 聲卡,許多年來聲音系統的需求沒有真正地改變過。兩個揚聲器,二維方向,音量簡單地隨着距離減小。從Doom一直到Quake III沒有發生太大變化。而且在遊戲行業中,如果不是迫不得已,別理會它。

  通常你會僅僅使用DirectSound爲你做聲音混合,因爲它會可以使用的聲音硬件,或者轉而依靠軟件,很多地方就像DirectX爲3D顯示卡所做的一樣。在 90% 的聲音情形中,依靠軟件混合對你的幀速率沒有真正發生太多不同。當DirectSound在一些狂熱的編碼者眼中甚至還不是一絲光線時,Doom引擎就已經產生了。它從來沒有得到更新過,因爲它從來就沒有真的需要更新。 

  當然,你可以使用 SoundBlaster Live!聲卡的一些聰明特徵,例如房間的回聲特性: 一塊石窟,或一個禮堂,一個巨穴, 一個足球體育館等。而且你真的應該使用由硬件提供的混合器,畢竟,那是它存在的目的。這種方法的一個不足之處是程序本身時常無法獲得混合結果,因爲混合是在聲卡內部完成而不是在主存。如果由於某種原因你需要看到產生的音量,你是運氣不好。


Music Tracks in Games(遊戲中的音軌)
  我們沒有過多的談到遊戲中的音樂生成。傳統的有兩種方法,一種是簡單的音樂 .wav 文件(或同等物)。它被預先製作做好,準備運行,和最小忙亂。然而,這些在內存和回放時間方面很昂貴。第二種方式用預設的樣本編碼MIDI音軌。這時常比較節省內存,但缺點是必須同時把一些聲音混合在一起,因而會把聲音通道用光。 

  動態音樂就是根據在遊戲中目睹的行動改變你的音樂的能力,比如探險用慢節奏的音樂,戰鬥用快節奏的音樂。預先製作的音樂的一個困難之處是要合拍,因此你可以從一段音樂漸弱到另一段音樂,這對於MIDI音軌比較容易。儘管時常你足夠快速地淡出,或者一段音樂在播放另一段音樂之前已經消失了,你能僥倖不被察覺。

  在我們離開這個主題之前,順便說一下,值得一提的是存在一些公司專門爲你的遊戲創作特定意義的音樂。FatMan(www.fatman.com) 就是一家這樣的公司。音樂可能比其他別的東西更加容易外包,這是他們存在的方式。 

  最後,遊戲現在的事情自然是MP3格式,允許巨大的11 :1的聲音樣本壓縮,然而在送到聲音卡之前只花費CPU很少的時間解壓縮。當我在Rave Software工作時,在Star Trek Voyager: Elite Force 中,我們設法用MP3在一張CD上面完全支持三種語言,仍然爲較多的圖形留有空間。主要地,我們 MP3 只用於非玩家角色(NPC)的語音,由於遊戲的全部音頻效果MP3流和動態解壓縮超出了硬件的處理能力,雖然在將來這是肯定可能的。比較新的格式,如來自 Dolby 的 AAC 和來自微軟的WMA,以將近兩倍MP3的壓縮率提供了相等或者更高的音頻質量(實際上一半的比特率),可能應用到將來的遊戲中。 

  以上是這一章節的內容,下面將是網絡和連線遊戲環境的開發。 


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


 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章