我们需要怎样的游戏编辑器

我当技术策划（也叫TD）也有一阵子了，参与过一些大型项目，经手的业务类型和工作流也各种各样。恰逢最近面临一些变动，便整理一些工作心得。

从我个人视角看，目前TD的工作可以分成以下三类：

• 快速产出原型玩法
• 设计大型复杂系统
• 设计并维护工作流
  

第一点，快速产出原型玩法，其实不太算是TD的专职工作，而应该是每个策划岗位都需要的基本技能，而且这里面其实也没什么门道，至少熟练掌握商业引擎或者一些其他的原型工具，就不是什么大问题。

关于第二点，大型复杂系统设计，会包括技能、AI、任务、关卡、对话、过场等等，是多数游戏的主体内容，业务逻辑深度大，而且需求多变，每一项具体业务都牵扯很多细节，不便在此一一展开。

至于第三点，设计并维护工作流，和上一条其实是互为表里的工作，TD需要基于对业务的理解，设计好一个制作流程中需要在什么模块引入哪些工种，每个环节交付什么内容，最后整合得到最终的产品。相比于具体的业务，编辑器作为一个话题就不那么庞大，本文就围绕编辑器展开好了。

1. Gameplay的编辑环境

根据以往的项目经验，策划需要使用到的编辑环境，两只手数得过来，无妨穷举一遍。

1.1. 文本

文本是最基本、最直接、最自由的格式，而优秀的文本的编辑工具则非常普遍，如

• VSCode
• SublimeText
• Notepad++
  

文本最大的优势，还是在于它一般是最终的数据格式。如果没有加密或者压缩，运行时读取的配置文件最终是文本，这表示用文本表示的内容是最接近运行时数据的，因此通过修改文本造成改动需要经过的步骤最少，修改起来效率最高。

直接编辑文本还有以下优势：

• 是最容易比对与合并的格式，多人同时编辑没有压力
• 不依赖引擎，可以直接使用文本编辑器打开，复制粘贴撤销，批量查找与替换等基础编辑功能健全
• 没有图形界面的渲染压力，数据量很大也不会造成卡顿
• 没有编辑界面的遮蔽，编辑者更接近数据的最终结果
• 可以自定义格式，从而自定义可读性和信息密度
  

实际上，文本编辑的优势是如此明显，以至于我一度暴言，一个大型项目的开发效率取决于有多少配置可以直接走文本。关于这个暴言面临的实际挑战，我们留到后文再聊。这里先简单列举一下文本格式存在的缺陷：

• 非常容易出现格式错误，难以排查，因此必备良好的辅助工具，例如自动补全，格式校验等
• 如果格式设计失当，容易导致信息密度过低或者语境过高，难以阅读
  

适合文本直接编辑的格式的内容有：

• 剧情台本
• 自定义脚本语言
• 有良好辅助工具的json，xml等配置文件，这里良好的辅助工具是必要前提
  

1.2. 参数面板

参数面板是一个把参数都平铺开的面板，一般来说属于引擎白给的功能，典型例子如：

• Unity的Inspector界面（尤其是在有了Odin插件加持之后）
• Unreal的Details界面
  

参数面板能够比较清晰地显示出当前有哪些可配置项，以及每一项的具体信息。一般来说参数面板都高度可扩展，可以很方便地实现下列功能：

• 优化排版，控制复合结构的折叠和展开
• 在字段数量大时提供搜索功能
• 控制每一个字段的类型、值域
• 提供交互逻辑友好的提示
• 根据合法性或相关性控制特定字段的显示或隐藏
• 在引擎内可以支持拖动交互
• 提供搜索功能
  

在参数面板的辅助下，配置的条理性和安全性都可以得到相当大的提升。另外，参数面板的序列化也比较友好，所以相关的配置文件很多时候可以不用打开引擎就能编辑，在比对与合并的时候也比较好操作。

不过参数面板也有一些问题，例如：

• 在字段数量大的时候导航困难
• 不方便查看、比对较大量的数据
  

参数面板主要适合编辑能够便捷地以树形展开，且没有复杂引用关系的数据结构，例如简单的键值映射、列表与字典


1.3. 表格

表格是一个典型的根据键来索引值的结构，不过受到展示方式的限制，能够直观呈现出来的仅有二维表格。

表格的优势在于：

• 可以非常直观地通过单键或者双键索引一个值，在嵌套使用的情况下具备非常强大的描述能力
• 便于批量预览
• 有一套白给的工具集，如Excel和GoogleSheet，在绘制格式、数据筛选、公式计算、功能开发等方面都有非常强大的功能和可扩展性
  

