做了三年的遊戲專案宣佈關閉，失敗經驗

作者：竇月汐  首發知乎，
原文：https://zhuanlan.zhihu.com/p/372336924

序

從我進入這個公司到現在，我們花了三年半的時間來製作一款有特色的遊戲，直到最終制作人決定專案關閉。在外面的人看來，我們消失了三年而一無所成，確實如此。從我們成員自己的視角看來，失去了人生中的一段寶貴的三年，隨著專案的閉關，所有勞動成果都將埋沒。唯一積累下來的，只有隱隱作痛的失敗經驗。

在做商業專案之前，我是不相信真正用心的遊戲專案會在上線前失敗的，甚至上線後如果反響不佳，也不一定就宣判失敗。失敗一定是有原因的，我相信只要能夠定位到真正的原因，並把它解決，就能夠避免失敗。我有一句口頭禪：問題，就是用來被解決的。但我疏忽了一點，有些時候人們能夠發現問題，能夠想到解決辦法，但並不一定會有意願去解決問題。有些時候是權衡利弊，覺得解決問題的成本太高而不願意；有些時候是信心不足，覺得沒有足夠的能力去正面處理問題而不願意；有些時候是興趣不足，單純地不喜歡做對解決問題而需要展開的行動。在此之前，我也並不拿市場的表現去評判一個遊戲的成敗，所以有時候我並不清楚專案的“失敗”到底代表什麼，現在大概有個認識了：失敗就是，大多數成員對此失去了信心。

而我是屬於少數的那一部分。

這篇文章，我是想總結一下三年專案期間經歷的一些事情——會導向失敗的事情。並非為了問責或其他目的，僅僅是想為以後或同行的其他專案提供有用的經驗，以加大將來專案成功的可能性。從現在回溯過去的開發歷程，我認為我們專案中為失敗埋下伏筆的有這麼幾個因素：

• 對遊戲終極想象的不一致和不堅定
• 對“好”評價標準不一致
• 對細節的盲目追求
• 決策者與設計者的合作方式問題
• 試圖量化設計方案
• 對於不確定因素的虛假自信
  

下面我將以第三人稱視角來敘述這些問題。

對遊戲終極想象的不一致和不堅定

專案製作人是一名近50歲的資深引擎程式設計師，作為玩家和開發者更偏向模擬經營莊園養成類遊戲，並非MMORPG遊戲型別受眾，也從來沒有深入玩過現代主流沙盒遊戲。興趣點在於實現有難度有挑戰性的技術方案，喜歡實現各種遊戲Demo。

專案主策是一名資深的MMO、沙盒遊戲玩家，對於傳統的開放大世界營造很熟悉，並且也深刻體會到傳統MMORPG型別遊戲數值無限積累的玩法弊病，希望建立下一個時代的MMO玩法框架。

專案主程，是資深的競速遊戲玩家，對於非競速類硬核PVP型別遊戲經歷並不深入。希望建立一個模擬世界，讓世界中的NPC如真人一樣活動，從而演化出社會。

專案立項的契機是製作人與朋友的交流，碰撞出一個“大世界”+“領地爭奪”的想法。從技術上來說，這個想法的實現技術壁壘還是比較高的，市場上幾乎沒有專案做到。從策劃上來說，這個上層玩法能夠很自然地解決MMORPG和沙盒遊戲的數值積累通病，實現價值很高。當然由於它是同時凌駕於MMO和沙盒之上的，所以設計難度也非常高。

在立項之初大家對於遊戲的總體描述還都是一致的：把一群玩家丟進一個大世界裡，讓他們自己生存、發展，爭奪領地，最後遊戲在領地的不斷爭奪迴圈中進入動態平衡。隨著遊戲的不斷開發，每到一個細節路口，我們都要做一些取捨判斷。主策因為有豐富的沙盒遊戲經歷，所以他更偏重於在沙盒的基礎上實現上層玩法，所以許多設計都帶著強烈的沙盒風格，比如嚴酷的生存挑戰，高勞動強度的物資採集，真實的死亡懲罰。並且客觀推演出遊戲要實現上層的領地爭奪玩法，最終遊戲氛圍會是一個週期性軍備競賽，硬核PVP戰鬥的遊戲，並且始終保持這一結論。製作人由於是模擬經營類出身，在成長上更偏向于田園小鎮生活，生動的勞動表現，輕鬆的生產環節。在PVP戰鬥上一般持保留意見，隨著後期的不斷開發，模擬經營的思想基本完全佔據了決策上風，開始弱化PVP。

在主策看來，弱化PVP基本就背離的立項的最初的想法：領地爭奪。在遊戲開發的第三年，期間不斷的交流碰撞中，製作人提出了新的方向：大世界+莊園養成。無論是出於對設計難度的考慮，還是出於對開發成本的考慮，方向肯定是一次大改。在改方向的半年後，遊戲基本面目全非，十個月後宣佈專案關閉。

後面在交流總結的時候，大家也提到對遊戲終極想象的不一致，導致在開發過程中對各種細節設定的取捨想法不同。而製作人在開發前期對領地爭奪的積極想象，到後期逐漸傾向於莊園養成的轉變，進一步提高了終極想象的問題解決成本。

本來人人都是會有不同的經歷、不同的思想，在興趣和偏好上也有自己的一套，這是一個客觀現象並不是一個問題。而不同的人湊在一起組成一個團隊，去實現同一個目標，這是再正常不過的事情。關鍵在於，當大家想法不一致的時候，需要有人能夠站出來主持大局，讓大家心往一處想，力往一處使。有人該妥協的需要妥協，以實現團隊目標為第一優先。我們經歷的問題在於：團隊目標逐漸變成了領導者個人目標，並且個人目標還在發生改變。製作人首先提出“大世界”+“領地爭奪”的團隊目標。主策堅定地接受這個目標，並客觀地去推演實現目標的過程和最終效果，之後在這個路徑上做了兩年多的設計工作。然後製作人由於某些因素的考慮更改了團隊目標，這一決定直接使前面的工作變成沉沒成本，間接導致了專案後期的混亂。

