上週五，很榮幸接受龍華科技大學人文暨科學學院院長的邀請，到學校進行了一場演講。

李院長非常地親切認真，不僅從演講前、演講中及演講後全程參與到底，也相當關心學生的生涯規劃與未來發展。此外，還有一位教授蒞臨現場聽講，並請我多多向學生們強調學習英文的重要性。而許多遊戲系的學生與少部分他系學生，發問也相當踴躍，如潮水般毫不間斷，就連中場休息時間的空檔也不放過。像這樣積極主動的提問情形，在一般的專題演講中可真是少見哩！

這次的演講，除了依照遊戲系學生的需求，將原有的簡報內容進行修改與補充之外，另外也新增了一項新的主題，以最近完成的商業獨立遊戲《Potion Action》為例，分享我在遊戲開發與設計過程中的經歷以及心得。

這次的簡報下載，只有摘錄新的內容喔。

簡報下載：SpeechSlidesExcerpt_LhuChs.pdf（PDF 格式）(下載次數： 1818 )

有幸受到系上學弟的邀約，上週回到了我的母校，與系上的學弟妹們進行了一場演講，分享我在遊戲業裡六年來的心得感想。

內容大綱：

• 為什麼不要進入遊戲業？
• 認識遊戲業
• 破解遊戲業迷思
• 如何進入遊戲業？
• 案例分析
• 「希望」在哪裡？

這場 97 張投影片與 100 分鐘的演說，為我的六吋光陰下了一個最棒的註腳。 ^_^

簡報下載：SpeechSlides_NthuCS.pdf（PDF 格式）(下載次數： 14087 )

《Crystal Guardian》Design Draft

這是《Crystal Guardian》的遊戲設計草稿。

其實大約在四個月前，我就已經完成了遊戲的基礎設計，本來想要在 NDS 平台上嘗試製作這款小小的遊戲原型，不過後來因為被其他有趣的事情吸引，再加上我一直找不到能夠在 Homebrew 套件上執行 Lua 的方法，所以也就沒有往 NDS 的方向繼續發展下去了。直到兩個月前，在玩過「咕世界」並且讀了「How to Prototype a Game in Under 7 Days」一文之後，內心深處那股「無論如何都想要做遊戲」的雄雄烈火，又再度燃燒了起來！

一開始在做遊戲設計的靈感發想時，對於目前網路上各種動作過關類型的小遊戲，可以看到大多數作品都是以「攻擊」、「毀滅」或者「破壞」當作遊戲的主要題材與樂趣元素。而我想要嘗試的，則是完全相反的方向。我反問自己：「有沒有可能以『保護』或者『防衛』的概念，做為遊戲的主要機制？」

當然，現在有許許多多 Tower Defence 類型的遊戲，但是我想做的並不是這種玩法的遊戲。我想做的遊戲，設計概念與核心機制的出發點在於「防護」(Defence)，或許是保護金銀財寶、捍衛重要的東西或者心愛的人，無論那是什麼，我認為世界上總有些值得我們守護的人、事、物以及價值。而至於遊戲的操作方式，我想嘗試的方向，是一個不用動腦思考，只需要不停移動並且點擊滑鼠就能夠進行的遊戲。

按照遊戲原型開發文章裡的做法，我原先預估的開發時程為 10 天整。直到正式開始動工之後，馬上就發現每天的開發時間，實在是超級無敵不夠用，才剛做出了點東西就花費掉一整個晚上，依照這樣的進度，10 天左右肯定無法完成遊戲，於是決定將開發時程延長為 14 天。結果，最終在燃燒小宇宙與睡眠時間的狂暴化狀態下，還是延遲了 2 天，整整用了 16 天才完成這款小遊戲。

雖然遊戲的核心機制很早就已經建立完畢，但是 Game Theme（遊戲題材）卻一直處於懸而未決的狀態。原因是「遊戲題材」與「遊戲素材」具有非常高的相依性，在找不到美術設計者合作，我自己也不會畫圖的情形下，想要對遊戲題材拍板定案，實在是一項相當困難而又不切實際的想法。

以後見之明來看，如果當初能夠使用 Flash 做為製作工具的話，應該可以節省不少開發基礎遊戲元件所花費的時間。但是我對 Flash 的熟悉度，差不多停留在讓矩形移動與變大變小的程度而已，所以最終還是毫無懸念地決定使用我最熟悉的 C++ 與 Lua 製作遊戲。

而這次開發的成果，並不是完全從零到有產生出來的。我原先已經有一個小小的遊戲程式框架 (Framework)，曾用來製作過一個 2D 遊戲的半成品，其中的功能只有非常基本的 Graphics、Audio、Input、Script 與 Debug 功能。於是我就以這個 Framework 做為出發點，義無反顧地展開了這趟遊戲開發的奇妙旅程。

過程中，我將每一天的進度都大致記錄了下來。以下就是這段時間裡，每天所做的開發日誌筆記：

Day 1

• 簡單扼要地在 Lua 端確立了程式的主流程。當程式啟動初始化完畢後，程式的控制權，包含 Update、Render 以及偵測視窗訊息與鍵盤滑鼠狀態在內，全權交由 Lua 端掌控。只要控制權一回到 C++ 端，就要清理資源然後準備結束程式了。
• 在既有的程式碼中，只能夠顯示單一的 Sprite 物件，這樣可不行哪。以 Sprite 為基礎，開始打造 CompositeSprite，可以組合任意多個 Sprite 做為一個完整的物件個體。（結果最後並沒有使用到這個功能）
• 原先在 Framework 中的 Input 系統只有二元狀態 On 或 Off 的 Polling 模式，對於開發除錯來說實在很不方便，所以決定先在 Lua 裡弄個簡易的 Event-based 模式，讓我在每次按下鍵盤或滑鼠按鈕時，只會送出一次事件訊息。
• 在網路上亂逛，意外找到《太空戰士》系列作品的 Sprite Sheet，品質看起來很不錯，是不是可以考慮拿來做為遊戲的素材？

Day 2

• 製作 Animation 系統。以前有使用 Lua 寫過相同的東西，所以翻出舊作的 Source 來看。「寫得真糟，當初怎麼會這樣想又這樣寫呢？」費了些功夫，翻修製作出新的 AnimatedSprite 元件。當然動畫資料的定義，也全部都使用 Lua 完成。
• 現在可以載入多張獨立的圖片播放動畫，但是網路上找到的 Sprite Sheet 通常都是一整張圖片的連續畫格，如果還得自己動手裁切，未免也太費力了點。所以只好再製作 AnimatedSprite 的第二種模式，讓它能夠讀入單張圖片來播放動畫。
• 套用《太空戰士》的 Sprite Sheet，測試 AnimatedSprite 元件的功能無誤。好，就決定偷這些圖來用！
• 重新組織 Lua 端的檔案結構。

Day 3

• 給點回應吧！實現簡單的矩形與圓形碰撞檢測。有了 Pick 元件後，才能夠知道滑鼠到底有沒有點選到 Sprite。
• 創造簡易的 State Machine 元件來搭配角色的 Animation 系統，目前只有 idle 與 move 兩種狀態。
• 放上數個不同圖片的角色，於遊戲視窗中隨機遊走。顯示結果怎麼全部的角色圖片都相同？
• 第一次臭蟲大魔頭來襲：是之前的 AnimatedSprite 功能有誤嗎？還是哪個部分的功能有所疏忽？經過了一番奮戰並且用掉好幾罐「補血瓶（小）」之後，才發現原來我誤用了 Lua 物件導向設計的觀念！

下列程式碼是錯誤的用法：

    local o = self:Instance();
    o.m_Transform = transform;
    o.m_Texture = texture;
    o.m_Sprite = sprite;
    

下列程式碼才是正確的版本：

    local o = self:Instance
    {
        o.m_Transform = transform,
        o.m_Texture = texture,
        o.m_Sprite = sprite,
    };
    

修改完成後，終於還給每個角色他們原來的真面目了！

Day 4

• 開始加入先前已設計完成的 Game Level 結構，可使用 Lua 檔案很便利地定義每一個關卡敵人的出現時間、類型、數量與方位。
• 簡便地使用 function 與 if-else 切換不同的 Game Stage。目前初步規劃，共有 Initialize、In Game、Between Level 與 Game Set 四個 Stage。（決策錯誤）

Day 5

• 建立玩家角色的各種狀態：idle、move、attack、powerup 以及 dead。滑鼠點擊後，玩家角色會移動至滑鼠位置，如果角色正在進行攻擊動作則無法移動。過程很順利。
• 創建敵人的 dead 與 dig（偷取水晶）狀態，包含先前的 idle 與 move 在內，終於完成了第一個完整的 AI 流程。不過敵人還是只會在場景上到處亂逛。

Day 6

• 開始著手製作原先規劃的數種 AI 型態：預設的一路走到底 AI、亂亂走 AI，還有走一走會停下來的 AI。

Day 7

• 為了讓 Release Build 的建置程序更加自動化與直覺化（簡單說就是我懶得做一大堆複製貼上的動作），所以用 Lua 弄了個 Prebuild 程序。將指定的純文字格式 Lua 檔案，全部寫入一個新的檔案中，完畢之後執行 luac 編譯成 binary 格式。最後，把執行命令加在 Project 的 Post-Build Event 中，搞定！

Day 8

• 開始寫 Gameplay 流程的部分，包括 Stage 與 Stage 之間的銜接，Game Over 與全破關的條件判斷。程式碼逐漸有越來越混亂的感覺……

Day 9

• 到目前為止，遊戲中還沒有出現任何文字。所幸 Framework 中已有繪製 TrueType Font 的功能，直接拉進 Lua 使用。測試無誤。

Day 10

• 到 POPcade 的音樂音效素材區搜尋資料，找到一個日本的網站 Propan_Mode，裡頭滿滿的都是 MP3 格式的高品質音效與音樂，真是太棒太讚太感動啦！（不過一直沒有找到合適的攻擊音效，囧）
• 加入播放音樂與音效的功能。製作一個 Radio 元件，用來做為遊戲中的 BGM Player，可把使用者提供的播放清單，依序、隨機或者循環播放。

Day 11

• 在 Google 打上「Free Font」，從成千上萬個 Font 裡找到幾個還算合用的字型。
• 用網路上搜尋到的免費軟體，將 MP3 轉換為檔案容量較小的 OGG 格式，將播放音效的程序加入遊戲。

Day 12

• 用 Photoshop 幫角色圖片進行去背程序。讚！終於不用帶著白色的框框在場景上行走啦。
• 再度修改 Animation 系統與 AnimatedSprite 元件，現在可以指定動畫中每個畫格的起始位置了。
• 產出遊戲角色以及水晶的動畫定義檔，對每一個動作的每一個畫格（還好數量很少），Pixel by Pixel 逐一進行微調。

Day 13

• 測試 AI 系統裡最複雜的「閃避」程序。果然有不少問題，經過整修後得出一個還算可接受的成果。
• 修改 Framework 的 Debug 功能，可將 Lua 的錯誤訊息以 MessageBox 秀出來並且記錄在 Log 檔中。（為什麼這麼晚才想到可以這樣做？ =_=）

Day 14

• 實作 AI 的 Perk 程序，敵人「格檔」時會無視玩家的攻擊，「反制」時會使玩家在三秒內無法動作。掛上一個額外的盾牌與雙劍小圖示。
• 加入分數計算以及 Combo 連擊加成的程序。
• 從以前的作品素材中，拉來幾張背景圖。場景畫面終於脫離了單調無趣的背景色！

Day 15

