（圖片來源：www.cnblogs.com）
原文出處：OpenGL 3 & DirectX 11: The War Is Over
現今在 DirectX 與 OpenGL 皆已相當普及的年代裡，我們似乎也逐漸淡忘了兩者從前的那段江湖恩怨。在著名硬體網站 Tom’s Hardware 的這篇專欄文章裡，作者帶領我們重新回顧這場「繪圖 API 戰爭」中的起伏轉折，以及 OpenGL 3 與 DirectX 11 的未來展望，是篇值得仔細閱讀的好文章。
「DirectX 最殺！很強很邪惡的微軟帝國萬歲！」
「想跨平台嗎？OpenGL 才是唯一的光明道路！」
「我是初學者，應該要選擇 DirectX 或 OpenGL？」
「我想做出一款超棒超好玩的遊戲，要用 DirectX 還是 OpenGL 比較好？」
身為遊戲程式設計者，如果你有定期瀏覽國外各大程式論壇的習慣，應該會對以上這些問題感到非常親切、熟悉，而且可能還會有些反感吧？在遊戲程式設計相關領域的討論區裡，最常見的萬年討論串非「DirectX 與 OpenGL 的比較」莫屬。DirectX 與 OpenGL 雙方各有死忠的支持者陣營，只要在網路上裡提出類似以上敘述的問題，往往會引來雙方擁護者激烈的對抗與辯論；如果又不小心觸動了某些資深程式設計者的「逆鱗」，就更加會戰到天荒地老無以復加。
在過去的短短幾年之內，我們親身經歷了消費性 3D 顯示卡市場的爆炸性成長。從以前只有硬派玩家會花大錢購買的「3D 加速卡」，到現在幾乎已成為標準配備的「3D 顯示卡」，電腦繪圖硬體不僅成功地打入了一般消費者的市場中，其性能也獲得革命性的突破，目前 GPU 的電晶體數量甚至已經超越了 CPU。時至今日，DirectX 與 OpenGL 在電腦繪圖與遊戲業界中的地位，究竟是處於分庭抗禮的情勢，或者已經分出了勝負？且讓我細說從頭。
繼續閱讀 << "《OpenGL 3 & DirectX 11: The War Is Over》：繪圖 API 終戰之日？"
接續前篇文章的簡短介紹，本文將開始使用 VSTO 與 Lua 語言實作 DHL 系統。首先，定義 DHL 系統的開發環境以及執行環境：
Database Hot Loader 系統
- 程式開發環境：Visual Studio 2005 Team Suite
- 使用者執行環境：Office 2003
為了使 Office 2003 達成轉換資料格式的任務，必須仰賴 VSTO 所提供的擴充功能。Visual Studio Tools for Office （簡稱為 VSTO）的作用，簡單來說就是讓程式設計者能夠在 Office 應用程式中，使用 .NET 撰寫附加的擴充元件，使一般的文件檔案，也能夠具備客製化的特殊功能。另外，微軟 .NET 平台的優勢，就是能夠使用 .NET 家族中的任何一種語言來撰寫程式，在此我選擇 C# 做為開發 DHL 系統的語言。
只要使用 VSTO，幾乎就能夠達成一切 Winform 可以做到的事情。在活頁簿上放個按鈕元件？沒問題；另外產生一個全新的 Winform？小意思；在 Excel 的主選單上增加自訂項目？一片蛋糕。總是覺得 Office 應用程式某些地方用得不夠順手嗎？有了 VSTO 以後，就可以幫助我們達成自己動手撰寫擴充功能的願望。
在前篇文章中，曾特別提到需要使用 Visual Studio 2005 的 Team Suite 版本，原因在於 DHL 系統必須使用 VSTO 的「文件層級」(document-level) 擴充程式，而在 Visual Studio 的眾多版本中，只有 Team Suite 版本能夠開發文件層級的擴充程式，一般程式設計者常用的 Professional 版本則只能夠開發 VSTO 的「應用程式層級」(application-level) 擴充程式。關於文件層級與應用程式層級的介紹，請參考「Visual Studio Tools for Office 」中文線上文件裡的詳細說明。
繼續閱讀 << "Database Hot Loader 二部曲：Using VSTO and Lua"
說來有些慚愧，一直以 C++ 語言做為謀生工具的我，在使用了多年的 C++ 程式語言之後，最近終於與聞名遐邇的開源專案 Boost C++ Libraries（簡稱為 Boost）進行了第一次的親密接觸。在本文裡，將參照 Boost 官網的「Getting Started on Windows」文章，於 Windows 作業系統以及 Visual Studio 2005 程式編譯器的環境下，詳細介紹安裝及建置 Boost 的步驟，並且在最後使用 Boost.Thread 函式庫做為測試範例。
從前就常聽到其他人談論著 Boost 的優點，但是只要知道其中由上千個標頭檔以及數十個函式庫所組成，而且還需要以繁複的步驟手動建立函式庫的 .lib 檔案，很容易就會使初學者望而卻步。對於用慣了程式整合開發環境以及現成函式庫的我來說，Boost 簡直就像是一座美麗動人但又戒備森嚴的堡壘般令人不敢輕易接近。多年以後的現在，總算是鼓起了勇氣重新面對 Boost。花了些時間閱讀文件，然後按照指示一步步完成安裝建置之後，發現原來這些步驟比起從前已經簡化許多，函式庫的使用也不如想像中的困難！
One of the reasons for boost’s success has been the cross-pollination of ideas between diverse library projects.
Boost 是由一群功能獨立的函式庫所組合而成的集合體，其中涵蓋了許多熱門而經常使用的函式庫，以及比較冷門的特殊功能作用函式庫。所有的函式庫都包含在名為 boost 的 namespace 中，不僅能夠使各函式庫維持一致的使用風格，同時也得以避免命名衝突的問題。如官網中的 FAQ 所述，Boost 的成功正是由於不同功能函式庫之間的「交叉授粉」(cross-pollination) 作用所致；雖然其中多數函式庫都能夠分開獨立使用，但正是由於函式庫之間相互支援的功能以及介面，才使得 Boost 的開發者社群與使用者社群能夠蓬勃發展且欣欣向榮。
繼續閱讀 << "登泰山而小天下：Boost C++ Libraries 初體驗"
在美國的憲政體制中，《權利法案》(Bill of Rights) 的制訂是一項相當重要的里程碑，不只保障了身為美國公民的基本權利，更進一步使人們能夠享有充足的言論自由與媒體出版自由。換個角度，如果站在「遊戲玩家」的立場來看，我們是否也應該擁有關於遊戲軟體產品的基本權利以及保障？
在今年八月底時，獨立遊戲開發公司 Stardock 的執行長 Brad Wardell 提出了一份「玩家權利法案」(The Gamer’s Bill of Rights)，洋洋灑灑總共列出十項遊戲玩家應享有的基本權利；此舉動不僅震驚了整個遊戲業界，也隨即在國外各大網站的玩家社群中引起廣大的迴響與討論。
（圖片來源：www.aeropause.com）
玩家權利法案：
- 玩家有權利退回無法在他們電腦上執行的遊戲，並且獲得全額退費。
- 玩家有權利要求遊戲必須以完成狀態上市。
- 玩家有權利期望在遊戲上市之後，獲得有意義的更新內容。
- 玩家有權利要求不需強制執行遊戲的下載管理員與更新器，才能夠進入遊戲。
- 玩家有權利期望遊戲能夠在最低需求配備的電腦上充分地運行遊戲。
- 玩家有權利期望遊戲不會安裝隱藏的驅動程式，或其他可能潛在有害的軟體。
- 玩家有權利能夠在任何時間重新下載任何一款他們所擁有的遊戲的最新版本。
- 玩家有權利不被遊戲開發者或發行商視為潛在的犯罪者。
- 玩家有權利要求遊戲的單人模式，不強迫他們在每次進行遊戲前都必須連結網際網路。
- 玩家有權利要求遊戲可以完整安裝於硬碟，不需要遊戲的光碟片才能夠執行遊戲。
請以遊戲玩家的身份，仔細地閱讀以上「玩家權利法案」中的條文敘述：你的直覺反應是搖頭不以為然，或者猛然點頭稱是？
繼續閱讀 << "電腦遊戲市場的善與惡：玩家權利法案 VS. 數位著作權管理"
「我有一個夢想，期望有天我們能夠免於調校遊戲資料數據的苦痛。」馬丁路德博士的夢想，是人人生而平等並且免於種族歧視的迫害。而我的夢想，沒有這麼崇高偉大，只是希望能夠幫助團隊成員改善遊戲的開發流程。
每次當我看到遊戲企畫者，為了調整遊戲中的各種數據，而必須不斷重複一連串繁瑣而且漫長的操作程序，就替他們感到很辛苦。為了測試資料數據的正確性，首先要在 Microsoft Office Excel 上輸入資料內容，存檔後匯出，接著以外部工具將文字檔轉換為遊戲自訂的檔案格式，把檔案置入遊戲目錄中，最後再開啟遊戲，等待遊戲程式以及遊戲資料載入完成，然後檢視執行的結果。
「咦，食人怪的偵察範圍太遠，而火球魔法的距離太近了些。」於是按下離開遊戲的快速鍵，然後在 Excel 表格中修改相對應的數據後，再次存檔匯出，再次以外部工具轉換為遊戲自訂的檔案格式，再次把檔案置入遊戲目錄中，然後再次開啟遊戲，再次等待遊戲程式與遊戲資料載入完成。
（圖片來源：www.play-gadgets.com）
除非企畫設計者擁有強大的靈動感知能力，能夠精準地預測出合適的遊戲數值，否則總是需要不斷地嘗試錯誤並且經歷許多修改程序，才能夠將遊戲數據調校到完美平衡的狀態。不停地、不停地、不停地重開遊戲，幾乎是每位遊戲企畫設計者都曾經歷過的處境。在遊戲專案開發初期時，可能還感受不到特別的困擾之處；然而當專案到了後期階段，遊戲中的美術素材動輒佔有成千上百 MB 的份量，所以每次開啟遊戲都必須要等待漫長的遊戲初始化載入時間，甚至只是修改單一一個欄位的數據，同樣難以免於遊戲重開的等待過程。
有沒有可能改善這種狀況，減少重新開啟遊戲程式的頻率？有沒有可能在不需要重新啟動遊戲程式的情況下，讓企畫設計者能夠即時調整遊戲的資料庫數據？
繼續閱讀 << "Database Hot Loader 首部曲：Introduction"
原文出處：The Code/Art Divide: How Technical Artists Bridge The Gap
當遊戲專案的規模日益龐大，團隊成員的數目也越來越多的情況之下，伴隨而來的就是更為精細的分工模式與更加複雜的製作程序。精細的分工合作模式，使美術設計者、企畫設計者與程式設計者都能夠專注在自己最擅長的領域中，但同時也無可避免地加深了不同領域之間的距離與鴻溝。而為了解決美術設計者與程式設計者之間的鴻溝，本文將介紹在遊戲開發團隊中的一個相當特別的職位：Technical Artist，技術美術設計者，簡稱為 TA。
（圖片來源：www.primotechnology.com）
何謂「技術美術設計者」？這個角色所具備的專業能力為何？TA 究竟屬於美術設計者還是程式設計者？如果以英文的字意來解釋，Technical Artist 所指的是「技術的美術者」，也就是懂得程式技術的美術設計者。在遊戲開發團隊中，TA 的作用就像是一座橋樑，職責在於連結起美術設計領域與程式設計領域之間的萬丈鴻溝。
以 3D 遊戲的開發流程來說，美術設計者在 3ds Max 或 Maya 軟體中所創造的各種遊戲素材 (Game Asset)，包含模型、動畫與其他物件，並不是只要在製作完成之後按下「儲存檔案」的按鈕後就算是大功告成。事實上，在絕大多數的情況下，由這些套裝軟體所產生的原生檔案格式如 .max 與 .3ds 等等，都無法直接在遊戲程式的系統中使用。
繼續閱讀 << "《The Code/Art Divide: How Technical Artists Bridge The Gap》：技術美術設計者，為您搭起團隊的橋樑"
在物件導向生成設計模式的範疇中，除了之前曾經介紹過的 Facory Method 以及 Abstract Factory 兩項工廠類型的模式以外，本文將繼續介紹另一項在遊戲程式領域中，經常受到廣泛使用的 Prototype 設計模式。
Prototype，原意為原型或雛形，與工廠模式接收到使用者命令之後即時生產物件的方式不同，在 Prototype 模式中，我們需要先打造出物件的原型樣版，待鑄模程序完成以後，接下來就能夠輕易地以此原型複製產生出全新的物件。複製，也可以是一種生成物件的方法。如 UML 圖所示，在 Prototype 設計模式中，定義了三個參與角色：
- Prototype：宣告自我複製的介面。
- ConcretePrototype：具體實作出自我複製的操作。
- Client：叫原型個體自我複製一份，以生出新的物件。
按照上述的責任關係，程式系統的使用者 Client 只需要指涉到基礎的 Prototype 介面，就能夠以此 Prototype 介面所宣告的 Clone() 方法，複製出類別的物件成品；而 ConcretePrototype 們衍生自 Prototype 介面，是 Client 進行 Operation() 方法後將會獲得的實際成品，所以必須一肩扛起實作 Clone() 內容細節的重責大任。
繼續閱讀 << "Prototype：物件原型複製者"
1980 年前後出生的我們，誕生在一個荒誕而奇異的年代。
1980 往前，是經歷過經濟起飛時期的父母長輩；1980 向後，是成長於物質與資訊不虞匱乏時期的年輕後輩。1980 是民國 69 年，正好處於六年級生後段班與七年級生前段班交界點的位置。屬於 1980 年代這一掛的我們，現在還不是社會上的中堅份子，但也不是媒體形塑出來的爛草莓族。我們所站的位置，似乎有那麼一點特別。
在上一代長輩的眼裡，我們被視為過度早熟的孩子，不論是知識、資訊或者自我意識，所有的事物都接觸得太早也來得太快；事實上，我們都是晚熟的大孩子。大學的錄取率逐年攀高，新鮮人的起薪停滯不前，工作機會越來越少，在畢業幾乎等同於失業的狀況下，不論是有意或者意料之外的延畢，再加上就讀研究所的時間，都拉長了校園生活的時期，也延後了正式踏入社會上班工作的年齡。由於比較晚踏入社會的緣故，所以在心理狀態上，自然呈現出與實際年齡不成正比的晚熟程度。
（圖片來源：www.postershop.com）
繼續閱讀 << "1980，我們的寂寞星球與孤獨世代"
原文出處：Flagship Founder Bill Roper Interview
2003 年，冬天，旗艦工作室 (Flagship Studios) 於萬眾矚目之下創立起始；2007 年，秋天，旗艦工作室的第一個遊戲作品《地獄之門：倫敦毀滅》正式於歐美地區發行上市；2008 年，夏天，旗艦工作室大量資遣公司員工，旋即於同年七月宣告沈沒覆滅。
五年，人生有幾個五年可以揮霍？
（圖片來源：www.tech2.com）
Bill Roper，身為旗艦工作室的首席執行長以及共同創始人，也是 Blizzard 公司三大名作《魔獸爭霸》、《暗黑破壞神》以及《星海爭霸》的遊戲製作人 (Producer)，如果讀者清楚瞭解他的資歷，曾經玩過、看過或者聽過他所參與開發的遊戲作品，應該很難不對於旗艦工作室的黯然落幕感到震驚：像他這樣成功經驗豐富的遊戲開發者，怎麼可能會失敗！？
還記得五年前，那個 2003 年的夏天，當我正在軍營裡折騰翻滾的時候，Blizzard North 分部的三位創始人以及副總裁 Bill Roper 宣布集體離開如日中天的 Blizzard 公司，不僅在玩家社群中掀起巨大的波瀾，也大大地震撼了整個遊戲業界。於是，開始有人說 Blizzard 公司快要完蛋了，有玩家說《暗黑破壞神》不會再有續作了。經過將近四年的開發時程後，背負著無數玩家的熱切期望，在許多狂熱者眼中引頸期盼，能夠繼承《暗黑破壞神》系列作精神的《地獄之門：倫敦毀滅》終於在 2007 年 10 月 31 日上市。
但是很遺憾地，這款嘔心瀝血的遊戲大作，在大多數的遊戲評論者與玩家之中，都無法獲得良好的回應及評價。
繼續閱讀 << "《Flagship Founder Bill Roper Interview》：地獄之門崩壞，旗艦之夢沈沒"
在專案管理領域中，所謂的時程，也就是一般常聽到的 Schedule 一詞。當上司、主管或者指導教授交付給你一項工作時，需要知道這項任務的預估完成時間。我們身為遊戲開發者以及工作執行者的身份，應該要使用什麼方法來預估工作的時程？如何達到預估的準確性？工作時程中又隱含著些什麼樣的秘密呢？
經過前篇文章「遊戲開發入門：專案管理管什麼？」的介紹之後，相信即使是從未接觸過專案管理領域的讀者，也能夠對於專案管理的基本概念有一些基礎的概念與認識。接下來，本篇將深入時程的層面，探討在專案管理中相當重要的專案時程估算議題。
（圖片來源：www.codinghorror.com）
任何一項工作的時程安排，都需要具備三項條件：起始日期、結束日期以及與其他工作的依存關係。在專案管理領域以及專案時程表中，最受到廣泛使用的甘特圖 (Gantt Chart)，可以用清楚易懂的圖示來描述工作項目的這三項條件。而另外一項在專案時程中會經常聽到的術語是 Work Breakdown Structure（工作分解結構），或經常簡稱為 WBS。簡單來說，WBS 近似於前篇文章裡所提到的「工作項目階層分解程序」，能夠將原來非常龐大的功能項目，逐步往下分解為可處理的單一工作項目。
在遊戲開發流程中，為什麼我們需要制訂出專案時程表？
繼續閱讀 << "遊戲開發入門：專案時程怎麼估？"
Loading ...