只是隨筆 --
遊戲程式設計初學者常遇之疑問
作者: 陳寬達
EMail: kuan@ilife.cx
DirectX 的角色
DirectX,這讓初學者最易搞混學習重心的罪魁禍首。
DirectX在遊戲開發者的歡呼聲中帶著一身眾人的期許誕生後,由於它的版本更新速度
遠比作業系統還快,因此,使用者不得不自行至網路上下載或由光碟來安裝DirectX
runtime library,DirectX就是由此吸引使用者的目光而得聲名大噪,就如同ActiveX,
COM,OLE一般,即使不曉得它究竟是什麼玩意,至少也能琅琅上口,輸人不輸陣嘛。緊接
著各大書局的電腦書區剛始成批出現打著"Games SDK"及"DirectX"名號的書籍,讓這
些對遊戲設計有著憧憬夢想卻還不得其門而入的遊戲愛好份子們誤以為DirectX是遊
戲程式設計最重要的一環。事實上,如同衣裝之於人類,DirectX之於Game Application
的關係僅止於外表的打理而已,至於內涵則是另話,與人的衣裝,Game Application的
DirectX同樣是八竿子打不著邊。
DirectX中,最重要的當屬DirectDraw,它是屬於不吃不可,不用不行型的,也就是說,
若微軟沒有推出DirectDraw這套程式庫,堂堂一個功力深厚上可飛天下能遁地的程式設
計師也照樣沒輒,無法突破GDI及HAL這些層層的防護直接控制顯示卡,唯有如此才能得
到最高的畫面顯示效能呀。也就是說,我們無法不依賴DirectDraw而擁有DirectDraw所
提供的功能及效率。至於另一個重要的元件,Direct3D,也與顯示卡驅動程式直接私通,
才能獲得快速的3D繪圖效能,同樣屬於不吃不可型（除非你偏好OpenGL）。其它的元件,
如DirectSound,DirectMusic,DirectPlay,DirectInput及DirectSetup等,都大大地方
便我們撰寫遊戲程式所花費的功夫,你也可以不使用它們而作到一樣的功能,不過既然別
人都為我們做的好好的了，除非有充分的理由（例如自行發展快速而穩固的TCP/IP連線
函式庫）,否則不去使用還還真是自找苦吃:p
另外,雖然DirectX是真正構築於COM(Common Object Model)上的套件,我想是為了降低
學習門檻及使用的方便性,設計者將較容易讓COM初學者困惑之處包裝起來,讓你不必先
閉關修煉COM三年後才能使用DirectX,就當作是一般的物件導件程式庫來用即可。所以
當你迫不急待想感受DirectX的power時,可以先暫時不理COM,用了再說；當你已能靈活
運用DirectX的好處時,可別忽略在底層辛苦出力的COM,是它的功勞才讓DirectX能以二
進位形式突破原始碼種類的限制讓你可以任意程式語言工具輕鬆享用物件導向程式設計
的好處,對這大功臣還是不可不熟悉熟悉唷。
嗯,回到原題, 提供極欲入門遊戲程式設計的各位一句經驗談,不必花太多的時間金錢及
精神在學習鑽研DirectX的微末細節,遊戲程式設計關鍵之處末過於整個遊戲的核心製
作及內容設計, 相較之下,DirectX真是比較輕鬆愉快的課題呢。試想: 以遊戲程式設計
員的角度來瞧, 對 DirectX 來說是 "user", 使用 DirectX 的 API; 而對遊戲核心及
內容來說, 是 "designer", 要設計高效率運作良好的核心及豐富迷人的內容來滿足遊
戲玩家們, 你覺得, 學習的重心該放在哪呢？
噢, 順便一提, 直到現在, 我仍認為對稍有經驗的程式員來說, 學習 DirectX 最好的
教科書即是 DirectX SDK 裏頭附的文件, 厚厚幾百頁, 讀一讀再寫一寫, 絕大部分
DirectX 的馬步工夫是可以這樣就學得的。
※
開發環境的選擇
對於許多剛接觸Windows程式設計的新手而言，要在各家說法紛云、眾多開發工具強伺
的環繞之下，選擇一個明智有把握又最適合自己的開發工具的可算是最難的一道入關
匣門了。不啻是新手，就連許多老手也常執著於同一套工具軟體，寧可使用鐘愛的工
具埋頭苦幹，無視於身旁更方便好用的解決方法，即使它可以省下開發者三倍的工作
時間。開發工具確是這樣重要的一項選擇, 選的好, 可讓你天天有時間陪陪女友看看
電視逗逗小狗, 萬一不幸選到難學難用難寫或者根本不適合該專案的開發工具, 就有
無盡的漫漫長夜等著你囉。
常跟朋友聊起, 面對開發工具及程式語言的選擇, 約略可將所有的程式員分為三大類：
『菜鳥型』對所有的開發工具程式語言甚至開發平臺全然陌生, 只是大略聽過一些開發
工具的名稱, 而且還經常背錯, 如 "Virtual C++", "Virtual Basic", "Dephli",
"Borland C Builder" 等等。這個族群所佔的比例最高, 也往往是在網路論壇上詢問
"該學什麼程式語言 ?" "我想寫遊戲, 該用什麼語言 ?"這類問題, 甚至常是引發程
式語言及開發工具優劣論辯的導火線, 雖然是矇懂無辜的。
『專家型』所謂專家, 即是訓練有素的...呃, 技術實力高人一等的...呃, 嗯, 專家。
他們通常精通一種開發工具, 獨衷一派程式語言, 擅於撰寫特定領域的程式, 該開發
工具提供的函式庫, framework 滾瓜爛熟。但, 卻往往獨衷特定工具及語言, 甚至帶
點宗教式的狂熱, 這類型的玩家常是網路論壇上語言及工具論辯的超級打手。
『無入而不自得型』他們往往會熟悉至少兩三種以上的開發工具及程式語言, 並將火力
集中在與語言無關的系統呼叫 (API)。於是, 開發 Client/Server Database 專案時,
拿 Delphi 來拉拉資料庫元件; 撰寫遊戲時, 裝起 C++Builder 下載 DGC 元件立刻拼
湊出一個遊戲外框; 專案用到 VxD, WDM 或 kernel mode driver 時, 捲起袖子拿出
SDK, DDK 加上 Visual C++, 再買套 VToolsD 或 Driver::Work 來立即動工。無所為
無所不為, 不執著於任何開發工具及語言, 自然不會被任何公司的規劃(如MS的VBA吃
遍天下)或美好遠景(如Inprise的Information Network)等解決方案所羈絆,而隨波逐
流了。
現在有許多電腦玩家常不由自主地對自己所鐘情的作業系統, 開發工具, 應用軟體甚
至遊戲及軟體公司產生幾近宗教崇拜式的不明究理的狂熱, 在此情況下, 很容易去找
到一個貌似敵對的 "對手"來反, 堅定自己的信仰, 壯大自己的聲勢, 例如 PC vs MAC,
FreeBSD/Linux vs MS Windows, Visual C++ vs C++Builder, Delphi vs VB 等等。
在情況越益嚴重無法遏抑其勢的今日, 只能期待點醒一些狂熱份子, 擁 X 反 Y 並沒
有什麼不對, 但是：
"一個人若是為有了宗教信仰而驕傲，自滿，甚至因
此鄙薄無信仰的人，或動輒排斥與他信仰稍稍不同
的人，便表示他自己還沒有找到信仰，所以，他也
在他自己鄙薄和排斥之列。"
<<疑神>>。楊牧
TANet 上一位大哥級的人物也曾語重心長地說：『科技的出現應該是要為人來服務的
，你盡可以擁抱 X 痛罵 Y ，不過切記知己知彼百戰百勝』, 這是看到網路論壇上一
堆連 protected mode, file system, scheduling 都不知何物的網友痛罵 Windows95,
連 API, OOP, framework 都摸不清脈絡的新手卻大聲疾呼推行或反對某某發開工具的
怪現狀所發的無奈之語吧！吾亦有同感。
對於"我想寫遊戲, 該用什麼語言 ?"這類常見也會永遠存在的問題, 我曾在網路上見
過這樣的回答：『Visual C++ 最適合了』、『VB 好學, 所以 OOXX』等等十分
no-sense, 說是不負責任也不為過的言論。不想流於空談, 我想還是來談談我自己的
看法好了, 就像人類戰士通常拿雙手巨劍, 侏儒通常肩著巨斧, 而魔法師無可選擇地
手執魔杖一樣, 選擇一把稱手武器還是得視個人的情況及需求來量身訂作：
一.學習動機
遊戲程式設計是程式設計各領域中, 狂熱及理想成分比例超高的一群, 甚至有許多各
種性質的程式設計師, 當初都是因為熱衷遊戲設計, 而就這樣持續掉入程式設計的漩
渦呢。學習動機是毫無疑問地: 想要具備撰寫遊戲的程式功力。不過, 就依遊戲種類
的不同, 日後學習的方向與重心也迥異, 例如 2D RPG, 重點在於畫面設計及故事劇情,
外加 DirectDraw 提供的快速捲軸能力; 3D 動作遊戲, Direct3D 或 OpenGL 是跑不
掉的, 對於圖學的理論, 演算法及應用面, 也最好花心思時間去努力研究學習; 再如
多人連線棋類遊戲, DirectDraw, Direct3D, DirectInput 我想都用不太上, 好好研
究提供連線功能的 DirectPlay 或發展一套穩固的 Client/Server Socket Library
才是重點。
二.目前基礎
目前基礎是決定工具及語言上手度的最重要因素。許多人在高中時代學了 QB, 之後便
接著玩 VB; 有些大學的大一計概課程教的是 Pascal, 接著便可順利進入 Delphi。
必須承認的是, Basic 確實不是開發大型程式適當的語言, 它的先天不良, 例如執行
速度慢, 不是物件導向語言卻硬加入類物件導向功能(事實上, 它只可算是
object-based, 而非 object-oriented), 甚至使得微軟為了 Visual Basic 一個語
言, 將 COM 規格做了些修改以配合之(如 IDispatch interface), 即使有微軟如此
強而有力的老大哥極力護盤, 先天缺陷仍舊無法去除, 除了易學外, 實在找不出太多
該使用VB的理由。VB 雖然可以使用 DirectX, 但還必須透過其它程式庫的幫忙, 因此
除了 VB, 我很贊成就配合你目前的所學, 會 Pascal 就用 Delphi, 愛用 C++ 就請
用 C++Builder 或者 Visual C++。
若原本是一張白紙, 還未學習過任何程式語言呢？那也好, 請見下段, 視你的個人偏
好囉。
三.個人偏好
Basic, C/C++, Object Pascal 這三個程式語言, 雄霸著整個 Win32 程式設計領域。
Basic 易學易用, Pascal 嚴謹明確, C++ 強大複雜, 各有各的擁護者及理由。
Basic 簡單是因為微軟希望 VB 及 VBA 維持在簡單到任何想依靠電腦來做自動化程序
的電腦用戶都可以輕易地上手的程度, 因此雖然功能不斷上疊, 語言本身維持著 Basic
的所有特性。不過缺乏物向導向的支援及執行速度的緩慢, 確是超級無敵讓人沒力的
致命傷, 因此我會建議所有的初學者, 若能有力能夠接受學習其它的語言如
C++/Pascal, 轉移陣地為上策。
C++ 的強大無庸致疑, template, exception-handling, RTTI, Stardard Library
等功能不斷地加入翻新, 由於使用者眾, 要求必多期望必高, 再加上 C++ 本身定位於
功能強大範圍廣泛的通用性語言, 如江海之納百川, C++ 自然日益複雜。著名的雜誌
C++ Journal 上曾有段話讓我印象頗深, "如果你認為 C++ 還不算太複雜, 那麼請你
解釋何謂 protected abstract virtual base pure virtual private destructor,
何你又會在何時需要它呢？"(Tom Cargill, C++ Journal, Fall 1990) 雖然是最流
行的 OOPL, 但除非你有足夠的耐心及精神來全盤掌握它, 否則輕易嘗試的後果可能只
會得到一臉的挫折。當然囉, 十分的複雜也帶來十分的便利及不同的樂趣, 我有一位
朋友, 工作上使用其它語言, 但將C++ 當作興趣來把玩, 跟酷企鵝一樣酷呆了。
Pascal, 其實應該說是 Object Pascal, 為 Borland Delphi 所採行的語言。Pascal
的嚴謹明確是自 Niklaus Wirth 發明它以來一直遵行的宗旨, 而之所以可以順利演化
為完全的物件導向程式語言 Object Pascal 是由於 Inprise 公司 (原名 Borland)
對 Pascal 語言的全盤掌握, 就像 FreeBSD 的 coreteam 全盤控制所有 FreeBSD
套件的更新撰寫一般, Pascal 控制權控制在 Inprise 一小措人手中, 雖失去開放性,
但保有該有的堅持及清新, 也因此我認為它的物向導向支援恰得其所, 該支援的全都
支援了但也沒有更多。它與 C++ 的優劣是沒有答案, 見人見智的, 正如同大禮服及
小洋裝, 好不好看, 適不適合, 因人而異。
※
RAD Tool 無罪論
最近網路上興起一道 "Visual C++ 與 C++Builder 孰優孰劣的討論", 其中可以看到
一些頗為中肯的言論：
發信人: Meou@m2.dj.net.tw (Dadai), 看板: programming
這兩個東西都蠻好用的. 但是現在我摸了幾個月之後, 我反而比較喜歡 VC++.
VC++ 的界面看起來繁瑣, 但是真的用心花個幾天把 VC++ 的功能摸熟, VC++
用起來還蠻順手的. 再加上把 VC++ 的 Application Wizard
的來龍去脈搞清楚, 把 ClassWizard 的用法弄懂, MFC 一點一點慢慢弄熟之後,
VC++ 的功能還蠻強大的. 加上 VC++ 的 HTML Help 比 BCB 好上百倍,
我現在覺得 VC++ 比較好用.
其實這兩個工具, 一個是倚天劍, 一個是屠龍刀, 放在不會用的人,
那一把都不順手. 這兩個工具都需要相當好的 C++ 基礎. 好的 C++ 基礎對
MFC, OWL, VCL 來說都是基本功而已. 學程式學了一陣子, 覺得 MFC
摸熟之後, construct 界面不比 BCB 來的慢,
重點在於界面之下你到底要如何解決問題. 這個問題比 Application
Framework 及那一套開發工具比較好來的重要多了.
====================================================================
發信人: dyliu@ms1.hinet.net (四眼的王蟲), 看板: programming
VC++ 的 help 系統的確比 Borland 的 Delphi, BCB 等好太多了,
Borland 在這一方面一直沒有甚麼進步, 有時候我用 Delphi 或
BCB 時還會執行 VC++ 就是要用 VC++ 的 help 系統, Borland
實在應該在這一方面大力改進才是.
界面方面 MFC 實在是比不上 VCL, 簡單的界面還好複雜一點的
MFC 就得搞上老半天.
====================================================================
發信人: oesd@email.gcn.net.tw (Dadai), 看板: programming
VC++/MFC 的 Learning Curve 看起來比較長, 但是值得.
因為你如果搞懂的話, 再配合上一些 SDK 的 knowledge 及合適的 development
kit, 你幾乎可以在 Windows 下做任何你想做的事
(剩下的只是你怎樣解決你要解決的問題). 我自己覺得 MFC 要用的有點基礎,
最起碼你要能把 VC++ Wizard 能做的東西知道如何全部用手工打造出來.
不然用 Application Wizard 建出來的東西, 你一樣看不懂,
更不要講如何去改它了.
其實像 BCB 這種 RAD Tool 要學的好, 我覺得比 MFC 還難.
因為在那漂亮界面下的底層機制往往比 MFC 複雜許多. 真的大聲喊 BCB
好簡單的, 我只看到兩種人. 一種是在 Win32 SDK 裡面打滾多年, 那幾千條
Win32 API 就算沒用過也都大概摸過, 沒摸過也知道大概會叫什麼名字,
該往那邊找. 問他一個問題, 腦袋裡面會自動列出一堆 Win32 API,
一條條過濾該如何解決. 寫 Windows 程式可能打字到手指頭都長肌腱炎了.
BCB 對他們是種解脫, VCL 更是不成問題.
而另一種則是完完全全的初學者. 用 BCB 來學 Windows Programming.
最多只能學到 Compnent 有提供的功能都會用, component 不會的他也不會.
component 不行的他也不行. component 的限制就是他的限制. AP 寫到一半,
中間要 call Raw WIN32 API, 他大概就掛了. 要做現有 component
做不到的功能? 那你要不要花錢買 VCL library?
====================================================================
同樣是 RAD Tool 的使用者, 有的是全然解脫, 輕巧駕御 RAD, 大部分卻屬於陣日搜
索元件, 侷限於別人製作的元件功能內的 RAD enabled-expert, 你願當哪種人 ?
以大局觀 Visual C++, C++Builder 及 Delphi 這三套工具, 就最重要的差異來列出
以下這張表：
Visual C++ C++Builder Delphi
設計公司 Microsoft Inprise Inprise
前端語言 C++ C++ Object Pascal
Application MFC VCL
Framework
介面設計方式 傳統 RAD
(Class Wizard 及 (拖拉點按)
手工打造)
程式核心 手工打造 手工打造
(有許多程式庫及 (有許多元件, 程式庫及類別可供運用)
類別可供運用)
運作原理 呼叫 Windows API 呼叫 Windows API
--------------------------------------------------------------------
呼叫由 kernel32.dll, user32.dll 及 gdi32.dll 三大模組為首所提供的數千個
Win32 API, 原本是 Win32 應用程式開發者唯一可用的方式, 這些 API 分成幾些
種類, 各擅其職, 只要利用它們, 少有做不到的事, 唯一的缺點是, API 多且繁雜,
而且如同 RISC CPU 的指令, 每一道 API 所做的事情並不多, 往往一些必須頻繁
撰寫的例行公事, 例如建立新視窗, 註冊視窗類別, 更改按鈕顏色等等動作, 還得
花上十幾行程式碼來做, 麻煩透了。需求乃創造之本, 於是程式庫出現了, 緊接著
挾著物向導件的優點類別庫也出現了, 最負盛名的兩套就是 Microsoft 的 MFC 及
Borland 的 OWL。慢慢地, 雖然有類別庫及 wizards, experts 的輔助, 仍有人不
知足地想要發展能夠更快地開發應用程式的方法, 於是就有了 Visual Basic 這類
可靠滑鼠完成大部分介面設計工作的 RAD 開發工具, 最後才是 Delphi及C++Builder。
隨著時間的腳步, 人們總要適應大環境的變遷及進化, RAD 的確為程式開發員省下
不少介面開發的時間, 但相對地來說, 它也降低了程式設計的門檻, 太多的初學者
沈溺於 RAD 元件的強大及使用, 不知有程式語言之重要, 無論底層的系統呼叫。
我想這也許是 RAD Tool 開始受到部分人們的質疑之故。
看透非 RAD Tool 及 RAD Tool, 抹穿 MFC 及 VCL 這兩套 application framework,
它們只是包裝一薄一厚, 用法各異罷了。MFC 薄薄的一片, 讓你擁有全盤掌握的滿足,
相對地, 學習曲線既陡峭且高峻, 需有足夠的背景知識才能充份融入 MFC, 享受它的
好處。VCL 包裝地並不徹底, 但厚厚地這一層, 讓人完全看不到骨子裏的究竟, 如同
寒流一來, 一個身穿五六件襯衫外加夾克兩條的女人打從你眼前走過, 天知道究竟是
蛇腰豐臀亦或骨瘦嶙離呢。就介面打造來說, VCL 包裝的真是好用方便, 不過常有
VCL 力有未殆, 包裝不足時, 此刻, 是 RAD 也好, 非 RAD 也好, 任何工具幫不上忙,
只有瞧自己琢磨 API 的功夫, 若沒有三兩下功夫, 馬腳隨著framework的不足就立即
露出了。
啥
這讓我想到幾年前曾發生的 "command line 優劣之爭", 有些高手們及UNIX fans
喜愛命令列, 一來速度快, 二來有全盤掌握的感覺; 而另一派當然是傾向 GUI 囉。
傳統確實有傳統獨到之處, 否則為什麼在電子音響大行其道的今日, 仍有玩家願意
傾幾十倍的價格, 把玩真空管音響呢 (我老爸就是一個:p) ? command line 用得熟,
操作速度比 GUI 還來得快上幾倍倒是真的, 我覺得這是 command line 需要存在的
最大理由。也有人對我說, "command line 較讓人懂得電腦真正的運作原理", 我告
訴他, "為什麼 GUI 就會妨礙到我們去瞭解電腦的運作原理呢 ?" 守舊也得要合理的
理由, 否則只是戀舊, 潛意識裏的觀感其實是怕跨入新的領域而失一向保有去優勢。
所以呢, 手工打造的好, 還是拖拉點放的方便 ? 手工打造的快, 還是拖拉點放的省
事 ? 我想是答案是很明顯的, 寧可在例行公事上能省時間就多省點時間精神, 我們
還有未來等著去創造呢, 焉可鎮日沈迷在手工打造全盤掌握之感覺中呢 ? 我想,
RAD Tool 無罪, 它只是讓門檻變了低, 讓程式設計變得簡單輕鬆, 何罪之有！
--