• 開始正式製作遊戲關卡。試玩，微調，微調，微調。
• 找了台沒有安裝 MSVC 的電腦測試，確認遊戲執行檔沒有 DLL 相依性的問題。
• 第二次臭蟲大魔頭來襲：正當我以為遊戲已經逼近完成之時，突然發現了嚴重的邏輯與流程問題。當敵人奪取水晶之後再被玩家擊倒，敵人的 AI 會產生異常狀態。然後過關條件的判斷也不正確，水晶都被幹光了竟然沒有切換到 Game Over 的 Stage，到底是怎麼回事？

Day 16

• 重新大整修：首先是敵人連結水晶的部分，寫的方式含糊不清又太多假設條件，造成不正確的執行結果。接著再重新思考敵人的 State 轉換，將原先散落在各個 State 中的邏輯判斷，提煉出來做為獨立的 function。最後，加入一個新的「準備階段」Stage，大幅簡化 Stage 與 Stage 之間的切換流程。
• 重新調整關卡難度。調整。測試。調整。測試。完成！
• 打包壓縮，撰寫文章，發佈。（靈魂飄走）

以上就是 16 天以來的開發流程。

雖然我使用 Lua 已經有一段不算短的時間了，但這還是我第一次以 Lua 完成所有的 Gameplay 程式碼。在遊戲的開發流程中，相關於程式設計的部分，只有使用了 5% 左右的時間在修改及新增 C++ 端 Framework 的功能上，其餘 95% 的時間全投注於 Lua 的環境下撰寫程式碼。再者，為了使這些以 Lua 撰寫的遊戲元件能夠繼續在未來的遊戲作品中使用，所以也耗費了不少時間在考量 Reusability（可復用性）的議題。最終，順利地把 Lua 端的程式碼，分成了「遊戲元件」（可復用）以及「Gameplay 相關」（不可復用）兩種不同的用途。

使用 Lua 編寫 Gameplay 程式邏輯的主要優勢在於「速度」。修改，存檔，然後執行，一氣呵成！再也不必因為一點小小的修改，而必須等待漫長的程式碼編譯與函式庫連結時間。但是使用 Lua 也並非全無缺點；在程式碼編輯工具的選擇上，我使用的是 Lua for Windows 套件中的 SciTE 編輯器，雖然 SciTE 具備有基本的編譯與除錯功能，但無法與 C++ 端的程式碼相互連結，所以在 Gameplay 的除錯程序上比較麻煩，還是必須執行 C++ 端的程式執行檔，才能夠找出 Lua 端的錯誤與問題點。

另外在撰寫程式的過程中，我有點太過於小看 Stage 切換邏輯判斷的複雜度。一開始在撰寫 Stage 相關的部分時，並沒有設想太多，只使用了最簡單的 function 與 if-else 敘述句來切換不同的 Stage，結果到了最後反而造成不少問題。還是應該打從一開始就把 Stage 的架構與流程控制，寫成一個獨立可重複利用的元件才正確。

而在所有的程式系統與遊戲邏輯中，最複雜的部分應該就是敵人的 AI 程序了。我想達到的目標，是多變且具有擴充性的 AI 模組。為了達成多樣化的 AI 行為，如果只是單純地將 AI 程序分成「直線型」、「隨機型」與「格檔型」等等，其實無法發揮良好的綜效。所以後來我想到了一個做法，就是將 AI 處理程序拆解成三種獨立的邏輯程序，分別是 Path Planner、Tactic Thinker 以及 Perk（特技）：

Path Planner

• 直線
• 隨機

Tactic Thinker

• 無
• 暫停
• 閃避

Perk

• 無
• 格檔
• 反制

分成三種獨立程序之後，我就可以在設計各關卡的敵人類型時，任意組合上述三種 AI 邏輯程序，然後再加上敵人外觀與生命數值的設定，製作出豐富而多樣化的敵人軍團。

在這 16 天的遊戲開發過程中，排除之前預先完成的遊戲設計層面，以程式設計、素材生產與關卡設計三個面向進行評估，程式設計約略佔了 80% 左右的開發時間，而素材生產與關卡設計加起來卻只佔用了 20% 左右的時間。用在關卡設計與素材製作面向上的心力，實在太少太少啦！

總結來說，下一款遊戲作品的改善目標為：

1. 先搞定 Stage 架構與流程控制元件。
2. 美術！我需要找到能夠共同合作的美術成員，或者是可以見人的 Better Programmer Art。
3. 花費更少的時間寫程式碼，把更多時間心力投注在關卡設計與素材製作上。
4. 遊戲必須要更有趣，更具有可玩性。

在遊戲設計的層面上，我還是個十足的嫩咖，但是只要過程好玩，我就會一直一直玩下去！ ：D

你可能不知道的小秘辛：遊戲本來想取名為 Crystal Defender，後來發現 Square Enix 在 iPhone 上有發佈一款同名作品，所以只好更換名稱為 Crystal Guardian。 XD

你不可不知道的小秘技：如果覺得遊戲太刁難或是滑鼠不夠滑而過不了關，請打開遊戲資料夾中的 GameEnemy.lua 與 GameLevel.lua 檔案，相信各位一定能夠發現戰勝遊戲的很黑暗的招。 ：P

（圖片來源：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 個月左右，完全沒有任何收入進帳的開發時期裡，付給員工們足夠的薪資以及各項相關的研發費用。

「既然如此，遊戲開發者為什麼要獨立？有人願意捧著大把鈔票請你製作遊戲耶！」

然而，事情總有一體兩面。

金錢必須以權力做為交換。在發行商出錢交由開發商製作遊戲的商業模式裡，發行商往往掌控著很大的權力，能夠左右遊戲的開發流程、功能需求以及專案時程。出錢的是老大，所以很多遊戲開發面向的決策，經常都是遊戲發行商說了算。大部分的發行商都會希望製作風險比較低，同時廣受全球玩家市場喜愛的遊戲類型；而只要製作出一款成功的遊戲作品之後，遊戲開發商接下來的任務，就是進行數不清的續集、資料片、擴充包與威力加強版等等相關遊戲專案。由於上述的種種因素限制，使遊戲創造者們很難實現出創新的遊戲類型與遊戲玩法。

為了讓遊戲開發商們能夠脫離發行商的監控與擺佈，在 1998 年時由幾位遊戲開發者合資創立了 Gathering of Developers 公司（簡稱為 G.O.D.），目的在於以開發者的角度提供遊戲的發行服務，同時也讓開發者能夠自行掌控專案並且參與市場行銷層面的決策。可惜在發行了數款遊戲，其中包括大獲好評的《Max Payne》後，仍然不敵殘酷的現實，在 2000 年被 Take-Two Interactive 公司收購，最終併入旗下的 2k Games 子公司後，G.O.D. 的理想也就逐漸式微了。

在獨立遊戲開發商的範疇裡，其實也有規模大小的區別。規模大者如 id Software 或者 Stardock，都是相當優秀且極具知名度的獨立遊戲開發公司。相對來說，小型的獨立遊戲開發者，團隊人數多在 10 人以下，其中全職投入的團隊成員更是只有 2 到 5 名左右而已。在接下來的文章內容中，我將特別著重於這些小型規模的獨立遊戲開發者上。

並不是只要做出好遊戲，就一定能夠成為大賣特賣的遊戲。

World of Goo（圖片來源：handheldwii.wordpress.com）

對於許多懷抱著夢想的創作者來說，或許是一件非常難以理解的事實，但是請各位務必謹記上述這項極為關鍵的觀念。創造與製造產品是一回事，而如何賣出產品則是另一回事。如何讓客戶知道新產品的存在？如何說服客戶你的產品比別人的好？如何使產品出現在客戶會去的商店？如何讓客戶心甘情願地掏出鈔票購買產品？在過去的遊戲市場中，遊戲開發者與玩家之間的巨大鴻溝，正是在於難以跨越的「通路」之中。從商品銷售的角度來看，由於遊戲發行商掌握了行銷、庫存與通路端的龐大資源，遊戲開發者所擁有的交易談判力量相對弱勢許多，因此在販售遊戲所得的收入中，發行商通常會佔去至少 50%，甚至到達 70% 以上的利潤。

在科技日新月異，寬頻網路服務逐漸普及之後，也使得所謂的「數位下載」(Digital Download) 成為一條前所未見的全新通路，為獨立遊戲開發者帶來一項全然不同於傳統商業模式的可能性。相較於必須花費龐大金額建立的實體通路，在虛擬的網路空間裡，任何人只需要花費極少的費用建立網站與購物流程，就能夠在網路上販賣自己製作的遊戲成品，想要發行遊戲產品不再需要侷限於實體通路，以及商店裡極為有限的貨架空間！而在免除了遊戲發行商的抽成與拆帳之後，更能夠使遊戲開發者真正得到 100% 完整的遊戲銷售利潤。

與休閒遊戲相同，獨立遊戲大多使用共享軟體 (Shareware) 的模式，在網路上釋出限制遊戲時間或者遊戲關卡數量的試玩版，以吸引玩家下載試玩；試玩之後如果覺得滿意，就可以前往該網站購買遊戲的完整版。需要特別注意的是，務必不可將「休閒遊戲」與「獨立遊戲」兩者混為一談。在獨立遊戲的範疇中，限於人力與資源的限制，多數都是規模比較小型的遊戲；即使如此，仍然有比較屬於硬派玩家市場而非休閒市場取向的獨立遊戲，例如像是《雷電》般彈幕漫天飛舞的縱向捲軸射擊遊戲，或是類似《洛克人》般的平台動作類型遊戲。反過來說，在休閒遊戲的領域中，由於所需投入的金錢與資源較少，所以也相當適合做為獨立遊戲開發者的目標。因此，可以說休閒遊戲與獨立遊戲兩項領域有所交集，但彼此間並不存在分支或者衍生的關係。

除了一般在 PC 與 Mac 平台上常見的數位下載商業模式以外，最近幾年在三大遊樂器主機上，由於硬碟配備已經逐漸地被玩家市場所接受，也使得包括 XBox Live Arcade、PlayStation Network 以及 WiiWare 在內的三大遊戲下載平台，很快地成為了一股極具發展潛力的新興勢力。另外，剛問世不久的 Apple iPhone 同樣也開放了 App Store 數位下載服務平台，更為獨立遊戲開發者帶來了更多全新的契機與市場！

或許有些人會懷疑，獨立遊戲的品質是否比得上那些高成本的大型商業遊戲？目前在市面上，有許多獨立遊戲所呈現出來的成果，即使與大型商業遊戲相比也不會落於下風；例如《Aquaria》、《Braid》以及《World of Goo》，都是極富創意與樂趣的優秀獨立遊戲作品。在獨立遊戲的內容裡，或許不會有細緻精美的 CG 電影，或許不會有生動自然的人物語音，或許不會有能夠探索數百個小時的遊戲世界，但是也正因為極為有限的資源限制，反而使獨立遊戲能夠真正專注在「樂趣」的本質上。

Braid（圖片來源：www.frictionlessinsight.com）

而比起大型遊戲開發商製作的高成本大作，獨立遊戲也更能夠深入特殊而小眾的利基市場之中，在遊戲領域中達到驚人的「長尾效應」。以 Positech Games 為例，該開發者所研發的《Democracy》系列，是一個以政治選舉題材的策略模擬類型遊戲，不僅獲得遊戲評論網站的高度評價，同時也具有相當優異的銷售成績。

