在游戏开发中的，新手引导法式部门如何设计？

随风飘向何处

在目前的工作中，比来在开发新手引导，遇见了各种让本身蛋疼的问题，本身越做到后面越感觉本身的新手引导法式部门做的乱起八糟。

mjp004

新手引导一般分成两大块，第一块是专门的新手引导游戏场，还有一种引导就是引导操作;
做专门的新手引导的游戏场，这个和做普通的场是一样的。做一些情节的介绍等。还有一些就是第一次引导操作，一般的会判断一下是否已经做完新手引导，如果没有，就开始，一般都是用弹出式界面的一个介绍，比如介绍某个按钮，搞一个黑色的半透mask,周边有说明文字，同时复制一个同一个按钮改上面，作为新手引导的第一次点击，让”事件”看上去穿透。再派送一个下面同样的按钮事件就可以了。具体的可以根据新手引导的具体需求去设计。不一定，没有死的方式。

lihao0522

最近刚好完成一个 U3D 端游大厅部分的新手引导，聊聊我的思路(￣.￣)
<hr/>从一开始拿到那个长得不行的新手流程设计文档，我就知道，完全用 C# 代码来写的话迟早药丸（主要是新手引导代码这样跳过来那样跳过去，可读性很差，后期维护时直接看 C# 脚本的话肯定要疯），所以一开始就定好了基调，必须是 C# 提供接口， xml 来配置，后面所有设计都是围绕“可配置”这个核心来进行。
<hr/>先将整个连续的新手引导流程，从逻辑上划分成一个一个引导节点，一个节点是一段连续的、不可再拆分的引导步骤（如从进入商店界面开始，到引导购买物品结束的全过程），然后给每个引导节点分配一个数字 ID，服务端那边再提供一个存储引导 ID 表的功能，客户端每完成一个引导节点，向服务端表写入一个 ID，这样即使玩家中途退出，只要在下次登录时主动请求这个表数据，也能知道玩家的新手引导走到了哪一步。
<hr/>在 xml 表中，每个引导节点又包含了哪些内容呢？
这部分与策划的具体需求结合得比较紧密，还是具体情况具体分析，我这边是将每个引导节点划分成了四块部分。

• 开始条件
  

即满足了哪些条件就能执行，如
场景名：此节点只能从哪个场景开始执行；
界面状态名：我们项目中是通过一个状态机来管理控制整个 UI 系统，可以去主动查询当前处于哪个状态（哪个界面模块），如只有在商店界面才能启动此引导节点；
玩家等级：玩家必须达到指定等级才能开始此引导；
前置引导节点的 ID：必须先完成给定的引导节点才能开始此引导；
等等。

• 完成条件
  

一般来说只要一个节点正常启动了，一旦所有引导步骤走完，该节点就会被自动标为完成，是用不到完成条件的，完成条件这个东西主要是用在玩家重连时进行一次遍历检测，关掉之前已经完成的节点。具体各种参数大致类似开始条件（如玩家达到了几级，记录了哪一个 ID 就代表完成了这一步引导节点等）。

• 回滚节点
  

一般的引导节点是没有这一部分的，主要用于应付这类的需求：
有一大段逻辑上连续的引导，我们将它划分成多个引导节点，当走到其中一个节点时玩家强退，玩家重连后需要回滚到最开始那个节点重新引导。
举个例子，我们引导玩家去匹配比赛，匹配成功进入游戏，第一个引导节点就完成了（后续的战斗引导和结算引导显然不能和这个匹配引导放在一个节点里），这时玩家强退游戏，然后重连来到主界面，虽然引导匹配的那个节点已经完成过了，但显然我们还需要重新执行这个节点（引导玩家去再次匹配比赛），否则玩家就失去了引导（直到他主动去匹配比赛）。
这里我当时就踩了个坑，一开始没有考虑到这个需求，结果搭框架时，每完成一个引导节点，直接从节点列表里把它给删了。。 后来发现有节点需要重新执行就傻眼了(T＿T)  所以改成每个引导节点都持有一个节点状态（分为：未开始，执行中，已完成），每完成一个节点就把它的状态设为已完成。
回滚节点这部分唯一的参数就是前置节点的 ID ，
当检测发现当前节点的开始条件不满足时，检查前置节点的状态，一旦前置节点处于已完成状态且满足开始条件，就回滚到前置节点重新执行。

• 详细引导步骤
  

