The world at your fingertips - 天涯明月刀幕后（9）工具

2018-03-30

https://zhuanlan.zhihu.com/gu-yu

前文回顾：The world at your fingertips - 天涯明月刀幕后8（重启）

脚本

趁着小方重做整个动画系统，策划黄教授也蠢蠢欲动。

在mmo游戏中，战斗系统的逻辑描述是一个工作量的重头。大量的Buff、动画、特效信息，按照时间轴排列，分别被配置和整合，将美术、程序、策划的想法融合到一起。

旧版本的战斗逻辑内嵌在xml里面，战斗的各种基本功能是程序根据策划需求开发的，策划通过XML配置，将各种功能整合形成各种人物的技能。

技术策划黄教授是一个掌控欲极强的男人，为了获得更强的能力来征服世界，他想要更好的武器，他需要脚本。脚本作为胶水语言，很适合用作整合各种功能，有一定的灵活性，也不至于增加太多的复杂性。我们的第一想法是整合一个Lua之类的语言就好了，但是黄教授不要。他表示Lua显示不出他的能耐，人人都会的东西，不容易有壁垒，对他今后在项目中的地位会有影响。

所以黄教授又像当年设计动作框架、重构战斗体系一样，说我们自己做一个极简的脚本吧。全部语法从简，只有简单的表达式和跳转，配合各种方便策划的shortcuts，能少打字就少打字。编译模块内置，直接做到数据文件转换过程中，脚本可以热更新，不用调试和debug，反正没打算给别人用。

虽然这个需求有点荒谬，但想想能做个初步的脚本编译模块还是很有趣的。这时候引擎团队加上逻辑团队也有十个多人了，我的工作也逐渐从每天想怎么搞定编程的任务，变成了如何把这些兄弟们的工作排满。更多的间接层次，带来了更多的脑力负担，其实并不好玩，但项目要做大做强，别无他法。

这个任务规模不大，做起来不费事，胜固然可喜，败也可以无忧，大不了让黄教授还用老方法工作，这个正是求之不得的理想任务。想着想着，我就顺手把这事情记到了pending task pool里面。

过了两天，项目事情稍空一点，转念一想，这么有趣的事情，而且整体规模不大，怎么能交给别人做呢，当然要自己来搞啦。搞砸了就搞砸了，Leader是最适合做这种不在关键路径上的任务的。

说干就干。大学毕业多年，编译原理早忘光了，但想想黄教授要的并不复杂，直接用状态机搞语法分析吧。先上去写代码，发现不太对，搞不出来。老老实实拿了一张纸，画状态关系跳转，思考结构该如何组织。

因为这个语法比较简单，一会就画出来了，按状态机编程，很快搞定了。周末回去想想，有点意思，翻了一下编译原理的材料，其实自己瞎凑做了一个DFA。原来大学里面学的编译原理没有那么复杂，虽然当时也没认真学习，事后自己也可以推导的。

后续就是让所有模块都数据驱动，把词法分析需要用到的语法描述放到XML文件中，然后把输出的结果也放到XML中，就顺利完成了词法分析、语法检查等功能，且和原来的对象序列化直接结合，完美。

输出方面偷了一个懒，并没有编译成字节码，直接写小解释器运行这些逻辑吧，先应付了燃眉之急，其他都可以日后再说。我郑重的把输出字节码并执行这件事写到了To Do List，总有一天我会做的，我恨恨的想。不见天日的任务很快会被遗忘，特别是后续的维护工作转给其他同学之后，不出意外，这个工作就逐渐被淡忘了。

再后面的事情就变得无聊起来，我需要工程化的解决所有问题，确保各种情况下策划都能使用这个工具。所有的事情都是开始有趣，收尾无聊，好比开学的时候都是踌躇满志，期末考试的时候如丧考妣。

