給獨立遊戲製作人的進階建議

之前我寫過一篇給新手獨立遊戲開發者的入門級建議，經過三年的開發，對於獨立遊戲製作這件事我有了一些新的理解和看法，所以是時候補充一篇進階級的建議了。如果你希望成為一個獨立遊戲製作人或者希望瞭解相關行業的部分知識，也許這篇文章會給你一些有用的幫助。

特別的，本文的內容更多的偏向於獨立遊戲製作人和小型團隊，並不適用於所有的情況，所以在閱讀時請注意保持個人的獨立思考，對所有內容應僅當參考。

一、發展方向篇

需要探索的第一個問題是獨遊發展方向的問題，本篇的核心主題其實只有一個，那就是獨遊和商業手遊的區別。

1.1 獨立遊戲和商業手遊的區別

這裡有一個很大的誤導在於，對商業手遊的解釋，畢竟獨立遊戲也是需要賺錢的，部分獨立遊戲的商業收益甚至是非常可觀的。所以它們之間最核心的區別並不在於營收能力，而是兩者在立項時的指導策略或驅動要素。

一般來說，獨立遊戲的是以玩法、內容、創意為驅動要素的產品，其主導的做法就是，遊戲怎麼好玩怎麼做。而商業手遊則一般以市場調查、使用者群規模、吸量、APRU值等資料分析為驅動要素，其主導做法就是，遊戲怎麼賺錢怎麼做。

特別要注意的是，商業手遊不以玩法為核心並不是在說這些手遊不注重玩法或者玩法要素不會成為衡量一個手遊品質的維度，而是它的重要性不足以左右產品的立項。這在一定程度上導致了產品在立項時依賴良好的市場驗證，而在缺乏足夠的市場資料導向時，很難有人願意投入太多資金進行玩法探索，這樣的策略偏保守，優勢在於可以透過現有資料對產品的結果進行相對準確的預測，劣勢在於會因為步調落後而無法搶佔市場先機。

1.2 社交價值公式

兩者驅動要素的不同導致了遊戲整體的製程和制度規範有較大的差異，尤其是其成本投入的偏重點，為了說明手遊的偏重點，我們先引入一個簡單的公式，我稱之為社交價值公式：


不同的產品總歸會為我們提供不同的價值，手遊相比於提供娛樂價值，其提供的社交價值更大一些，特別要注意的是，這裡的社交價值是一個狹義的社交價值，嚴格來說，它是一種炫耀價值，或者講的通俗一點，叫裝逼價值。

社交價值最核心的一個點在於構建社交信用，信用是一種關於認可人群規模的描述，舉個例子，如果你嘗試使用辛巴威幣在國內購買商品大機率是行不通的，因為這裡沒有人認可辛巴威幣，同樣的，一個遊戲裡的道具要產生社交的信用，前提條件是有很多人認可這個道具，說白了就是大家知道這個道具的價值，這就是社交信用。如果你玩了一款非常冷門的手遊，你在裡面抽到了一張SSR卡片（可以理解為一種稀有道具），你把抽到的卡片截圖發到群裡，你期望得到的是羨慕的眼神，但是由於該手遊太冷門了，大家都不屑一顧，這樣的手遊我們可以認為它的社交信用太低了。如果把一款遊戲的社交信用拉到極限，全球所有的人都認可這款作品裡的道具，那我們甚至可以用這款手遊裡的金幣作為交易貨幣，只是這種情況有可能只出現於《頭號玩家》這樣的科幻電影裡。

認可的、知道的、熟悉的人越多，說明這個圈子越大，說明這個物件的社交信用越高，這就是品牌溢價的來源，鋪天蓋地的廣告和營銷主要就是為了提高它的社交信用，類似於茅臺酒或者其他奢侈品，必須要營造出我買了它我就是最有面子的那個人的群體印象。

社交價值的第二點源自於稀有度，因為人都存在一種潛意識心理效應叫稀缺心理。但是和社交信用不同，稀缺性是可以人為營造的，比如奢侈品可以透過打造限量版的產品，手遊可以降低SSR的爆率來提高稀有性。

稀缺性的降低對產品的價值的影響不是線性的，舉個簡單的案例，在我還是初中生的時候，就看過一個新聞，在2009年《地下城 與勇士》最火的時候，一把魔劍·阿波菲斯甚至可以賣到10w人民幣的價格，但前提是整個伺服器只有一把， 如果整個伺服器有兩把，那麼每把的價格也許就會降到3w塊，如果有三把，那麼每把可能只值1w塊了。

這就是社交價值公式，社交價值與使用價值不同，附帶極高社交價值的物品的使用價值可能很低，比如再貴的表也只是用來看時間。光刻機和梅賽德斯賓士AMG-Project-One都很貴，但是兩者貴的點卻完全不同。社交價值可以穿越時空應用於所有存在社交概念的物種，從石器時代到現代，從動物到人類，同樣它也是大佬願意在手遊中充錢的核心理由。

1.3 對內容和營銷的理解

手遊的運營本質上就是在維持自身的社交信用，不過隨著時代的發展，各類手遊產品會越來越多，所產生的圈層也會不斷地增多，一方面是開發門檻降低，一方面是內容開始偏向於短平快，碎片化。所以一款現象級、全民級的手遊在未來出現的機率會越來越低，這也給提升手遊的社交信用帶來了更多的困難。

維持社交信用是一個抽象的概念，它可以等價的轉換為讓更多的人知道以及認可這款作品，一方面要提高現有使用者的粘性，不由於內容的迭代而產生太多的使用者流失，一方面要提高廣告對潛在客戶的精準投放。無論如何，這注定了手遊的大部分預算可能不是用在開發上的，其營銷成本與開發成本有可能是分庭抗禮甚至對於部分微信小遊戲來說營銷成本遠超開發成本。

正如有人問，手遊的品質重要嗎？這個問題其實是對手遊方向的總結，手遊的品質固然重要，但是它並不是一級屬性，而是一個次級屬性，也就是它是用來影響其他一級要素的，如果我們建構一張圖表，對手遊投入的開發成本與使用者群規模進行一個單一維度的研究，會發現手遊的品質對使用者群規模的影響是有限且不穩定的，因為一旦來到了內容領域，就會帶有很強的主觀性，其維度就會受到使用者群的制約，假設我們要做一款解密向手遊，那麼就得考慮，喜歡解密遊戲的圈子本來就不是很大，這個使用者群的規模上限就在那，即便是品質拉滿，宣發拉滿，所產生的提升也是十分有限的。但是手遊開發商仍然會選擇那些更加穩妥的選擇，比如加入更多的擦邊要素來吸引男性使用者，典型案例就是2022年的《NIKKE：勝利女神》在歐美市場的優異表現。

（當然，投入成本無法精確的錨定到手遊品質，一方面是各廠商的生產線和美術成本投入不同，一方面是部分手遊存在開發上的各類矛盾而導致工期的蔓延，所以兩者之間無法完全等價，只能作為一種投影引數）

不過這並不是說獨立遊戲不存在運營的概念，只是獨立遊戲更偏重於內容，所以獨遊的開發成本更多是用在內容的製作上的。