由各种引导命令组成，如
<command type="force_click" target_name="/ShopPanel/SkinModule/BuyBtn" />
就是一个强制点击指定控件的命令，前面的 type 是命令名，后面跟着的 target_name 是命令参数。
xml 脚本里只需配这么一句，然后在 C# 脚本里采用命令模式( Command Pattern ) 将这些引导命令都封装成对象（所有命令继承自同一个基类 Command），这样读取 xml 配置表时就可以将所有命令先存起来，等到需要的时候再执行。
因为一个引导节点通常有多步引导命令，一个引导命令又不一定会在一帧内执行完毕（如播放助手语音的命令，等助手说完一段话，不知道过了多少帧），所以每个 Command 也持有一个命令状态（CommandState，同样分为：未开始，执行中，已完成），我们在 Node 节点类里维护一个 Command 命令列表，然后通过 CommandState 来控制命令的顺序执行（前一步 Command 执行完成才会开始下一步）。
<hr/>引导系统执行流程

玩家登录游戏，去向服务器请求引导 ID 表，根据这个 ID 表关掉所有已完成的节点，
开始引导系统的检测流程，在每一帧( Update )检测是否存在哪个引导节点满足了开始条件, 有就启动该步引导（启动一个引导节点即将该节点的状态从未开始转为执行中），
当有节点在执行中时，停止引导系统的检测流程，改为刷新该节点的 OnUpdate 逻辑（引导节点类会在 OnUpdate 函数中逐步执行各个引导命令，直到全部执行完毕，关闭当前节点），
当检测到当前节点执行完成后，又开始新的一轮检测流程。
<hr/>还有很多其他机制，都是视项目需求添加，随便举几个例子：

• 不可逆的引导
  

比如一个商店教学，要先给玩家发金币，然后引导去商店买个物品，如果玩家在发完金币后就强退了，怎么办？下次玩家登录时从哪里开始引导，不可能再给他发一次钱吧。
所以我们会在服务端再存一个奖励 ID 表，在新手引导过程中，每次给玩家发东西都会在服务端存下对应的 ID ，一方面防止重复发放奖励，另一方面客户端能够依据奖励 ID 表知道玩家重连时如何重新引导。

• 系统的顺序开放
  

玩家一级进游戏时只能看到开始游戏这一个功能模块，后续在新手引导流程中再把商店、排行榜等模块一个一个开放给他。
有了引导 ID 表之后，这个实现起来就简单了，只需将 xml 表中玩家开放新系统的那一步骤 ID 单独存入一个列表，可视为不同系统模块均绑定了一个给定 ID，玩家登录游戏时，检查一下引导 ID 表中已经记录了哪些 ID，就知道哪些系统模块已经开放了。
<hr/>就我个人而言，这样设计就已经达到了我之前的想法：即一开始搭好框架后，以后需求变动就只需要改 xml 文档，有新功能需要实现也用加一个引导命令类ヽ(￣▽￣)ﾉ 但新手引导毕竟是一个特别依赖于需求设计的系统，只能说我这样弄刚好满足了我这边的需求，肯定还有很多不足，具体情况具体分析吧，欢迎各位大佬批评指正( • ̀ω•́ )✧

junmeng

做新手之前一定要先弄清楚这些再动手（本来想复制几遍提醒重要的，还是不浪费流量了）
1.游戏是要强制引导（什么都强制，不给点其他的地方），还是弱引导（就是进到模块里面，达到某些条件就触发），还是两者都要，优缺点要先说明好了，别全部做完，几百个账号测试完了再来说改，那就是大坑了（我真遇过这样的策划）。
2.新手引导的游戏时长是多久，短的好说，如果是长的，会不会离谱了，市面上同类型的主流的时间是多长，那样引导会不会烦人，然后如果什么都要引导，是不是考虑修改下功能，因为这样的话体现了这游戏实在太不人性化了，或者你把玩家当傻瓜了。
3.每一步都要策划去游戏里面截图画出来，然后再操作几遍，很多时候策划光靠想象，做出来跟实际的一点都不相符，有时候逻辑都不通的，然后一做完就要改了。
4.每一步的引导的意义，是要引导玩家建造呀，是要穿装备呀什么的，要说出背后的希望引导的东西，不然有时候真的是糊里糊涂的，什么都想要引导。
5.断线，奔溃了，重新进来的时候要怎样引导，模块引导是跳过当前引导呢，还是重新来，但是有时候有的是不可逆的操作，比如金币，一来给了100金币，你花了钱，可是没引导完，这时候如果重新引导肯定钱不够，或者建造建筑，有的可能已经建造了，你要重新造一遍都不行，这时候就要在策划上看有没有对应的方案，比如新手期，钱不管怎么用，都是假用，建造也一样，或者有个标志位保存本地先。
6.步骤的保存，这个肯定得先保存本地（因为网络的原因，肯定会有偶尔会丢失的），然后再发服务器（如果是网游），但是是要一步步同步到服务器呢，还是做完几步在同步，这个你要自己根据项目抉择。
7.一定要做成配置，如果是id来对应每一步的引导的，一定不要全部连续，要空一些出来，不然改动之后id乱糟糟，然后给策划自己去配置
8.新手有什么功能确定好，是手指指东西，还是高亮哪里，是程序来挖空高亮的地方还是美术出图。
再次强调，一定要把上面说的是这些确定之后才动手，然后技术上无非是2种：
一种把游戏剥离出来，做个单机版的游戏，这种的做法就不怕断线，奔溃重新来，因为每一步都记录在了本地，不存在做了，但是没同步到服务器的问题，奔溃了重来或者帮助跳过都很好做。
另一个种只能是嵌入代码的做法，看别人代码头疼，如果前期没有规范好的话（这里心疼你们几秒好了），不过这里细分还是有两种做法的：
（1）一种是非常低耦合的，不过一般是强引导才能用，就只是弄一个遮罩上去，其他的地方全部屏蔽掉，然后按顺序给玩家点，点完跳下一个地方，但是这里有的时候要等待某种callback或者消息才能跳下一步，这个如果前期在做按钮和界面有高层次去统一处理就超级好处理了。
（2）另外就是最糟糕的做法了，哪里要用就去看代码嵌入。
祝大家做完新手还心情愉快吧~