然而表格的问题也有很多，例如：

• 要求配置的格式高度统一，对于存在多态的数据支持不友好，容易增加数据和操作的冗余，例如
  

• 字段A依赖字段B的配置才生效时，对应的依赖关系很难在表中体现
• 一些极少数情况才使用的字段在表格中需要占一列
  

• 无法逐级展开，涉及到多层级结构时只能嵌套，不便于编辑数组、字典字段
• 在列多的时候导航困难
• 编辑器环境和编辑环境经常不够隔离，即Excel本身是一个集格式、公式、导出于一体的工具，难以比对与合并，导致表格原文件在多人协作时比较不友好
• Excel源文件的数据绝大多数情况不能直接使用，需要走一套导出流程，迭代流程可能因此变得繁琐
  

二维表最适合描述的是大量简单的内容，用简单的一维或者二维键值映射就可以完全描述的数据。一旦超出这个范畴，继续使用表格就需要：

• 把多个层级的数据强制铺在一张二维表中，造成配置字段的冗余
• 多张表嵌套使用，增加导航的难度
  

一旦上述配置方式在项目中开始蔓延，表格的编辑效率就会开始下降。


1.4. 时间轴

时间轴是用来精确地调整时机的工具，主要优势在于能够快速预览一段时间中某个精确时刻的状态，因此一般也需要配合一个视窗使用。

如果沿用Unity Timeline的术语，一个时间轴会包括多个Track，Track上面可以装载Event和Clip；Event对应一个时刻，而Clip由起止时间标记出一个时间段，这些都是为了精确描述逻辑触发的时间。

目前商业引擎一般都有较为成熟的时间轴工具，如Unreal的Sequence，Unity的Timeline，不过实际项目中依然会有大量需要自定义时间轴的需求。

时间轴的优势

• 能够直观地看到某个事件的发生时间，以及不同事件的先后关系
  

时间轴容易遇到的问题

• 由于和表现强相关，因此比较容易涉及到逻辑和表现的协作部分，协作的需求比较大；然而一般时间轴编辑后保存下来的数据格式相对复杂，比对与合并的工作略显繁琐，协作性不是特别好（在Unreal中可以靠合理设计嵌套规则解决）
  

适合时间轴工具编辑的业务

• 动作打击，需要精确地配合角色动作调整攻击判定、特效、音效以及一些逻辑区间（如无敌帧、霸体帧）的时机
• 过场动画，需要快速地预览摄像机、场景和角色之间的位置关系，调整运动的节奏
  

1.5. 曲线

时间轴工具的另一个版本是曲线编辑器。曲线主要描述的是两个值的映射关系，并且将值的变化绘制出来。如果输入值是时间的话， 那么曲线就可以是时间轴上的一部分。

曲线主要适合难以精确定量地描述变化过程的时机，例如：

• 角色身上某些逻辑挂点的位置如何随着动画变化
• 相机的某些参数如何随着角色运动变化
  

实际开发过程中，尤其是表现强相关的部分，我们很多时候是基于直观在调整，这时的需求都是类似于：如果这里再怎样一点点就好了，这样子的。用数值来拟合这样的描述效率相当低，因此曲线工具可以较好地辅助解决这类问题。


1.6. 节点图

近几年来通过节点图编写逻辑的方式开始盛行。节点图是由节点（Node）和连线（Link）组成的结构，其中节点和连线表示的含义可以各有不同。节点图的特点如下：

优势：

• 直观，上手难度低
• 节点类型、引脚的类型、连线数量的约束都可严可宽，能够适配各种不同的业务类型
• 可以通过嵌套实现更加复杂的逻辑
• 与编辑器深度结合后还可以执行断点等操作，迭代效率高
  

劣势：

• 信息密度低，逻辑一旦复杂起来会变得极难维护
• 节点数量大了之后或许会面临渲染效率的问题
• 涉及到编辑器到运行时数据的转换
• 编辑节点图的操作在物理上有些许不便，因为涉及到鼠标和键盘操作的频繁转换
  

在设计得当的情况下，节点图能够提供符合直觉的编辑方式，只要搭配合适的事件和变量机制，可以大幅提高开发效率。下面介绍几种不同的节点图类型。

1.6.1. 流

流是一种用节点表示执行逻辑，连线表示数据流向和执行顺序的节点图，典型的流节点图例如Unreal的蓝图和材质编辑器等。

流和其他的节点图相比的特性如下：

