「閱讀選錄是什麼鬼？」

關於猴子靈藥的「閱讀選錄」分類下的文章，目前總共包括「遊戲業界閱讀」、「遊戲程式閱讀」、「遊戲設計閱讀」、「遊戲美術閱讀」與「遊戲開發閱讀」五類。請注意，在這個分類底下的文章，全部都不是由我自己原創撰寫的內容，而是來自國外遊戲開發網站的優質專業文章。

在撰寫閱讀選錄文章時，我會盡最大努力將文章中的關鍵要點，詳細地用中文轉述解釋，但並不會依照原文逐字逐句地進行翻譯。在每篇閱讀選錄的第一行，我一定會先附上原文的文章名稱與網址連結，而在翻譯文章時，我會使用自己慣用的名詞語句，例如將「Designer」翻譯為「企畫設計者」、「Artist」翻譯為「美術設計者」，「Programmer」翻譯為「程式設計者」等等。除此之外，在一些比較難以傳神表達原文意義的字句中，我會以刮號附註原文名詞，或是節錄一部分原文句子的方式呈現出來。

「所以這是文章翻譯嗎？」

是，也不是。如前所述，這並不是百分百完整的文章翻譯，有些原文寫作風格較為口語化，有些字語詞彙較為艱深難懂，所以我會依照自己的個人偏好以及對於題材的熟悉度，僅摘錄翻譯其中部分的內文。因此，如果你期望讀到最完整也最原汁原味的文章內容，我建議閱讀原文會得到更多的收穫唷！另外，除了原文的段落以外，我也會將文章所述的內容，與自己在業界的經歷相互印證，然後在文章裡撰寫一些自己的心得與感想。至於哪一段是原文，而哪一段又是我自己增加的補充心得，我不會特別標示出來，需要請各位自行查閱原文了。請體諒我的一點小小任性。

「為什麼要做閱讀選錄？」

因為我爽。講得更明確一點，是因為我喜歡做這件事。閱讀，原本就是一件很過癮的事情，每每讀到一篇好文章，總會使我有醍醐灌頂與豁然開朗的感受，如果能夠將這份充滿喜樂的滿足感與更多人分享，豈不是一件更加痛快的事情？雖然可能需要閱讀完十篇文章，才能夠選出一篇值得翻譯的文章，雖然翻譯一篇文章所需花費的時間，超過閱讀一篇文章所需時間的十倍以上，但我認為，光是閱讀並不能夠使我真正瞭解作者原文的精華內容，唯有透過自己的筆調用心詮釋，才有機會將這些東西化為自己的靈魂血肉。

所以結論是，「閱讀選錄」不是翻譯文章，而是翻譯文章加上閱讀心得，也是經過咀嚼消化之後反芻出來的產物，可能會有些黏乎乎地，外表看起來也不太可口，如果各位朋友及讀者發現文章裡有詞不達意或者不太通順的段落，都非常歡迎提供更好更流暢的翻譯，將來我才能夠呈現出品質更好的文章。

最後，在目前共 30 篇的閱讀選錄中，我挑選出幾篇自己很喜歡的文章，推薦給每一位熱愛遊戲開發的遊戲人：

• 《Statistically Speaking, It’s Probably a Good Game, Part 1》：遊戲設計者的基礎機率入門
• 《The Code/Art Divide: How Technical Artists Bridge The Gap》：技術美術設計者，為您搭起團隊的橋樑
• 《How Mega Man 9 Resembles… Real Life?》：那些洛克人教我們的事
• 《Flagship Founder Bill Roper Interview》：地獄之門崩壞，旗艦之夢沈沒
• 《How to Prototype a Game in Under 7 Days》：如何在七天內完成遊戲原型
• 《Postmortem: RiverMan Media’s MadStone》：奉獻、持續，以及無與倫比的熱情

Let’s read, write and share!

（圖片來源：www.cals.ncsu.edu）

原文出處：Game Artists: The Three Cardinal Rules

這是一篇專為遊戲美術設計者所寫的文章，同時也是一篇對所有遊戲業界從業者很有幫助的文章。

在這篇文章裡，作者提出了三項最基本也最重要的準則：自我意識管理、專業面向的溝通，以及接受多樣化任務。其中，佔最多篇幅的內容在於專業溝通的議題上。多數人都知道「溝通」非常具有重要性，但是在現實生活與每天的工作中，到底該怎麼做才能達到良好的溝通成效？該用什麼樣的態度與主管溝通？該用什麼樣的方式與同儕溝通？要如何說話提問，那些該死的企畫設計者與程式設計者才聽得進去？本文為遊戲美術設計者，提出幾項實用而懇切的溝通要領。

本文作者 Keith Self-Ballard 從普渡大學 (Purdue University) 的電腦繪圖技術系畢業後，旋即進入遊戲產業工作。目前他在遊戲公司裡擔任美術部門主管的職務，也同時兼任母校的業界諮詢委員。去年，電腦繪圖技術系的教授向他詢問，是否能夠提供一些給美術設計者的小提示，讓學生們能夠瞭解什麼是他們必須學習與追求的東西。

這是個令 Keith 十分感興趣的議題。十年多以前，當他剛進入遊戲業界時，對於如何成為專業的遊戲美術設計者，他只有非常非常稀少而有限的認識。當他學習到新的工具與技術之後，同時也發展了自己的知識，瞭解該如何與同儕以及領導者協同合作，在製作過程中解決問題，並與各種不同類型且擁有獨一無二特質的人共同工作。

在那個時候，Keith 也在自己專業工作上犯了一些錯誤。我們每個人都會犯錯，幸運的是，他犯的錯並沒有糟糕到使他的業界生涯終止的程度；其中大多數的錯誤，應該都是剛進入業界的新血員工容易犯的那種錯誤。這些年來，不論是對於自己或者他人所犯的錯，Keith 繼續以這些錯誤行為做為自己的警惕，並持續地觀察這些錯誤所造成的衝擊與影響。

當他在兩年多前成為管理階層的一員時，他開始面對關於美術設計者的成員管理、人才招募，以及個人績效評量等各種事務。正因如此，他熱切地想要識別出對專業美術設計者的共通期望。於是，他開始研究遊戲業界對於美術設計者，究竟保持著什麼樣的期望。最終他想要獲得某些具體的東西，使他能夠與美術設計者分享，並對於那些直接從教育機構進入業界的新血，或者從其他業界進來而不夠清楚瞭解準則的員工，能夠用來做為一項訓練輔導工具。

令人驚訝的是，Keith 發現在這方面有所著墨的文章極少。多數文章不是講得太過於廣泛，就是太過於專注在細節之上。由於在這個主題上，缺乏足夠份量的文獻研究，他必須以其他方法建立這些專業指導準則。除了他自己的個人經驗與觀察以外，他也向其他專業同仁徵求意見，另外與其他遊戲工作室的美術指導者以及遊戲製作人請教，也與幾個不同的教育機構的職員討論，最後則和遊戲業界之外的資深美術設計者討論，一切只為了找出這些實例中的一致性或不足之處。

最終，在 Keith 回覆給教授的清單裡，鉅細靡遺地列出了超過 30 項條目。其中比較關鍵的項目，包含自我意識的管理、與同儕間的相處、面對工作任務的態度，以及如何學習積極溝通等等。而在這篇文章裡，他將原先所列的 30 項條目，濃縮成三大項最一致化也是優先權最高的專業準則。期望這些內容不僅能夠做為新血美術設計者的指引，同時也可以提供老手美術設計者一些值得思考的營養補給品。

1. 管理你的自我意識 (Managing Your Ego)

這是 Keith 在原回覆信件中排名第一的首要準則，而他現在依舊認為在任何關於專業美術設計者的討論中，這個項目應該佔有最高的優先順序。自我意識是一個複雜的議題，不論你的職業為何，它都會對於你個人的職業生涯以雙面刃的方式運作著。他認為美術設計者，是特別容易受到自我意識效應影響的人。

首先，我們應該先釐清「自我意識」的意思。在專業面的意義上，自我意識代表一個人對於自己的工作的認同感，也是對於自己的作品所擁有的關心；就某種程度上來說，自我意識也是使一個人能夠繼續增長自己的技巧與才能的動機。在這個面向上，自我意識能夠以「對動機與靈感的正面力量」角色存在而良好運作著，同時對自己產生影響也對其他人產生影響。

然而，自我意識的確需要被管理。如果疏忽而未加抑制的話，自我意識同樣會在你自己身上以及你的工作環境中，產生有害的影響力。如果放任自我意識恣意而為，原來對於「個人工作」的驕傲感，有可能會隨著時間逐漸轉移成對於「個人」的驕傲感或自己應得的特權，而這種個人的驕傲感，在每個人的工作關係中，的確會擁有最具毀滅性的衝擊力。

（圖片來源：www.insideoutshop.de）

個人驕傲就像是一條滑坡，可能會導致美術設計者看不起他們的同儕，認為其他人比較沒有價值或是比較沒有才能。因此，他們便會停止給予具有建設性的意見回饋給那些他們認為較沒有價值的人。而同儕間的意見與回饋，卻是對於成長中的美術設計者來說，最為關鍵重要的事物之一。

以上種種觀察，對於那些身為專業美術設計者而無法管理自我意識的人，令人想到兩種可能的結果：其一，無法或不願管理自我意識的美術設計者，很少能夠達成他們最高的創造潛力。當他們的態度趨於疏遠他人的時候，他們也關閉了創造性輸入的渠徑，因而限制了自己的潛力與成長空間；其二，遊戲業界可能會慢慢地淘汰這一種類型的人。

在超過十年的業界生涯中，Keith 所認識的那些最有才華與最有成就的美術設計者，絕不會讓自我意識或特權以任何方式危害他們的成長，他們總是會非常細心地照顧他們的藝術技能。無法掌控自我意識的美術設計者，不僅冒著傷害自己聲譽的風險，更會損害自己的職業生涯。

2. 專業面的溝通 (Professional Communication)

專業溝通的重要性應該很易於理解。當我們創造的產品在規模與複雜度上增長時，我們的製作團隊人數也會跟著向上攀升。積極溝通，將會對於團隊的執行效能有直接且立即性的衝擊。

對照來說，如果未能有效溝通，將可能為團隊帶來最高昂的代價。關鍵點取決於互動方式的效能，就像許多人所說的一樣，你所使用的溝通風格，應該要隨著你的目標聽眾而轉換。在接下來的幾個段落中，將討論三種不同類型的聽眾與溝通方式：

• 與同儕的溝通

  這裡所謂的「同儕」，特別指的是其他的美術設計者。美術設計者對美術設計者之間的溝通，最簡單的例子，就是學習與教學。因為學習與教學需要持續不斷地互動與刺激，它們通常也是最難維持的事情。多數時候，任務期限與工作時程的重擔，會阻礙這些具有生產力的知識交流行為，然而它們的重要性絕不會因此而減退。

  維持這些溝通管道的第一個步驟是經由「分享」。多數的美術設計者，都知道多種方法能達成相同的目標，或許是不同的工具，或許是不同的技術。即使像是使用熱鍵這樣簡單的事情，其重要性也經常會被忽視，但這些知識交流卻能夠對於你周圍的美術設計者，造成立即性的正向衝擊。強烈的美術設計者文化，正建基於這種彼此參與的程度上。

  然而，現實是這項動力在每一位美術設計者「自己」的身上。如果美術設計者們不願意投入其中，管理者或領導者也無法創造出這樣的環境。值得悉心留意的是，請記得分享你所知的知識，並且從其他人身上學習。身為美術設計者，這種知識交流對於你的個人成長非常緊要。其中有許多機會，將會來自於美術的檢閱過程或是具建設性的批評，如果想要獲得更多，你自己就需要奉獻更多。

• 與管理者及領導者的溝通

  就像稍早前曾提過的，製作團隊的規模不斷地增長，也意味著我們需要更多有能力的管理者。而如果管理事務也跟著增長，那幾乎可以確定，你將會需要更頻繁地與你的領導者與管理者們進行互動。從一個遊戲工作室到另一個，任何團隊的組織結構都不會相同。一個常見的思路是，人們似乎認為管理者和領導者絕對不會犯錯；他們可能不會說出口，或者正好相反，但通常他們的行為已經揭露了他們的心態。

  簡單的事實是，你不會同意管理者或領導者所做的每一項決定。這樣沒問題。不能接受的是，當他們看見一個錯誤或問題出現在地平線上時，卻理所當然地以為他們不能說出口。Keith 把這種情形稱呼為具有「沈默習俗」(code of silence) 的環境，它可能起源於許多不同的因素，包括害怕因為指出問題點而被駁斥，或者會遭受某種形式的懲罰。

  不幸的是，這樣一來負責製作產品的美術設計者，也是每日從事大多數工作的人，將會與發生在他們周圍的決定變得疏離。他們能夠預知那些可能發生的問題，但卻選擇不說出口而且不提供建議。在這樣的環境中，這些人同樣該為「因不行動而產生的失敗」受到責備。

  真正的事實是，管理者與領導者需要倚賴他人提供的意見做出決定——或者至少他們應該這麼做。因此，幫忙辨別問題就是身為產品製作美術設計者的責任。採取積極的步驟去發現問題，遠有利於已成事實後才對問題做出反應。

  然而，指出問題是容易的，但管理者與領導者們應該會同意，只是說出某件事情有問題存在並不足夠。所謂「發現問題」的最關鍵要素，就是推薦合理且適宜的解決方案。對許多美術設計者來說，這也是最困難的一步。「你打算如何防止問題發生？採取你的替代方案有什麼好處與風險？這是一個合理適宜的計畫嗎？」這些對話，需要在你與你的決策者之間被揭露。

  另一項值得警惕的是在討論問題時的態度。有些人覺得他們可以選擇做個「誠實的人」或者做個「好人」。想像一下，在工作中可能有某個令人挫敗的個人或專業面問題，已經被忽略了很長一段時間，只因為「談論它會令人難受」。正如預期地，當人們不回應外界的輸入訊息時，會導致他們覺得唯一的選項就是「做個好人」，並且將問題忽略。

  但是，經常會被人們忽略的事實是，「誠實」與「好人」並不是互斥的觀念。你可以具有很好的專業才能，同時也是個誠實而且尊重別人的傢伙。當你與同儕、領導者或管理者討論問題時，「尊重」才是其中關鍵的要素。

  上面提到許多關於「問題」的事情，但必須澄清的是：問題與錯誤，與失敗並不相同。錯誤會發生在遊戲開發的許多面向中，它是被預期的，而且可以被理解為學習與實驗的常見實踐結果。然而，錯誤仍然帶有付出代價的重擔，最明顯的花費就是時間，時間的損失將可能對你視為重要的功能或素材造成直接衝擊。因此，身為一位優秀的美術設計者，你需要盡可能積極主動地與管理者或領導者進行溝通。

