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"
說來有些慚愧，一直以 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"
Loading ...