為啥遊戲的版本迭代，都是作死？

1.想好了再做，還是做好了再迭代？


想法總是那麼單純可愛，特別是在手遊行業，什麼是迭代？

但凡參加某些成功專案的分享會，總會聽到核心戰鬥改了5次，玩法迴圈改了8次，UI當然也是改了10多次，經過5次測試，上線次留過80%，月留20%，流水過億。

當一件事不確定的時候就需要不停的去試錯，試錯是對“不確定性”的資料化，產品化的過程，我們拿不準，不知道，才會去做測試，做迭代，但凡涉及到核心戰鬥的迭代，已經屬於傷筋動骨的範疇，屬於是大手術，心臟搭橋。

經歷過5次整容的產品總算成功，取得了市場極大認可，那麼我試著問了另外一個問題

“你們研發團隊有多少個人呢？”“我們研發團隊，包括美術外包的人合起來200人左右吧”

很好，版本迭代實實在在的涉及到工作量，也是人數的問題，我相信，200人做的版本迭代內容，絕不是20多個人能夠完成的，這還不包括對專案總體的把控能力，人家是用一個公司的人做一款專案的迭代，而你話只聽了一半，準備用20個人對同樣級別的專案，同樣的工作量，死扛？這難道不是屬於痴人說夢麼?

2.百發百中，指哪打哪


製作人更多職責傾向於各個環節之間的資源調配，確保遊戲製作環節資源充沛並對遊戲最終正常上線做好充分的資源準備

之前在國內某知名外包公司面試助理製作人的時候，面試官說他們Producer能做到把下個月的需求開發進度，精確的控制在以小時的單位。

（四次面試均通過，但最後由於專案擱淺，崗位被取消）

非常震撼，入行這幾年版本需求的規劃不是隨時都在變的麼？怎麼可能精確到以小時為單位呢？

以至於從細枝末節之間，便能感受到中外遊戲研發管理上的巨大區別。

現在我們回到迭代這個問題上，策劃出案子，程式一次性搞定，之後再也不用修改迭代。

那幾乎是不可能完成的任務，大佬們總是認為“想好再做，免得返工”是不是看起來無法反駁？

問題的焦點在時間維度上，世界上唯一可以確定不變的事情就是，“變化”

3.迭代迭代，疊著疊著就Go die

我看來，如果核心玩法，核心戰鬥，甚至UI出現嚴重問題，需要反覆迭代，那麼就是製作管理上出現了嚴重問題，如果按照國外研發公司的標準模板來說，就是主策的重大失誤，

當然國內的公司通常和主策關係不太強，上有公司的老闆，只需要一句話

“次留必須過60%”主策就得按照這個KPI去把他分了，這時已經不存在什麼遊戲性了，首先得完成任務啊！

“這個玩法加兩個內容，就和哪個XXOO一樣，已經是驗證過的，我們搬過來就可以直接用，不要想那麼多”

“UE的反饋特效太弱了，這是升級呢！必須讓玩家感到自己很牛逼啊，特效要覆蓋全屏啊”

挺好，這就是從需求變成了迭代，迭代變成了Go die

4.迭代沒啥卵用，那可未必。

首先我中心觀點，為迭代而迭代，那必定狗代，為什麼呢？

短期類，你這幫研發的人，製作人，策劃，程式，美術水平並不會得到極大的提高，做的人一樣，沒有結構性改變的前提下，還能把湯圓做成小籠包麼？

顯然是不可能的，凡是都有個方法，不可能無中生有啊，

如果能考慮到時間維度，以及方法維度，那麼迭代的思路就對了一半

我們花多長的時間，要達到什麼目標？從準備迭代伊始就需要有明確的里程碑，人員安排，自然而然的在製作過程當中，就會出現方法。

我相信方法總會比問題多，解決問題才是專案迭代的核心。

而為了迭代而去迭代，那麼真的是得不償失

另外一半是什麼，“止損點”，在金融行業中經常被提到到一個詞，

虧到什麼時候，我收手，避免收益雪崩，對一款遊戲來說，我再三強調，就是時間，如果想20個人去拼200人，那麼在什麼時間點，做什麼事情就非常非常重要，

我拿UI的迭代舉個例子，如果你看人家做了8個版本的UI，那麼我們也做8個版本，那隻會被美術爸爸噴SB，正確的姿勢是

我們最多做3個版本，最次從這三個版本中選一作為CBT的測試UI

為什麼？因為UI的工作量佔到總體工作量的15%，需要在1個月內搞定，超過這個時間範圍，超過這個工作量，勢必擠壓日後的美術需求，得不償失。

您看這樣理解容易多了吧。

作者：陳廷澤
專欄地址：https://zhuanlan.zhihu.com/p/87547389