• 节点类型自由，可以用于表示数据或者逻辑，也可以有流程控制节点，如Sequence和ForLoop
• 引脚数量与连线类型自由，允许连出网状结构
• 可以用于表示数据输入输出关系或者执行顺序
• 不擅长表示结构
  

典型的适合由流来编辑的内容包括：

• 涉及到数据流和执行流混编的复杂业务，例如关卡流程，技能流程，对话流程
• 函数，可复用的逻辑片段
  

1.6.2. 树

树是用节点表示逻辑或数据单元，连线表示从属关系的一种特化的节点图，典型的例子如Unreal的行为树和状态树

树相比于流有更强的结构性：

• 要求严格按照树形结构展开，每一个子节点拥有唯一确定的父节点，且根节点只有一个，连线用于指示节点之间的父子关系
• 如果涉及到执行，会根据节点执行后的返回信息决定接下来的导航方式（一般来说是成功和失败）
  

需要指定运行时在树中的导航方式，例如：

• 行为树，显式地使用Composite节点来指定一个父节点下的子节点以怎样的规则执行，以及通过主动Interrupt或者Decorator类型节点来控制打断
• UE状态树，隐式地规定了从父状态进入和跳出子状态的规则
  

基于以上特性，我们也可以找到适合用树表述的业务特性

• 有逐级细化的特征，支持多分支，末梢有多出口，例如对话树
• 有统一的导航逻辑，例如AI的行为树或者决策树
  

1.6.3. 状态机

状态机是由节点表示状态，连线表示跳转关系的图，典型的状态机工具包括：

• Unity Animator
• Unreal Logic Driver插件
  

状态机图有以下特性：

• 节点表示状态，连线用于指示状态之间的跳转关系，由于每一个跳转都有对应的图形化的连线表示，因此创建、预览、编辑一条跳转都可以非常直观
• 状态之间互斥，如果需要状态共存的话，需要多层并行的状态机，不像流或者树可以同时有多个节点在执行
  

因此状态机的优势也非常明显：

• 适合表示多个互斥状态之间以及之间的跳转关系，尤其是在可以不增加状态的情况下通过编辑跳转来更细致地定制多个状态之间的流转关系。例如，如果有状态A和状态B，状态A有子状态A1和A2，他们都可以跳转到B，如果希望从A1到B触发某逻辑，但A2到B不触发，这样的事情在状态机里可以简单增加一条跳转来表示，比其他的图简单直接得多
• 可以便捷地基于状态来控制一些功能的生命周期，例如当一个单位进入击飞状态时，就关闭边缘保护（即允许被从边缘击落）
  

适合使用状态机的业务包括

• 交互物件，例如门、宝箱、有特定身份的NPC等
• AI状态，一般来说游戏AI最上层是由一些互斥的状态表示的，如待机，搜索，战斗，关卡指令等；还有一些更具体的行为状态，例如一个在休息室休息->走到工作间工作->回到休息室休息这样的简单循环状态
• 动画状态切换，如在UE动画蓝图和UnityAnimator中的表示方式
  

1.7. 公式

公式是一类特化出来的配置类型，专门服务于数值运算。

公式比较少被作为单独的编辑格式，主要有以下原因：

• 多数游戏没有太复杂的数值计算过程，多数数值配置是在公式中已经预留好的位置填入参数
• 简单的公式往往可以由执行流直接拼凑而成，如UE蓝图提供的数学运算节点
• 一些现成工具提供的计算解决方案已经能够满足需求，例如Excel自带的公式
  

但是，实际开发中，依赖比较复杂的数值计算的需求其实并不罕见，例如：

• Dota中死灵法的大招，敌方每损失1点生命值就额外受到X点伤害
• 金铲铲之战S9比尔吉沃特羁绊的效果，将受到的伤害累计下来并且在一定时间后造成该累计伤害百分比的伤害
• 星穹铁道角色刃的普攻，造成攻击力百分比加上最大血量百分比的伤害
  

此外，在实际数值平衡操作中，仅仅调节数字是不够的，往往需要修改到参与计算的因子。这时，如果有快速自定义整个计算过程的方式，对开发迭代效率可以有较大提升。


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提供了一个非常优秀的范例。他本质上是一个表格工具，将不同对象的不同字段平铺在一张二维表里，提供了相当大一部分表格编辑的体验，例如能够便捷地对比多个条目中同一个字段的值，而编辑之后还是保存在原本的文件中。