1.4 獨立遊戲的生存之道

手遊的生存靠的是對一款特定作品的運營，而獨遊靠的是工作室的產品矩陣，往往是系列作品自帶的流量。典型案例比如恐怖生存類《森林》成功之後，其開發商推出了作品的二代《森林之子》，而如果你是接觸了森林之子去了解這個系列作品，那麼你大機率也會去了解一下森林，正如其他的系列作品一樣，無論是小型獨遊還是大型的3A級作品。

所以本質上來說獨立遊戲運維的是自身的工作室或者作坊，靠的是作品IP，靠的是工作室的粉絲群對系列作品的熱愛。當然，將作品IP的粉絲群轉換為手遊的天然流量也是現代化手遊常用的做法之一，其實早點在2016年的時候就有騰訊出品的《MHOL》，這是一款相對較為成功的單機IP流量轉網遊的案例。

以上是第一篇的內容，當然我覺得個人對手遊的理解可能還比較淺層，對我的觀點，僅為一家之言，大家應該理性的分析和判斷。總的來說，當我們開始獨立遊戲的製作時，應該將重心放在內容領域上。部分以營銷為核心的獨立遊戲也很成功，但是這樣的成功帶有一絲投機主義，能積累下來的東西不多，成功難以覆盤，更難以復現。

二、內容製作篇

無論是手遊還是獨立遊戲，最核心的工作都是產品的具體研發，降低開發成本、提升開發效率一直是永恆的主題。所以本篇中，我會提到個人對於內容製作的部分理解。

2.1 製作人是否一定是多面手

製作人之所以是製作人，是因為他統籌整個作品的開發，也就是說，他要負責多項工作，或者與多個負責對應工作的人打交道。這裡就牽扯到關於製作人是不是一定是一個多面手，或者通俗的來說，他是不是必須是一個六邊形戰士。

2.1.1 策劃是否需要玩過很多同型別的作品

這個問題的答案其實和策劃是否需要玩過很多類似的作品一樣，我的答案很簡單，策劃需要玩很多的目標型別的遊戲作品。但和一般理解的點不同的在於，很多人以為策劃需要玩過很多作品的目的是在於尋求更多的可借鑑的方案，正如同寫文章需要有寬泛的閱讀履歷和人生履歷一樣。但是我認為，尋求可參考、可借鑑、甚至是可抄襲的案例是次要的，更主要的是提高溝通的效率，降低溝通成本。

我們無法以一己之力去對抗歷史，如果你從事創作行業，你大機率可以感受到這點，就是無論你進行怎樣的創作，你的作品的區域性或整體都可以在漫長的歷史的長河裡找到類似的作品，有的時候你甚至完全不瞭解過另外一款作品，兩者之間也斷不可能存在連線關係。但是這兩款作品卻可以產生碰撞，有類似甚至非常相似的設計在其中。任何設計目前都無法再算是新穎，遊戲設計逐漸從大體量的創新轉向了子系統的融合。比如《幻獸帕魯》，採用了《方舟生存進化》的玩法縫合寶可夢的皮，恰好又與國內的部分主流媒體文化連結，就產生了非常神奇的化學反應。

（題外話：任何設計目前都無法算是新穎需要劃分不同的層級來判斷，正如你把大逃殺型別的第一人稱或者第三射擊遊戲拿給零幾年的老玩家去看，拋開畫質的問題，他們大機率會說這個遊戲和CS很像，因為兩者都具有第一或第三人稱射擊要素，這個案例也可以很形象的證明，以前的創新是創作出一種新的遊戲型別，而現在的創新會變得越來越細節，越來越無法被非圈內的人所識別，正如對於老一輩的父母來說，他們可能也無法Get到街機遊戲和早期網遊的區別在哪，對於你的男朋友來說，口紅色號是一個難以辨別的東西，對你的女朋友來說，佐菲奧特曼和傑克奧特曼就是不太容易分得清楚）

簡而言之，策劃可以利用案例而非直接敘述的形式來表達自身對某項設計的理解或者描述。這就好像是一種引據經典，如同部分成語一般，簡短但是十分貼切。在策劃溝透過程中，如果一個策劃多款經典遊戲都沒有玩過，與之溝通的成功就會不斷地提升。當然，前提是我們將策劃錨定在一個系統和玩法設計層面的策劃，而非數值或者文案策劃等，這點我後面還會繼續強調。

瞭解了這個點，再回到關於製作人是否一定是多面手的課題下，我們大概也有了一定的認知，如果整個製作組只有製作人一個人，那麼他肯定得是一個多面手，而如果整個製作組有其他開發者，那麼製作人又需要在一定程度上了解其他領域的內容用以降低溝通成本，只是當開發組有其他人來負責具體的任務，製作人只需要統籌和部署開發任務時，對製作人在該領域的要求會下降很多。

以我個人淺薄的經驗來看，獨立遊戲鐵三角（程式、策劃、美術），製作人必須至少佔據兩個方面才能成為一個製作人，否則開發所產生的溝通成本會無限的變大以至於這種本來是隱性成本的東西卻可以在團隊建立之初就產生較大的障礙。

2.1.2 消除遊戲的短板

一般會說揚長避短，這是兩件事，揚長是發揮自身的長處，避短則是一個反義的概念，兩者往往的對等的，也就是除了揚長，還要避短。但是在遊戲開發中，避短的重要性要高於揚長。

簡單來說，遊戲有著比較嚴重的短板效應，但是遊戲對綜合技術力的要求又會因為遊戲品類的不同而產生差異，舉個簡單的例子，galgame型別的遊戲對立繪、劇情、音樂更加重要，好的作品肯定是三項都拉滿，稍微劣勢一點的作品應該也是某兩項做到高分，某一項是及格。但是如果三項裡有任何一項是不及格，那麼整款作品就會因為這個短板而被認為是渣作。

當然，針對獨立遊戲會談到這個點往往是因為很多獨遊沒有太過豐富的資源，錢不是問題，問題是沒錢。所以在進行專案選型時，你無法選擇一個包含了團隊嚴重短板的專案，比如某個專案需要高品質的逐幀動畫，而你的團隊裡並不具有相關人才，那這個作品就不應該在你的考慮範圍內。美術問題往往是獨立遊戲開發者最頭疼的問題，不僅是針對國內，即便是遊戲工業相對成熟的國外也是一樣的。所以採用各類方法來消除美術成本就是一個值得參考的事情。

什麼叫消除美術成本，或者什麼叫消除問題？消除問題和解決問題不一樣，舉個簡單的例子，假設某古人在旅行並途徑一個村莊裡，村民告訴你，前方的小路路徑很短、但是有一夥強盜會攔路搶劫。解決問題就是，你僱傭一組保鏢，為你保駕護航，去打擊這幫強盜或者只是避免被搶劫。消除問題就是，不要走這條路，換另一條路走，本質上強盜的問題沒有被解決，但是你不會再遇到這個問題了。

