时间：2024-05-01 12:54:24
优化排版，控制复合结构的折叠和展开，提供大量字段的搜索功能，控制每个字段的类型和取值范围，提供交互逻辑和友好的提示，显示或隐藏控件可以在范围内显示或隐藏引擎，考虑合法性或相关性支持拖拽操作，并提供搜索功能借助参数面板配置和隐藏配置安全性大大提高，参数面板序列化也比较友好，所以经常可以在不打开引擎的情况下编辑相关配置文件，使比较和合并时的操作更加容易。但参数面板也存在一些问题：
大量字段可能难以导航，并且不方便查看和比较大量数据。参数面板主要适用于编辑可以轻松扩展为树并且没有复杂引用的数据结构。简单的键值映射、列表、字典等关系。
大家都爱Odin Inspector 1.3. 表格表格是一种典型的基于键对值进行索引的结构，但由于显示限制，只能直观地显示二维表格。表的优点是：
使用单键或双键索引值非常直观。嵌套使用时，它们具有非常强大的描述能力，并方便批量预览。它附带了一组免费工具，例如Excel 和Google Sheets。虽然它在绘图格式、数据过滤、公式计算、函数开发等方面具有非常强大的功能和扩展性，但表格也存在很多问题，例如：
配置格式要求高度统一不适合支持多态数据，容易增加数据和操作冗余例如，根据B字段的配置启用A字段，则设置不会体现出来难度极高表内的依赖关系仅在少数情况下使用的字段必须占据表中的一列，并且不能增量扩展对于多级结构，不能嵌套对于编辑数组和字典字段很有用列较多时难以导航编辑器和编辑环境往往不足分离，即Excel本身集成了格式化、公式、导出比较和合并使得原始表格文件在多人协作时难以使用大多数情况下，Excel源文件中的数据无法直接使用系列迭代如果您遵循描述大量简单内容的二维表，以及可以通过简单的一维或二维键值映射完全描述的数据，则过程可能会变得乏味。非常适合。如果超出此范围并且您希望继续使用该表格，请
将多个级别的数据强制放入二维表会使导航变得困难，因为配置字段是冗余的并且多个表是嵌套的。一旦上述组织方法开始在您的项目中流行，您将看到编辑表格的效率有所提高。减少。
WatchDog2 的NPC 压力计有800 列，很难匹配1.4. 时间轴时间轴是用来精确调整时间的工具，能够快速预览准确时刻的状态。它必须适应Windows 的用途。按照Unity 时间线术语，时间线包含多个轨道，您可以在其中加载事件和剪辑。事件对应于时间点，剪辑标记从开始时间到结束时间的持续时间。所有这些仅用于说明目的。逻辑被触发的时间。虽然现在商业引擎中已经常见了Unreal的Sequence、Unity的Timeline等相对成熟的时间轴工具，但在很多现实项目中仍然存在定制时间轴的需求。时间线的优点
时间线的常见问题，您可以直观地看到事件发生的时间以及各种事件的顺序
由于与性能强相关，很可能会涉及到逻辑和性能的配合，并且配合需求比较大，但一般时间线编辑后保存的数据格式比较复杂，导致对比工作比较困难合并有点繁琐，协作不太好（可以在Unreal中合理设计嵌套规则解决），但适合用时间线工具编辑的业务
《动作打击》需要在逻辑间隔（如无敌帧、霸王帧）精确的进行攻击检测、特效、音效和过场动画的计时，以配合角色的移动和镜头的定位。我需要快速预览的关系。调整动作节奏以适应场景和角色
官方Unity Timeline教程1.5的截图曲线时间轴工具的另一个版本是曲线编辑器。曲线主要描述两个值之间的映射关系并绘制值的变化。如果输入值是时间，则曲线可以是时间轴的一部分。曲线主要适用于难以准确、定量地描述变化过程的情况，例如：
角色上某些逻辑挂点的位置是如何根据动画而变化的？摄像机的一些参数是如何根据角色的动作而变化的？实际开发过程中经常会进行调整，尤其是与角色相关性较强的区域表现。要求是这样的，“我希望这里有更多这样的东西。”使用数字来拟合此类描述效率非常低，因此曲线工具有助于更有效地解决此类问题。
Unreal 的曲线编辑器1.6. 节点图近年来，通过节点图来描述逻辑已经变得很流行。节点图是由节点和链接组成的结构，它们可能具有不同的含义。节点图的特点如下。
直观、易上手对节点类型、管脚类型、连接数的限制可严可宽可适应各种业务类型通过编辑器嵌套链接可以实现更复杂的逻辑断点等执行操作，高迭代效率缺点：
信息密度低，逻辑复杂，维护起来非常困难节点数量较多时，会导致渲染效率问题节点图需要从编辑器转换为运行时数据，物理上不方便，因为它经常过渡到鼠标和键盘交互，但如果设计得当，它可以提供直观的编辑方法。结合适当的事件和变量机制，可以显着提高开发效率。下面介绍一些不同的节点图类型。 1.6.1. 流是一个节点图，使用节点表示执行逻辑，使用连接表示数据流和执行顺序。常见的流程节点图包括Unreal的蓝图和材质编辑器。流与其他节点图相比的特点是：
节点类型自由，可以表达数据和逻辑，也可以使用顺序节点、四环节点等过程控制节点，引脚数和连接类型也可以自由，允许以网状结构连接。输出关系和不同的执行顺序，用于表达结构，擅长表达结构，适合流式编辑的典型内容包括：
FlowCanvas 1.6.2 的Flow Editor 树是Unity 的流行插件，它使用节点来组织复杂业务的逻辑，包括数据和执行流程的混合，例如关卡流程、技能流程、交互式流程功能和可重用的逻辑片段等表达。它是一种特殊的节点图，其连接代表数据单元及其隶属关系。典型的例子包括Unreal的行为树和状态树。树的结构比流更强。
必须严格按照树形结构进行扩展。每个子节点都有一个唯一的父节点和一个根节点。连接用于指示节点之间的父子关系。当涉及执行时，以下导航方法（一般来说，成功和失败）需要在运行时在树中指定导航方法（例如，在行为树中，不能显式使用Composite 节点）。父节点下执行子节点的规则，以及从父状态进入和退出子状态的规则，通过主动中断或装饰器类型节点控制UE状态树的中断。从以上特征中，我们还可以找到适合树表示的业务特征。
其特点是逐级细化，支持多分支，末端有多个出口。例如，交互树集成了人工智能行为树和决策树等导航逻辑。
Just Cause 3 的NPC 行为树，典型的嵌套父子树结构1.6.3. 状态机状态机是一个图，其中节点代表状态，连接代表跳转关系。
Unity AnimatorUnreal Logic Driver插件状态机图具有以下特点：
节点代表状态，连接用来表示状态之间的跳转关系。每个跳转都有相应的图形连接表示，因此创建、预览和编辑跳转非常直观。状态机的优点也非常明显：不像流和树，它们可以同时运行多层和多个节点，除非状态需要共存。
这适合表达多个互斥的状态以及它们之间的跳转关系。当您可以编辑跳转而不添加状态以更仔细地自定义多个状态之间的流关系时，它特别有用。例如，如果有状态A 和状态B，则状态A 具有子状态A1 和A2，所有子状态都可以跳转到B。如果你想触发从A1到B的某个逻辑，而不是从A2到B，这样的东西在你的状态机里就只需要添加一个跳转来表示即可，这是比其他图简单直接的多.你可以根据某些函数的状态轻松控制它们的生命周期。例如，当一个单元处于碰撞状态时，关闭边缘保护（即）。边缘被击落）适合使用状态机的业务包括：
交互对象（门、宝箱、具有特定ID 的NPC、其他AI 状态等）通常，游戏AI 的顶层是由互斥状态（如待机、搜索、战斗和关卡指令）来完成的。还有一些方法可以表达更具体的运动状态，比如简单的循环状态如在休息室休息-走到工作室上班-返回休息室休息，以及切换动画状态。大家都熟悉UE动画蓝图和UnityAnimator，最著名的UnityAnimator典型状态机1.7.公式公式是一种专门的构造类型，专门进行数值运算。公式很少用作单独的编辑形式。主要原因有：
大多数游戏没有非常复杂的数值过程。大多数数字设置都用表达式中保留位置的参数填充。简单的公式往往可以直接从执行流程中组合出来，比如UE Blueprints提供的数学节点，提供的计算方案，比如Excel自带的公式，已经可以满足你的需求了，但在实际开发中，这种情况并不少见需要依赖更复杂的数值计算，例如：
UE5中引入的StateTree实际上是表示为树结构的状态机。您可以在UE 蓝图中编写数学函数。它实际上是公式曲线编辑器保存的实际结果的流表示。相当于公式。它们通常显示相同的内容，但以不同的格式编写。几乎所有的配置方法只要在逻辑上是同质的，就可以相互转换。这种兼容性导致了工具开发的两种不同思路：一是保证工具的统一性，用相同的构成方法来描述尽可能多的结构。规划需求虽然工具集小，项目稳定性高，但是不可避免的会有很多数据无法直观的设置，执行端的损失会比较大，未来扩展的负担也会很大。其次，通过尽可能确保设置的便利性并为每个任务提供直观的编辑方法，工具开发的工时将增加，规划将需要使用许多工具集。虽然提高了效率，但前期需要较高的工程开发成本，并且还需要一定的规划学习成本。这里的便利实际上并不意味着稳定性差。正确的工具将提供足够的错误检查机制，以减少格式错误并使其对规划者更加友好。在实际开发中，每个项目都会在这两种想法之间进行权衡。应用两个简单的轴，一个是硬开发与硬规划的问题，另一个是保持短期稳定性和效率与长期灵活性和可扩展性的问题。这是关于维护它。行业早期的项目倾向于跨工具的统一，因为当时的项目相对较小，复杂性也相对较低，但随着表格工具的成熟，很多项目都会使用使用Excel搭建规划配置环境。 Excel本来就很强大，但如果不是的话，对于小型项目来说VBA基本上就够用了。因此，很多规划工具和技能也是围绕Excel展开的。但相应的问题是，当你手里有锤子时，一切看起来都像钉子。结果就是在Excel中配置了大量衍生的技能、对话框、关卡等，涉及高度复杂的流程，需要层层嵌套才能完成，且难以维护。与此非常接近的另一个想法是我之前提到的，即如果可以的话使用文本。常用的文本编辑器提供更方便的文件到文件导航、全局搜索、批量修改，并且可能需要更长的时间来开发用于规划学习项目的文本格式，一旦掌握它，它就像Excel一样高效。那么，当一个简单的工具链就足够了的时候，为什么还要开发一个复杂的工具呢？既然只要逻辑同构就可以用任何配置形式来表达，如果规划者仔细想一想，是不是不管怎样都一样你使用什么样的配置格式？行动前三思而后行难道不是计划者的工作吗？虽然理论上如此，但实际情况可能并不那么理想。因为在现实中，很多计划都没有经过深思熟虑，至少在初期是这样。一个项目永远不会从如何做的清晰想法开始。因此，在开发中需要时间来理解需求，而在规划中则需要时间将需求想清楚。最重要的是，我做过研发的朋友意见很广泛，而且实际上是最花时间思考清楚的。因此，提高开发效率的一个关键途径在于如何帮助大家更快、更清晰地思考，而这正是综合工具集的好处。
例如，如果您拥有的只是一个表格工具，那么从中抽象出状态机并手动在两种格式之间进行转换并不是特别容易。如果你雇佣了一个新人并要求他理解，这一点尤其正确。从头开始创建这种配置结构将非常昂贵。相比之下，如果面对一个已经有相应图形界面的状态机，你可以指向一个节点说这是一个状态，指向一个连接说这是一个跳转，就可以简化集合直觉。可以建立在。关于状态机。此外，如果状态机编辑器是可重用的，则相应的运行时也可以重用，从而无需每次根据您的规划需求重新抽象近似函数。当然，如果工具集很复杂并且支持相互嵌套，那么可能会导致运行时的性能问题，并且经常触及一些技术专家的雷区。执行效率，尤其是后端的执行效率是一个不容忽视的问题，但优化工作也需要性价比的计算。优化的本质是让人类解决更多的问题，让机器解决更少的问题，实际上将运营成本转嫁到开发上。因此最终的计算结果就是增加多少额外的开发成本来节省运行时间成本。尤其是为了保证运行效率，开发流程变得更加复杂，人际沟通的损耗增加，开发效率受到影响，可能会弊大于利。此外，通过适当的规划，可以避免过于复杂的嵌套。下面说一下配置格式的相互转换。当项目的工具集变得复杂时，您如何决定在使用时将哪些格式配置应用于哪些内容？答案是只有孩子才能做出选择；成年人才能做出所有决定。这意味着您想要它。 UE的PropertyMatrix提供了一个很好的例子。这本质上是一个表格工具，可以在二维表格中并排显示来自不同对象的不同字段，并提供很大一部分表格编辑体验。例如，您可以方便地比较多个条目中同一字段的值。编辑后仍保存在原文件中。
UE的PropertyMatrix 因此，实际的编辑需求是从不同的角度产生的。如果一个工具集能够提供多视角的编辑体验，则有助于提高开发效率。当然，每个项目都有其独特的情况，但我这里所说的主要是那些由大团队开发、上线后长期运行的项目。从长远来看，它更具成本效益。 3.我们谈到了编辑器的未来，但是编辑器的本质功能是什么？这是我的答案。）是一套翻译工具，用于翻译成.这部分数据需要特定的格式，编辑器可以轻松创建符合该格式的内容。然而，该翻译器可以执行的任务非常有限。生成的内容只能在游戏运行时支持读写，而事实上大部分翻译都是由人类自己完成的。例如，我使用流程来编辑我的技能。开发环境需要技能描述。同时，该项目还要求玩家提供一份技能描述。该副本包括各种多语言版本。这三块数据实际上描述的是同一个东西，开发者必须将其转换成三块不同格式的数据并存储在项目内的不同位置。如果一个位置发生变化，其他位置必须做出相应响应。再举个例子，规划人员编写需求，程序相应地开发功能。该程序必须向代码添加注释并在项目知识库中编写功能的实现。规划者还应该：在配置文件中维护用户文档。现在，您可以将需求+功能代码+配置文件+用户手册视为最终一起编写相同的东西，但它已经以不同的角度和粒度翻译了很多次。那么，我们是否可以希望出现一种翻译工具，可以在自然语言描述要求和符合该格式的游戏数据之间任意转换，从而节省在不同格式之间来回翻译的时间呢？简单地说，我们是否可以期待具有多模态能力的工具？ 在这一点上，很自然地会想到生成式人工智能。现阶段，仍然有充分的理由怀疑人工智能是否可以完成原创者的工作，但如果你已经有了符合你的设计要求和格式规范的内容，人工智能工具可以为你转换它。我很期待到它。这似乎并不那么难以捉摸。他不需要知道A为什么存在，但他确实知道A=B。换句话说，我们的工具不需要理解什么是理念，只要认识到不同的形式可以表达同一个理念就足够了（顺便说一句，柏拉图哲学中理念的希腊语是Eidos，实际上这就是Eidos）袭击者。初始开发者名称）。例如，创建任务时，必然要考虑情节大纲、剧本、对话和表演结构、任务结构等。虽然每个链接提供的内容和侧重点不同，实际上也不同，但背后的逻辑却非常相似。你能想象在一个工具的合理协助下，你只需要对其中的一部分给出充分的解释，而另一部分最初就可以由工具完成一半以上吗？在工作流中，数据流是单向的，下游的问题通常会反馈给上游进行纠正。
因为这些中间环节很多传递出来的结果其实依赖于同一套统一的描述，所以即使我直接下游修改，也可以直接同步到上游，你能想象吗？乍一看，但归根结底，从一般的角度来看，工作流程简单而稳定，将灵活性和调整留给了人类。仔细想想，这是一个合理的想法。然而，并不能保证人类组织总是比程序更灵活，而且人类组织的效率远远超过程序，尤其是当它们规模扩大时。因此，前瞻性的开发方式是优化工具、培养人才，帮助个人完成更多的工作，而不是定制组织层面的流程，让更多的人协作，我认为是可以做到的。如果把原本属于上下游的任务整合为一个，即使上下游之间存在复杂的交互，也成为个体决策范围内的事情，不存在沟通或协作的损失。在这里我们看到，提高个人效率和缩小组织规模可以相辅相成。如果技术进步不那么快又怎样？如果下一个产品周期（大约3-5年）继续由人类设计，以技术作为辅助生产手段，更好的规划又如何能期待一个导向性的游戏编辑环境？以下几点可能会有所帮助
改进的类型定义可以更有效地区分不同类型的数据。游戏引擎对艺术中使用的数据类型进行了清晰的分类，例如模型、材质、纹理、动画和灯光。另一方面，在规划程序时，IDE会严格帮助程序区分不同的数据类型，无论它们是什么。表格数据是一个单元格，即使引用类型是ID，自然也更容易出错。商业引擎编辑器一般都提供稳定的类型约束控制，但是拖拽操作减少人工错误还是值得学习的。更好的导航。目前大多数人类产品都提供基本的导航功能，例如后退和前进。 Web浏览器、APP和IDE都是可能的，但规划工作环境会发生很大的变化。我们经常需要在多个不同类型的文件、多个不同的窗口、甚至多个独立的软件之间切换。其中每一个都是独立的。在环境中移动变成了一项纯粹消耗能量的任务。拥有一个一站式入口点，通过简单地在子窗口之间切换并快速跳转到外部引用的内容来全面查看正在编辑的所有内容，通常可以减轻编辑人员的精神负担。使验证过程尽可能短。完成内容编辑后，您可以在最短的时间内看到编辑的效果。如果您无法减少发布校验和值所需的时间，请提供一种绕过验证的方法。如果您无法减少每次启动游戏所需的时间，我们将提供一种无需重新启动即可检查您的更改是否生效的方法。游戏。人类的注意力是极其宝贵的资源，一旦失去就很难重新获得。让文件管理尽可能简单。一些编辑器工具在基本编辑测试期间提供了相对友好的交互，但在编辑器UI 的背后，实际的
际操作的内容可能非常复杂，导致策划在提交的时候总是不确定哪些是自己有意的修改，哪些是自己无意动到的，或者编辑器的隐含规则操作到，实际上需要提交的。如果编辑器操作和实际修改的文件之间的映射规则简单直观，那么用户也会花更少的时间甄选自己的实际的工作。实际上，上述这些特性对于任意一款商业引擎而言都是交互体验的及格线，因此对于一个熟悉引擎基础功能的朋友，都会觉得拿原生功能做个Demo不是什么困难的事情。然而遗憾的是，大家总觉得做Demo的方法未必能够直接做项目，做项目总需要一些额外的条条框框，这些条条框框当然能够提升项目的稳定性，但是如果没有经过足够好的修饰，它们也会对效率造成不必要的损害。那么，为什么不能像做Demo一样做项目呢？明明不是那么难以做到的事情，为什么效率和稳定不能全都要呢？最后再借题发挥一下。表面上看，编辑器和工作流的问题，处理的是每一项开发业务到对应的工具链的映射，是一个静态的问题；但是实际上这更是一个如何理解人和组织的问题，是一个面向有发生与发展过程的动态的问题。前面提到过，所有的想法都不是一蹴而就的。想清楚需要时间，传达想法需要时间，执行想法也需要时间，而人和组织的都是有限的。编辑器和工作流通过提高个人的效率，可以在单位时间内做到更多的事情。更重要的是，效率提高意味着试错成本降低，一些失败的探索变得可以承担，也不会过度挫伤团队的信任和积极性。毕竟一个团队最不容透支的是士气。此外，更高的效率意味着更多的试错机会，更意味着一套在错误中学习和自我纠正的机制有存在的空间，以及旁逸斜出的想法有机会得到验证与支持。做过游戏设计的都知道，一个好结果，尤其是可持续的好结果，都不应该依靠某次灵光乍现，而是靠一个拥有可靠的反馈循环的系统，在一次一次迭代中渐进地产生的。工具的进步，实际上给了组织机会，来形成这样的反馈循环的机制。念在国内大多是在做长线运营的项目，除了关注项目是怎么做出来的，也要关注他该怎么继续做下去。目前许多的大型项目，是通过建立流程，让20个专业不同的人得以协作，然而这些人可能一进来就被困死在这个1/20的空间里，而且充满了互相损耗。而我们期望的更好的流程，是给这些大家各自发展的空间，比如渐渐地覆盖5/20的工作，这样组织的效率得到了提升，而对于寻求进步的人都可以得到个人的发展，而不是在重复的工作中变得麻木而失去热情。所有人类的创造，无论是具体的事物还是组织，都遵循着这样一个过程。它起初只是一个想法，这个想法在不断塑形，不断向外传播，不断变得更加具体，从而能号召更多的人，在一遍一遍这样的循环中，最终积累到足够的让自己诞生的力量。这个是个令人着迷的过程，像极了基督教里说的道成肉身。如果我们依然相信人类的创造，那让就我们尊重这个生长的过程，并给予圣子降临的土壤，直到有一天，也许有一天，我们的创造再也不直接依赖人的思考。