小眼游戏架构：UI篇：系统功能（新手引导）

admin管理员组

文章数量:1657451

前言

这个引导它又臭又长，就像这面。。。
说实话我本人也很讨厌新手引导，感觉把玩家当成弱智一样，什么都要交，比ta妈还要对ta好。
关键是程序不想做妈啊，一个游戏不改个三到五次的新手引导，你好意思上线么？我知道的就有改十多次的，真的吐了老血。

程序做新手引导就是被策划虐，动不动就要改：

1. 引导流程太长了，怕玩家烦，你们程序改；
2. 引导流程太短了，怕玩家看不懂，你们程序改；
3. 好不容易不长不短，相应的功能点改了，你们程序改；
4. 这个引导特殊处理下，和原系统流程分开，你们程序改；
5. 这个引导样式放在这里不好看，你们程序改；

被程序虐完又被美术虐。我改还不行吗？不行！

接下来我们将实现一套：

1. 程序提供环境；
2. 策划配置流程；
3. 美术控制显示；

将程序从这个泥潭中解救出来，以上的问题就变成了：

1. 引导流程太长了，怕玩家烦，你们策划自己改表；
2. 引导流程太短了，怕玩家看不懂，你们策划自己改表；
3. 好不容易不长不短，相应的功能点改了，你们策划自己改表；
4. 这个引导特殊处理下，和原系统流程分开，你们策划自己改表；
5. 这个引导样式放在这里不好看，你们美术自己改UI；

引导效果和配置

实现上面步骤需要的配置如下（应该开放出去让策划配置）：

看了以上的两张图，你是不是有很多疑问？没关系，接下来我会一一说明。

我们分两个部分来说明：流程控制和表现控制。

1. 流程控制：控制新手引导的流程，每一步具体该做什么。
2. 表现控制：每一步引导的时候应该如果去表现。

流程控制

新手流程既然是流程那么，就应该按照我们的规定顺序执行下去，所以需要一个控制器。
有了控制器，怎么绑定将新手引导绑定到现有的功能上？

1. 注入写法：在每个功能点处增加代码，去执行相应的引导，这样的话，实现起来主要注意当前的页面逻辑，尤其是要消息异步的操作，比如等待消息返回，等待界面打开，才能做的一些引导。
2. 事件写法：引导触发的事件和引导完成的事件，我们主要的工作的开发这两种类型的事件。事件触发：比如界面打开，收到具体消息（功能开放、等级达到…）。事件完成：点击，拖拽等等。后面策划基于我们提供的事件类型想怎么改，他们自己改，随便他们玩！

新手引导流程：

图解释：

1. 图中是一个引导流程；
2. 引导流程分为四步，其中第三步是关键步骤，关键步骤完成之后引导就已经完成了，后续步骤时客户端表现。
3. 引导中的步骤很大情况下是在各个UI中；

从上图中我们能发现设计的核心在哪里么？

1. 新手流程怎么被触发的？
   我们需要一个触发事件，监听这个事件，一旦触发，我们就开启引导：比如界面打开，收到具体消息（功能开放、等级达到…），因此我们的重点就是触发机制的设计；
2. 新手流程怎么被完成的？
   引导流程通过关键步骤被分成了客户端流程和服务器流程，在关键步骤完成时我们发送消息给服务器，说引导已经完成，后续的步骤只是客户端自己在跑。如果是在关键步骤之前中断流程，那么引导会重新开始。

以上就是需求的分析，接下来我们来实现。
流程图分析：

根据上图我们做以下分析：

1. 怎么让步骤一步步的执行下去？
   我们需要在当前的引导步骤时，保存下一步的引导，这样，上一步完成之后就会直接开始下一步了。如果不这样设计，你将没有办法保证关键步骤之后的引导的触发时机：引导服务器看来已经完成，这个时候你必须不依赖服务器数据，这样设计的代价太大，没必要在关键步骤之前依赖服务器数据，关键步骤之后，使用自己保存的数据。
   
2. 事件如何开启？
   因为我们的设计是被动的，我并不知道什么时候引导就开始了，所以这里需要外部通知：比如界面打开。这样界面打开之后我们就能通知开启引导了。
   
3. 事件如何完成？
   想要事件完成，首先得注册事件，根据返回去完成引导步骤。
   
   上图设计了两个完成事件：点击完成（红色）和收到特定的消息完成（绿色）。
   通过注册事件的回调，做响应的事情，可以看出完成引导步骤的事件注册很简单，那么后续扩展起来就非常容易了。
   这里面有一个问题：就是上面代码AddTopClick所做的事情。
   因为我们是按照事件的触发从而触发的引导，那么如果一个事件同时被打开引导步骤（eg：界面打开）和关闭引导步骤（eg：点击回调）同时注册，这是很常见的，在我们在我们关闭界面之后会立马打开一个新的界面，这时也会触发点击。两件事件一起做，就会出现冲突，因为先后的触发的问题。这时我必须能保证：先响应完成引导步骤的事件，再去响应打开引导步骤的事情。那么我们就需要将完成引导的事件放入事件列表的最前端：也就是AddTopClick做的事情。
   AddTopClick的实现逻辑如下（让当前注册的事件最先响应）：
   