其實很多開發者都在嘗試用各種各樣的方法去減少美術成本，比如完全用文字來代替美術素材的表達。以下是典型的美術要求不高但相對比較成功的作品案例：如果你的技術力比較強，能夠獨立的完成比較龐大的工廠類模擬經營遊戲，可以瞭解一下《浮島物語》，而如果劇情和音樂能力很強，《UnderTale》也是一個值得參考的案例，如果你對程式動畫或插值動畫了解的比較多，可以看看SokPop出品的《StackLands》和《Yard》他們非常擅長使用非具象化的遊戲要素比如卡片，圖示等來製作遊戲，使用線性動畫來構建動態視覺要素。而如果你的特效能力很強，也可以看看8bit工作室出品的《BleakSword/荒絕之劍》這款作品的美術壓力相對較低，但是對特效的要求更高。同樣的作品還有《城市疊疊樂》《紀念碑谷》等


當然，這也是一個有趣的話題，即很多人覺得特效和美術素材是一樣的，都屬於美術的範疇，寬泛的來說的確如此，但是個人認為特效和畫面其實是一個偏向於技術美術的工作，也是更偏向於程式進行轉型的部分，畢竟技術轉技術美術相比於美術轉技術美術的難度要小很多，我的美術能力並不強，但是完全可以實現荒絕之劍中所有的特效需求，做出與之對等的畫面和風格。不過如果堅持認為TA是一個更加困難的職業，那麼也從選項中移除該項即可。

而如果只擅長一個固定的領域，就只能將這個領域的能力發揮到極致，亦或者開始去學習不同的領域，兩者所需的時間沒有本質上的差異，無非是廣度和深度的區別，這是獨遊製作人無法避免的一個問題。如果壓根沒有任何選項可以選擇，那麼不妨反思一下自己是否還需要經過一段時間的學習和歷練。

所以回顧上述的遊戲，會發現，這些遊戲沒有一個明顯的短板，沒有足夠的資金去外包美術或者招到對應的人才，就消除美術成本，利用其他方法維持遊戲的及格線，而不是強行保留一個生硬的短板。

2.2 分層處理問題的思想

分層處理的思想簡單來說就是將大的問題拆分為彼此關聯又互不干涉的結構，這有點類似於程式設計領域時常說到的元件程式設計，舉個簡單的案例，知乎上有一個熱門的問題是為什麼人類沒有進化出攻擊性的器官？這個問題其實問到了一個人類和其他動物比較大的區別，就是人類有一雙靈活的雙手，手和臂的組合讓人可以使用各種武技，讓人可以持握各類武器，讓人可以投擲重物，如果人類的手是專門為攻擊而設計的，那麼它大機率會被攻擊性這個元件限制住，因為生活所做的不全是需要我們去攻擊的行為。手可以讓人類的身體和各類武器進行解耦，形成兩個不同的元件。

所以分層處理問題的思想簡單來說就是，戰鬥時我不需要知道武器的原理是什麼，只提升自己使用武器的技巧即可，畢竟劍士有可能是不知道劍是怎麼煉製的，研究武器時也可以專注於威力和易用性，研究完了告訴別人怎麼用就完事了。這個簡單的思想其實非常好用，很多時候一個問題討論不清楚只是它捆綁了多個不同的問題，緊密的連線在一起。但是真正的矛盾在於很難找到一個合適的分割技巧將問題分割為所謂的彼此關聯但又互不干涉的多個部分。為此需要學習很多思維技巧。

2.2.1 內容和結構上的分層處理

假設要做一個簡單的走迷宮的遊戲，重點就是要設計一個巨大的迷宮，這就是一個龐雜的問題，嚴格來說它可以被抽象為一個線性遊戲，與解密類遊戲很相似，比如《黑羊》《煙火》《隱秘的角落》等作品，也與部分銀河惡魔城型別遊戲很相似比如《空洞騎士》《RustedMoss》等。

這些遊戲的設計絕不是透過設計一個巨大的迷宮然後讓玩家從頭走到尾來製作的。這樣的風險太大了，因為當其中的部分關卡進行調整時，前後關卡都會產生較大的矛盾從而必須要調整前後關卡，為此我們必須要將遊戲的設計分割為數個互不干涉的多個完整流程，比如分為多個章節，第一個章節的結局是固定的，無論玩家如何遊玩，它都會把玩家導向第一個章節的結局，這是線性遊戲的特點，也是將第一關的製作風險和改動成本控制在一個關卡的內部。也就是說，我們把一個巨大的迷宮分割為了幾個部分，有幾個關鍵性的節點，比如玩家一定是沿著A、B、C、D、E五個節點最終走到迷宮的終點，A和B之間是一個被分割的小迷宮，B和C之間也是，我們只要保證前一個迷宮的重點與下一個迷宮的起點彼此連線，就可以確保整個迷宮是連在一起的，這樣即便過程中我覺得BC迷宮做的很爛，不太行，要重構，也不會影響到AB迷宮和CD迷宮，哪怕我們覺得BC迷宮應當刪除也只是需要關聯AB迷宮和CD迷宮的終點和起點罷了，這就是線性遊戲的特點，也是為什麼我們一定會分章節和關卡去處理這些問題。

這就是內容和結構上的分層，關於線性遊戲的這一特點，下面的遊戲構型一節中會繼續探討。

2.2.2 系統和機制上的分層處理

系統和機制上的分層更偏重於前面所提到的解耦合的思想，嚴格來說這也是最能體現策劃也依賴程式知識的點，舉個簡單的案例，假設要設計的遊戲有科技樹系統。首先應該思考的是，科技樹完成的任務到底是什麼？是幫助我們解鎖科技嗎？從玩家的角度來說是的，但是從策劃和程式的角度來說，科技樹看起來更像是一個回收素材或者點數的系統。

在開發科技樹的過程中，它的系統邏輯應該是玩家滿足了某些點數條件之後，可以開啟對科技樹某個節點的開關，某個節點被點了之後，科技樹負責通知其他系統來幫助解鎖某些科技或者開啟什麼開關，具體會解鎖什麼科技樹是不清楚的，說白了科技樹只是一個用於回收點數的形式性系統，而如果我們真的把解鎖的行為耦合到科技樹，策劃在配置資料、程式在開發時都會遇到更多的麻煩，因為它同時解決了兩個問題，對接解鎖點數和具體解鎖的功能。

但是科技樹只能解鎖科技嗎？它為什麼不能是讓民兵的發展路線，它為什麼不能是建築的等級提升，功能追加，科技樹會解鎖什麼，達成什麼條件應該是一個獨立的系統，但是消耗素材、回收點數是科技樹固有的特點，這也是為什麼我們說，從策劃和程式的角度來看，科技樹更像是一個回收素材或者點數的系統。

在拆分系統的時候，我們需要對系統之間的連線關係有相對完善的判斷，科技樹是一個比較經典也比較簡單的的設計，但是真正的開發過程中，我們所遇到的問題可能更為複雜和繁複。

2.2.3 分層處理思想的總結

分層處理的思想是一個底層的思維邏輯，它可以是分化問題的思想，它可以是將大目標拆分為小目標從而引發目標梯度效應的學習技巧，它也可以是程式裡解耦合和元件程式設計的思想，它可能有不同的名稱，不同的叫法，但我認為是一個比較重要的思想，當然，不僅要有這個思想，更要明白如何分層，如何拆解，這是需要長時間的學習總結和體悟感受的。