因為遊戲開發不同於普通的應用程式開發，應用程式會講究系統解耦，每一個模組相對獨立，完成自己需要負責的事務就行，儘量不要與其他模組糾纏，這樣在改的時候每次都可以獨立修改單一模組。而遊戲專案越到後面越講究模組耦合，把遊戲裡所有的系統功能、設定全都融匯打通，讓它們形成一個有機的整體。兩年多時間，主策都已經把各個模組耦合得差不多了，這時候叫改，而且是改大方向。這不是鬧著玩麼？

如果說早一點，在專案前期幾個月，就把方向、體驗推演清楚，那時候改方向完全可以。並不是說一定要“大世界”+“領地爭奪”才能擊穿市場，並不是說“大世界”+“莊園養成”就做不出精緻的遊戲。只是，大家要從一開始就確定遊戲的最終想象，並至始至終堅持它，越到後期越堅持它。這是一種成事的信心。

如果立項的時候，核心成員就信心不足，抱著試一試的心態進來，那時間會證明他多半靠不住。做事還行，拿捏事情就算了。

對“好”的評價標準不一致

每個人都會去追求“好”的事物，為“好”的觀點發表言論。同時每個人也都有自己的價值觀，和一套個人的評價體系，去指導我們評價其他事物是不是“好”。

遊戲開發的過程，是一個創新、創造的過程，在很多方面它不像標準化的工業流程那樣存在具體的指標去判斷每個環節處理的好壞。並且我們的專案一邊開發遊戲業務，一邊還開發工具，建立製作流程，同時在內容設計、規則設計上，一些設計原則也是在過程中固定下來的。這個過程走得非常艱難，往往一個小的問題意見不一致，就能把問題上升一級去討論，追溯到設計理論、設計理念、設計原則層面，仍然會產生不同的意見。

舉一些例子，比如說：玩家死亡，裝備要不要掉落？

主策思考這個問題的時候，想的是：裝備不掉落不損失的話，資源的積累就沒法釋放，最後還是會走進數值困境。主程會認為：對於現代RPG玩家來說，裝備的養成打造是很費心的，如果搞半天掉了沒了，玩家會接受不了而退遊。一個站在框架完整性的角度去思考，一個站在玩家體驗的角度去思考，兩個角度都肯定有自己的正當性，那這意見分歧怎麼解決。

然後主策提出：對於核心玩家來說，一套裝備的損失肯定是不好的體驗，但不至於退遊，這是一個玩領地爭奪的遊戲，其他東西都是為核心服務的消耗品。主程也是行業老兵，會提出：一個MMO級別的網遊，如果不能保證大眾玩家的體驗，就不能保證玩家基數，沒有這個基數，領地爭奪根本玩不起來。所以普通玩家的體驗得保證，掉裝備核心玩家能承受，普通玩家能承受嗎？有些問題一旦提出，它就沒有便宜的處理方式。

最後問題可以上升到，我們設計遊戲的原則，是“在保證大眾玩家的體驗上，深挖核心玩家的需求”，還是“在保證核心玩法核心玩家的體驗上，儘可能讓更多人能玩上手”。主程明顯持有前一種設計原則，而主策持有後一種。在原則、理念這個層面，大多數時候我們並不能分出孰是孰非，只是大家的基本思想不一致，這是一個客觀事實。這個問題，在日常中的表現就是各種小問題的意見矛盾。

上面說的是“設計理念”不同引向的問題，還有另一個維度的評價標準不一致——做事風格。用專業術語描述就是“設計方法論”不一致。

舉個例子：在專案開發的第二年，基本的沙盒生存建造的內容都已經落地了，接下來應該做哪一部分？製作人認為應該做任務系統、引導系統，把前面已經做的內容串起來，做成一個可以體驗的遊戲流程，後面的開發工作就是在不斷地去增加內容延長這個流程。主策認為遊戲中最核心的部分“領地爭奪”系統還沒有落實，它屬於框架中最重要的一環，應該先做它以閉環整個玩法迴圈。

這兩個人的設計方法論，一個是“一步一個腳印”型，一個是“先打框架再填內容”型。這個基本做事方法不一致，會導致配合過程中內部產生應力。由於製作人是具有最終決策權的角色，所以第二年還是以做前期流程作為了主要團隊工作。後面基本上每個月都會迭代一個版本，來跑一趟前期流程。新手引導是不是順暢，數值是不是合理，表現夠不夠生動，任務有沒有節奏。“一步一個腳印”的方法最大的問題就是，當你意識到有幾步走錯的時候，那基本上前面精心踩出來的腳印都得重搞一遍。比如第二年年底，我們流程好不容易搞得有滋有味了，然後製作人出於想輕鬆生產的意願，決定要實現自動倉庫。然後前面所有的生產環節、天賦加點、機器設施、任務指引都得跟著改，要知道這些玩意兒可是花了幾個月精心打磨過的，每一個細節都是經過推敲經過團隊共同認可的。