目前在獨立遊戲界裡，最盛大也最受到開發者關注的年度盛事，莫過於獨立遊戲大獎慶典——Independent Games Festival（簡稱為 IGF）。IGF 會在獨立遊戲開發者所製作的遊戲中，選出包括設計創新獎、最佳技術獎、最佳視覺獎等各種獎項，並且在每年 Game Developers Conference 舉辦的地點中進行頒獎。獲獎的遊戲作品，除了能夠得到獎金的鼓勵之外，更重要的是能夠獲得大量的媒體版面與行銷效應。

如果想要進入獨立遊戲開發的領域，以遊戲程式設計者的觀點來看，會考量的首要事項應該就是開發工具的選擇了。一般來說，相較於中型以上的商業遊戲，開發小型獨立遊戲的技術門檻比較低。事實上，不論是以 C++ 或 Java 手工打造的遊戲引擎，或是 Torque Game Builder、BlitzMax，以至於現成的套裝軟體 Flash、Director，甚至是 RPG Maker 等等，都可以做為開發獨立遊戲用的程式語言以及軟體工具。

為了開發獨立遊戲並且進行販售，除了基本的遊戲企畫設計、美術設計與程式設計之外，必須要考量更多不同面向的事務。如「Triforce：遊戲開發三原力」文中所提，身為獨立遊戲開發者，更加需要對遊戲以商業、設計與技術三個不同的面向進行思考。二年多前，我開始接觸獨立遊戲開發領域的資訊，在深入學習各種相關知識並且嘗試自行製作遊戲之後，不僅讓我大大地拓展了遊戲開發領域的視野，更有醍醐灌頂、功力大增般的收穫。

在獨立遊戲的領域中，最最最著名的莫過於 Indiegamer 以及 TIGSource Forums 兩大論壇。有志進入獨立遊戲開發領域者，不妨先大量地閱讀這兩個論壇之中的文章。而若要學習系統性的獨立遊戲開發入門知識，那麼我會推薦閱讀「The Indie Game Development Survival Guide」這本書。作者在書中第一部份的章節「Indie Basics」裡詳細闡述了各種定義、源由與動機，接著針對小規模的遊戲專案做出遊戲設計規劃；然後在「Production Plan」與「The Team」章節裡，教導讀者如何進行組織團隊以及安排時程；最後的兩個章節「Building The Game」與「Selling The Game」則將之前的概念化為實際行動，談論進行遊戲製作的各項程序細節。由動機、設計考量、組織團隊、建立遊戲至如何販賣遊戲，相當徹頭徹尾完整的系統知識，即使對於一般的遊戲開發者來說，同樣是一本非常值得一讀的好書。

在獨立遊戲領域中，有些公司是先由遊戲入口網站 (Portal) 或者遊戲發行商的角色開始發展，而後也自行開發一些遊戲。而在另外一方，也有許多獨立遊戲開發者，會與其他的獨立遊戲開發者進行結盟，在自己的網站中販售更多的獨立遊戲作品。以下列出數個獨立遊戲開發者與遊戲發行商的網站，以及其代表作品：

• Bit Blot：《Aquaria》
• 2D Boy：《World of Goo》
• Positech Games：《Kudos》、《Democracy》
• Amaranth Games：《Aveyond》
• Games Faction：《Project Aftermath》
• Gamelab：《Diner Dash》
• Puppy Games：《Titan Attacks》
• PopCap Games：《Zuma》、《Bejeweled》
• Big Fish Games：《Mystery Case Files》、《Azada》
• Reflexive：《Ricochet》、《Big Kahuna Reef》
• Sandlot Games：《Cake Mania》、《Westward》

Aquaria（圖片來源：game.ali213.net）

有人說：「會選擇投身遊戲業界的人，如果不是熱血的傻瓜，就是無可救藥的浪漫主義者！」不論是哪一類人，誰不希望有天能夠做出一款真正自己夢想中的遊戲呢？而如果在自己夢想中的遊戲，恰好也是所有玩家夢想中的遊戲，那就更棒了！既能夠實現夢想，又可以賺大錢，人生樂事莫過於此！為了實現這個夢想中的夢想，有些人會在工作之餘默默地製作自己的遊戲；而有些資歷深厚的遊戲開發者，甚至會選擇辭去穩定的工作、捨棄優渥的薪資，全職進行獨立遊戲的開發工作。

如同獨立音樂與獨立電影在音樂以及電影產業中的重要地位，獨立遊戲正是代表著遊戲產業中的另外一種聲音，以及一股不容忽視的力量，使遊戲開發者與遊戲玩家看見更多的「可能性」。卸下了龐大的預算、團隊、繁複的專案時程，獨立遊戲更有機會超越出遊戲業界既存的框架，闖出另外一片天空。

你的腦袋裡是否裝滿著各式各樣稀奇古怪、精彩絕倫的遊戲點子？還是已經得到了一種「不做遊戲就會死掉」的病？不論你是遊戲業同行、在學的學生，或者是曾對遊戲抱持夢想的人，只要有本事，獨立遊戲開發的領域，隨時歡迎各位一起來挑戰！ ^_^

在今年八月底時，獨立遊戲開發公司 Stardock 的執行長 Brad Wardell 提出了一份「玩家權利法案」(The Gamer’s Bill of Rights)，洋洋灑灑總共列出十項遊戲玩家應享有的基本權利；此舉動不僅震驚了整個遊戲業界，也隨即在國外各大網站的玩家社群中引起廣大的迴響與討論。

（圖片來源：www.aeropause.com）

玩家權利法案：

• 玩家有權利退回無法在他們電腦上執行的遊戲，並且獲得全額退費。
• 玩家有權利要求遊戲必須以完成狀態上市。
• 玩家有權利期望在遊戲上市之後，獲得有意義的更新內容。
• 玩家有權利要求不需強制執行遊戲的下載管理員與更新器，才能夠進入遊戲。
• 玩家有權利期望遊戲能夠在最低需求配備的電腦上充分地運行遊戲。
• 玩家有權利期望遊戲不會安裝隱藏的驅動程式，或其他可能潛在有害的軟體。
• 玩家有權利能夠在任何時間重新下載任何一款他們所擁有的遊戲的最新版本。
• 玩家有權利不被遊戲開發者或發行商視為潛在的犯罪者。
• 玩家有權利要求遊戲的單人模式，不強迫他們在每次進行遊戲前都必須連結網際網路。
• 玩家有權利要求遊戲可以完整安裝於硬碟，不需要遊戲的光碟片才能夠執行遊戲。

請以遊戲玩家的身份，仔細地閱讀以上「玩家權利法案」中的條文敘述：你的直覺反應是搖頭不以為然，或者猛然點頭稱是？

為什麼明明是單機遊戲，卻必須要先上網進行認證才能進行遊戲？為什麼明明是花錢買的遊戲，卻限制只能夠執行三次安裝程序？為什麼安裝了遊戲之後，光碟燒錄機竟然會變得無法正常運作？為什麼電腦明明符合遊戲的最低需求配備，卻在買回家安裝以後才發現不能玩卻又無法退換？你是否也曾被條文中敘述的種種情況所困擾過？如果你和我一樣，是個經歷過電腦遊戲市場輝煌時期的玩家，應該多少會對以上的問題有些認同感。

各位讀者可能不熟悉甚至沒聽過 Stardock 這間遊戲公司，在此先稍微介紹這間公司的近況與表現：前陣子由 Stardock 所發售的太空戰略遊戲《Sins of a Solar Empire》，在沒有龍頭發行商的強力行銷奧援之下，已經在全球賣出了超過 50 萬套的銷售量！對於一間沒沒無名的小型遊戲開發商來說，可以說是非常優異的成績。

Stardock 之所以能夠獲得玩家社群的廣大迴響與推崇，除了遊戲內容充實有趣以外，最為人稱道的就是遊戲的執行需求配備非常的低，確保了多數玩家的電腦都能夠順利運行，甚至還對於無法順利執行遊戲的玩家提供全額退費服務，並且沒有在遊戲中使用惡意或擾人的 DRM 機制。目前他們與 Gas Powered Games 公司合作的《Demigod》預計將在明年第一季上市，同樣相當受到玩家的矚目與期待。

自數位化的時代以來，沒有實體的數位形式內容使得各種媒體的流通散佈更為迅捷便利，但同時也更嚴峻地考驗著著作人的權利；因此在技術層面上，很快地發明了各種對抗非法使用數位媒體產物的保護機制。現在經常聽到的 DRM 一詞，也就是所謂的「數位著作權管理」（Digital Rights Management，簡稱為 DRM），是用來保護數位內容使用權的一種技術，用意在於防止著作人的作品成果在未經授權的情況下被複製。主要來說，DRM 有以下幾種常見的限制手段：

• 必須在指定的硬體裝置上才能播放。
• 必須在特定的日期前才能播放。
• 播放的次數。
• 傳輸到播放機的次數。
• 燒錄到光碟的次數。
• 以上限制的混合。

約略從光碟燒錄機與空白片大幅降價的那個年代起，遊戲廠商也逐漸開始在遊戲光碟中加入各種防拷、認證或者保護機制，其中比較著名的系統包括有 SafeDisc、StarForce 以及最近掀起猛烈戰火的 SecuROM。其中，在數年前遭受玩家社群強力抵制的 StarForce，也曾經被廣泛地應用在國產的單機遊戲裡。例如《仙劍奇俠傳四》剛推出時，由於線上認證機制與 StarForce 防護機制所產生的問題，使玩家們興高采烈買了遊戲回家卻無法遊玩甚至無法安裝，不僅造成網路討論區哀鴻遍野的景象，也因此失去了許多忠實玩家對遊戲公司的信任感。

當時，StarForce 在許多遊戲中所造成的各種災難可說是罄竹難書，後來不僅遭受玩家社群的強烈抵制，更有人製作專門的 Anti-StarForce 網站，以及 StarFuck 共享軟體幫助玩家破解防護機制。StarForce 不僅會隱藏在電腦系統中無法讓使用者解除安裝，更會試圖改寫作業系統原先使用的光碟驅動程式，因而有可能造成光碟片無法正常讀取，以及燒錄機無法正常運作的情形。像這樣惡名昭彰的 DRM，很快地就變成了惡魔的詛咒，不但無法達到原先預期的破解防護效果，更在許多玩家的心裡埋下極深的負面觀感。

近來由 EA 所發售的年度遊戲大作《Spore》，不僅在全世界大賣特賣，已經突破了百萬套銷售成績，同時也正在世界各地的玩家社群中掀起激烈的 DRM 戰火。由於許多玩家反對 EA 所採用的 SecuROM，在 Amazon.com 中對於《Spore》的顧客評鑑裡，已經有數以千計的使用者串連，給予僅有一顆星的最低評價。而這樣的舉動，同樣也出現九月中旬才剛上市的《Crysis Warhead》顧客評鑑裡。根據 TorrentFreak 網站上的報導，因為 EA 所使用的防護機制激怒了駭客，結果反而使《Spore》成為最快被破解也最熱門的非法下載遊戲之一。

（圖片來源：kotaku.com）

以物理學的觀點來說，施予強烈的作用力，反而會導致更強烈的反作用力。但是我們仍然不應該以 DRM 做為使用非法下載遊戲的藉口，《Spore》的確是一款相當創新有趣且值得一玩的遊戲，可惜遭受到 DRM 機制的拖累，而未能達到更好的銷售成績。之前曾在「價格？價值？遊戲下載才是王道！」一文中，討論過關於遊戲盜版與非法下載的議題；事實上，非法下載已經不是單純可以用道德或法律約束的行為，除了在消極面改進 DRM 技術與制訂法律政策以外，或許我們更需要的是積極面的價值創造與商業模式創新。

「那麼，電腦遊戲軟體的價值何在？」

