對開發中的遊戲計畫感到失控怎麽辦？

針對題主的一個問題更新一下：

新寫了一個刷怪的，雖然這個刷怪機制也用了6年多了，但是一直也沒有寫過啥，因為大家都覺得這本身就是個小問題。但是如果你仔細想想，其實這個問題真的不小：

原文：

我以一個朋友聊天而非軟文的方式寫這個，可能不太好看，但是相信你耐心看下去，是會多少有點收獲的：

沒想到今天如此浮躁的遊戲行業，還有人問出了我的專業領域的問題來了。短短17年的遊戲行業工作的實戰經驗中，我自己經歷的、朋友經歷的、朋友的朋友經歷的、朋友的朋友的朋友經歷的、……經歷的加起來上百個計畫，都會遇到這樣的困惑——計畫開發到了中期開始，出現了嚴重的失控感，不僅程式設計師會有，策劃也會有，嚴重的美術也能感覺到。我個人針對這樣的問題研究了10年左右，並在實際計畫的開發中逐漸抹平了這樣的問題。

其實題主提到的這5個感覺非常有代表性，可以分析為以下幾個問題在作怪：

問題1：缺乏必要的軟體工程知識——沒有把重構當做工作內容

很多遊戲團隊的制作人只是憑資格老就上位了，其實實力根本就到不了制作人的水平。在這樣的制作人規劃計畫進度的時候，典型的一個問題就是——他根本沒有想過程式碼是要重構的。甚至他的理解是計畫每一個階段就是有一個肉眼可見的進度。但事實上，從開發角度出發，在一個遊戲裏，不僅程式碼需要重構，連設計也是需要重構的。每一定時間我們需要重構一次程式碼，同時當遇到了困難，即程式團隊有人提出一個感覺——這麽寫下去似乎不太理想（樓主現在的感覺得弱化或者說早期版本），這個時候我們就需要停下腳步，來重構一下程式碼；而策劃設計也是如此，當發現一個玩法存在與其他玩法的矛盾或者耦合，或者沒有足夠知識經驗的策劃感覺到哪兒不對勁的時候，是應該停下來重新思考，用紙模擬玩法，看看是否應該重構一下玩法的。而單從程式角度出發，看題主提到了繼承，所以我想說——oop是最需要重構的，沒有之一，這也是當年我們使用了ECS的原因（被人說了4年傻逼，直到守望先鋒拍了這些猴子們的耳光）。

既然計畫進展到這個時候了，重構已經是勢在必行的，應該騰出至少2周的工作周期來，不僅程式碼，連玩法也要一起重構，不然繼續下去只可能是最終崩盤，計畫可能上了線沒幾天就玩完。

所以第一個要點是：放棄沈沒成本，不要因為已經有的為即將到來的埋榴。該重構的即可開始重構，可以花一周左右的時間去重新整理需求和實作思路，也包括策劃們，可以花一周時間整理一下設計，把混亂的玩法和系統需求梳理一遍。

重構包含了一個很重要的Key：如果有了明確的需求和實作思路，哪怕從0開始寫，也叫重構；只有在完全沒有明確實際需求和實作思路的情況下，從0開始寫才叫重寫。這是軟體工程定義的，所以不要擔心你心裏理解的「重寫」，那其實就是一種重構，只是到了現在的地步，程式碼量很大。

曾經我在起凡工作的時候，我們做一個Moba遊戲，當我看到了一個傷害流程，數萬行程式碼的時候，我花了一段時間思考總結，設計了一套自稱為「buff機制」的東西（因為核心在於遊戲中的buff，所以這麽起名了，後來很多朋友給了更多好的名字），大體思路如此：

這個設計解決了遊戲行業一個歷史性難題——如何設計好可延伸的技能體系。並且這個思路至今已經9歲了，經歷了近百個計畫的實戰，被完善了很多很多。而原本幾萬行（甚至隨著新英雄設計逐漸有潛力突破10W行）的傷害流程（一個函式）被縮減到了10幾行，甚至之後都沒必要去改動他，這個思路大概是這樣的：

在這貼裏我大概描述了一下這個傷害流程。事實上我們可以看到，在需求和設計思路完善之後，原本幾十萬行的程式碼可以做一個有效的整理，很多細節可以進行重新編寫，這僅僅只是花點時間的事情而已，而且這花的時間遠比想象的少，通常思考1周左右，然後動手1-2天就能完成幾十萬行程式碼的重構。

這個其實涉及到了問題1、2、3。

問題2：策劃的設計水平，僅僅停留在提需求的程度。