策划喜欢用Excel来编辑数据，游戏引擎自然不会读Excel格式，而是读XML数据和Binary数据。于是我们要做XML和Excel数据互相转换，开始研究office的自动化编程。两种数据格式的语法描述能力不同，所以要有各种工程角度的取舍和权衡，并配合策划工作流程做细致的设计，再考虑多人协作的工作流，还要做一些双向的转换同步。便于开发的辅助功能也不能忘记，时不时策划还要在Excel里面做点注释，这个信息也不能在转换XML后丢失，虽然游戏引擎并不需要这些数据，但工具流程必须考虑。

黄教授真是磨人的小妖精，天天有需求，日日缠着我。我找了个借口，赶紧把做了八成的功能转给其他同学维护，从此断了和他的羁绊，相忘于江湖。

布料

天刀早期的版本，布料得到了玩家的一致肯定，玩家身上的衣服，随着战斗、轻功等动画，会自然飘动，一方面会更自然，另一方面也降低了3D动画的工作量，相关动作制作的时候就不需要考虑服装飘动了。这里用了Nvidia的Apex Clothing技术，是一个比较完善的解决方案了。

但是开发布料全过程并不如此顺利。

优先摆在我们面前的困难，是Apex Clothing并不成熟，也在开发中。虽然Apex Clothing已经有不错的demo展出，但开放的API版本还是不够完善，经常需要NVidia的深度支持才可以搞定。还好我们和Nvidia的关系一直不错，双方也有好的合作意愿，希望能把这个技术更好的应用在游戏中，所以推进还是比较顺利。

对于中间件等技术，一直有的一个问题就是先有鸡还是先有蛋。项目会表示，我们很愿意用前沿技术啊，等你们的版本稳定了，我们一定用，先让隔壁家的项目试试水吧。技术开发团队会忽悠，说你们现在不用就来不及啦，隔壁谁谁谁马上就有某某某游戏要用上了，少壮不努力老大徒伤悲，过去不投入，将来必是悔之晚矣。这样的一般将来过去完成时，往往特别有说服力，让项目心驰神往，目眩神迷，一冲动就用上了新的技术。

在考虑引入新鲜技术的时候，一定要考察合作厂商意愿，有没有可能深度合作，开放源码的中间件是最好的，真出了问题也能自己定位问题，如果是封闭源码的组件，就必须有很好的合作关系，才有可能顺利应用。产品的环境比demo复杂一万倍，再好的组件，没有经过2-3个产品的实际应用，终究还是温室的花朵，经不起风吹雨淋。

其次的问题是引擎整合。目前Nvidia已经在Unreal等大型引擎中，整合了Clothing组件，但当时是没有的，而且我们是自研引擎，也只能自己来整合整套SDK了。从团队里面捉了一个做过PhysX相关工作的同学，就开始做Clothing。整个引擎框架当时还不够成熟，物理没有，渲染模块也女大十八变，一天一个样，在浮沙筑高台，难度可想而知。负责的程序同学天天被抽，日日被逼，终于奋起反抗，提了离职，成为天刀客户端的离职第一人。好在走之前，总算把布料大致放了进去，虽然性能不理想，结构非常乱，但勉强能work了。

最后我们发现，怎么和想象的不一样，布料整合在系统里面了，但还是没有办法调试出好的效果。于是又把问题定位到技术美术。技术美术是一个神奇的工种，拥有跨界的知识，站在美术食物链的顶端，藐视众生。在布料系统的开发中，技术美术的作用不容小视，和Nvidia多次深入沟通，研究如何调试出好的参数，中间来回迭代多轮，这才在最终拿出了大家都满意的效果。

越到后期，团队的协同增效越明显。已经不怎么存在依靠单一团队就可以搞定的技术，那些容易搞定的，早已被搞定。剩下的，基本都是需要多团队协同，加上跨界人才从中协调，才有可能开发出来的特性。为了开发最后20%的特性，可能需要80%的人力，二八法则怎么都成立。最艰难的是，在走通所有流程前，这个工作怎么看都是遥不可及的，需要一点运气和坚持。回想天刀开发过程中被砍掉的不少features，对比布料系统，非常感慨。布料系统也一直徘徊在要不要砍掉的边缘，对那些不幸的特性，是不是当时我们再坚持一下，结果就会有所不同呢？