• 與其他人的溝通

  所謂的「其他人」，指的是「非美術設計者」。這裡要談論的是與其他部門的同儕，例如與程式設計或企畫設計之間的協同合作。

  

  （圖片來源：teachers.saschina.org）

  簡單來講，美術設計者應該使用不同的方法，從不同類型的團體中獲取資訊並且呈現給他們。根據 Keith 的經驗，每個團體與團體之間的互動，很容易會變得十分挫敗，而幾乎所有這樣的情況，都是源自於溝通上的問題。多數情況下，這樣的障礙並非只存在於某一方，而是雙方都沒能提供或取得他們真正需要的資訊。更直接地說，他們都未能「使他們的訊息迎合聽眾的喜好」，因而產生誤解。

  這樣講應該不會讓任何人意外：程式設計者往往比較喜歡詳細且精確的資訊；比較上來說，美術面的分析更加地捉摸不定且具有主觀性。因此在這兩個團體的溝通行為之間，往往需要更多的時間與更多的思考。有好幾次，Keith 都聽到程式設計者這樣下評論：「美術設計者不知道他們要的是什麼。」舉例來說，這種情景可能源自於再三重複或失敗的工具創造，或者各種功能的修改事項上。

  可理解的是，雙方都會因為這種情形而受挫。程式設計者受挫，是因為從他們的觀點來看，他們已經花費了時間建造出某些東西，結果竟然不可用或不是別人想要的；美術設計者受挫，是因為從他們的觀點來看，他們已經要求了某些東西，但程式設計者卻沒有交付出他們想要的成品。

  有些時候，美術設計者提出的需求太過於模糊不清，或易於被非美術設計者錯誤解譯，唯有清楚闡明你的目標才是更有效益的方式。為此 Keith 會經常性地鼓勵美術設計者提供參考範本，或某種形式的視覺化指示，藉此明確傳達什麼才是你想要達成的事情。這才是你如何澄清需求目標的好方法。

  另一項要點，是你如何提出你的需求。美術設計者常見的錯誤是問：「我們可以有Ｘ功能嗎？」透過這個問句，你已很有效地詢問某人一個「是或否」的問題，就像是在問他們是否想要做更多的工作一樣地有效。在這樣的情況下，你期望能夠得到什麼樣的答案回應？

  更有效的問題是問：「如果要實現Ｘ功能，需要什麼樣的代價？」代價或許是三天的時間，或許是更動的工作項目順序，也或許只是一個小時的功夫而已。關鍵在於這種類型的問題打開了對話，讓你知道實現某功能所需花費的代價為何。也許你所問的東西將會需要某些犧牲，也許你的要求會值得那項犧牲，但如果你不用正確的方式詢問的話，你就無法找出答案。

  就算沒有得到其他好處，程式設計者仍然能夠進一步瞭解你重視的事項的優先順序，有助於未來做出其他決定。程式設計者會很願意與美術設計者一同工作以協助支援他們想達到的目標——只要他們願意討論各種選項與替代方案。請不要再讓程式設計者說「美術設計者只是想要每一樣東西」了。

  對照來說，當美術設計者與企畫設計者進行溝通時，常見的卻是相反的情形。企畫設計者向美術設計者提出需求時，最尋常的原因是為了要支援遊戲性的變更。在 Keith 的經驗中，美術設計者時常會抱怨企畫設計者提出的需求太過於模糊，或不瞭解什麼是他們想要的東西。聽起來很熟悉嗎？

  然而我們需要瞭解的是，精確的企畫設計很難在開發過程的早期中達成，好的設計常常需要經過許多迭代與實驗的程序。因此，改變應該是在預期中的事情，同時美術設計者必須注意他們自己也是這個迭代程序中的一部份。

  舉個好例子，關於模糊的關卡設計指示，企畫設計者可能會說：「請把房間加大一點。」或者是：「你能不能夠增加更多的裝置物？」有些美術設計者，會直接採用這個模糊的指示並且做出變更，他們或許會抱怨指示太模糊，但卻沒有採取進一步的步驟去釐清這項資訊，最終結果就是雙方都可能必須要重新檢視這項需求數次。就像是與程式設計者溝通一樣，問題在於只有「功能需求」被闡述出來，卻遺漏了更重要的「功能目的」。

  Keith 的建議是：小心謹慎地，並且充滿尊敬地，詢問對方為何做出這樣的要求。也許企畫設計者想要一個更大的房間讓他們能加入更多的敵人，也許他們想要更多裝置物以創造出能讓玩家獲得掩護的地方。一旦瞭解目標之後，討論就可以專注於選擇或其他替代方案上，某些方法可能得以節省許多時間與精力，並且可以避免丟棄已經完成的素材與作品重新製作。

3. 多樣化 (Diversification)

所謂的「任務多樣化」，在此特別指的是美術設計者如何回應或應對廣泛類型的指派任務。美術設計者面對多樣化任務的方法，將會影響他們的職涯成長以及他們的技藝發展。

在 Keith 的經驗中，這個挑戰較常發生在後進的美術設計者們當中。在最糟的情境下，美術設計者可能會抱怨或拒絕做那些他們視為「不配他們做」的事情。通常有幾個原因會造成這樣的情形，但最常見的抱怨就是這些工作沒有創意、無法鼓舞人心或者是不夠吸引人。

我們可以很容易地識別出其中的自我意識元素——面臨這項挑戰的美術設計者，已經對工作採取了主觀的價值判斷。他們可能會以個人的喜好程度，來決定指派工作的價值高低；而問題在於，無論如何這項工作仍然需要由某人來完成。身為一位專業的美術設計者，不論你的個人喜好為何，你會被期望以相同等級的品質與投入程度，完成每一項交派的任務。

擁有個人喜好的心態是可以理解的。Keith 相信只有當每位美術設計者對他們的工作充滿熱忱時，他們才能夠交付出他們最佳的作品。具有爭議性地來說，美術設計者可能是對的，並且可能在意願較低的任務中，只能夠交付出品質較低的成品。高強的領導者能夠辨識出身邊的人的強處與弱點，因此多數管理者與領導者，會試著以這個思維模式去分配工作，但並不保證一定能夠如此。

應對這種工作項目的最佳方法，取決於你著手處理它們的態度。即使你可能無法對某些工作樂在其中，但它可能正代表著一次個人成長的機會：

（圖片來源：www.unf.edu）

• 技術性任務：有些美術設計者會推延技術性的工作，因為他們覺得這些任務會使他們與自己的創造力疏離。然而，技術性的工作，通常會讓美術設計者更加瞭解驅動整個遊戲的系統。此外，這種工作也能顯示出美術設計者是否能夠滿足於瞭解運作的細節。獲取更多技術限制的認識，也意味著你可以做出更好的決定，並且對於如何提升視覺品質提出更強而有力的建議。
• 組織性任務：安排工作時程以及對於工作小組的管理，幾乎是每位美術設計者都需要應對的事情。此外，業界外包的成長，也擴展了追蹤指導大量素材的需求。

  我們很容易可以理解，為什麼美術設計者會對於建造美術內容更有興趣，而不是去創造那些待追蹤內容的清單。但是，這種層級的計畫經驗，對於任何領導階層的職位來說都相當關鍵。如果你未來渴望指導專案中的美術面製作，那麼這些組織性任務將可以提供給你穩固的學習經驗，瞭解如何管理生產時程表中的重要元素。

• 團隊價值：能夠處理較多不同面向事務的美術設計者，對團隊來說更加具有價值，因為他們可以有更大的影響力。專注於某些項目的專業人才，對於專案來說很珍貴；然而，遊戲專案總是一直渴求能夠在不同面向領域中解決問題的人才。如果你能夠協助解決團隊中的大小問題，你就會成為更不可或缺的團隊成員。

總結來說，這篇文章只是概略性地提出了給美術設計者的三項專業指導準則，事實上還有許許多多可以被討論的議題，但以上三點肯定是其中最重要的項目。這些事情對於每一位美術設計者來說，都是一項嚴格的考驗，而對於那些有興趣想成為美術設計者的人來說，這些都是以後你將會遭遇，並且應該謹記於心的事情。

這篇文章所提到的準則，不只是對遊戲美術設計者有很大的助益而已，我想就算是企畫設計者或程式設計者，也能夠從中學到許多正確的待人處事觀念，以及與美術設計者之間的溝通要訣。看完文章後，你有什麼心得感想或其他的想法嗎？不論你是不是遊戲美術設計者，都歡迎加入討論，提出更多不同的想法與意見！

（圖片來源：diplomaguide.com）

原文出處：So You Want To Be A Producer

「遊戲製作人」(Game Producer)，或許你曾聽過這個高貴的職稱，或許你心中有幾位崇拜的業界典範，或許你從小就立下志向想成為一位遊戲製作人。但是，你真的知道什麼是「遊戲製作人」嗎？

製作，是個有點過於廣泛而籠統的詞彙，也使得「製作人」職位蒙上了一種神秘的色彩。在遊戲開發過程中，程式設計者不斷製作程式碼，美術設計者不斷製作圖片與模型，企畫設計者則不斷製作規則、數值與文件。在這樣分工明確、三足鼎立的研發團隊中，製作人究竟扮演著什麼樣的角色？是肉盾坦克、控場輔助、看護療癒、傷害輸出者，或者只是個可有可無的尷尬角色？

讓我們先回頭想想，遊戲界裡的幾位大師級遊戲製作人，像是製作《模擬城市》系列的 Will Wright，製作《潛龍諜影》系列的小島秀夫，以及製作許多任天堂經典作品的宮本茂，他們是不是成天坐在自己舒適寬敞的辦公室裡，憑空想像出遊戲的各種設計與創意玩法，然後豪爽地說聲「去吧！」就把自己天馬行空想出來的好主意交給底下的人，進而製作出一款又一款經典遊戲作品的那種人？

到底應該如何定義「遊戲製作人」？更進一步來說，遊戲製作人的職責與任務為何？如果你是嚮往遊戲業界的學生，你可能想瞭解要成為遊戲製作人必須具備哪些專業技能與個人特質；如果你是身處遊戲業界的遊戲人，心裡可能已經有一套對於遊戲製作人角色的定見。不論你對遊戲製作人的認識有多少，藉由這篇文章，作者將帶領我們一窺遊戲製作人在開發過程中所需承擔的各項職責與任務。

Producer 〈名詞〉

1. 能夠成為遊戲發行商與遊戲開發團隊之間的聯繫橋樑的人
2. 製造煤氣的熔礦爐

英文的 Producer 具有兩種截然不同的意義，如果你想要知道熔礦爐是怎麼製造出煤氣的話，你肯定是走錯地方了。而如果你想要學習成為遊戲製作人的各種基礎概念的話，請繼續往下讀吧！

從遊戲公司的徵才資訊來看，遊戲製作人的職位，範圍廣從入門等級的助理製作人職位、聯合製作人、資深製作人、線上製作人、研發指導製作人、內部製作人、外部製作人，到管理階層的製作人等等。無論你想要成為哪一種類型的製作人，首先你必須確認自己是否擁有正確的專業技能。

在學生時代時，你是不是會使用分類文件夾妥善組織讀書計畫的那種小孩？你是不是個有計畫、喜歡排定時程，並且會指揮與朋友間的遊戲比賽的那種人？有時候，這個世界的其他人可能會因為你的「指揮者態度」而感到有些困擾，但這些正是能夠使你成為明星遊戲製作人的重要特徵。因為實際上，每一位能夠勝任遊戲製作人職位的人，都需要具備下列這些屬性：

• 優秀的時程安排能力。
• 極佳的組織技巧。
• 傑出的領導力與建立共識的能力
• 從頭至尾指揮專案的開發，使其能夠在期限內完成的能力。

身為一位遊戲製作人，你必須要熟知如何善用 Microsoft Project、Word 與 Excel，以及一些尋常可見的腳本語言。同時，你也必須熟知最新的遊戲系統。而且一般來說，你應該要是一位熱愛遊戲的玩家。

對於想要應徵遊戲製作人職務的人來說，撰寫出組織良好的履歷表是一項必要的條件。如果連一份簡單的履歷表都無法寫得好，又如何能夠妥善組織錯綜複雜的遊戲開發程序？另外，在期限內完成專案以及注重事物的細節，對遊戲製作人來說都是至關緊要的特質，所以如果你要去遊戲公司進行面試的話，請確認你會準時到達！

除此之外，如果你想成為一位遊戲製作人，更需要仔細瞭解製作人工作中的每一項基礎，包括如何發展最初的遊戲概念，以及如何向管理階層推銷你的想法。直到遊戲進入組裝廠壓片裝盒為止，遊戲製作人都必須親身參與遊戲開發過程中的每一個面向。

魔鬼全在細節中

對於遊戲製作人來說，以紮實穩固的根基啟始遊戲專案，是一件很重要的事情。在面對如遊戲開發這樣需要創造力的工作時，所謂的穩固根基，就是本質上在你的內心所感受到的願景，或者是能夠成為專案靈魂的那份主體概念。這個願景將會成為一股驅動與刺激的力量，協助你以及你的團隊，度過許多難以成眠的夜晚與現實世界的限制，並且將其實現。

身為製作人，你最初的任務有兩個面向：第一，概念化或者辨認出你所相信的遊戲概念。第二，將這些想法推銷給上頭的管理階層。毫無疑問地，你將會被要求將你的遊戲概念當作一個商業上的良機，呈現給上位的決策者或擁有資金的投資者。因為唯有如此，才能夠使你得到足以開發遊戲概念原型的資金。

下一步，則該評估你的開發團隊。無論你是在尋找一個團隊投身實現你的遊戲概念，或者是在尋找一個持有引人入勝想法的團隊，徹底地評估每一位開發者以及整個團隊，都是一項不可輕視的重要事務。把它想像成一個面試程序，你必須確認每位成員都具備正確的處事態度與專業技能。因為開發團隊所扮演的角色，和願景本身具有相同的重要性，因為唯有優秀的團隊才能夠克服重重險阻，將「腦袋中的願景」化為「現實中的成品」。

花費時間與團隊以及團隊中的個別成員相處，同樣也是相當重要的要務。瞭解每一位成員的長處與短處，瞭解驅動他們前進的力量是什麼，以及他們如何在一起共同工作。當你逐漸瞭解團隊以後，就能夠以此評估出專案的潛在風險。更重要的是，觀察團隊是否對專案的目標遠景懷有熱忱，以及是否擁有足夠的技能得以執行任務。另外，技術層面的考量同樣具有重大意義；例如，團隊是否有能力使用既存的遊戲引擎來開發遊戲？他們是否已經具備充足的開發工具？

這個階段的關鍵，在於定義團隊中的各個角色，包括遊戲製作人自己。良好的溝通並不只是基本事務而已，而是遠比基本事務更重要的事情。每一位團隊成員都應該對於誰負責什麼項目，以及誰有權做出決定，有非常清楚的認知。打從一開始就討論這項議題，並且使所有人都清楚瞭解，將有助於預防在專案開發過程中可能發生的衝突情形。

前製時期：企畫設計、技術設計，以及可玩的遊戲原型

在遊戲開發的預算數字日益升高的情況下，通常最好在啟動完整的遊戲開發程序之前，先進行一至兩次前製階段的執行程序。在這些階段中，完整的遊戲設計、技術設計，以及在目標平台上的可玩遊戲原型都應該被完成，並且以這些前製的成果，共同定義及證明遊戲中的基礎遊戲性、角色動作與基底技術。

在前製開發階段中，不僅可以給遊戲製作人一個機會，觀察你的開發團隊是否真正瞭解這款遊戲的願景，你也將從中習得開發團隊如何共同分工合作，並以此評估團隊是否能在預期的時限內完成專案，以及你目標內的開發預算與開發時程是否符合實際現況。為了達到這項目標，你必須開發每個月的專案里程碑，藉此追蹤專案的開發進度，並且瞭解團隊如何回應這些里程碑的目標。

訂定里程碑文件的目的，並非為了製作出詳盡的遊戲建造藍圖，而是為了提供結構與方法以量測開發程序的成效。對於每一個里程碑，必須考慮以下各項定義：目標、企畫設計工作、程式設計工作、美術設計工作、音樂設計工作、整合測試、風險評估、到期日，以及完成後所需付出的預算等等許多項目。

另外，工具開發與核心引擎技術研發，也應該被納入里程碑的時程中。重要的核心遊戲性功能與相關的技術，同樣必須在早期的里程碑時程中被處理；例如，在一個平台動作類型的遊戲中，早期證明基本的遊戲機制，如移動與遠距離跳躍動作，是非常重要的事情；必須先確認這些基礎的運作機制，遊戲關卡才有辦法依此功能特徵開始進行建造工作。

最後，關於製作遊戲的試玩版、電玩展的用展示版、市場行銷材料，以及每年的假期與感冒季節等等，都是經常會被忽略，但應該好好納入專案時程考量的要素。一旦完成遊戲的前製階段，並且通過管理者與執行團隊的檢驗之後，雖然還有一座高山需要攀越，但你與你的團隊至少已經到達關鍵的高原區了。

（圖片來源：www.young-germany.de）

完整開發時期

當專案來到這裡，你的遊戲正處於完整開發時期。遊戲的靈魂已精神抖擻，遊戲的框架已準備就緒，現在正是開始動手執行的時刻了！然而正如我們所知，並不是所有的事情都能夠一如預期地順利執行。遊戲製作人的角色，就是要成為這段期間裡的力量支柱，幫助團隊度過每一段無可避免的風暴。

與團隊建立良好且頻繁的溝通，將會是你最重大的資產。更重要的是，要讓你的團隊知道你會「為了他們而在」，以及確保資訊能夠盡可能客觀地被連結呈現出來。即使是過度的溝通，也比完全不溝通來得好。請記得這個世界並不是個客觀的存在體，而是端視人們怎麼看待它。身為遊戲製作人，你看待世界的方法毫無疑問地將會與你的團隊中的成員有所不同，特別是當你必須同時與極為「左腦導向」與極為「右腦導向」的兩種人應對來往時。

關於專案時程的里程碑，即使可交付的里程碑目標通常都是以月做為單位，但是你最好經常性地每週追蹤任務的進度。如果你正與外部的開發團隊共同進行工作，可以考慮在週一時詢問他們本週的預定目標，然後在週五時檢閱本週的進度。如果團隊的進度落後了，請立即找出問題的根源所在。盡可能鼓勵團隊多花一點額外的時間補足目前落後的進度，而不要在快到達里程碑期限之前，才開始像是燃燒生命般地瘋狂加班。