2.3 理解成本慣性

慣性其實是一個物理性質，也就是牛頓第一定律所描述的：

任意具有質量的物體具有維持其運動狀態不發生改變的性質，稱之為慣性。

但是慣性在本文中的概念更為寬泛一些，它指代任意具有來拒去留性質的物件或者概念，小到個人的生活習慣，大到網際網路的生態。對於個人來說，習慣是很難養成又很難移除的，而網際網路生態同樣如此，比如有人一直疑問為什麼Python程式語言可以這麼流行，很簡單，Python簡單好學，吸引了很多人來學習和使用，既然有了很多使用者，就會有人為其構建更多的工具，有了更多的工具就會有更多人學習和使用，這就是生態的良性迴圈，久而久之，Python就形成了龐大且活躍的生態，這既難以形成，也難以消亡。

所以，慣性在本文中指代的是這些具有來拒去留性質的物件或概念，只是我個人更喜歡用慣性去描述此類性質，簡約又直觀，所以成本慣性描述的就是當我們已經制作了大量的美術素材、或者程式碼資源的時候，整個遊戲逐漸成型，就無法再輕易的變更現有風格，亦或者 大規模的修改玩法。否則部分程式碼系統就需要重構，部分美術素材就要重繪，這裡面產生的成本浪費是很大的。

這個點其實是一個顯而易見的問題，然而我們提到了這個點，更多的還是因為獨立遊戲確實經常需要好的創意或者遇到各類天馬行空的想法。但是在此之前我們應該對成本慣性有深刻的認知，並在開始推進美術計劃和程式計劃之前，將玩法徹徹底底的捋清楚，透過紙面玩法模型去推演玩法的可行性，即便要構建最簡單的demo，也應該儘量降低對美術的需求，使用白模或者色塊以代替各類遊戲中的元素。直到策劃團隊或者製作人對玩法毫無疑問時，才應當展開後續的美術和程式開發計劃。

一個典型的失敗者案例就是，如果一個新手製作人不清楚自己要做什麼，本身有很多想法但又覺得不夠完美，追求完美卻又沒有太多開發經驗，來回撥整目標，重構玩法，這個過程中成本慣性所產生打擊是毀滅性的，以目前遊戲人才市場價格來計算的話，投入百萬資金打水漂是常有的事。

當然這並不是說一旦開始了計劃就完全無法再回頭了，只是變化時肯定會有部分成本慣性的對沖，我們將其統稱為美術成本或者程式成本，但其中肯定不乏各類細節成本，只要成本在可控範圍內，變化和調整就是可接受的。所以成熟的製作人會在動手之前會經過非常徹底的思索和考量，去磨策劃案，透過紙面模型或者簡易的程式原型來進行測試，這個程式原型甚至可以是一個控制檯程式，只要可以表達玩法即可。不過此類概念更適合運用於以玩法為核心的遊戲，如果遊戲本身的玩法偏固定，只是題材和表層內容的切換，那麼我覺得甚至可以美術先行以免浪費開發週期。

2.4 提高自身的審美

審美在此處是一個廣義的概念，審美能力是對產品好壞的一種判斷能力，正如對一個廚師來說，味覺失靈是一種毀滅性的打擊。

2.4.1 洞察缺陷比如何最佳化更重要

在講這個節點之前，可以先引入一個經典的認知偏差效應，叫鄧寧·克魯格效應，該效應指的是當一個人的能力比較低時，他對自身實力反而會產生一種誤判，以為自己很強，從而變得傲慢，這也是我們通常所說的愚者山峰，這類人經常容易和別人爭吵，道德經中也有類似的描述：

知者不言，言者不知。——《道德經·第五十六章》

所以想要讓作品變得更好的前提就是，要了解作品是不好的，或者說，要承認自己的作品是不好的。然後才能進一步的改進它，如果不承認或者無法洞察到作品的缺陷在哪，最佳化就無從談起了。

所以如何深刻的瞭解作品問題在哪，本質上就是提高審美，而且是各方面的審美。尤其是作為製作人對作品玩法和體驗的審美。用打擊感來說，經常有人說打擊感不行，那麼能不能詳細的把打擊感不行這樣一個具體的外層表現轉換為具體的問題，轉換為本質的可以去最佳化的點？

於是就要分析不同的作品，多玩、多看、多體驗，比如希望學習快節奏戰鬥系統，可以偏重於研究《鬼泣》《真三國無雙》《討鬼傳》《噬神者》《哈迪斯》等，慢節奏的遊戲則可以研究《怪物獵人：世界》《只狼》等，如果沒有了解過這些遊戲，當打擊感出現問題的時候，也很難搞清楚到底是哪裡出了問題。

這也是為什麼說：洞察缺陷比如何最佳化更重要。

2.4.2 有時需要的不是答案，而是佐證

利用分層處理問題的思想，如果已經洞察到問題的缺陷，來到了一個次級問題，即如何最佳化時，就可以丟擲這個節點，即解決問題的方法比問題的答案更重要。簡單來說，如果要提升自身遊戲的打擊感，作為一個身經百戰的製作人，問題的答案几乎是脫口而出的。打擊感源自於五個點

• 擊中目標物件時的動畫及時反饋（敵人的動作變化）
• 擊中目標物件時的物理反饋（敵人的後退或者浮空等物理行為）
• 擊中目標物件時的特效變化（敵人的血跡粒子、閃白或屏震效果等）
• 擊中目標物件時的時間流速變化（角色的卡頓/時停等）
• 擊中目標物件時的音效反饋（金屬碰撞或者受傷的音效等）
  

如果嘗試透過某個影片來學習如何強化打擊感，大機率也會找到類似的分析和總結，但是問題就在於，不同的作品對其細節的要求是不一樣的，比如怪物獵人中，敵人是一個巨大的物件，它的物理反饋效果就不可能是後退之類的，於是物理效果的反饋就會是IK物理效果，也就是反向動力學。而如果敵人是一個和主角一樣大小的人形角色，那麼IK就不適用了。

如果要做的遊戲是類似於真三、暖雪或者武士刀零這樣的割草遊戲，傾向於快節奏，那麼像怪物獵人一樣砍中怪物之後刀的動畫播放速率變慢所產生的卡肉感就不應該出現，因為後者是目標作品希望表達武器的力量感而設計的。

所以應該自己分析一套對應的最佳化方案，嘗試用自己的方法進行最佳化，得到對應的結果，然後對該結果進行驗證。如果效果不好，則回頭繼續分析和提出方案進行最佳化，每次提出新的方案，綜合能力都會得到一定的提升和積累。而如果只是得到了一個答案，且不說這個答案能不能幫助最佳化作品，關鍵的是分析的過程本質上是需要積累足量的經驗從而應對後續的開發的。

更不要說這裡提到的只是最常見的一類問題：打擊感，而實際上游戲開發中所面臨的真正問題往往是找不到答案的，能直接搜到答案的問題往往也不是什麼大的問題。

