一、前言

首先，推薦一本書，名為《妙趣橫生的遊戲製作之旅》，你在本文中看到的大部分名詞都能在這本書中一一找到對應解釋，這本書能幫助你對整個遊戲製作流程有一個初步的認識，這篇文章或許也能算是這本書的讀書筆記。

其次，本文面向的群體主要是學生以及準備入門或剛入門的萌新，所以會寫的儘量“短小精悍”，希望這篇文章能對你有一定的指導作用，也希望這能夠幫助你在遊戲行業中更好地施展你的才華。另外這篇文章也會更多的講到策劃部分，一方面因為策劃是一個團隊中的絕對核心，另一方面程序和美術對項目經歷的需求一定程度上要小於策劃(但不會提及更專業的內容，這些理論知識去看書可能學到的會更多)。

最後，何為長週期，個人認為對學生而言，3個月及以上即可稱作是長週期，如果從目前的一些GameJam類型來分的話，大致就是(假設用1年時間做一款遊戲)：

48~72H快速完成玩法原型驗證(可以有多個原型，然後挑一款最好玩的原型繼續打磨)
1~2周打磨原型(讓它有至少5mins的體驗流程，並且美術表現不能太差)
3~6周出Demo(至少有1個表現和邏輯稱都得上“完整”的關卡可供外部玩家體驗)
2~3個月出alpha版本(特性完備)
3~4個月出beta版本(內容完整)
最後1~2個月持續優化迭代並準備正式發佈的相關事宜

但是在此之前，如果你是剛入門的策劃，那麼最好先熟悉一下游戲製作流程，然後在1個月內花上多個1~2周自己solo3款不同類型的遊戲出來，瞭解清楚其中的難點後，再嘗試去組隊，不然你可能會因為不清楚其中的技術難點和你的隊友爭吵，最後不歡而散……

二、為什麼要熟悉流程？

簡而言之，即便一開始不去熟悉流程，後續自己在實踐的過程中也會慢慢總結出來，而這些流程大多也是前人總結的，所以……不如先看一下他人的總結，然後自己在實踐中慢慢去體悟，甚至打造出一套專屬於自己團隊的流程。

不過流程不一定要完全遵守。這可能與你的認知相悖，但事實就是，製作遊戲是一種創造性的行為，而這種行為難以被約束，就像你沒法給一個畫家定KPI一樣，所以就需要保證一定的“鬆散性”，流程在這裡更多的是用來“保底”，以及讓大家知道現在正在做什麼，下一步該幹什麼，或者用來找到現在的工作卡在哪個流程無法繼續推進。

三、為什麼推薦做長週期的遊戲？

如果你想繼續深耕遊戲行業，製作長週期的遊戲大抵是不可避免的，因為製作週期越長，要遇到的問題也會越多(長度有一定上限，臨近上限後，遇到的問題就開始大同小異了)，比如製作流程和製作規範，這在短週期的遊戲中幾乎用不上，設計能力和製作能力需要經年累月的練習，但解決問題的能力可以快速鍛鍊起來：這也是為什麼實習經歷比項目經歷更吃香的原因之一。因為在實習中你會需要和更多不同角色的人合作，並有機會遇到一些前所未有的問題，而製作長週期遊戲會讓你離實習經歷中需要掌握的技能和經驗更近一些，另外如果遊戲取得了一些成果，你收穫到實習offer的概率也會更大。

當然，項目經歷無法替代實習經歷，最根本的原因就是：你沒法拉著你的同學去做商業化項目(有DAU、付費率、轉化率、留存率等指標)，併成功解決商業化項目中獨有的問題。如果你做到了，那麼恭喜你，你或許已經不需要offer了，因為你已經成功地邁入了創業地段，準備好給其他人發offer並進入市場激情廝殺吧😉。

四、如何開始製作長週期遊戲？

在開始之前，最好像前言說的那樣，花上不止一個48~72H做多款原型，並且原型越多越好，因為“你做的前十個遊戲都是垃圾，所以趕緊做掉吧。”也就是說，

你可以在1~2個月中，用很多個48~72H來驗證你的很多個原型是否有足夠的拓展深度和廣度，並且它還要足夠好玩；
挑選出你認為最有潛力的原型，並開始打磨它，直到它有至少5mins的體驗流程；
接著優化它的設計和視聽表現，再適當地拓展現有的玩法深度，讓它看起來足夠“完整”，體驗足夠“絲滑”；
這之後，讓它越來越完整吧。

4.1 前十個遊戲都是垃圾，這對嗎？

對的。

引號中的名言來自《遊戲設計藝術》這本書，至於為什麼是名言，大抵是因為這句話爭議比較大，而爭議點大概就是“前十個遊戲”和“趕緊做掉”這2個地方。

首先，根據遊戲製作時長、遊戲類型的不同，這“前十個遊戲”的範圍就顯得尤為模糊，1個月做10個遊戲是做，10年做10個遊戲也是做，因此重點要放在“趕緊做掉”。