因為策劃的設計水平，僅僅只停留在提需求，所以你經常會收到感覺很矛盾、不清晰的需求，甚至在後期會收到一些似曾相識、卻又感覺似是而非的需求，在實作的時候不知所措，即使是重構，你也不見得能拿捏好是否該整合。

在設計中，不僅程式設計師要設計單環依賴圖（DAG），就連策劃的玩法設計中也是少不了這一步的，如果邏輯中沒有設計好單向依賴關系，那麽開發的時候出現耦合在所難免。關於程式的如何設計，其實大家都讀過書，都懂，但是對於策劃，尤其是對於遊戲的歸納設計，是非常重要的一門學問，這個問題在題主之前就有人提過，不妨看看

這就是一個典型的策劃提需求，卻沒有進行歸納的案例，也是遊戲行業常見的「交給程式哥哥」，但最後大家都沒做好的情況。

程式設計師和策劃一起對現有的玩法進行設計和歸納，這是至少得，不要覺得職位限定了你的工作內容，這種思想在遊戲開發這種「特種兵工作」中是萬萬要不得的，一個合格的遊戲人，應該是在有遊戲設計思路的基礎上掌握程式或者美術中至少一門（日本遊戲人也是這麽要求的，早年國內遊戲人大多也是如此）。

精細到一些題主的問題：

1， lua的使用 ：明確lua就是寫邏輯用的，事實上填寫數據也不錯（本來Lua就都是metatable），看你們自己定義，但是一定只有一個用法。而且決定了寫邏輯，就不好怕「寫得不好」，因為誰來寫不是問題的關鍵。很多團隊會擔心指令碼導致執行效能低下，但事實上一個遊戲計畫因為指令碼導致效能低下，那這個開發團隊的水平得低下到什麽程度？就好比當年做諾基亞手遊因為存盤檔導致遊戲超過49k限制一樣的差勁了。

2， id與耦合性問題 ：這是一個開發中實實在在存在，但是卻有被人不認為是問題的問題。因為程式設計師總認為——這個只要策劃克服一下就能解決，策劃也總是認為自己能克服。所以開始設計的時候，都覺得一個系統的數據暴露出id來依賴其他系統就好了，但是實戰中，越是大的計畫，到後期越是會管理不暇。於是我花了一點時間思考了這個問題，設計了一個采用Tag的方式，至今已經7年經歷上百計畫實戰了：

原帖是任務設計，因為任務設計中最常見到這種與其他物件的關聯問題，比如道具和怪物等等等等。至於刷怪的問題，也是開始的時候策劃就沒有抽象好需求，不妨試著和策劃一起去設計。

3， ai指令碼依賴性問題 ：這個和設計思路非常相關，需要進行一輪重新思考，我見過的大多遊戲策劃和程式設計師在開始抽象這個的時候，所站的角度是上帝視角來控制一個怪物。但是好的ai思路一定是「我就是這個怪，假如我是這個怪，我會做什麽」這樣就會很容易把問題分離開。而必須依賴其他物件的數據的時候，也只能允許依賴Tag而非id。

問題三：新功能怎麽辦？

很多時候我們保持沈沒成本的習慣，讓我們放棄思考很多功能的共性以及功能的可延伸性，這就導致了每一個新功能都是一個「新的小遊戲」。實際上在我看來，任何一個新功能的麻煩僅僅只是UI而已，對於程式設計師來說，邏輯上根本不是問題。UI就是花一點時間，把積累的套路搬出來用的事情，但是如果你不曾積累，就會比較麻煩。

1， UI\UE的積累 ：你如果不曾積累，不妨去github找找，如果也沒有好的合適的，不妨在這個計畫重構過程中提煉一下，至少針對這個計畫，他應該是100%合適的，也不見得是壞事兒。

2， 歸納遊戲策劃設計的玩法，是可以提煉出「套路的」 。相信我，至少99%的國遊系統策，能想出來的玩法都是一套程式碼就能玩轉的，我曾經用ECS做過這麽一個模組，後來竟然成了核心：

遊戲開發不是做煎餅果子，不是你埋頭不停地做下一個，哪怕這個做的不好也就丟一邊繼續做下一個，就能提高生產效率的。 適當的時候可以停下來重構一下程式碼，但是註意要在能力範圍內，雖然我跟你鼓吹了ECS多麽好，但是如果你們沒有技術棧，請不要冒險 。

如果你有更細節的問題想要我說說，可以跟帖，也可以私信給我，我有空的時候會回答。 雖然我剩下的存款可能都到不了你的年終獎這麽多，而且目前也沒有收入，但是請【不要用付費咨詢】來羞辱我，知識是無價的，你要的我有的我樂意分享，這也是老一代遊戲人欠新一代遊戲人的 。