這也是為什麼說：解決問題的方法比問題的答案更重要，或者有時需要的不是答案， 而是佐證。

2.5 對遊戲構型的理解

遊戲構型，一個相對較為抽象的概念，但是我們在該節關注的點比較簡單，就是遊戲的構型是否可被量化，也就是有沒有辦法把遊戲拆分為相對比較獨立的幾個結構同步進行開發。那麼這和之前提到的線性遊戲就產生了很大的關聯，一般來說，線性遊戲更容易被量化，被預估和統籌。

2.5.1 遊戲是否可被量化

用經典的跳臺遊戲《蔚藍》來舉例，蔚藍初代裡包含了三個章節，又分AB面形成六個大型的關卡，每個大型關卡又分為數十個小型的關卡，嚴格來說，並不需要六個大型關卡全部設計完成之後這個遊戲才可以體驗，而是做了一組關卡之後就可以開始測試了和遊玩了。

如同其他的線性遊戲，諸如解密類遊戲、ARPG、銀河惡魔城等都具有這樣的特點，即它們整體玩法體驗除了裝備和數值的提升帶來了節奏感的變化之外，整體體驗可以在最初的關卡里打磨和完善，擴充套件遊戲的時候也可以輕鬆的增加更多的關卡和流程，每個關卡的製作流程和管線是相對比較類似的。

不過雖然一直提到的都是線性遊戲，但是不代表其他非線性遊戲是不可量化的。比如賽車類遊戲並不屬於線性遊戲，但是它的關卡也可被量化。這些可以被量化的遊戲，它們的製作更加的偏重於某個關卡的研發和製作，核心的體驗打磨完畢，後續的擴充套件即便會遇到問題和矛盾，也相對來說比較容易解決。但是部分遊戲是不可量化的，比如我正在製作的模擬經營型別，這類遊戲的特點就是，它的短板效應非常嚴重，必須把所有的系統都製作出來，它的demo才足以成型，才能開始體驗效果到底好不好。

2.5.2 可表達玩法的最小原型

對於那些不可量化的遊戲，我們也試圖尋找一個最小的可體驗demo結構設計以提升策劃迭代的速度，但問題的關鍵是這樣的最小原型是如何設計的？

最小原型的設計指的就是，能夠完整的讓玩家體驗到遊戲核心玩法的最小demo，其他不必要的就不用去加，這也是一種奧卡姆剃刀原則，即如無必要，勿增實體，這種原型demo的設計技巧是可以練習的，可以找到一個現有的遊戲案例，然後對它的系統進行剪枝，也就是隻要移除該系統不會對核心玩法造成致命影響，或者可用其他現有代替的，都可以移除掉的。經過系統剪枝後所保留下來的原型，就是不可量化遊戲的可表達玩法的最小原型。

這種練習也可以幫助新手策劃理解如何編寫一份策劃案，如何設計一款遊戲，如何最快速的表達遊戲的核心玩法是什麼？我以前寫過一篇文章，即《模擬經營類遊戲玩法綜述》，在該文章中，為了描述模擬經營玩法迴圈的量變和質變升級，我提出了一個極微型的模型，叫葡萄樹模型。

在葡萄樹模型中，玩家會經營一片農場，系統提供了一個商店，商店中任何的道具都可以買入或者賣出，商店中的道具現在包含了葡萄樹和葡萄。葡萄樹每個100金幣，葡萄每個10金幣，玩家初始會有200金幣。玩家可以消耗1000個金幣來升級商店，商店升級後可以購買或者銷售兩種新的道具，即榨汁機和葡萄汁。榨汁機的價格為300金幣，葡萄汁的價格為50金幣。玩家可以消耗10000個金幣來升級商店，商店在升級之後可以提供兩種新的道具，釀酒桶和葡萄酒，價格分別為1000金幣和100金幣。

葡萄樹模型是一個非常微型的模擬經營類遊戲原型，它甚至比開羅遊戲更加微型，只滿足最基礎的遊戲迴圈，但是它足夠直觀而且可以立刻用一個Python指令碼來實現成為具體的可執行原型，甚至花不了一兩個小時的時間。

葡萄樹模型只是單純的在描述這個遊戲的結構是怎樣的，雖然部分地方有所簡潔比如沒說農場的地塊數量或者葡萄樹的生成公式或者計算模型等，但是大概我們可以知道它的運作邏輯。但是這樣一個模型是如何得到的？是經歷了怎樣的探索取得的？它也許是透過對別的遊戲進行系統剪枝得到的，亦或者對模擬經營類遊戲的本質進行抽象後總結出來的，它就是作為策劃或者作為製作人應該要去提煉和總結的內容，而在此之上又會增加怎樣的細節設計，生長出何種“枝丫”，則是根據題材或者契合度來進行判斷。

2.5.3 對遊戲構型的總結

無論是可量化的遊戲，還是在遊戲不可量化時構建最小的可表達玩法的原型，都是在嘗試以最小的代價或者成本去進行玩法的測試和打磨，在開啟真正的大規模美術和程式任務的推進時，這樣的測試可以有效的保證遊戲結構的穩定，這與前面說到的成本慣性是一個目標。

2.6 帶有戰略或階段目標的產品立項

先做出一些失敗的作品，個人認為是有意義的，大部分優秀的作品都經過漫長的迭代和技術的積累才能做出來，一款龐大的遊戲作品，它的開發團隊需要經歷多個階段專案的歷練。於是在團隊建立之初，將目標設為一個龐大的專案也許並不合適，將其拆分為幾個獨立且完整的專案更好。

舉個簡單的案例，B站UP主Gamker曾經做過一款遊戲叫《宅物空間》，這款作品並沒有太多的玩法，就是單純的給定一個方形的空間，玩家可以選用各種傢俱來佈置這個空間，透過截圖的方式來分享自己的房間設計，與其說是一款遊戲，更像是一款軟體。

不清楚Gamker做這款作品的初衷，但是從發展的視角來看，透過製作這款作品，必然會積累一定的經驗和技術。我們很難在一款作品裡成功或者做出多麼亮眼的成績，所以不妨將設立幾個戰略級的目標，比如要做一款作品，透過這款作品，我們要積累怎樣的技術、達到一個怎樣的階段目標，從而為下面的目標做準備。

這其實與為什麼要登月類似，研究登月的過程中所積累的各項技術和成就不是孤立的，它們可以被運用於各方各面比如核磁共振技術，而更早的導彈技術也可運用於航天，大疆無人機的航拍技術也可運用於軍事技術，軍事工業技術也可運用於民事工業生產，比如二戰時期虎P坦克的電驅系統研發者費迪南德·保時捷後開創了大眾車品牌保時捷。

如果要做一款多人線上對戰的槍戰競技遊戲比如CSOL的話，這個目標對於獨立團隊來說就未免太過於龐大了。相比之下，於是先製作一款FPS單機作品就顯得更為容易，也更適合作為一個更好的階段目標，透過製作這款單機作品去積累各類研發技術、團隊管理等方面的經驗是更好的，對於獨遊的開發來說更是如此，比如《星露穀物語》和《饑荒》最一開始都不支援聯機，星露穀物語在爆火之後也才在1.1版本中引入了官方的聯機系統，此前只有個人開發者為其做了聯機Mod，饑荒也是一樣，只是饑荒並沒有將聯機作為一個獨立的功能，而是作為了一個獨立的版本，叫饑荒聯機版。