在專案開發期間，請帶著急迫感回應開發者們的需求。不論是開發者所需使用的硬體配備，或是對於專案里程碑的意見回饋等等，請將他們所發出來的聲音，視為必須即刻處理的燙手山芋。你的開發者通常會焦急地等待著你的領導與回饋，所以你最好可以很迅速地釋放他們的壓力，才能夠使整個團隊保持備受激勵與快樂的狀態。

讓團隊快樂：好的、壞的或醜的

在遊戲專案的執行時期中，你需要使「團隊」——這個瞭解你的願景並且活生生、會呼吸、有機的生命體——感到快樂。以下是幾點建議事項：

• 讚美：如果在應得的時候真誠地給予，讚美會有很長遠的影響，特別是當團隊或個人做出了超越職責的工作之後。這些正向的回饋，會讓團隊或個人知道怎樣的表現才是你所想見到的成果，而且他們通常都會以更多相同的事物回應，因而形成一種良好的正向循環。
• 透過開放式溝通以解決衝突：衝突，經常是溝通錯誤或缺乏溝通的一種徵兆。舉例來說，有可能是主程式設計者被一項剛定案的設計決定激怒，特別是當專案逼近結束期時，他可能不會再壓抑心裡的各種感覺而一口氣爆發出來。不被衝突本身纏住而迅速地找到衝突發生的根源，讓事情不會逐步擴大升高，是一件非常重要的事情。做為一位製作人，需要找出具有創意或心理學的方法來解決衝突。或許你需要給程式設計者一天的假期，讓他休息以回復狀態（我舉雙手贊成！XD）；或許最好是將企畫設計者與程式設計者聚集在一起，坦承佈公地討論這些議題。
• 加入市場分析、公共關係與行銷人員：在整個專案的開發過程中，將這三個團體視為你的盟軍是很關鍵的事情。市場分析人員能夠協助提供市場研究資訊，並且藉由焦點測試蒐集許多玩家資料，而銷售人員則能夠提供寶貴的第一線回饋訊息。身為遊戲製作人，最好能夠教育他們透過你的觀點來看待遊戲中的各種面向，同時也要將他們對於遊戲的意見納入考量。他們越加熟悉遊戲，同時你也越加重視他們的意見，遊戲產品成功的機率就會越高。

最終開發時期：封閉測試、開放測試，最後的里程碑

當遊戲專案到達了這個階段，毫無疑問地你必須放手，將一些在專案啟始時覺得很棒的想法捨棄。理想上來說，專案里程碑必須將那些不屬於遊戲核心元素的東西，排到更後面的順序。

在開發的最終階段，好好照顧你的團隊更是一件特別重要的事情。在最終的測試期間裡，將會是一段非常艱苦的時間；遊戲臭蟲源源不絕地冒出來，其中有些臭蟲似乎不可能找到合理的方法修復，而程式設計者也可能正對於某部分的程式碼感到焦慮不安。身為遊戲製作人，這是一場你必須帶領他們共同度過的風暴。

請用盡一切可能的辦法。例如，向技術指導人員諮詢以解決技術層面的問題；給予你的團隊關心，推心置腹地瞭解他們缺少什麼與想要什麼。「不論任何代價也要解決問題」，是你在這個階段中必須奉行的座右銘。

通過考驗

最後，不論是在內部或外部測試期間，遊戲製作人都需要定義回報遊戲臭蟲的方法與流程。開發者會希望盡早得到關於臭蟲的報告，而不是非得經過漫長的等待才能得知測試後的結果。藉由建立出適當的處理程序，例如一個線上臭蟲回報資料庫系統，就可以幫助你的團隊減輕負擔。

製作人應該要檢閱臭蟲的報告，並且在指派給開發者之前先行過濾臭蟲。臭蟲報告必須要結構良好並且易於閱讀，臭蟲的敘述也應該要清楚又精確，如此才能夠避免指派多餘或重複的臭蟲給開發者。你一定要瞭解哪些臭蟲很重要且必須修復，而哪些又是基於時間與理性因素，必須放手讓它走的臭蟲。抗拒要求遊戲一定要達到完美程度的誘惑，並接受使其達到優秀的程度吧！

經過漫長的測試與考驗，當遊戲送廠壓片，專案告一段落後，記得舉行慶祝會！讓你自己和團隊有機會感謝這段期間以來的辛苦工作，並且感激我們能夠在此做著我們熱愛的工作！

（圖片來源：www.asiaarts.ucla.edu）

看完以上對於遊戲製作人的工作職責簡介後，你是否更加瞭解該如何扮演開發團隊中的領導人物了？有些讀者或許會覺得遊戲製作人，好像只是個高高在上、不容侵犯，只負責出一張嘴交代工作的人。事實上，遊戲製作人除了必須發展初期的遊戲概念以外，更需要監督專案的執行成效、協調各部門的事項、做出關鍵的設計決策，同時也要懂得信任團隊中的成員。

從這篇文章的內容與我個人的業界經歷來說，我心目中的理想遊戲製作人形象，應該是個使用「耳朵」更勝於「嘴巴」的角色。溝通，是一項說來容易，執行上卻困難異常的事情。我認為溝通並不是從「說話」開始，而應該以「聆聽」做為起點。有句諺語說：「當你知道如何聆聽，每個人都是你的導師。」我想就是這樣的意思吧。

製作商業遊戲，是一件很艱苦，甚至會使人非常痛苦的事情。以開發一款 MMO 線上遊戲來說，一般情形下至少需要花費 2 至 3 年的開發時期，30 人以上的研發團隊規模。在這段漫長的完整開發階段裡，研發團隊需要每天 8 個小時沈浸在專案當中，剛開始時，多數成員都會處於鬥志高昂、興趣盎然的狀態，然而隨著專案的推移，難以避免地將會逐漸開始產生疲乏的感覺。更甚者，如果專案中發生了進度延宕、設計變更或溝通衝突等問題，未獲得妥善解決而日積月累之後，往往會嚴重侵蝕團隊的士氣，造成非常負面的後果。

以客觀理性的角度來說，身為受雇於公司的工作者，只要每月領到薪水，就應該認真地把上頭交付的工作做好。然而，如果遊戲製作人或管理者，只是把團隊成員當作機器一樣，認為只要輸入指令，就可以得到分毫不差的結果，不會有任何失誤的話，恐怕就太過於高估了人類的不確定性。我們並不是機械人，所以我們會有情緒起伏，有各自的工作態度，也有各自的人生目標。如果團隊成員無法感受到公司或領導者對他們的關心，那他們又怎麼會關心公司的前途，或甚至是遊戲的品質？

所謂的「團隊」，其實就像是「人」一樣，需要被鼓勵、需要被鞭策、需要被刺激，也需要被教育。遊戲製作人，身為團隊中的領導者，則像是引領羊群的牧羊人一樣，你不可能期待團隊中的每個人，每次都能夠平安順利地回到羊圈裡。他們需要你的指引，才不會走上歧路險途；他們需要你的信任，才能夠發揮出百分之百的戰力。我想，這些困難的事情，就是遊戲製作人真正的使命與職責所在吧。

不論你的專業領域是企畫設計者、美術設計者或程式設計者，同樣可以朝著「遊戲製作人」這項目標努力前進。只要時常抱持著積極開放的心胸與學習態度，多多結交不同專業領域的同事朋友，即使面對未知的挑戰也願意勇敢嘗試的話，相信將來你也能夠成為一位令人景仰的遊戲製作人！

你認為一位稱職的遊戲製作人，需要什麼樣的個人特質或專業技能？歡迎各位提出自己的觀點一起討論～ ^_^

（圖片來源：potq.cl）

標題壞掉了？沒壞，就是 12345。

從 2004 年 4 月踏入遊戲業界開始，到現在 2009 年 4 月為止，已經滿 5 年整了。說起來就像是算算數一樣，用完一隻手的五根指頭 12345 剛剛好，但卻又不是像算算數一樣簡單的 12345。

五年，代表著什麼樣的意義？有人說，在一個行業裡持續工作滿五年的時間，表示你正式從菜鳥的行列中畢業了，雖然還稱不上是功力深厚的老手，但至少也是個具有一定裝備等級的「中手」。最近這段時間以來，幾次試著動筆想為自己的五年下些註解，卻不知從何開始。回首來時路，在這五年的光陰裡，雖然經歷過大大中中小小數個不同的遊戲專案，但竟沒半個能夠稍微拿來說嘴，或者能夠引以為傲的遊戲作品，想來真是有些令人沮喪。

所以我害怕，也不害怕。

我很害怕，害怕自己在歷盡風霜的面容中，已經遺忘了最初擁有的熱情；害怕自己在現實生活的壓力下，已經拋棄了最初緊握的堅持；害怕在接下來的五年內，還是做著差不多的工作、領著差不多的薪水、寫著差不多的遊戲，然後就這樣過完差不多的人生。翻轉到硬幣的另一面，我不害怕；即使前方的道路誨暗不明，即使身處險惡嚴峻的環境之中，即使所有人都說這條路沒有前途，我不會害怕。

And all the roads we have to walk are winding.
And all the lights that lead us there are blinding.

不懼且懼。反覆咀嚼著這兩句歌詞，別有一番滋味。

五年前，當我懷著滿腔熱血進入遊戲界時，是國產單機遊戲最衰弱的黃昏期，網路遊戲是新興的強盛勢力，幾乎所有的遊戲公司與許多從來沒做過遊戲的公司，都急著想跳下去分食市場。在那個年代裡，線上遊戲的競爭者還不是很多，只要代理到一款正確的遊戲作品，幾乎就可以養活一整間遊戲公司好幾年。

很快地，打著免費制口號的線上遊戲，開始大舉侵略月費制線上遊戲的市場，除了超大型強作之外，幾乎所有遊戲都改投向免費遊戲的陣營。除此之外，遊戲的類型越來越豐富而多樣化，也逐漸地由技術門檻較高的萬人同時在線模式，演化出「開房間」或「下副本」等技術門檻較低的遊戲機制與類型。

線上遊戲就像是從前的單機遊戲市場一樣，一款接著一款地問世，每個月都有許許多多新的遊戲、新的資料片或新的廣告活動。然而，打著免費旗號的商城制線上遊戲，已經漸漸地顯露出了疲態，玩家們對於換湯不換藥的線上遊戲，感到厭煩的速度也越來越快。線上遊戲需要「新玩意兒」，不論是新的收費模式、新的遊戲機制或者新的樂趣技術。但沒有人敢踏出第一步，所有人都在等待先驅者的降臨。

如果從另一個角度思考，除了線上遊戲以外，還有沒有其他的可能性存在？大型遊戲機台、數位下載服務平台、手持式遊樂器平台、野心勃勃的 iPhone 平台……，我們還要錯過多少台灣以外的世界？市場可以借鏡，技術可以模仿，但文化無法複製。我們在存活下來之後，是否應該花費更多的心力在別人無法輕易複製的獨特優勢上？

包含電腦遊戲與遊樂器平台遊戲在內，電子遊戲的發展歷史並不很長，比起其他娛樂媒介，電子遊戲像是個正逢青春期的毛頭小鬼，一下子往東跑，一下子又衝向西，雖然擁有備受期待的巨大潛力，但也十分令人捉摸不定。我很敬佩那些知名的遊戲製作人，以及更多籍籍無名的遊戲開發者，心甘情願投身於遊戲界奮鬥打拼十年、二十年，甚至是更久更久的時間。我想，他們一定很愛很愛「它」，才能夠和它在一起這麼長的時間吧。

回過頭來問自己：我能夠愛它這麼長這麼久，保證永遠不會變心嗎？現在的我無法回答。但我選擇了這條路，至少到目前為止還沒有後悔過，也從來不會覺得特別辛苦。能夠打從一開始，就得以從事自己熱愛的工作，我認為這已經是一件非常非常幸福的事情了。職業無分高低貴賤，差別只在於熱情與用心程度罷了。

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

除了埋首撰寫程式碼，以及參與遊戲製作的歡樂時光以外，工作中也常需要面對許多明知不合理，但卻無能為力改變的事情。因此，偶爾我也會感到沮喪、不平甚至憤怒，即使看起來有些負面，但這些情緒有其獨特的價值存在：正因為我關心在乎，所以我有情緒。

如果哪天我變成了冷漠的「社會化完成體」，只是成天將「沒辦法，這就是現實」這句話掛在嘴邊時，或許我已經成為一位真正的「大人」，可是也失去曾經擁有的寶貴特質了。如果你也有相同的心情感受，請化憤怒為力量，時時保持氣（熱）血通暢，不要讓自己成為麻木不仁的傢伙！

某本書裡提到，要在特定專業領域中成為出類拔萃的傑出人物，至少需要經過一萬小時的努力、練習與累積。一萬小時，約略等同於十年的時間。嘿，原來我才正好在「半路」上而已，再回頭想想之前那些比較消極的想法，現在似乎舒坦多了。

下一個五年，我會在哪裡？寫著些什麼樣的文章？與什麼樣的伙伴相處？做著些什麼樣的遊戲？老實說我並不清楚。但這個問題，不能就這樣輕易地交給五年後的自己來回答。我非常清楚，並不是現在什麼也不做，到了五年後我就會自動成為我想要的那種人。我要交由現在的自己，親筆寫下每一頁的歷史。

最後和各位分享兩篇我非常喜歡，而且讀來很有感觸的文章：

• HP大中華區總裁孫振耀退休九大感言
• 朱學恆：不當富翁，快樂做自己

勉勵各位，也勉勵自己。 ^_^

所謂的「多執行緒」程式設計，或者可簡稱為「多緒」程式設計，在英文中有許多相關的專業技術名詞，例如 Threading、Multithread、Concurrency、Parallel、Multicore 與 Multiprocessor 等等，在搜尋資料時可以嘗試不同的關鍵字，往往可以找到不少意料之外的好東西。而其中最常見的總括性簡稱，應該就是 Threading 了。

基礎定義

既然要學習 Threading 程式設計的知識，首先要瞭解的當然是 Threading 的基礎概念：

• Thread：看看 Wikipedia 裡的定義，至少把最前頭那段 Thread 的基本定義，以及 Thread 與 Process 的不同之處搞懂。簡單來說，執行緒是用來執行電腦程式的執行環境；而多執行緒，就是能夠使程式系統同時執行多個不同程式碼區段的一種技術。
• Thread Safety：雖然使用 Threading 技術能夠提升程式系統的執行效能，但伴隨而來的則是麻煩又難解的 Thread Safety 議題。大致上，我們可以使用 Re-entrancy、Mutual exclusion、Thread-local storage 以及 Atomic operations 這四種方法來達成安全使用多執行緒技術的目標。

教學文章

• C++ Multithreading Tutorial @ paulbridger.net：質量非常不錯的基礎教學文章，從 Race Condition、Mutex、Deadlock 到 Condition Variables 等等重要的基本概念，都有清楚易懂的文章教學與程式碼範例。
• Multithreading Tutorial @ Homepage of Mario Konrad：網站裡分成基礎、中間與進階三種等級的教學文章，可以看看 Socket 網路程式與 Producer-Consumer 的程式碼，應該會更加瞭解多執行緒技術的可運用之處。

跨平台函式庫

• Boost.Thread（連結為 1.38 版）：簡單易用且功能完備的跨平台函式庫。如果沒有使用過 Boost C++ Libraries，可以參照這篇文章的步驟來建置 Boost.Thread 函式庫。
• threadpool：以 Boost.Thread 為基礎，實做出一個非常好用的 Thread Pool 設計模式。

名家專區

• Intel: Parallel Programming and Multi-Core：因為 Intel 的本業是靠 CPU 吃飯的，所以自然相當注重多執行緒程式設計的議題，在這裡可以挖到不少質量兼具的優秀文章。
• MSDN: Parallel Computing：MSDN 中的平行計算處理專區，充滿文章、影片以及部落格等相關資源。
• DevX.com: Move to the Future with Multicore Code：有幾篇不錯的概念性文章，另外還有介紹如何使用 .NET 平台的 Task Parallel Library。
• Sutter’s Mill：Herb Sutter 大師的個人部落格。目前在 DDJ 雜誌上，有他每個月固定連載的 Effective Concurrency 專欄文章，適合進階高手服用。

投影片

微軟於 2007 年與 2008 時所舉辦的 Gamefest 開發者會議，其中有許多關於 Threading 的演講主題，內容非常豐富多樣且紮實，而且大部分課程都有投影片與錄音檔可供下載：

