猴子靈藥 [Monkey Potion]

本文要提出的內容，是一個非常基礎的程式觀念：表頭檔 (Header Files) 與編譯依存關係的課題。雖然對於許多程式設計者來說，這個觀念技巧應該是相當基本而且必備的基礎知識，但在現實世界中，我卻時常看到許多人忽略了這個問題的重要性，因而造成專案開發流程中的重大災難。

來看看實際的範例。例如在專案中有一個 GameObject 類別，用來實作遊戲物件的相關操作行為：

// @ GameObject.h
#include < string >

class GameObject
{
public:
    int GetType();
    std::string& GetName();

private:
    int m_iType;
    std::string m_kName;
};

有了基礎的遊戲物件類別之後，自然會陸續建構並且實作出其他的類別。當 GameObject 需要使用或包含其他的類別時，可能會在類別中定義一個該類別的成員變數，以結合 GameObject 類別進行更複雜的操作行為。例如，可能會在 GameObject 類別中，加入一個 ComponentA 類別的物件定義遊戲物件的基本組件：

// @ GameObject.h
#include < string >
#include "ComponentA.h"

class GameObject
{
public:
    int GetType();
    std::string& GetName();
    ComponentA& GetComponentA();

private:
    int m_iType;
    std::string m_kName;
    ComponentA m_kCompA;
};

繼續閱讀 << "表頭檔要不要？拿速度來換！"

原文出處：Statistically Speaking, It’s Probably a Good Game, Part 2: Statistics for Game Designers

承續前篇文章「遊戲設計者的基礎機率入門」，本文是原著系列作中的第二篇，將介紹「統計」理論的基礎概念，以及統計在遊戲設計中的應用實例。

科學理論中的統計學，應用在許多不同的層面都十分有用；但相對地，統計學也很容易被誤用而產生出誤謬的結果。統計學就像是一種暗黑的科學，身為勇者的你，如果不能善加利用這個強大的力量而被魔戒誘惑，根據錯誤的推論做出重大決策，往往會導致糟糕而悲慘的結局。

統計學是與「資料」高度相關的一種理論。蒐集資料的方式，包括常見的路邊攔人問卷調查、電話詐騙訪談調查、焦點群組測試程序，以及偷偷紀錄不告訴你等等許多不同的方法可用，而重要的是，如何將蒐集而來的資料加以分析詮釋，得出對於遊戲設計者有用的知識以及資訊。與前篇文章相同，作者在文章開頭就先提出了三個有趣的小問題，在繼續往下閱讀之前，不妨先思考看看：

• 謎題一：20 位焦點測試者剛測試完你所開發的蝸牛賽車遊戲，根據蒐集所得的資料顯示，跑完整個賽道的最佳成績是 1 分 24 秒，而最差成績是 2 分 32 秒。如果你原先設定的遊戲設計目標時間是 2 分鐘左右，那麼這是一次成功的測試程序嗎？如果你蒐集了更多的資料，計算出這些資料的平均值是 2 分 5 秒，而標準差是 45，這樣的結果可以讓你滿意嗎？
• 謎題二：你設計了一個休閒遊戲，目前正在 Beta 測試的階段，總共找來了 100 位的測試者完成超過 1000 次的遊戲測試程序。將蒐集回來的資料計算之後，顯示出分數的平均值是 52000 分，而標準差是 500 分，這樣的結果是不是已經通過檢驗，可以準備出貨上市了呢？
• 謎題三：你設計了一個 RPG，然後從中蒐集資料觀察玩家從等級 1 晉升到等級 5 共需花費多少時間，其中共有 4.6 小時，3.9 小時，5.6 小時，0.2 小時，5.5 小時，4.4 小時，4.2 小時，與 5.3 小時這幾筆資料。你是不是能夠直接將這些資料拿來計算平均值與標準差？

繼續閱讀 << "《Statistically Speaking, It’s Probably a Good Game, Part 2》：遊戲設計者的基礎統計入門"

本篇文章將承續前篇「Factory Method：工廠化的物件生產方法」，介紹經常與 Factory Method 模式搭配使用的 Abstract Factory 設計模式，以及 Abstract Factory 模式於遊戲程式中的應用實例。

在複雜的軟體系統架構中，將原來雜亂無章的組件加以分門別類，然後從中取出性質相似與功能相近的物件，使其集中群聚，就能夠大幅地簡化程式系統組件的複雜度。而 Abstract Factory 模式，正是用來協助程式設計者將物件分門別類與集中管理的好方法。