也就是說，在維持團隊生存的前提下，應儘可能將一個大的目標分割為幾個戰略級目標從各個階段目標中吸取足夠的經驗和正向反饋。如果上來就完美主義，反覆修改也害怕失敗，害怕自己的作品被抨擊和評論，那麼永遠也無法生長出豐滿的羽翼和蓬勃的肌肉。只有掙扎著生存下去，才有更可能製作出優秀的作品。

三、工作制度篇

在內容推進的過程中，漫長的開發週期和鬆散的目標結構會使工作室的進度變得很慢，摸魚划水的問題也會很嚴重，思考和探討的流程也可能會變得很浪費時間，所以如何構建簡明扼要的制度體系是非常重要的。

3.1 獨遊工作室和大型遊戲公司的區別

我曾提出過一個簡單的問題，去大型遊戲公司工作，是否可以學到更多知識和技能？如果這件事不經思考的話，其實大家的答案都是會的，但是我習慣於把問題分拆的更仔細一些，因為這個問題有一個很簡單且直觀的反思，即如果個人沒有足夠多的知識和經驗，那為什麼能夠去到大型遊戲公司工作呢？

這裡就是問題的關鍵了，其實能不能學到東西，是一個可以進行推斷的思維訓練。大型公司的運作，依賴的不是個人的主觀能動性，而是制度。公司不會因為員工偷偷地摸了一天的魚而直接倒閉，但這是一個結果，即公司需要將個人對公司的影響力降到最低以維持自身的韌性和穩定性。不至於某個人離職就導致公司運轉不下去了。如果你是公司的老總，你打算如何提高公司的韌性呢？

深入思考這個問題，如果一個員工離職公司就運轉不下去了，其實代表著這個員工肩負著非常重要的職責或者承擔了很多核心工作，當然，員工離職導致公司運轉不下去這個案例過於誇張了，可以舉個更加正常的案例，一個員工離職，導致某個業務部門停擺了，或者某個業務部門的工作效率大大降低了還是有可能的。這都代表著工作部署上，這個人被部署了太多工作導致的。

所以，解決問題的方法很簡單，就是分割這個人承擔的職責，分割他的職責本質上也是在分割他的權力，正如明朝朱元璋採用三省六部的內閣制罷黜宰相一樣。舉個簡單的案例，在手遊或網遊公司，策劃部門往往是多個職位構成的，比如文案策劃、數值策劃、系統策劃等。分割的更細一方面是提升職業的專業程度，一方面也是在提高公司的韌性，如果整個公司只有一個策劃，那麼這個策劃離職了，從離職開始到設立新的招募需求再到面試、選拔、任務交接所產生的摩擦性時間成本是非常大的，關鍵是此時公司的策劃工作完全處於停擺狀態。

但是如果將策劃的工作分割的更細，如果文案策劃離職了，至少不影響其他策劃工作的展開，如果希望進一步提高韌性，還可以將文案策劃崗位的數量設為多人，只是這樣也提升的公司運營的成本。但總的來說，可以推斷的是，公司為了降低自身運轉的風險往往會將個人的職責分拆的很細，招募基礎崗位只是為了完成相對基礎的工作，很難進入到這個公司的高層，但是換而言之，如果是作為執行崗位，進入該公司就直接來到了管理層或者接近管理層，那這個所謂大型公司可能規模並不大。

所以去到大公司是可以學習很多東西的，但是可以學到的內容偏向於經驗性內容、例如管理模式、互動體系（檔案交換系統和版本控制等）、技術棧（比如黑神話悟空團隊採用MotionMarching構建3D角色的動畫系統）、生產管線（比如米哈遊公司在疫情期間、線上上工作的基礎上仍然保持高頻率更新，其工作管線體系必然十分優秀）等內容。所以個人感覺在公司可以開闊自身的眼界，但對個人專業方向的技能提升有限。

3.1.1 對制度的解釋

說明獨遊團隊和大型公司的區別，主要是建立起一個意識，即獨遊團隊靠的是個人的主觀能動性而非制度，也就是很多人做獨立遊戲偏向於我想要做獨立遊戲或者我喜歡做獨立遊戲而聚集在一起的，於是獨遊團隊無法建立起完善的制度體系，這是在探討工作制度時首先要有的基礎認知。而我們在此處所涉及的制度，更多的其實是一個關於內容製作的廣義概念，可以將其理解為一種粗糙的生產管線，一種大概的探討規範或者協定等。

舉個例子，現在團隊假設有幾個人，關於遊戲怎麼做，大家都有想法，於是可以建立起一個簡易的規劃機制：

• 在設計某系統之前，由所有人準備多份設計預案
• 開會進行預案的介紹和探討、所有設計案探討完畢後進行投票選擇
• 如果沒有投出一個既定的結果，就根據現有投票結果改進現有預案繼續投票
• 重複2-3步直到方案確定為止。
  

當然，實際情況其實更為複雜，採用投票機制其實是一種很不靠譜的表現，只是我個人最初的隊伍協議就是這麼設計的。這就是一種工作制度，或者一種所謂的協議或探討規範等。而前面談到的公司的制度，更多的是懲罰制度或者稽核制度比如早晚都要打卡，或者公司只招收工科專業的人等。以上，就是我想說明的一件事，即制度在本文中的含義。

3.1.2 加強團隊的韌性

理論上來說，將職務分割的比較細節一方面是可以降低風險，另外一方面也是減少由於人員變動造成的摩擦性成本，舉個簡單的案例，在一個三人的獨遊團隊，如果策劃離開了，再招一個新的策劃，那麼整個遊戲之前的所有內容都需要跟他詳細的講一遍，所以分割職務的另外一個好處就是前面說到的提高團隊韌性。

在一人兼職多項工作的情況下，一個人的離開會對隊伍產生很大的打擊，包括職務停擺、心理壓力、其他摩擦性時間成本等。所以提高團隊韌性地兩方面，一方面團隊要有完善的文件體系，一方面是儘量減少實習和兼職需求。

3.1.3 如何看待制度

制度本質上是一種對某些執行或者決策進行標準化地處理，而標準化可以幫助團隊反思制度或者結構問題。舉個簡單案例，為了每週都總結和反思一下游戲地製作進度，團隊應該建立一個週會制度，每週大家不僅要展示這周地工作進度，另外需額外發表一下個人對於當前製作進度地看法，也許最一開始部分人有部分看法想提出來，但是事實上大部分人都是多一事不如少一事，也就是他們傾向於不發表任何觀點，於是每週地這個週會的個人意見發表環節就慢慢變成了個人週報地彙報環節，因為大家都不再發表觀點了。

特別要注意的是，這個過程中，沒有任何人對制度提出疑問，也沒有人覺得制度不合理，但是這個原本是個人意見發表的週會環節自然而然地坍縮為了工作週報。沒有人刻意提到它，於是可以說，這個制度並不合理，以後可以改為：

