The world at your fingertips — 天涯明月刀幕后21（妥协）

一元

文/顾煜 专栏：https://zhuanlan.zhihu.com/gu-yu

前文回顾：The world at your fingertips — 天涯明月刀幕后20（繁星）

轻量的编辑器

对于技能、特效等制作内容所必不可少的工具，开发工作也被逐渐提上议事日程。毕竟我们不能总让策划用文本工具来处理XML文件。

在编辑器模块，一直有着很多不同的思路。总体来说，更强大功能、更深度整合是一个大趋势，Unity、Unreal莫不如此，提供了一个巨大的all in one版本editor。整合编辑器带来了非常多的好处，便于开发者在一个统一的环境里开发、测试功能，但有一些小的不足。一个小问题是随着更多的功能被塞进编辑器，编辑器越来越庞大，导致启动一次编辑器的时间已经长到无法忍受。另一个问题是高度整合的架构，导致开发非常复杂，模块之间耦合非常的紧密。

我们最后并没有选择All in one的editor。当然编辑器启动慢并不是最大的原因，最大的原因还是在于all in one的编辑器开发成本过高，会产生大量的冗余代码。这里和单机游戏有一个巨大的不同。地图编辑器当然还是尽可能完整的整合大量功能，但对于其他网游常用的周边功能，我们选择剥离出来。

比如我们要做技能编辑器，技能的逻辑，在我们的体系中，是在服务器端被处理的，主要是为了安全原因。技能编辑器要配置的，不仅仅是画面表现，包括动画、特效等，还有大量技能逻辑信息，比如位移距离、什么时间点加什么buff、每个技能和其他buff如何产生互动等等。这些逻辑信息都在服务器上处理，我们不应该，也不可能把它们放在客户端中处理。

我们的编辑器体系是纯单机的，我们也不应该尝试让编辑器连接服务器协同工作，这会让工作变得更复杂，如果强行那样做，会有大量的冗余逻辑处理代码散布在服务器和客户端。一个合适清晰的物理边界是有必要存在的，编辑器就是单机的，游戏就是联网的，服务器只需要考虑和游戏连接即可。

在这些大前提下，对于一个游戏中角色技能的实际预览，很难在一个纯编辑器的环境中进行完美的模拟，我们既不能绕开服务器逻辑，把相关逻辑处理代码在编辑器中重新实现一遍，也不想连上服务器，让服务器的设计变得更复杂。另外技能预览，时不时需要在实际游戏中做一个体验，召唤出一堆怪物做点试验，这个工作也无法在编辑器中进行。

实际情况变得有一点复杂，需要做一些决定了。

最理想的做法，无疑是用编辑器中也可以跑游戏的做法，就像unity中一样，只能说，咱们当时开始做的时候并没有想到这样做，属于考虑不周，后续发现这个模式很有价值的时候，已经积重难返，来不及修改了。

考虑到所有技能的效果和逻辑，最终都会在客户端游戏和服务器上完美展示，这个是我们绝对无法绕开的最小工作集，再考虑到驱动这些效果和逻辑表现的底层数据都是XML数据，我们退一步，做成游戏也可以有少量in game编辑功能的模式，配合热加载数据以及一个更通用的XML编辑器来完成这部分工作。

最终的架构，是游戏中有少量编辑模式的代码。所有的配置数据在一个通用的编辑器中进行，这个编辑器只按照时间轴来编辑各种xml数据，我们把实际的技能预览都放在游戏中进行。当编辑完数据，我们可以一键导出到游戏客户端和相应服务器上，客户端和服务器逻辑都可以热加载新的改动，这样我们就可以不用重新启动游戏，就看见新的技能。由于游戏在实际运行，会随时热加载所有修改的数据，所以测试新的技能也很方便。客户端和编辑器全部打开在两个屏幕，修改完导出，服务器和游戏客户端会自动热加载，所以策划需要做的只是选择游戏的客户端，直接召唤一群敌人测试一下新招数即可。迭代速度基本是30s就可以完成保存、导出到测试全过程。

这是一个运行时刻动态attach上去的编辑器，对于不需要做技能的开发人员，他们无需感知到这个编辑器的存在，也不用付出额外的开发维护成本。游戏、服务器和编辑器的公共接口就是描述技能的基础XML格式上，每个部分只要保证能正确存取这个格式即可，没有太多维护成本。编辑器模块只要保证能做通用的XML编辑即可，预览等问题都无需考虑，因为那些本来就是游戏和服务器需要做的工作。编辑器模块对各方面依赖都比较小，额外的开发成本非常低，后续维护成本也最小化了，是当时能做的不错的选择。

同样的思路也被用在了很多其他模块上，脚本编辑、特效编辑等，都是attach在具体的游戏进场，只需要在游戏和服务器上做好数据的热更新，能随时响应新变化的数据，就可以即时预览新的变化。

妥协

对于程序员来说，游戏工具和流程的开发，永远是一个怕做什么就来什么需求，缺什么功能就被催什么特性的过程。

由于我们一开始并没有打算做无缝世界，所以也没有考虑协同编辑同一个地图的工作。每个地图一组策划、美术负责，并行展开数张地图的工作就好了。

大多数时间这个模式工作的挺好，直到项目快临近上线了，更现实的问题就出现了。每个地图进展速度不一，但有些地图确实来不及开发了，而且工作量差距不小，仅仅依靠加班是无法解决的。

