Show Me Demo
讓我們把焦點轉回遊戲程設
核心工作上:也就是 Graphics API — DirectGraphics 與 OpenGL 學習上
無論是學習何種 API
開始免不了都是需要熟記很多很多函式名稱、呼叫方式、傳入參數等等繁複東西然後還需要把整個繪圖 API 程式設計流程架構從頭到尾徹底瞭解；在學習 API 時很重要件事就是要用心去研究繪圖 API 設計者想法盡可能掌握住這個繪圖 API 「設計思維」以其思維模式來學習如果能夠掌握住了這個重點則我相信不管是在學習繪圖 API 理論或甚至是記憶函式名稱等等都會變成是很自然而然容易理解記得試著多問自己「why」與「why not」『學習
應該是種主動性研究而非僅止於被動性知識填充而已』當你確定自己已經建立起正確
觀念與思維模式時就該開始來寫寫小程式囉對於初學者來說從無到有往往是最難跨出步；如果想自己從零開始行行撰寫程式碼可能到最後才發現辛苦結果全部變成不解程式 bug如果覺得自己可能還沒辦法獨立完整完成個程式那麼比較好思路方法就是:先參考別人程式碼無論是 DXG 或 OGL在各種書籍與網站中都有為數不少範例程式存在藉由 trace 個範例完整程式碼可以因此而學到很好程式寫作方式如果已經把整個範例程式碼都瞭解差不多了或者還有疑惑不明白的處可以試著改變程式中些變數或函式呼叫看看程式結果會有什麼變化這也是種很不錯學習方式 『學習 Graphics API 最重要
是什麼？熟記函式和參數？搞懂整個理論架構？』都不是
最重要是:動手做如果所謂學習只是腦袋裡記了大堆不知所以然東西而很少真正動腦去想、動手去做那麼所有切可以說都是白費功夫沒有實際踏實程式寫作經驗幾個月後記憶裡只會剩下堆不連續殘片碎影罷了很多寫程式時要注意小地方或小窍门技巧我們稱的為 tip 或 trick；般書籍或網站多只提供概略性教學對於實做上細節些小窍门技巧就需要自己親身經歷過才能真正體會到簡而言的就像是種經驗值累積囉；現在很辛苦練等級到了真正要面臨大陣仗、大魔王時候才不會臨場怯陣、紕漏百出如果對整個 API 已經有了相當程度
瞭解加上時間經驗累積的後就可以開始動腦想些有趣點子來做囉有 3角形、有燈光、有材質可以做些什麼？讓燈光顏色隨著時間變化如何？還是改變材質座標讓物體外表有變化？還有透明度也可以做很多變化！工具在你手上創意在你腦中；魔法人人會變巧妙卻各有区别的前經歷過這麼長學習曲線路篳路藍縷、披荊斬棘到了這裡終於是可以自由揮灑時候了快把自己腦中存積已久所有點子都壓榨出來吧！ : )『嗯？有什麼地方不對勁嗎？』
隨著自己寫
小程式數目直累積下來或許你已經發覺到件事實:「其實根本不用每次都從零到有行行程式碼撰寫對吧？」沒錯般來說都會存在有部份程式碼是重複、不變；例如:視窗程式
化、繪圖 API 定會做化的類動作那應該怎麼做比較好？需要時候再從的前程式 “copy-paste”？不這絕對是既沒有效率又存有風險思路方法什麼是最好做法？最好做法就是把每次都會重複使用程式碼寫成個骨幹架構 (framework)所謂骨幹架構部分通常是個程式中變異性很小程式碼；例如視窗程式繁複化動作動輒數百行程式碼以上但卻有很大固定性所以就非常適合寫成骨幹架構如果我們把骨幹部分程式碼獨立在個 source file 中而把真正相關繪圖部分程式碼抽離出來到另個 source file 中；把所有不相關閒雜人等寫成個 source file 次解決從此不需要再煩惱那些不相關東西只要我們把主要繪圖部分程式碼撰寫完成後再和以前就寫好骨幹程式做編譯連結就可以讓專案 (project) 整體架構看起來更清楚易懂也大幅增加了專案結構性『除了最基本
framework 的外還覺得需要什麼嗎？』沒錯
你需要自己圖書館 (library)什麼是 library？讓我舉個例子來說明:如果你所學習 API 是 OpenGL你可能會發現不管是 BMP、TGA 或 JPG 等等所有圖檔格式都需要自己撰寫程式碼來讀取OK那就寫吧The same as old你會發現到無論所需讀取是哪種格式圖檔我們目都是很相近類似:就是做為多邊型材質 (texture)那我們何不以 C＋＋ 物件導向模式寫出個專門處理相關 texture 大大小小事務類別呢？把讀取每種圖檔 function 寫在 texture 
成員函式中並且樣把它獨立成個 source file；如此來只要每當需要處理 texture 相關程式時就把已經寫好 texture source file 和我們專案做編譯連結夠簡單又結構化看起來很棒吧？同理可證
除了處理 texture 類別外還有文字輸出呢？計時器控制呢？鍵盤滑鼠操縱？………別忘了還有最基本矩陣和向量！把所有你能想到基本功能都寫成個個獨立 source file只在需要時候才和它編譯連結；如此不但程式碼易於維護除錯未來擴展性也相對寬廣許多！而這個個 source file 集合起來就是所謂 library 囉就像是自己家裡有座圖書館樣架上擺著分類齊全、功能眾多各種書本可以依照自己需求而選取区别書本來運\用；而不是把幾萬行程式全都濃縮在本書 (source file) 中時日久如果生了臭蟲恐怕連原作者都不認識書內容了！『所以
在寫小程式賺取經驗值同時最重要工作就是要開始建立起自己 library』其實不管是在網路或書籍範例中
都可以看到很多別人寫 library；有些 library 甚至還具備了很強大功能但是我並不建議在自己程式中使用別人 library有什麼壞處？以學習者立場來看使用別人 library 所能學到知識遠遜於自己辛苦寫出來參考別人 library 寫法或許是個不錯主意但是要記得:自己 library自己應該要看得懂才行否則別說是擴充功能了就連善加利用可能也沒辦法做到在寫 library 過程中就可以看出的前學習成果如何了；如果程式語言、資料結構基礎沒有學好現在肯定會是最痛苦刻在撰寫自己 library 的時也未必要次就寫出功能非常齊全物件類別；如果使用物件導向設計模式來撰寫 library就可以利用其可擴充彈性在有需要時候才寫新出功能並加入相對應成員函式；如此又可減輕了設計負擔Hardcore Stuff
經過漫長
旅程寫過幾個小 demo擁有些自己 library 的後應該可以感受到點遊戲程設樂趣與魅力了吧？但是這樣知識可能還是不足以達到設計你心目中理想遊戲能力對吧？基本知識有了繪圖 API 熟了接下來呢？讓我們更進步來看看比較深入遊戲程設世界『Ok, let’s talk something seriously.』
我想
只要是對於遊戲設計稍有興趣人在玩款遊戲時候多少都會問自己:「這個遊戲是怎麼做？」是如果你是路踏實努力走來學習者你現在更應該認真研究這些問題除了以玩家身份體驗款遊戲樂趣的外更要以設計者角度來看這款遊戲在此網路上許多網站就扮演了很重要學習媒介角色相信你在學習過程中偶爾都會聽過些奇怪名詞術語像是:BSP、Portal、Octree、LOD、Lightmap、Ray tracing ………等等這些就是遊戲設計相關技術名詞你知道這些技術和遊戲程式有什麼關連性嗎？你好奇這些技術如何應用在遊戲程設中嗎？在此你英文能力 (或翻譯軟體 :p) 就十分重要了『你想知道
切網路上都找到答案』網路資源
利用可以說是學習過程中非常重要並且不可或缺環以國外 3大遊戲設計網站 Gamasutra、Flipcode 和 Gamedev 來比較:Gamasutra 通常會提供相當深入、內容充實研究主題包含了遊戲程設、美術甚至音樂與企畫管理非常適合想對某特定主題深入探討人；此外Gamasutra 也是 Game Developer 這本著名遊戲設計雜誌相關網站Flipcode也會不定期有教學文章更新主題多數都蠻具實用性；並且 Flipcode Image Of The Day 區域提供大家個展示程式地方在此往往可以看到不少有意思作品絕對是這個網站不可不看部分Gamedev 相較於另外兩者在業界新聞及教學文章更新速度都比較快並且文章數量很多、分類詳細不過其所提供教學文章多以概論為主少有比較深入探討『到此為止
才算是真正開始逐步踏入遊戲程設殿堂時候』只要稍微瀏覽過國外遊戲設計網站
話應該不難發現其中文章數目及種類實在太多太多了其實對個初學者而言這個樣子反而不見得是件好事可能會不知從何開始學習文章裡充斥著大堆看不懂專業術語甚至可能搞不清楚自己想要學習什麼萬事起頭難剛開始或許整篇文章從頭到尾仔細閱讀了兩次還是只懂得其中兩 3成內容；這個時候就需要踏實投注時間與精力點點滴滴累積知識廣度文章看得多了程式寫得勤了漸漸就可以瞭解 7、 8成以上內容囉每篇文章所講主題就像是個個「點」如何找出點與點的間「關係」將這個個「點」連成「線」進而化成個知識「面」也是學習中值得研究件事除了每個網站
教學文章的外附屬於網站的下討論區也是個非常重要資源試著用英文表達你誠\懇、發出你問題即使文法不是百分百正確、即使找不到合適詞彙表達你意思你會發現總是有許多熱心人很樂意幫助你在國外討論區回答問題人往往都很願意幫助別人解答疑惑就算是自己不熟悉問題也會提出自己經驗和想法甚至連程式碼展示也毫不吝嗇；所以只要你問問題夠好 (我相信唯有好問題才能導引出好答案)往往可以得到遠超過你所想像豐富收穫、學到很多有用知識在發問前也可以先搜尋看看該討論區有沒有類似討論或許你問題早已有人問過了記得不要再問「DirectX and OpenGL, which _disibledevent=>」這種問題囉！ : )『網路
資訊是學習新知技術最好條途徑那如果想對基礎原理有更深認識呢？』別無 2法
就是書本書本可以說是學習知識最紮實 (也或許是最痛苦 :p) 途徑其實真正學習最好最好思路方法就是找到個好老師加上本好書不管任何知識如果有了好老師授業解惑絕對有事半功倍的效；很可惜是位稱職好老師真很難找特別是在遊戲程設這個怪領域中所以靠人靠天最後還是靠自己最實在；書本就是閉關練功武林密笈、不 2法門或許你會懷疑已經學會了程式語言、視窗程式、繪圖 API為什麼還要看書？書裡寫不都是堆無聊理論加上複雜數學式嗎？正如在的前文章所提到瞭解理論並不見得會帶來什麼立即效益也不定能增強寫程式功力；但是書本知識能夠幫助你更確實掌握住事物本質基礎與思維模式特別是在日趨複雜遊戲程式設計中如果沒有深厚穩固理論基礎所建構起法則做為地基恐怕難以負擔起越來越龐大複雜遊戲程式架構還是那句老話:「想創造規則
人必先瞭解規則」每本好書都是前人以無可計數時間經驗所得來心血結晶集英薈萃的後以文字形式傳諸於世讓所有有心學習知識人都能因此受惠從書本中我們可以輕易學到前人知識經驗與心血結晶；原來可能自己要花費數年時間才能領悟道理現在只需要從閱讀書本中知識就能輕易習得以 3D 電腦圖學來說瞭解其背後許多理論基礎更能幫助你更快學習並吸收新知識例如在瞭解了 Phong reflection model 定義的後就可以很容易理解為什麼光源組成要分成 ambient、d
fuse 及 specular 3個成分了；如果瞭解 3D 電腦圖學發展歷史就不難理解為什麼目前 3D 繪圖主流方式還是以 polygonal mesh 為主了；諸如此類太多太多例子可以舉理論知識這東西不會是你時飯碗；卻會是你輩子財富Build Up Toolbox
熟悉了
些遊戲核心技術的後就可以開始建立自己工具箱了何謂工具箱？般常見講法就是「編輯器」(editor)編輯器大致上有兩種用途:是做為程式測試工具 2是做為遊戲開發編輯工具以第種用途來說例如你想用的前文章提過質點系統 (Particle 
) 來做個施放魔法時特效場面要怎麼要才能知道所寫出來程式碼有沒有符合需求呢？這個時候就可以寫個質點系統編輯器工具把所有可以調整變數全部列在編輯器面版中可能會包括質點大小、位置、顏色、速度及運\動法則等等要素然後就可以在編輯器面版上直接調整變數值即時觀察質點系統變化情形如何使用這種思路方法就能夠很便利以各種区别數據測試程式結果而不是每次都要在程式碼中更改數據後再重新編譯連結整個程式更大好處就是可以讓不懂程式碼人也能直覺性調整並控制程式呈現結果所以建立編輯器的後就算是複雜交叉數據測試也會變得容易、而且直覺許多編輯器
第 2種用途呢？舉個例子來說Quake 3 Arena 中宛如藝術品般驚為天人美麗場景是如何製作？如果你對遊戲設計核心技術已經具備有基本概念就應該能夠瞭解它場景不可能是由幾位程式設計者個個物件撰寫程式碼而完成整個複雜場景那應該是用什麼樣方式來建立複雜遊戲場景呢？就是依靠所謂編輯器般來講個完整 3D 場景就稱做個 level而編輯場景用就叫做關卡或場景編輯器 (level/map editor)通常編輯器是由程式設計者將所有可能會使用到功能先設計完全並做出個易於操作使用者介面；如此來就可以讓專門負責場景設計者 (level designer) 來完成所有關卡與場景只要編輯器功能夠強大齊全甚至不用懂得任何程式碼也可以設計出非常棒場景；而這正是編輯器真正威力編輯器
真正目應該是化繁為簡能力最理想狀態應該要做到不需要任何說明文件與教學任何稍具遊戲設計概念人都可以輕易上手才是編輯器產生也使得遊戲開發分工變得更合理可行；只要程式將人物對話編輯器寫好的後就可以交給企畫負責編撰人物文案；如果程式開發出夠強場景編輯器就可以讓美術來負責整個場景建模與成形了所以編輯器往往是遊戲製作過程中相當重要個部分如果說個遊戲開發時間有百分的 5十投注在設計開發編輯器過程上也不為過！『我知道你在想什麼
』到了這裡
又要再次面臨類似問題:Borland C
Builder 與 MS Visual C到底要選擇何者做為開發工具用編譯器？我答案還是樣平凡:兩者都學了再說在的前文章提過要寫出比較進階視窗程式可以用 Win32 SDK、Borland VCL 或是 Microsoft MFC其實編輯器就是屬於種進階視窗程式設計因為它會包含很多複合性元素如繪圖 API 呈現、對話盒、控制面版與檔案儲存載入等等在各大程式設計討論區BCB 與 MSVC 批評比較絕對不亞於 OpenGL 與 DirectX 情形如果用另種方式來比喻話BCB 就像是家裡萬能老媽樣會幫你把所有想做事情都打理很好；只要用「拖拉點放」方式就可以完成大部分視窗元件設計而 MSVC 就像是精打細算老婆樣所有要完成事情都要跟她報備照著規矩項項來做；雖然有些便利設計精靈可以應用可是大部分還是要用「手工打造」方式循序漸進來完成而兩者
缺點呢？BCB 常被人所詬病就是其不佳程式編譯效率及執行效能；而 MSVC 則是 MFC 學習曲線太長龐大複雜 MFC 結構往往使初學者望的卻步我建議還是相同不管別人說法如何還是只有自己親身用過的後才能體會其優劣勝敗的處兩者都學習的後或許才會發現在別人眼裡是優點地方自己不以為然；而在別人眼裡是缺點地方自己卻不以為意不論是 BCB 或 MSVC都只是種工具為了達成某些目而被造出來工具；所以能因地制宜選擇合適工具看何者用比較順手就使用何者或許才是比較好方式On The Way
『什麼？你是認真
嗎？這麼無聊 3篇文章你都能看到這裡了喔真服了你耶』『嗯？你說你前面
所有學習步驟都完成了接下來呢？』『不
如果你會有這個疑問表示你還沒到達這裡』『………………………』
『好吧
好吧如果你真好奇話讓我們再來稍微談談的後路』其實很容易
至此有幾個簡單選擇；是對自己有興趣主題繼續深入研究往深度發展； 2是再尋找其他沒學習過主題往廣度發展；第 3還有別嗎？就是寫 GAME！跟我唸次G‧A‧M‧EGAME！別忘了我們路從這漫長艱辛路程走來為是什麼目現在你終於可以大聲說:我有能力寫出個遊戲了！開始激發你創意爆發你潛能構思設計個 GAME 吧！ : )最後再提
件事情或許你也會常常聽到某某遊戲用了什麼「3D 引擎」的類嗯？你說這系列文章怎麼從來沒有談過有關 3D 引擎主題？咳咳請記得這篇文章主題是「淺\談遊戲程式設計入門」不是什麼「如何在 30 天內做好個 3D 引擎」、「快快樂樂學做 3D 引擎」或「如何在 30 歲前擁有人生第個 3D 引擎」的類OK？……………好啦講認真3D 引擎真是非常複雜東西絕非像這樣 3兩篇文章可以解決也不是我目前能力可以分享其實像的前所提到編輯器工具可以說就是 3D 引擎個重要核心；不過 3D 引擎同時還必須整合美術及音樂部分將切製作遊戲所需元素都考慮進去才能算得上是個完整、真正「3D 遊戲引擎」不過我建議是就算你已經學習至此還是先不要想太多 3D 引擎東西；繼續充實自己累積寫程式經驗利用自己現有知識與技術做出個有趣小遊戲吧！向慣於以文字表達我到了這裡還是不禁要懷疑:這些辛苦敲打出來文字究竟能不能適當地表達我心裡真正想說話呢？真正能瞭解我想表達意思人有多少呢？而真正能努力做到並且達成目標人又有多少呢？…………………好吧我承認我想太多了 (其實是已經不知道要說什麼了 ~_~)總而言的基本上這系列文章重點差不多已經告個段落在接下來最後篇文章中我會以自己親身學習經驗為例和大家做個分享還請大家多多指教
最新评论