Abstract Factory 的「工廠」，與 Factory Method 的「工廠」目的相同，同樣屬於「生成模式」的分類，都是用來產生出物件成品的製造者。對於設計模式的入門者來說，很容易將 Factory Method 模式與 Abstract Factory 模式兩者的使用目的以及使用時機搞混；雖然都是屬於工廠類型的作業模式，然而 Abstract Factory 與 Factory Method 的不同之處在於，抽象工廠模式是將一組性質相關或相依的物件，放在同一個工廠裡生產。例如對於食品工廠來說，能夠生產的包含飲料、零食與泡麵三項食品類的產品；而皮件工廠，則能夠生產出皮包、皮帶與皮鞋等皮製產品。也就是在一個工廠之內有數個不同的生產線，能夠同時進行不同成品的生產作業。在實際程式系統的應用中，可以說 Abstract Factory 經常是一堆 Factory Method 的組合。

繼續閱讀 << "Abstract Factory：物件家族的抽象工廠"

2008 年的 Google Summer of Code 活動正如火如荼地展開當中。

所謂的 Google Summer of Code (GSoC) 是由 Google 提供贊助經費，推動在學學生進行「開源專案」(Open Source Projects) 開發工作的活動計畫。這項計畫自 2005 年起每年舉辦，今年已經是 Google 第四度舉辦這樣兼具實質意義與精神意義的活動。

開源專案的發展，一直在全世界的軟體產業中佔有相當重要的地位。而在遊戲業界中，則以 John Carmack 的 Quake 系列作品，做為原始碼開放精神的首選典範。如果沒有了這些專案開發者與貢獻者的無私奉獻，現在的我們就不會有免費的 Lua、Wordpress、MySQL、PHP 與 OGRE 以及許許多多功能強大的軟體系統可用。

根據 GSoC 2008 FAQ 中開宗明義所闡述，發起這項活動計畫有下列五項目的：

• 使更多的開源專案能夠被創造出來。
• 鼓勵年輕的開發者，開始參與開源專案的開發。
• 幫助開源專案找到並且帶來新的開發者與貢獻者。
• 提供資訊科系的學生，一個在相關領域工作的機會（而不是去做漢堡）。
• 給學生更多接觸真實軟體開發情境的機會。

繼續閱讀 << "Google Summer of Code：貢獻，收穫，然後成長。"

原文出處：Statistically Speaking, It’s Probably a Good Game, Part 1: Probability for Game Designers

本文作者是一位遊戲設計者，在這一系列的三篇文章中，他以生動有趣的角度介紹了「機率」與「統計」兩項數學理論的基礎概念，以及兩者在遊戲中的相關應用。本篇是系列作的第一篇，解釋了機率的部分，而後的第二篇介紹統計的部分，最後一篇則是以一個 Board Game 的實例，解釋機率與統計於遊戲設計中的實際應用。我個人覺得這一系列文章非常棒，點出了很多遊戲數值設計層面的迷思與問題點，相當值得遊戲企畫者，或未來有志於從事遊戲數值企畫的讀者詳加閱讀。

許多人只要一聽到有關於「數學」的詞彙或術語，可能就會倒吸一口涼氣，然後想辦法敬而遠之。「機率」與「統計」，應該也曾經出現在大部分讀者的求學過程中，而且經常是屬於不怎麼受歡迎的兩個傢伙。但不論過去你和它們相處得好不好，和它們的關係像陌生人還是好朋友一樣，如果能夠善加利用機率與統計的知識，將能夠使許多遊戲設計的功能與機制更加完備而有趣。

文章開頭，作者就先提出了三個有趣的動腦小問題。在往下繼續閱讀之前，不妨先試著思考看看這些問題的答案：