所以對於這句話，我的理解是：在不熟悉遊戲基本的製作流程、基礎的遊戲設計能力不足的前提下，花一段時間製作幾款原型，每做完一款後就讓自己和其他人體驗一下，體驗過後收集反饋，再根據自己的體驗和反饋，覆盤一下這款原型做的好與不好的地方(比如：“我喜歡……我希望……，如果……”)，然後促成一個正循環，以實現對基本製作流程的熟悉和基礎設計能力的快速提升……簡而言之，就是“儘早失敗、快速失敗、經常失敗”(當然最重要的還是要覆盤，否則這些提升免談)。

至此，你或許就具備了製作長週期遊戲所需的基本技能。

4.2 我需要團隊合作嗎？

這需要看個人目的，如果僅僅是為了實現一下夢想，其實自己一個人慢慢做會更好(再加上現在的AI技術也比較成熟了，更別說之後的AGI還能做成更多事)，那麼你可能就不需要這些長篇大論；但如果你希望進入遊戲行業，並想要做一個出色的Game Designer，那麼在你求學生涯中組建一個長期穩定的團隊或許必不可少，最少也需要策劃、程序、美術各3個人(如果再有一個單獨的音樂就更棒了)。

當然，也不是人越多越好，這還要看你的遊戲體量、具體需求量、隊友能力以及他們所掌握的垂直技能是否能滿足這個項目的需求。

此外，你或許可以從一些GameJam中找到隊友，但找隊友也是門技術活，並且有一定的運氣成分，就像黑暗森林法則，雙方都不確定對方的目的，並且每場GameJam都會出現隊友中途失蹤或不歡而散的情況，這你需要特別注意，因為這2種情況大都是一些開發者厭惡甚至害怕團隊協作進而成為獨狼的根本原因。另外下面列出了一些參與GameJam的人群中可能存在的幾種目的，你可以參考一下，歡迎補充：

什麼都不懂只是來玩的
來立人設拍素材
新手入門來熟悉流程
來實現夢想
想從繁重的工作/學業中解放一下
來驗證點子
來刷簡歷
想拿獎
把Demo拿出來看反饋
來擴列
來找隊友

至於如何識人並且如何應對，這需要大量經驗，但總之，保持一顆赤誠之心吧。

4.3 接下來溝通能力會很有用

這個溝通能力並非單指說話，它背後所包含的意思是：

能把自己的想法清晰地傳達給他人
能準確地理解他人的想法
能正確地消除歧義

要做到這些其實並不難，只需要分別做到這些事：

說明需求後，給美術/音樂發參考，和程序一起拆解需求(需求拆解可以瞭解一下WBS方法)
雙方多問一句：“我的理解是xxx，你看看是不是這個意思。”
記得驗收

4.4 怎麼寫策劃案/需求文檔？

這是一個問題，但也不是問題。一些策劃或許會說每個策劃寫案子的風格都不同，只要“能讓人看懂就行”，但怎麼才能讓人看懂也是一門學問。你或許可以借鑑一下互聯網行業中“產品經理”這一職業寫PRD時的規範和標準，這或許有助於你更好的輸出一份“能讓人看懂”的策劃案，當然，記得第4.3節中提到的參考圖/參考曲、需求拆解以及需求驗收，這些能輔助對方正確地理解你的需求。

五、項目管理

大多數獨遊/學生團隊對項目管理都不太重視，甚至沒有項目管理意識，認為小團隊甚至是個人並不需要項目管理，其實這是非常錯誤的想法，製作遊戲作為一個“項目”就應該要有一個截止日期，不能永無止境，否則最後的結果大都是放棄。即便是《火山的女兒》製作團隊，都曾遇到過許多項目管理問題，所以這是一個非常常見且容易被萌新忽視掉的嚴重問題。

文章來源：https://mp.weixin.qq.com/s/RRxasLk2rbYVMB1kjon1Fg

5.1 項目管理應該包含哪些東西？

項目管理鐵三角、瀑布流、敏捷開發、里程碑、版本、迭代、進度控制、立項啟動規劃執行監控收尾……等等，或多或少你可能已經聽過這些名詞，也可能沒有，但正如前所述，這一節註定也不會出現過多的專有名詞。簡單來說：做項目，要有目標、要有人。

首先是目標，分為項目目標、里程碑目標、版本目標、迭代目標，其中項目目標>里程碑目標>版本目標>迭代目標，版本由多個迭代組成，里程碑由多個版本組成。總之，它們關係如下圖所示：

你可能會疑惑為什麼每個迭代→版本→里程碑不是一一對應的關係，這是因為目標不同，比如里程碑1的目標是製作Demo，因此分了v1.0版本實現玩法原型和v1.1版本世界觀設計，但世界觀設計沒法像原型那樣快速驗證，它需要持續不斷地打磨，而製作Demo對世界觀設計是否完整的依賴性並不高——我現在還在救公主的路上，怎麼救到的公主那就是後話了。因此，就會出現跨里程碑的情況——跨版本的迭代也是如此。

