1. 前言
年前最後一天上班的時候，我收到了公司另外一個項目組的Demo，和Demo一起的還有一份調查問卷。
試玩Demo和寫反饋應該是一個非常常見的事情，但是在我現在工作的公司裡，這兩件事情是非常罕見的。三年前加入現在的公司的時候，我認為這是一個充滿創造力的，有生氣的公司；三年後我仍然認為我所在的公司充滿了創造力，但是生氣——似乎被一次次的項目失敗所打消殆盡了——我不知道其他幾個項目的製作人或者公司的老闆是怎麼看待的，但是這是我的真實想法。
一個由藝術家領導的公司，內部分佈著幾個十人左右的，同樣由藝術家氣息濃厚的製作人領導的團隊，帶來的好處是顯而易見的：有想象力，審美趣味良好，創意天馬行空。三年前我認為這是獨立遊戲的天堂，三年後我發現了這背後也有著一個巨大的“藝術氣息”陷阱：如何把項目落地，製作出來一個好玩的遊戲。
目前我所在的公司的這種模式擁有一個明顯的特色：因為似乎沒有資金壓力，導致每個項目的週期極長。如果有合格的製作人，那麼這是一個十分巨大的優勢，簡直就是每個獨立遊戲製作人的夢想模式。但問題是，如果沒有合格的製作人，項目必然會陷入無盡的返工和方向變更。十分不客氣的說，我所在的公司內暫時沒有合格的能扛起來稍微大型的項目的製作人，正因為此，公司幾個項目組製作週期長，不是因為精益求精，而是恰恰相反的原因：項目主導者 （製作人）控制不住遊戲方向，帶來漫長的內容修改時間。
有的時候，我十分希望我所在的公司能夠仍然維持做小體量的遊戲，最好是五人左右，一年到兩年能夠完成的遊戲體量。這個好處顯而易見：能夠迅速磨合團隊，培養新人，即使失敗了，也能很快速的幫助項目製作人成長——體量小，所以能夠及時反思更正，調整下一個項目的製作方式。與其五年做一個大項目，肯定是一年一個小項目帶來的成長更大。但是很可惜的，我人微言輕，公司也沒有合理的反饋渠道，我只能看著幾個項目在一個前途未卜的道路上前進（即使我個人十分悲觀）。恕我直言，這種製作方式已經接近於賭博了。
另一方面，我也很清楚地能夠感受到，公司裡對於學院派的遊戲設計的不齒，以及對於遊戲策劃這個崗位（或者任何其他有軟性能力的崗位）的輕蔑。我不是一個迂腐的人，我也不相信一板一眼的學院派式製作遊戲的方法能導向成功的遊戲（能保底一個合格的遊戲是肯定的），但我更不相信憑藉著直覺就能夠做出來驚豔的遊戲（我相信製作一個平庸的遊戲不是任何人的目標）。工作之餘我大量攝入了各種遊戲的製作幕後，有開發者的Devlog，有開發者的播客、視頻分享，也有文字版本的分享，我可以肯定這些成功的遊戲沒有一個是純粹的碰運氣碰出來的。正是因為如此，我才會越來越對公司目前的幾個項目感到絕望。
我理解公司內的製作人們也一定是迷茫的，所以他們按照自己的方向去做。問題是，既然不確定方向是否正確，為什麼不更加頻繁的在公司內部開展Demo試玩呢？
在這裡，問題就回到了開頭：年前最後一天上班的時候，我收到了公司另外一個項目組的 Demo，和Demo一起的還有一份調查問卷。這個Demo已經悶頭製作了至少12個月，任何反饋都變得沒有意義了——各個部分的方向已定，除了一句“不錯，挺好的”，還能給出什麼反饋呢？
2. 從各個名詞的解釋，來解釋一種遊戲製作的流程
我參加過很多game jam和小型項目，和形形色色的人和項目組合作過。想要解釋一種遊戲的製作製作流程，是十分龐大且困難的，很多遊戲設計的經典教材或者書籍中都花費了很大的篇幅才能夠說清楚一種遊戲製作的流程。更重要的是，對比其他行業，遊戲行業本身十分年輕，遊戲理論研究更加青澀，談論一個“正統的”遊戲製作方式無疑是十分幼稚的，何況每個遊戲工作室都會有適合他們自己的一套遊戲製作方法論。
但是，這些客製化的遊戲製作方式中，一定有共通的關鍵之處。我希望能通過解釋一些常見的名詞，結合我自己的實踐經驗，進而嘗試建立一個比較科學的關於遊戲製作的大致印象。
2.1 Prototype（原型）/Demo/Vertical slice（垂直切片）/MVP
2.1.1 Prototype（原型）
Prototype（原型），一個用於驗證某一個功能的東西。在任何項目中，這一定是優先級很高的一個步驟。
比如要做多人遊戲，那麼需要一個多人聯機的技術原型，去驗證多人遊戲是可以被實現的。如果說我想做一個戰地的克隆遊戲，那麼首當其衝肯定就需要驗證我們的技術能力能否實現六十四名玩家同時在線對戰。如果不能通過技術優化滿足網絡的要求，那麼項目的預算是否能夠支持通過堆服務器的量來滿足多人對戰的條件？
這裡可能還會涉及到的情況有，可能項目組的後端能力是滿足的，但是美術上無法把畫面渲染優化到足以支持多人玩法，那可能就會需要一個包含美術資源的多人遊戲原型，用來測試項目的邊界情況，例如項目支持什麼樣的貼圖分辨率，每個人物的模型面數最大不超過多少等等。
再比如要做一個無縫開放世界，那麼自然需要先有一個相應的技術原型來驗證可行性；如果要做一個卡通風格的遊戲，那麼需要一個技術美術上的渲染原型來驗證可行性；如果要做一個 rogue-like遊戲，那麼可能需要一個地牢生成的技術原型來驗證隨機生成的可行性；如果要做一個大量對話的敘事遊戲，那麼先要有一個良好的對話管理器技術原型來驗證對話內容的維護或者文本本地化方面的可行性，等等。
可以說，除非你想要製作的遊戲是非常輕量和休閒的小體量遊戲，否則應該都是需要有原型的。（身邊的做小體量遊戲的朋友，一款遊戲的製作週期也很短，通常三到四個月遊戲就從想法到上線了。）
用料理來對比製作遊戲，製作原型就像是在挑選（驗證）料理中的各個步驟
2.1.2 Demo
Demo，組合各種原型，用於向人展示項目可玩性的東西。在完成初步的驗證後，接下來經過一段時間的前期製作（可能此時美術資源還是用臨時資源代替的），團隊應該能拿出來一個 Demo用於展示遊戲的初步概況。有的製作團隊為了讓Demo更能吸引人的目光，可能會先製作一部分完成度很高的美術資源，那麼此時這樣一個完整的Demo應該要讓來試玩的人快速地瞭解遊戲的各個方面：美術風格，遊戲的核心玩法，遊戲故事的開頭等等。總而言之，Demo是項目第一次面向項目組之外的人的遊戲包，它是遊戲在公共領域的初次登場，直接面向潛在玩家、投資人、發行商、媒體等等。
製作一個Demo，就像是製作了一個家庭手作小蛋糕。
2.1.3 Vertical slice（垂直切片）
Vertical slice（垂直切片），是一個包含所有遊戲中會出現的系統的遊戲包。這種叫法常見於正規的開設了遊戲設計專業的學校體系，因為從這一類專業中畢業的學生大概率是要進入大型公司製作大型遊戲。那麼在大型項目中，使用垂直切片的目的仍然是為了階段性地確認目前項目的方向是正確的（修正方向），確保遊戲這個狀態是合格的，以便萬一出現問題能夠在繼續鋪量進行生產前做出補救。這樣的一個遊戲包應該包括的是遊戲項目的完整骨架，比如：從開始遊戲菜單——遊戲的核心玩法——遊戲的結束——遊戲的保存和退出。
一個蛋糕的垂直切片，可以非常方便地觀察其構成。
2.1.4 MVP(minimum viable product)
MVP，字面翻譯是“最小可執行產品”。那麼顯然一個MVP應該是在遊戲製作的中後期才會出現的遊戲包，此時可能遊戲填量的部分（比如音效音樂，美術動畫資源，比如寫好還沒來得及實現的劇情設計）還沒有完成，但是這個時候遊戲已經有一個包含核心遊玩體驗的完整的包體了。我自己的理解就是，如果這個時候遊戲已經能夠上架了，剩下的未完成部分可以作為DLC上架，那麼就代表項目組完成了一個MVP。
在飯店正式開業前，不如先擺個小攤測試一下，看看食客的反應吧！
2.2 市場調查
對於中小體量的製作團隊來說，我認為市場調查中最重要的事情應該是成本控制以及明確市場規模。
成本控制上，要選擇力所能及的遊戲製作方向，規避掉需要大量成本的遊戲品類。比如，我認為應該規避的兩個方向：即時的多人在線遊戲（網絡和服務器問題），需要大量美術資源的3D遊戲（美術資產成本太大）。
明確市場規模，就是要能夠大致估算出項目所需要的資源，並且要把所需要的資源量和目標遊戲市場能夠帶來的利潤做對比。比如我面向點擊冒險遊戲市場，那對於這個很小的市場來說，在Steam首月能夠賣出兩、三萬份以上就算是不錯的成績，一年能夠有十萬份以上的銷量就是爆款的情況下，如果項目估算製作完畢的成本總和在一百萬以上，可以說就是在進行一次豪賭了。夢想誰都有，但是不是每個有實力的人都是那個被好運眷顧的人。這樣的投資行為就全看投資人的目的了，如果目的不是盈利而是為了磨合團隊培養人才，那似乎沒有在這裡討論的必要了。
還有更多的市場調查的車軲轆話我就不再贅述了，很多調查並不適合本就資金緊缺的小型團隊。而且我自己認為過度的市場調查一定會導向平均的遊戲，那還為什麼要加入小團隊製作獨立遊戲呢？
2.3 Game loop（遊戲循環）
談論遊戲設計，很容易形而上的走向討論什麼是遊戲，在這裡我不想也沒有能力去討論這個話題。我更加感興趣的是更加腳踏實地的設計方法。
那麼，以我淺薄的知識來說，讓我們假設遊戲設計的不同方式可以被放置在一個光譜上，光譜的一端是電影化的遊戲設計（極端例子比如交互電影），另一端是純粹的只有玩法的遊戲（比如俄羅斯方塊）。在這個光譜中，我的理解是：越靠近“電影化”的遊戲，越難以歸納出屬於遊戲的循環，遊戲的結構也越容易用電影化的敘事理論去分析；相反的，越是靠近“玩法”一側的遊戲，越容易歸納出一個屬於遊戲的循環。
不要做二極管，做一個光譜。
這似乎和遊戲的本質有著密不可分的關聯。在遊戲研究領域中有各種各樣的對於遊戲的定義，我很喜歡的一個優雅的解釋是：遊戲是自願地克服非必要的障礙。我自己更傾向於把遊戲看作是一種人類天生的對於和物理環境交互的渴望——勞動。自然的，勞動帶來的是客觀環境的改變（對於現代的社會化的人類來說，能夠在勞動中感受到勞動的結果是一種奢侈），這就是一種最原始的天然的循環：人勞動，勞動帶來正反饋，人繼續勞動。
所以歸納出一個屬於遊戲的遊戲循環，在我自己設計遊戲的一個基本方法論。而分析其他的遊戲，如果不清楚遊戲循環的概念，我相信也很難有效地做出分析進而學到精華而非表層的皮毛。
舉例來說，比如非常電影化的Detroit: Become Human（底特律：變人），基本的循環是：玩家在場景中交互，推進既定的劇情分支，最後進行一個關卡的結算，並且看到全球玩家的對於劇情分支的選擇數據統計。
再比如稍微添加了更多“玩”的部分的遊戲，VA-11 Hall-A（賽博龐克酒保行動）的基本循環是：玩家開啟新的一天在酒吧上班，選擇歌曲，給不同的客人調酒（調酒遊戲），觸發新的劇情，下班結算。
接下來，添加更多的“玩”的遊戲，比如新戰神系列，一個基本的遊戲循環首尾仍然是劇情的推進，只不過中間被動作或者解謎玩法填充。
最後，可能是光譜另外一頭的遊戲，比如Baba is You（Baba是你），遊戲循環更加簡單純粹：打開新的關卡，完成解謎，進入下一個關卡。
而在真正製作做遊戲的時候，不難發現的是，越容易歸納出想要製作的遊戲的循環，越容易讓人理解我們想要做什麼樣子的遊戲。一個遊戲的循環也不單單隻有一個，可能遊戲的每個系統都有相應的循環。
但是，遊戲設計真的需要一個循環麼？我將嘗試在下一個部分回答這個問題。
2.4 Scripted Design（手工設計）/Systemic Design（系統化設計）
“歸納出遊戲的循環”，另一個側面就是“遊戲是否遵循一定規律”。在我看來，難以歸納出規律的遊戲設計的重災區就是點擊冒險遊戲，這也是一個極好的解釋scripted design的例子。
點擊冒險通常代表著一種技術上的妥協——限制玩家對於遊戲世界的交互。例如早期的點擊冒險遊戲會限制玩家和環境的交互（如：拿取，檢視，使用，交談，給予）。這些交互行為是一種無可奈何的抽象歸納，顯然玩家在遊戲世界中的交互難以被這幾個動詞描述完全，所以玩家會出現一種經典的反應：“為什麼我可以和A交互，卻不能和B進行同一種交互？”。在更加現代的點擊解謎遊戲中，例如Machinarium（機械迷城），仍然並且一定會出現的遊戲設計是：玩家必須在某處執行某種操作，才能推進劇情進展。這就是我所說的scripted design，而這種設計模式必然會導致玩家感受到一種抽離，既“出戏”。
誠然，這種“出戏”感可以被其他遊戲設計方法所降低，比如：限定少量的可以遊玩的場景，以降低玩家尋找那個特定的解法的難度。更多的方式不在此贅述，我可能以後會單獨寫一篇文章闡述一些設計點擊冒險遊戲的小技巧。
玩家在遊戲世界中希望的是：“我可以拿起場景中的杯子，就應該也能拿起差不多大小的盤子”，而不是“我能拿起杯子，是因為這是任務道具，我拿不起盤子，是因為這個盤子根本沒有出現交互UI”；“我可以爬進一個通風管道，就應該也能夠爬上路邊的箱子”，而不是“我能夠爬進管道，是因為這是一個劇情動畫，我爬不上箱子，是因為這裡被放置了空氣牆（更可能的是玩家根本沒有攀爬的能力）”。
所以，與scripted design相對的是systemic design（系統化設計）。這個設計思路早就出現了，我認為最能體現這種設計的無疑是Arkane的幾款沉浸式模擬（immersive simulation）遊戲。但是直到2017年的塞爾達，使用這種設計模式的遊戲才被更廣泛的玩家接觸到。
簡單來說，系統化設計設計系統，並且嘗試把遊戲中的內容歸納成類。系統接受輸入，改變受到系統影響的類（輸出）。比如，玩家擁有瞬間移動的能力，那麼這個移動系統如果接受到了合適的輸入（比如能力範圍內允許移動到的地方/距離），那就應該能夠改變玩家的位置；同時這個系統肯定也會關聯到場景系統，場景中能夠容納玩家的碰撞盒的空間都應該能夠允許玩家到達。這兩個系統合起來就是恥辱（Dishonored）系列中的瞬間移動能力。
在這種設計模式中，設計師設計的是規則，而非一個一個去設定玩家能夠去到哪裡/在什麼地方可以瞬移。
更多的例子如：荒野之息中的天氣系統配合上地形系統，導致窪地在雨天會積水，而非手工指定哪些地方會有積水；天氣系統和元素反應配合，導致雨天火會熄滅，而非手工指定什麼時候火會熄滅，等等。不難看出，系統化的設計非常容易導向湧現式的遊戲玩法，因為設計師只設計系統的規則，沒有指定任何特定的遊玩方式。
左：Scripted design | 右：Systemic design
但是需要注意的是，這種設計模式不是一定優於scripted design。設計模式只是工具，適合的工具才是好工具。如果我在設計的遊戲本身就是體量很小的遊戲，或者我的遊戲本就不追求湧現式的玩法/更高的自由度，那麼構建多個系統的規則反而是事倍功半的。根據現實情況結合使用兩種設計模式才是更好的設計方法。
所以，回到上一節的問題：遊戲真的需要循環麼？似乎是不需要的：越是難以歸納和抽象出循環的遊戲，就會出現越多的scripted design。這對於有資源支持的公司或者工作室顯然是沒有問題的，比如Remedy。但是對於獨立遊戲或者小體量遊戲的開發來說，顯然應當控制成本，把有限的資源放在刀刃上——遊戲循環上。另一方面，越難以被歸納出循環的遊戲， “遊玩”體驗似乎越接近於一種被動地，電影化的消費體驗，即“觀看”的體驗。我不是在嘗試貶低這一類遊戲，而是嘗試說明，這種遊戲體驗似乎喪失了遊戲媒介本身的特點。製作這類遊戲時，可能更加註重的是劇本而非玩法——不提優秀劇本的創作難度，如果要製作這樣的遊戲，為什麼不去製作獨立電影呢？（疊甲：當然可以做這樣的遊戲！但是我自己的態度如此，我必將狠狠地表達！）
2.5 Top-down design（頂底設計）
頂底設計模式即由上至下，由大到小地進行設計的設計模式。在遊戲設計中，我認為使用這種設計模式能夠十分有效地完成兩件事情：明確設計目標，以及便於進行項目管理。在我的經驗中，這兩點是很多經驗不足的團隊栽跟頭的地方。
設計需要設計目標，而頂底設計模式能夠很好的幫助團隊明確目標。舉一個例子：賽博龐克的世界觀特色是高科技，低生活。如果這六個字作為一切設計的最頂層，那麼視覺上，故事上，玩法上等等項目各個方面的設計目標都應該向著這六個字靠齊。所以，賽博龐克世界觀中之所以出現各種科幻視覺奇觀，正式因為要遵循總的設計目標；而到底這個世界觀中應該訴說什麼樣的故事，也需要確保故事要說的主題是和總的設計目標相關的。
同時，由大到小地確定了設計目標後，也就確定了衡量設計好壞的標尺，任何方面的設計才有討論的空間，否則開會討論就變成了無主題的辯論會。這也是很多經驗不足的團隊，開會總是效率很低的原因：無人確定設計目標。最終開會便是徒勞無功的過場（無人拍板）；如果有人拍板，那也是不歡而散，因為做出決定的人沒有明確的理由去說服其他人，沒有一個早先提出的設計目的。
項目管理方面，頂底設計的優點主要體現在便於把控項目進度。如果設計遊戲的過程能夠被一層層拆分成小的設計目標，那麼我們可以在項目的早期就對於項目整體的體量有一個大概的估計；在項目進行中，我們也可以直觀的看到項目進行到了哪裡；如果進度偏慢，我們可以方便的看到是哪些部分在影響進度；如果要增加或者刪減項目的某些部分，我們也可以很方便地對項目中的各個小的組成部分進行評估。而不是處處憑藉感覺——感覺很重要，但絕不能只依靠感覺。
2.6 Concept Design（概念設計）
概念設計是我自己的專業方向。我教授過學生概念設計，也嘗試在工作中進行“概念設計”。但是我發現大部分人不知道什麼是概念設計，即使是從業者，也對概念設計有很多誤解（概念設計就是畫草稿），更別提在現在的環境中進行概念設計了。概念設計行業可以說是年輕且不成熟，甚至全世界沒有幾所學校開設了這門專業。下面我所說的一切都是我自己理解中的“概念設計”。
那麼，什麼是概念設計？
狹義的說，概念設計是把抽象的文字設計視覺化。概念設計行業的出現也是隨著娛樂行業的興起，特別是科幻、幻想題材的電影和文學作品大量出現，那麼這類娛樂行業的最前沿自然是好萊塢。概念設計師脫胎自插畫師和工業設計師：從美國科幻黃金年代，給科幻小說雜誌繪製封面的插畫師開始；到之後為科幻電影設計道具、場景的插畫師/工業設計師；再到CG技術成熟，遊戲行業興起，給各個大廠繪製設計稿的概念設計師們——不難發現，最早的概念設計師負責給文字配上畫面（那時候還沒有概念設計），後來電影行業不單單要求概念設計師把文字畫出來，還要確保畫出來的東西能夠落地，再後來的遊戲行業則是要求概念設計師畫出來的東西能夠滿足遊戲設計的要求——概念設計是一個很混合的行業，它要求設計師產出的設計滿足審美上的要求，也需要滿足功能上的需求。
Saiful Haque為Outer wilds所做的飛船概念設計。
廣義的說，設計了概念的人就是概念設計師。J·R·R·托爾金的小說描繪了生動的中土世界，那他其實就是在進行概念設計。金庸構建了一個自己的武俠世界，那他也是在進行概念設計。概念設計師絕不是隻會畫畫的人，概念設計師也絕不是只需要會畫畫。
舉一個工作中的例子，在進行一個遊戲項目的前期概念設計的時候，概念設計師需要做的應該包括：根據故事大綱/時代背景確定美術風格方向；尋找視覺和文字參考資料，繪製草圖；不單單要測試各個不同的角色服裝風格是否滿足審美上的要求，也要確保這些服裝符合時代背景、人物個性；如果遊戲有技術上的限制，還要確保不會給後續其他工種帶來麻煩；如果人物在遊戲的故事中有前後的變化，還要考慮兩個階段的角色設計是否有足夠的對比……等等。而對於場景的設計，要確保遊戲中鏡頭下角色的可見性；如果項目中會出現程序生成或者大量重複相似的場景，要考慮設計時儘量保證美術資源的模塊化；如果遊戲中角色身高多變，要確保場景能滿足各個角色的交互需求不會穿幫……
實際中，各個項目的限制和要求不同，概念設計師需要面對的設計問題也多種多樣。可以說發現問題、解決問題的能力才是概念設計師的核心能力，畫得如何反倒不那麼重要。
這種解決問題的能力在目前國內的概念設計行業基本用不到，而這也是我極其討厭國內現在的行業現狀的原因。遊戲的視覺設計和遊戲的玩法設計、敘事設計已經解耦到一個離譜的程度，遊戲生產過程中的任何一個方面都被資本要求和其他方面脫鉤，以便能夠大批量的快速生產出一個“遊戲產品”。這種高度原子化的螺絲釘式的生產模式，是不存在概念設計師的，只有畫圖的人。
概念設計師在遊戲行業中一般只存在於中大型的工作室或者公司。小公司或者獨立團隊通常沒有“需要概念設計的意識”。即使有這個意識，部分團隊的遊戲體量很小，完全沒有概念設計師發揮的餘地（比如休閒遊戲）；又或者團隊沒有預算去僱傭負責前期設計的概念設計師，通常這個職能會被主美（可能是小團隊中的唯一一個美術）負責。近幾年也有越來越多的中小團隊選擇在進行前期設計的時候臨時多找幾個概念設計師/藝術家/插畫家進行概念設計創作，比如
Jusant、Outerwilds等。對於遊戲項目的概念設計來說，這似乎是一個處在設計質量和成本的甜點的設計方式（相對於沒有專人進行概念設計或者開放一個in-house概念設計師崗位來說）。
Andrey Surnov為Jusant所做的前期概念設計。根據參與了Jusant的各位藝術家在A站上發表的信息，除了Andrey外，DONTNOD還和更多的freelance概念設計師達成了合作。
2.7 Game Design Document（遊戲設計文檔）
GDD是一系列項目設計文檔的綜合，各個項目的GDD結構不同，甚至有的項目沒有一個完整的GDD。我認為GDD有兩個目的：記錄設計大綱，和讓人快速瞭解項目概況。
2.7.1 記錄設計大綱
GDD可以包含很多東西：比如技術文檔，比如遊戲劇本大綱，比如美術概念設定，比如項目的市場調研結果。GDD就是遊戲設計思路的濃縮精華，一份設計的綱領。一個好的GDD一定會讓遊戲的設計和製作過程更加輕鬆，至少會有章法可循。
2.7.2 瞭解項目概況
GDD可以面向團隊成員：除非你是一個單槍匹馬的獨立開發者，你可能不需要一個書面的 GDD，但是一旦組成團隊，GDD能夠幫助其他團隊成員瞭解項目狀況，同步各個成員之間的信息。
GDD也可以面向投資者：良好的GDD代表著項目更加規範，投資者自然也會更有信心進行投資的行為。
但是，獨立團隊要注意的是，自己的項目規模是否需要一個GDD。一個小的項目可能只需要一個Demo便能承擔大部分GDD的作用。
2.8 Pitch
Pitch，就是向人推銷自己的點子。
自信，且狠狠地推銷！
小團隊、獨立團隊可能沒有這個過程。比如團隊可能是通過一個玩法Demo確定了這個方向可行，然後就直接進行製作了。等到遊戲完成了部分再放出demo或者預告視頻尋找發行商、合作伙伴。這個時候因為項目是自負盈虧的，所以沒有什麼pitch的必要，頂多是團隊自己向自己“pitch”，說服自己這個方向能做下去。
正規的公司中大到項目立項與否，小到一個設計方案的選擇，都會通過pitch來決定。這種工作方式的另一個好處我將在下一節詳細說明。
2.9 項目管理，遊戲測試
這兩點都是我所在的公司中項目組暴露出來的問題。
2.9.1 項目管理
項目管理的問題我認為是沒有使用頂底設計模式進行製作遊戲的表現。說人話就是，沒人能夠掌控大局。不做頂底設計，項目的製作進度沒有人能夠做出大致的估算：因為每一個遊戲部分的設計（遊戲已經很難抽象出循環，所以只能說是遊戲的“部分”），都是遊戲設計者零散的遊戲經驗的組合，所以設計者自己也不知道項目會變成什麼樣，更不用說消耗資源情況了。
在有一個項目管理框架後，比如一個簡單的工單系統，此時仍然需要人力去維護更新表格，並且最重要的是——進行驗收。這就引出了下一個問題：遊戲測試。
2.9.2 遊戲測試
我對於遊戲測試的看法是，多測試，儘量早測試。並且有條件一定要去實時的觀察玩家的反應，而不是依靠測試問卷——大部分人不願意填寫問卷（或者不願意批評），我們設計的問卷中包含的問題不一定是測試者遇到的問題。在這個問題上我也諮詢了一位朋友，為了避免問卷的主觀性，他舉了這樣的一個例子：比如在驗證什麼樣的角色控制方式更能被玩家接受，他們會直接統計玩家在每種控制方式下的遊玩時長，時長最長的控制方案即被採用。
儘早測試，避免屎上雕花。
有的時候，一些遊戲的測試demo是無法進行評價的。通常這種demo沒有一個完整的玩法循環，試玩者無法進行任何有價值的評判，頂多評價兩句畫面表現如何如何。更糟糕的情況是，在進行一些demo的試玩過程中，出現了大量的待優化的UI/UX、邏輯、表現問題。這個時候不提評價demo了，此時這個項目的管理和溝通一定出了問題，否則不會放出來一個明顯各個功能未驗收的版本。
測試遊戲，驗收功能其實和項目組所使用的製作工具和製作流程相關性很大。小項目組通常沒有一個好的工具和工作流程，如果項目規模很小，那尚且可以通過蠻力一一驗收遊戲的各個部分。但是，當項目規模變大，此時好的工具、工作流程就是必要的了。
舉一個簡單的例子，文本測試：當小項目組進行一個文本量小的項目的時候，文本寫完了就可以通過程序（或者文案自己）配進引擎中，然後跑一遍對話就可以驗收了。但是，當項目的文本量比較大，特別是牽扯到多分支文本的時候，上述的工作流程會出現這樣一些問題：
- 當文本分支變多，並且選擇會影響到遊戲進程的時候，負責配文本進引擎內的人如果不是文案自己，那會增加一層溝通成本：文案要和對接者溝通好如何配置文本分支以及後續影響；如果文案自己配置文本，那要求文案需要擁有使用引擎配置文本邏輯的能力。
- 在這之上，如果文本配置過程中還包括動畫演出、邏輯更改、數據更改等更加複雜的要求，這對於文案的要求更加高了。如果不是文案自己去配置，那麼就需要一個更加詳細的文檔去說明這些內容。
- 此時，驗收文本配置的工作就變成了一個艱難的任務。在沒有良好的文檔的情況下，一個一個分支去驗收變成了幾乎不可能完成的任務。即使有良好的文檔，也需要耗費大量時間實機運行遊戲才能測試。
- 雪上加霜的是，即使配置驗收完成，一定會發生的情況是後期對文本表演等內容進行修改或者優化。而每發生一次這種迭代，基本意味著把之前的流程全部重來一遍。
很顯然，項目規模變大後，擁有良好的工具和工作流程就變成必要的了。寄希望於小項目的經驗，企圖純粹依靠人力或者蠻力去完成大項目是十分不理智也不現實的。
但是引入新工具和規範製作流程會增加工作量，並且接入新的工具和流程勢必需要其他遊戲製作的其他部分配合。所以比較理智的選擇是，進行製作前先跑通流程，評估工具帶來的便利和增加的成本是否處在合適的平衡點，確保從設計生產到最後的測試環節都合適自己的項目組。
3. 溝通
在討論完以上這些名詞後，我想談談製作遊戲中更軟性的能力——溝通能力。
3.1 關於如何討論問題
討論的規模有大有小，有全組成員的大會，也有兩個人之間的小會。有的人討論問題的時候，面對和自己相反的觀點會變得非常的passive aggressive，會嘗試尋找各個理由進行反駁；有的人討論問題的時候，會帶上過多的個人取向，會嘗試加入自己喜歡的內容；還有的人會十分看重自己的觀點，嘗試說服所有人同意自己的看法……
一次友好的討論。
所以我認為，討論問題的時候，所有人都需要做到以下四點，討論才有進行下去的可能性：
3.1.1 明確討論中要解決的問題是什麼：
討論一定要有一個大綱，至少應當記錄下來每個討論主題的關鍵字。這樣可以避免討論的時候在一個點上無限發散，最終回不到要討論的問題上——討論的時候需要發散，而且一定會有成員喜歡發散性地思考事情。
3.1.2 明白討論的時候，我們在就事論事：
那麼接下來，討論進行時，針對同一個問題一定會有不同的人提出不同的方案。沒有人喜歡自己提出的方案被否定，但是討論中我們應當明白的是，自己的方案被否定，不是自己的人被否定了。同樣，指出他人方案的不妥之處的時候語氣可以委婉，但是應當直接了當地指出問題。
這種快速高效的溝通方式的前提就是，大家應當明白討論的時候，所有的意見都只是針對討論的問題。在討論中人產生情緒是應該的，但是我們應當能努力消化掉這些情緒——想想大家都是為了項目更好而說出自己的想法，這樣應該能讓自己好受很多。
3.1.3 給出的解決方案要完整：
在討論之前，方案提供者準備好完整的解決方案，是提高討論效率的最佳方式。工作中我遇到過一類“即興思考者”：他們給出問題的解決方案可以很迅速，但時常無法細細思考下去，連續追問一兩次便會卡殼。討論時一定會有靈光一現的時刻，但是在討論前能進行提前的思考，給出完整的方案一定是更尊重所有參與討論的人的工作方式。
3.1.4 要記錄下來討論出的解決方案：
小團隊中還容易出現的一個問題就是沒有會議記錄。會議記錄不用非常正式，但是應當至少能給參加會議的人在日後提供一些回憶的錨點。特別是兩三個人的小型討論會，如果不做記錄，一定會出現過了一段時間後所有人都忘記了當初針對某一個問題得出的具體解決方案，那就只能幾個人再重新討論一遍，事倍功半。
當沒有人做會議記錄的時候，討論中還會出現一個問題就是隨著討論的深入，或者話題的偏離，大家會漸漸忘掉討論的主題，自然也就很難日後回憶起當初在討論什麼。通常來說，如果有一個會議大綱，那麼也應當會有有效的會議記錄，這兩者像是雙胞胎一樣，一般都是同時存在，或者同時不存在。
3.2 從不同視角進行溝通
最有效的溝通往往產生在溝通雙方都對對方負責的環節有一定程度的瞭解。
在製作遊戲的流程中，越是早期的工作越需要對下游工作環節有一定的認知。如果策劃提出要增加某個系統，ta應該能瞭解到一個新的系統對於程序、美術、動畫等工作環節會產生多少影響；如果美術提出要修改一些表現，ta也需要了解美術表現上的改動是否會對玩家體驗造成影響，這些改動又是否會需要程序進行配合；如果文案提出需要進行修改，那麼ta應當確認好這些改動是否會影響到動畫的演出……
一個常見的人類獨立遊戲製作者。
當然，這是不現實的幻想，每個人有專精，不可能一個組的所有人都是全才。但是，這應當是每個製作遊戲的人努力的方向，也只有這樣能夠換位思考，團隊成員溝通起來才能夠更加順暢。
3.3 如何critic
接下來，我將從兩個角度來更具體的說明，明確設計目標後我們應該如何討論設計問題。
3.3.1 方案提供者
對於方案提供者，要儘可能的提供多個解決方案，並且應該保證每個方案方向儘可能不同。比如，假設現在要解決玩家在遊戲中走路的時間過長這一問題，那麼以下兩個方案顯然過於相似：
1. 給與玩家速度更快的交通工具，比如馬匹；
2. 給與玩家飛行的能力。
這兩個方案本質上都是縮短玩家從A到B的時間，那麼作為設計者，此時我們應該提供更多其他的方向，比如：
1. 增加玩家路程中可以遊玩的內容，比如增加NPC、交互內容、或者更多的支線任務；
2. 直接減少玩家的走路時間，在玩家完成從A到B的首次旅行後，直接跳過旅行階段；
這是一個非常粗糙的例子，但是在實際設計中，設計者會非常容易陷入一個方向的更加細分的解決方案。最差的情況是，這些方案顯得十分像是拿來湊數的。
大家完全看不出來你的設計在湊數呢！
接下來在展示自己的方案時，不要一上來就直接跳躍到方案結果，而應該一步一步說明自己是如何得出這個設計方案的。說明自己遇到的設計困難，以及如何克服困難，這也是在給方案的聆聽者時間去思考。而當確實無法提供更多方向的方案時，不如開誠佈公，提出自己方案的缺點，詢問其他人是否有更多的提案。這時候，作為討論中的另一方，應該如何討論呢？
3.3.2 方案聆聽者
首先，如果方案十分成熟完整，那麼皆大歡喜，不要吝惜自己的讚美。
其次，如果面對的是一個不成熟的方案，仍然第一步是找到其中的閃光點。這一步足夠難倒很多人。我不知道有什麼方法能讓人發現一個不好的設計的優點，我能總結的方法就是跟著提供方案的人的思路去思考，明白ta為什麼會做出這樣的設計選擇，這樣總是能夠找出值得誇讚的地方的。
接下來，才是找出方案中的缺點。這一步不是隻指出問題，而應當要提供一個自己認為的能夠讓這個方案更好的設計。對一個設計評頭論足永遠是簡單的，困難的是如何幫助一個設計方案變得更好。
“我喜歡你用彈力帶做絞刑繩子的想法，但是如果能讓受刑人死得更快就好了。”
3.4 尊重你的工作夥伴
一個只在公司工作過的人永遠也不會明白這句話的意思，他們的工作夥伴不是自己挑選的。經歷了更換專業，更換學校，參加各種小項目之後，我深切體會到，能找到志同道合的人一起為一件事情努力是多麼的不容易。並且我越發體會到，團隊中一個人的能力如何絕對不是最重要的，因為能力總是能夠提升的。更重要的是，在團隊中一個人能否百分百的發揮自己的能力，能否和其他人共同合作，產生一加一大於二的效果。
我記得以前看過一篇小島秀夫的採訪（寫文章的時候我又去找了很久，結果沒找到），採訪人問他為什麼要製作這麼多遊戲的宣傳片，並且頻繁的放出這些預告片。小島秀夫的回答大致是這樣的：他明白製作一款大型的遊戲需要很多人很多年的努力，這些共同工作的人會在製作這個遊戲的過程中經歷很多新的人生階段，有的人會結婚，有的人會生小孩，有的人會經歷親人離世等等。他希望和自己共同工作的人能在這麼長的時間跨度中，有東西能告訴身邊的人自己在為什麼東西努力工作。
我記得當時看到這裡我感慨萬分，這種對於工作夥伴的尊重，是我這三年工作從來沒有體會到的。所以我自己帶隊參加jam的時候，哪怕隊友只是做了很少的工作，我也會在製作人名單里加上他們的名字，我想要和大家分享製作遊戲的快樂。
一名應屆畢業生參加工作三年的變化。
4. 可行的製作流程
製作流程分為製作前期、製作遊戲、遊戲製作完成後三個部分。而我已經在第二部分的各種名詞概念解釋中，先把這三步走的流程中容易踩坑的地方提取出來詳細展開描述了。
那麼，籠統地再梳理一遍，製作前期包括市場調研，確定方向，招兵買馬，前期設計，拉投資立項等環節。對於非商業的獨立遊戲製作者來說，這一部分可能會非常精簡——所有和市場調研、拉投資立項相關的內容都可以省去。但是以國內的環境來說，即使大部分團隊或者個人打著獨立遊戲的旗號進行遊戲開發，其實大家都是希望能賺到錢的，那麼這些很“商人”方向的環節其實才是最重要的。
像前文所說的，如果一個項目製作前期完成的很好，製作中期其實就是漫長的堆量過程。無論是團隊還是個人開發，如果製作框架沒有大問題，在這個階段倒不如多花點時間照顧照顧自己或者團隊成員的心理健康，這是我根據自己的經驗唯一能想到會踩雷的地方。
製作完成後，一般來說是測試，優化和發行的部分。但是，我認為測試優化和宣發都應該提前到製作中期就開始進行。特別是宣發，對於我個人來說這反而是最消耗精力的部分，因為這需要我頻繁地在開發者和宣傳者的工作狀態中切換。而即使遊戲開發完成，我能夠暫時卸下開發者的擔子之後，我也很難在痛苦的開發工作之後馬不停蹄地繼續製作更多宣傳物料，去各種平臺上吆喝——實在是沒有幹勁了！
如果想要更加“專業”一點，那麼提到製作流程，就不得不提到遊戲設計文檔（Game design document）。網絡上能夠找到很多制式的遊戲設計文檔，不提其中的內容，光是文檔的格式就能嚇人一跳。對於我這樣的實用主義腦袋來說，我更希望知道的是拋開它的結構和格式，這份文檔到底應該發揮什麼樣的作用？或者說，應該如何寫一份適合自己的遊戲設計文檔呢？
一個常見的遊戲設計文檔模板。
4.1 從設計者角度
無論是美術設計者、還是程序設計者、還是遊戲設計者……任何設計者在設計前都需要明確的兩件事情是：設計目標和設計限制。所以從設計者的角度來說，一份設計文檔應該包含的是滿足設計目標和設計限制的框架。這份文檔需要闡明設計目的、設計方法，能讓團隊中的其他成員快速地瞭解對應方向的概況，並且指導遊戲的設計開發工作。
舉例來說，我熟悉的美術方面，一份良好的美術文檔除了包含最基礎的制定風格（畫成怎麼樣）外，更重要的是能夠說明如何達成指定的風格（怎麼畫成這樣），以及說明選用這種風格的原因（在限制下進行設計）。很多美術主導的團隊，很容易出現如下兩種情況：第一種是美術表現力很好，但是主美術沒有能力製作美術文檔，導致除了風格制定者以外的美術團隊成員無法很快地加入美術資源的生產中，更糟糕的是這種團隊也很難培養美術新人，極度依賴關鍵角色的發揮；第二種情況是團隊因為擅長美術表現，所以過於依賴美術，輕視遊戲的其他方面，以及在某些設計問題上企圖使用美術表現大力出奇跡而不是思考更加有效的解決方案。
一個簡單的例子：假設一個2D為主的項目中需要一個書本翻頁的動畫，一個更加需要動腦子的解決方案是團隊討論能否使用3D完成翻頁動畫，方便以後資源複用。但是過於依賴美術的團隊很可能會出現如下情況：團隊第一次遇到需要翻頁的動畫時決定使用逐幀動畫解決問題（甚至不會去思考複用的問題），以至於之後的所有翻頁乾脆全部使用逐幀解決。
需要注意的是，這種路徑依賴並不是只出現在美術上。團隊中如果程序能力十分突出，也可能會出現對應的問題，仍然拿翻書動畫舉例，假設這個動畫只會出現一次，那麼如果一個逐幀動畫可以解決自然好過更加複雜但是通用且便於維護的解決方式。這裡的關鍵是，設計文檔應該是非常務實的指導解決問題的方法的文檔，什麼方法性價比最高就使用什麼設計方法。
4.2 從製作產品的角度
如果跳出設計者的視角，從“生產產品”的角度來看待遊戲製作，又有哪些需要明確並且記錄在設計文檔中的內容呢？
首先，先要確定遊戲這個產品各個方面所需要用到的生產路徑。在這一點上，技術實現和美術實現兩個方面是更加貼近傳統的製作“產品”的思路的：即要使用到什麼樣的技術，以及要實現什麼樣的美術效果。
舉例來說，如果要做一個類似猛獸派對式的遊戲，那麼需要解決的技術問題可能有在線聯機、多人在線物理解算等後端問題；以及一些和畫面表現相關的技術問題，比如毛髮渲染、ragdoll系統、程序生成的動畫等問題；還可能會有一些和遊戲系統相關的問題，比如文本管理系統的本地化、搭建和使用音樂/音效系統、多種操作模式的映射、內購、更新等問題……美術方面則在上面的美術文檔部分討論過了，不再贅述。
在確定了生產路徑之外，還有一點也同樣重要，那就是成本估算。但無論是時間成本還是金錢成本，成本估算總是更加依賴經驗的。就像每個獨立開發者可能都聽過的傳說：要給自己的項目至少兩倍以上的時間預算（或者更多，哈哈）。這就需要文檔作者確實瞭解一些生產的細節，從生產實踐中來，最終才能走到生產實踐中去。
4.3 從創業者的角度
文章寫到這裡的時候其實我內心是很虛的，即使聽過有人說獨立開發者應當把自己視為創業者，而我自己也贊同這一點，我也沒法說出更多的見解——我自己還沒真正開始“創業”！但是在寫文章的時候碰巧我看到了這個視頻This Problem Changes Your Perspective On Game Dev（作者是Thronefall和ISLANDERS的製作者），作者是從Search Algorithm的角度來看待獨立遊戲設計的。這對我啟發很大，特別是站在一個創業者（開發者）選取創業方向（遊戲製作方向）的角度來說，用搜索算法的視角來看待選取方向的問題確實幫我梳理了思路。
5. 後記
首先要感謝你能閱讀到這裡，也感謝文章成稿後提出各種反饋意見的朋友們，謝謝你們的反饋、鼓勵和支持。
這篇文章大部分總結出來的經驗都是來自於我觀察自己所任職的公司內部各個項目組的情況得來。但是越往後寫，我越釋然。開始時我是很憤怒的，語言也尖酸刻薄。寫著寫著我覺得沒必要這麼憤怒了，因為每個人做遊戲追求的東西都不一樣：
有的人追求的是把遊戲作為表達自己的媒介，那麼我就很難苛責ta在製作遊戲流程上的各種缺點；
有的人追求的是畫面好看，想把自己作為藝術家的審美散播開，讓大家視覺上得到享受，那我也無法對ta的遊戲的遊戲性要求很多；
還有的人追求的是做一個自己夢想中的遊戲，把所有自己覺得好玩的內容都塞進去，那我便無法去批評ta的遊戲體驗混亂，設計糟糕；
更多的人不知道要做什麼，做遊戲只是一份工作，混口飯吃，那我更加無法要求ta要全身心投入項目，做個好遊戲……
到頭來這變成了一篇寫給我自己的避坑指南，一份提醒我自己不要再犯文中所提到的這些錯誤的備忘錄。文中很多觀點可能都經不起推敲，因為我自己的實踐經驗有限。在寫完這篇文章之後，我也將更多的投入實踐，真正地使用我的遊戲製作方法論進行遊戲開發。
希望這些凝結自痛苦彷徨的經驗總結能幫助到你。