• 謎題一：你正在設計一個 MMO 遊戲，其中某隻怪物有 10% 的機率會在死掉之後掉落寶物。但是有位測試者告訴你，他殺了 20 隻這種怪物後，共拿到 4 次掉落的寶物；而另一位測試者，則回報在解決 20 隻怪物後，卻沒有拿到任何的掉落寶物。這是程式碼的臭蟲嗎？你應該殺去程式部門震怒拍桌子了嗎？
• 謎題二：你要在戰鬥系統中加入「致命傷害」的要素，假設玩家的基礎攻擊命中率是 75%，只要成功擊中了對手，系統就會再做一次機率判定，如果成功通過機率運算，傷害數值就會乘以 2 倍；然後再繼續做機率判定，如果再度成功的話，傷害值就變成原來的 3 倍；以此類推下去，不斷地往上加乘。在這樣的系統設定之下，玩家的每次攻擊，至少能夠造成 2 倍傷害的機率是多少？玩家能夠造成 4 倍或 4 倍以上傷害輸出的機率是多少？
• 謎題三：你決定在遊戲中加入一個賭博的小遊戲，讓玩家能夠下注丟擲硬幣後的正面或反面兩種結果。然而，在這個小遊戲中必須包含一個歷史紀錄，就像是賭場中的下注系統一樣，在螢幕上會顯示出最近 20 筆的遊戲結果。做為這個小遊戲的設計者，你是否應該要求程式設計者在其中加入某些特殊的運算邏輯，以防止玩家利用這些歷史紀錄的資料，贏錢贏到使你的遊戲經濟系統崩潰？

繼續閱讀 << "《Statistically Speaking, It’s Probably a Good Game, Part 1》：遊戲設計者的基礎機率入門"

本篇文章將介紹在軟體設計模式 (Design Patterns) 中相當著名而且受到廣泛使用的 Factory Method 模式，以及 Factory Method 在遊戲程式設計難題中的實際應用。

想要熟悉 Factory Method 設計模式，首先要瞭解下列幾項問題：

• 這個設計模式的目的是什麼？
• 這個設計模式能夠用來解決什麼樣的問題？
• 這個設計模式要如何應用在遊戲程式之中？

或許對於程式設計者來說，十個人之中有九個半討厭聽到「工廠」或「工廠化管理」的相關術語，但是在軟體設計模式的領域中，工廠化的生產作業方式反而是相當實際而且管用的方法。Factory Method 是軟體領域中，非常基礎同時也非常重要的設計模式之一，或許你從來沒有在書本中學習過相關的知識，但是已經在撰寫程式的經驗過程中，處處使用著這樣的設計方法而不自知。如果能夠進一步瞭解這些前人思維架構的心血結晶，將有助於改善現有的程式架構，並且提升未來撰寫程式系統架構的能力。

繼續閱讀 << "Factory Method：工廠化的物件生產方法"

再次在機緣巧合之下，向好心人借到了一台 PSP 與 Patapon 這個創新有趣的遊戲，結果就是讓我這幾天一直沈浸在這些大眼 Pon 與啪打啪打的節奏聲中。Patapon 結合了音樂節奏與即時戰略的新穎玩法，再加上極具獨特性的美術風格以及豐富活潑的音效，使這個遊戲呈現出很強的吸引力以及感染力。

不過如果要挑出一些小缺點，應該是其中的某些細節部分做得不夠仔細吧。很希望能夠一關接著一關的玩下去，但還是免不了需要進行所謂的練功程序；而在練功的情況下，為了達到 FEVER 的狀態，需要一直重複著相同的按鈕步驟，時間久了就會覺得有點厭倦。另外像是使用材料產生士兵的地方，介面上沒有明確提示出合成材料是可以更換的選項，結果就是我把得來不易的「響聲」全都拿去製造最初階的兵種了，直到打 Boss 不夠力時才發現原來可以生產更強的部隊。還有在某個需要祈雨的關卡，我因為把 PON 按鈕誤認為 DON 按鈕（別懷疑，在連玩 N 小時的情況之下，真的很容易眼殘誤認！XD），因而卡在同一個地方一個多小時以上。 Orz

這個遊戲很奇妙地非常合我的 Tone。我特別喜歡這樣畫面簡單、元素創新、風格出眾的遊戲類型。在進行遊戲的過程中，需要維持相當高的專注力以及聽注力，想要一心兩用的一面看棒球、一面按按鈕練功，完全就是沒辦法同時兼顧的兩件事。要命的是，現在我自己在走路、騎車或是思考問題的時候，都會不自覺地啪打啪打啪打碰了起來，這些可愛大眼 Pon 的影響力真的是太恐怖了啊啊啊啊～ XD

在這篇簡短的訪談文章裡，提到 Patapon 是一個先有了美術成果，而後才想出遊戲設計與玩法元素的奇妙遊戲作品。遊戲原畫師 Rolito（他的網站與部落格）是一位現年 35 歲的法國人，這是他所參與的第一個遊戲專案，而 Patapon 的原型是早在 2002 年時就已經創造出來的角色。由他所創造出來的角色原型，帶給 Patapon 的遊戲製作人「節奏擊鼓」、「史詩戰鬥」與「偉大探險」的強烈印象，最後開發出來的成果，就是呈現出這樣一款前所未見的有趣遊戲。