為什麼製作人會做這樣的決策？從他的角度來說，肯定是因為覺得先做流程體驗比完善框架要好呀，流程做了就能讓人玩起來了，框架做半天啥也玩不到。改方案也是因為改了之後體驗會更好呀，至少他作為玩家來說他的個人體驗會更稱心意。因為秉持的基本方法論就不一致，所以就算讓主策來做最終決策，那結果又會怎麼樣呢？也是有事實證明的。後期製作人覺得自己把握不了這個專案，讓主策來全權主持大局，製作人完全不干預製作。然後主策帶著團隊花了6個月時間，把遊戲所有的框架都搭建完成了。最後呢，6個月階段驗收的時候，製作人一玩，發現這兒也毛糙，那兒也有瑕疵，說是框架搭完了，但遊戲體驗晦澀不堪根本走不下去，玩不到領地爭奪那兒就想退遊了。在主策看來，這隻一個階段性驗收呀，以前一直沒閉環的玩法，總算完成了，接下來就只需要按部就班新增內容，打磨細節就行了。但是在製作人看來：時間給你了，你就拿出這麼個表現的東西，別說什麼核心玩法，連物品描述這種最基本的內容都沒寫全，後面還搞個啥。

兩個角色在同一時刻對同一輪測試做出完全不同的評價，基本上就是因為做出評價時採用的評價系統不一致，在我們這個案例中就是做事方法論不同。對於先做什麼後做什麼，在什麼時間節點應該完成什麼事情，持有不同的觀點。設計方法論的問題不同於設計理念的問題，方法論確實是能分出個孰優孰劣的，因為這比較的是誰能把事情做的更好更快更低成本高容錯。問題就在於，誰都覺得自己的方法是更好的，對方的不行不行。

對細節的盲目追求

這一節緊接著上一節的“一步一個腳印”式做法繼續講。不知道大家有沒有看過網上美術大師畫畫的視訊，如果看過的話你們會發現，他們經常喜歡從一個區域性出發畫完整幅畫。

然鵝當我們去學畫畫的時候，你如果這麼畫的話，多半會被老師摁在調色盤裡，告訴你先構圖，先起形，別抓著個眼睛細節在那兒可勁兒磨。畫過畫的人都知道，扣細節爽，一直扣，一直爽，扣到最後發現，兩個眼睛單獨看是挺好看，合到一起，咋是歪的呢？啊？咋辦，擦了重來，扣兩小時細節白搭。

那都還好，畢竟一幅畫的創作時間不太長，不像我們做遊戲動不動幾年搭進去了，做到第二年發現前面做的不對，得重來，那誰遭得住？

會遇到這種問題的開發者，多半都是有細節癖，當然也可以說自己是完美主義者，自己是自我要求很高的遊戲人，作品裡容不得瑕疵。

其實這些問題的根源有兩種：一種是對專案的把控缺少全域性性，心中的不安只能用豐富的細節去彌補；另一種是有了全域性觀，但是對計劃和成本沒有把控，放任時間和資源成本的膨脹。前一種是新手上路畏畏縮縮，後一種是大佬飆車放飛自我。但不管是哪一種最後多半都不會有啥好下場。（Rockstar的大佬除外）

不管什麼級別什麼資歷的開發者，我都建議採用框架式設計。就像蓋樓一樣，要先打地基，然後建樓體框架，然後裡外裝修，通水通電。一步一個腳印是啥意思，就是先打地基，然後蓋第一層，蓋的時候直接做到樣板間的程度，做好了能住人了，住著舒服了，再開始蓋第二層。每一層都要裝修完能住人才允許繼續往上蓋。有開發商這麼蓋樓的麼？

插個題外話，我們立項之初，有個建築師朋友正好開始施工建一個小樓，我們專案關閉的時候，他們樓已經建好了。

在我們的專案中，第二年制作人一直壓著要做前期流程，要把每一個細節打磨到位。並不是說做遊戲不該打磨細節，而是要看什麼階段該去打磨細節。樓體沒有建好呢，去做裝修有什麼用？因為製作人長期投入精力在引擎和工具開發上，對遊戲全域性設計幾乎託管給主策，所以他內心肯定是有所不安不確定的，而他能確定的就是那些他能看到能聽到能互動的那些遊戲細節。另外製作人還把這個專案當作是他的收官之作，所以在成本投入上，幾乎是不設指標的，專案不設開發時間表，要問什麼時候要做到什麼樣，不知道；什麼時候能做完，不知道。這個澆水的時候，水滴灑下去回彈的感覺必須得加一下。水滴在地上和葉子上的不同層次的聲音也也得體現出來（舉個例子）。包括後期主策全權負責專案的時候，在階段性驗收中，也去用細節打磨的問題來做出負面評價。在主策看來：壓根沒做的事情，也可以被評價做的不好麼。就像造一輛車，造到一半，人家說你這車輪子咋就只有個輪轂呀？

不管是做作為個人開發者，還是專案管理者，在聚焦細節的時候都應該先看一眼專案時間表，看一看現在是個什麼階段，做什麼工作才能使專案離成功更近一步，而不是盲目地任性地進入細節打磨狀態。我們應該不停地審視專案階段，在開發過程中專案狀態是動態的，這個月可能戰鬥系統是最大的短板，下個月可能戰鬥系統還沒做完善，但是橫向比較坐騎系統已經變成最迫切需要落實的模組了。工作計劃需要跟隨專案狀態實時更新，以確保專案是在全域性性地推動。

決策者與設計者的合作方式問題

遊戲製作人負責製作什麼？

可能會有各種答案，但肯定不會是開發工具。

在我認知中，一種遊戲製作人就是主策，負責設計遊戲的主體內容框架，決策重要內容。另一種遊戲製作人更多扮演專案經理的角色，管理專案進度，協調資源。這都是可行的職權方案。

但是很多時候分設了製作人和主策的崗位，卻沒有明晰兩個崗位的工作職責。最典型的問題就是，最大的決策權在製作人那裡，但是要主策去全域性設計遊戲。既然要主策去把控全域性，那製作人的決策權，他決策個啥？用什麼依據什麼視野去做全域性決策？要做全域性決策，就要思考全域性的事情。不然做出正確決策的概率跟抓鬮沒啥區別。