• Multi-Threaded Rendering for Games
• A Detailed Overview of Xbox 360 Direct3D Synchronization and Multithreading
• Introduction to the Direct3D 11 Graphics Pipeline
• Practical Parallel Rendering with DirectX 9 and 10, Windows PC Command Buffer Recording
• Multicore Programming, Two Years Later
• Magic and Technology: Migrating from One to Many Cores in Shadowrun

另外這篇是微軟於 GDC 2008 中開設的講座：

• GDC 2008: Getting More From Multicore

推薦文章

• Threading Basics for Games：概略簡介了遊戲所使用的基礎多緒程式架構。
• Threading the OGRE3D Render System：這篇文章闡述了三種能夠使 OGRE 繪圖引擎充分利用多緒能力的技術，並完整實作出其中一種方法，附源碼可供下載。
• Multithreading the Rendering Pipeline for 3D Model Animation：相對於 GPU 的強大運算能力，這篇文章試圖藉由多核心 CPU 的力量來達成 Skinning Animation 的功能。雖然目前這個作法的實用性不高，但是文章中的設計架構仍然非常值得參考學習，也有完整源碼可下載。
• Designing the Framework of a Parallel Game Engine：相當夠份量而且完整的好文章！著重於設計概念與流程架構，沒有提供任何程式碼範例。

書籍文章

關於書籍中的文章，我推薦《Game Programming Gems 7》中的「Design and Implementation of a Multi-Platform Threading Engine」與「Multithread Job and Dependency System」這兩篇文章。前者實作出了一個可跨平台的 Threading 引擎架構，後者則著重於更加複雜的任務相依系統上，兩篇文章各有擅場，而且都有完整的程式源碼可供讀者仔細研究！

如果有其他關於遊戲 Threading 程式設計的資源，隨時歡迎各位的回應與補充喔～ ：D

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

原文出處：Physics in Games: A New Gameplay Frontier

截至目前為止，在猴子靈藥中從未探討過與遊戲物理學相關的課題，主要原因是我以前從未接觸過任何物理引擎或物理面向的應用程式，所以相當缺乏對於遊戲物理學的概念與知識。讀完這篇文章以後，我總算是開了眼界，對物理學有了一番新的體悟，也開始能夠想像如何在遊戲中的運用各種物理學的觀念。所以我希望藉由分享原作者所寫的這篇文章，讓大家都能認識並且開始思考遊戲物理學的設計應用。

如許多老玩家所知，在遊戲中使用物理學，並不是什麼新鮮的事情。事實上在許多年代久遠的老遊戲，譬如《Lunar Lander》與《Marble Madness》中，已經充滿許多與「重力」這項物理特性互動的遊戲性。隨著時代的推移演進，今日我們所擁有的嶄新技術方案，使遊戲開發者能夠將更進階而且更新穎的物理學特性運用於遊戲之中。

物理學處理程序對電腦運算能力的要求非常高，所幸拜核心數目越來越多的中央處理器，以及專門的硬體加速卡誕生所賜，身為遊戲開發者，現在我們可以真正深入考量如何在遊戲中緊密結合物理學的使用。而真正的問題所在，是我們該利用這些新的資源來做些什麼事情？直到目前為止，遊戲中所使用的物理學大多侷限於裝飾性的效果，雖然這些效果能帶給玩家很重要的沈浸感受，但卻無法真正改變現有的遊戲性。

當我們瞭解物理學在遊戲性中各種應用的可能性以後，我們又該如何提供給玩家與物理學相關的全新體驗？本文的目的就是為了回答這些問題，同時作者也分享了他從設計多人連線地圖模組 CTF-Tornado 中所學習到的經驗。（CTF-Tornado 是在《Unreal Tournament 3》中，被設計來充分發揮 Ageia 物理加速卡優勢的地圖。）

首先讓我們從一些物理學的基礎定義開始吧。物理學的範疇並非僅侷限於模擬重力或者物體與物體間的碰撞行為，實際上物理學也包含了以下這些應用：

• 流體力學，包括液態與氣態。
• 扭曲形變，包括柔軟物體或者剛硬物體。
• 摩擦力與黏力的行為模擬。
• 改變物質的狀態，例如水由液態變成固態的過程。
• 材質的破壞。

由此可知，物理學涵蓋了相當廣泛的內容，而其中有些理論仍未實際被應用於遊戲之中。因此我們可以預期，物理學的發展潛力非常龐大，但遊戲開發者所面臨的各項議題也十分具有挑戰性。隨著開發者在遊戲中使用物理學而產生出來的難題，主要可以分為以下四個項目：

• 對電腦運算能力的需求。
• 更多物理學以外的處理程序。
• 多人連線遊戲中的挑戰。
• 在既存劇本與物理學混沌本質間的不相容性。

讓我們更進一步仔細地檢視每一個項目。

對電腦運算能力的需求

首先必須具備的認知是，處理物理學需要龐大的運算能力。由此可知，儘管市場上已經有像 Havok 這樣非常優秀的物理引擎存在好幾年了，但物理學仍沒有被廣泛應用於遊戲中，並不是個令人意外的結果。

在目前的遊戲作品中，只有非常少量的 CPU 能力，約佔單個核心的 10% 至 25% 左右，是分配給物理學處理程序使用的運算資源；但就現實面來說，處理物理學的邏輯需要相當可觀的運算資源。讓我們來看個最簡單的碰撞處理範例：

每一個動態物件的移動行為，都是被許多參數（移動方向、速度以及多軸向旋轉等）所控制，必須要在每一張畫面顯示之前被重新計算出來。而除了動態物體本身的參數之外，這些動態物件之間的互動行為也必須被計算出來。假設有 10 個動態物件需要處理，就需要進行 55 次的檢測處理程序，20 個動態物件需要 210 次檢測程序，而 30 個動態物件則需要 465 次檢測程序！

我們有兩個技術方案可以解決這個問題：

• 多核心 CPU 世代的來臨，將帶給我們非常大量的運算能力。雖然雙核心 CPU 仍不足以產生顯著的影響力，不過從四核心開始，將會開始帶來物理學應用所需要的運算能力。但是四核心的 CPU 是否真的足夠？我們無法確定。因為遊戲引擎與繪圖引擎對於硬體能力的需求，同樣也在不斷地增長當中。
• 第二個方法是使用專門的物理加速卡，例如由 Ageia 公司製造的產品。（註：Ageia 已於 2008 年 2 月被 NVIDIA 公司收購）

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

更多物理學以外的處理程序

使用物理學使得遊戲關卡中所需的路徑搜尋演算法更加複雜。事實上，這個演算法必須要能夠適應不斷發生變化的環境：如果一個巨大的石塊掉下來擋在路中間，遊戲中的人工智慧必須將這項突如其來的環境變動納入邏輯思考程序，才有辦法使由 AI 控制的角色繞過這些物件或者使用它來當作掩蔽物。

另外，場景中的光源和影子也必須以動態的形式製作。因為如果物件會移動，或者牆壁會被摧毀，我們就無法使用預先計算完成的光影效果，因此動態光源的使用會變成遊戲的基本需求。或許我們可以選擇採用對比度較低的場景以避免光影失真的問題，但是地圖場景的繪圖品質也會因此而犧牲。

多人連線遊戲中的挑戰

從遊戲性的觀點來看，在多人遊戲中使用物理學，允許玩家們能夠動態變更遊戲場景的拓樸結構，將會帶來非常有意思的遊戲樂趣。然而與單人遊戲相比，多人連線遊戲會因為網路頻寬及延遲的因素產生限制。所以在多人連線遊戲中使用物理學的難題，就是在於必須同步化所有會對遊戲性產生直接影響的事件。

在大多數遊戲中，通常只會對玩家的位置以及它們的投射物體進行同步化程序。但如果物理學會對遊戲性產生影響的話，代表所有的物理事件，例如具物理屬性的物件、可能遮蔽玩家視線的粒子群，或者是損害區域等等都應該要被同步化。其中有些程式設計面向的技巧，可以用來解決部分網路延遲所產生的問題。因此，如果要在多人連線遊戲中加入物理學的功能，設計者就必須打從一開始就將這些限制因素納入考量，並且約束進行同步化程序的物件數量最大值。

在既存劇本與物理學混沌本質間的不相容性

所有遊戲作品的目標，都是為了提供給玩家最佳的感知娛樂體驗。但由於遊戲開發經費有限，多數遊戲提供的都是線性式的遊戲關卡設計，確保玩家在滿足某種條件後，會在某個特定的時間地點，看見某些特殊效果、過場動畫以及按腳本進行的戰鬥場面。線性化的關卡設計使遊戲開發者能夠良好地控制遊戲的節奏，能夠充分避免玩家隨處閒晃而開始覺得無趣。

在這樣的前提下，使用物理學可能會發生許多關卡設計者原先所沒有預測到的情形，這也就是所謂的「應變式遊戲性」(emergent gameplay)。這種類型的遊戲性，通常很受到玩家們的歡迎與喜愛，但如果玩家利用物理學的功能來改變關卡中的拓樸結構，藉此阻擋對手的移動路徑，也可能會因此擾亂了 AI 的運作程序，甚至使得原先安排好的過關道具消失不見等等，各種物理學的元素都會增加遊戲設計層面的複雜度與困難度。

上述這些狀況同樣可能發生於多人連線的遊戲關卡中。因此，當作者在 CTF-Tornado 地圖中，設計了一個會阻礙玩家去路的「龍捲風」物體時，他們必須非常小心地考慮各種可能產生的問題。因為龍捲風的出現，不僅會破壞場景上的某些物體，也會直接妨礙玩家的行進路線，但同時也可以孕育出許多嶄新的戰略。為此他們決定增加地圖中的通道數量，並且讓玩家能夠使用 Impact Hammer 武器來擺脫移動路線中的阻礙物。

物理學除了可以提供主要的遊戲性機制以外，實際上最初是被拿來做為裝飾性的用途，像是遊戲物體爆裂飛散，或是遊戲角色受到衝擊力所做出的動作回饋反應等等。即使到了今日，仍然少有遊戲使用物理學來增進它們的遊戲性。因為大眾市場裡的一般遊戲，例如動作射擊類型的遊戲，對於電腦運算能力的需求已經非常高，所以如果在這些遊戲中使用物理學，將會對遊戲其他面向，譬如繪圖成像上的表現，造成強烈的衝擊。

當我們克服了上述四項難題之後，就可以大膽地說：「不論是哪一種類型的遊戲，現在都能夠更密集而且更深入地使用物理學了！」但問題是，我們該為了什麼目的使用物理學？大致上可以分成四類應用：

• 給予玩家新的方法處理他所面臨的挑戰。
• 創造機動式的遊戲環境。
• 發展強而有力的學習機制。
• 允許玩家建造自己的工具。

讓我們深入檢視這些應用項目。

給予玩家新的方法處理他所面臨的挑戰

對多數遊戲來說，遊戲性不外乎有兩項主要的出發點：第一，提供玩家一項需要克服的「挑戰」，像是擊倒一群敵人或通過關卡；第二，給予玩家一些「工具」，例如武器、動作或場景元素等，讓他們有機會獲得成功。而玩家玩遊戲的目的，就是學習如何精通這些工具，並且明智地使用它們來克服面前的挑戰。

如果從這個觀點來看，任何由遊戲設計者提供給玩家的新工具，都應該要使他們能夠達成這個目標。對物理學來說也是相同的道理，如果物理學無法提供新的方法讓玩家克服挑戰，那麼它將會在遊戲性的層面中完全失去意義。例如以動作類型的遊戲來說，主要的挑戰要素在於「戰鬥」以及「移動」。而物理學的應用，應該要提供給玩家新的工具，讓他們能夠達到以下這些目標：

• 削弱或消滅對手。
• 保護自己。
• 開啟或關閉通道。
• 偵測對手。
• 閃避對手。

一旦瞭解玩家的目的之後，立即就可以想出幾個可於遊戲中應用物理學的實例：

• 如果可以破壞場景中的元素，將使得玩家能夠佔據有利位置接近對手，建造掩蔽物以獲得保護，或是開啟新的通道與關閉現存的通路。
• 如果能夠運用流體力學，無論是液態或氣態的形式，都能夠提供全新的遊戲廣度。它們可以使玩家點燃火焰，或者讓風把火焰吹到正確的方向。而由玩家的行動所產生出來的煙霧，也可以削弱對手的視線，因而產生出許多全新的戰略性機會。

創造機動式的遊戲環境

現今多數遊戲的遊戲關卡都是全然靜態的形式，真正賦予遊戲關卡生命力的是其中的敵人對手。假設我們能夠使「遊戲環境」變成一位對手，或至少提供某些變動的狀態，是不是能夠讓遊戲變得更加多樣化而充滿驚喜？物理學能夠允許遊戲環境發生變動，以及隨之而來的各種影響效果，像是物件掉落、失去平衡、根據坡度來決定物體是否容易移動等等。其他譬如火災、地震、潮汐波浪、炸彈爆炸、海嘯火者是重力改變等等，也都是遊戲開發者可以設想的應用情境。

事實上，這就是作者的團隊在 CTF-Tornado 地圖裡所做的事情。其中的「龍捲風」就像是第三組團隊，藉由阻擋或者開啟數個可變動的通路，龍捲風得以動態改變關卡地圖的狀態，也可能因為被撕裂的牆壁與屋頂而使防守態勢產生變化，甚至還能夠使玩家發射的子彈偏離原本的軌跡。

（圖片來源：roleplayingpcgames.info）

發展強而有力的學習機制

遊戲本身就是一種學習過程。在動作射擊類型的遊戲中，藉由探索遊戲環境以及試驗各種不同的武器效果，我們學會如何在適當的時機選擇使用最合適的戰鬥方式。

物理學特別適合用於這種自學式的機制中，因為我們都知道它在真實世界中是如何地運作。我們出自本能地知道萬有引力與流體力學會影響潑灑出來的水，所以只要提供給玩家們仰賴物理學的遊戲機制，將能夠使他們學會如何找出複雜問題的答案。

允許玩家建造自己的工具

物理學的出現，使得扭曲破壞遊戲中的物件，例如裝甲、管線或橫樑變得可行。我們可以想像，如果玩家能夠依照自己的需求形塑出自己的武器、謎題的解答或者通過關卡的途徑，例如藉由扭曲某些金屬片，玩家可以建造出水渠或者球的通道等等，或許遊戲也可以變得更加有趣而多元化。

這種類型的物理學應用項目，或許只能夠運用在某些特別的遊戲，像是解謎類型的遊戲或者生存類型的遊戲中，而且操作介面也會有許多限制，但是遊戲潛在可能發展出來的樂趣非常龐大。如果可以讓玩家使用具有物理性質的磚瓦材料來建造東西，將能夠使玩家們建造出完全獨一無二的遊戲環境。

雖然在本篇文章中提到的某些想法，目前可能還沒有辦法達成，但是隨著可預期的科技發展與工具發明，未來將會賦予遊戲開發者全新的能力。從今以後，物理學不只可以運用在裝飾性的效果上，更能夠用來增進核心的遊戲性機制。而對於遊戲設計者與關卡設計者而言，也必須利用這些新技術帶給玩家更多新鮮有趣的娛樂體驗。物理學，使一切不可能變成可能。

自從 Ageia 被 NVIDIA 收購以後，「物理加速卡」就從消費市場上消失無蹤，改由效能突飛猛進的繪圖顯示卡提供物理引擎的硬體加速功能。當 ATI、NVIDIA 甚至 Intel 的顯示卡與顯示晶片，將物理引擎的硬體加速功能推向普羅大眾，成為每台電腦中的標準配備時，不論你是美術設計者、企畫設計者或程式設計者，我們都將會擁有全新的力量以及隨之而來的艱鉅挑戰。

以我在最近幾個月內玩過的幾款遊戲來說，我認為將物理學運用在主要的遊戲性機制上，並且得出十分出色成果的遊戲，包括之前提過的《World of Goo》、用蠟筆畫出謎題解答的《Crayon Physics Deluxe》，以及使用 Flash 製作的物理解謎遊戲《Fantastic Contraption》。從這些遊戲中，讓我們見識到即使是以 2D 畫面形式呈現的遊戲，同樣能夠充分應用各種物理學的理論知識，而且遊戲性也完全不會輸給 3D 形式的遊戲。

前一陣子如果各位有注意《Diablo 3》的展示影片的話，應該不難發現，物理引擎的功能將會在這款萬眾矚目的遊戲中，扮演舉足輕重的遊戲性機制。就讓我們一起思考也一起期待，物理學在遊戲中的應用與發展吧！除了上面提到的這幾款遊戲以外，你有玩過什麼令你印象深刻的物理學遊戲嗎？或者是曾經見過將物理學特性運用的很出色的實例？非常歡迎各位一起提出來討論唷～ ：D