每週所有人進行工作週報的彙報，並如果有任何額外的想法和意見都可以發表。

一般來說，某個強制執行的決策會幫助我們逐漸認識到原先設計的不合理的點並進而產生良好的改進，因為正如穿著不舒服的衣服始終會讓你意識到這個衣服是不是有些不合身。但是這個任務無法繼續把工作週報簡化，因為這裡留有了太多摸魚和划水的空間。這就是制度的另外一個優勢，即它本身其實是一個備忘機制，或者一種標準化機制，每當開始執行這樣一個環節時，就像是填寫一個既定的簡歷表格一樣，一定要寫姓名、民族、年齡等引數。設計這個簡歷表格的時候，它就形成了一種標準。

3.2 設立開發計劃和會議制度

製作遊戲是一個開發週期非常長的活動，我們很容易迷失在漫長的開發或者學習的道路上，尤其是沒有上級監管物件的時候，所以此時就需要先指定一個開發計劃，將開發計劃視為一種監察制度，當然，很多時候一款獨立遊戲畢竟是自己設立的開發專案，如果開發週期逾期了也沒有懲罰制度，但是如果製作人不能將其視為一種錯誤或者問題進而批判或者反思自身的話，那我認為這樣的製作人是非常失職的。

3.2.1 開發計劃

指定開發計劃往往分型別來進行處理，但是如何設立一個良好的開發計劃呢？還是分層處理問題的思想，即找到合適的點對現有問題進行分割，首先注意設立開發計劃並沒有一個嚴格的模板，因為目標到底是怎樣的遊戲我們是不清楚的。

但是無論什麼遊戲，總會分為開發階段和QA階段，所以是否可以將開發計劃分為開發階段和測試反饋打磨兩個階段？如果來到開發階段，那麼問題會變得更簡單一點，雖然不知道是什麼遊戲，但總的來說肯定會分為內容填充階段和Demo開發階段。如果來到Demo開發階段呢？即便不知道要做什麼遊戲，它也肯定肯定會分為預研階段和原型測試階段。如果繼續來到預研階段，它又可能分為立項調研階段和紙面原型測試階段。


當然，每個節點都會繼續的細化和分割，至於分割的多細，有沒有節點是不必要的，則根據具體的遊戲來選擇。這就是一種制定開發計劃的方法，即根據遊戲的階段找到一個合適的節點對目標進行二分。這是一種圍繞製作節點而設計的計劃展開辦法。當然也有不同的開發計劃設立辦法，比如根據開發週期來設立開發計劃，如果打算利用12個月的時間來構建一款作品，那麼可以將遊戲分割為6個版本代號，當然不一定是6個版本，具體分為多少個版本可以根據內容來計算。相比於圍繞目標展開的開發計劃，以開發週期為主的開發計劃以時間為核心驅動因素，如下圖所示：


當然還有更多的描述計劃的方法，而且很多時候這些計劃表的構型是相互混合的模式，比如內容填充計劃裡會以時間為主要因素，但是整體的開發計劃以目標為主。

3.2.2 建立溝通制度

一個抽象的行為比如對遊戲進行立項往往由於其過於抽象而無法被有效的探討，就好像馬上就要開始探討立項的問題，我們應該如何進行有效的溝通，說白了，溝透過程中太需要一個有效的溝通模板了。

舉個簡單的案例，假設某遊戲工作室是某個公司的子工作室，作為一個專案的負責人，需要週期性的彙報現有的開發進度，就應該設計一個完善的彙報模板，如果每月彙報一次，它就相當於屬於月會彙報。說白了就是透過一個簡單的會議說明這個月幹了什麼。


這就是一個模板，或者一個表格，而每個月或者每週需要填寫一份這樣的表格以展示最近的開發進度。但是母公司也許存在各類其他的工作室，對於上級物件來說，這樣的一份彙報是缺少上下文的，即為什麼會有這樣的一個開發計劃？所以相比於某月的開發計劃進度，它更像是某月在某個版本計劃下的進度展示：


而且大機率版本計劃不會即刻在1個月內完成，所以大機率還有部分內容是沒有完成的。


這樣就構成一個相對完善的月會彙報的會議模板，但是情況往往可能會更復雜一點，比如開發計劃中，部分人比如玩家甚至是領導認為0.x版本中某些計劃是不合理的（雖然這樣的不合理應該消除在開發計劃設立之前），從而導致了開發計劃的調整：


這樣也許完善了，也許還不完善，也許太複雜了需要簡化，也許我們壓根沒有彙報的需求，但是它構成了一個溝通制度，因為彙報或者對開發計劃進行總結這件事只是日常開發計劃中一個可能存在的一個需求，而這樣的一個模板，就是溝通模板，我個人喜歡將其稱之為會議制度或者溝通模板。針對不同的事件或者目標完全可以建立不同的溝通模板以簡化思考成本。

3.2.3 建立評估模板

評估或者評價，往往是針對滿足同一需求的兩個或多個選項而展開的，比如零幾年的時候，學校旁邊的諸多小賣部有很多小零食賣，而你手裡的錢可能不多，你需要對有限的資金購買什麼樣的零食進行評估，如果購買棒棒糖這樣的食品，一根就比較貴但是美味且足夠吃很長時間。但是如果購買類似於話梅這樣的食品，你可以把話梅分給其他小夥伴從而換取他們手中的小零食從而品嚐更多的滋味。

簡而言之，評估大體分為兩個方面，一方面是建立針對單個物件的維度畫像，一方面是針對多個物件進行評選。維度畫像是根據需求建立的，我們需要設計不同的評估維度來應對不同的問題，舉個簡單的案例，如果要實現遊戲中的某個系統玩法，大體的做法有兩種，兩種都可以，而且比較難抉擇，這個時候就產生了評估需求了，因為如果一種方案存在致命缺陷或者被另外的方案全線碾壓，那麼壓根就不會存在爭議。

針對一個系統的實現方案的評估，大體是針對它的兩個方向的維度展開的，一者所消耗的成本，一者是所產生的結果。成本側最基礎的就是美術成本和程式成本，當然還會有策劃成本但是一般來說程式和美術是核心要考慮的，結果側則有兩種型別，一種是所產生的優勢、一種是所產生的副作用，因為很多時候，很多系統設計方案是會附帶一定的副作用的，正如延遲渲染對透明渲染的支援較差一樣。於是我們設立四個維度：

• 美術成本
• 程式成本
• 額外優勢
• 新增劣勢
  

對於對於策劃組來說，每個人都可以根據現有的維度提案對目標方案進行個人視角的評估，滿分為10分，由策劃獨立打分。

• 美術成本（A方案：7.0）/（B方案：10.0）
• 程式成本（A方案：5.0）/（B方案：10.0）
• 額外優勢（A方案：10.0）/（B方案：1.0）
• 新增劣勢（A方案：10.0）/（B方案：10.0）
  

注意這裡的10分指的是這個維度表現較好，美術成本10分指的就是美術成本很低，收集評分可以建立其對維度的更準確的畫像，從而進行更好的分析。