According to Stardock, the objective of the Gamer’s Bill of Rights is to increase the confidence of consumers of the quality of PC games which in turn will lead to more sales and a better gaming experience.

很多遊戲公司花費大把的金錢與時間，在遊戲裡施加了嚴格複雜的 DRM 機制，結果卻只是懲罰了誠實購買正版遊戲的玩家，傷害與玩家之間辛苦建立起來的信任感，使駭客們得到更多挑戰的樂趣，無法達到原先預期能夠防止非法下載並且提升遊戲銷售量的目的。正如 Stardock 的聲明稿所述，在「玩家權利法案」的立意中，最為關鍵的要點就是達到玩家對於電腦遊戲的期望以重新建立玩家的信心，以及對於電腦遊戲廠商的信任感。

電腦遊戲並不像 Console 平台的遊戲，在遊樂器主機上本身就有硬體的防護機制，也因此比起 Console 遊戲市場來說，電腦遊戲市場的非法下載比例總是居高不下。遊戲開發者與發行商必須認清的事實是：減少一份非法下載，並不表示就能夠增加一份遊戲銷量。在「非法下載」與「遊戲銷量」之間，從來就不是一比一的比例關係。如果無從下載，那些非法下載玩家多半只會選擇不玩，或者選擇下載其他遊戲，而並不會選擇去花錢購買遊戲。

在電腦遊戲市場上，雖然已經存在有像是 Games for Windows 這樣的認證標準，但這些認證大多還是專注於軟體品質層面的考量，而非由玩家角度出發，能夠使一般消費者都能很容易瞭解的標準。能不能讓玩家免於購買回家後才發現不能順利進行遊戲的恐懼？能不能讓玩家免於安裝遊戲會對電腦系統造成損害的恐懼？能不能不再將玩家們視為潛在的犯罪者般處處提防？「玩家權利法案」期望能夠補足這個開發者與消費者之間的認知落差。

Making games for customers versus making games for users.

不要把心力拿來對付那些不會購買遊戲的「使用者」（而且通常沒什麼效果），結果卻苦了真正花錢購買遊戲的「客戶」。不論是開發者或是發行商，做為遊戲的創造者，如果能夠從客戶的角度出發設想，應該不難理解為什麼會有這麼多人厭惡 StarForce 與 SecuROM 的存在。當然 DRM 機制並不是全惡無善，適當的 DRM 仍然有助於保障著作人的權利，只是我們需要更能被玩家所接受的 DRM，同時遊戲公司也應該主動做出聲明並且告知玩家，不去隱藏任何有關於 DRM 機制的細節。

不論是以遊戲開發者或者遊戲玩家的立場來說，我們都不希望讓目前已相當衰弱的電腦單機遊戲市場，最終消失殆盡而淪為物種滅絕的下場。「玩家權利法案」的目標，是為了達到一種長久的市場效應。未來某天，當我們在電腦遊戲的外盒上看到了「此遊戲遵守玩家權利法案標準」的閃亮亮認證貼紙時，是不是可以讓你毫不猶豫的掏出錢包購買遊戲？是不是可以給我更多對於遊戲公司的信心？是不是可以讓我們拍胸脯掛保證向親朋好友推薦這款遊戲？我希望答案是肯定的。

信心與信任感，這種無形的心理作用有多重要？就像最近國內發生的毒奶粉風暴，如果主事者不能給予消費者足夠的信心，使人民能夠安心且放心，即便提出再多政客、專家或者學者的背書，同樣都只是徒勞無功而已。電腦遊戲市場的現況亦同於此。

（圖片來源：www.wisconsincommonmarket.com）

或許有人會質疑「玩家權利法案」只是 Stardock 公司的宣傳手段，但我想如果這是一種行銷公關的手法，也絕對是我見過最高明而且對遊戲業界有益的作法！這份「玩家權利法案」究竟是電腦遊戲市場的一線曙光，或者只是嘩眾取寵的手段？你相信人性本善或者人性本惡？提出你的看法與意見吧！

經過前篇文章「遊戲開發入門：專案管理管什麼？」的介紹之後，相信即使是從未接觸過專案管理領域的讀者，也能夠對於專案管理的基本概念有一些基礎的概念與認識。接下來，本篇將深入時程的層面，探討在專案管理中相當重要的專案時程估算議題。

（圖片來源：www.codinghorror.com）

任何一項工作的時程安排，都需要具備三項條件：起始日期、結束日期以及與其他工作的依存關係。在專案管理領域以及專案時程表中，最受到廣泛使用的甘特圖 (Gantt Chart)，可以用清楚易懂的圖示來描述工作項目的這三項條件。而另外一項在專案時程中會經常聽到的術語是 Work Breakdown Structure（工作分解結構），或經常簡稱為 WBS。簡單來說，WBS 近似於前篇文章裡所提到的「工作項目階層分解程序」，能夠將原來非常龐大的功能項目，逐步往下分解為可處理的單一工作項目。

在遊戲開發流程中，為什麼我們需要制訂出專案時程表？

首先假設一下：如果今天你幸運地獨得大樂透頭彩，很豪邁地決定撥個幾千萬出來，投資製作一款自己夢寐以求的遊戲大作。於是你找來了擁有數十年業界經驗的資深遊戲製作人以及超強的研發團隊，準備開設一間全新的遊戲公司。然後，遊戲製作人拿出一份超棒的企畫設計文件，告訴你說：「只要給我二年時間加上四千萬資金，我一定能夠做出擊敗《楓之谷》、超越《魔獸世界》的遊戲作品！」

請問，你會不會相信他？你能不能夠安心地把自己的金錢與時間交付給他？

一款遊戲作品，從無到有的開發製作，少則需要花費 12 個月，多則需要 24 個月，甚至是 36 個月以上的時間。相對於企畫層面的設計文件，專案時程表就像是執行層面的計畫，可以用來告訴出錢的投資者無須擔心；例如說我們預計在三個月內完成遊戲雛形製作、六個月完成遊戲功能、九個月完成測試與調校，接著第十個月就可以上市，然後就開始蹺腳收錢！所以我們需要時程表，告訴自己目前的工作進度狀況如何，告訴團隊成員我們正在邁向偉大的航道，告訴投資者他們的錢沒有白花！當然所有的這些良好意圖，都必須建立在計畫時程估算準確的前提條件之下，才能夠發揮時程表計畫的原意。

How does a project get to be a year late?…… One day at a time.

如果你已經在遊戲業界裡打滾，經歷過了幾個專案的工作經驗，可能會想說：「誰家的專案不 Delay？」或者說：「所謂的專案時程，本來就是拿來 Delay 用的啊！」除去政治因素的考量，我想我們必須從專業的知識理論中學習，試著減少專案的延遲情形才是正確的態度。就像《人月神話：軟體專案管理之道》書中所提到：「為什麼專案會落後一年？……因為每次落後一天。」當工作進度只延遲一天的時候，看起來並不嚴重，但也就是這樣一次一點點的延遲，最終就會導致專案產品數個月，甚至長達數年的延遲。

今天上頭指派了一件任務給你，以工作執行者的觀點來看，對於交付的任務我們可以說：「完成 X 項目概略需要花費 Y 工作時間。」但如果工作項目的時程，是由管理者而非實際的執行者進行預估與安排，很容易就會變成「在 X 時間內必須完成 Y 項目」的過度強勢壓力或者過度樂觀想法。試問如果不是真正執行工作的人，如何能夠準確預估工作項目所需的時間？當然，時程估算並不是放任執行者開心地隨意自訂時程，所以管理者本身需要具備一定的專業知識能力，才能夠對各執行者交付的時程預估做出合理的判斷。

帕金森定律 (Parkinson’s Law)：無論配置多少工作時間，該工作都會把配置的時間耗光。

如果帕金森定律是真實成立的理論，那麼管理者只需要盡可能壓縮每項工作的分配時程，就能夠獲得越來越好的生產力與工作效率；但很顯然地，事實並非如此。在《Peopleware：腦力密集產業的人才管理之道》書中，對於這項著名的帕金森定律進行反駁；由研究機構調查的統計數據顯示，將工作交由程式設計師進行預估所得到的生產力，反而遠大於交由監督者進行預估所得到的生產力。除非管理者對每個工作者的能力、經驗與心理狀態瞭若指掌，否則在大部分的情況下，還是只有執行者能夠最準確地估算出工作項目的執行時程。正如此書最後所提，應該將帕金森定律修改為「組織裏沒有效益的白工，傾向於會把工作時間耗光」才是真實而令人戒慎恐懼的理論。

「無論如何，我就是要在一個星期後，看到這項功能完成！」如果管理者只是一意孤行地想在有限的時程內塞入不合理的工作項目，不管是加班爆肝還是燃燒小宇宙，只是逼迫執行者自己想辦法解決，反而經常會造成難以收拾的後果。正所謂「上有政策，下有對策」，對於無理的時程安排，如果積極的抗議與建言無效，執行者的消極應對方法最後通常都會演變為「犧牲品質以拯救時程」的結論。「反正只要交出結果就好，不是嗎？」像這樣只重視結果而忽略過程的遊戲開發流程，往往會在專案後期遭受到嚴重的災難反噬。

至此，假設你已經說服老闆或管理者，可以把工作時程的生殺大權掌握在自己手上，那麼又應該要注意哪些工作時程估算的細節？

錯誤的工作時程預估，往往是使得整個專案不斷往後延遲的罪因之一。為了達到比較良好的預估準確度，首先必須要將工作任務進一步分解至合理的規模大小。一般情況下，主管只會就系統面或功能面進行任務指派，例如「製作武器的拖曳軌跡特效」工作項目。而如何妥善地分解工作項目，就是屬於執行者的職責；在分解完成之後，單一一項任務的執行時間不應該多過於 24 小時，也不應該少於 4 小時。如果你無法妥善地分解功能項目，表示你對工作任務的內容並不完全瞭解，很可能是你不熟悉的領域或者具有困難度的任務，請先尋求主管或同事的建議與協助後再行預估。

工作項目：武器的拖曳軌跡特效

• 特效系統架構設計：8 小時
• 特效系統實做：24 小時
• 拖曳軌跡 Shader 製作：12 小時

工作總時數：44 小時

如果工作者被分派到的是完全沒接觸過或者不太熟悉的工作項目，例如研究一項全新的 Shader 技術、Scripting 語言，以及美術製作的新工法等等，往往需要花費一段比較長期而且連續的時間，最好是一次以三到五天為一個單位，由管理者設定研究探索的目標與停損點，在一段工作的期間完畢之後，檢視目前的成果，然後再決定是否繼續投注人力研究這些知識與技術。

除了遊戲功能面的一般任務以外，時程表中還有一些易於被忽略的隱形項目，包括文件撰寫、功能測試以及除錯工作在內。關於文件撰寫，事情是這樣的：「你沒有安排時間的項目，就不會自動自發地被執行與完成。」非常合理，但許多管理者總是傾向於當個樂觀主義者，相信所有人都能夠迫不及待地完成那些額外的工作。比較好的執行方式，應該是將撰寫文件的工作也列入正式的工作項目時程之中。

而另外一個時程預估入門者常犯的錯誤，就是沒有將功能測試程序以及後續除錯工作所需花費的時間排入時程之中，結果自顧自地完成了指派的功能項目，卻沒有安排充分的時間以進行測試。即使已經預先排定了測試的時程，在專案時間吃緊的狀況下，測試程序往往也是第一個被犧牲的項目。與撰寫文件相同，最好在工作項目之中將測試程序明確地安排進去，而不是把測試這件事，理所當然地視為功能設計或者功能實做任務中的一部份。