如果你使用的作業系統是 Linux、Mac 或其他非 Windows 平台，你可以忽略這篇文章；如果你使用的作業系統是 Windows 平台，但沒有用 Microsoft Visual Studio C++（以下簡稱為 MSVC）軟體撰寫 C++ 程式的話，這篇文章對你的幫助可能很有限；但如果你的作業系統是 Windows，而且你使用的程式整合開發環境是 MSVC 軟體撰寫 C++ 程式的話，這篇文章應該能夠幫助你釐清一些重要的基礎觀念。

身為程式設計者，在學習程式設計的過程中，你是否曾經遇過某些看起來不知所云的錯誤訊息，卻不知該如何解決？例如當你快快樂樂地寫完程式，並且確認所有的程式碼都能成功通過編譯之後，接著執行「建置方案」(Build Solution) 的步驟，結果卻跑出一堆莫名其妙的錯誤：

LIBCMTD.lib(mlock.obj) : error LNK2005: __lock 已在 MSVCRTD.lib(MSVCR80D.dll) 中定義過了
LIBCMTD.lib(mlock.obj) : error LNK2005: __unlock 已在 MSVCRTD.lib(MSVCR80D.dll) 中定義過了
LIBCMTD.lib(crt0.obj) : error LNK2005: _mainCRTStartup 已在 MSVCRTD.lib(crtexe.obj) 中定義過了

…………

LINK : warning LNK4098: 預設的程式庫 ‘MSVCRTD’ 與其他使用的程式庫衝突，請使用 /NODEFAULTLIB:library
LINK : warning LNK4098: 預設的程式庫 ‘LIBCMTD’ 與其他使用的程式庫衝突，請使用 /NODEFAULTLIB:library
D:\Workspace\CrtLibTest\Debug\CrtLibTest.exe : fatal error LNK1169: 找到有一或多個已定義的符號

以一般的情況來說，如果在你的程式專案中有使用某些由他人所撰寫的第三方程式庫或是開源專案的程式庫，比較容易會發生上述的錯誤狀況。從上述這些看似離奇而令人摸不著頭緒的錯誤訊息中，我們大概可以猜測問題點應該在於 LIBCMTD.lib 與 MSVCRTD.lib 這兩個程式庫身上。但到底什麼是 LIBCMTD.lib 和 MSVCRTD.lib？在我們的程式碼中有使用這些程式庫嗎？

答案是肯定的。

熟悉 C 語言的程式設計者都知道，如果要使用 printf()、scanf() 或者 fopen() 等等 C 語言的基本 I/O 操作函式時，首先必須用 #include 語法將 stdio.h 這個標頭檔納入我們的程式碼中。藉由 stdio.h 中對這些 I/O 操作函式所做出的函式宣告 (function declaration)，編譯器 (Compiler) 才得以確認 printf、scanf 以及 fopen 等等都是合法可用的函式。

而當我們撰寫的程式碼經過編譯器產出 OBJ 形式的檔案之後，需要再經由連結器 (Linker) 的處理程序，將程式碼中全部有使用到的函式定義 (function definition) 連結建置起來，才能夠產生出最後的程式執行檔。問題來了，我們知道 printf、scanf 以及 fopen 的函式宣告存在於 stdio.h 當中，但是這些傢伙的函式定義，也就是真正的實做程式碼，究竟存放在什麼地方呢？

在 C 語言的標準程式庫中。

由 C 語言所制訂的標準程式庫，稱之為「執行階段程式庫」，也就是 C Run-Time Library，通常可簡稱為 CRT。在 C 語言的標準程式庫中，包含了一組常用的基礎函式，例如 I/O 處理與字串操作程序等等，所以只要我們使用 C 語言撰寫程式碼，就一定要將編譯完成後的程式碼 OBJ 檔，連結至 C 語言的執行階段程式庫，才能夠產生出合法的 C 語言程式執行檔。

而 CRT 並非只有單一一種版本存在。事實上，除了可以依「除錯」與「釋出」用途分成兩個版本之外，兩者又可分別衍生分出「靜態連結」與「動態連結」兩種形式：

靜態連結：

• LIBCMTD.lib（除錯版本）
• LIBCMT.lib

動態連結：

• MSVCRTD.lib（除錯版本）
• MSVCRT.lib

雖然這四個 CRT 版本的用途與使用方式各不相同，但卻有個共通的特點，就是它們都是滿足執行緒安全需求，可在多執行緒程式碼中安全使用的程式庫版本。事實上，在過去 MSVC 6 的版本中，本來還有另外兩個 LIBCD.lib（除錯版本）與 LIBC.lib 程式庫，是專門給單執行緒程式使用的 CRT 版本，但是這兩個選項自 MSVC 2005 開始就從設定選項中被刪除掉了，所以現在大多數程式設計者使用的都是多執行緒的 CRT 版本。

在程式庫連結 (library linking) 的行為中，靜態連結和動態連結的分別，在於使用靜態連結時，會直接將程式庫的函式定義嵌入執行檔之中，而使用動態連結時，程式庫的函式定義則存在於另外的獨立檔案，通常是 DLL 格式的檔案中，然後與程式執行檔一同發佈給使用者。因此在檔案的尺寸上，使用動態連結的執行檔檔案，通常會比使用靜態連結的執行檔檔案來得更小一些。

使用動態連結 CRT 版本的好處，是能夠將經常使用到的標準程式庫們獨立出來，放在 Windows 的系統資料夾中，以減少我們建置出來的執行檔檔案尺寸。但反過來說，使用動態連結 CRT 版本的缺點也在於這些與執行檔相依為命的 DLL 檔案上。舉例來說，如果程式以 MSVC 2005 建置出 Debug 組態的執行檔，則此執行檔需要有 msvcr80d.dll 存在才能順利執行；如果是 Release 組態，則相依於 msvcr80.dll。但是如果你把相同的程式碼拿到 MSVC 2008 上建置，產生出來的執行檔則相依於 msvcr90d.dll 與 msvcr90.dll 兩個不同的 DLL 檔案。不同版本的 MSVC，都會有各自不同的相依 DLL 檔案。

在 MSVC 的程式專案中，如何指定程式碼要使用靜態連結或者動態連結的 CRT 版本？其實很容易，只要在專案屬性的「C/C++」頁面中，選擇「程式碼產生」(Code Generation) 子頁面，其中有個「執行階段程式庫」(Runtime Library) 的項目，也就是專案中用來設定 CRT 連結版本的地方。其中總共有四個選項，正好對應於上述靜態連結與動態連結的四個不同程式庫版本。

• 多執行緒偵錯 (/MTd)：對應 LIBCMTD.lib
• 多執行緒 (/MT)：對應 LIBCMT.lib
• 多執行緒偵錯 DLL (/MDd)：對應 MSVCRTD.lib
• 多執行緒 DLL (/MD)：對應 MSVCRT.lib

如果你沒有做任何設定就開始建置程式的話，MSVC 的預設選項則會使用動態連結的版本。

C Runtime Library

請注意，以上只是單純 C 語言的程式庫而沒有包含 C++ 語言在內。如果你的程式系統中，有包含 C++ 語言的程式碼的話，那又是另外一回事了。但是在專案屬性的頁面中，為什麼找不到相關的設定選項呢？因為 MSVC 悄悄地幫程式設計者代勞處理掉了。只要在程式碼中使用 #include 語法納入任何一個 C++ 的標頭檔，例如 iostream 或 fstream，MSVC 就會在連結器的運作階段中，自動幫我們連結 C++ 的執行階段程式庫。而 C++ 的執行階段程式庫，同樣可分為四個版本：

靜態連結：

• LIBCPMTD.lib（除錯版本）
• LIBCPMT.lib

動態連結：

• MSVCPRTD.lib（除錯版本）：執行檔相依於 MSVCP90D.dll
• MSVCPRT.lib：執行檔相依於 MSVCP90.dll

至於程式執行檔使用的是靜態連結或者動態連結的版本，就仰賴於 C 語言的版本設定選項了。舉個例子來說，如果你撰寫了一個 Debug 組態的 C++ 程式，並且保留專案原先預設的建置選項（動態連結），那麼最終建置出來的程式執行檔將會相依於 MSVCR90D.dll 以及 MSVCP90D.dll 兩個 DLL 檔案。如果將相同的程式以 Release 組態建置完成，則會相依於 MSVCR90.dll 以及 MSVCP90.dll 二者。

Standard C++ Library

剛學習程式設計的入門者，經常會在滿心歡喜地完成一件程式作品並且傳給其他人使用時，卻發現不能在別人的電腦上啟動程式，其實就是陷入了使用者電腦缺少 DLL 檔案而無法執行程式的窘境。有三種方法可以解決這個令人困擾的問題：

1. 使用者的電腦，必須先安裝「Visual C++ 可轉發套件」（MSVC 2008 或 MSVC 2005 ）。
2. 將所需的 DLL 檔案，例如 MSVCR90D.dll 與 MSVCP90D.dll，直接附在程式的下載包當中。
3. 以靜態連結方式建置程式執行檔。

當你無法確定自己的程式或別人的程式，是否相依於某些特定的 DLL 檔案時，有一個非常好用的免費工具程式 Dependency Walker，可以開啟 EXE 格式的執行檔或者 DLL 格式的動態程式庫，然後詳細地條列出它們所相依的 DLL 檔案。

瞭解了幾種不同的 CRT 版本選項之後，回到最前面的錯誤訊息問題，相信各位現在應該能夠很清楚地理解，原來會發生這些奇怪的錯誤狀況，是因為程式同時連結了 LIBCMTD.lib 與 MSVCRTD.lib 所以造成函式定義版本衝突。也就是說，程式連結器已經在其中一個 CRT 的版本中找到所需的函式定義，但此時卻又跳出另外一位 CRT，也給了一份相同函式的實作版本，所以連結器無法判斷應該忽略誰並且選擇誰。

而這個狀況的發生原因，就是你的程式與程式所連結的外部程式庫，使用了不同的 CRT 版本之故。例如，當你的程式使用了 Lua，自然必須連結至 Lua 的程式庫 lua5.1.lib，但如果 lua5.1.lib 是以靜態連結版本的 CRT 建置而成，而你的程式卻是以預設選項，動態連結 CRT 來建置程式執行檔的話，如此一來就會產生上述這些錯誤訊息了。至此，問題的答案已昭然若揭，解決方法有二種：其一是將 Lua 重新以動態連結 CRT 的方式建置出一個新的程式庫，其二則是將自己的程式專案改成以靜態連結 CRT 方式建置。

換個角度想，當你身為一位程式庫的設計開發者，想要將自己寫的東西分享給其他人，但又不想要完全開放自己撰寫的程式源碼時，至少可以同時提供以下四種版本的程式庫，以妥善滿足使用者的各種不同需求：

• Debug：動態連結除錯版本
• Release：動態連結版本
• Debug_Static：靜態連結除錯版本
• Release_Static：靜態連結版本

然而，有時候世界並不會運作得如此理想。在某些特殊的狀況下，當我們使用他人所寫的第三方程式庫時，有時可能只拿得到其中某個特定的版本，例如 Release_Static 版本時，就很有可能會遇到程式庫衝突的錯誤情形。此時就需要視專案的實際需求而定，可以在專案屬性中指定「忽略特定程式庫」(Ignore Specific Library) 這個選項，讓程式碼連結器忽略某些程式庫，以此化解動靜程式庫或新舊程式庫之間的恩怨衝突。

小測驗：你所撰寫的程式，必須連結某個以靜態多執行緒 (/MT) CRT 建置而成的程式庫。如果你的程式在 Debug 組態下以多執行緒偵錯 (/MTd) 選項建置，是否會產生衝突？如果你的程式在 Release 組態下以多執行緒 (/MT) 選項建置，是否會產生衝突？是的話，應該如何解決？

延伸閱讀：

• [MSDN] Visual Studio 2008: C Run-Time Libraries
• Dynamically linking with MSVCRT.DLL using Visual C++ 2005

「有許多人以為他們想要製作遊戲，但是只有非常少數的人瞭解遊戲開發所需的投身奉獻與持續耐久力。在專案最初的興奮感褪去之後，你必須在數以月計或數以年計的日子中，身處看不見光線的隧道盡頭裡辛勞地工作。你必須足夠熱愛製作遊戲，以致於就算在視線中看不見終點或者金錢時，仍然能夠保有無與倫比的熱情。」—— Jacob Stevens

（圖片來源：www.paec.org）

在 18 年前，當 Jacob Stevens 只有 8 歲大，而他的弟弟 Paul Stevens 只有 4 歲大的時候，他們就下定決心要為任天堂公司製作遊戲。當時他們並不知道要做些什麼，更不懂該如何去做。雖然如此，在將近 20 年的時間之後，他們成功達成了童年的夢想。這是一篇為任天堂的遊戲平台製作遊戲，也為自己實現夢想的真實故事。

RiverMan Media 是一間由 Jacob 與 Paul 兩人共同創立的小型獨立遊戲開發公司，而《MadStone》是一款 2D 型態的方塊掉落解謎遊戲，也是他們所製作的第一款 WiiWare 平台遊戲，售價 8 塊美金。在這款遊戲之前，他們曾於 PC 平台發售兩款表現中規中矩的休閒遊戲《Cash Cow》以及《Primate Panic》。

標題的 Postmortem 是「後鑑之明」的意思，也就是在完成整個遊戲並且發行上市之後，重新回頭檢視專案開發過程中的種種是非對錯。在龐大的遊戲產業中，或許 RiverMan Media 只是一個微不足道的小公司，但在這篇自我檢討的文章裡，Jacob Stevens 非常坦然且毫無保留地剖析他們的心路歷程，娓娓道來許多令人深思的想法。看看他們做對與做錯的事情，再回頭想想自己，或許也能夠使我們的遊戲開發旅程少走一些冤枉路。

同時，我也想將這篇文章獻給所有對遊戲設計感興趣，以及將遊戲產業視為未來職涯目標的讀者們。

我們做對的事情

1. 獵捕任天堂

當時 Jacob 在 IBM 公司從事使用者介面設計者的兼職工作，有天他的同事告訴他關於任天堂新推出的 WiiWare 遊戲下載服務平台，主要目標是針對比較小型的遊戲專案與獨立遊戲開發者所設立。他的同事建議他，應該藉由這個管道去追求製作 Wii 平台遊戲的機會。而 Jacob 一開始的反應是：「不可能！」雖然他從小就是任天堂的愛好者而且也很喜愛 Wii 遊戲機，但是他認為他的公司太小、經驗太嫩而且資金太少，所以不可能達到這樣的目標。再者，這個直接追尋童年夢想的遠景，也讓他感到有點害怕：如果我把事情搞砸了怎麼辦？

之後 Jacob 在 Google 上查到了任天堂公司的電話號碼。他並沒有期待會有任何好事發生，只是拿起電話撥通了任天堂公司的號碼。很顯然任天堂公司的電話接待員並不常接到這樣的電話，在一陣等待之後，最後終於幫他接通了 WiiWare 平台的業務代表。那位先生告訴 Jacob，下週他將會參加在奧斯汀舉辦的遊戲開發者會議，他很願意在那時私下與他會面。

於是 Jacob 在最後一刻買到了機票前往德州奧斯汀，但很不幸的是，他根本沒有事先計畫要在何時何地與任天堂的業務代表碰面。更糟的是，任天堂公司並沒有任何的展示攤位，所以當他到達會場時，只能夠瘋狂地用眼睛掃射每個人身上的名牌，希望能夠遇到那位從任天堂來的傢伙。但他的運氣不夠好。

最後，在絕望的情形下，他再次 Google 了任天堂公司的電話，然後撥過去拜託他們給他那位業務代表的電話號碼。當然，Jacob 能夠理解，給予員工的電話號碼通常是違反公司政策的行為，但他只能夠拼命地向他解釋緣由，而且這場會議就快要結束了，他真的非常需要幫助。最終任天堂公司打破規定，給了 Jacob 那位業務代表的電話號碼！

就在任天堂業務代表上飛機前的幾個小時，Jacob 終於得以與他會面共進咖啡。Jacob 告訴他關於 RiverMan Media 公司的事情，並且解釋他們有多麼想為任天堂的遊戲機製作遊戲。最後，任天堂業務代表同意 RiverMan Media 公司的目標聽起來很適合 WiiWare 平台。Jacob 感到無比的狂喜。

