不知道各位如何規劃遊戲專案的目錄結構？各位所使用的是專案管理體系的正規方法，或者只是隨意地將檔案與資料夾散佈在電腦中的各處？在一個遊戲專案的開發過程裡，重要的資產除了程式碼檔案之外，還包括了設計文件、美術素材、音效檔案，以及最終的執行檔等等。該如何妥善管理這些不同類別的項目，以達到良好的成效？在此將以我個人目前使用的方法，提出一套目錄結構的規劃架構，與各位一同進行交流討論。
有些人喜歡將許多各式各樣不同用途的資料夾，直接放置在電腦的「桌面」上，最後經常會使得整個桌布，幾乎被各種不同圖示與資料夾所淹沒。這樣的作法，在一時的使用上或許非常方便，但是如果沒有善加整理歸檔，未來很容易會找不到想尋找的目標文件或檔案。不論是公司的正式專案，或是自己在工作之餘開發的個人專案，都能夠從良好的目錄結構規劃中，得到易於管理與變動的益處。
首先，我習慣在電腦硬碟的作業系統槽（通常是 C 槽）之外，選擇一個空間足夠的磁碟槽，在根目錄下開啟幾個資料夾進行專案的管理：
- Codespace：專案區，只存放由 CVS 或 SVN 等版本控制系統取出的各項專案。
- Workspace：工作區，存放各項測試中的程式、待完成的工作項目，以及各種經常需要查閱使用的文件及資源。
- Temp：暫存區，存放各種暫時物件，包括從網路上下載的安裝檔，以及檔案解壓縮後的資料夾等等。
專案區中的資料，應該經常與版本控制系統保持同步化，盡可能減少修改後的版本存在於自己電腦中的時間。即使個人的工作硬碟不幸遭遇毀損的狀況，也能夠由版本控制系統的伺服器中，重新取回整個專案的資料。而工作區，則用來存放各項試驗中的專案；例如在剛開始接觸 Boost.Pool 函式庫時，我就會在工作區裡開設一個測試資料夾命名為 TestBoostPool 進行各項測試，等到成果達到一定程度後，再將專案提交至版本控制系統以及專案區中存放。最後，在暫存區中的資料，則只是便利暫時性的使用，可以隨時將全部的內容清空刪除。
繼續閱讀 < < "遊戲專案的目錄結構規劃"
猴子靈藥
滿一週年了。
從 2008 年 1 月 5 日發佈的「關於」頁面，與 1 月 6 日的第一篇文章「始動！」開始，至今日為止，總共寫了 87 篇文章，有 481 則迴響留言（另外還有 801 則 Spam，囧），以及 365 則靈藥筆記。
轉眼間，一年了。從剛起步的第一篇、第二篇到第十篇文章之後，在鍵盤上敲打文字，逐漸成為我生活中的一項重要習慣。自電腦與網路世代降臨後，「寫」這個動作，不再僅限於使用紙與筆，我們現在能夠利用電腦、網路、硬碟與鍵盤，輸入並且儲存自己各種想法心得，而這項全新的寫作型態，也帶來了許多不同於以往的分享與交流方式。
在這段寫作的過程中，我很幸運地認識了許多網路上的朋友，例如 lsk、yag、Trombe、R2D2、兔子安、獸王、Milo、藍斯洛、gino、doomleika、Percy、Wallace、COdE fr3@K 等等族繁不及備載。即使彼此之間並沒有見過面，但我們同樣能夠從共同關注的事物與知識中獲得交流與學習的樂趣。不論你是學生、遊戲人或是路人，不論是業界同行或者非同行，不論人在台灣或是國外，我都很高興能和各位相聚於此。
在猴子靈藥裡，我所遵行的準則是：每一則迴響我都會回覆。我喜歡收到各種回應，更喜歡與各位討論，因為我相信，很多時候，好靈感與好想法就是必須經過互動、激盪或者挑戰，才能夠產生出耀眼的火花。將來，除非留言數一下子暴增到四、五十則以上難以負荷的程度（看起來應該不太可能），否則我仍然會遵循著這樣的模式，對每一篇迴響，都會用心閱讀思考之後再加以回覆。
繼續閱讀 < < "猴子靈藥一歲啦！"
（圖片來源：handheldwii.wordpress.com）
原文出處：Opinion: How Mega Man 9 Resembles… Real Life?
如果你和我一樣，自純真的孩提時代開始接觸任天堂的紅白機遊樂器，一步步走入電玩遊戲的這條不歸路。那麼，在你的童年記憶裡，必然有一個小小的角落為這位英雄人物所佔據。這位由 Capcom 公司所創造出來的人物，現在被稱為「Mega Man」，但我們對他更熟悉的稱呼是「Rockman」，或者是「洛克人」。
在 2008 年裡，遊戲業界中的許多開發商紛紛推出各款遊戲強作，而其中最特殊，也是立即能夠吸引老玩家目光的遊戲作品，莫過於由 Capcom 公司所製作發行的《Mega Man 9》。《洛克人9》，是《洛克人》系列的正統續作，一款遊戲能夠自 1987 年第一代的作品問世開始，歷經二十個年頭流傳至今，推出多達九款續作，必然有其不可動搖的地位。然而，這次 Capcom 卻做了件讓所有洛克人的玩家粉絲跌破眼鏡之事。
在這款與前作《洛克人8》相距足足有 12 年之久所推出的續作裡，遊戲設計與遊戲技術全部以反璞歸真的形式呈現。在遊戲中，沒有幾可亂真的的 3D 模型，沒有精巧炫麗的畫面特效，遊戲開發者選擇回到洛克人最初的根源與起點，以最純樸簡單的像素風格，為今日的玩家呈現這款全新的遊戲作品。而遊戲軟體本身，也僅在 WiiWare 遊戲下載服務平台上提供販售。
為何 Capcom 敢於做出如此大膽的嘗試？開發者是不是只為了隨便做個續作來交差了事？在遊戲英雄角色後浪推前浪的趨勢中，洛克人是否已經黯然失寵？除了遊戲設計層面的考量之外，本文作者從《洛克人9》的遊戲過程中，領略到與現今遊戲全然不同的娛樂體驗與成長心態，甚至能夠實踐於我們的真實生活之中。讓我們隨著作者的遊戲體驗，一起乘時光機回到過去，滲透隱藏在單調圖像背後的設計決定，學習那些洛克人教我們的事情。
繼續閱讀 < < "《How Mega Man 9 Resembles… Real Life?》：那些洛克人教我們的事"
（圖片來源：asymptotia.com）
原文出處：Nine Paths To Indie Game Greatness
本文的作者，是一位曾製作過 PC、Console 以及 Mobile 平台遊戲的專業開發者。自從他以《Quake》內附的編輯器，製作出第一個遊戲關卡的那一刻起，他就領略到了創造遊戲的那種無上樂趣，也因此下定決心開始學習如何製作遊戲。然而當他在遊戲業界中，經歷了六年的工作生涯後，反而開始質疑自己是否擁有繼續開發遊戲的渴望。就在他決心離開遊戲業界，去嘗試其他的事物之後，反倒從如新生嫩芽般的獨立遊戲社群中，再次重新找回自己對於創造遊戲的熱情。
在經歷過許多已經關門倒閉的遊戲公司以後，他充分地瞭解，開發商業遊戲需要非常廣泛的作用力與各種面向的考量，耗費於其中的時間，甚至遠超過投注於實際遊戲開發程序的時間。越瞭解這項事實，他就越加覺得自己已經游離了當初那個使他感到興奮雀躍的遊戲開發根源。他不禁懷疑，世界上是否有任何地方，能夠以他剛起步時的那種精神來創造遊戲。藉由這個捫心自問的問題，他發現了正迅速成長中的「獨立遊戲」。
所謂的「商業遊戲開發者」與「獨立遊戲開發者」，實際上的不同之處為何？當一間商業公司啟動一項新專案的時候，他們經常會問的問題是：「誰會給我們所需的資源來支付薪資與帳單？」如果這間公司夠幸運的話，他們可以問：「誰會給我們所需的資源來製作我們想做的遊戲？」而當獨立開發者啟動新的專案時，他們經常會自問的問題則是：「如何以現成可用的資源，製作出我所想要的遊戲？」這就是兩者間最大的不同之處。
在 1982 年時，由 Namco 公司所生產製作的《Pac-Man》，只需要 10 萬美金的開發費用；現今，開發一款 PS3 平台的遊戲，平均花費估計約為 1500 萬美金左右。即使經過通貨膨脹的調整之後，遊戲作品的開發費用仍然呈現出相當大的躍升幅度。而當近年的遊戲開發預算，已然呈現出數以倍計的增長局面之後，銷售量與收益仍然很難產生相對的具體變化。為了抵抗如此情勢，有些缺少開發流程經驗的獨立開發者，會盲目而不加思考地貿然前進，但是那些最成功的獨立開發者們，則能夠善用現存的資源大展身手。
開發遊戲這件事，最令人神魂顛倒之處，莫過於創造這些互動世界的能力，僅侷限於我們所能夠想像以及我們的技術能力所及之處；只要擁有想像力與技術力，你就能夠創造出一個充滿歡笑與樂趣的夢想國度。在這篇文章裡，作者提出九項非常實際有效的訣竅，並且引用了相當多成功的遊戲案例交互印證，帶領各位讀者進一步踏入獨立遊戲開發領域的康莊大道。
繼續閱讀 < < "《Nine Paths To Indie Game Greatness》：獨立遊戲開發者的獨孤九訣"
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"
Loading ...