对开发中的游戏项目感到失控怎么办？

针对题主的一个问题更新一下：

新写了一个刷怪的，虽然这个刷怪机制也用了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多么好，但是如果你们没有技术栈，请不要冒险 。

如果你有更细节的问题想要我说说，可以跟帖，也可以私信给我，我有空的时候会回答。 虽然我剩下的存款可能都到不了你的年终奖这么多，而且目前也没有收入，但是请【不要用付费咨询】来羞辱我，知识是无价的，你要的我有的我乐意分享，这也是老一代游戏人欠新一代游戏人的 。