Editor

早期的天刀用了原先MMO的地图编辑器，因为场景比较小，问题也不大。

但那个地图编辑器架构并不合理，渲染模块和主体引擎的渲染不一致，导致后续开发渲染效果，很可能要编辑器做一份，引擎做一份，浪费了工作量。另外之前的工具集也过于零散，大量功能散落在不同的工具中，如果这些工具之间没有足够好的规划，共享模块，也会带来渲染模块一样的问题，即代码模块的重复开发。

显然，这是一个历史遗留的问题，大量的工具集来自于不同时期的不同项目，每一个项目并没有太多的时间来整合，就忙着继续开发新的游戏内容。工具碎片化带来了维护的高成本和重复开发，也带来了使用体验上的割裂。

往另一个极端看，UE、Unity为代表的大、中型引擎，喜欢所谓的All-in-One式样的引擎，重型引擎，什么功能都有，使用体验顺畅，追求一站式解决问题。重复开发问题是没有了，但并不能完全解决开发效率问题。越大的引擎，编译链接时间也越长，开发一个功能涉及的模块也越多，也可能造成程序员过多的脑力负担。

其实还是一个度的问题，如何在两个极端中找平衡，是一个没有标准答案的问题。

具体到天刀当时的情况，虽然旧版本工具集也勉强能用，但可预见的将来，维护成本必然会越来越高，并不符合开发团队的长期利益。但我们也没有技术宅的架构强迫症，一切要为工程服务，适当的妥协是可以考虑的。我们决定先整合所有地图编辑器模块，做个新的编辑器。模型导入导出模块，需要考虑给外包公司用，还是独立开发，以免暴露太多内部工具。当然，两个系统必须要共享一样的渲染和底层模块。

事实上，是不是要从头做引擎，做决定之初是非常犹豫的，最重要的原因就是考虑到编辑器开发的巨大工作量，可能会拖慢整个项目的进展。但架不住怨念的日积月累，今天有人抱怨一下旧引擎的不堪，明天有人在旧框架下抽掉一块砖，渐渐的，我们就发现与其天天活在哀怨里，不如奋起反击，推翻这不合理的技术架构。

我们就这么开始了编辑器的开发，小李天天加班到死，Tough哥努力贡献着渲染功能，时不时抽空帮忙做点编辑器模块，包哥搞资源浏览器模块，我抽空把底层对象架构整理一下，顺便做点对编辑器友好的导入导出、copy/paste功能、多对象属性编辑之类的工作，也维护了一些通用的控件。

在多年的开发中，编辑器开发始终承担了极其繁重的任务，所有的新特性，都往往和编辑器有所关联。开发人员做出新的功能，经过技术美术或者技术策划的初步验证，通过了，就需要编辑器提供量产的工具支持。没有什么一蹴而就的成功，一切庞然大物的诞生，都来自点点滴滴的进步。在美术的焦急催促中，在策划的翘首以盼中，在程序的众志成城中，编辑器慢慢成型，逐渐把以往繁复冗余的工具集替换。然而，只有游戏开发不结束，编辑器永远不会有被完成的那一天，就像建筑工地的脚手架，编辑器始终伴随着产品的成长。

岔开说几句，在国外的游戏行业，工具程序员受到非常大的认可，而在国内，工具程序员并不被重视。我想原因还是在于国内游戏行业并不足够成熟，大量项目的开发流程和技术还停留在简单的初步竞争（不包括商业化，这个国内是最强的）。在这样一个环境中，功能的有没有，重要性远远大于质量好不好以及效率高不高。而在国外游戏行业，已经进入了比较成熟的阶段，竞争也比较激烈，对游戏产品本身提出了更高的要求。工具是促进多人协作的最重要的因素之一，大型团队如果没有好的工具，根本无法支撑巨型游戏的开发。在这样的竞争下，能不能提高团队的效率，往往是一个重要的考虑因素，所以工具开发就被提到了相当的高度。

参与评论