多人协作编辑又被提上了议事日程。但这类特性是需要从一开始就规划的，不能指望在最后一刻开发。这是一个牵一发动全身，想一下头就痛的功能，会影响到完整的开发流程，眼看游戏要上线测试，策划和美术来不及开发的功能，程序也很难在短时间开发出来并投入使用。

做不到100分，做个70分，缓解一下美术和策划的问题也好，再小的改动也是有帮助的。我们分析一下遇到的问题，目前开发工作来不及，所以策划和美术希望能同时工作在一张地图上，通过更多的人力投入，来加速地图的开发工作。而原来的所有引擎、工具链，都是假设同一时刻只有一个人在一个地图上工作，每一个编辑操作，都没有考虑多人并行的问题。

在大型引擎中开发游戏，即使在UE4如此成熟的引擎，也有大量协作中的数据冲突。各个项目组一般都是有非常细节的开发流程跟进，规定了各个步骤谁可以编辑哪些文件，才能确保多人能同时在一个游戏项目上工作。具体到我们项目，也建立了这样细致的工作规范，目前看上去我们需要做的，就是进一步细化规范，配合少量开发，来确保大家能并行工作。

多人协作有两个重要的问题需要解决。

最核心的是如何避免数据的冲突，如果大家做不同的工作，修改的都是不同的数据，那就不存在冲突的问题，多个人也可以同时工作了。我们做了深入的分析，根据策划和美术在地图开发的工作内容，拆分了他们需要编辑的内容，然后把相关需要修改的数据一一梳理。以此为基础，我们把制作地形、制作逻辑内容、摆放场景物件等常见的工作分类，把它们需要操作的数据剥离，建立了更细节的工作流程，明确告知策划什么操作会修改什么数据，什么情况下大家编辑的内容会有冲突。在这个流程下，大家就可以在自由度受限的情况下，进行一定程度的写作工作。

不太重要的问题是如何快速同步大家的工作，把所有数据合到一起，看见最终的结果。最极端的例子，可以想象一下多人版的minecraft，其实就是一个多人编辑器，所有的编辑改动都像网游一样，随时被所有工作人员看见。我们还真见过这种类型的编辑器Demo，可以多人同时工作，原理也不难想象，就是一个多人游戏的结构，但做原型容易，做产品太难，要把这样的Demo做成成熟的工具，有很多的工作需要做。在这个项目里面，没必要死磕这么高端的问题，我们只要解决手边的问题，还是比较简单的，由于我们尽量分开了协作编辑的数据，所以在我们定义的工作流程上，大多数工作都不会导致数据有冲突，直接从Perforce是拿最新的版本即可。

协作工作中另一个常常冲突的数据，是mmorpg中常用的表格。很多表格天生就需要被多个不同的开发者使用，比如怪物的配置表格，掉落表格，都是属于不同地图人员同时会使用的。一个简单的办法是把表格分得更细，同一个表格，可能会根据记录数量，分成几个文件，确保每个策划只能更新其中的一个文件，避免冲突。这个方法并不够优雅，但事实上可用。

我们也在考虑有没有更好的方法。正好有公共团队做了一个表格的编辑工具，进一步缩小了表格修改的粒度，可以针对每一个表格行，做单行的锁定、修改和上传。策划可以工作在数据行的层面，且带有版本管理，即使有冲突也可以比较方便的解决，比原先通过流程和分散文件来管理的方式高端很多。

作为程序员，我们天生对这样模式的修改有好感，也尝试整合相关的逻辑，推动策划团队尝试。但这个推动并不顺利。

天刀的团队是新组建的，每个团队的人有各种不同背景，开发中的理念不同一直是一个问题，我们经常会面临观念上的差异。对于不同的开发模式，推动和PK是常见的事情。过去的开发中，我们面临过要不要引入PBR渲染的争论，我们有过策划要不要用脚本来写关卡逻辑还是让程序来写逻辑的争论，我们有过精细碰撞要基于现有框架还是在原有体素模式上修改的争论，每一次的争论，据理力争，尽可能有理有据说服大家，有些争论则需要老于最后拍板。团队一直表现出了比较高的职业素养，争论可以有，但决定做出来了，我们就坚决执行。

逐行修改的表格编辑系统，理念上是有先进性的，而策划实际使用下来并不顺利。策划工作中有大量编辑数据，依赖于excel的表格体系，数据策划也会在excel中做各种宏，来模拟计算，简化表格修改过程。在我们的逐行编辑系统中，我们不可能复刻excel的功能。功能的不足还在其次，最不济我们也可以让传统excel和新的表格编辑系统并存，更大的问题还在于编辑习惯。策划普遍对这么细粒度的编辑流程不适应，没法习惯这样的工作方式。这个就比较致命。对于大型项目，每个子模块都和其他周边系统有千丝万缕的关系，引申出千头万绪的流程和协作关系，表面上看我们仅仅修改了一个表格编辑系统，实际上对地图编辑器，对策划工作编辑流程，对制作内容的游戏中预览等模块都有不小的冲击，全面改变了大家的所有工作流程，被策划抵制，也是意料中的事情了。

很遗憾这个系统没有被推进下去，策划又回到了原来的工作状况中。没有完美的选择，都是权衡的过程，策划付出了数据管理复杂的代价，换来更简化和熟悉的工作流程，很难判断是对是错。日后的漫长岁月中，他们时不时还是会抱怨表格数据的冲突问题，回想起程序员为之努力而抛洒过的血泪，他们有没有后悔过当初的选择？