GameRes游资网

 找回密码
 立即注册
查看: 5412|回复: 0

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

[复制链接]
发表于 2018-3-30 11:12:35 | 显示全部楼层 |阅读模式
02.jpg

文/顾煜 专栏: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功能、多对象属性编辑之类的工作,也维护了一些通用的控件。

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

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

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|稿件投递|广告合作|关于本站|GameRes游资网 ( 闽ICP备05005107-1 )

GMT+8, 2018-6-18 19:56

快速回复 返回顶部 返回列表