在我們的專案中，製作人由於是程式出身，本身的興趣點也在於技術實現上，所以開發期間大部分時間都在思考一些技術難點如何實現，一些開發流程能不能優化加速。主策問及巨集觀問題的方向時，製作人時不時就避重就輕，把話題引向具體細節展開討論，最後對原初問題做一個草率決定，並加以說辭“先試試看吧”。慢慢地主策意識到，有些問題是不用問的，自己心裡很清楚該怎麼做才是對的，問的話反而會得到其他不可知的答案。但是這樣，對於重要決策，免不了遭到製作人“中途”問責存在先斬後奏的行為。

然後主策的溝通策略變成，帶著問題和答案開啟交流，就是報告發現了什麼問題，同時也想好了解決方案該怎麼做，說一聲大家知曉一下。但是這種報告總是會引出“更好”的解決方案。聰明的人都會認為我能比別人想出更好的方案，權力的上游尤其會有這種錯覺。然後主策經過數天深思熟慮，平衡利弊得出的方案可能就被五分鐘討論出來的方案替包了，甚至連他自己都覺得新的方案似乎更好。回去冷靜下來一思考，剛才我們確定了個啥玩意兒？

再後來主策的溝通策略變成了：引導製作人思考，讓製作人想出一個他覺得是他自己想出的，同時符合主策預想的解決方案。這溝通一下就變成一個藝術活的。就像你想讓你家孩子認為喝開塞露是錯誤的，但是你不能直接告訴他那不能喝，他會覺得那玩意兒那麼好喝為什麼不讓喝，我偏要喝。你得想點辦法讓他“自己”覺得那玩意兒不能喝，讓他這個想法產生於他自己的思考，而不是你的灌輸。

有些時候，事情本身並不難做，難的是讓人做事情。

而上面那些奇奇怪怪的溝通技巧其實可以不用的，因為越是有技巧性的溝通肯定越是消耗心力的，有這些心力留著去思考遊戲本身的設計問題它不好嗎。一個團隊要把職權分清楚，把最終決策權交給做全域性思考的職位手裡，拿著最終決策權的人也要做好全域性思考的工作，不要用任何方式迴避巨集觀問題，也不要妄想交給他人託管。

試圖量化設計方案

在評論中看到猴與花果山，猴叔的深刻分析，感覺非常有啟發。但是猴叔表示文中沒有反應主程的問題，批評得不夠均勻，所以回來特意補充這一小節。

其實主程是一個無可指摘的老好人，一直兢兢業業地開發業務邏輯。唯一能說道一下的就是在溝通中，主程會習慣性去量化設計方案。讓方案的提出者回答——這個方案有什麼好處，會帶來什麼其他問題，好處與壞處相比哪個更多？是能讓遊戲更好玩，還是創造更多收入？

當一個方案建立時，它確實應該經歷上述問題的審視。這樣會逼迫方案提出者考慮更全面，平衡利弊更清晰。

而問題在於，如果這種提問，變成了一種溝通中爭奪我方正當性，提升對方回答成本的，話術。那麼這個話術的威力可就太大了。可以駁回幾乎任何感性的設計方案。因為感性的東西很難用量化指標去評估的，即使方案提出者信誓旦旦回答“好處大大滴”，那大家心裡葉門兒清不能信。

這種話術經常發生在，主程正在專心看早間新聞，或者正在焦頭爛額地處理棘手BUG，然後主策屁顛屁顛去提出他想了好幾天上的方案，讓對方評估一下準備實現。

對這個問題進行分析，其實深層次的原因並不在與程式設計師的思維方式問題，而是開啟對話時參與者的狀態問題。明明人家此刻都不處於Ready to talk的狀態，但是非要開啟一個方案的討論，那受害的多半都是無辜的方案。

另外就是忠告，真正抱有量化思維習慣的開發者，遊戲的設計不是純工業性的，是帶有一定藝術性的。應該要允許主觀表達的存在。如果對每一個設計點都嚴格地進行量化評估，那麼得到的結果要麼就是策劃人員變成越來越不可理喻，要麼就是遊戲變成冷冰冰的程式。

猴與花果山 評論：

主策篇

故事裡的主策非常缺乏經驗和設計能力，從幾個點就能看出來：

首先是在專案內容的設計上，很多人非常天真的認為做遊戲就是要設計“對”的東西，可是既然要設計，就不會有“對”的東西，所以當你在一個團隊做專案的時候，設計的【絕對重要的基石之一】，就是團隊每個人心中的“痛點”，也就是說其實每個熱愛遊戲的人來做遊戲，他心中一定是對某一個細節帶有執念的（即使不熱愛，也可能對於收費點賺多少錢非常有執念），一個主策劃設計遊戲的時候，必須把每個核心成員心目中的期許包容進來，這才是完整的設計——就拿股市裡的例子來說，其實大世界+領土爭奪+莊園養成+競速元素，這些並不完全衝突，因為這些都只是一個概念（絕大多人的執著的痛點無非是概念級的），並不是不能組合在一起設計的，但是主策固執於自己的想法，認為這些就沒法融合，這其實就是太過堅定某個遊戲玩法神聖不可侵犯在先了，然後本能的就認為要融入其他的就毀壞了這種“對”的感覺。無論什麼原因都不要緊，要緊的是——記住，遊戲是為人設計的，至少，每個核心參與者都應該滿意這個遊戲，而滿意的基礎之一，是每個人心中的期許得以某種形象的實現（也就是說未必是直接的，也可以是間接的，比如領土爭奪本身就會有建造玩法，莊園養成也有，那麼莊園養成的建造快樂在哪兒？仔細想想，和領土爭奪的建造絕對不共通嗎？）。

