|
|
業界觀點：XNA是玩具？還是玩真的？
在本書第一章中，我們有提到微軟推出XNA Game Studio時，許多人的態度不儘儘是好奇，甚至還有保留與觀望。這點對於在遊戲業界中工作的我們，感受尤其明顯。我可以從我周遭的同事、業界朋友等人聽到各種褒貶不一的評論。 在XNA 1.0版剛推出的時候，遊戲業界對於這樣「又一個在PC上開發遊戲的SDK」的出現，比起業餘玩家的興奮程度，表現上相對是比較保守的。在PC上早已經有了成千上萬個從免費到幾萬美金的遊戲開發SDK，XNA的出現又代表什麽？讓業餘愛好者體會做遊戲新鮮感的新玩具？還是遊戲開發新時代的來臨？ 其實從業界的角度來想，會有這些質疑與觀望一點都不奇怪。以PC的遊戲開發來說，大多數的遊戲公司 (不論大小) 可能在過去幾年的遊戲產品開發過程中，早已經累積了太多既有的資源。這些包括開發人員已經使用的非常熟悉 (或者是自行開發) 的遊戲引擎、過去所有撰寫的輔助遊戲開發工具、程式碼等等。而且這些累積了五年十年的資源，絕大多數都是以 C/C++ 程式語言所開發的。如果一時三刻間要這些公司把早已累積多年的資源，替換成使用 C# 開發的XNA Game Studio，大部分人都會思考再三的。 這樣的論點乍看之下有理，其實並不竟然。這些資深開發人員並不見得真要丟掉自己過去用 C/C++ 所累積的心血。如果是針對PC，這些過去用C/C++開發的程式模組只要規劃得當，並不難做成可以給 .Net 環境使用的程式模組。在MSDN上你也找的到技術文章 (中文的喔)，教你如何「混用」.Net 與 原生 C/C++ 開發的程式碼。在本書中最明顯的例子就是我們的《城市賽車》所使用的 ODE 物理引擎。它就是一個第三方開發的免費物理引擎，而且全部是用 C/C++ 所撰寫。目前很多XNA的使用者，包括我們，都是將它包裝成 .Net 環境可以使用的程式模組讓 C# 程式直接去使用它的功能。 所以除了因為寫習慣了C/C++而不喜歡改用C#這類個人好惡的理由外，讓這些資深遊戲開發人員觀望的問題還有些什麽呢？ .Net 軟體執行效率大概是最關鍵的議題之一。在過去遊戲之所以難做，就是因為必須在電腦有限的效能下，壓榨出最大的運算能力，分配給畫面、音效、物理效果計算、遊戲中的人工智慧運算等等。在PC這種開放式環境，還有防毒軟體、背景下载軟體、與一堆安裝在系統中的背景服務程式要來分享有限的電腦效能。如今畫面處理、音效處理的運算負擔，都已經被3D會圖加速卡、音效卡這些硬體裝置幫忙分擔掉了。剩下使用 C# 最主要的考慮，就是遊戲本身的邏輯與人工智慧處理的效能問題，以及必要的數學運算 (譬如物理效果模擬)。 某些特殊的遊戲類型，必須大量的使用物理效果的模擬，這包括某些動作遊戲、需要極高真實程度的駕駛遊戲等等。針對PC的遊戲這可能還不是問題，因為我們可以把需要速度的物理效果運算做成原生的 C/C++ 模組供 XNA 遊戲使用，就像我們的賽車使用ODE.net一樣。不過這招對於XBox 360就沒轍了。因為在XBox 360上的 XNA 執行環境並不開放使用原生 C/C++ 模組。換句話說目前在 360 上，你只能使用 C# 程式碼來撰寫任何XNA Framework 沒有提供的功能，包括物理模擬。 另外就是那些需要大量人工智慧運算的遊戲類型。譬如戰爭遊戲中畫面上成千上萬的戰鬥單位，要如何進行戰術模擬與個別的戰鬥模擬，可能就會牽涉到模糊邏輯、類神經網路或是基因演算法等這些「吃效能的老祖宗」，在 .Net 環境下來執行就會有比較明顯的效能差別。同樣的這在PC不是問題，在 XBox 360 上就必須要做適度的簡化，或是改用其他效能負擔更輕的演算法來取代。 當然也有人會說，在電腦越來越快的時代，明年的C#執行速度，可能就和今年的C/C++程式碼執行的速度差不多了！不過這個論點一樣也有問題。同樣地，當明年的電腦速度比今年更快時，那些繼續使用 C/C++ 程式碼的開發人員又會把遊戲的各種效果推向更高的極限，因為遊戲玩家對話面效果的胃口成長速度，其實並不少於電腦效能的成長速度。照這樣說的話，用C#開發的遊戲，不是在效能與效果上永遠會略遜於原生 C/C++ 程式碼開發的遊戲嗎？ 上面這個論點是事實，但是它其實窄化了遊戲業界對「效能」的需求。在遊戲業界我們看重的「效能」並不是單單只有「遊戲執行的效能」；另一個可以說是一樣 (或更加) 重要的是「開發遊戲的效能」。能用更短的時間把遊戲做出來，在競爭激烈的遊戲產業中是很重要的。使用原生 C/C++ 程式碼開發遊戲，確實可以得到最大的自由度與最大的執行效能。但是相對地撰寫 C/C++ 程式所需要關心的事情，遠比撰寫 C# 要注意的事情多的多。 在遊戲中固然有一些極端需要效能的程式模組，其實大多數的程式模組並不需要有「最大的自由度與最大的執行效能」一樣可以達成它們的任務。有經驗的程式人員只需要檢視一下一款遊戲中用到的所有程式模組，就會發現其實大多數的程式模組都不見得真正需要最大的執行效能。 以台灣與大陸目前常見的PC網路休閒遊戲的用戶端來說，有些模組如網路資訊的傳輸與接收、畫面的繪製等等，都是我們希望要有最好執行效能的部分。如果用XNA Game Studio來開發的話，我會把網路的部分用原生的 C/C++ 做成XNA可以使用的模組，讓這個模組能以「最大的自由度與最大的執行效能」來處理各種網路遊戲連線傳輸會碰到的問題；至於畫面的繪圖，基本上XNA可以交給外部的shader來做，所以 C# 程式對於繪圖部分的效能拖累是有限的；剩下的遊戲邏輯、玩家的操控、音樂音效的播放等等，其實以 C# 來做在大部分情況還是可以接受的。(當然XNA 2.0也要支援網路了，不過目前它還未出來，所以對於功能、效能與防駭的處理是否能滿足需求還不能評論) 所以這個問題的思考重點，就成了效能與開發便利性的平衡點。 所以再回到原本的問題：XNA究竟只是個讓業餘愛好者做些小遊戲的「玩具」？還是「玩真的」，可以讓遊戲廠商開發商業上可以販賣的遊戲呢？當然你可以把它當成業餘之外的小玩具，在閒暇之餘用來實現一些自己想到的遊戲點子。你也可以認真思考在兼具執行的效能與開發的效率上，讓XNA Game Studio成為一個真正實用的開發工具。 下次李震宇老師還會和我們分享他個人從初步接觸到真正使用XNA開發遊戲的一些心得。
|