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

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

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

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

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

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

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

从扩展性上来说：

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

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

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

从配表本身的特点来说：

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

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

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

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

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

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

我认为，程序有责任告诉他们，你们有更好的方式来完成你们的目的。脚本是专业的流程工具

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

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

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

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

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

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

……

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

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

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

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

此外，脚本化后显而易见的我们获得了下面的优势：减少沟通成本，增加效率

……

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

……

程序概念更清晰

……

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

……