主策的第二個能力缺陷是對於問題本質的分析能力和解決能力的欠缺。在故事裡有一段主策和主程的“意見矛盾”，就是主策固執的認為掉裝備是符合核心玩法的，而主程認為掉裝備懲罰太嚴重——說到這裡應該看出問題的所在了，根本就不是“不應該掉裝備或者不應該掉落什麼東西”，沒有那麼絕對，主程的意見其實是說“裝備在遊戲裡這麼重要你讓我掉落了我肯定受不了”，討論的核心不是玩家會不會退遊（這是他的話術——誇張），也不是裝備掉落不好——裝備在這裡只是一個代詞，本意是“如果這個東西這麼難以獲得，就不應該讓玩家輕易失去”，其實他說的問題直指了“框架”中的致命問題，不該營造一些“珍貴物”的損失，隨便舉個例子，比如wow裡面掛了裝備掉10%耐久，花錢修，有人嘴上會心疼，但是沒人真的心疼甚至退遊，因為錢來得快去得也快，沒什麼情感；但是如果某個遊戲裡，玩家養的寵物，伴隨自己1年遊戲時光，和自己一起戰鬥、一起冒險，哪怕他不是頂級的，掛了也很難受的，“資料是假的，情感是真的”。當然這裡討論的也不是這個設定好不好（損失有感情的事物本身就不是快樂的東西，是不值得分享的負能量），而是問題很明顯——主策不能辨別別人的提的意見的立意和本質，對於別人提的不同意見抱有很大的排斥，這不僅會和上面說的那樣設計不好，還會導致人與人之間的信任斷裂，最關鍵的是——問題也根本得不到重視和解決。

主策的第三個能力缺陷是缺乏對於遊戲的架構能力。這是國內現在95%以上的主策都有的缺陷，就是說在設計的時候，缺乏一種模組設計意識和抽象能力。故事裡的主策，我都不用知道細節，就能知道他為什麼改不好遊戲——道理很簡單，他所設計的“框架”其實是玩家級的，而不是到某個模組（玩法）關注哪些資料，具體流程怎樣，如何資料互動，不是這樣去架構的，所以當改的時候，從流程到資料都拿捏不準，再由資料獲取改變流程，然後改著改著也不重構（程式設計師士氣接近0不願意了），問題堆問題，然後只能妥協，妥協+問題=做不出來。這個現象我舉個例子，比如我們做回合制RPG，踩地雷後的戰鬥過程中才有buff，而策劃希望戰鬥開始前能先把這場戰鬥中怪物會造成的一些buff顯示出來，乍一看這需求沒什麼問題，if else寫起來也槓槓的，但是很顯然，策劃就沒理解，在非戰鬥模式下buff是個冗餘資料。

製作人篇

製作人在這個故事裡，最大的問題在於他沒有做製作人應該做的幾個職責：

第一職責是保持團隊的士氣高昂：這裡有幾個明細點，製作人都沒做好。

第一是團隊的思想溝通，或者用大多淌著口水的鬥雞眼的說法叫“畫餅”——在專案裡的每個人，對於專案的期許都可能是不同的，這是自然現象，沒有辦法改變的，也就是老人說的“人各有志”。製作人要針對每個人的喜好，時不時給每個人打打氣，比如說關注“玩家會不會喜歡”的，你得經常跟他說，這個我們之後這樣做，什麼樣什麼樣的玩家就會非常激動（是不是？我也沒吹牛，愛吃屎的人都有，何況是一個玩法，總有人喜歡的）。再者，就是和主策那個問題一樣，不能聆聽發現問題，併合理利用身份來權奪問題的解決方案，然後各個擊破，也就是挨個去說動每個人妥協（這是真的妥協，因為最終必定不是100%按照每個人想法來了）。

第二是保持團隊氣氛虎躍——當團隊存在意見不同的時候，氣氛一定是詭異的，並不是一定要讓大家的意見一致，這也是不可能的，但是可以經常轉移轉移話題，這時候大家一起玩一款遊戲之類的都會是很好的新話題。製作人應該在團隊氣氛詭異的時候，即時去調整團隊氣氛，並且在人開心的時候各個擊破，這跟哄20多歲想談戀愛的小姑娘是一樣的套路（一個製作人要是這點本事都沒還是拉倒吧，製作人的主能力是魅力而不是智力）。而且製作人應該讓團隊中存在一種信任——你有問題去找我，或者找誰誰說，最後都是有反饋的。這個舉個例子比如在靈娛的時候，我們團隊裡有2個點，一個是我，當然如果覺得我猴叔不好說話，就可以找製作人魯大師去吐槽，無理論什麼吐槽，我們都會去發現一些問題，有些甚至還會開會討論解決方案，讓每個人覺得自己都是被重視的，而不能沉默不語。而我跟魯大師則都是一看就很逗比的傢伙，不是那種充滿心計的陰險狡詐之徒，所以才有的溝通，而我們也都會主動出擊找不對勁的聊聊（其實我會叫魯大師去，因為魯大師有文化，聊起來讓人舒服）。

第三是對於專案的把控問題——其實有經驗的製作人，在專案進度上都有“陰陽賬”，這什麼意思呢？就是有一條線專門開發給人看的東西，比如傻了吧唧的老闆們，另一條線則是內部真正的開發線，兩條並行才是專案開發線。真的做遊戲的人都知道，遊戲有這麼一個開發階段，可能根本就拿不出“可以看的進度”，比如在搭我的buff機制的時候，可能1、2周就是框架，什麼看起來的進展都沒，但是2周確實都在做事，但你能不能跟老闆也這麼說？老闆不懂，老子花錢2周沒什麼新東西可還行？是不是，所以專門得有一條線負責UI、內容錄入（這裡就有技巧了，比如哪些可以先錄入，後期改動甚至做一個指令碼就能實現，而不用人工的），是專門看起來的，也就是故事裡說的“一步一個腳印”，而另一條線就是搭核心邏輯框架的，也就是故事裡說的“先框架再資料”。自己開發當然一定是先框架在資料，沒有那麼虛偽，但是人多了，總有人會擔心進度問題（即便不是老闆而是團隊裡的比如美術人員），所以“面子功夫”也得做足，其實這不算面子功夫，只是專案開發過程的巧妙安排而已。