流程的分析到这里就结束了，接下来我们来说说引导的显示部分。

显示控制

我们需要实现两点：

1. 点击事件的屏蔽：只能操作当前引导的功能点；
2. 引导部分的显示特殊化：高亮显示、特效加持和动画表现等等

先放一张图：

图分析：

1. 图中有两个Camera：Camera和CameraTop；
2. Camera的层级比CameraTop低；

怎么屏蔽点击事件？

因为在操作的过程中我们只能操作引导的功能，我们只需要关闭上图中Camera中的UICamera事件组件就行了，因为当前引导功能（singleButton）已经被设置成CameraTop能看到的层中，所以能够响应事件。

UI怎么自定义显示？

因为我们新做了一个UI：uipanel_tut，这个UI会在新手引导阶段一直存在，就是为了给美术自定义用的；比如美术在里面放置一个动画节点，在配置表中，选择相应的表现就行了。

注意事项

1. 节点层级设置问题：设置层级的时候必须增加一个UIPanel，不然你设置之后，也会别还原的，原因如下：NGUI里面以UIPane作为层级的更新。
   
2. 如何避免条件引导：如果新手引导会改变系统原有的功能，最好的做法不是特殊判断，而是补全条件：比如我们有一个装备升级的引导，可能引导出现的时候会出现材料不足的情况，我们可能会这样去写：引导阶段，不扣材料，这样服务器和客户端都要改，太耦合，后期也修改起来也麻烦。我们可以这样想：引导开启的时候补全功能需要的材料，这样升级引导就不会因为各种原因导致材料不足而卡住了。而且客户端、服务器和策划皆大欢喜。为啥策划也会开心：因为如果后期要跳过新手引导，引导需要的条件（材料、等级、成就等等）全部都会给玩家，这样就不需要再特殊设计了，跳过的流程就会和手动跑流程一样了。
3. 特殊引导的设计：这个就是我要说的大坑了，比如：装备升级，一般情况下，都是一件件去升级，当时策划说我们在新手引导的时候需要一键将所有部位全部升级，这样在点击按钮的时候，就需要特殊判断了：新手阶段发送一键升级消息，其他发送单件升级消息，这样很明显就违反了我们的设计原则，尽量不要在原有的系统功能里面做新手引导的逻辑处理，不然后期修改了系统功能，新手引导也得改。出现这个问题的原因就是：新手引导需要发送特殊消息。实现：在新手引导开始的时候屏蔽单件升级的事件，增加一键升级的事件，这样在点击按钮的时候就变成了一键升级了，这样也不需要改动其他其他。因为这套方案的设计原则是事件触发和完成，所以不管多特殊的引导，都可以通过这样的方式解决。后期程序最主要的功能就是开发新类型的事件了，比如装备升级时替换完成消息的事件类型（后期再遇到这样的替换消息就能直接使用了）。
4. 点击事件屏蔽的问题：因为在新手引导阶段，除了引导功能的可操作外其他的事件都是被屏蔽掉的。正常情况下，屏蔽之后都会解除屏蔽，关键是如果不正常，你的屏蔽没有解除，整个界面就没有办法点击了，这个没有什么解决办法，只能检查自己的逻辑，做各种异常处理。
5. 服务器和客户端同步问题：比如升级装备时：你需要发送两条消息：升级装备和完成引导。你如何确保这两条消息都会发送成功?你能确保服务器都能处理成功？还是保证消息返回时你能全部收到？弱网环境和断线重连时有没有做相应的处理？，如果上述条件你不能保证就会出现问题，造成的后果是这个账后可能就没有办法使用了。比如前一个条件是获得一件装备，后面还有一个引导是拿着这件装备去升级，但是你在获取装备的时候，引导过去了，进入了装备升级引导，但是并没有过得装备，这个时候你就卡死了。 解决方法：我们前面说过一部分，就是引导的条件在引导前全部满足，引导之间的进行解耦，每个引导前都会给与当前引导需要的条件，这样在装备升级的时候，如果没有装备， 就会给一件装备，后续的引导也不会卡死。
6. 手机性能差：在游戏的某个点，突然卡主，导致加载卸载，显示的不正常，一般情况下，你可以退出再进，刷新一下就好了，但是引导阶段是没有办法这样操作的，所以新手引导对手机的异常处理更加严格，不过这类的问题在下线再上都会等到解决。

至此新手引导的相关就全部说完了。程序设计功能的时候：换位思考一下，别人设计出来的功能，你会不会去用？用的开不开心？如果你设计的功能被后人维护，ta会不会骂你？

项目地址：https://github/xiaoyanxiansheng/SmallEyeGame

本文标签： 小眼架构新手功能系统