時程安排的另一項重要議題，在於如何驗證工作成果。當工作者完成了工作項目並且遞交成果之後，應當如何驗證成果的正確性？缺少驗證機制的時程安排，也就等同於忽略了非常關鍵的測試與除錯程序工作時間。以傳統程式設計的領域來說，在完成一段程式碼或系統功能之後，必須進行功能面的單元測試 (Unit Testing) 程序，以確保即使遭遇各種邊界條件或者異常資料，也不會對程式系統造成損害。如果專案採用測試驅動開發 (Test-Driven Development) 的方法，一開始就先由測試套件著手進行開發，應該就能夠達到更加良好的驗證效果。

此外，時程表還具備另一項比較隱性的功能作用，就是拿來做為個人績效考核的參考材料。在交付日期之前提早完成，能夠獲得比較好的績效考核；如果發生工作進度的延遲情形，就會減損考績的表現。然而，像這樣非黑即白，不是加分就是扣分的時程考核制度，久而久之就會使工作者在預估工作時程的時候，隱匿性地預留緩衝時間，以避免自己的進度落後因而影響工作獎金或分紅的情形。到最後，這樣的方式反而會衍生出時程上的隱形陷阱，使整個專案都遭受到進度延遲的負面效應。

如果你是業界的工作者，或許會對以下的這個例子感到有些熟悉：「我能夠在 24 小時左右完成這項功能，但是萬一發生某些狀況，或許會花費多至 36 小時的工作時間。」很多時候，由於熟悉度或者困難度的緣故，我們可能無法明確地估算工作的完成時間。為了解決這個模糊的估算問題，在國外的討論區，我看到有人提出一個有趣的想法，不再只是使用單一估計值，而是使用了雙估計值加上雙信心指數的時程預估方法。舉例來說：

工作項目：武器的拖曳軌跡特效

• 70% 信心指數：24 小時
• 30% 信心指數：36 小時

工作時程期望值：24 * 70% + 36 * 30% = 27.6 小時

與傳統非黑即白的單點預估值不同，雙估計值方法具有合理的誤差範圍值，使我們能夠使用比較精準的數字，來代替原先模糊不清的「應該」、「或許」與「萬一」用詞。其中的信心指數，可以先由管理者制訂出固定的比例，然後再由執行者預估在這兩個信心指數下完成工作的時間。如果所有的工作者都使用這個方法預估工作的時程，遊戲專案的製作人，就能夠根據這些資料，計算出在最好的狀況下、最差的狀況下，以及平均期望值下的專案時程進度。

在專案管理的理想世界中，只要妥善地安排好所有的 WBS 項目，制訂出完美的時程表，每個人就能夠按照著圖表中的時程計畫，分毫不差地進行且完成各項工作。但是在現實世界中，往往沒有這麼美麗可人的專案時程。並不是在專案正式開始之前，預先分解完所有的細節項目，讓所有的人完全按照時程表工作，就保證可以製作出優秀的遊戲成品。與遊戲企畫面的設計文件相同，專案時程表並不是死的東西；時程計畫需要具備適應變動的能力，才能夠隨著設計需求與實際執行成果的回饋，不斷地朝著正確的方向修改、演進以及成長。

（圖片來源：www.reqdb.com）

不論是漂亮的甘特圖或是詳細的 WBS 項目，目的都是為了幫助我們掌握專案的執行狀況，所以當時程表與專案的實際執行情況背離時，就毫無作用可言了。因此至少需要每週進行一次進度檢核，找出工作項目執行面的問題；如果團隊中的成員發生了進度延遲的情形，最重要的是幫助他解決問題，而不是一眛地指責批判或者施加壓力。當管理者謹守著自己預想中的時程表，而底下的工作執行者卻擁有自己的「私人時程表」，那麼最終導致專案延遲的後果也不是什麼令人訝異的事情了。

總而言之，遊戲開發並不像是在鐵軌上行駛的火車，能夠不偏不倚地沿著既定的規劃路線前進，而比較像是航行在海上的船艦；當我們訂立了終點目標與前進方向之後，仍然需要視海流、風向、氣候等等狀況，持續地調整揚帆的角度、划槳的力道與轉舵的方位，才能平安抵達預定中的目的地。你的時程進度表，是否真真切切地呈現出專案的執行現況？

生命生存的三要素是陽光、空氣與水；色彩學中的三原色是紅色、綠色與藍色；三國演義的三霸主是曹操、孫權與劉備；程式的三元素是語言、API 與工具。而在《薩爾達傳說》的故事背景中，則仰賴著力 (Power)、知惠 (Wisdom) 與勇氣 (Courage) 所結合而成的 Triforce 維持著世界的平衡。

（圖片來源：http://www.neoseeker.com/）

以遊戲作品來說，受到玩家喜愛的原因可能有很多，例如畫面漂亮、故事感人、音樂動人、操縱流暢以及玩法創新等等許多不同的因素。但是如果從遊戲創造者的觀點檢視，各位是否曾經思考過遊戲開發的三大原力為何？遊戲業界中是否也存在著神秘又奧妙的三原力？本文中，將分別以研發部門、專案管理以及遊戲開發，這三種不同角度的觀點，探討遊戲開發領域中的「三大原力」。

首先，以遊戲研發部門的觀點來看：

遊戲研發部門三元素

• 美術部門：美術設計者 (Artist)
• 程式部門：程式設計者 (Programmer)
• 企畫部門：企畫設計者 (Designer)

製作遊戲就像是孕育一個新生命，需要懷胎十數個月，不斷地灌溉愛心、耐心與細心，經過無數風波險阻，才能夠使「它」安然無恙地誕生於世。美術，是它的「皮」；程式，是它的「骨」；企畫，是它的「髓」。美術的皮，是吸引玩家的第一眼印象；程式的骨，是支撐起遊戲系統的樑柱；企畫的髓，則是使玩家流連忘返的魔力。這裡並沒有孰輕孰重的分別，就像是一個完整的人一樣，皮、骨、髓三者缺一不可；唯有緊密結合的皮骨髓，才能造就出一個人見人愛的遊戲寵兒。

另外，請注意在此指的是「研發部門」的部分，也就是經常縮寫為 R&D (Research & Development) 的部門。事實上，視公司的規模大小與經營方向而定，在遊戲公司內可能還會存在許多屬於研發領域以外的部門，例如行銷部門、測試部門、音樂部門以及營運部門等等，同樣具有舉足輕重的地位而不可漠視。

接著，以遊戲專案管理的觀點來看：

遊戲專案管理的三要素

• 時間 (Time)
• 品質 (Quality)
• 預算 (Budget)

時間、品質與預算三者之間，存在著天生的自然競爭關係；以專案執行的角度考量，很難找出能夠同時達到三個面向的最大利益的方法，因此我們必須從中抉擇，訂立出最合於既有條件與目標的執行方向。如果想要製作出品質卓絕、如同 Blizzard 公司出品的遊戲，至少需要挹注非常大量的時間與預算；如果想要節省團隊預算或者成員數目，相對來說就會花費較多的時間，才能夠達到比較好的成果品質；而如果是為了配合電影檔期上市的遊戲，時間是專案中最為關鍵而不可違逆的要素，也就難免會犧牲了些品質，或者必須投入相當程度的預算以彌補開發時間的不足。

想要在三者之間達成完美的平衡，幾乎比不可能的任務還要再多三倍的不可能。三者難以兼得，這是遊戲專案中的三股相互拉扯也相互制衡的原力。如何從中做出適切的取與捨，是遊戲專案製作人與管理者需要時時放在心上的重要課題。

最後，以遊戲開發的整體觀點來看：

遊戲開發三原力

• 技術 (Technology)：程式以及開發平台。
• 商業 (Business)：金錢、資源與時間。
• 藝術 (Art)：圖像、聲音、設計，以及遊戲整體的感覺。

在遊戲研發的專業領域中，為何我們經常提到的詞句是「遊戲開發」(Game Development) 而不是「遊戲設計」(Game Design)？因為在遊戲的領域中，除了「設計」這個比較引人矚目的面向以外，其實還有許多不可忽略也不該漠視的領域，所以如果只是單單使用「設計」一詞，並不足以完整表達出遊戲產業中的各種面向。

（圖片來源：http://www.freewebs.com/）

將視野放遠來看，商業遊戲的開發可以分為技術層面、商業層面以及藝術層面三種領域。技術層面可以說是「電子遊戲之所以成為電子遊戲」的基礎條件，同時也是相當注重工程原則與邏輯思考的面向；商業層面中包含了金錢、成本與時間等等一切有關於賺錢與賠錢的現實考量；藝術層面則包含遊戲中各種有形以及無形的東西，不論是看得見的圖像、聽得到的音樂或者是玩得到的遊戲性，都是屬於遊戲藝術的一部份。三個面向，三種領域，所需具備的專業知識與思維想法幾乎全然不同；而遊戲，就是工程、商業與藝術三者的完美結合體。

如果你的夢想，是想要做出驚天地泣鬼神的遊戲鉅作，那麼請先試著把自己的腦袋思維「三分天下」；工程、商業與藝術，一個都不能少，誰也不能忽略。如果你無法巧妙地把自己的頭腦分成三等分，或者無法在不同的時刻裡稱職地扮演不同角色，那麼請不要忘記伙伴的重要性。對於公司裡每個部門或者每個團隊中的成員，不僅只是做為公司員工 (Employee) 的身份而已，而應該把每個人視為可信任合作的伙伴 (Partner) 才是對遊戲開發有所助益的態度。

即使是想要成為海賊王的男人，船上也少不了大副、廚師、航海士、狙擊手與寵物（？）等等不同功能作用的伙伴，所以在遊戲開發團隊中，我們也需要信賴各個伙伴的專業能力，並且虛心接受他們的建言，才能夠齊心協力製作出充滿三原力平衡美感的好遊戲！套句《星際大戰》中的名言改編：May the Triforce be with you！

你是學生嗎？你渴望在畢業之後進入遊戲業界工作嗎？你抱持著滿腔的熱情，卻不知道如何替未來的自己做好準備嗎？這篇文章裡，將以我個人的經驗與心得，提供給有興趣進入遊戲業界的學生一些行前準備建議。因為我自己是屬於遊戲程式設計者的身份，所以這篇文章多數的內容是針對未來有志於成為遊戲程式設計師的大學生。在文章最後，則會稍微提到一些關於遊戲企畫設計者與遊戲美術設計者的面試加分項目。

對於有志成為遊戲程式設計者的人來說，大專院校中的資訊相關科系，如資訊工程、資訊科學以及資訊管理學系，可以說是最為接近遊戲程式設計的領域。雖然台灣目前已有幾間學校設立了遊戲設計學系，但是以成為遊戲程式設計者的目標來說，我認為選擇資訊相關科系仍然會是比較合適的決定。資訊科系畢業的學生，未來可以從事許多不同面向的工作，例如 IC 設計、韌體開發、軟體設計以及網路多媒體程式設計等等；而一般來說，相較於硬體與軟體產業，遊戲業界在考慮新鮮人的履歷表時，比較少有學歷面向的資格限制。

（圖片來源：http://www.rougarai.com/）

大學考試的錄取率年年昇高，至今年甚至已經達到 100% 的錄取率，如果你身為一位大學畢業生，在每年六、七月新鮮人開始投履歷尋找工作時，要如何從眾多的大學畢業生中脫穎而出？如何爭取到更多的面試機會與工作機會？又或者應不應該念研究所？要回答這些疑問，首先必須瞭解的關鍵問題是：「進入遊戲業界需要什麼樣的能力？」