第四是人事管理問題——製作人也應該有HRBP的職責在內的（HRBP往往是合夥人，也就是人事管理，和HR職責以及責任心是不同的，權力也更大些），也就是當發現團隊裡有些人無可救藥，比如說也說不好，對於專案不抱有認同感和自豪感，整天負能量的時候，應該及時裁撤（當然不一定是開除，這得看公司具體的人事安排，有些大的公司就是轉別的專案組了）。這不是一個能力的問題或者人際的問題，“千里之堤毀於蟻穴”。善於發現團隊內負能量源，並且及時消滅是製作人的主要工作之一。

這些工作，其實和專心寫程式碼都不衝突。

所以故事裡的專案，光目前來看，問題就在於人，從人出發產生了更多的問題，比如因為溝通不順，開始團隊裡產生了怪氣氛，到後來彼此失去信心，對遊戲也失去信心。

對於不確定因素的虛假自信

正如評論中東東所說，用蓋樓比喻做遊戲是不那麼恰當的，因為樓房需要從工程圖到施工計劃每一步都精確設計，完全完工直至交付。而做遊戲，特別是有探索性質的遊戲，是很難做到早期的“完全設計”的，再牛逼的策劃，也不可能在策劃案裡把每一個細節都考慮到，也不可能對每一個設定方案抱有百分百的確信——在上線後這些預想的方案能發揮期望的作用。

上面尖銳地指出製作人的問題在於專注細節缺少全域性考量。第三年，經過多次交流，製作人也大度地承認了指揮問題客觀存在。同時，製作人也把決策權全權交給了主策，給了主策一定時間去挽救專案。

主策自認為對於所做遊戲的認知非常深刻，主體框架已經思考很成熟，只要設計完全落實即可保證專案完成。但是在專案的後期，大家逐漸發現，主策的這種自信，是一種帶著盲目和掩飾的自信。

在第三年十月的時候，專案1.0決定關閉，大家都心有不甘，覺得付出多年的心血不應該落得如此下場。那時主策為了挽救專案，表示自己對專案有十足的信心，知道如何挽救才能走出困境，並且努力地向團隊和製作人傳遞這種信心和決心。那時大家都非常低落，主策的這種態度作為一道強力的腎上腺素注入團隊。大家決定跟隨主策再做最後一次努力。但是為了保證專案的續存，主策傳遞的信心和資訊存在過多的水分。其中主要的問題就有：為團隊建立了不切實際的預期。

在主策爭取專案繼續的時候，製作人心裡想的是再給兩三個月讓他改改看。而主策心裡明白，專案1.0已經從內容框架和程式框架上都改廢掉了，沒有挽救方法，只能推到重構。而如此龐大的專案重構至少需要六個月才能搭建完整體框架。但是六個月顯然不符合製作人的挽救心態。在那個時刻主策向製作人給出的計劃安排是：兩個月搭建完核心框架、四個月搭建完主體內容——然後回去就做了六個月開發計劃——試圖先斬後奏綁架時間週期。

這個行為導致的後果就是在第二個月和第四個月的進行階段驗收的時候，遊戲表現遠遠不如製作人預期。但是由於車輪已經滾起來，大家都被主策裹挾上車，只好硬著頭皮繼續做下去。

另一個維度的虛假自信是主策對團隊成員的不確定資訊掩飾。在這個專案中有許多設定是沒有先例參考的，在上線和玩家見面之前誰也不能確保方案的有效性。有些問題是主策也不確定的。比如說：我們設計了領地爭奪，但是由於動態平衡的需求考慮，我們沒有加入對領地爭奪的直接利益獎勵，期望通過讓玩家的團隊榮譽感驅動領地爭奪行為發生。這種核心玩法的驅動力是否足夠？主策並不確定。但是當被團隊質問起時主策給出的回答是：這樣的驅動力就足夠了。類似的對不確定性問題給出虛假確定回答的案例還有很多。事後覆盤時他自己也坦白到，是希望傳遞出確定的態度，因為不確定的開發內容容易引起工作牴觸。

但是當不確定的東西最終被識破時，引起不僅僅是工作牴觸，那會變成信任危機。在專案2.0的期間，主策就因為多次沒有坦誠地說明不確定設計，總是試圖塑造一種全知強硬人設，而逐漸失去了團隊的信任。

在專案2.0的第六個月階段性驗收時，主策對製作人那邊才真正地坦白專案開發的後續計劃和成本。出於對階段性細節表現的失望，對後續開發成本的憂慮，對團隊成員信心的丟失，最終我們只能再次做出了艱難而沉痛的決定。

回顧這段遊戲開發歷程，我確信這是一段極其特殊的經歷。立項之初，我們核心成員租了一棟別墅，在裡面吃住生活工作。別墅帶一個院子，本想著大家沒事兒在院子裡邊乘涼邊討論下方案，嗐，結果忙起來院子裡野草都長到人那麼高了，也沒用過幾次。製作人沒有給大家施加什麼工作壓力，希望保持團隊有充沛的精力和良好的生活狀態，以做好這份創意型工作。不設時間節點，也不走繁瑣的商業流程，大家儘可能地去發揮自己的才能，做出心目中的理想遊戲。這樣的開發心態，在浮躁的遊戲行業裡算得上是一股清流了。公司曾經有許多專案，但是目前僅靠最早的幾款吃老本撐著現金流。每次我們表示擔心公司的經營狀況的時候，老闆就會安撫大家不用考慮資金壓力。以做出一個能打動市場的作品為最高目標。

