终于小松一口气，上来冒个泡

去年五月份开始，开展了一个对已在研项目的流程和架构改进方面的工作。

小生所在的单位是一个拥有“辉煌历史”、并且在今天仍然有着看起来不错业绩的单位。但是这样的单位，可能也正如微软一样，特别是在“中式管理”无处不在的中国，容易陷入一系列的怪圈。从技术上来说，容易死抱着过去的一系列意识和方法不放，言必称某英雄项目，且风险较大的尝试一般不愿意去做，不敢去做。混合以大公司通病的效率低下，导致人们也不愿意、也不敢去尝试新的东西。

流程整理的推进遇到了不小的阻力，再加上是本项目是在另一项目的某版本基础上进行的重构，而不是一开始就去设计的结构，因此对困难估计不足的我很快就亚历山大了。

这中间倒不完全是公司的原因，也有自己的问题，一开始对整个结构没有捋清楚就贸然进攻，导致冲了一半遇到版本和工作量的双重压力，只得放弃，这一年的改进中，代码的废弃量之高回想一下自己都感到很惊悚。在一个没有反射系统的系统上去开发工具化、流程化，可想而知是个什么结果。

好在头儿是一直顶住压力表示支持的。

于是去年中的时候发力把反射系统给收了，接下来就越来越顺利了。到目前为止，技能系统的主要流程逻辑部分已经完全可以交由策划通过连图来实现。

过程中产生的一些想法，之前也大概都写过，再重新整理一遍吧：

我们有许多制作流程的方式，最土鳖的方法是程序根据策划的需要不断开开心心地硬编码啊硬编码，我想时至今日除非毕业生否则不会有人再喜欢这么做了吧？稍微好一点的就是设计一个可以读取配置文件的系统，策划通过配置文件来自定义一些流程。这个是某英雄项目的做法，也是我过来后重点在推倒的东西。再往后，就是程序只写核心、只搭框架，要什么菜？自己通过脚本和工具往里面装。如果你在业内做过10年以上，你应该会回想起来这就是我们开发模式一直以来的变化。

如果不能把策划调动起来，在这个游戏内容爆炸、游戏革新速度加快的时代，迟早会被淘汰。

配表为什么不靠谱？

为什么反感配表、配配置文件呢？这个方法一是太老旧了，二是它实际上并未能完成调动策划的使命。

老旧就不用说了，02、03年刚开始学游戏开发的时候，这种配表的方法就是初级读本中也会收录的基本技能。

未能完成调动策划的使命是怎么回事呢？但凡使用配表的工作组，往往只有两种对配表的组织方式：

一种是程序提供核心流程后，“给，配吧”，交给策划。

一种是策划想好自己的需求后，告诉程序，我要这样一个流程，然后这些地方开给我配置。

从扩展性上来说：

前者的问题是，做这个功能的程序实际上决定了整个系统的扩展能力。

而后者的问题是，虽然表面看起来策划拥有对这个系统的控制权，但是实际上，做这个功能的程序实际上决定了整个系统的扩展能力。

无论哪种情况下，策划由于并不是实际的实现者，因此再强势，其实也只是纸老虎。真正把控系统命脉的，仍然是制作这个系统的程序。如果这个程序是个没有扩展性思想的程序的话，策划需求的完成时间就会随着开发时间变得越来越高。如果这个程序是个有扩展性思想的程序的话，他一定会抛弃配表这种做法。

从配表本身的特点来说：

配表本身其实并不是为了解决流程概念的。它只是为了能让一些数据性的工作能交出去，不要占据程序宝贵的编程心力。用来描述已经既定的、简单的逻辑也是能够胜任的。比如，当条件A成立时做行为A，条件B成立时做行为B这种还是能够手到擒来的。

问题在于，项目开发期，特别是端游，很多方案最终的样子跟最初的样子能够差得很远很远。我们的策划一开始也认为技能判伤害，最多只要做父子关系就行了。实际的结果呢？判伤害这块儿根据需求的变化已经调整了好几版了。如果我们程序是按照配表的方式做的话，单读表、分析表的地方都要改好几次。

虽然这种工作对程序而言是小Case，但是同样也是没营养的工作，我相信就算是再喜欢写程序的，隔三岔五让你改个读表、改个流程，你也会心怀愤懑的。

简而言之：配表无法自我进化。

