http://blog.monkeypotion.net 遊戲開發‧遊戲程式‧遊戲設計 Wed, 03 Sep 2008 16:15:41 +0000 http://backend.userland.com/rss092 en 原文出處：Flagship Founder Bill Roper Interview 2003 年，冬天，旗艦工作室 (Flagship Studios) 於萬眾矚目之下創立起始；2007 年，秋天，旗艦工作室的第一個遊戲作品《地獄之門：倫敦毀滅》正式於歐美地區發行上市；2008 年，夏天，旗艦工作室大量資遣公司員工，旋即於同年七月宣告沈沒覆滅。 五年，人生有幾個五年可以揮霍？ （圖片來源：www.tech2.com） Bill Roper，身為旗艦工作室的首席執行長以及共同創始人，也是 Blizzard 公司三大名作《魔獸爭霸》、《暗黑破壞神》以及《星海爭霸》的遊戲製作人 (Producer)，如果讀者清楚瞭解他的資歷，曾經玩過、看過或者聽過他所參與開發的遊戲作品，應該很難不對於旗艦工作室的黯然落幕感到震驚：像他這樣成功經驗豐富的遊戲開發者，怎麼可能會失敗！？ 還記得五年前，那個 2003 年的夏天，當我正在軍營裡折騰翻滾的時候，Blizzard North 分部的三位創始人以及副總裁 Bill Roper 宣布集體離開如日中天的 Blizzard 公司，不僅在玩家社群中掀起巨大的波瀾，也大大地震撼了整個遊戲業界。於是，開始有人說 Blizzard 公司快要完蛋了，有玩家說《暗黑破壞神》不會再有續作了。經過將近四年的開發時程後，背負著無數玩家的熱切期望，在許多狂熱者眼中引頸期盼，能夠繼承《暗黑破壞神》系列作精神的《地獄之門：倫敦毀滅》終於在 2007 年 10 月 31 日上市。 但是很遺憾地，這款嘔心瀝血的遊戲大作，在大多數的遊戲評論者與玩家之中，都無法獲得良好的回應及評價。 I'd always maintained that the day we left Blizzard North was the hardest professional day I'd ever had. That ... http://blog.monkeypotion.net/reading/gamedevreading/flagship-founder-bill-roper-interview 在專案管理領域中，所謂的時程，也就是一般常聽到的 Schedule 一詞。當上司、主管或者指導教授交付給你一項工作時，需要知道這項任務的預估完成時間。我們身為遊戲開發者以及工作執行者的身份，應該要使用什麼方法來預估工作的時程？如何達到預估的準確性？工作時程中又隱含著些什麼樣的秘密呢？ 經過前篇文章「遊戲開發入門：專案管理管什麼？」的介紹之後，相信即使是從未接觸過專案管理領域的讀者，也能夠對於專案管理的基本概念有一些基礎的概念與認識。接下來，本篇將深入時程的層面，探討在專案管理中相當重要的專案時程估算議題。 （圖片來源：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 小時。如果你無法妥善地分解功能項目，表示你對工作任務的內容並不完全瞭解，很可能是你不熟悉的領域或者具有困難度的任務，請先尋求主管或同事的建議與協助後再行預估。 工作項目：武器的拖曳軌跡特效 ... http://blog.monkeypotion.net/gamedev/process/how-to-estimate-project-schedule 本篇是推薦文。很短，但藥效很靈而且不傷身體噢。 我要誠心誠意地推薦一個網站「程式者的胡言亂語」，以及其中的一些文章，給各位現在身處業界或者未來即將成為程式設計者的讀者。 漫談程式碼的相依性 - 1 漫談程式碼的相依性 - 2 漫談程式碼的相依性 - 3 漫談程式碼的相依性 - 4 「緊緊相依的心如何 Say Goodbye，你比我清楚還要我說明白……」身為遊戲程式設計者，在撰寫遊戲系統的時候，你是否曾經考慮過類別之間的相依性問題？如果你對於相依性的定義與影響不甚瞭解，閱讀這幾篇文章之後，應該能夠得到很大的收穫。 當你的下一個專案、下一款遊戲或下一間公司，有機會重新撰寫遊戲中的子系統時，請用心想想如何利用 Manager 類別來扮演子系統與子系統之間的 Facade 介面層，以及如何降低表頭檔間的編譯依存關係，別再把繪圖、網路、使用者介面與其他雜七雜八的家族類別們，全都混在一起開雜交派對了。 程式員與開發文件之間的恩怨情仇 如一般人所知，程式設計者與文件之間，經常處於某種微妙的對立關係。真正能夠發揮功能作用的好文件，應該是隨著開發而不斷演進的有機生命體，而不是為了交差了事，完成以後就束之高閣或者拿來墊便當用的東西。如果你是程式部門的主管，不論擅長的是專案管理這把倚天劍，或者是軟體工程那把屠龍刀，請許你的程式設計者們，一個認真撰寫文件的動機與誘因吧！ 程式碼共有下的團隊開發 即使遊戲業界距離極限編程 (eXtreme Programming) 的流程方法仍然有很遙遠的距離，我們還是能夠應用其中的某些準則規範，做為遊戲程式開發中的指引。為了達到集體程式碼共有 (Collective Code Ownership) 與共同認識 (Shared Understanding) 的目標，可以運用在之前文章中提過的 Code Review 程序，逐漸凝聚起團隊中的思維共識與程式寫作風格。從此以後，不分你我，再也沒有誰不能更改的 Code，達到「你 Code ... http://blog.monkeypotion.net/reading/gameprogreading/recommended-articles-for-game-programmers ３，是一個很奇妙的數字，經常用來描述相互抗衡，同時又彼此連結的能量關係。 生命生存的三要素是陽光、空氣與水；色彩學中的三原色是紅色、綠色與藍色；三國演義的三霸主是曹操、孫權與劉備；程式的三元素是語言、API 與工具。而在《薩爾達傳說》的故事背景中，則仰賴著力 (Power)、知惠 (Wisdom) 與勇氣 (Courage) 所結合而成的 Triforce 維持著世界的平衡。 （圖片來源：http://www.neoseeker.com/） 以遊戲作品來說，受到玩家喜愛的原因可能有很多，例如畫面漂亮、故事感人、音樂動人、操縱流暢以及玩法創新等等許多不同的因素。但是如果從遊戲創造者的觀點檢視，各位是否曾經思考過遊戲開發的三大原力為何？遊戲業界中是否也存在著神秘又奧妙的三原力？本文中，將分別以研發部門、專案管理以及遊戲開發，這三種不同角度的觀點，探討遊戲開發領域中的「三大原力」。 首先，以遊戲研發部門的觀點來看： 遊戲研發部門三元素 美術部門：美術設計者 (Artist) 程式部門：程式設計者 (Programmer) 企畫部門：企畫設計者 (Designer) 製作遊戲就像是孕育一個新生命，需要懷胎十數個月，不斷地灌溉愛心、耐心與細心，經過無數風波險阻，才能夠使「它」安然無恙地誕生於世。美術，是它的「皮」；程式，是它的「骨」；企畫，是它的「髓」。美術的皮，是吸引玩家的第一眼印象；程式的骨，是支撐起遊戲系統的樑柱；企畫的髓，則是使玩家流連忘返的魔力。這裡並沒有孰輕孰重的分別，就像是一個完整的人一樣，皮、骨、髓三者缺一不可；唯有緊密結合的皮骨髓，才能造就出一個人見人愛的遊戲寵兒。 另外，請注意在此指的是「研發部門」的部分，也就是經常縮寫為 R&D (Research & Development) 的部門。事實上，視公司的規模大小與經營方向而定，在遊戲公司內可能還會存在許多屬於研發領域以外的部門，例如行銷部門、測試部門、音樂部門以及營運部門等等，同樣具有舉足輕重的地位而不可漠視。 接著，以遊戲專案管理的觀點來看： 遊戲專案管理的三要素 時間 (Time) 品質 (Quality) 預算 (Budget) 時間、品質與預算三者之間，存在著天生的自然競爭關係；以專案執行的角度考量，很難找出能夠同時達到三個面向的最大利益的方法，因此我們必須從中抉擇，訂立出最合於既有條件與目標的執行方向。如果想要製作出品質卓絕、如同 Blizzard 公司出品的遊戲，至少需要挹注非常大量的時間與預算；如果想要節省團隊預算或者成員數目，相對來說就會花費較多的時間，才能夠達到比較好的成果品質；而如果是為了配合電影檔期上市的遊戲，時間是專案中最為關鍵而不可違逆的要素，也就難免會犧牲了些品質，或者必須投入相當程度的預算以彌補開發時間的不足。 想要在三者之間達成完美的平衡，幾乎比不可能的任務還要再多三倍的不可能。三者難以兼得，這是遊戲專案中的三股相互拉扯也相互制衡的原力。如何從中做出適切的取與捨，是遊戲專案製作人與管理者需要時時放在心上的重要課題。 最後，以遊戲開發的整體觀點來看： 遊戲開發三原力 技術 ... http://blog.monkeypotion.net/gamedev/industry/trifoce-of-game-development 原文出處：Measuring Responsiveness in Video Games 本文接續前篇文章「《Programming Responsiveness》：遊戲程式設計中的回應性」的遊戲回應性 (Responsiveness) 以及遊戲回應延遲 (Response Lag) 議題，進一步提出能夠實際測量反應時間的方法，同時對各款遊戲作品的回應性表現進行測試與分析。 （圖片來源：http://www.geardiary.com/） 在前文中，提到了遊戲開發者易於忽略的遊戲回應性問題，但是並沒有提出實際的測量方法；如果我們只使用人眼去觀察遊戲是否產生延遲情形，是相當主觀而且不準確的測量方法。身為遊戲開發者，我們需要更加精確的方法以及更為客觀的數據，才能夠證明遊戲的回應性緊密或者遲緩。在 PC 平台的遊戲上，通常比較少對於 FPS（遊戲每秒畫格）做出限制，強制鎖在 30 FPS 或者 60 FPS 的數值；但是在 Console 的平台上，遊戲需要從 30 FPS 或 60 FPS 中做出選擇。如果能夠取得客觀的延遲時間數據，遊戲開發者就能夠更明智地在兩個數值之間做出抉擇，進一步強化遊戲畫面以及遊戲操控性的表現。 想要測量遊戲中的延遲時間並不困難，只需要準備一台具備攝影功能的數位相機，對準遊戲中的電視螢幕與操縱手把進行錄影。作者使用的是便宜且常見的 Canon Powershot SD800IS 相機（我不清楚這台相機的價格算不算是便宜 XD）；將相機設定調整至「運動模式」或「快速畫格取樣率模式」，然後把取樣數調整至「60 FPS」後，使用腳架置放於電視螢幕前面；如圖所示，使相機能夠清楚地拍攝到電視螢幕畫面以及手上的遊戲手把，就可以開始拍攝遊戲中的各種操縱動作與結果反應。拍攝完畢後，可以使用 QuickTime 或其他播放軟體，以鍵盤的方向鍵每次移動一個畫格播放，計算出由按下按鈕到畫面呈現結果所花費的畫格數，也就是遊戲中的回應延遲時間。 由於目前市面上廣為流行的電漿電視與液晶電視，會在顯示畫面之前經過一些數位訊號的處理程序，因此無可避免地會導致一些額外的延遲時間；而傳統的映像管電視，反而能夠呈現出較高的回應時間值。瞭解如何進行測量，以及各種電視螢幕之間的延遲因素之後，就可以開始對各款遊戲進行實地測量。首先，我們需要一個校準數據，做為與各款遊戲的比較基準數值。在此作者選擇最單純應該也是最快速的「PlayStation 3 選單系統」操作，做為基準測量數值。 根據作者在傳統電視上使用 PS3 的選單系統所進行的測試，按下遊戲手把的方向鍵之後，直到第三個畫格，電視螢幕才顯示出選單項目。由結果可知，PS3 選單系統的反應時間為 3/60 秒，也就是 50 毫秒，是一個相當優秀的測試數據，同時也是理想上能夠在 PS3 平台上所達到的最快反應時間。另外，PS3 選單系統於電漿電視上的測試結果為 5/60 秒，與傳統電視之間存在著 ... http://blog.monkeypotion.net/reading/gameprogreading/measuring-responsiveness-in-video-games 原文出處：Programming Responsiveness 在玩遊戲的經驗裡，你是否覺得有些遊戲玩起來不太順暢，但又說不上來是什麼原因；明明是單機的遊戲，卻覺得操作反應有些 Lag；狙擊槍的準星明明抖個不停，竟然也可以命中敵人。這篇文章裡，作者對於遊戲的「回應性」(Responsiveness) 這個鮮少有人提及的議題，做出了詳細的觀察與探究，非常值得遊戲程式設計者與遊戲企畫設計者閱讀參考。 （圖片來源：http://games.mattsarrel.com/） 如果以軟體領域的角度來檢視，遊戲軟體與其他軟體最大的不同之處，或許就是在於遊戲對「即時反應」(Realtime Response) 的嚴格要求。在一些節奏比較快速的遊戲中，如第一人稱射擊、賽車競速或音樂節奏類型遊戲等等，甚至不能夠承擔超過零點幾秒的延遲誤差。那怕只是一點點的延遲反應而已，都會破壞玩家對於遊戲的投入感；更甚者，也可能就此在玩家心中埋下難以逆轉的負面印象。 Response lag is the delay between the player triggering an event and the player receiving feedback (usually visual) that the event has occurred. 「回應延遲」(Response Lag) 的定義，是指從玩家觸發事件，直到玩家得到回饋反應的延遲期間。觸發事件，是指玩家藉由搖桿、手把、鍵盤或滑鼠等輸入裝置，觸發遊戲系統中的行為動作；而回饋反應，則通常是指遊戲中的視覺面呈現。如果在「觸發事件」與「得到回饋」兩者之間的延遲期間過於冗長，將會造成玩家認為遊戲反應遲鈍、動作慢吞吞或是操縱不順暢等等負面觀感。 當遭遇回應延遲問題的時候，許多玩家，甚至是遊戲設計者，都沒有辦法用正確的詞彙敘述遊戲的問題何在；多數玩家不會說「這個事件在我按下按鈕的 0.1 秒後才發生」，而是會說「這個遊戲感覺緩慢」、「遊戲的節奏不對」、「遊戲太過於困難」，或者只是說「這是個爛遊戲」。他們無法真正瞭解「爛」的成因為何，因為他們並沒有意識到延遲現象背後的成因。在進行遊戲測試時亦然如此；即使測試者沒有明確地回報關於回應延遲方面的問題，但這些問題可能只是以不同形式的敘述句表達。無論是企畫設計者，或者程式設計者都不應該忽略掉這些問題的嚴重性。 回應延遲通常不是由單一因素所造成的局面，而為了解決這個問題，首先我們必須知道現象背後的成因。由前述的定義可知，延遲時間簡單來說就是玩家按下按鈕到螢幕產生結果的期間；而為了瞭解延遲從何而來，首先必須知道遊戲程式在主迴圈 (Main Loop) 中進行了哪些工作程序。在遊戲的主迴圈中，主要有兩項基本任務：邏輯運算與繪圖；邏輯運算程序用於更新遊戲物件的狀態與數據，繪圖程序則負責繪製遊戲畫面的畫格 (Frame)，並且將結果呈現在螢幕上。除了上述的兩大程序之外，在主迴圈中，還會有個負責偵測輸入裝置系統的程序。以最簡化的遊戲主迴圈流程來說，程式碼如下所示： // 遊戲主迴圈 while (1) { // 偵測輸入 Input(); ... http://blog.monkeypotion.net/reading/gameprogreading/programming-responsiveness 自前一篇「物件導向設計新思維：探索Policy-Based Class Design新視界」發佈以來，已經過了很長的一段時間。在這篇千呼萬喚始出來的續集裡，將會進一步深入探索 Policy-Based Class Design 背後的設計概念與理論，以及在實作層面上經常會遭遇到的問題；最後，以一個遊戲系統中常見的音源引擎 (Audio Engine) 類別設計為範例，做為本文的片尾曲目。 記得曾經有人問過比爾蓋茲，如果有天他被迫一人獨自在荒島上生活，身旁只有一樣物品陪伴的話，最想要什麼東西？他的回答是：「一部電腦與編譯器。」許多程式設計者心裡所嚮往的美好世界，就是那種無拘無束、無邊無際的自由；好像只要手指還能夠活動、頭腦還能夠寫程式，天底下就沒有辦不到事情！只是，有時候這種無限度的自由，反而會對程式系統造成負面的影響。 在《C++ 設計新思維》(Modern C++ Design) 書中的第一章，就對於程式系統的設計就開宗明義地闡述： 理想上，一個良好設計應該在編譯期強制表現出大部分 constraint（約束條件、規範）。 身為一位程式設計者，或多或少都有把自己的程式碼交給其他程式設計者使用的經驗，相對於「程式撰寫者」來說，所謂的「程式使用者」，就是那些使用你所撰寫的程式碼的人。就像是遊戲程式中經常使用的 DirectX、OpenGL 或者 .NET Framework 以及遊戲函式庫與引擎等等，我們都是身為「程式使用者」的身份。 在一個龐大的程式系統框架中，動輒擁有成千上百的原始碼檔案與物件類別，在交錯複雜的物件體系與階層架構中，如何讓使用者不會迷失方向而誤入歧途？即使想要依賴文件資料、UML 圖示以及程式碼中的註解，也只能夠提供相當有限的指引。有經驗的程式設計者應該都知道，很多函式庫與引擎系統都有各自的「眉角」，如果不能真正瞭解這些系統的使用邏輯，經常會造成事半功倍的反效果。因此，換個方向以「程式撰寫者」的角度來看，當我們在撰寫程式時，最重要的關鍵就是如何正確地傳達設計者的意圖 (intention)。 舉例來說，C++ 語言中的在物件封裝設計，缺少了 package 的概念，只要是宣告為 public 的成員函式，就無法阻止其他的使用者進行操作，即使這些類別與函式的原意並非如此。由 C++ 語言的所提供的能力，從程式撰寫者的角度來看，是一種很大的自由度；然而如果從程式使用者的角度來看，卻很可能是一種設計上的缺陷。而 C# 的 internal 關鍵字則正好補足了這一點缺陷，讓 public 的屬性只存在於同一個專案的 package 中，對於其他的專案來說，則變成不能擅自使用的私有類別或者私有成員函式。 做為一個有經驗的程式設計者，我們經常會半強迫性或者半自願性地寫出「語法有效」但「語意無效」的程式碼。什麼叫做「語法有效，語意無效」的程式碼？舉個遊戲程式架構中常見的實例，例如 LifeEntity 是一個生物體的基礎類別，而遊戲中的怪物 Monster 類別與玩家 Player 類別，同樣繼承自 LifeEntity 類別。遊戲中的怪物需要 AI 功能的設計，而為了要使 Monster 類別能夠設定 AI ... http://blog.monkeypotion.net/gameprog/advanced/diving-into-policy-based-class-design 「我想進入遊戲業！但是不知道要如何做準備！」 你是學生嗎？你渴望在畢業之後進入遊戲業界工作嗎？你抱持著滿腔的熱情，卻不知道如何替未來的自己做好準備嗎？這篇文章裡，將以我個人的經驗與心得，提供給有興趣進入遊戲業界的學生一些行前準備建議。因為我自己是屬於遊戲程式設計者的身份，所以這篇文章多數的內容是針對未來有志於成為遊戲程式設計師的大學生。在文章最後，則會稍微提到一些關於遊戲企畫設計者與遊戲美術設計者的面試加分項目。 對於有志成為遊戲程式設計者的人來說，大專院校中的資訊相關科系，如資訊工程、資訊科學以及資訊管理學系，可以說是最為接近遊戲程式設計的領域。雖然台灣目前已有幾間學校設立了遊戲設計學系，但是以成為遊戲程式設計者的目標來說，我認為選擇資訊相關科系仍然會是比較合適的決定。資訊科系畢業的學生，未來可以從事許多不同面向的工作，例如 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 ... http://blog.monkeypotion.net/gamedev/career/how-to-prepare-for-entering-game-industry 我想，在進入 Scrum 這個新奇有趣又好玩的新主題之前，必須要先來一兩篇楔子，介紹關於遊戲開發層面的入門知識。首先，就來談談基礎的專案管理概念。 （圖片來源：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 ... http://blog.monkeypotion.net/gamedev/process/what-the-project-management-manages 原文出處：What Gamers Want: Silver Gamers 對於遊戲業界來說，如何吸引更多不同族群的消費者目光，一直都是一件非常重要同時也十分艱鉅的任務。為了瞭解不同族群消費者的想法與需求，Gamasutra 找來一群 50 歲以上的銀髮族玩家進行焦點團體測試，實地去遊玩各種不同類型的遊戲，並且從中獲得他們的意見與回饋。 所謂的 Silver Gamers，銀髮玩家，泛指那些「不是從小跟著電玩遊戲一起長大」的族群，可以說大約是 1970 年之前出生的人，也是我的父母那一代；同時，銀髮族玩家也是那些不會將自己視為電玩遊戲商品消費者的族群。在這樣的前提條件之下，這些願意嘗試電視遊樂器遊戲的玩家，在測試過程之後，提供了許多相當有趣而且值得思考的觀點與意見，總共可歸納為以下 10 項結論： 可反覆練習的教學模式 (Repeat Tutorial) 多數的銀髮玩家，需要比一般玩家更多的學習時間以領會遊戲的各種操控方式，但是現今的許多遊戲，經常會假設玩家已經非常熟悉遊戲的操控方式，因而忽略了某些基礎而關鍵的教學指引。但是與一般的核心玩家不同的是，銀髮玩家想要擁有更多的機會，能夠反覆地練習同樣的一個動作，直到他們能夠操作自如為止，接著才能夠安心地學習下一個操作步驟。在這一點上，Wii 平台的《Madden NFL 08》意料外地表現的非常好，這個遊戲不止擁有步調合宜的控制方法介紹，而且玩家還能夠在遊戲進行的時候，隨時跳回練習模式複習那些不熟悉的動作指令。 印刷成冊的說明書 (Printed Manuals) 你在剛買到最新上市的遊戲後，會先閱讀遊戲包裝內的說明書嗎？在一般玩家的印象中，很容易假設大部分的人都不會仔細閱讀操作手冊，所以現在許多遊戲的說明書內容也就越來越少、越來越單薄了。然而，印刷成冊的說明書卻是對於銀髮世代來說，最為熟悉的閱讀與學習形式。買了一台冷氣，會有紙本的使用說明書，液晶電視有說明書，電腦燒錄機有說明書，手機也有說明書。如果能夠在放進光碟片開始遊戲之前，事先閱讀過充滿豐富資訊與指引的遊戲操作手冊，將能夠有效降低他們對遊戲的不熟悉感與不安全感。 以《Grand Theft Auto 4》為例，在遊戲的包裝盒裡，有提供紙本印刷的街道地圖，使得銀髮玩家們可以在進入遊戲之前，先行熟悉遊戲場景中的各種區域。只要能夠預先提供給他們份量適當的「遊戲教材」，銀髮玩家也能夠更有信心嘗試他們所不熟悉的娛樂媒體，更有勇氣地踏入遊戲的世界中。 遊戲文字的可閱讀性 (In-Game Readability) 許多遊戲中的文字，即使是呈現在高解析度的電視螢幕上，都相當不易於銀髮玩家閱讀。再者，在某些遊戲中，文字出現的時間太短，經常在還沒有注意到文字內容，或來不及閱讀完畢之前就消失不見了。所以在遊戲的測試過程中，經常會聽到銀髮玩家們詢問「剛剛那個指示說什麼？」之類的問題。在這個面向中，《Wii Play》中的 Find Mii 遊戲表現出色，玩家可以按住 B 鈕以顯示說明文字，既可以有充分的時間閱讀文字，同時也不會破壞整體畫面的美觀；除此之外，這個遊戲也使用了較大的字型，以及呈現高對比度的背景，幫助玩家更加易於閱讀文字。 這一點的確是相當關鍵而容易被忽略的問題。很多遊戲喜愛使用花俏酷炫的字體，或者誇張鮮豔的字型顏色以獲得玩家的目光，但是往往沒有仔細考慮到文字內容與遊戲背景的視覺搭配。這種介面設計的呈現結果，不僅會加速玩家眼睛的視覺疲憊感，也會大幅降低玩家一字一句閱讀遊戲文字的意願。 遊戲行話與專門術語 (Jargon) 對於遊戲人或我們這些生活在遊戲世代的玩家來說，可能直到你真正和銀髮玩家一起坐下來玩遊戲，你才能體會到自己使用了多少行話。很多我們可能視為再平常也不過的術語，例如「Level Up」代表的是「人物等級提升」的意思，對於很少接觸遊戲的銀髮玩家來說，都是一種無形阻礙。如果能夠在遊戲的詞句用語上，盡量使用日常生活可見的一般用語，就可以減少許多銀髮玩家的混淆與疑惑。 遊戲題材的多樣性 (Variety of Subjects) 在銀髮玩家進行各種遊戲的測試過程中，有許多人不能理解為什麼有許多遊戲看起來如此相似。「為什麼我們需要另一個賽車遊戲？這和前一個賽車遊戲有什麼不同？」因為這個賽車遊戲強調速度感，而另外那個強調真實性？在他們的眼中，看不出這些遊戲的不同之處。相對來說，銀髮玩家更樂意於嘗試比較少見的遊戲題材與遊戲類型。在這點上，Wii 平台的《Deca Sports》中的滑冰運動與冰上擲石遊戲脫穎而出，為他們帶來既新鮮又有趣的遊戲樂趣。 能夠跨越不同世代的遊戲 (Play Across Generations) 許多銀髮玩家對於能夠跨越不同世代，和自己的外甥甚至孫女一起遊玩的遊戲類型特別地感興趣，例如 Wii 平台的《Smarty Pants》（益智問答類型遊戲）就獲得相當不錯的評價。這項事實也充分地反映出了他們渴望與家人朋友共享娛樂體驗的需求。對於遊戲設計者來說，如何才能夠使熟練遊戲技巧的玩家，以及剛接觸遊戲的玩家，都能在同一台主機上一起進行遊戲，而且同樣能夠獲得滿足的娛樂體驗？「動態差距調整 (Dynamic Handicapping)」是一項用來幫助遊戲設計者達成這個目標的有趣概念。藉由遊戲中所提供的功能設定，例如調整所選角色的血量與能力值，使玩家們能夠視情況改變與其他玩家的競爭優勢與劣勢，進而減少玩家之間的差距。 《瑪利歐賽車》是一個非常出色的動態差距調整實例。當一群玩家一起進行比賽時，跑在最前面幾名的玩家，往往只能得到效果很普通的輔助道具；而進度落後較多的玩家，相對來說則有較大的機會獲得更強力的武器道具，甚至是能夠一舉反敗為勝的「超級砲彈」。這種設計方式，比起直接調整角色數值的方式更為聰明，而且能被玩家們接受。利用這樣的方式，讓擁有不同技巧等級的玩家也能夠在一起玩遊戲，而不會因為某位玩家總是獨佔第一名的位置，久而久之其他人就不會想繼續玩下去了。 進行遊戲時的姿勢 (Posture) 以休閒活動的角度來考量，如果需要保持站立姿勢完成整個遊戲過程，對於銀髮玩家來說似乎太過於疲憊。由於《Wii Sport》在採取坐姿時會產生某種程度的操控阻礙，因而招致許多玩家的怨言：「我在工作時已經站了一整天，並不想在下班後繼續站著。」或者是：「正如同我不會選擇站著看電影，我也不願意站著玩遊戲！」在這方面的設計，《Tiger Woods ... http://blog.monkeypotion.net/reading/gamedesignreading/what-gamers-want-silver-gamers