後來花費了三個月左右，數十通電話與電子郵件往返，以及許多令人苦惱的事情之後，最終 RiverMan Media 總算跨越了「成為 Wii 遊戲開發者」的那道門檻。這是個令人挫折的程序，Jacob 甚至經常在想他是否做了正確的決定。但是當他們通過痛苦的考驗之後，他們變得與任天堂內部的幾位關鍵人物更加親近，甚至還幫助他們以折扣的價格，從其他公司取得遊戲的開發套件！

訓誡：要踏進那道門並不容易。為了穿越門檻，非得跨出你的舒適區不可。

2. 堅守 2D

Jacob 堅信的原則是：低預算的 2D 看起來會比低預算的 3D 遊戲好得多。而且非常多。

選擇使用 2D 的方式來製作遊戲，對他來說是理所當然而且不用經過思考的決定。但除了個人的偏好因素以外，還有幾個採用 2D 製作方式的好理由：

• 一般而言，2D 專案的美術工具流程極度簡單。在大多數的情況下，Photoshop 就是他們唯一的工具流程。
• 只需要非常少量的程式碼支援遊戲的成像功能。沒有骨架、皮膚或者曲面運算，這裡只有像素點。
• 因為現今的遊戲機平台，能夠在每秒內畫出上百萬個含有貼圖的三角形，所以使用 2D 從來不需要擔心效能的問題，即使擁有非常多的物件與粒子特效也一樣。
• 能夠簡化碰撞處理與物理反應。
• 遊戲機制傾向於比較容易調整。
• 訓練 2D 的美術設計者比 3D 的美術設計者容易許多。

另一項關鍵的要點，在於現在的 2D 遊戲比 3D 遊戲稀有許多，所以有趣的 2D 遊戲自然能夠獲得玩家與媒體的注意。總而言之，Jacob 認為對於他們的公司來說，3D 遊戲並不是一項好的選擇，因為 3D 有太多太複雜的東西需要處理，會分散他們對於遊戲本身的注意力。或許多數玩家會告訴你他們比較喜歡 3D 遊戲，但他相信 2D 圖件與圖塊的表現形式，總是有空間可以生存！

訓誡：與其被尖端技術分心困擾，最好使用讓團隊感到舒適無慮的技術，才能夠使你專注在遊戲本身之上。

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

3. 採用優雅與可靠的 Slag

Jacob 在 IBM 公司時學到的秘密：幾乎所有企業等級的商業與醫療軟體，現在都是以 Java 或其他高階的資源管理式程式語言撰寫。

你或許會想抱怨有關效能以及缺少指標操作的問題，但是在大型軟體中使用 Java 有很好的理由：程式設計者會產生出比較少的臭蟲。因為程式設計者無須分心於低階記憶體的管理程序上，而能夠直接專注在解決問題與撰寫簡潔的程式碼中。正因如此，Jacob 與他的兄弟 Paul 在創立 RiverMan Media 公司時，首要之務就是確保他們有個能夠將遊戲的程式碼，從低階位元操作抽取出來的開發平台。

很幸運地，他們的一位好友 Abe Pralle，提供給 RiverMan Media 一個很合適他們需求的開發平台 Plasmacore，以及一套特別的程式語言 Slag。他們在先前開發的兩款遊戲《Cash Cow》與《Primate Panic》中，已經使用了 Plasmacore 結合 Java 與 DirectX 的優勢，得到非常令人滿意的執行成果。

但是 Java 的執行期函式不僅容量太大，而且也無法在 Wii 平台上執行。所以他們必須為《MadStone》尋找新的解決方案。最終他們成功地由 Java 環境，轉換到了由 Abe 所撰寫的程式語言 Slag 之中。Slag 是一個由遊戲開發者實作，同時也是為了遊戲開發者所製作的程式語言。Slag 的程式語法與 Java 以及 BASIC 很相似，優點在於它的執行期函式庫僅有幾百 KB 的大小而且很容易移植。另外，Slag 也能夠結合 C++ 語言的程式碼，大幅增進遊戲的效能表現。

訓誡：程式語言是程式設計者的表達媒介，選擇一個語言與框架，讓你的程式設計者能夠專注在遊戲而非電腦之中。

4. 獲得資訊學位，同時製作商業遊戲機平台遊戲

Jacob 的弟弟 Paul 在他就讀大學的第一個學期裡，開始為他們的公司撰寫商業遊戲程式。之前他完全沒有任何了不起的程式設計經驗，他只知道他喜歡遊戲和電腦。事實上，在他為 RiverMan Media 撰寫第一款商業遊戲《Cash Cow》的程式時，他才剛學到了「函式能夠回傳數值」的程式設計基礎知識，在此之前，他所寫的程式碼全都是由全域變數與靜態陣列所組成！

Paul 需要處理完整的大學課程負擔，同時為一款商業遊戲機平台遊戲撰寫程式，對他來說無疑是一項非常艱鉅的挑戰。他本來可以選擇只做學校的功課或者只做公司的工作，但是他沒有放棄任何一方。有效地安排時間以管理學校與公司兩者的事務，是對於他的專注力與意志力的一項嚴峻測試。而他成功了。

Paul 能夠達到這番令人印象深刻的奉獻的秘密非常簡單：他熱愛花費時間製作遊戲勝過所有一切。

有許多人以為他們想要製作遊戲，但是只有非常少數的人瞭解遊戲開發所需的投身奉獻與持續耐久力。在專案最初的興奮感褪去之後，你必須在數以月計或數以年計的日子中，身處看不見光線的隧道盡頭裡辛勞地工作。你必須足夠熱愛製作遊戲，以致於就算在視線中看不見終點或者金錢時，仍然能夠保有無與倫比的熱情。

Paul 將原本玩遊戲的熱情，轉換成為 GPA 4.0 的學業成績表現，再加上一款設計良好、精巧實作的商業遊戲作品。他為渴求成功的獨立遊戲開發者所需具備的心態，設立了一個良好的典範。

訓誡：遊戲開發是一份許多人渴望從事，但很少人真正理解的職業。你要徹底地熱愛創造遊戲，否則請挑選其他比較輕鬆的職業吧！

5. 展現良好的態度，即使當我們不想要這麼做時

他們在《MadStone》的開發過程中，意外流出了幾張遊戲截圖與短片。一開始，他們從媒體報導所獲得的回應有些負面且具有敵意。主要來說，部落格裡的輿論者們似乎忽略了這款遊戲的特點，而只是把焦點放在「又一款 WiiWare 的解謎遊戲」這樣的陳述中。除此之外，遊戲的音樂、遊戲性與圖像也同樣遭致批評。

Jacob 的第一個直覺反應，就是要挺身而出捍衛自己的遊戲作品。然而在他冷靜下來之後，他想或許忽略這些言論是比較好的作法。但最終，他們決定跳下來參與討論。他們首先介紹了自己的身份，並且回應讀者們的留言迴響。與其向外捍衛自己的遊戲，他們只是解釋了他們的遊戲目標，並且讓讀者自行判斷他們是否感興趣，同時也釋出許多善意感謝他們的迴響。

而他們迫使自己支援這些強硬讀者的作法，立即就得到了回饋。部落格裡的文章與迴響，很快就從輕視否定的態度，轉變為發自內心的關心與支持。他們開始收到愛好者的來信，網站編輯也來信感謝他們參與討論，甚至還向他們要求獨家訪問以及遊戲的預覽。一般而言，Jacob 認為玩家很高興能夠有機會與真正的遊戲開發者互動。雖然沒有明確的數據，但 Jacob 認為《MadStone》早期的銷售量，很多都是來自於他們積極和讀者參與討論的網站。

訓誡：線上社群可以成就或者破壞你的遊戲。參與、回答他們的問題、接受他們的評論，同時最重要的是，要誠實以對。

我們做錯的事情

1. 以為我們能夠做出一款出眾的方塊解謎遊戲

RiverMan Media 的第一款遊戲作品，是在 PC 平台上發售的方塊消除解謎遊戲《Cash Cow》。因為他們非常熟悉這種類型的遊戲，所以他們覺得為 WiiWare 平台製作另外一款方塊消除解謎遊戲，應該會是一項正確的選擇。他們認為他們能夠增加足夠多的變化，使《MadStone》變得獨一無二而且令人興奮。

然而 Jacob 承認，選擇製作一款方塊掉落解謎遊戲，是一個嚴重的錯誤。

當他們宣布了《MadStone》的開發消息之後，玩家們的回應冷淡而輕視。就像先前所提的一樣，許多部落格迴響以及論壇文章都認為，《MadStone》不過又是另一款解謎遊戲罷了，很少人對於遊戲所擁有的特點感興趣。為了不被這些質疑的聲浪擊倒，他們非常努力地賦予《MadStone》有趣的遊戲機制與獨特的美學風格。

難道玩家們不喜歡《Tetris Attack》、《Meteos》與《Lumines》這些經典的方塊消除遊戲嗎？他們當然喜歡，問題在於過去幾年內，已經有太多太多配對消除類型的遊戲氾濫成災。不止在休閒遊戲的入口網站中有上百款這樣的遊戲，更有許多是以免費 Flash 遊戲形式發佈的作品。

無論《MadStone》表現得有多棒多有趣，它仍然是個方塊消除解謎遊戲。即使 Jacob 他們已經克盡全力使它在眾多相同類型的遊戲中脫穎而出，但不幸的是，玩家們已經在其他的形式中，見過《MadStone》許多、許多、許多次了。玩家喜歡被給予驚喜感與興奮感，但是一般標準規格的解謎類型遊戲無法做到。驀然回首，Jacob 瞭解《MadStone》的命運早在它被構想出來時就已經被決定了。

訓誡：選擇一個會引起人們注意的主題與類型。如果你見到你自己的遊戲被發表在部落格上時，你會感到興奮雀躍嗎？

（圖片來源：www.wiiware-world.com）

2. 想得太復古

與選擇一個已過流行的遊戲類型的不幸相符，他們也選擇了效法以前那些受歡迎的老遊戲，做為他們在《MadStone》設計抉擇上的參考指標。

Jacob 與 Paul 兩兄弟從小就喜歡玩方塊消除類型的遊戲，不僅花費了數以百計的時數在《Tetris Attack》與《Puyo Puyo》中，也一直把這些遊戲視為他們的最愛。正因為他們對於這些遊戲的高度重視，他們也很自然地將這些遊戲視為設計《MadStone》時的評判基準。更明確地來說，他們選擇在遊戲中加入比較少量經過仔細平衡的遊戲模式，試圖仿效過去那些成功的方塊消除解謎遊戲。

而這是另一個天大的錯誤。在過去的日子裡，雖然《Tetris Attack》與《Puyo Puyo》只有非常有限的遊戲模式，卻是能被玩家接受的設計機制，而以現今的方塊解謎遊戲來說，玩家們則預期會有大量不同的遊戲模式以及混合選項。基本上，《MadStone》只有提供少量額外的關卡與不同的勝利條件給遊戲的競爭模式。如果與其他現今的解謎遊戲，例如《Tetris Party》相比，這款遊戲甚至能夠讓玩家使用 Wii 平衡板來操縱遊戲，相形之下《MadStone》給人的印象就是缺少功能特點。

Jacob 認為當初應該花費更多的時間研讀現今的方塊解謎遊戲，如果當初有這麼做的話，他們就會很清楚在《MadStone》中非常有限的遊戲模式並不足夠。然而，他們追隨著老遊戲的腳步做出決定，而沒有瞭解這個產業已經毫不間斷地往前跨出了許多步伐。

訓誡：鍾愛陪伴你成長的遊戲很好，但別忘記你的遊戲將會被拿來與最新以及最棒的遊戲做比較。

3. 懶惰（並且希望媒體會原諒我們）

當我們談到網站、雜誌與各種媒體上的遊戲評論者時，他們最具有影響力的工作，可以說就是根據他們主觀的遊戲經驗，給予一項數字化的成績評斷。而在那些評論中所寫的文字，無論是否與評斷出來的分數有些什麼樣細微的差異存在，都會被這個單一的「分數」數字所掩蔽。但分數真正代表的意思是什麼？是對比於金錢花費的價值嗎？是對比於相同類型相同平台的其他遊戲的品質嗎？還是對比於所有現存遊戲的品質？

由於 Jacob 他們決定將《MadStone》的售價定為 8 塊錢美金，僅僅是一般 Wii 平台零售遊戲的五分之一至七分之一左右，所以他們認為評論者應該會對遊戲中缺少的一些特點，像是額外的遊戲模式、寬螢幕支援、多種控制方式、多人連線模式，以及漸進式掃瞄等額外功能睜一隻眼閉一隻眼。

但是他們錯了。每一篇評論都十分徹底地提到了《MadStone》所缺少的這些特點，而且對遊戲造成很深的影響。以 IGN 網站的評論為例，在滿分為 10 分的評論基準中，他們只給了《MadStone》4 分的總評成績，非但無法幫助遊戲的銷量，反而使得銷售狀況更加令人失望。

最初 Jacob 對於評論者竟然對一款 8 美金的遊戲，如此著重在那些缺乏的特點感到生氣。沒錯，它當然有短少功能！它可是由三個人製作出來的遊戲作品！靜下心來之後，他瞭解這些狀況至少有一部份可以避免。再多出額外幾週的工作，他們應該能夠實作出額外的遊戲模式、寬螢幕支援與漸進式掃瞄等等功能。但是他們沒有做，因為他們認為不需要。

大多數的這些功能都不會使遊戲本身更加有趣。但事實是，這份短少功能的清單使得《MadStone》很輕易地得到糟糕的分數評價。Jacob 希望他們當初有花費時間加入那些他們早就知道缺少的功能。他們當初有意識地做了決定，在某點上畫出一條界線，所以才能夠在專案時程內完成遊戲，但現在他認為，或許應該將這條界線畫得稍微更遠一點。

訓誡：不要給評論者有機會對你的遊戲輕易下標記。如果你能夠以較少的花費實作出常見的功能特點，就要去做。即使這些特點無法真正加強遊戲本身的內涵。

4. 生產力殺手：網路

身為一位獨立遊戲開發者，當你一早坐下來準備開始工作的時候，你有很多的選擇可做。在《MadStone》的一般開發日子中，Jacob 的所擁有的選擇包括繪製背景圖片、製作動畫圖件、撰寫特效程式碼、撰寫市場行銷內容、安排遊戲測試程序、改善遊戲平衡、為遊戲音效錄音，以及處理與任天堂之間的事務等等許多待辦工作。

面對以上所有的可能性，Jacob 通常訴諸最顯而易見的解答：檢查電子郵件以及閱讀 Slashdot 網站。

Jacob 斬釘截鐵地說，如果當初在工作時拔掉網路線的話，《MadStone》肯定能夠成為一個更好的遊戲作品。閱讀部落格文章比製作遊戲容易許多，而他的腦袋似乎已經習慣了採取比較輕鬆的途徑（我們又何嘗不是？）。所以他經常花費數個小時懶散地在網路上瀏覽網站，幾乎沒有完成任何重要的事情。

直到遊戲專案的時程進行了三分之二時，Jacob 終於開始接受事實，瞭解他的這項習慣會讓他的工作進度緩慢下來。於是他採取了比較激進的措施：反安裝 Gmail 的郵件通知軟體、刪除 Firefox 的捷徑，甚至在製作美術與音樂素材時拔掉網路線。這項轉變並不容易。好一陣子以來，他的眼睛總會本能地注意螢幕右下角的常駐列是否有新信件。滑鼠的指標，則彷彿有自己的意志力般，也會不由自主地移向之前 Firefox 捷徑圖示所在的位置。

在經歷過一段孤獨與隔離的苦痛之後，Jacob 終於克服了工作時不能上網的煎熬感受。現在他不止能夠工作更多的時間，而且產出物的品質也更好了。他真正地感覺到與工作的連結感，甚至開始體驗到所謂的「心流」(Flow) 狀態，好像進入了一個充滿生產力的區域，所有工作都能夠自動完成。這是在每過幾分鐘就休息上網的時候，所不可能存在的感受。

訓誡：當你工作的時候，工作。全神貫注在手邊的任務上。如果需要的話，拔掉網路線。以一天內休息幾次比較持續的時間，替代每幾分鐘就休息一陣很短的時間的作法。

5. 低估自己

對於 Jacob 的團隊來說，《MadStone》的確是一項龐大的成就。他們耗盡了極大量的心智能量使《MadStone》得以成真。但不幸的是，在整個遊戲產業中，《MadStone》充其量不過發出了一點點微弱的聲響而已。有時得到讚賞，有時得到不受歡迎的回應，但更多時候只是被忽視而已。部分原因是由於他們只是這個巨大產業裡的小小公司而已，而部分原因則是因為他們保留做出更好作品的態度。

