大家再熟悉不过的UnityAnimator，最典型的状态机
1.7. 公式
公式是一类特化出来的配置类型，专门服务于数值运算。
公式比较少被作为单独的编辑格式，主要有以下原因：
- 多数游戏没有太复杂的数值计算过程，多数数值配置是在公式中已经预留好的位置填入参数
- 简单的公式往往可以由执行流直接拼凑而成，如UE蓝图提供的数学运算节点
- 一些现成工具提供的计算解决方案已经能够满足需求，例如Excel自带的公式
但是，实际开发中，依赖比较复杂的数值计算的需求其实并不罕见，例如：
- Dota中死灵法的大招，敌方每损失1点生命值就额外受到X点伤害
- 金铲铲之战S9比尔吉沃特羁绊的效果，将受到的伤害累计下来并且在一定时间后造成该累计伤害百分比的伤害
- 星穹铁道角色刃的普攻，造成攻击力百分比加上最大血量百分比的伤害
此外，在实际数值平衡操作中，仅仅调节数字是不够的，往往需要修改到参与计算的因子。这时，如果有快速自定义整个计算过程的方式，对开发迭代效率可以有较大提升。
策划最熟悉的公式编辑方式还是在Excel里
1.8. 视窗
视窗本身并不负责数据储存，主要是预览位置关系，同时也是便捷地编辑位置信息的界面。
视窗可以作为辅助面板，配合各种需要视觉预览的编辑环境使用，例如编辑时间轴（如对话），也可以作为编辑位置强相关的信息的主要界面，如果关卡中物体的静态位置，或者环境笔刷。
对于这类位置敏感的信息，有视窗可预览的编辑体验会完胜无视窗。
典型的适合由视窗编辑的信息包括
- 关卡中对象的位置信息和材质信息（如用笔刷
- 角色身上特定挂点的位置信息
2. 编辑器的使用
2.1. 编辑环境的嵌套
在理解了以上可用的编辑方式后，我们只要理解每一项业务的具体特性，做一些简单的排列组合，就可以很方便地构建出任何一个复杂业务需要使用的编辑工具。
拿一个对话举例：
- 在最上层是流或树，表示选择支和对应的跳转关系，例如此处选A触发分支对话，选B返回上一级，选C完成任务退出对话
- 流或树内部可以维护一些变量，通过参数面板定义和编辑，管理一些分支走向，例如当角色智力大于16时会开启特殊对话选项
- 流或树中的执行节点可以是时间轴，表示一段顺序播放的游戏内对话，在时间轴上有角色和相机的轨道，记录了每一个时刻角色的表情动作语音，以及相机机位，在玩家做出对应选择时，播放时间轴。
再拿一个环境交互物举例：
- 最上层是一个状态机，表示了交互物可能有的状态，以及状态之间的可能的跳转规则
- 状态机的每一个状态，以及每一个跳转，都可以展开为一个或者多个流，流里记录的是进入该状态或者该跳转状态时，需要执行的逻辑
- 流中可以嵌套时间轴，用于触发动画，或者表示在精确的时刻需要发生的事情；时间轴里也通过事件再嵌套流，用于复用一些流的片段，执行一些较为复杂的逻辑。
- 通过视窗预览和编辑对象、子对象位置，通过参数面板来编辑简单的属性，这些基本的需求就不再展开说了
（实际上，这基本可以理解为一个Unreal的Actor蓝图加上一个LogicDriver插件，这也从侧面说明了UE的原生工作流是相当优秀的）
2.2. 配置方式之间的相互转换
另外，不同的配置方式之间不仅能够互相嵌套，也是可以互相转化的。
绝大多数的表格编辑器，最终导出时会去掉公式和格式，变成仅有值的文本；绝大多数节点编辑器的最终的编辑产物也会被序列化成文本。不过相比于这种偏底层的序列化，更值得讨论的是，在不破坏原有配置格式的特性并保证逻辑同构的前提下，配置方式之间的互相转化，例如：
- UE5引入的StateTree，其实是用树形结构表示的状态机
- UE蓝图中可以写数学函数，其实是用流表示的公式
- 曲线编辑器保存的实际结果，等价于一个公式
可以看到，同样的内容被用不同的配置格式描述，是很常见的事情。只要逻辑上同构，几乎任何配置方式之间都可以互相转化。这种可转化性可以衍生出两种不同的工具开发思路：
第一种，保证工具的统一性，将尽可能多的结构使用同一种配置方式来描述，这样工具开发的工作量小，策划需要掌握的工具集少，项目的稳定性高，但是无可避免地有很多数据无法用符合直觉的方式配置，在执行侧会造成比较大的损耗，未来扩展时也会面临更大负担。
第二种，保证配置的便捷性，尽可能为每一项业务提供符合直观的编辑方式，这样工具开发的工作量大，策划需要掌握的工具集多，在工作流正式运转起来之后可以比较大地提升效率，但是前期需要投入比较大的工程开发成本，策划也需要付出一定的学习成本。而且这里的便捷其实并不意味着稳定性差，因为合适的工具会提供足够好的查错机制，减少格式错误，对策划来说会比较友好。
在实际开发中，每个项目都是在这两种思路之间做权衡。套用两个简单的判断维度，一个是苦一苦开发还是苦一苦策划的问题，另一个是维持短期的稳定高效还是长期的灵活可扩展。
行业早期的项目，整体上会更偏向工具的统一，因为当时的项目规模比较小，里面的复杂内容也比较少，在表格工具足够成熟的情况下，大量项目会统一使用Excel来搭建策划的配置环境。Excel先天功能强大，不行的话还可以上VBA，对于一些小型项目基本够用。因此很多策划的工具技能也都围绕着Excel展开。不过相应的问题是，当你手上有个锤子，就容易看什么都是钉子。于是会衍生出大量的Excel配置的技能、对话、关卡等，其中不乏一些非常复杂的流程，需要依赖层层叠叠的嵌套来完成，变得难以维护。
另一个与此非常接近的思路，是我前面提到的，能走文本就走文本。常用的文本编辑器能提供比较方便的跨文件导航，全局搜索和批量修改，尽管可能需要花较长时间来培养策划学习项目的文本格式，但是一旦掌握之后效率便完全不输Excel。
所以，如果简单的工具链也完全能够胜任，为什么还要开发复杂的工具呢？一个东西，只要逻辑上同构，就可以用任何配置格式表示出来，那只要策划想清楚，用什么配置格式不都一样吗？以及，在开始动手之前想清楚，难道不是策划的本职工作吗？
道理上是这样，但是实际情况却未必这么理想。因为实际上很多策划其实是想不清楚的，至少一开始很可能是还没想清楚的。项目从来不会是完全想清楚怎么做才开始的，所以开发需要花时间来理解需求，而策划也需要花时间把需求想清楚。在此之上，做过研发的朋友都有一个广泛的共识，其实想清楚才最花时间。
所以，提升发开发效率的关键路径，在于如何帮助大家更快地想清楚，而这正是综合性的工具集体现优势的地方。
举个例子，在手上只有表格工具的时候，想要从中抽象出来一个状态机，并且人为地在这两种格式之间翻译，不会是一件十分轻松的事情，尤其是如果此时来了一个新人，让他从0开始理解这一套配置结构，就会有相当高的成本。相比之下，面对一个已经有对应的图形界面的状态机，可以指着一个节点说这是一个状态，指着一条连线说这是一个跳转，就能够比较轻松地建立起一套关于状态机的直观。而且，当状态机的编辑器可以复用的时候，对应的运行时也是可以复用的，因此也不必每次根据策划的需求重新抽象一个近似的功能。
当然，在工具集复杂，且支持互相嵌套的时候，运行时有可能造成一些性能问题，此时往往会触到一些技术大佬的雷区。运行时效率，尤其在关系到后端时，确实是个不容忽视的问题，只是优化工作也需要计算性价比。优化的本质，是让人多解决一些问题，从而让机器少解决一些，其实是把运行的成本转嫁到开发头上。所以最后要算的账，是为了节省运行时成本，额外增加了多少开发成本。尤其是，为了确保运行时效率而复杂化了开发的流程，增加了人员沟通上的损耗，影响了开发效率，是有可能更加得不偿失的。更何况，规划得当的话，过度复杂的嵌套本是可以避免的。
再说到配置格式的互相转化问题。如果一个项目的工具集做得复杂了，使用的时候该如何判定哪些内容应用哪些格式配置呢？答案是小孩子才做选择，大人全都要。UE的PropertyMatrix提供了一个非常优秀的范例。他本质上是一个表格工具，将不同对象的不同字段平铺在一张二维表里，提供了相当大一部分表格编辑的体验，例如能够便捷地对比多个条目中同一个字段的值，而编辑之后还是保存在原本的文件中。
UE的PropertyMatrix
所以，实际编辑的需求会来自各种不同的视角。如果工具集能够服务于不同视角的编辑体验，便有益于开发效率的提升。当然，每个项目都有自己的实际情况，这里主要说的是大型团队研发，并且上线之后会长线运营的项目，在工具集上多花一些功夫，从长远来看一定是更具性价比的方式。
3. 编辑器的未来
聊到这里，我们不妨进一步问，编辑器的本质的功能是什么？
我给出的答案是这样的，编辑器是一套把策划脑内的设计，翻译成游戏可读的数据（或者源数据）的翻译工具。只是因为这部分数据要求特定的格式，而在编辑器的辅助下，产出符合格式的内容会更容易。
不过这个翻译器能做的工作非常有限，因为他产出的内容仅仅能够支持游戏运行时的读写，还有大量的翻译其实是靠人自身来完成的。例如，我用流编辑了一个技能，我需要在开发环境中有一个技能描述，同时项目里还需要一个面向玩家的技能描述文案，这个文案会有不同的多语言版本。这三份数据实际上描述的是同一个东西，而开发者需要把他翻译成三份不同格式的数据，存放在项目中的不同位置，如果有一个地方发生了修改，其他的地方也得相应修改。再举一个例子，策划会撰写一个需求，程序相应地开发了一个功能，程序需要在代码中添加注释，或者项目的知识库中描述功能的实现，而策划还需要维护一份配置文件的使用手册。这里，我们也可以认为，需求 功能代码 配置文件 使用手册，最终共同描述了同一个东西，只是被从不同的角度和粒度翻译了若干遍。
所以，我们是否可以期待一个翻译工具，能够在自然语言描述的需求，和符合格式的游戏数据之间任意转换，帮我们省去在不同格式中来回翻译的时间？换一个更时髦的说法，我们能否期待一个拥有多模态能力的工具？到这里，是不是就很自然地联想到生成式AI了。现阶段我们依然有充分的理由怀疑AI能否胜任第一创作者的工作，但是如果已经有一份符合设计要求也符合格式规范的内容，希望AI工具把它转换成别的格式，这听起来就不像一个那么难以实现的事情。他不需要知道为什么有A，但是他会知道A=B。换个柏拉图主义的说法，我们的工具不需要理解什么是理念，而只需要识别不同的形式可以表达相同的理念（插一句，柏拉图哲学中理念一词的希腊文是Eidos，其实也是古墓丽影早期开发商的名字）。
举个例子，当我们要制作一段任务的时候，不免需要经过剧情大纲、台本、对话与演出配置、任务配置等等环节，每一个环节要交付的内容和侧重点都不尽相同，但其实他们背后的逻辑是很相近的。我是不是可以设想，在工具的合理辅助下，我只需要给其中的一部分足够充分的描述，而其他的部分可以先由工具代劳做到一半甚至更高的完成度？
如果再激进一些，在传统的工作流里，数据流向都是单向的，如果下游遇到了问题，一般是反馈到上游修改。我们是否可以设想，这许许多多的中间环节的交付的成果，其实都依赖同一套整合性的描述，以至于即便我在下游直接修改，他也可以将改动直接同步到上游？这一设想乍一看有些离经叛道，毕竟从一般的认知上来说，保证工作流简单稳定，而灵活协调的事情都交给人来处理，是更合理的思路。但是人类组织其实并不能够保证永远比程序更灵活，尤其是随着规模的扩大，人类组织的效率折损远大于程序。据此我们可以认为，面向未来的开发方式不是定制组织级别的流程以让更多人协作，而是通过对工具的优化和人的培养，让个人可以完成更多的工作。如果原本分属上下游的工作被合并为一环，上下游之间即便有再复杂的互相影响，也成为了个人决策范围内的事，省去了沟通与协作的损耗。这里我们看到，提升个人效率和缩减组织规模带来的效率提升是可以互相促进的。
那么，如果技术进步的速度没有那么快，又该如何呢？如果在未来的一个产品周期（大约3-5年）依然还是由人类主导设计，技术作为生产的辅助手段的话，我们应该如何期待一个更好的，面向策划的游戏编辑环境？以下几个点或许可供参考
- 更好的类型定义，以及对不同类型数据的更有效的区分。游戏引擎会把美术用的数据类型分得干干净净，模型，材质，贴图，动画，灯光；而IDE会严格地帮助程序区分好每个不同的数据类型，而策划配表的时候无论什么类型的数据都是一个单元格，无论什么类型的引用都是一个ID，出错的概率自然会高很多。一般商业引擎的编辑器都提供了稳定的类型约束的控件，通过拖动和点选的操作来减少手误，是非常值得借鉴的。
- 更好的导航。目前任何一款面向人类的产品几乎都会提供基础的导航功能，例如后退与前进。网页浏览器可以，APP可以，IDE可以，但策划的工作环境变化比较大，经常需要在多个不同类型的文件，多个不同的窗口，甚至多个独立的软件中来回切换，在这些彼此独立的环境中导航就成为了一个纯粹消耗精力的事情。如果有一个一站式的入口，能够通过简单的切换子窗口的操作，完整浏览要编辑的全部内容，而对于外部引用的内容都能提供快捷的跳转，那么编辑者的心智负担又可以降低许多。
- 尽可能短的验证流程。每当完成编辑一个内容的时候，可以在尽可能短的时间内验证这次编辑的效果。如果校验和数值发布花费的时间不能缩短，那就给一个能够绕过校验的途径；如果每次启动游戏花费的时间不能缩短，那就提供一个能够不重启游戏就看到修改生效的方式。人的注意力是一种非常稀缺的资源，一旦散了就很难找回来，千万不能浪费在等待上。
- 尽可能简单的文件管理。一些编辑器工具，在编辑测基本做到了比较友好的交互，但是在编辑器UI背后，实际操作的内容可能非常复杂，导致策划在提交的时候总是不确定哪些是自己有意的修改，哪些是自己无意动到的，或者编辑器的隐含规则操作到，实际上需要提交的。如果编辑器操作和实际修改的文件之间的映射规则简单直观，那么用户也会花更少的时间甄选自己的实际的工作。
实际上，上述这些特性对于任意一款商业引擎而言都是交互体验的及格线，因此对于一个熟悉引擎基础功能的朋友，都会觉得拿原生功能做个Demo不是什么困难的事情。然而遗憾的是，大家总觉得做Demo的方法未必能够直接做项目，做项目总需要一些额外的条条框框，这些条条框框当然能够提升项目的稳定性，但是如果没有经过足够好的修饰，它们也会对效率造成不必要的损害。那么，为什么不能像做Demo一样做项目呢？明明不是那么难以做到的事情，为什么效率和稳定不能全都要呢？
最后再借题发挥一下。表面上看，编辑器和工作流的问题，处理的是每一项开发业务到对应的工具链的映射，是一个静态的问题；但是实际上这更是一个如何理解人和组织的问题，是一个面向有发生与发展过程的动态的问题。
前面提到过，所有的想法都不是一蹴而就的。想清楚需要时间，传达想法需要时间，执行想法也需要时间，而人和组织的都是有限的。编辑器和工作流通过提高个人的效率，可以在单位时间内做到更多的事情。更重要的是，效率提高意味着试错成本降低，一些失败的探索变得可以承担，也不会过度挫伤团队的信任和积极性。毕竟一个团队最不容透支的是士气。
此外，更高的效率意味着更多的试错机会，更意味着一套在错误中学习和自我纠正的机制有存在的空间，以及旁逸斜出的想法有机会得到验证与支持。做过游戏设计的都知道，一个好结果，尤其是可持续的好结果，都不应该依靠某次灵光乍现，而是靠一个拥有可靠的反馈循环的系统，在一次一次迭代中渐进地产生的。工具的进步，实际上给了组织机会，来形成这样的反馈循环的机制。
念在国内大多是在做长线运营的项目，除了关注项目是怎么做出来的，也要关注他该怎么继续做下去。目前许多的大型项目，是通过建立流程，让20个专业不同的人得以协作，然而这些人可能一进来就被困死在这个1/20的空间里，而且充满了互相损耗。而我们期望的更好的流程，是给这些大家各自发展的空间，比如渐渐地覆盖5/20的工作，这样组织的效率得到了提升，而对于寻求进步的人都可以得到个人的发展，而不是在重复的工作中变得麻木而失去热情。
所有人类的创造，无论是具体的事物还是组织，都遵循着这样一个过程。它起初只是一个想法，这个想法在不断塑形，不断向外传播，不断变得更加具体，从而能号召更多的人，在一遍一遍这样的循环中，最终积累到足够的让自己诞生的力量。这个是个令人着迷的过程，像极了基督教里说的道成肉身。如果我们依然相信人类的创造，那让就我们尊重这个生长的过程，并给予圣子降临的土壤，直到有一天，也许有一天，我们的创造再也不直接依赖人的思考。
,