再怎么说，配表只是流程的附庸，先有了流程，才能决定配表是怎么个东西，如果流程在变，配表自然无法自我圆满。

所以，拿配表来做流程的想法典型的就是土鳖想法——没有见过更好的方式，所以只能寄希望于他们唯一明白的方式——配表、配表、再配表。

我认为，程序有责任告诉他们，你们有更好的方式来完成你们的目的。

脚本是专业的流程工具

人们设计语言和脚本，就是因为他们能够在我们和计算机之间建立起沟通的桥梁。人们因此可以让计算机去做我们想要他们做的事情。

刚刚说的那个问题，脚本化之后根本就不是问题：

之前的一次技能一次伤害判定不够了？脚本里这块儿之前是做了一次，你自己再加几次。

哦，对了，相应的数据可以自己从配表里面读喔，不想读的直接写死在脚本里也行。

后面，如果有需要的话，这里你改成读表就行。

什么？你改了表结构？那脚本这里读表的地方你自己改一下就好啦。

……

除此之外还能完成很多你之前不敢想的东西：

什么？Boss战的整个流程完全要跟角色技能不一样？

没关系，为Boss这个技能单做一组脚本……中间还可以穿插场景交互喔~~

过去程序钉死那就是死了，现在？自己发挥去吧。

此外，脚本化后显而易见的我们获得了下面的优势：

减少沟通成本，增加效率

之前版本的时候，都是策划忙，然后给程序一堆问题，程序费劲解决，策划休息，程序解决完后，策划再忙，忙完后再给程序一堆问题，循环往复。

关键是，做沟通的时候经常发现很多问题：策划问题描述不清楚，说半天程序仍然一头雾水，或者乱猜问题原因，查半天发现问题其实在别处，项目中沟通永远是最大的成本。

现在不会了，程序这边拼了命开新任务，策划那边狂野地改脚本、配表，有问题过来问问，说清楚了回去继续搞。两组人马都几乎100%专注在自己的业务上。

程序的设计被倒逼框架化、模块化、单元化。

过去，到底要不要把系统做成模块完全要看相关程序的水准。

系统按照组件化的设计进行，却写出了几十个互相依赖交织成网的组件这种事情简直是太正常了——一个程序团队十几号人，每个人的代码天天都能监控到吗？

现在不需要了，程序不做成模块也不可能了，因为你要把模块接口导出给策划用啊，不模块化，借口怎么办？导出怎么写？

程序再想偷一时之懒也是不可能的了，必须模块化地去考虑问题，而这种考虑方式虽然一开始会麻烦些，后面将带来深远的好处和影响。

程序概念更清晰

代码无小事，任何在IDE里敲下的代码必然先天就带有各种问题。

过去，为了实现策划需求，我们必须把本来不该程序去考虑的东西硬给安插到我们的系统里去。

上层设计就算一开始是健全的，也极易因为需求的不断提出和修改，加上赶工，加上对结构理解不深的人们的“好心维护”，到后面千疮百孔。

现在不会了，程序不需要考虑数值计算、升级流程、关卡载入时的行为、物品使用时的条件判断、技能施放后的效果——所有这些都是脚本和工具去做的，程序只需要保证：

IO指令正常发送给每个游戏对象。

游戏对象本身的各个功能组件状态，在任何情况下正常、可控。

游戏对象互相之间的交互接口，在任何情况下正常、可控。

游戏世界对游戏对象在任何情况下的删除、增加、获取操作正常、可控。

这样的设计才是真正的设计。

更早地发现设计问题，更灵活地完成目标

策划自己负责实现功能后，比之前对设计变得更敏锐了。之前设计策划案时隐藏的细节设计问题，这下不太可能再被隐藏下来了。

游戏中很多细节的问题真心不是程序能解决的，Dota这么成熟的游戏，都还会有一些机制上的小问题在极限情况下会造成Bug，何况我们呢？

另外，可以到达某个目标的路变多了，因此策划没必要一开始战战兢兢地去设计整个系统，生怕哪里没想清楚后面麻烦，而是可以由浅入深，就算一开始没想明白，后面想明白了改改脚本就Ok。

所以，尽早地推进脚本化战略吧！

不是为了给程序省事儿，而是为了项目的未来。

最后还是想感谢一下我们的策划们，能开始接受并愿意向着这个方向前进，跟你们的合作很愉快，谢谢你们！