基本能力，通常是工作應徵者的第一道關卡；如果連基本能力都無法滿足，很可能就無法得到面試以及工作的機會。在遊戲業界中，程式設計者所需具備的基本能力有兩項：

• 程式設計能力：必須熟悉 C++ 語言，真正瞭解虛擬與繼承的使用時機，能夠使用 STL 並且瞭解資料結構與容器，認識基本的設計模式 (Design Patterns)，並且具備優秀程式設計者的特質。
• 英文讀寫能力：能夠閱讀以英文撰寫的技術文件、國外討論區的文章，以及各種英文技術書籍，並且能夠撰寫簡單的英文句子與其他人進行討論。

通過以上兩項基本能力的門檻以後，接下來的關卡考驗則是專業能力的條件項目；依所學領域的分野，大致上可分為客戶端 (Client Side) 與伺服端 (Server Side) 兩大領域：

• 客戶端：具備 3D 繪圖領域的知識，至少熟悉 DirectX 或 OpenGL 兩者之一。瞭解基礎的 Windows 視窗程式設計，能夠使用 MFC 或 .NET 製作視窗程式，認識 Lua 語言。
• 伺服端：具備網路通訊協定與網路架構理論知識，熟悉 Linux 平台以及 GCC 操作，瞭解封包傳送、加解密與壓縮的方法，能夠使用 SQL 語法處理資料庫，認識 Perl 或 Python 語言。

瞭解上述的基本能力與專業能力項目之後，就可以開始思考念研究所是否對這些項目有所幫助了。在你的面前，有兩條岔路延展開來：

• 大學畢業，當兵，進入業界。
• 大學畢業，念研究所，碩士畢業，當兵，進入業界。

在這兩個選項之間，存在著時間成本以及機會成本上的差異。如果選擇第一條路，在讀完大學後直接投入遊戲界，優勢在於能夠及早接觸業界，學習成長的同時也為公司做出貢獻；有了現實層面的壓力，成長的速度往往遠勝於在學校的學習效果。只要能夠在一間不錯的公司裡工作，二年之內，就能夠熟悉各種遊戲開發的知識，進而成為優秀的遊戲程式設計者。而如果選擇第二條路，讀完大學後繼續就讀研究所，並且在二年後順利拿到學位證書，然後再進入遊戲界，優勢在於工作之後如果覺得不如預期，將比較有後路能夠轉向其他業界。然而，在碩士班裡，往往需要花費許多時間在畢業論文之上，而比較少有磨練程式設計能力的機會；在對於程式設計實作能力非常重視的遊戲業界中，這是比較容易使面試主管產生疑慮之處。

如果沒有仔細思考念研究所的目的為何，只是跟著其他人上補習班、考研究所然後念研究所。進入研究所後，只管挑選比較熱門的研究領域，或者比較輕鬆的指導教授，整天窩在研究室裡玩著連線遊戲，然後在二年級下學期才匆匆忙忙地開始著手動工撰寫論文，即使擁有了碩士學位也難以經得起時間與工作的考驗。博士畢業生，要有發現問題的能力；而碩士畢業生，應該要有獨立解決問題的能力，這才是碩士學位的價值所在。

如果你已經做出決定，確定要朝向碩士班的目標努力，除了考慮想要就讀的目標學校良窳與否的考量以外，最好能夠先確定指導教授的研究領域是否與遊戲開發有關連性；因為雖然資訊相關科系的研究所相當多，但是真正能夠稱得上與遊戲開發或遊戲程式設計相關的系所卻很少。以研究領域來說，與遊戲業界最為相關的應該是電腦圖學 (Computer Graphics) 以及網路理論 (Network Theory) 的相關領域。

在電腦圖學的領域中，可以學習到各種繪圖程序的基礎理論與知識，對於想要成為專攻 3D 程式設計的人來說很有幫助；另一方面，如果有志於開發伺服器程式系統的話，網路理論則是最合適的研究領域。此外，可能大部分人都會認為人工智慧 (Artificial Intelligence) 也是與遊戲製作非常有關連性的領域，然而人工智慧在國內遊戲界的應用非常少。國內的遊戲作品很少使用複雜的人工智慧技術，也鮮少使用模糊邏輯、類神經網絡、基因演算法之類的理論，所以目前能夠一展所長的機會並不多。

在資訊科系中，需要學習的課程科目非常多，同時也有很多的機會接觸各種不同的程式語言。各種程式語言都有各自的優點與缺點以及不同的學習曲線，雖然也有以 Java、C# 語言或者 Flash ActionScript 撰寫的遊戲，但是以遊戲界的現況來說，最首要、而且必須熟練自如的程式語言還是非 C++ 語言莫屬。而在資訊工程學系滿坑滿谷的課程目錄中，我會選擇資料結構、線性代數、離散數學與演算法這四門課程，做為最重要的學習目標。

（圖片來源：http://blogs.theage.com.au/）

需要特別注意的是，資訊相關科系的各種課程，與遊戲程式設計幾乎沒有直接的關連性存在。但是為了成為一位優秀的程式設計者，這些課程就像是紮馬步、練內功一樣，絕對是不可或缺的訓練過程。只是如果要學習遊戲程式的相關知識，就必須靠自己的努力，投入額外的時間閱讀書籍文章並且撰寫程式。另外，在廣告媒體上強力促銷的資訊證照考試，對於遊戲業界的工作，到底有沒有加分的作用？其實只要對照一下上述的基本能力以及專業能力列表，就不難理解這些證照的加分效果其實相當有限。

其他資訊產業的狀況我並不清楚，但以遊戲業來說，學歷多半只會在你尋找第一份工作時產生效用。當你在第一份工作裡持續二年以上的時間之後，未來如果轉換公司，面試主管更會注重的是你在前一份工作中所學習到的知識、所完成的工作項目，以及所獲得的知識經驗；所謂的學歷或者學位，已經變得微不足道了。反過來說，如果在第二、第三份工作面試時，還需要不時強調自己的學歷而非工作經驗，可能就會使面試主管產生疑慮了。

不論你是大學畢業生或者碩士畢業生，找工作與投履歷就是一種推銷自己的競賽，必須盡可能地展現出自己的優點，以及與其他競爭者的不同之處。如果能夠展示出與遊戲相關的作品、專題或者比賽成果，就能夠很快地吸引面試主管的目光而獲得更多的工作機會。現在各種與遊戲製作相關的活動及比賽越來越多，參加這些比賽，不僅僅只是為了豐厚的獎金獎品，在團隊合作的過程中所獲得的經驗，不論好壞，都是金錢難以比擬的無價收穫。

在這個人人都有部落格的年代裡，除了擁有記錄自己生活點滴的小天地之外，不妨另外開設一個專門的部落格，將自己對於遊戲程式、遊戲設計或者遊戲美術的相關文章、學習心得及個人作品，以文字、圖片或者其他的形式記錄下來。痛快地玩過一款遊戲之後，能不能以自己的觀點去剖析遊戲的設計？遊戲中使用了 Pixel Shader 或者哪些先進的繪圖技術？有什麼地方能夠更進一步的改善？這些都是非常好的自我訓練題材。幾年之後，部落格裡一點一滴的累積起來的內容，將會搖身一變成為你個人的王牌銷售員。（註：記得時常進行備份。）

即使你現在所就讀的科系，不是屬於資訊相關科系，平時也比較少有機會接觸程式設計方面的知識，轉個彎吧！別忘了還有很多的可能性，例如轉校考試、校內轉系、輔系申請、雙主修學位以及選擇相關學程等等方法。我自己是從大二時才開始學習程式設計與資訊領域的知識，直到大三才開始接觸遊戲開發的相關知識，大四時跑去修了幾門研究所與其他系所的課程。當時在網路上，有個人氣鼎盛的專業遊戲論壇「拿鐵遊戲研究院」，有許多業界的前輩在此分享程式、企畫與美術的相關心得。在參與討論的過程中，不僅使我學習到許多業界相關知識，瞭解未來前進的方向，也認識了引薦我進入遊戲業界的前輩。只要有心去做，就會找到方法而不是藉口。

除了國內的遊戲業界以外，或許你的目標更遠大，想要到美國的 Activision Blizzard 或者日本的 Square Enix 工作；目標不同，應該如何做準備？如果你想到美國的遊戲業界工作，最好的方式就是申請美國學校的研究所，直接攻讀相關研究領域的碩士學位。在畢業之後，就有比較大的機會能夠留在美國，並且得到遊戲業界的工作機會。如果你想到日本的遊戲業界工作，則需要先到日本念一至二年的語言學校，接著再去就讀遊戲開發的專門學校。但是一般來說，日本遊戲公司較為保守，並不會輕易接納非日本人擔任正職工作，請在做出決定之前仔細考量清楚。

除了以上關於程式設計者的準備方向以外，如果你的目標是成為遊戲企畫設計者，什麼科系畢業並不是很重要的因素；在達成遊戲企畫設計者的基本條件之外，如果懂得撰寫簡單的程式，或者熟悉美術的製作軟體，都能夠在面試中獲得不少加分。而對於遊戲美術設計者來說，展現出來的實力才是關鍵；看起來再怎麼高明的學位證書，也比不上眼見為憑的作品來得具有說服力。另外，美術設計的領域中，分成平面設計、動畫設計、多媒體設計等等不同的範疇，所需熟練的技能以及工具，與遊戲美術領域有所不同，在自我學習時需要多加留心。

我想應該有不少人是因為「喜歡玩遊戲」或者「對遊戲製作充滿憧憬」，當初才會選擇就讀資訊相關科系，從此與電腦結下不解之緣。如果你在經歷大一的程式語言課程後沒有放棄，在大二的數位邏輯課程後沒有轉向硬體之路，在大三的演算法課程後存活了下來，那麼恭喜你，已經獲得進入遊戲業界的門票了！接下來更要勤加練習程式設計的功力，努力充實各方面的能力，才能夠進入遊戲業界，成為一位合格的遊戲程式設計者！

（圖片來源：http://www.employmentspot.com/）

最後我想說的是，即使遊戲業界目前有許多令人不滿意的現況存在，即使目前的薪資待遇比不上電子產業，仍然有許多人默默地認真工作著，為了製作出好遊戲、為了讓公司能夠賺錢，也為了證明我們能夠做到。只要擁有熱情，就不會對自己失去信心。如果能夠在困境中闖出一條路，就可以獲得更大的成就與收穫！而對每位大學生來說，想不想、要不要，或者該不該念研究所，都有家庭、金錢與現實狀況等各種因素需要詳加考量，不論你所做的選擇是什麼，有句話說：「機會是留給做好準備的人。」當機會來臨時，你是否已經準備好面對挑戰了？Be Prepared！

（圖片來源：http://www.areait.info/）

「專案管理」聽起來是一個很酷炫的 Buzz Word，如果用一句《神奇寶貝》裡的名言比喻，專案管理就像是個「可愛又迷人的反派角色」一樣，經常讓人對它又愛又恨。在之前的「經驗與管理的迷思」以及「Peopleware：腦力密集產業的人才管理之道」這兩篇文章裡，已經討論過「人」這項因素對於開發團隊的重要性。然而在一個企業、公司或團隊中，如果只注重人的因素仍然是不足夠的，因為即使是能力再強的領導者或管理者，也無法一天八小時盯住每一項工作的執行細節。如果說在管理學中常聽到的「領導統御」是著重於「人」的層面，則「流程管理」就是著重於「事」的層面。良好的管理制度，將能夠補足「人」所力有未逮之處。

