第二步、提案階段就積極跨部門溝通
跨部門溝通是專案委員會的重要職責之一。【大軍未動，糧草先行】。老板看過提案之後很心動，但是接下來老闆會問一件更重要的事：【這樣的案子要花多少時間、多少錢才能完成?】
接下來就是做專案的計畫與成本預估了。這一段時間的工作就是需要製作人與三大總監合力完成專案計畫書與雛型系統，並且與行銷、財務部門做一個溝通了。
是否真要產出一本厚厚的書倒不是重點。原型展示、成本、人力與時程四大項至少要有簡明扼要的說明出來，讓行銷與財務認可，能夠讓製作人在老闆面前受到支持才是關鍵。
計畫的製作通常會讓遊戲公司的主管頭痛，原因是這類管理性的工作是他們長期浸淫在遊戲開發中所忽略的。這裡提供實務上的建議：整個專案委員會除製作人具備對市場的敏感性外，也可以考慮第一時間邀請行銷或產品經理擔任市場顧問。
讓行銷人士也參與的做法，就是要避免進入遊戲開發後才被行銷或產品人員放砲，輕則翻案，重則專案胎死腹中。由於專案委員會本身具有美術與程式能力，行銷人員不會只看到文案，而是包裝過的雛型系統。這種手法才有說服力讓行銷點頭支持。
以上的動作都透過提案會議來進行，重點人士到場即可，既不佔用高層的寶貴時間，又可以收內部宣傳之效。另外，這樣的溝通方式也可以讓行銷跟財務人員知道自己也有責任。
比如說，市場的現況到底如何?需不需要有預算支持市調？這些在會議中一定會被提出來。因為提案中一定會需要引用一些市調數據，老闆就可以去思考要不要建立市調制度了。
第三步、成案後進入規格的設計與開立階段
一個成功的提案含雛型系統開發，大約半年內可以完成。也可以說，這是第一個里程碑，委員會成員可以舉辦一次簡單的餐會輕鬆一下，並且可以讓總監們考慮人力的配置了。如果是重用引擎的新案，時間可能大為縮短，2~3個月就可以過關。
或許有讀者會問：這樣就半年啦?只有雛型系統是不是太沒效率了呢？筆者的回答是剛好相反，三到五位資深專業人員投入六個月，就讓公司高層支持提案、確定遊戲開發方向，這是很划算的事情。
就筆者的經驗，許多遊戲提案就是在一開始無人問津的情形下，憑著老闆的意志過了(其實是懶得看只有文字的提案，老闆打定主意等展示版出來再說)，結果這個文案到了程式與美術手上才被提出質疑，但因為已經通過了，大家只好摸摸鼻子開始討論問題，在企劃與製作人奔走之下很勉強地慢慢進展，當三個月後的里程碑會議時，這份拼湊起來的遊戲報告極可能只有原畫稿、遊戲企劃案以及部份陽春的遊戲畫面。(別忘了各單位都透過層層反應在拖時間，三個月很快就過了)
更糟糕的是遊戲玩法可能還停留在紙上談兵的階段，講也講不清楚，參與的行銷與產品經理於是開始砲轟，老闆在失望之餘只好把製作人抓來念，要求提出更具體的成果以及新的時間表。承受壓力的製作人便把老闆的意志再傳達下去，而本來對企劃案不滿的團隊成員也提出質疑挑戰，就這樣吵吵鬧鬧三個月又過去了，高層看到的成果仍然乏善可陳。
這時候財務或產品部門就會開始建議老闆找外包了，並且列出半年內所有人員投入這個遊戲的成本加以佐證 (別忘了製作人可是把開發人員都加進來努力製作遊戲了，每個月都是十幾位成員的工作費用啊)。
同樣的半年，不一樣的結果，前者開始產出規格發包給開發人員製作遊戲，而且高層已經對遊戲有具體印象，不易被市場上的資訊迷惑。後者可就命運坎坷了，製作人腹背受敵、老闆跟行銷的新想法不斷提出、各單位對遊戲信心崩盤，大家一邊上班一邊等遊戲翻案或者再開新案，遊戲胎死腹中的未來已經確定了。資本額愈高的公司，這種混亂狀況會撐得更久，兩年都在空轉筆者也見識到過。
說回規格開立的階段，三大總監可以專心在設計遊戲需要的功能，也可以配置需要的助理人力來加速規格的製作。由於有雛型系統可以參考，對這些助理而言規格的開立並不會太困難。
製作人在這段時間可以藉由雛型系統不斷與公司內部討論，對象不只是行銷、產品，甚至是未加入團隊的開發者也不在此限。藉由這些新的意見，可以加強或擴充遊戲的玩法，然後再請三大總監將正面的意見納入規格之中。
這個階段並沒有限定要使用哪種開發手法，想用瀑布型或者新的Scrum都很適合。原因簡單，委員會本身包括了各單位的人才，單純設計規格，或者加入更多開發人員設計小系統取代規格文件的開立都沒問題，因為他們都有總監加以帶領，不用擔心無頭蒼蠅的狀況發生。
一到兩個月後，適合給開發者的各樣說明文件、稿件、清單與附件，當然還包括最新版的雛型系統，都可以交付了。於是，三大總監這時候開始擔任監工的職責，隨時掌控遊戲開發的進度了。
第四步、嚴格執行P-D-C-A完成Alpha版本
要讓遊戲的開發按照規格、彈性地執行下去，執行力是非常重要的。企劃總監負責監控遊戲任務的腳本撰寫、人物成長數值、戰鬥玩法的平衡性，各種要交接給行銷跟產品部門的相關設定資料、遊戲說明書。美術總監將場景、模型、圖像、肖像、特效動畫等等發包給2D、3D的組長執行。程式總監統合前、後端程式組長的工作，並確認與美術部門的整合事項。由於規格在前一階段都已經設定、溝通好了，成員們只要按照既定的標準互相整合即可。
這個階段重點在執行，筆者特在此提出PDCA的管理策略。何謂PDCA呢？P-Plan、D-Do、C-Check、A-Action。
Plan(計畫)-總監要確認發包出去的規格，是負責成員已經了解也知道要怎樣在時間內完成的。由於規格是總監開的，成員有不了解之處他也可以直接指導，並且掌控住可能的變化。
Do(製作)-規格化的文件搭配雛型系統，可以減少成員憑空想像、瞎子摸象開發的時間浪費，再加上製作人在前一階段便不斷藉由雛型系統與公司員工溝通玩法，這段計畫執行(Do)可以得到最大的效益。
Check(檢核)-任何一項工作執行完畢，不是收到成員的開發日誌就算了事。各組組長是查核成果的最基本單位。如果完成的工作有些誤差，也都能在這一階段加以要求、更正。總監本身負責統合性的檢查，所有的問題都要列管，一些在製作過程中發現的問題也可以藉此紀錄下來。
Action(解決方案)-任何可以影響遊戲開發進度的重大問題，都要在委員會中得到解決方案，並且要持續追蹤效果，落實到開發團隊之中。這個階段最常碰到的都是程式整合的問題，諸如重用性的介面整合、地圖編輯、跨伺服器的資料驗證、戰鬥系統特效整合等等，技術上常常會有瓶頸發生。
而委員會的存在，就是為了跨部門溝通提出解決方法。有些是需要美術配合修改模型的建構方式來解決，委員會中直接就可以討論，也可以馬上指示美術相關人員配合相關的修改。
這個製作遊戲的階段是週期性的發生，它會持續追蹤到計畫發布的版本完成，交付給測試階段來確認為止。週而復始。比如說第一個版本計畫是新手村到人物可以成長到10級的城鎮與野外關卡，附帶30個任務。第二個版本計劃是人物可以成長到30級的城鎮與野外關卡，以及組隊與國戰功能。第三個版本計畫是人物可以成長到60級(上限)的城鎮與野外關卡、100個任務、以及所有社群、商城功能。那麼，第三個版本就是完整的Alpha版本了。
Alpha版本是功能都已經開發完成，可以接受公司的內部測試的版本。一方面做為遊戲玩法的總體檢，吸收各單位的意見，一方面可以作為規劃系統壓力測試的參考。
這個版本容許某些來不及最佳化的圖像表現，但是整個遊戲玩法、關卡、任務、社群功能、對戰功能都必須完成，才能為CB(Close Beta)做好準備。
第五步、發布內測的Alpha版本，並且做好交接給運營的準備
專案委員會負責Alpha版本的發布。在開發團隊向製作人展示整個遊戲的運作之後，敲定出公司內部可以進行上線測試的時間，如果公司設有測試團隊，則可以在上線前先交由測試團隊進行嚴格的審核，確認是否每個功能都正確的運作，開發團隊根據錯誤回報再一次進行系統的修正。
當系統也通過測試團隊的考驗後，委員會就可以向公司宣佈舉行Alpha版本的內測了。再一次將測試後的意見收集後，經過一段時間的修改，當測試團隊再次收到測試通知時，遊戲本身就是Close Beta的版本了。
同時間，三大總監各自將修改過的功能寫回企劃案，企劃總監與製作人討論後整理出要交付給運營的相關資料。這份文件包括了遊戲說明書(文案)、預錄的特效動畫、畫面剪影、人物原畫、場景原畫等等資料。詳細的內容由製作人與運營開會後再次確定。
第六步、組織維護團隊，由運營發布Close Beta計畫
進行到此，遊戲版本算是做出來了，Close Beta的活動就由運營來設計。一般都是由原團隊接手遊戲的修改與維護。專案委員會在交付運營相關資料完畢後，就可以準備指定維護的負責人，解散，然後為下一個新案開發做準備了。
維護團隊基本上還是可以重用專案委員會的概念，由三大總監推薦的人才來擔任維護委員會的大任。雖然筆者認為CB版本出來就可以解散委員會了，但是這個時機點是有彈性的，可以視各公司的需要加以改變。
走筆至此，深深感到一個萬人線上遊戲從提案到開發完上線，真的是非常的不容易。這段期間可能你隔壁的戰友走人、你的主管也消失了，更有甚者是換了新公司繼續開發。台灣在線上遊戲這一塊付出了許多代價，有的人因此功成名就，有的人因此黯然離開。
反躬自省，想要讓遊戲在台灣生根、青年學子以作遊戲為職志，除了靠學子一身熱血、不屈不撓的努力之外；要想與列強並駕齊驅，還是需要政府的覺醒，願意投注資源發展這塊產業。
企業所能做到的，就是以戰養戰，做得出好遊戲賺錢才有可能考慮建立更好的制度與環境，但這樣畢竟能力有限。筆者認為如何讓政府覺醒? 關鍵就在於國內的數位內容產業要有人挺身參政(就是立法委員啦)，從法律的源頭去影響政策，落實管理才有可能讓動漫、遊戲圈有進一步發展成完整的產業的機會。
下一次，就來談談獨立遊戲製作的新潮流。
創作內容
我對台灣遊戲產業的評價 part5 關於遊戲開發之我見(下)
小說 (12)