（圖片來源：prblog.typepad.com）

獨立遊戲開發是不是一個充滿創意的沙池，讓我們能夠實現孩童時代的想像力？絕對是。但 Jacob 所沒有料想到的是，要將靈感費力拉出腦袋是多麼困難的一件事情。相信你自己所擁有的潛力是一回事，而坐在一片空白的螢幕前，將潛力化成具有美感與機制的實在遊戲，則全然是另外一回事。

Jacob 希望當初能夠把創意再推得更遠一點。他們曾製作出許多更具有創新性以及令人興奮的點子，但是太過於擔心自己無法實現這些想法。他認為他們陷在自己所知的事物當中，以專案管理的觀點來說或許是好的，但是他總是在想如果當初他們再多做一點點，會發生什麼樣截然不同的結果。

訓誡：你是藝術家，而且你的工作是推升創意的極限。比你所盡的最大努力再多做一點，讓你的遊戲是只有你們的團隊才能產生的作品。

以上，就是 RiverMan Media 的遊戲開發者們與《MadStone》的故事。

誰說只有那些名聞遐邇的大牌遊戲製作人，所說的話或所寫的文章才能夠帶給我們寶貴的收穫？我認為比起成功者的經驗分享，這些失敗的經驗教訓反而更加難能可貴。在一般人以成敗論英雄的價值觀裡，Jacob Stevens 與他的伙伴們鼓起勇氣坦然面對一切的成果，真切檢討自己做對與做錯的事情，著實令人十分感動。

而且除了從錯誤中習得的血淚教訓之外，他們的故事裡更傳遞出許多激勵人心的正面訊息。他們的團隊總共只有 3 位開發者，1 萬美金的預算，以及 8 個月的時程，就製作出了他們的第一款 WiiWare 平台遊戲。這是他們的童年夢想，而他們做到了！雖然結果並非盡如人意，但我相信，這不是他們夢想的終點，而是他們所跨出的第一步。

你是否因為喜歡玩遊戲，所以希望自己將來能夠成為遊戲的創造者，親手製作出超讚超酷超好玩的遊戲？擁有夢想，是一項美好的恩賜；然而，只有夢想並不足夠。我們都知道，玩遊戲是一件非常快樂、非常有趣，而且非常令人滿足的事情。但是做遊戲，則完全是另一回事。

製作遊戲並不是變魔術，只需要輕敲手中的魔杖，創意和遊戲作品就會像兔子一樣神奇地蹦出來。如果你認為做遊戲就像玩遊戲一樣，能夠很迅速地讓你得到無比的興奮感與成就感的話，或許你並不適合將遊戲開發設定為你的職涯目標。換個角度想，如果你相信在其他的專業領域中，無論是誰都必須投注大量的心力才能夠獲得美好的成果，那麼「遊戲開發」與「遊戲設計」為什麼該是個例外？

在本文最前頭引用 Jacob 所述的一席話，將我的感受完整無缺地表達了出來。希望各位想要進入遊戲業界，從事遊戲設計與開發工作的讀者，能夠將這段話銘記於心。 ：）

Strategy Pattern

身為一位程式設計者，你是否曾面臨條件判斷式繁殖過盛的困擾？經常用折疊不完的 N 層 if-else 結構來考驗自己的腦力？或是只能瞪著超過 500 行的 switch-case 條件判斷式舉手投降？您的困擾我瞭解，請容許我向您引薦本篇文章的雙主打星——Strategy 與 State 範式，讓它們帶領我們一同邁向美妙動人的範式之道吧！

首先要瞭解的是，為什麼要將 Strategy 與 State 範式放在同一篇文章裡介紹？因為兩者雖然在設計層面的動機與出發點有所差異，但是在實際的應用面中非常地相近。根據《物件導向設計模式》(Design Patterns) 書中的定義，只要將右圖中的 Strategy、ConcreteStrategyA 與 ConcreteStrategyB 角色，更改為 State、ConcreteStateA 與 ConcreteStateB，就會變成 State 範式的結構圖，可以說兩者就像是孿生兄弟般密切相關。

如果真的要區分出 Strategy 與 State 範式之間的差異，可以參考《重構——向範式前進》中論述的內容：

State pattern 對「必須在一整族 state classes 的實體之間輕鬆轉換」的 class 有益，而 Strategy pattern 則是有助於讓 class 把演算法執行任務委託給「一整族 Strategy classes 的某一個實體」。

從我理解的角度來解釋，Strategy 範式比較著重於包裝相同派系的演算法，而 State 範式則特別注重在各狀態之間的轉換邏輯。所以只要瞭解 Strategy 或 State 範式兩者之一，就等於學會了兩種設計模式，真的是太划算太值得啦！雖然 Strategy 與 State 範式非常單純而且易於理解，但這兩項看似不起眼的小小範式，卻經常能夠在程式系統中發揮很好的應用效果，絕對是程式設計者不可不學的必備基礎知識。本文中將以 Strategy 範式為主，說明兩者在遊戲系統中的相關應用。

如上面的 UML 結構圖所示，Strategy 範式由三種角色的交互作用而生：

• Strategy：制訂出一組共通的介面，使 Context 能夠透過此介面呼叫由 ConcreteStrategy 所實做的演算法。
• ConcreteStrategy：根據 Strategy 所制訂的介面，具體實做出合適的演算法。
• Context：Strategy 的操作者，另可定義介面以供 Strategy 存取自己的資料。

讓我們直接來看看，單純的條件判斷式在遊戲系統中產生的問題，以及 Strategy 範式如何解決問題。

在遊戲系統的程式碼中，特別是與遊戲邏輯相關的部分，經常會面臨需依照各項條件要素，切換不同控制邏輯的情況。以一般的遊戲主迴圈流程為例，多半由偵測鍵盤滑鼠等輸入裝置、更新遊戲世界，以及繪製遊戲世界三項程序組成：

while (m_GameIsRunning) {
	// 處理輸入裝置訊息
	ProcessInput();
	// 更新遊戲邏輯
	Update();
	// 繪製遊戲世界
	Render();
}

但是對於一個完整的遊戲來說，光是區分為上述這三項處理程序，無法完整滿足遊戲中的各種設計需求以及狀態轉換。例如，在剛啟動遊戲時、進入遊戲主選單時，以及遊戲運行中時，可能就會需要三種完全不同的偵測、更新與繪製程序，所以在此可以宣告一些列舉值，用來區分各種遊戲狀態，接著再以 if-else 條件判斷句在處理程序中分項處理：

enum GameState
{
	GameState_Init,
	GameState_Menu,
	GameState_InGame,
};

void ProcessInput()
{
	if (m_State == GameState_Init) {
		// 處理剛啟動遊戲時的輸入偵測邏輯
	}
	else if (m_State == GameState_Menu) {
		// 處理進入遊戲主選單時的輸入偵測邏輯
	}
	else if (m_State == GameState_InGame) {
		// 處理遊戲運行時的輸入偵測邏輯
	}
}

除了 ProcessInput() 函式以外，Update() 與 Render() 函式也以同樣的方法區分成不同的流程控制邏輯。如此一來，只要我們在程式執行的過程中改變 m_State 的數值，當遊戲主迴圈下次進入這三項程序時，自然就會切換至不同的處理流程中了。這樣的程式邏輯看起來完全無害，不是嗎？

但實際上，使用 if-else 敘述句的作法不夠直覺化，有另外一位控制結構的候選者更合適於擔綱這項任務。只要是熟習程式語言基本語法的讀者，應該不難想到可以將上面的 if-else 敘述句，轉換成另外一種作用相同的 switch-case 敘述句：

void ProcessInput()
{
	switch (m_State)	{
		case GameState_Init: {
			// 處理剛啟動遊戲時的輸入偵測邏輯
			break;
		}
		case GameState_Menu: {
			// 處理進入遊戲主選單時的輸入偵測邏輯
			break;
		}
		case GameState_InGame: {
			// 處理遊戲運行時的輸入偵測邏輯
			break;
		}
	}
}

相較於 if-else 敘述句，使用 switch-case 敘述句的優點，在於每個分支選項都會擁有同等的重要性。所以對於程式設計者來說，只要一見到 switch-case，首先就會聚焦在控制變數 m_State 的身上，並且直覺化地理解其中的各項 case 程序，都是具有同等重要性的程式碼。而也正因為 switch-case 比較符合程式設計者的直覺觀感，所以在遊戲系統的程式碼中，switch-case 敘述句也是最常被濫用與誤用的條件判斷式。

當遊戲專案剛啟始，同時整個程式系統仍處於萌芽階段時，使用前述 switch-case 的方法並不會產生任何問題。然而，隨著與日俱增的專案進度與設計需求，程式系統也會無可避免地越來越加錯綜複雜。可能一開始時，程式設計者只是單純想使用一個最簡單明快的方法，以解決切換控制邏輯的需求；然而，隨之而來的程式碼增修幅度，總是遠遠超過原先的預期程度。即使只是偶爾增加個十幾行程式碼，到了專案中後期時，卻有可能使一個小小的 switch-case 敘述句膨脹至 500 行以上的巨型怪物。

為了避免 switch-case 毫無節制地接受程式設計者的餵食，最終成為體態臃腫的大傢伙，我們立即可想到的一項改善方式，就是把原來散落在 case 敘述句中的程式碼，依照功能分門別類，包裝成一個個的中小型函式：

void Update()
{
	switch (m_State)
	{
		case GameState_Init:
		{
			UpdateNetwork();
			UpdateGameWorld();
			UpdatePhysicsEngine();
			UpdateAudioEngine();
			UpdateGraphicsEngine();
			break;
		}
		case GameState_Menu:
		{
			break;
		}
		case GameState_InGame:
		{
			break;
		}
	}
}

有些奉「效能」兩字為最高指導原則的程式設計者，可能會因為遊戲執行效能上的疑慮，而不願意將原來的程式碼包裝成一個個的小型函式。但事實上，這不僅是沒有必要的顧慮，也是一種「過早進行最佳化」的錯誤觀念。在最低限度的情況下，甚至只需要妥善利用 inline 方式來宣告函式，就能夠大幅降低函式呼叫的成本了。

雖然將 case 敘述句中的程式碼分裝處理是個好的開始，但是仍然沒有解決根本上的條件判斷式過多的問題，而且使用 switch-case 敘述句，就像是中了流行性感冒病毒一樣，會不斷地在整個程式系統中傳染擴散開來，讓程式設計者越來越難以擺脫。以上述的幾個分裝函式為例，除了在原有的 Update() 函式中判斷不同的運作條件之外，UpdateNetwork() 是不是同樣也需要進行判斷？還有 UpdateGameWorld()、UpdatePhysicsEngine() 和 UpdateGraphicsEngine() 函式呢？應該也免不了需要切換不同的控制流程吧！

所以，分裝函式最終經常會長出像這樣的程式碼：

void UpdateNetwork()
{
	switch (m_State) {
		case GameState_Init: {
			break;
		}
		case GameState_Menu: {
			break;
		}
		case GameState_InGame: {
			break;
		}
	}
}

void UpdateGameWorld()
{
	switch (m_State)	{
		case GameState_Init: {
			break;
		}
		case GameState_Menu: {
			break;
		}
		case GameState_InGame: {
			break;
		}
	}
}

還有 UpdatePhysicsEngine()、UpdateGraphicsEngine()、UpdateAudioEngine() 和 UpdateOOXX() 等等，到處都是 switch-case 敘述句，想躲也躲不了！

而除了近乎無性繁殖的 switch-case 程式碼以外，更令人頭痛的是，當程式設計者需要加入一項全新的遊戲狀態，例如 GameState_Pause 來控制遊戲暫停時的邏輯運作時，我們必須得回過頭來，前往每一個與 m_State 變數相關的 switch-case 敘述句中，加上一則新的 case 敘述句使 GameState_Pause 狀態能夠正確運作。或許你會認為：「用 Copy-Paste 的方式很快就可以完成，不是嗎？」但是人為干預的動作越多，也就代表疏忽犯錯的可能性越高。

清楚瞭解濫用 if-else 與 switch-case 的種種問題之後，就輪到本篇的英雄主角上場，拯救我們程式設計者的世界啦！為了能夠妥善管理各種不同遊戲狀態之間的運作邏輯，首先可以利用純虛擬函式，宣告一個無法直接具現化的抽象類別 GameState，來扮演最前面所提到的 Strategy 角色：

class GameState
{
public:
	virtual void Update() = 0;
	virtual void Render() = 0;
	virtual void ProcessInput() = 0;
};

將 GameState 宣告為抽象類別，優點在於強制使用者必須自行定義子類別的實做細節，藉此可避免對於 GameState 類別的誤用情形。接著，就可以依照遊戲系統的需求，自 GameState 衍生出一個個獨特的 ConcreteStrategy 角色：

class GameInitState : public GameState
{
public:
	virtual void Update() {
		// 處理剛進入遊戲時的更新程序
	}

	virtual void Render() {
		// 處理剛進入遊戲時的繪製程序
	}

	virtual void ProcessInput() {
		// 處理剛進入遊戲時的輸入偵測程序
	}
};

class GameMenuState : public GameState
{
public:
	virtual void Update() {
		// 處理遊戲主選單的更新程序
	}

	virtual void Render() {
		// 處理遊戲主選單的繪製程序
	}

	virtual void ProcessInput() {
		// 處理遊戲主選單的輸入偵測程序
	}
};

依此方式製作出 GameInitState、GameMenuState 與 GameInGameState 類別後，就可以快樂地和 switch-case 說再見囉！原來的 ProcessInput()、Update() 與 Render() 三項程序就可以修改為：

void ProcessInput()
{
	m_CurrentState->ProcessInput();
}

void Update()
{
	m_CurrentState->Update();
}

void Render()
{
	m_CurrentState->Render();
}

是的，你沒看錯！就這麼容易！先前由一個 m_State 變數以及 switch-case 敘述句控制的條件判斷式，轉換成僅需要一個 m_CurrentState 物件進行操控的程式碼邏輯。程式設計者只需要依條件更換 m_CurrentState 所指向的 ConcreteStrategy 物件，就能夠輕鬆地享受後續的免費服務而無須費心。所以只要我們能夠善加利用 C++ 語言的「虛擬」與「多型」特性，就能夠為程式設計者節省下許多非常珍貴的腦容量與腦細胞，使用在其他更有意義的難題上。

而 Strategy 與 State 範式，不僅能夠用在遊戲主迴圈的流程控制程序中，更可以運用在人工智慧等許多不同的系統中。像遊戲系統中常見的角色狀態機制，同樣也可以利用 State 範式的方式來實作。首先定義好基礎的 State 類別之後，就可以進一步衍生出 IdleState、MoveState、CombatState 等等不同用途的狀態類別：

class Character;

class State
{
public:
	State(Character* context);
};

class IdleState : public State
{
public:
	IdleState(Character* context);
};

class MoveState : public State
{
public:
	MoveState(Character* context);
};

class CombatState : public State
{
public:
	CombatState(Character* context);
};

「萬里長城萬里長～」如同萬里長城般綿延不絕而且橫跨數個頁面的 if-else 或 switch-case 敘述句，絕對是任何一位程式設計者最不願意見到的程式碼結構之一。當你爽快地揮舞著 if-else 與 switch-case 連段 Combo 招式時，請先暫停片刻，冷靜下來想想這樣的做法是否合適？是否有其他方法可以簡化條件判斷式？

另外，如果你習慣於撰寫動輒六、七層以上的條件判斷式深度，不但是在考驗自己的邏輯思考空間，同時也是在殘害程式碼的閱讀者與維護者——而很有可能你自己就是那位可憐的閱讀者與維護者。為了避免寫出深達地底三萬呎的迷宮結構，我們可以多加利用 return、break 敘述句，或者判斷反向的 boolean 值，以減少條件判斷式的巢狀深度。

平時要如何自我檢查是否已經中了條件判斷式的流行性感冒？通常當你發現自己反覆用著 Copy-Paste 在程式碼檔案之間，處理某些「大部分相同而小部分相異」的程式碼時，很可能就是一種濫用條件判斷式的徵兆。請記得，早期發現早期治療的效果最好，否則當程式碼日益增長茁壯，重構的痛苦也會越來越厚重。當你發現自己在兩個地方以上寫著相同的條件判斷式時，可能就是就是 Strategy 與 State 範式該出馬的時候了！