這是真正的遊戲人的心態。加入這樣的團隊我感覺非常幸運和幸福。

三年的遊戲開發經驗，只是專案沒有做成，很可惜。不過能積累下這些經驗也算是非常寶貴的。總結一下：

立項之初，以及開發過程中，核心成員一定要有統一的遊戲想象，並且對最終想象做好全面的推演，想清楚遊戲做出來是什麼樣，玩起來是什麼感覺。後面就是堅守這個立項根本，不再動搖。如果一開始就想不清楚，就不要妄想以後會突然開悟。

核心成員的設計理念和設計方法論最好要一致，這種基本思想的不同會導致合作的全方面立體性矛盾。如果理念談不到一起，就不要硬湊CP了，何必互相折騰呢。

在不同的階段做不同的工作，在該打磨細節的時候才打磨細節，不要放任全域性不管，一頭扎進細節的大坑裡。跳坑容易出坑難，出坑發現當初沒有解決的大問題，仍舊佇立在那裡。

不謀萬世者，不足謀一時；不謀全域性者，不足謀一域。把全域性的決策權，交給謀全域性者。謀全域性者，別天天寫程式碼，程式碼寫多了真的不想去思考巨集觀的感性的問題。

在大家狀態合適的時候開啟方案的討論，如果方案不如自己意願，可以直接表達，可以持保留意見，但不要習慣性用量化提問抬高對方的回答成本。設計者在丟擲方案前，應該自己主動評估利弊，做到心裡有數，有問有答，不要臨時信口開河。

決策者應該對團隊成員開誠佈公，允許不確定因素的存在，但不能允許不確定因素被掩蓋。應該提供正確的資訊，為團隊建立正確的期望。不要等到不切實際的預期被迫破滅時，團隊的信任瓦解，再無回天之力。

東東 評論：

其實製作人的方向是對的，符合標準的敏捷開發思路。

做遊戲不能跟蓋樓相提並論，蓋樓是瀑布式，因為樓必須完全蓋完後才能交付使用，所以整體流程必須從框架到細節。

而遊戲不同，前期開發如果已經包含核心玩法（即玩家遊玩過程中的積攢與基礎釋放閉環）那麼就應當儘早完成前期整體細節，然後小範圍測試，用測試資料來驗證後續的所謂“領地爭奪”是否需要做以及應當怎麼做。

很有可能小範圍測試後發現，目標玩家在此類遊戲中根本不在意有沒有領地爭奪，只想像我的世界一樣隨便蓋房子分享自己的成果，那麼第二階段開發重點肯定就不會領地爭奪上，而是更加細化建造於生存層面。

用瀑布的思路做遊戲本來就是錯的，前期設計太多太細，花了大精力做出來，結果發現玩家根本不買賬，那是一件非常痛苦的事情。

謝謝大家的客觀分析和評論。我想在文末補充一些資訊，我們團隊中每一位成員都是有能力製作獨立遊戲的從業者。尤其製作人是從2000年就進入遊戲行業的業界資深前輩，親自帶隊開發過許多大型專案，其中不乏商業成功的專案。文中對製作人角色進行了許多尖銳刻薄的指責，僅僅限於筆者的主觀視角，肯定存在片面和偏激的論斷。大家還請客觀看待。對於製作人大有冒犯，還請海涵。提筆之意不在於甩鍋，也不在於否定具體的人，而是對工作中經歷的事情做出反思。我相信不管是誰來當製作人或主策，都或多或少會存在一些問題。因為人本身，不可能是完美的，不可能不犯錯誤。我們團隊的一個良好氛圍就在於，大家總能夠直言不諱地指出問題，每個人也都能夠坦誠大方地領鍋。所以專案的成功是大家共同的成功，失敗是大家共同的失敗。每個人站在不同的視角，能夠總結出不同的經驗教訓，希望這些經驗，能對同行和我們今後的專案，有所借鑑之處。

文章部分結束~

摘選部分網友評論

網友1：

出於志趣相投而聚在一起做東西的人，很容易因為有人發現志趣其實不合/有人志趣發生了變化/有人熱情被工作消磨殆盡等等原因而散掉，這也是為什麼大專案很難有特色，有特色的都是小專案的原因。意見不容忽視的人一多，不是遊戲特色被磨平，就是有人熱情被磨光。

我尤其認為，一個自己想做出一個什麼東西來都沒有徹底發自內心地確定的人，是絕對不能去領導一個團隊的。連領導者的心都不定，其他所有東西都是空中樓閣。

網友2：

當“主程也要來聊一聊遊戲設計理念”的時候，這個專案十之八九要黃。

網友3：

真好的實戰總結，雖然帶有主觀性。

單從本篇文章提到的來分析：

1. 立項沒立好。

從過程來看，做了兩年遊戲方向都沒完全定下來，之後又大改？！這說明立項就沒立起來啊，哪怕立項立個一年半，有了一致的、完整的且閉合的、可實行的設計方案，再進行開發也不遲啊，這樣才能控制好成本且又降低了風險，效率也反而高了，因為方向很明確。

2.決策者不堅定。

幹遊戲開發這行的基本上都是遊戲愛好者，一個專案團隊裡的每個人當然都會有自己的想法和偏好，活躍且民主的氛圍也會讓團隊裡的成員更用心更積極的做好自己的工作。細節上的問題，大家互相商討，各出招數，這是非常好的現象。

但是在遊戲方向遊戲框架以及核心玩法這種立項之初就立起來的事上，就不能各抒己見了，決策者應該要有這種說一不二的定力。

而在文章中，我個人非常認同主策的思路，用週期性消耗來打破傳統MMO中的數值困境，如果考慮到玩家體驗，也有解決思路，那就是再配上一套迴圈閉合的遊戲內金融系統。

