[程式][隨筆] 遊戲程式設計初學者常遇之疑問

看板GameDesign (遊戲設計)作者DreamYeh (天使)時間18年前 (2006/05/03 21:34)推噓2(2推 0噓 0→)

留言2則, 2人參與討論串1/1

板主心得：這一篇其實很有歷史了，不過裡面所闡述的內容，對於　　　　　任何時期的遊戲製作者來說都是個重要學習內容！　　　　　面對遊戲製作這個高深的學問，初心者往往最容易、最　　　　　想問的就是：「有沒有什麼捷徑？」、「有沒有什麼程　　　　　式語言最適合寫遊戲。」　　　　　我想這一篇就是最適合的解答。原文開始－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ ※ 原文刊登於遊戲設計大師1999年四月號只是隨筆 -- 遊戲程式設計初學者常遇之疑問作者: 陳寬達 EMail: kuan@vclxx.com 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), 即使有微軟如此強而有力的老大哥極力護盤, 先天缺陷仍舊無法去除, 除了易學外, 實在找不出太多若原本是一張白紙, 還未學習過任何程式語言呢？那也好, 請見下段, 視你的個人偏好囉。三.個人偏好 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, 轉移陣地為上策。 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++ 的優劣是沒有答案, 見人見智的, 正如同大禮服及小洋裝, 好不好看, 適不適合, 因人而異。　　　　　 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.105.58.3