所以，实际编辑的需求会来自各种不同的视角。如果工具集能够服务于不同视角的编辑体验，便有益于开发效率的提升。当然，每个项目都有自己的实际情况，这里主要说的是大型团队研发，并且上线之后会长线运营的项目，在工具集上多花一些功夫，从长远来看一定是更具性价比的方式。

3. 编辑器的未来

聊到这里，我们不妨进一步问，编辑器的本质的功能是什么？

我给出的答案是这样的，编辑器是一套把策划脑内的设计，翻译成游戏可读的数据（或者源数据）的翻译工具。只是因为这部分数据要求特定的格式，而在编辑器的辅助下，产出符合格式的内容会更容易。

不过这个翻译器能做的工作非常有限，因为他产出的内容仅仅能够支持游戏运行时的读写，还有大量的翻译其实是靠人自身来完成的。例如，我用流编辑了一个技能，我需要在开发环境中有一个技能描述，同时项目里还需要一个面向玩家的技能描述文案，这个文案会有不同的多语言版本。这三份数据实际上描述的是同一个东西，而开发者需要把他翻译成三份不同格式的数据，存放在项目中的不同位置，如果有一个地方发生了修改，其他的地方也得相应修改。再举一个例子，策划会撰写一个需求，程序相应地开发了一个功能，程序需要在代码中添加注释，或者项目的知识库中描述功能的实现，而策划还需要维护一份配置文件的使用手册。这里，我们也可以认为，需求+功能代码+配置文件+使用手册，最终共同描述了同一个东西，只是被从不同的角度和粒度翻译了若干遍。

所以，我们是否可以期待一个翻译工具，能够在自然语言描述的需求，和符合格式的游戏数据之间任意转换，帮我们省去在不同格式中来回翻译的时间？换一个更时髦的说法，我们能否期待一个拥有多模态能力的工具？到这里，是不是就很自然地联想到生成式AI了。现阶段我们依然有充分的理由怀疑AI能否胜任第一创作者的工作，但是如果已经有一份符合设计要求也符合格式规范的内容，希望AI工具把它转换成别的格式，这听起来就不像一个那么难以实现的事情。他不需要知道为什么有A，但是他会知道A=B。换个柏拉图主义的说法，我们的工具不需要理解什么是理念，而只需要识别不同的形式可以表达相同的理念（插一句，柏拉图哲学中理念一词的希腊文是Eidos，其实也是古墓丽影早期开发商的名字）。

举个例子，当我们要制作一段任务的时候，不免需要经过剧情大纲、台本、对话与演出配置、任务配置等等环节，每一个环节要交付的内容和侧重点都不尽相同，但其实他们背后的逻辑是很相近的。我是不是可以设想，在工具的合理辅助下，我只需要给其中的一部分足够充分的描述，而其他的部分可以先由工具代劳做到一半甚至更高的完成度？

如果再激进一些，在传统的工作流里，数据流向都是单向的，如果下游遇到了问题，一般是反馈到上游修改。我们是否可以设想，这许许多多的中间环节的交付的成果，其实都依赖同一套整合性的描述，以至于即便我在下游直接修改，他也可以将改动直接同步到上游？这一设想乍一看有些离经叛道，毕竟从一般的认知上来说，保证工作流简单稳定，而灵活协调的事情都交给人来处理，是更合理的思路。但是人类组织其实并不能够保证永远比程序更灵活，尤其是随着规模的扩大，人类组织的效率折损远大于程序。据此我们可以认为，面向未来的开发方式不是定制组织级别的流程以让更多人协作，而是通过对工具的优化和人的培养，让个人可以完成更多的工作。如果原本分属上下游的工作被合并为一环，上下游之间即便有再复杂的互相影响，也成为了个人决策范围内的事，省去了沟通与协作的损耗。这里我们看到，提升个人效率和缩减组织规模带来的效率提升是可以互相促进的。

那么，如果技术进步的速度没有那么快，又该如何呢？如果在未来的一个产品周期（大约3-5年）依然还是由人类主导设计，技术作为生产的辅助手段的话，我们应该如何期待一个更好的，面向策划的游戏编辑环境？以下几个点或许可供参考