「Art as gameplay?」
「Yes.」
「Art as gameplay!」

或許未來，我們會見到越來越多這樣獨特有趣的遊戲呢。

另外，為了進一步學習與測試 NDS 平台上的程式設計，終於去買了傳說中很貴的謎樣備份卡。看到自己所寫的程式，能夠在真正的 NDS 主機上順利執行無誤，還真是有一種難以言喻的感動哪！：D

書名：好創意，更要好管理
作者：鄭秋霜
出版：三采文化 (2007年10月)

我是一個很缺乏創意的人，所以一直以來都很喜歡閱讀有關於「創意」這個主題的書。然而大部分談論創意的書，多著眼於理論學說或是訓練學習的方法論，比較少有真實世界中的驗證實例。「好創意，更要好管理」這本書最吸引我的地方，就是在於其中所收錄的十二個案例，全部都是台灣文化創意產業的真實故事。

等一等。

「創意」與「管理」？是不是有人搞錯了？這兩個主題為什麼會放在同一本書裡面？

創意與管理，是兩個完全不同世界的東西，怎麼能夠放在同一本書的內容中討論？所謂的創意，是能夠讓蘋果公司開發出大紅大紫的 iPod，能夠讓任天堂的 Wii 風行全球的超級關鍵耶。而管理？只是些硬梆梆的老學究理論，或是渾身銅臭味的商人腦袋裡面裝的東西吧。創意與管理，根本是兩件完全背道而馳的事啊！畢竟擁有無限可能的創意，要如何能用有限管理的制度來約束呢？這些發明什麼鬼管理制度的人，應該一個一個抓去關起來才對，都是因為世界上有這樣的人存在，才使得我們無法自由發揮寶貴的創意！

繼續閱讀 << "《好創意，更要好管理》：感性與理性的衝突碰撞"

是的，你沒有看錯，本篇文章的主題是「NDS 程式設計」。

由任天堂公司所開發的 Nintendo Dual Screen 攜帶型掌上遊樂器，前幾年甫一上市就席捲了全世界的遊戲市場，而在 NDS 平台上的程式設計與開發，也已經是行之有年並且十分活躍的社群活動。一開始是由 GBA 平台，開啟了業餘愛好者在 Console 平台上自製程式的可能性，接著在效能強大的 NDS 掌上型遊樂器問世之後，很快地就有幾位能力高強的程式設計者，開發出能夠製作 NDS 程式的函式庫與工具。

我自己原來就非常喜歡玩 NDS 上的各種遊戲，在機緣巧合之下，最近剛好接觸到 NDS 程式開發的相關知識，覺得實在是非常新奇有趣又好玩！所以往後在這個新增的「學習筆記」分類中，我將會分享自己在學習過程中所獲得的一些心得與經驗；包括從門外漢一步步踏入這個新領域的過程中，所需建立的概念以及所需閱讀的文章，並且由淺入深地詳細解釋每個必要步驟，希望能夠對於有興趣學習 NDS 程式設計的讀者有一點幫助。如果其中內容有所錯誤或疏漏之處，也請不吝指正。

在搜尋引擎中，鍵入 NDS 程式開發或 NDS 程式設計的相關字句，立即就能夠找到許多相關於 NDS 程式開發的網站教學，然而，對於一個完全沒有 Console 平台程式寫作經驗的人來說，應該要從哪裡入門比較合適呢？在本篇文章中，將使用 libnds 函式庫與 devkitPro 開發工具，加上 PAlib 的環境設定為輔，在 Windows 平台下，初探 NDS 程式設計領域中 Frame Buffer 的使用以及 Input System 的操作，並提供完整的程式碼範例下載。

繼續閱讀 << "初探Nintendo DS程式開發與設計（一）"

在側邊欄位加了一個「熱門文章」的排名列表。這個排名的評分方式，是以直接點擊、分類點擊、存檔點擊，還有留言迴響等等要素的加權值所自動計算出來的。可以參考看看猴子靈藥的來訪者，對於哪幾篇文章的關注程度比較高喔！

在目前的排行榜中：

• 第一名：「遊戲引擎的層級架構」
• 第二名：「Scripting系統概論與Lua簡介」
• 第三名：「商業或自製，引擎大不同！」

讓我們恭喜這些得獎者～ XD

另外，更新了「投票調查」的主題，請各位閒暇之餘去按一下投票選項吧～感謝支持！ ：D