从我个人视角看，目前TD的事情可以分成以下三类：
1. 快速产出原型玩法
2. 设计大型繁芜系统
3. 设计并掩护事情流
第一点，快速产出原型玩法，实在不太算是TD的专职事情，而该当是每个策划岗位都须要的基本技能，而且这里面实在也没什么门道，至少闇练节制商业引擎或者一些其他的原型工具，就不是什么大问题。
关于第二点，大型繁芜系统设计，会包括技能、AI、任务、关卡、对话、过场等等，是多数游戏的主体内容，业务逻辑深度大，而且需求多变，每一项详细业务都牵扯很多细节，不便在此逐一展开。
至于第三点，设计并掩护事情流，和上一条实在是互为表里的事情，TD须要基于对业务的理解，设计好一个制作流程中须要在什么模块引入哪些工种，每个环节交付什么内容，末了整合得到终极的产品。比较于详细的业务，编辑器作为一个话题就不那么弘大，本文就环绕编辑器展开好了。
1. Gameplay的编辑环境
根据以往的项目履历，策划须要利用到的编辑环境，两只手数得过来，无妨穷举一遍。
1.1. 文本
文本是最基本、最直接、最自由的格式，而精良的文本的编辑工具则非常普遍，如
VSCodeSublimeTextNotepad++文本最大的上风，还是在于它一样平常是终极的数据格式。如果没有加密或者压缩，运行时读取的配置文件终极是文本，这表示用文本表示的内容是最靠近运行时数据的，因此通过修正文本造成改动须要经由的步骤最少，修正起来效率最高。
直接编辑文本还有以下上风：
是最随意马虎比对与合并的格式，多人同时编辑没有压力不依赖引擎，可以直策应用文本编辑器打开，复制粘贴撤销，批量查找与更换等根本编辑功能健全没有图形界面的渲染压力，数据量很大也不会造成卡顿没有编辑界面的遮蔽，编辑者更靠近数据的终极结果可以自定义格式，从而自定义可读性和信息密度实际上，文本编辑的上风是如此明显，以至于我一度暴言，一个大型项目的开拓效率取决于有多少配置可以直接走文本。关于这个暴言面临的实际寻衅，我们留到后文再聊。这里先大略列举一下文本格式存在的毛病：
非常随意马虎涌现格式缺点，难以排查，因此必备良好的赞助工具，例如自动补全，格式校验等如果格式设计失落当，随意马虎导致信息密度过低或者语境过高，难以阅读适宜文本直接编辑的格式的内容有
剧情台本自定义脚本措辞有良好赞助工具的json，xml等配置文件，这里良好的赞助工具是必要条件例：神秘海疆4的动画事宜，末了产生的东西基本便是文本
1.2. 参数面板
参数面板是一个把参数都平铺开的面板，一样平常来说属于引擎白给的功能，范例例子如：
Unity的Inspector界面（尤其是在有了Odin插件加持之后）Unreal的Details界面参数面板能够比较清晰地显示出当前有哪些可配置项，以及每一项的详细信息。一样平常来说参数面板都高度可扩展，可以很方便地实现下列功能
优化排版，掌握复合构造的折叠和展开在字段数量大时供应搜索功能掌握每一个字段的类型、值域供应交互逻辑友好的提示根据合法性或干系性掌握特定字段的显示或隐蔽在引擎内可以支持拖动交互供应搜索功能在参数面板的赞助下，配置的条理性和安全性都可以得到相称大的提升。其余，参数面板的序列化也比较友好，以是干系的配置文件很多时候可以不用打开引擎就能编辑，在比对与合并的时候也比较好操作。
不过参数面板也有一些问题，例如：
在字段数量大的时候导航困难未便利查看、比对较大量的数据参数面板紧张适宜编辑能够便捷地以树形展开，且没有繁芜引用关系的数据构造，例如大略的键值映射、列表与字典
人见人爱的Odin Inspector
1.3. 表格
表格是一个范例的根据键来索引值的构造，不过受到展示办法的限定，能够直不雅观呈现出来的仅有二维表格。
表格的上风在于：
可以非常直不雅观地通过单键或者双键索引一个值，在嵌套利用的情形下具备非常强大的描述能力便于批量预览有一套白给的工具集，如Excel和GoogleSheet，在绘制格式、数据筛选、公式打算、功能开拓等方面都有非常强大的功能和可扩展性然而表格的问题也有很多，例如：
哀求配置的格式高度统一，对付存在多态的数据支持不友好，随意马虎增加数据和操作的冗余，例如字段A依赖字段B的配置才生效时，对应的依赖关系很难在表中表示一些极少数情形才利用的字段在表格中须要占一列无法逐级展开，涉及到多层级构造时只能嵌套，不便于编辑数组、字典字段在列多的时候导航困难编辑器环境和编辑环境常常不足隔离，即Excel本身是一个集格式、公式、导出于一体的工具，难以比对与合并，导致表格原文件在多人协作时比较不友好Excel源文件的数据绝大多数情形不能直策应用，须要走一套导出流程，迭代流程可能因此变得繁琐二维表最适宜描述的是大量大略的内容，用大略的一维或者二维键值映射就可以完备描述的数据。一旦超出这个范畴，连续利用表格就须要
把多个层级的数据逼迫铺在一张二维表中，造成配置字段的冗余多张表嵌套利用，增加导航的难度一旦上述配置办法在项目中开始蔓延，表格的编辑效率就会开始低落。
WatchDog2的NPC应激表，800列很难配
1.4. 韶光轴
韶光轴是用来精确地调度机遇的工具，紧张上风在于能够快速预览一段韶光中某个精确时候的状态，因此一样平常也须要合营一个视窗利用。
如果沿用Unity Timeline的术语，一个韶光轴会包括多个Track，Track上面可以装载Event和Clip；Event对应一个时候，而Clip由起止韶光标记出一个韶光段，这些都是为了精确描述逻辑触发的韶光。
目前商业引擎一样平常都有较为成熟的韶光轴工具，如Unreal的Sequence，Unity的Timeline，不过实际项目中依然会有大量须要自定义韶光轴的需求。
韶光轴的上风
能够直不雅观地看到某个事宜的发生韶光，以及不同事宜的先后关系韶光轴随意马虎碰着的问题
由于和表现强干系，因此比较随意马虎涉及到逻辑和表现的协作部分，协作的需求比较大；然而一样平常韶光轴编辑后保存下来的数据格式相对繁芜，比对与合并的事情略显繁琐，协作性不是特殊好（在Unreal中可以靠合理设计嵌套规则办理）适宜韶光轴工具编辑的业务
动作打击，须要精确地合营角色动作调度攻击剖断、殊效、音效以及一些逻辑区间（如无敌帧、霸体帧）的机遇过场动画，须要快速地预览摄像机、场景和角色之间的位置关系，调度运动的节奏Unity Timeline的官方教程中的截图
1.5. 曲线
韶光轴工具的另一个版本是曲线编辑器。曲线紧张描述的是两个值的映射关系，并且将值的变革绘制出来。如果输入值是韶光的话， 那么曲线就可以是韶光轴上的一部分。
曲线紧张适宜难以精确定量地描述变革过程的机遇，例如：
角色身上某些逻辑挂点的位置如何随着动画变革相机的某些参数如何随着角色运动变革实际开拓过程中，尤其是表现强干系的部分，我们很多时候是基于直不雅观在调度，这时的需求都是类似于：如果这里再若何一点点就好了，这样子的。用数值来拟合这样的描述效率相称低，因此曲线工具可以较好地赞助办理这类问题。
Unreal的曲线编辑器
1.6. 节点图
近几年来通过节点图编写逻辑的办法开始盛行。节点图是由节点（Node）和连线（Link）组成的构造，个中节点和连线表示的含义可以各有不同。节点图的特点如下：
上风：
直不雅观，上手难度低节点类型、引脚的类型、连线数量的约束都可严可宽，能够适配各种不同的业务类型可以通过嵌套实现更加繁芜的逻辑与编辑器深度结合后还可以实行断点等操作，迭代效率高劣势：
信息密度低，逻辑一旦繁芜起来会变得极难掩护节点数量大了之后或许会面临渲染效率的问题涉及到编辑器到运行时数据的转换编辑节点图的操作在物理上有些许不便，由于涉及到鼠标和键盘操作的频繁转换在设计得当的情形下，节点图能够供应符合直觉的编辑办法，只要搭合营适的事宜和变量机制，可以大幅提高开拓效率。下面先容几种不同的节点图类型。
1.6.1. 流
流是一种用节点表示实行逻辑，连线表示数据流向和实行顺序的节点图，范例的流节点图例如Unreal的蓝图和材质编辑器等。
流和其他的节点图比较的特性如下
节点类型自由，可以用于表示数据或者逻辑，也可以有流程掌握节点，如Sequence和ForLoop引脚数量与连线类型自由，许可连出网状构造可以用于表示数据输入输出关系或者实行顺序不善于表示构造范例的适宜由流来编辑的内容包括
涉及到数据流和实行流混编的繁芜业务，例如关卡流程，技能流程，对话流程函数，可复用的逻辑片段Unity热门插件FlowCanvas中的流编辑器
1.6.2. 树
树是用节点表示逻辑或数据单元，连线表示从属关系的一种特化的节点图，范例的例子如Unreal的行为树和状态树
树比较于流有更强的构造性：
哀求严格按照树形构造展开，每一个子节点拥有唯一确定的父节点，且根节点只有一个，连线用于指示节点之间的父子关系如果涉及到实行，会根据节点实行后的返复书息决定接下来的导航办法（一样平常来说是成功和失落败）须要指定运行时在树中的导航办法，例如：行为树，显式地利用Composite节点来指定一个父节点下的子节点以若何的规则实行，以及通过主动Interrupt或者Decorator类型节点来掌握打断UE状态树，隐式地规定了从父状态进入和跳出子状态的规则基于以上特性，我们也可以找到适宜用树表述的业务特性
有逐级细化的特色，支持多分支，末梢有多出口，例如对话树有统一的导航逻辑，例如AI的行为树或者决策树Just Cause 3中的NPC行为树，范例的父子树嵌套的构造
1.6.3. 状态机
状态机是由节点表示状态，连线表示跳转关系的图，范例的状态机工具包括：
Unity AnimatorUnreal Logic Driver插件状态机图有以下特性：
节点表示状态，连线用于指示状态之间的跳转关系，由于每一个跳转都有对应的图形化的连线表示，因此创建、预览、编辑一条跳转都可以非常直不雅观状态之间互斥，如果须要状态共存的话，须要多层并行的状态机，不像流或者树可以同时有多个节点在实行因此状态机的上风也非常明显：
适宜表示多个互斥状态之间以及之间的跳转关系，尤其是在可以不增加状态的情形下通过编辑跳转来更细致地定制多个状态之间的流转关系。例如，如果有状态A和状态B，状态A有子状态A1和A2，他们都可以跳转到B，如果希望从A1到B触发某逻辑，但A2到B不触发，这样的事情在状态机里可以大略增加一条跳转来表示，比其他的图大略直接得多可以便捷地基于状态来掌握一些功能的生命周期，例如当一个单位进入击飞状态时，就关闭边缘保护（即许可被从边缘击落）适宜利用状态机的业务包括
交互物件，例如门、宝箱、有特定身份的NPC等AI状态，一样平常来说游戏AI最上层是由一些互斥的状态表示的，如待机，搜索，战斗，关卡指令等；还有一些更详细的行为状态，例如一个在安歇室安歇->走到事情间事情->回到安歇室安歇这样的大略循环状态动画状态切换，如在UE动画蓝图和UnityAnimator中的表示办法大家再熟习不过的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的事情，这样组织的效率得到了提升，而对付寻求进步的人都可以得到个人的发展，而不是在重复的事情中变得麻木而失落去激情亲切。
所有人类的创造，无论是详细的事物还是组织，都遵照着这样一个过程。它起初只是一个想法，这个想法在不断塑形，不断向外传播，不断变得更加详细，从而能号召更多的人，在一遍一遍这样的循环中，终极积累到足够的让自己出身的力量。这个是个令人着迷的过程，像极了基督教里说的道成肉身。如果我们依然相信人类的创造，那让就我们尊重这个成长的过程，并给予圣子降临的土壤，直到有一天，大概有一天，我们的创造再也不直接依赖人的思考。