木陵子白

待我先占个坑，明天再来回答
以下是回答：
游戏新手引导老实说我没有自己写过，但看过一些别人写的。在这里和大家交流一下。
不知道题主的游戏是什么类型，策划的新手引导文档是否详细，如果有详细的文档，开发时也比较好做。不同游戏的新手引导开发难度区别很大。如果是只需要点点点的游戏，那按照流程显示按钮设置遮罩让玩家依次点击就行了。按钮的显示顺序和遮罩镂空的大小和位置要可以配置。
如果需要战斗等玩法上的引导就比较费事些。除了如上说的UI层的引导，你通常需要引导玩家的操作，指向，抵达触发点等。一般会专门做一个新手引导关卡。如果游戏运行有状态机概念，引导开启时游戏状态切换到暂停状态，直到完成一个操作再切换回正常状态。如果有任务系统，可以利用任务系统的方位指示。如果你的项目本来就做了编辑地图的工具，那地图上的交互部分应该已经可以配置了。总之，好好利用游戏中已经设计的模块。开发新手引导时应该是其他模块已经比较成熟的时候了，不然也没啥好引导的。
关于代码设计方面，真和你的游戏已经有的架构联系紧密。如果有使用lua，可以利用协程。开启引导的时候挂起协程，完成操作继续执行。lua又能热更新。

qiuhill2000

刚踩过... 我的办法是给main loop做个暂停状态 切暂停然后开始引导 结束切回... 过程还得是数据驱动因为保不齐就中途退出了 嗯 大概这样 有空再详答
不过主要是看你需求 这个实现很难有统一的 你可以参考下wow任务系统的设计
--------------------------------------------------------------------------------------------------------------------------------------------
这里开始是说好详答
--------------------------------------------------------------------------------------------------------------------------------------------
引导设计在游戏里面非常常见，基本都会有以下需求：
1、当游戏运行到某一阶段的时候会触发引导，被触发的引导在完成前不能通过任何手段终止
2、引导运行时，能够根据策划需求只放发引导包含的逻辑，终止或者禁用游戏其他逻辑
3、希望引导能够尽可能的便于修改
然后我大概能想到的方案是：
1、使用配置文件配置游戏元素和所执行逻辑的对应关系，有点像资源索引
2、如果早期架构允许，在游戏轮询中希望引导和正式游戏尽可能是有互斥关系的并行运行。比如Task1为主逻辑，Task2为引导逻辑，那么当启动Task2后，游戏轮询优先执行Task2的逻辑并在Task2结束后继续执行Task1
3、需要一个方法保存任意时刻游戏的数据或者状态，并能恢复运行
其实针对以上每点都有现行方案可以使用。
1、针对逻辑与调用的关系，可以使用lua或者ulua
2、针对状态切换有CPS或Coroutine
---------------------------------------------------------------------------------------------------------------------
具体代码大概类似这样：
使用一个结构去匹配元素和对应的函数


使用结构去做游戏状态的控制流，当然以下只是随便举例


剩下就是如和保存你的运行状态在下次开启游戏时，又能回到之前的。这个根据组织逻辑的不同有不同做法，我上面的例子可以保存调用顺序，然后按顺序重建task栈。当然答主可以使用任何自己觉得合理的方法。
--------------------------------------------------------------------------------------------------------------------------------------------
以上仅供参考，并不是标准答案。代码也没有什么可行性，仅仅提供思路。
如有意见轻喷。