其實在經歷較多議題的分析後，我們發現，本質上問題的維度都是在利用較少的成本換取更多的優勢，也就是在追求方案的價效比，所以大概可以得到以下的公式：


但是特別要注意的是，最後所計算得到的價效比引數只是一個參考值，因為真正的設計方案非常複雜，而將其量化為一個簡單的數字本質上就是一種對資訊的閹割。但是有了該參考引數，總的來說整體的評估還是會更加穩妥一些。

但是這個維度資訊也是簡化過的，因為在講到評估維度的時候，我們壓根不知道議題是什麼，如果我們追求的是對一個老舊系統的替換或最佳化方案，那麼就得到了一個新的維度，即最佳化程度，如果需要對成本進行更完善的描述也許我們會將成本拆分為開發成本、維護成本、外包成本等多項成本因素。於是我們會得到不同的評價公式：


但是無論如何，還是那句話，這個計算結果只是一個幫助你進行判斷的評估引數，它既不是最終的答案，也不值得過分的依賴。

3.2.4 建立評估流程

評估是一個比較複雜的行為，我們往往也會擔心評估物件的單一致使評估結果的失信，於是也許我們需要建立多輪評估形成完整的評估流程，比如你可以在設立方案之初進行自我評估，如果你的評估出現誤差，不妨再讓小組進行評估，如果組內也沒有好的意見，也可以交給其他更具權威的人士進行專家評估，比如交給主策或者其他更有經驗的策劃進行評估。如果仍然存在爭議，最後可以交給使用者進行評估。

但是特別要注意的是，如果走到了專家評估這個流程仍然存在疑點，那麼這件事本質上就說明了兩者的優勢和缺陷是比較難以抉擇，這個時候我們可以啟用簡易策略：


任何爭議較大的問題在短時間內無法甄別或者決斷的，可以直接選擇成本更低或更易完成的那個，這樣的決策策略稱之為簡易策略。

簡易策略是一個題外話，在日常的開發過程中是非常有效的一種解決問題的方案。當然，這是最後的決策手段，透過建立評估流程以評估的方式精確的找到方案之間的問題是最佳手段，因為往往兩個方案之間的區別有的時候很模糊或者難以描述的的，於是我們必須建立相對完善的評估維度來加以描述和完善的評估流程去強化評估的準確性。

3.3 建立工作排程模型

大型公司為了簡化管理結構，一般會將一個大型公司劃分為多個部門，由部門負責人來統一負責一個方面的工作，但是對於由一個製作人來統籌所有開發工作的獨遊工作室來說，過分扁平化是一個常態，也是一個巨大的問題，製作人的壓力會比較大一些。在部署任務的時候，我們其實遇到過一種特殊的任務部署的阻塞問題，這種阻塞問題是由於部分工作由於存在其前置任務沒有完成而無法展開的情況。將其稱之為阻塞很形象，因為編寫程式的時候就存在著非常多的同步程式碼結構導致的阻塞問題。

什麼叫同步結構呢？就是嚴格按照順序執行，如果B完成他的任務依賴A的任務先完成，那麼B就會等待A的任務，直到A的任務完成為止，B都處於阻塞狀態，也就是空閒狀態，這樣的情況或者問題就是同步阻塞。


現實中更為複雜的點在於，B往往不知道自己要幹嘛，也不知道自己有哪些其他的任務要處理，B被A阻塞只是你在思考任務部署過程中的一種假想，你需要將B的其他工作放到前面來讓他完成，於是你需要安排一張錯位的工作計劃表，設計這樣一張表，我會將其立即為一種工作排程模式的設計。

阻塞問題不僅出現於這種依賴問題中，其實很多組織結構中都會存在各種各樣的阻塞問題，比如拍電影的時候就不會一個片段一個片段的順序拍，我完全沒有拍過電影，也沒有學過任何相關理論，但是如果我是導演的話，最能直觀的感受到的就是拍攝成本問題，於是我會將拍攝成本作為最優先考慮的點來進行拍攝任務的制定。

假設我們的電影要在三個場景A、B、C中拍攝， A在大型城市，B在鄉村，C在某景點。那麼為了運載所有劇組人員和食宿所產生的成本就很大，於是我們不得不將拍攝計劃圍繞在三個場景中展開，整個電影的所有分鏡指令碼製作完畢，就從中篩選出在三個場景中拍攝的指令碼，然後去到不同的場景中進行拍攝，也許電影的開頭和結尾都在A場景，但是過程中在B，區域性在C，那麼也許我們是先拍完了電影的開頭和結尾然後帶著所有劇組人員去到B中進行剩餘部分的拍攝，最後將所有的片段剪輯為一部完整的電影。

這個過程中也會產生額外的成本，比如造型成本，如果一個角色的造型非常複雜，那麼化完妝就應該優先拍攝與之相關的片段，於是拍攝計劃會逐漸形成一個樹形結構，再扁平化為日程表方便排期。當然現實可能會更復雜一點，因為某些電影會啟用某些明星而產生更多的演員成本，但是無論如何，圍繞的永遠都是那些成本最高的部分。

和拍攝電影類似，製作遊戲也有相關的編排邏輯，雖然遊戲製作過程中不存在和電影完全類似的結構，但是透過編排任務解決同步阻塞的問題的起因是完全一致的，稱他為同步阻塞問題是因為我第一次認識到阻塞問題是在程式碼中，所以說不定真的可以透過程式的手段來解決它，為此我們可以引入一種叫生產者&消費者模型的結構。

生產者&消費者模型建立的核心是引入一箇中間佇列，這個佇列是一個等待處理的任務佇列，所有的對應工作者（此處可以將其稱為消費者）從佇列中取出任務來完成，而策劃則負責向其中加入新的任務（此處可以將策劃稱為生產者），這樣構建一個錯位的工作序列。


圖中的場景美術工作池就是一個工作計劃佇列，這個工作池的深淺也會影響到策劃的工作排期，策劃在部署計劃時應當考慮各個部門工作池的深淺以免產生其餘工作單位的工作阻塞問題，這就是生產者&消費者模型

當然，這個工作排程模型只是一個非常簡單的示例，而且現實中並不一定會採用這樣的工作模型，關鍵是我們應該嘗試學會自己設計排程模型去完成各類繁複的組織性工作計劃。這就是本節的核心啟發，即設計工作排程模型。

總結

以上三篇內容就是所有我想說的部分了，當然還有很多課題和想法由於各類原因沒有寫入這篇文章。

怎麼說呢，成為一個製作人是一條相當艱苦的道路，和產品經理不同，製作人除了統籌開發計劃之外，可能還得親自上陣幹活，這個過程中很多事情都需要自己來決斷和決策，以上每個細節點都是一個曾經踩過的坑，沒有資金、缺乏完善的懲罰制度是一切問題的核心矛盾。所以獨遊製作人需要在有限的資源中做出更好的作品，就需要關注一切成本問題，從而為團隊保留足夠的實力以應對不期的結果。

希望以上內容對你有一定的價值，感謝閱讀，同時再次感謝@ComfyFinn提供的封面圖。


原文：https://zhuanlan.zhihu.com/p/690749704