專案管理，最初由時間管理 (Time Management) 的概念衍生而來，而時間管理的概念則存在於我們每一個人的生活當中；當你身為一個學生的時候，如何管理一天的生活？如何管理二個月的暑假生活？如何管理一整個學期的生活？如果只是放任著時間流去，最後或許會發現自己什麼事情也沒有完成，什麼東西也沒有留下。對於遊戲開發來說亦然如此，專案的功能清單與臭蟲列表上，總是存在著難以計數的項目等待進行；有多少事情需要完成？有多少人手可以用？六個月之內可以看到什麼樣的成果？專案管理，必須要能夠妥善地回答這些問題。

舉個實際的例子，假設你身為一位程式設計者，在夙夜匪懈、含辛茹苦地讀完 C++ 語言、視窗程式設計與 DirectX 繪圖 API 之後，終於能夠開始動手寫遊戲了！一開始，目標不要訂得太高，先從 2D 的小小遊戲開始好了。首先確立了遊戲的玩法與各項設計要素後，就可以準備開始寫程式了！但是在真正動手寫程式之前，總得先有個目標與方向，列出遊戲中各項必須具備的功能系統：

• 繪圖系統
• 音源系統
• 特效系統
• 角色系統
• 操控系統

嗯，看起來很不錯，已經把一個小遊戲所需完成的基本系統全部條列出來了。然而，這些項目的定義，對於工作的執行者來說，太過於模糊而簡略；例如其中的「角色系統」究竟指的是角色的動作系統，還是角色的屬性系統？角色有沒有包含怪物的相關功能？為了釐清這些問題，我們必須進一步地將這些系統大項，分解成為比較詳細的功能小項：

• 繪圖系統：
  • 2D 圖件功能
  • 背景圖件功能
• 音源系統：
  • 音效播放功能
  • 音樂播放功能
• 特效系統：
  • 圖片半透明效果
  • 淡入淡出效果
• 角色系統：
  • 角色動畫功能
  • 怪物 AI 功能
• 操控系統：
  • 鍵盤輸入功能
  • 滑鼠輸入功能

這種由上而下分解的階層架構 (Top-Down Hierarchy)，讓我們能夠將原來不知如何下手的「遊戲系統」這個龐然巨物，一層層分解為可對付的任務。如果目前的清單仍然過於模糊不清，也可以繼續往下分解，直到階層架構能夠清楚傳達每項工作的意義為止。經過階層分解所得的這份清單，也就是所謂的 To Do List（待辦項目清單），理論上我們只要把上面所列出來的項目通通完成，第一個自己製作的遊戲就大功告成了！

然而，除了工作項目以外，另一項不能忽略的程序，就是估算每個工作項目所需的執行時間：

• 繪圖系統：
  • 2D 圖件功能：16 小時
  • 背景圖件功能：12 小時
• 音源系統：
  • 音效播放功能：8 小時
  • 音樂播放功能：8 小時
• 特效系統：
  • 圖片半透明效果：12 小時
  • 淡入淡出效果：16 小時
• 角色系統：
  • 角色動畫功能：24 小時
  • 怪物 AI 功能：24 小時
• 操控系統：
  • 鍵盤輸入功能：8 小時
  • 滑鼠輸入功能：8 小時

在遊戲專案的計畫中，有了系統功能的細節項目，以及每個工作項目的執行時間之後，接下來就能夠排定各個工作項目的執行順序。排定工作的優先順序，需要取決於每個項目的關鍵性、重要性以及項目與項目之間的相依關係；以這個例子來說，特效系統中的半透明功能與淡入淡出功能，都需要等待繪圖系統完成後，才有辦法開始動手進行。

經過優先順序排列之後的工作項目列表，如下所示：

• 操控系統：
  • [1] 鍵盤輸入功能：8 小時
  • [2] 滑鼠輸入功能：8 小時
• 繪圖系統：
  • [3] 背景圖件功能：12 小時
  • [4] 2D 圖件功能：16 小時
• 角色系統：
  • [5] 角色動畫功能：24 小時
  • [6] 怪物 AI 功能：20 小時
• 音源系統：
  • [7] 音效播放功能：8 小時
  • [8] 音樂播放功能：8 小時
• 特效系統：
  • [9] 圖片半透明效果：12 小時
  • [10] 淡入淡出效果：16 小時

在此我會將操控系統列為製作遊戲的第一優先選擇，因為有了鍵盤與滑鼠的輸入功能，將會比較便於後續的開發與測試程序。接著要在畫面上顯示出東西，所以必須完成基本的背景圖件與 2D 圖件功能；有了圖件功能後，就能夠接著進行角色與怪物動畫的功能製作。完成以上主要的功能項目後，再繼續製作與其他系統比較沒有依存性的音效與音樂功能。為什麼把半透明和淡入淡出效果排在最後的順序？因為這兩項都不算是遊戲中的「必要」(Must-Have) 功能，而是「有也不賴」(Nice-to-Have) 的附加功能；雖然能夠使畫面更美觀，不過並不是非完成不可的功能。

以上，就是一個以程式設計者觀點出發的「遊戲專案時程」計畫程序。

在一個完整的開發團隊中，專案的時程安排與進度管理狀況往往比上述的例子複雜許多。一般來說，專案管理者會將每位工作者都視為一項可分配使用的資源 (Resource)，完成一項工作則需要 1 至多項不同的資源配合。而每個人與其他人之間，幾乎都會存在著某種程度的依存性 (Dependency)。例如，我所預計進行的這項工作，需要等待美術同仁的建模工作完成後才能夠開始；或者是程式的紙娃娃裝備功能，除了企畫的裝備部位設定資料以外，還需要先拿到美術的裝備模型與貼圖檔案，才有辦法進行實際測試。

工作項目與工作項目之間，存在依存關係，而工作者與工作者之間，同樣也存在著依存關係。程式設計者與程式設計者之間，需要彼此合作，因此難以避免地會有彼此間的依存關係存在，而對於企畫與美術設計者來說亦然如此。所以如果專案中的時程沒有安排妥當的話，將很有可能造成專案進度的延誤，或者是某些人做得要死，另外一些人卻閒置無事的糟糕情境。

正因為工作項目依存性的緣故，團隊中的專案時程，就像是一張錯綜複雜的蜘蛛網。專案管理者必須從中訂定出專案執行的關鍵要徑 (Critical Path)，確定哪一些項目才是最為關鍵的部分。如果以 RPG 的術語來比喻，關鍵要徑就像是遊戲中的主線任務；不論你的支線任務解了成千上百，如果不完成主線任務，故事劇情就無法推展下去，也就自然無法打倒最終魔王，並且看到美好的結局動畫與遊戲成品。

如果你現在只是一位單純的美術設計者、企畫設計者或者程式設計者，沒有身負管理職務的責任，或是對管理職務沒有半點興趣的人，可能會想問：「專案管理又與我有什麼關係？」其實專案管理的重要性，就如同每個人自身的時間管理一樣，正確的時間管理，可以讓一個人活得充實而滿足，而正確的專案管理，則能夠讓專案健康地成熟長大。不是因為學會專案管理，就可以當主管，然後可以管理一堆下屬員工。專案管理的出發點，在於幫助我們解決問題、達成目標，然後得以順利地完成專案。

身為業界中的小小工作者，我們或許偶爾都會抱怨：「為什麼總有開不完的會議、做不完的報告加上寫不完的文件？為什麼除了『做遊戲』之外，還需要做這麼多繁雜又無趣的事情？」如果能夠從專案管理的觀點來思考，就會清楚瞭解良好的管理制度可以幫助我們更加順利地執行專案，讓專案能夠早日完成並且順利上市，接著大紅大紫，最後賣到翻掉。專案管理能夠幫助團隊，迅速且有效地檢視目前的各項執行狀況、提供統計數據，並且找出潛在的問題；反之，如果在進度執行之後的數個星期、甚至數個月之後，才發現專案中的天大問題，此時縱使管理者突然腦袋開竅、大徹大悟，可能也早已造成難以挽回的慘烈局面了。

如果與其他產業相比，遊戲產業與傳統製造業或高科技製造業所需使用的管理方法，可以說是大相逕庭。我們可以訂立出非常嚴謹的 SOP（標準作業程序），每個人的每一項步驟都按照標準程序操作；然而即使從頭到尾每一項步驟都執行無誤，生產出了一件合格的商品，也無法保證最終所產出的成果，是一件「好玩」的遊戲成品。再者，即使這次花費了 18 個月、500 萬美金與 30 人團隊，成功了做出一套銷量百萬的遊戲大作，同樣無法保證能夠在相同的條件下，達成一樣的成功結果。

為什麼？

因為，「Creating fun can not be planned」；因為遊戲產業與其他產業不同之處，就在於「創造樂趣的時程難以管理」；也正是因為「樂趣無法規劃」的因素，所以遊戲產業不能夠與軟體產業劃上等號。這也是為什麼多數的遊戲專案，幾乎都會遭遇某種程度的進度落後與時程延遲的主要原因。所以如果身處上位的老闆與管理者，以為能夠複製別人成功的模式、複製自己過去成功的方法，或者是以製造業的思維來治理公司或者管理遊戲專案，都很有可能使得團隊陷入危險的處境中，專案的完成之日自然也遙遙無期。

（圖片來源：http://www.pigs-in-lipstick.co.uk/）

然而，做為遊戲的開發者以及員工的身份，我們無法對著老闆與發行商說：「因為樂趣無法規劃，所以專案進度勢必要向後延遲 N 個月！」在遊戲業中，只有這麼一間 id Software，能夠在發行商詢問遊戲何時完成時說出「It’s done when it’s done.」這樣豪邁爽快的話。也只有受萬人景仰膜拜的 Blizzard Entertainment（現已合併成為 Activision Blizzard），可以在公布遊戲影片的十數個月之後才正式釋出，同樣能夠賣破數百萬套以上的遊戲。所以，做為大大業界裡的小小公司、小小主管或者小小開發者，我們必須努力地找出時間、預算與品質三者之間的平衡點以及折損點。

有的老闆或者主管，喜歡三不五時在辦公室裡走來晃去地「巡視」員工的工作情形，我想這應該是大部分人都不願意使用的「專案管理」形式。以專案管理之名，不論是要以紙本的方式或者以電子檔案的方式指派任務，不論是要由工作者主動回報進度或者被動地由主管詢問進度，管理者都需要時常反省現行制度的真正用意為何，才不會使原來是一番美意的良好制度走了調，反而成為徒具形式的惱人雜務。如果各種文件、方法與手段，不能夠有效地幫助我們達成目標，產生出更好的成果，就毫無意義可言了。

專案管理到底在管些什麼，你是否已經有了答案？ ：P

在遊戲專案的開發過程中，除了排定工作項目之外，還有許許多多需要進行的流程：要由誰來估算工作時程？要怎麼估計某個工作項目需要花費多少時間？怎麼估算比較準確？如何驗證進度與成果？如何考評工作績效？下篇文章裡，將繼續探討與工作時程相關的主題。

首先必須澄清一個觀念：本文中所提的 Casual Game，不是一般玩家所熟知的「休閒類型線上遊戲」，如《勁舞團》、《網球拍拍》、《跑跑卡丁車》或《全民打棒球》等等。國內的遊戲業界與玩家，對於「休閒遊戲」存在著某種程度上的誤解，經常聽到許多人認為只要是非傳統 RPG 類型的 MMO 遊戲，就可以歸屬於休閒遊戲的範疇中；但是我們如果以玩家客群市場的角度仔細觀察，可以發現這個定義並不是很恰當。

