新手引导系统设计与编辑器设计(二)

在我们项目的实际检验中， 发现了一些简单的问题。

之前我把功能设计的很灵活， 但是使用起来，可能需要去考虑一些东西。

比如下面这个场景：

我需要玩家去 拖拽我们游戏中的3d建筑， 但是玩家又不能去操作UI。 在这种场景下， 如果项目是接管了 unity的原生的全部事件系统， 做这个东西可能会简单很多， 如果没有接管过来， 而且也没有一个输入的简单管理类的话。 估计你就写一些特别伤感了代码了。 我们的游戏有一个简单的Input的管理器， 但是只是管理 部分事件， 不包括UI的事件，因为UI的事件是由ugui管着的。 所以在这里， 策划可能需要配置， 1. 关闭UI输入事件。 2. 如果上一部关闭了禁止建筑操作的节点， 那么也需要在这里开启。 3. 如果下一步需要开启UI事件，屏蔽建筑点击事件， 那么我在下一步需要配置 开启UI输入事件 和 建筑点击事件 这么来看的话。 节点的自由组合是特别的灵活， 但是组合比较繁琐， 如果不小心遗漏东西的话， 就很容易出现BUG， 而且还不好复现。

所以在架构中， 引用了公共节点这种概念： 公共节点由一个脚本持有， 是脚本的所有的步骤的共有节点。 每当我要进行一个step的时候， 那么我就需要把公共节点执行一次。

引入了公共节点之后， 在每个脚本中， 我初始加入3个公共节点： 1. 关闭UI输入 2. 关闭摄像机操作 3. 关闭建筑点击。。。 等等 所有影响新手引导流程的输入源。 然后在每一个步骤中， 我需要什么输入源， 那么我就开启什么输入源， 这样就不会有输入源忘记关闭或者遗漏，导致点穿的情况出现。

为了优化使用者体验， 我们可以对一些显而易见的节点做特殊的优化， 比如某个节点是让玩家点击某个UI元素， 那么我们可以在代码中显示的直接打开UI输入， 同时在编辑器的显示中提示策划，这个节点会打开UI输入源。 某个节点是让玩家点击某个建筑， 那么我们可以在代码中直接打开建筑点击输入等等。 。 这样既节省了策划使用编辑器编辑的时间，也节省了我看他们制作的脚本的时间。毕竟检测某个步骤的输入源是否正确的关闭，这种事情还是很费时间的， 而且不好进行测试。

所以有些时候，给与一些善意的限制，其实感觉是有必要的。 只是这个怎么去寻找，需要靠实际经验去检验。

最后再谈谈我一直比较介意的这套系统的一个问题， 就是反射用的比较多。

反射用的多，在编辑模式下，我其实不是特别在意的。 因为编辑模式，效率再慢，也只是策划体验，而且PC机，一般情况下也不会特别慢。 主要是在运行时的时候， 当新手引导逻辑根据存储好的键值对，使用反射反序列到游戏实例上， 我觉得这个特别消耗效率。

现在有2个解决方案去解决这个问题：

1. 第一个解决方案： 我们游戏的Node的种类是有限的， 就算Node种类再多， 应该也就不到100种。 我们对每种Node再反射完成之后， 记录好它的反射结构， 下次需要的时候，直接拿反射好的结构去赋值。这样能解决部分问题。

2. 动态生成代码的形式生成新手引导的C#初始化代码。 但是很不好的体验就是每次一进行修改， 就会有编译行为产生。

2. 使用脚本语言， 动态生成脚本语言的代码。如果使用脚本语言， 那么数据就没有类型转换一说， 直接进行赋值了。所以也能绕过去。 比如使用lua。