其次是人，如果說目標是讓你清楚現在以及將來需要做什麼事，那麼人則是促成這件事的關鍵對象。人員管理及其背後所包含的溝通問題、進度管理、方向一致性、成本控制、質量管理、風險管理等講起來十分繁瑣，推薦過一遍《項目管理基礎》這本書，這裡只講個人得出的結論：

以人為本
注重信息互通
團隊成效不好80%是管理者的問題
要做好目標管理
覆盤思維很重要
明確開會目的
學會識別關鍵路徑
分清優先級

5.2 為什麼遊戲項目大都使用敏捷開發？

因為遊戲行業變化很快，因此打著“積極響應變化”口號的敏捷開發由此脫穎而出。如果你是新手，那麼我其實更推薦你先用2~3遍瀑布流來製作Demo，這能讓你更清楚這一步做完後下一步該做什麼，直接上手敏捷開發反而可能會打亂你的開發節奏，導致延期的可能性大大提高。以下是瀑布流的示例，下圖和“瀑布模型流程圖”結合著看，僅供參考。

前文的Demo對應這裡的預製作階段

瀑布模型流程圖

5.3 如何進行敏捷轉型？

首先需要明確一點，敏捷並非單獨使用，一定是敏捷+其他結合使用，至於+的是什麼，則要看你團隊的實際情況和你自身的項目管理經驗。一般來說是敏捷+瀑布(也就是混合式開發)，因為遊戲製作涉及策劃、程序、美術、音樂，一些大體量項目還會牽扯到多條管線+多個團隊+大量數據，雖然是在做遊戲產品，但這個產品裡卻有著大量內容。

其次，進行敏捷轉型首要的是轉變思路，將瀑布流時的階段性思維轉變為敏捷“短平快”打法的迭代思維(也可以瞭解一下Scrum這種較為常用的敏捷項目管理)。純文本解釋起來稍費口舌，可以通過以下圖例來說明：

迭代循環

顯然，“短平快”的重點在於"計劃"流程中的“拆分任務”，拆出來的任務量以及是否是可執行的任務直接決定了Sprint循環能否跑起來。因此，如果你不知道怎麼拆分任務，可以嘗試拉上專業人士一起拆，因為這會影響到接下來的Sprint流程順暢與否。

此外，敏捷需要可持續交付有價值的交付物，不僅要讓外部的玩家清楚某一階段的產品形態，團隊內部也需要時刻能夠看到遊戲的整體形態——鬆散的、未能將所有素材和邏輯拼接成整體的遊戲會讓人懷疑自己是否真的在做遊戲，或者說，會讓人懷疑是否真的能做出遊戲。

5.4 混合式開發怎麼用？

很簡單，舉個例子：里程碑1的目標是製作一個Demo(Demo的產品形態應該如何前面已經說明，不再贅述)，分3個版本實現：

v1.0版本：玩法原型產出

迭代1：原型1
Sprint1：關卡設計
任務1
任務2
任務3
Sprint2：3c實現
Sprint3：xx功能實現
迭代2：原型2
Sprint1：……
迭代3：打磨原型1

2. v1.1版本：美術概念設計

3. v1.2版本：資源整合

5.5 項目管理工具

Jira、PingCode、TAPD、禪道等等，你可能聽說過這些項目管理工具，但學習如何使用這些工具也需要一定成本，在熟悉如何管理項目之前先學習這些工具如何使用屬實有點本末倒置，所以不妨先回歸最簡單的工具——Excel來進行最基礎的項目管理。

說到最基礎的項目管理，學會如何排期作為入門可能再合適不過，但不太推薦從前往後排期，因為最後大概率會延期，常用的一種排期方法是“倒推法”，再結合前面的瀑布模型+任務拆解，其實排期這塊就不需要講太多內容了。

最後，項目管理的各種方法和工具只是輔助，關鍵還是在於人，在於如何激發人的主觀能動性。由於PM沒有實際產出，所以PM在團隊中只能打輔助，然而輔助也很重要，總不能說主程在這個項目中清的單子最多，評分13.0；PM在這個項目中沒做什麼事，評分3.0；所以主程是MVP，PM是躺贏狗吧。

六、市場調研

此時，你對製作流程比較熟悉了，也有了一定的設計能力，手握幾個有足夠拓展潛力的原型，並且組建了一支長期穩定的團隊，對如何管理項目也比較熟悉了，那麼就該考慮正式開始製作長週期遊戲前的市場調研環節了。

可能你會覺得市場調研會汙染你的天才設計，但其實恰恰相反，遊戲做出來是給玩家玩的，因此需要找準你的遊戲類型對應的是哪些玩家群體，以及在這些群體中，哪些是核心的資深玩家，哪些是較為邊緣的玩家……為什麼要這麼分？因為這個品類下核心的資深玩家能清楚的知道你的遊戲哪裡做的好與不好，並能給到你精準的反饋，這對你後續改進設計和體驗相當重要。