所謂的「休閒玩家」(Casual Gamer) ，是在最近五、六年之內才興起的專有名詞，用來對比於核心玩家 (Core Gamer) 與硬派玩家 (Hardcore Gamer) 之外的一種玩家類型；而針對於休閒玩家所開發製作出來的遊戲，很自然地就被稱為休閒遊戲 (Casual Game)。在英文原意中，Casual 有「非正式」與「漫不經心」的意思，將 Casual 一詞翻譯為「休閒」，是一個不完全正確但最接近於原意的翻譯。而在本文中，我將「休閒遊戲」定義為：

專為休閒玩家量身訂製，主要於 PC 與 Mac 平台上販售的單機遊戲。

只是，達到這樣的條件就能夠稱做休閒遊戲嗎？所謂的休閒玩家指的是哪些族群的人？休閒遊戲又有什麼樣的獨特樂趣與玩法內容？

休閒遊戲的主要市場客群以成年人為主，更精確一點地來說，是以 30 至 60 歲的女性為主要客群。從 Real Arcade 公司對他們的玩家客群所進行的調查結果中顯示：女性玩家約佔了休閒遊戲人口中 71% 的比例，而其中有 37% 為 35 至 49 歲的女性，28% 為 50 至 60 歲的女性。由以上的數據可知，休閒遊戲的客群市場與一般 PC 平台上的遊戲，有非常巨大的差異性！而全球休閒遊戲市場的產值，由 2002 年的 2 億多美金逐年向上攀升，到了 2007 年已經突破了 10 億美金，並且仍然不斷地持續成長。

休閒遊戲在歐美地區的遊戲市場已行之有年，幾間主要的遊戲龍頭發行商 (Publisher) 包括 PopCap Games、Big Fish Games、RealArcade、Reflexive Arcade、PlayFirst、Sandlot Games 等等。而在台灣地區的 Yam 天空遊戲以及 Yahoo! 奇摩 Boonty 機台遊戲網站，已有代理販售部分比較熱門的休閒遊戲。在國外的遊戲發行商網站上，可以發現他們大多不以 Casual Game 來稱呼休閒遊戲，取而代之的名詞則是 Downloadable Game、Arcade Game 或是單純的 PC/Mac Game。因為絕大多數的休閒遊戲，都是採用網路下載形式販售，不存在實體於通路中，所以早期的休閒遊戲經常被稱做 Downloadable Game。而在休閒遊戲市場中，也很廣泛地使用共享軟體 (Shareware) 的模式，先於網站中釋出有時間限制的 Trial 版本，供玩家們在購買遊戲之前先行試玩。

目前在休閒遊戲市場中，比較熱門的遊戲類型大致可以分為以下四類：

• Match 3：排列三個以上的相同元素，即可消除障礙、通過關卡或者獲得分數的遊戲類型；著名的遊戲有 《Bejeweled》與《Zuma》等等。
• Click / Time Management：以滑鼠點擊的方式，平行管理許多同時發生的遊戲狀態；著名的遊戲有《Diner Dash》、《Cake Mania》等等。
• Hidden Object：按照關卡所列出的英文單字或其他提示，於場景圖片中找出正確的對應物品；著名的遊戲有《Mystery Case Files: Ravenhearst》、《Dream Chronicles》等等。
• Simulation：以模擬或策略要素為主，需妥善分配遊戲中的各種資源以獲取最大化的利益；著名的遊戲有《Virtual Villagers》、《Democracy》等等。

在那個 PC 單機遊戲蓬勃發展的年代裡，初出茅廬的休閒遊戲，正摩拳擦掌地準備大展身手。從最早的方塊消除類型的遊戲開始，包括《MSN 寶石方塊》、《動物園管理員》與《Bejeweled》系列作品在內，休閒遊戲就這樣慢慢地打入另外一批遊戲玩家的心中。我自己則是從前幾年轟動一時的「青蛙吐珠」《Zuma》遊戲開始，才逐漸進入了 Casual Game 的新世界。這款由 Popcap Games 所推出的《Zuma》，雖然本質上仍然屬於 Match 3 類型，但是遊戲把原有的方塊換成了圓球，也將原來的固定流動方式轉變為曲線流動的行進方式，以嶄新的外貌包裝，顛覆了傳統的方塊式消除遊戲，帶給玩家全新的樂趣，以當時來說，的確是一個相當了不起的遊戲創意成品！

而正所謂江山代有才人出，繼風靡一時的《Zuma》與其他相似作品紛紛問世之後，在休閒遊戲市場上，又出現了《Diner Dash》與《Cake Mania》兩款極為優秀的新型遊戲。這兩款遊戲，結合了簡單又具挑戰性的滑鼠點擊操作，以及經營餐廳與蛋糕店的主題，很快地在全世界掀起一陣旋風，長期佔據銷售排行榜的寶座達數個月之久。而自 2007 年以來，休閒遊戲市場又開始由前幾年盛行的 Match 3 與 Click Management 類型，逐漸轉換方向至 Hidden Object 的遊戲類型上發展。Hidden Object 經常會以扣人心弦的故事背景，搭配高畫質與高精細度的圖片，引領玩家進入遊戲製作者所精心打造的世界之中。

如果以身為玩家的角度仔細觀察，可以發現休閒遊戲具有幾項獨有的特質與樂趣：

• 遊戲多以 2D 表現方式為主，畫面元素簡單易懂。
• 操作方式直覺易上手，多數遊戲甚至只需要滑鼠單鍵操作。
• 每個關卡的進行長度約 10 至 20 分鐘左右。
• 遊戲過程中，可以隨時暫停、中斷以及記錄遊戲進度。
• 遊戲的總長度少於 20 小時。
• 遊戲的檔案容量小，便於使用網路下載。
• 遊戲售價低廉，一般約在美金 19.95 元左右。

而以遊戲開發者的角度來看，休閒遊戲的研發領域擁有以下的特性：

• 低開發門檻。
• 低製作成本。
• 低技術風險。
• 所需團隊人數少。
• 不同面向的技術考量與設計挑戰。

若以身為開發者的角色仔細考量，休閒遊戲與一般的 PC 平台遊戲，其實存在著相當大的差異性；程式設計者不可以再使用絢爛的 3D 成像技術，美術設計者不需要再雕刻出栩栩如生的模型貼圖，企畫設計者不能夠再架構出龐大繁複的遊戲系統與機制。相較於一般 PC 平台上的商業遊戲，多數著力於製作華麗的物件光影、材質貼圖與 Shader 效果，對於休閒遊戲來說，最重要的是盡可能地降低系統需求配備。如何使遊戲在千變萬化的硬體組合、軟體系統中都能夠正常運行無誤？相容性，絕對是開發休閒遊戲的第一考量要項。而也因為上述這些考量，使得休閒遊戲的開發工具除了傳統的 C++ 語言之外，還存在著更多不同的選擇。例如 Flash、Director、Java，甚至是 RPGMaker 與 Torque Game Builder，都有被拿來當作休閒遊戲的程式開發工具，實際完成商業化的遊戲作品。對於遊戲開發團隊來說，休閒遊戲市場可以說是一項全然不同的另類挑戰。

當然，休閒遊戲的現狀並非全然如此美好。除了單機遊戲必然會面臨的非法下載問題以外，嚴重的遊戲 Clone 量產，也是休閒遊戲業界必須正視的挑戰。以《Zuma》為例，在這款遊戲爆紅之後，很快地市場上就出現了許許多多的複製遊戲，於是玩家們不止能夠看到青蛙吐球，更可以玩到瓢蟲吐球、平台吐球、神龍吐球等等列舉不盡的例子，共計約有二、三十款非常相似的遊戲。這些大量氾濫的複製作品，對於休閒遊戲的開發者與玩家，都會造成負面的衝擊與傷害。

近幾年來，由於 NDS 與 Wii 平台的迅速崛起，不僅使玩家們認識了遊戲的不同可能性，同時也打開了遊戲開發者們的眼界。再加上各家遊戲機廠商推出的遊戲下載服務平台，又更進一步地開拓了休閒遊戲的勢力範圍。而近來在休閒遊戲市場上，也出現了更多混合型態的嶄新類型，例如將傳統 RPG 要素結合 Match 3 玩法，在各個硬體平台上都頗受好評的《Puzzle Quest》。歸納以上種種因素，全都使得傳統遊戲與休閒遊戲之間的分水嶺越來越難以捉摸。儘管如此，如果能夠以玩家客群的特性進行分析，應該比較能夠掌握住玩家市場的脈動。關於休閒遊戲的定義，之前曾經看到一段令我印象非常深刻的敘述：

The real difference between gamer types is how they view pastime. Serious gamers see it as their chief source of entertainment; casual gamers do not.

「關鍵就在於我們怎麼看待自己的休閒娛樂。」對於核心玩家與硬派玩家來說，遊戲就是主要的娛樂來源，然而對於休閒玩家來說，遊戲並不是生活中的重要角色；或許只是各種娛樂活動之一，或許是可有可無的小配角，或許可被其他人事物所取代。我們應該如何滿足這種類型的玩家？這是遊戲開發者的機會，也是遊戲產業能夠繼續努力的地方。在休閒遊戲的領域中，真正有趣的課題在於如何設計出真正為女性，而且是專為成熟女性所打造的遊戲。這也是為什麼經常會在休閒遊戲中，看到經營餐廳、寵物店、美髮店、蛋糕店之類主題的原因。不論你是女性或男性的遊戲企畫設計者，是否能夠真正以女性的需求角度出發，設計出她們所喜愛的遊戲類型？

如「Why We Play Games: Four Keys to More Emotion Without Story」這篇文章所提到的內容，人們玩遊戲的目的，有時是為了轉換自身所處的狀態 (Altered States)，或者也可以說是一種逃避主義 (Escapism)，暫時將我們從紛紛擾擾的現實中拉出，進入一個充滿無限想像與自由的夢幻國度中。手上握著滑鼠拖移方塊、瞄準彩球、點擊東西，腦袋裡沒有任何複雜的思考程序，讓自己成為了近似直覺性的動作反應。而藉由這樣化繁為簡的「儀式」，或許也是一種放空自我的好方法。

有時候，玩家可能只想一個人靜靜地玩遊戲，不需說話、不需打字，更不需要和別人爭個你死我活。畢竟，有了工作、有了家庭，或者有了其他負擔以後，就無法經常花費數個小時以上的時間，全神專注於遊戲世界之中。那些 PC、PS3 與 XBox360 上的遊戲大作都非常地吸引人，但是除此之外，難道我們就沒有其他選擇了嗎？從前那個世代的玩家，包括我自己在內，都已經逐漸長大成人，出了學校開始工作以後，得到許多金錢自主權的同時，可能也失去了更多玩遊戲的自由時間。或許有一天，原本死忠硬派的超級玩家，也有機會「轉職」成為休閒玩家。

在我踏入遊戲業界之前，對於 Casual Game 的遊戲市場完全沒有概念；直到兩年多前，在偶然的機會下接觸了休閒遊戲以及相關的開發知識，然後就持續關注著 Casual Game 的市場發展與開發技術至今。自去年開始，甚至連 EA 這樣的巨型公司，也宣布將踏入休閒遊戲的市場以拓展全新的玩家客群；但是像 EA 這樣巨獸級的大公司，多已習慣了大成本、大團隊與大製作的遊戲作品，反而比較不利於分配資源在這種中小型的利基市場中，在這種態勢之下，小型的遊戲公司，反而有較佳的反應能力與發揮空間。

在已經戰成一片紅海的遊戲產業中，與現存公司的最佳競爭方式，就是改變遊戲規則——Change the Rules。休閒遊戲市場的新契機，你心動了嗎？

小謎題：猜猜看世界上玩家數目最多的 PC 平台休閒遊戲是哪一款？