• 更好的类型定义，以及对不同类型数据的更有效的区分。游戏引擎会把美术用的数据类型分得干干净净，模型，材质，贴图，动画，灯光；而IDE会严格地帮助程序区分好每个不同的数据类型，而策划配表的时候无论什么类型的数据都是一个单元格，无论什么类型的引用都是一个ID，出错的概率自然会高很多。一般商业引擎的编辑器都提供了稳定的类型约束的控件，通过拖动和点选的操作来减少手误，是非常值得借鉴的。
• 更好的导航。目前任何一款面向人类的产品几乎都会提供基础的导航功能，例如后退与前进。网页浏览器可以，APP可以，IDE可以，但策划的工作环境变化比较大，经常需要在多个不同类型的文件，多个不同的窗口，甚至多个独立的软件中来回切换，在这些彼此独立的环境中导航就成为了一个纯粹消耗精力的事情。如果有一个一站式的入口，能够通过简单的切换子窗口的操作，完整浏览要编辑的全部内容，而对于外部引用的内容都能提供快捷的跳转，那么编辑者的心智负担又可以降低许多。
• 尽可能短的验证流程。每当完成编辑一个内容的时候，可以在尽可能短的时间内验证这次编辑的效果。如果校验和数值发布花费的时间不能缩短，那就给一个能够绕过校验的途径；如果每次启动游戏花费的时间不能缩短，那就提供一个能够不重启游戏就看到修改生效的方式。人的注意力是一种非常稀缺的资源，一旦散了就很难找回来，千万不能浪费在等待上。
• 尽可能简单的文件管理。一些编辑器工具，在编辑测基本做到了比较友好的交互，但是在编辑器UI背后，实际操作的内容可能非常复杂，导致策划在提交的时候总是不确定哪些是自己有意的修改，哪些是自己无意动到的，或者编辑器的隐含规则操作到，实际上需要提交的。如果编辑器操作和实际修改的文件之间的映射规则简单直观，那么用户也会花更少的时间甄选自己的实际的工作。
  

实际上，上述这些特性对于任意一款商业引擎而言都是交互体验的及格线，因此对于一个熟悉引擎基础功能的朋友，都会觉得拿原生功能做个Demo不是什么困难的事情。然而遗憾的是，大家总觉得做Demo的方法未必能够直接做项目，做项目总需要一些额外的条条框框，这些条条框框当然能够提升项目的稳定性，但是如果没有经过足够好的修饰，它们也会对效率造成不必要的损害。那么，为什么不能像做Demo一样做项目呢？明明不是那么难以做到的事情，为什么效率和稳定不能全都要呢？

最后再借题发挥一下。表面上看，编辑器和工作流的问题，处理的是每一项开发业务到对应的工具链的映射，是一个静态的问题；但是实际上这更是一个如何理解人和组织的问题，是一个面向有发生与发展过程的动态的问题。

前面提到过，所有的想法都不是一蹴而就的。想清楚需要时间，传达想法需要时间，执行想法也需要时间，而人和组织的都是有限的。编辑器和工作流通过提高个人的效率，可以在单位时间内做到更多的事情。更重要的是，效率提高意味着试错成本降低，一些失败的探索变得可以承担，也不会过度挫伤团队的信任和积极性。毕竟一个团队最不容透支的是士气。

此外，更高的效率意味着更多的试错机会，更意味着一套在错误中学习和自我纠正的机制有存在的空间，以及旁逸斜出的想法有机会得到验证与支持。做过游戏设计的都知道，一个好结果，尤其是可持续的好结果，都不应该依靠某次灵光乍现，而是靠一个拥有可靠的反馈循环的系统，在一次一次迭代中渐进地产生的。工具的进步，实际上给了组织机会，来形成这样的反馈循环的机制。

念在国内大多是在做长线运营的项目，除了关注项目是怎么做出来的，也要关注他该怎么继续做下去。目前许多的大型项目，是通过建立流程，让20个专业不同的人得以协作，然而这些人可能一进来就被困死在这个1/20的空间里，而且充满了互相损耗。而我们期望的更好的流程，是给这些大家各自发展的空间，比如渐渐地覆盖5/20的工作，这样组织的效率得到了提升，而对于寻求进步的人都可以得到个人的发展，而不是在重复的工作中变得麻木而失去热情。

所有人类的创造，无论是具体的事物还是组织，都遵循着这样一个过程。它起初只是一个想法，这个想法在不断塑形，不断向外传播，不断变得更加具体，从而能号召更多的人，在一遍一遍这样的循环中，最终积累到足够的让自己诞生的力量。这个是个令人着迷的过程，像极了基督教里说的道成肉身。如果我们依然相信人类的创造，那让就我们尊重这个生长的过程，并给予圣子降临的土壤，直到有一天，也许有一天，我们的创造再也不直接依赖人的思考。


来源：七八五十万
原文：https://mp.weixin.qq.com/s/_G6RjgfHlpNmhWBHwhaTYg