體認完 Strategy 與 State 如何拯救世界之後，最後也該瞭解它們可能產生的副作用。若從效能層面考量，比起單純的 switch-case 敘述句，使用 Strategy 或 State 範式需要一次額外的 virtual table 提領步驟，多少會造成某種程度的效能衝擊。然而，就像之前所提到的「不要過早進行最佳化」，程式設計者應該先以 80/20 法則確認系統的效能瓶頸所在，然後再開始動手改善，才能獲得最佳的優化效益。另外要注意的是，Strategy 與 State 範式並不是任何狀況都適用的銀子彈，如果用在錯誤的地方，將會產生過多小型的物件類別，反而可能降低類別階層的耦合性與內聚力。

只要善加利用 Strategy 與 State 範式，就可以大幅簡化遊戲系統的運作邏輯，使程式碼更加易於閱讀與維護，同時也會變成一種無須太多註解與文件說明，就能夠在程式設計者間達到良好成效的溝通方式。以後再見到 switch-case 敘述句或是準備下手使用之前，不妨先仔細分析一下，想想是否能夠使用 Strategy 或者 State 範式取而代之吧！這樣可以讓你自己也讓其他人過得更快樂唷～

延伸閱讀：

• 《重構——改善既有程式的設計》：
  〈8.15〉以 State/Strategy 取代型別代碼
• 《重構——向範式前進》：
  〈7.2〉以 Strategy 替代條件邏輯
  〈7.4〉以 State 替代「狀態變換」條件句

（圖片來源：www.freedigitalphotos.net）

原文出處：Opinion: Game Industry Interviewing 101

面試，幾乎是所有步入社會成為工作者的人都必須經歷的一道程序。在這篇文章裡，作者以自己的面試經驗做為出發點，不僅為遊戲業界的應試者提出許多有用的教戰守則，同時也為面試者提供一些頗有幫助的小訣竅。對於許多即將踏入職場的新鮮人，以及擔任主管職務的人來說，文章裡有許多看似平凡無奇卻非常實用有益的觀念與知識，可供身處職場的我們，做為參考與省思之用。

在此先對「應試者」與「面試者」做出明確的定義。應試者 (Interviewee)，或者可以稱為「被面試者」，所指的就是應徵工作而接受面對面測試的職務候選人。而面試者 (Interviewer)，所指的則是公司裡負責與應試者進行面試程序的人；在一般常見的情形中，通常會以應試部門的主管做為面試者。

當我們踏出校園生活，欲將自己的身份由學生轉換成為社會新鮮人時，為了尋找合適又滿意的工作，面試可說是一條必經的途徑。而如果來到面試程序，表示我們已經通過了檢驗履歷表的第一道關卡，但最終是否能夠獲得工作機會，決勝關鍵仍必須取決於面試過程中的表現。因此，對於社會新鮮人來說，面試可說是一件令人又愛又恨的事情。

另一方面，若以公司經營者或身為主管的角度而言，也絕對不可以輕忽各項面試的相關程序——因為不論你是否能夠接受，面試程序都會對公司的風評產生非常深遠的影響。身為面試者，你所代表的角色就是公司形象，你的一言一行都會傳達出公司本身的文化氣息。請記得，當你在面試候選者的時候，候選者也同樣在面試你的公司。即使在面試的過程中，你發現應試者並不合於你的徵才條件，仍然應該展現出良好的應對態度，才是恰當的作為。

首先，讓我們瞧瞧應試者與面試者雙方所追尋的目標為何。從面試者的觀點來看，他們想要的是：

• 充分判別應試者的技能。期望候選者至少具有不錯的能力，最好能夠達到非常優秀的程度。
• 確認應試者能夠良好地適應於公司的團隊。
• 盡可能付出較少的薪水。

至於應試者關心的事物則有些不同。理想中，他們想要的是：

• 好薪資，好待遇。
• 令人愉快且充滿挑戰性的工作。
• 工作的安全感。
• 成長與晉升的機會。

由上述面試者與應試者所關心的事物可知，雙方需求存在著不少理所當然的差異點。而雖然雙方所希冀的事物很顯然並不相同，面試者與應試者還是有許多可以獲得共識的共同點。例如，對初入職場的社會新鮮人而言，雙方都希望能夠達成一段長期而良好的工作關係。

在新鮮人第一年的工作中，公司往往需要花費大量的心力、時間與金錢進行教育訓練。一開始需要耗費極大的努力去發現、面試，並且選出合適的員工，接著再通過一段訓練時期之後，才能使這些初來乍到的新血們產生高於薪資的貢獻值。另外，不論擔任面試者的人是企畫設計者、美術設計者或者程式設計者，當你離開了工作崗位，為了去面試未來可能將成為工作伙伴的候選者時，也意味著實際遊戲開發時間的損失。

正因為上述種種因素所致，如果一間公司的離職率與流動率很高，不僅會對於心理面的團隊士氣造成影響，實體面的後果也會直接反應在人事成本與開發成本上。所以不論對於任何領域的公司來說，都會希望將員工留住越長久的時間越好。而對於遊戲業界來說，研發執行專案往往需要長達一年至三年左右的時程，因此能夠雇用一位將會留在公司很久的員工，更是至關緊要的關鍵。

在遊戲業界裡，不論是面試者或應試者，雙方都期望能夠創造出最高品質的遊戲作品，所以如果你身為公司的員工（同時也是面試者），無法使應試者對你們正在進行的東西感到興奮雀躍，那麼很有可能他也不會對於在此工作感到興奮雀躍。只要其他公司提供看起來似乎比較好的可能性，應試者就更加不可能接受你所提供的工作職位。

做為一位應試者，完整的面試程序非常具有壓力，但請記得最重要的事，就是不要疏遠你的面試者。例如，錯誤地做了下列這些行為：

• 說前任雇主或者共同工作者的壞話。
• 指出你曾犯過的錯誤，卻沒有說明你如何解決它或者從中學習到什麼。
• 不瞭解公司或者公司所製作的遊戲，顯露出自己的不足。
• 沒有準備好，不論是專業層面或者個人層面的因素。

以上四點都是非常致命的錯誤。你是不是對於應試公司的遊戲作品一無所知？還是興高采烈地細數前一間公司的缺點？昨天沒睡好，所以腦筋不靈活，考試考得不好？全部都不是藉口。你既然已經來到了面試的戰場，同時也是未來很可能投注其中的工作職場，就非得克服一切心理與生理的障礙，把自己最出色的一面展現出來不可。

最終，面試就是要找到能夠讓面試者印象深刻的人。所以應該要如何讓面試者對你感到印象深刻？有一些簡單的方法可以做到：

• 展現出你對公司的所知。
• 推銷自己。包括你與他人共事的能力，以及你的專業技巧。
• 提早到達面試地點。
• 展現良好的禮貌與教養。
• 無論如何都要保持正面與正向的態度。
• 採用遊戲業的文化——不要穿著西裝或套裝！——但穿著要能顯現出你對於面試程序的看重。
• 徹底地感謝面試者花費時間與你進行面試——無論結果如何，他們給了你機會！

（圖片來源：aroundtheacademy.com）

而對於面試者來說，同樣需要瞭解他們也是「被面試者」。候選者可以選擇去別處工作，也可以在回去之後，告訴身旁的朋友同學面試過程有多麼糟糕無聊或者多麼精彩有趣，所以切記要展現出對於應試者的尊敬，並且將他們視為重要的獨特個體。如果身為面試者的你，沒有全盤瞭解應試者的履歷表，不給他們回答問題的時間，或者詢問與日常工作無關的問題，很容易就會帶給應試者不好的印象與感受。

當然，面試者期盼的是能夠從眾多候選者中找到合格適任的人。有些候選者即使知道自己的資格並不符合徵人啟事上所列出的需求，但還是寄出了申請表，這對所有人來說都是一項殘酷的虐待行為。如果面試者先前就有認真地做好篩選工作，他們打從一開始就不該讓資格不符者來到公司面試。面試程序並不像是在黑暗中射擊一樣盲目，所有的面試者都應該清楚地瞭解這項事實。

儘管如此，有些時候應試者可能剛好今天不太走運。面試不能夠重來，但是展現出一點體貼寬容的態度也無傷大雅。一間公司對於應試者所能做的最差勁的事情，莫過於提早結束面試程序。這可不像是在電話裡掛斷電話一樣無害無誤；這位應試者，可能剛離開了原本的工作、家庭以及日常生活，花費了一番努力來到你的公司，草草了事、早早結束的面試程序就像是在污辱應試者，而且顯示出公司完全缺乏專業素養。任何經歷過這種面試過程的人，應該都會感受到相似的糟糕感覺。

在面試程序中，也可以分成數種不同的類型：

• 交叉詢問 (The Gauntlet)：在這種類型的面試中，公司會把面試者一位接著一位地丟到應試者的面前，每位進行 30 至 60 分鐘左右的面試程序。這樣的用意是盡可能地讓團隊成員與應試者接觸，最後再聚集在一起討論應試者是否適任。這是作者身為面試者與應試者時，最喜愛的面試型態；因為採用這種方式，能夠帶給雙方最佳的洞察結果。雖然這個程序將會相當地令人疲倦。
• 大提問 (The Interrogation)：把所有的應試者丟在同一個地方進行面試，就像是馬戲團一樣，會令人感覺非常不舒服。對於一些個性比較內向的人來說，這樣的作法更是一種無比的折磨。
• 戰俘室 (The Pow-Wow)：一對一，像是平常對話式的面試。如果你已經完全確認了應試者的能力，接著想要瞭解他的個人特質，那麼可以考慮採用這個方式。同時，這也是一個能夠降低應試者防衛心的好方法；一位有經驗的面試者，會利用這種方式詢問比較深入的問題。

以上這些面試程序的目的相同，都是為了找出合適的人才，但是達到目標的手段卻各不相同。而無論遊戲公司所採用的是哪一種形式的面試程序，有些問題是面試者與應試者雙方都應該提出來的問題。對面試者來說，應該問候選者：

• 為什麼我們應該錄取你？
• 除了合乎資格的項目以外，你是否還有什麼額外的能力？
• 絕對不要問那種只能夠回答「是」或「不是」的問題。

對應試者來說，應該問面試者以及自己：

• 「為什麼我想要在這裡工作？」這是你所能夠問自己的最重要的問題。
• 「精確地來說，我的工作職責是什麼？」確實瞭解你被指派的任務為何。
• 「貴公司如何鼓勵員工的個人與職涯成長？」這個問題不僅能讓面試者印象深刻，同時也對你個人的職業生涯發展非常重要。

無論是面試者或者應試者，都必須格外小心所謂的「冒牌貨」(impostor)。當公司面試者在你面前描繪出種種美好的未來遠景，說得天花亂墜但卻沒有具體敘述達成期望目標的方法時，你就該好好地衡量這間公司所提供的條件，是否與你所知的事實相符。這種類型的公司，可能由於高離職率或者其他的因素，通常會非常猛烈地渴求新員工的加入，而且他們也不會對於真正的工作狀況據實以告。

做為公司代表的面試者，如果你在面試過程中對應試者很差勁，應試者很容易會相信這就是他們在此工作的情況。所以對於面試者來說，也同樣需要盡可能地使應試者留下深刻的正面印象，例如採用以下方法：

• 給他們做一趟公司巡禮。
• 展示你們的遊戲！有太多的公司，可能因為害怕遊戲想法被竊取，而不願意向應試者展示開發中的遊戲作品。這完全是顧慮太多而且有害無益的行為。
• 帶他們去吃頓午餐。讓他們離開正式的面試場所，有助於認識應試者的個人特質而非他的專業能力。

最後要提的，其實是最先發生的事情——「電話口試」。對於擔任口試者的人來說：

• 請單獨在一個房間內進行電話口試。
• 不要指派具有強烈口音的人擔任口試者。
• 在口試之前，先閱讀完應試者的履歷表。
• 除非狀況極佳，否則盡量保持口試時間在 30 分鐘以內。

而對於電話口試的應試者來說：

• 找一個良好而安靜的地方接受電話口試。
• 不要著急。
• 使用室內電話以避免收訊不良的問題。
• 準備一本筆記本，讓你能夠快速地記錄下各種問題與事項。
• 絕對、絕對不要打斷面試者的話。

總而言之，雖然面試的過程很辛苦，但是面試程序不應該是種折磨或懲罰；對雙方來說，它都應該是個有趣而且對彼此有益的過程。雖然上述這些內容比較偏向於遊戲業界的面試教戰守則，但其實保有正確的面試以及應試禮節，絕對可以應用在任何的領域之上。

最後，我想提一段令我個人十分難忘的面試經驗，以及給各位社會新鮮人的一點指引。

（圖片來源：www.interviewquestionsandanswers.org）

還記得幾年前，我剛從軍中退伍後，很快地展開了生平第一次投遞履歷與面試的過程。這也是我第一次為了「找工作」這件事，非常認真而且費盡苦心地寫出一份自傳與履歷表。之後經過了數次來回奔波，面試了七間遊戲公司，其中包括了老牌的知名公司、小到連名字都沒聽過的公司，以及剛起步不久的新創公司之後，才終於拍板定案，決定了我在遊戲業界的第一份工作。

從這段辛苦的面試過程中，我深入認識了許多遊戲公司的工作內容、目前狀態以及未來的發展目標，同時也親身體驗了每間公司所具備的不同企業文化。其中有一間公司，讓我留下了非常深刻的正面印象。在我初到那間公司面試時，一開始就先做了三份考卷，分別是智力測驗、專業測驗以及性格測驗。經過漫長的九十分鐘作答之後，才正式展開了面對面的面試程序。

第一位面試者是程式部門的主管。在詢問了我一些專業問題，並且解答我對於工作內容的問題之後，接著立即有另一位人事部門的主管進來與我面試。人事主管手上拿著的是我所做的性格測驗結果，在接下來的二十分鐘裡，他詢問了我一些與專業無關但與個人特質相關的一般問題。詢問結束後，已經花費了約兩個小時的時間，我心裡想：「應該就此結束了吧？」

讓我大感意外的是，第三位面試者竟然是公司的副總經理！「我只不過是個沒有任何工作經驗的新人，怎麼會由副總經理這樣職務的人親自與我進行面試？」在我還沒來得及想通之前，他已經向我提出許多不尋常的問題，像是「你覺得自己最大的缺點是什麼？」或者「這輩子到現在，你所遭遇過最重大的挫折是什麼事情？」等等，許多題目都是我自己以前從來沒有設想過的問題。當時我並不能夠瞭解他的用意為何，只是覺得非常奇特而已。

結束面試回家後，很快地接到了公司代表撥來的電話，告訴我已經錄取了！並且提供了一份相當不錯的薪資待遇。但是當時，我還有數間已經約好面試時間的公司仍未進行面試，所以我將自己的情形據實以告，並且請他給我五天的時間考慮。最後，經過數天以來的面試奔波與深思熟慮之後，因為某些個人因素的考量，我最終決定放棄這間讓我深具好感的公司。

在我回電給這間公司的人事部門，表達我已心有所屬，無法接受貴公司所提供的職位之後，掛斷了電話，總算放下了心中的大石頭，認為這場奇妙的邂逅應該就此結束了。沒想到幾分鐘後，我立即接到另一通由副總經理親自打來的電話，他向我詢問拒絕的原因、心有所屬的是哪間公司，以及我所考量的決定因素為何。這些是我在其他公司面試過程中，所從來沒有經歷過的體驗。即使經過了好幾年，我仍然非常清楚地記得該公司所傳達給我的正面訊息，而這間公司目前的發展也十分地出色亮眼！

承續去年下半年開始膨脹發酵的全球金融危機，在 2009 年裡，我們可能仍將面對一段比現在還要更加艱苦的日子。雖然短期來看遊戲業的確開創了單月或單季的營收新高，新聞媒體也創造出「宅經濟」一詞，追捧著遊戲產業是如何在這波不景氣的態勢中逆勢成長，但就長期的角度來看，未來一年的經濟情勢仍然非常不明朗，如果局勢持續惡化下去，遊戲業也絕對不可能倖免於其外。

受到種種不確定因素的影響，許多國外的大型遊戲公司紛紛中箭倒閉，或者裁撤員工以求度過難關，而以國內的公司來說，大多數公司幾乎都暫時不再應徵新人。雖然在這樣的非常時期裡，資方的確擁有較多的談判籌碼，但是身為公司老闆、主管或者領導者的你，以徵人為名，事實上是徵召「人力」還是徵召「人才」？找「員工」還是找「伙伴」？我相信只要經過面試程序後，應試者都會了然於心並且不辯自明。

而對於有心進入遊戲業界的社會新鮮人或者學生來說，現在正是自我充實的最佳時機，請用盡一切努力來證明你的能力——if you really want it。

延伸閱讀：

• 前進遊戲界：給大學生的行前準備建議