World of Goo
遊戲名稱：World of Goo
遊戲開發公司：2D Boy
遊戲發行平台：Windows、Mac、Linux 與 WiiWare
「它，到底是一款什麼樣的遊戲？」
它是一款以物理系統為基礎的解謎與建築遊戲；它是一款畫面簡單且風格特殊的遊戲；它是一款只需要使用滑鼠單鍵操作的遊戲；它是一款榮獲 IGF 設計創新獎項與技術精湛獎項的遊戲作品；它也是一款獲得無數玩家及媒體讚譽的獨立製作遊戲。
「它，到底是何方神聖？為何能夠讓每位玩過的玩家讚不絕口？」
它啟蒙於《Tower of Goo》，一款在七天之內製作完成的遊戲原型；它誕生於 2D Boy，一間剛成立屆滿二周年的獨立遊戲開發公司；它的成就，則來自於 Kyle Gabler 與 Ron Carmel 二位遊戲開發者，投注二年時間所孕育出來的美麗成果。
起初誰也沒料想到，這些看似毫不起眼又黑不拉嘰的「咕球」(Goo Balls) 們，竟然能夠獲得玩家們的廣大迴響與深厚喜愛，甚至還發揮了小兵立大功的威力，一舉攻下 Wii 平台遊戲排行榜中的超高評價。「揪～竟在這些咕球的背後，隱藏著些什麼樣不為人知的秘辛？」半路眉頭一皺，發覺事情並不如想像中那麼簡單。
請各位暫時放下手邊的工作，和我一同進入咕球的世界一探究竟吧～
警告：內文充滿大量咕球元素，如果您尚未玩過遊戲並且破關，閱讀本文可能會破壞您的遊戲樂趣或者解謎成就感，敬請小心服用本帖靈藥。甘溫蛤～
繼續閱讀 < < "《World of Goo》：歡迎來到「咕」世界！"
從剛進入遊戲業界開始，我就一直對於「記憶體配置」(Memory Allocation) 的系統架構與相關議題很感興趣。後來隨著閱讀書籍量的增加與工作經驗上的累積，逐漸接觸到各種不同設計架構與實作方法的記憶體管理機制，現在終於能夠將一些初步的心得整理出來了。
在遊戲程式設計的領域中，程式設計者經常需要即時且動態地產生出大量的小型物件，例如怪物、特效、場景物乃至於低階的節點物件等等。如果遊戲程式設計者只是天真爛漫地使用著單純無害的 operator new 以及 operator delete 程序，在經過遊戲執行中不斷反覆地配置與歸還記憶體的行為之後，很快就會使得完整的記憶體區段面臨嚴重的「記憶體破碎」(Memory Fragmentation) 問題。更糟的是，記憶體破碎的問題往往很難被偵測出來，而容易被開發者所忽略。
為了盡可能降低記憶體破碎的狀況，並且得到高效的物件配置程序，除了從高階層面利用資源管理 (Resource Management) 機制減少遊戲物件的生成與毀滅行為之外，同時也需要從比較低階的層面，也就是屬於記憶體配置的功能面向著手改善。在使用者每次進行 operator new 操作向作業系統索取記憶體空間時，C 語言的函式庫除了配置所要求的區塊大小以外，還會另外生成一小塊額外的區塊以簿記相關的資訊。對於經常進行生成與毀滅程序的小型物件來說，這樣的行為模式就顯得十分浪費而不具效率。如果能夠一次性的配置出一大塊記憶體，然後再依使用者的需求傳回部分區塊，可望就能夠改善 operator new 程序所產生的額外負擔。
為了能夠妥善管理一大塊的記憶體空間，程式設計者發展出了「Free List」這個用來處理動態配置記憶體的特殊資料結構。Free List 通常是以鏈結串列 (Linked List) 做為基底結構，將目前可使用以及使用中的記憶體空間紀錄並且連結起來。一般常聽到的「記憶體池」(Memory Pool) 或者「池式配置」(Pooled Allocation)，就是利用 Free List 資料結構實作出來的記憶體管理機制，也是遊戲程式設計者不可不知的記憶體系統管理技巧。而應該如何實作出高效能的 Free List 結構，使創建物件與刪除物件時的負擔減至最小，更是池式配置記憶體機制中最關鍵的要點。
繼續閱讀 < < "記憶體配置：Pooled Allocation技術評比與效能測試"
（圖片來源：www.refreshaustin.org）
原文出處：How to Prototype a Game in Under 7 Days: Tips and Tricks from 4 Grad Students Who Made Over 50 Games in 1 Semester
本文是於 2005 年時發表的文章，雖然距今已有三年以上的歷史，但絕對無損這篇文章的價值。同時，本文也與極具創意的優秀獨立遊戲作品《World of Goo》，有非常深的淵源以及關連性存在。
Kyle Gabler、Kyle Gray、Matt Kucic 與 Shalin Shodhan 是四位就讀於卡內基美隆大學 (Carnegie Mellon University) 研究所的學生。在 1 個學期的時間內，他們僅僅憑藉著 4 個人的力量，完成了超過 50 個遊戲的原型 (Prototype)！同時他們也設置了一個名為 Experimental Gameplay Project 的網站發表他們所製作的各款遊戲原型；其中最受歡迎的遊戲之一，就是由 Kyle Gabler 所製作的《Tower of Goo》，而這個遊戲原型也正是《World of Goo》的前身作品！
為了達到 1 個學期之內完成 50 款遊戲原型作品這項近似於不可理喻且不可思議的目標，他們將自己鎖在房間內，遵循著以下三項規則進行開發工作：
- 每個遊戲必須在 7 天以內完成。
- 每個遊戲必須從頭到尾以 1 人之力完成。
- 每個遊戲必須立基於一般常見的主題，例如「重力」、「植物」或「群聚生物」等等。
7 天，1 人，以及 1 個主題，製作成為一個遊戲原型作品。許多人好奇他們是如何在這麼短的時間內完成一款遊戲原型作品？又是如何能夠維持上述規則與紀律，長達一整個學期之久？在此，四位作者共同將這段過程中所學習到的各種寶貴知識，包括正確以及不可行的嘗試經驗沈澱整理之後，分為準備、設計、開發以及遊戲性四個項目，一一闡述如下：
繼續閱讀 < < "《How to Prototype a Game in Under 7 Days》：如何在七天內完成遊戲原型"
Bejeweled 2 Deluxe（圖片來源：www.aioforum.com）
原文出處：The State of the Casual Games Industry in 2008
若要追溯 PC 平台上的休閒遊戲起源，其實一開始只是附屬於 Windows 作業系統內，譬如《接龍》、《踩地雷》、《彈珠台》以及《傷心小棧》等等簡單的小遊戲。然而誰也沒有料想到，時序移轉至 2008 年的現在，休閒遊戲竟已迅速成長至不容忽視的市場規模，掀起一波反璞歸真的「遊戲文藝復興運動」。經過數年來的演化，休閒遊戲早已由初始的牌卡與方塊消除類型遊戲，發展出全然不同的嶄新面貌；休閒遊戲，不再只是家庭主婦或者上班族用來殺時間的小玩意兒，而是已經在主流遊戲市場之外開拓出了自己的一片疆土，搖身一變成為極具發展潛力的新興產業。
根據休閒遊戲協會 (Casual Games Association) 去年的一份報告統計，至 2007 為止，休閒遊戲產業的年產值，已經達到了 22 億 5 千萬美元的驚人規模，同時正以每年 20% 的成長速度不斷向上攀升。若以性別區分玩家的族群分佈，其中男性玩家佔了 48.3%，而女性玩家則佔有 51.7% 的比例；更值得注意的是，在付費玩家的比例中，女性玩家則涵蓋了 74% 的壓倒性比例。另外，目前在全世界最受歡迎的休閒遊戲為《Solitaire》、《Tetris》、《Bejeweled》、《QQ Games》集合、《Diner Dash》系列以及《Mystery Case Files》系列。
為了進一步探討這個急遽成長中的產業，在這篇文章裡找來了 PlayFirst 的 John Welch、PopCap 的 Jason Kapalka 以及 Reflexive Arcade 的 Russell Carroll，三位具有豐富經驗的遊戲開發者進行討論，對休閒遊戲產業的現況與未來發展提出了有力且深入的見解。
繼續閱讀 < < "《The State of the Casual Games Industry in 2008》：休閒遊戲產業的發展現況與未來展望"
（圖片來源：www.graffiti.org）
幾個月以前，曾在「遊戲產業新門派（一）：Casual Game」一文中討論過遊戲產業中的門派分支「休閒遊戲」(Casual Game)；在這篇一直想下筆但拖稿很久的續集裡，將繼續向各位介紹遊戲產業中另外一支極具份量的獨特門派——Indie Game。
首先必須瞭解的是，究竟何謂「Indie」？
Indie games are video games that are created independently of the financial backing of a large video game publisher.
Indie 一詞，源自於 Independent 的簡寫，所以 Indie Game 所指的也就是「獨立遊戲」的意思。在遊戲業界中，「獨立開發者」 (Indie Developers) 的定義，正是指不依賴外部發行者的財務援助，自行研發遊戲的創作者。而除了遊戲領域中的獨立遊戲以外，音樂業界的獨立音樂 (Indie Music) 以及電影產業的獨立電影 (Indie Movie)，都是歷史更為悠久的獨立創作形式。
各位讀者或許略有所聞，在歐美的遊戲產業中，財力資源最為雄厚的公司往往不是遊戲開發商，而是遊戲發行商。大多數的遊戲開發商，為了能夠開發以百萬美金預算為最低門檻的遊戲專案，必須先尋求遊戲發行商的資金挹注以及發行合約，才能夠在長達 18 至 30 個月左右，完全沒有任何收入進帳的開發時期裡，付給員工們足夠的薪資以及各項相關的研發費用。
「既然如此，遊戲開發者為什麼要獨立？有人願意捧著大把鈔票請你製作遊戲耶！」
繼續閱讀 < < "遊戲產業新門派（二）：Indie Game"
歷經了漫長的 DHL 系統一二三部曲後，終於來到了這一系列文章的最終曲。
本篇的重點在於對 DHL 系統進行效能的優化以及量測。首先，對於 LuaDatabaseManager 類別提出幾項效能優化的可能性。以資料庫系統的作用來說，一般使用者會期望在索取資料的程序中，得到最佳化的執行效能，才不會因為對於資料庫的頻繁讀取而拖累了遊戲系統的整體效能表現。在二部曲中曾經提過，為了取得資料庫中的數值，使用者需要利用 LuaDatabaseManager 類別中的 GetData() 函式：
void LuaDatabaseManager::GetData(std::string& sheetName, std::string& fieldName, unsigned int id, std::string& value)
{
int oldTop = lua_gettop(m_DBState);
lua_getglobal(m_DBState, sheetName.c_str());
lua_pushstring(m_DBState, fieldName.c_str());
lua_gettable(m_DBState, LUA_GETTABLE_INDEX);
lua_pushnumber(m_DBState, id);
lua_gettable(m_DBState, LUA_GETTABLE_INDEX);
value = luaL_checkstring(m_DBState, lua_gettop(m_DBState));
lua_settop(m_DBState, oldTop);
}
在 GetData() 函式中，必須進行三次取出 table 結構的步驟；首先以 lua_getglobal() 函式取得最上層的 table，然後傳入欄位名稱以 lua_gettable() 函式取得第二層 table，最後再傳入資料 ID 以 lua_gettable() 函式以取得使用者要求的資料值。
熟悉 Lua 語言的讀者應該很清楚，除了使用 lua_gettable() 函式取得 table 結構中的數值以外，還有另外一項替代方案：使用 lua_rawget() 函式。預設情形下，在 lua_gettable() 函式中，會喚起 table 的 metamethod，而對於將 table 單純當成陣列結構處理的資料表格來說，其實並不需要這層額外的彈性，所以如果使用 lua_rawget() 函式取代原來的 lua_gettable() 函式，理論上應該能夠獲得某種程度的效能提升。
繼續閱讀 < < "Database Hot Loader 最終曲：Tuning and Measuring Performance"
（圖片來源：brianlawler.smugmug.com）
原文出處：Good Middleware
之前在「遊戲引擎的層級架構」以及「商業或自製，引擎大不同！」兩篇文章裡，曾經討論過遊戲引擎的基本概念以及商業引擎與自製引擎的不同之處；而在這篇文章裡，第三人稱射擊遊戲《Fracture》的開發者 Kyle Wilson，對於遊戲開發領域的 Middleware（中介軟體）提出了幾項有力的觀點，非常值得做為使用與選擇遊戲開發中介軟體的參考指南。
身為遊戲軟體的設計者與創造者，為什麼我們需要仰賴別人製作出來的某些東西？為什麼我們要花錢購買所謂的中介軟體？主要來說，中介軟體能夠提供兩大益處，同時也具有相對應的代價。
首先，相較於自己撰寫的程式碼，中介軟體能夠以更少的花費提供給使用者更多的程式碼。因為中介軟體的開發商能夠將研發費用平均分攤在大量的授權客戶上，所以比一般的遊戲開發公司，更能夠維持龐大且具深厚經驗的團隊，專注在特定領域的功能項目之中。然而此項利益的相對代價，在於沒有任何中介軟體的功能，能夠百分百符合遊戲專案的所有需求；中介軟體是寫來支援最常見的使用案例，因此如果開發者擁有不同於一般標準的特別需求，最好還是自行實作這些特殊的功能。
另一項使用中介軟體的益處，是能夠為「你應該擔心的事」與「你無須擔心的事」畫出一條清楚的界線。只要中介軟體具備良好的文件以及穩定的系統，你就不需要浪費心思憂慮那些隱藏在公開介面之下的東西。當遊戲的複雜度增長到了某種程度以上時，如果中介軟體能夠協助開發者劃清各項功能系統的責任界線，將是一項相當具有價值的恩惠。而相對的代價，則是你不能夠去改變界線另一端的東西；如果決定要使用中介軟體，就必須願意接受某種程度上的缺乏靈活性，也必須願意將原本所使用的技術調適到合於中介軟體的程度，否則花錢購買中介軟體將會演變成為一場災難。
繼續閱讀 < < "《Good Middleware》：如何選擇遊戲開發的中介軟體"
Observer Entity
在前篇文章裡，以 VSTO 與 Lua 實作了 DHL 系統中資料匯出、讀取以及管理的核心功能後，本文將以一個簡單的 3D 程式範例，介紹如何將 DHL 系統與遊戲物件相互結合，以實現真正能夠使用於遊戲專案中的預定目標。
藉由之前建立完成的 LuaDatabaseManager 類別，已經能夠幫助我們動態修改並且載入 Lua 格式的資料庫表格，但是該如何使遊戲中的物件對資料庫的變化產生自動化反應呢？只要利用設計模式中的 Observer 模式，就能夠使我們順利達成目標。
如圖所示，在範例程式中，以 OpenGL 繪製出一個基本的三角形物件以及一個矩形物件，同時在視窗裡不停地旋轉；而視窗程式的建立，則使用 GLUT 函式庫以簡化相關的程序。
首先，在程式碼中創建出 Triangle 與 Quad 類別，分別用來代表畫面中的三角形與矩形物件。而這兩個物件的頂點、顏色、位移、旋轉軸與旋轉速度數值，則由 Excel 工作表中的資料數據進行設定。在範例程式的 Excel 檔案中，共有以下三張工作表：
在 triangle 表格裡的 vertex1、vertex2、vertex3、color1、color2 與 color3 欄位，分別定義了三角形物件的三個頂點及顏色的資料，而最末的 translate 與 rotate 欄位則用來定義三角形物件的位移量與旋轉軸；quad 表格以此類推。在 speed 表格中，只有 triangle 與 quad 兩個欄位，分別定義了這兩個物件的旋轉速度。
繼續閱讀 < < "Database Hot Loader 三部曲：Implementing Observer Entity"
（圖片來源：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"
Loading ...