3.遊戲開發思路。

文中的製作人採取的是從頭做起的開發思路，這種思路其實不適合創新遊戲專案。

文中提到的專案核心玩法是領地爭奪，那就應該圍繞這個來進行擴散性開發。

先把領地爭奪做出來，之後可以選擇先測試打磨核心玩法，也可以直接進行養成系統開發。

因為別的系統其實都是為核心玩法而服務的，玩家進行任務關卡是為了得到獎勵來養成，養成角色是為了在核心玩法中取得快感，必須要明確這個邏輯才能分清主次，否則你的遊戲只會顯得雜亂。

網友4：

從本文作者的角度看，確實是製作人背鍋。不過水友們也不必急著下結論，這畢竟是作者的一面之詞，至少得讓製作人發聲，兩相比較，我們局外人才能稍微瞭解一些，才有可能得出稍微客觀一些的結論。

作者的每一條都有一定道理，但事實是否是這樣，還是要多聽聽多看看。兼聽則明偏聽則暗。沒有冒犯作者的意思，單純從理論上講，作者說的也有道理。

網友5：

挺好的經驗分享，贊一個

專案不一定都是成功的，失敗帶來的經驗也十分寶貴，日後會長期受益

高贊評論對敏捷開發理解還不到位

這種長週期且處於功能技術磨合期的專案，是不應該從細節做起的。快速出第一個版本（六個月也蠻長的，也許遊戲業就是這麼久？），開啟討論思路和定方向，接下來完善細節。

敏捷開發有個重要概念，MVP，minimum viable product，就是紙上空談不如先出個樣品，架子搭起來就在眼前，idea就隨之而來了，接下來就是週期迭代。每一期要出個可用，即可以玩的版本，所有人都會對產品有直觀概念了。哪怕觀念不合，在實物上，磨合調整也可以更快了。

而且團隊每個人都發表意見是很重要的，不能誰是金主誰就最大。

做專案的初心如果是打造產品，那就不能以“滿足金主”為前提

帶團隊的人要對這一點有平衡的能力，要不咋做team lead 呢

網友6：

程式大佬寫程式碼的同時兼製作人2333 以前也在這樣的公司做過幾年 嘗試了幾個專案。不專精不資深的程式製作人都有一些通病，全域性設計想不清楚，有一些感覺就要開始做。很早就陷入細節，要讓專案可以玩起來，並且好玩。遇到瓶頸想不清楚，優柔寡斷，各種改來改去，美其名曰好的專案都是改出來的，用戰術上的勤奮掩蓋戰略上的無助，一會是玩法，一會是美術，甚至劇情也要改。號召大家一起思考，做專案的主人翁。但有的人天生就是玩家，做不了設計者啊。其實很多事情，職業製作人，策劃，都未必能做的很好，更何況不專業的程式大佬。一把辛酸淚

網友7：

簡單看了前面2條。

第一，立項沒有考慮市場。

市場是什麼？有一定規模使用者，規模裡面願意有人給你買單，買單後願意再次復購，以上能讓你產生盈利。

沙盒+強競爭，聽起來很美好。

積累全掉落？強社交？動態平衡？

請問有多少人買單？

從18年開始，玩家就已經討厭強pvp了，看一看coklike被率土like打得面目全非就知道了。

製作人的思路才是讓你們能活下去的根本。但他一開始沒看清市場。而主策只知道自己設計，不考慮玩家。

第二，遊戲程式問題。

無論是一步一腳印，還是框架先優化後。

框架結構是立項時定好的。數值結構不會變。

除非增加了改變框架的東西，但這樣的情況一定會出現。前兩方法無論選擇哪個，都是需要重操遊戲的。

問題出在版本節點上，版本無休止的開發，必然會出現認知“我覺得需要修改。”有了基礎閉環後，儘快見玩家，才能知道什麼需要修改。

我們專案研發半年，只做了前3天體驗，直接一測。

網友8：

看到扣細節那段想起一句話。

當遊戲製作到了結尾的時候，遊戲好不好玩已經不太重要了，能不能玩才是最重要的。

總之也給我提了個醒，若一開始就沉迷細節，終究會陷入泥潭，必須注重全域性才行。

製作人還是要長點心，幹什麼事情，中途不斷改主意，或者一開始走錯方向都是可怕的事情。還是感謝分享經驗，以後可以給我提個醒 大家共勉。

網友9：

我曾寫過失敗專案的總結《又是一年好輪迴》，寫完初稿後是先發給了主策主程都看了一下，得到他們認可後才公開發布出來。這樣可以更客觀地進行總結而不是主觀色彩濃郁的吐槽文。我那篇文公開當天就被事業部總裁看到，然後他轉發給了主策，主策又跟我說總裁把我的文轉發給他的事兒……因為我提前都看過了所以大家也不覺得尷尬。可是你這篇文若被製作人看到，會不會很難受呢～稍微一點小提醒，對同事或者領導多一些理解包容，都是打工的誰都不容易。

網友10：

我感覺製作人未必是具體的遊戲經歷缺乏，而是被過去的經驗束縛了。

我知道的程式出生的製作人，很多是換皮時代成長起來的，他們講究的就是一個快，比如六個月就要體驗完整之類，而在普遍抄襲的情況下整體框架確實不被重視，野蠻生長的年代大家都是往上面堆東西，撈一筆就跑。

稍微長線一點，不那麼及時的，就會讓他們感覺失控，再加上設計策劃這類東西好像誰都能說上幾句，骨子裡是有點看不上策劃的。

網友11：

團隊意見產生分歧的時候應該由風險承擔者做決策。一旦下了決定，就不應該討論誰對誰錯。


閱讀原文：https://zhuanlan.zhihu.com/p/372336924