新手引导很多游戏都有。但是有的做的却不是那么如意。有时候引导卡死，却找不到问题。其实很多时候和设计的机制有关。本文假设引导是一种强制性的引导。一个引导由很多步骤（比如要玩家点哪里，点哪里，这些都是一个个步骤）组成。
　　1、引导的发起
　　后端关注的是引导，因此，后端只要各种事件触发一个引导，把这个引导ID发给客户端，就完成了引导的发起。
　　客户端收到服务端发的引导ID，就会获取这个ID对应的步骤列表。然后播放这些步骤，等待玩家交互完成。
　　2、引导的结束
　　当前端执行完引导步骤时，把引导ID通过一个引导完成的协议发送给客户端，这样好吗？我觉得这种做法是不安全的。
　　如果是通过客户端来通知服务端引导完成，会出现2种情况：
　　以强化装备为例子
　　情况1：先请求强化装备，再请求引导完成。
　　可能在你请求强化装备的时候，这个请求发出去了。但是突然断线了，引导的请求没发出。这时候。下次上线，他还是会让你引导。但是，你可能已经没了强化材料。玩家卡死。
　　情况2：先请求引导完成，再请求强化装备。
　　请求引导完成发出，断线，请求强化没发出。然后玩家下次上线，不会再经历引导。
　　或许聪明的你会想到可以把引导ID带在强化装备的包里面，一次请求完成。这样是可以解决上面两种情况。
　　但是，这样，相当于，就把强化装备和引导耦合了。而且，以后可能有升级技能的引导，那么你升级技能的协议也要带上引导ID。这样设计无疑不是最好滴。
　　因此，通过客户端来通知服务端引导完成是不靠谱的。应该由服务端自己的内部事件来触发。
　　比如一个强化装备的引导，客户端最后肯定会请求服务端要强化装备。
　　这时候服务器就可以判断当前是否有强化装备的引导。有的话判断是否满足完成条件。满足就完成引导。
本文已收录于以下专栏：
相关文章推荐
游戏新手引导的制作原理
有人问我，都两年过去了，AS3 Coder系列怎么才出了10篇文章都不到？答案很简单：我TM懒得写！原计划出到10篇就洗手不写了，现在还有最后两篇，加把劲冲刺一下吧！
/post/58.html
使用框架：AS3
任务描述：了解游戏中新手的制作原理及流程
//--------------------------------------------------------------------------------------MyCameraScro...
Milliondollars智力问答游戏，主要的技术要点（一）、读取题库数据xml文件（二）、如何动态的生成题目和选项。这里做个总结，供以后参考。
（一）、读取题库数据xml文件
将assets/...
情况及处理方式
1.重复的表达式
2.不同算法做相同的事
3.类似代码
同一个类的两个函数有相...
关于游戏设计中的新手教程，如果不能适当的介绍游戏，反而可能会成为致命缺点。俗话说得好，no zuo no die。今天我们就来一起盘点一下新手教程中常见问题，希望各位小伙伴们尽量避免。
  ...
好几年以前是偶尔听说过“富客户端”这个词，但后来因为“RIA”这个词出来了，我居然就把RCA给忘记忽略了，真是大意！现在重新来学习一下，也与接下来要做的一个项目接轨。先把架构的图片传上来。
他的最新文章
讲师：王哲涵
讲师：王渊命
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)游戏设计中的新手引导(转)
游戏中的新手引导是帮助玩家快速掌握玩法技巧的一个重要手段，尤其对于新手玩家而言，新手引导的作用更是不言而喻。但是很多游戏设计师把新手引导的
作用扩大化了，企图让玩家通过新手引导能轻松掌握一切。由此导致的后果是：新手引导越来越详细，越来越长，玩家在游戏中主动思考的能力、自主探索的能力也
逐渐降低了。
目前国内很多游戏的新手引导都非常的冗长，最长的甚至有半小时之多，玩家在这半小时之内的心情是烦躁的，忍耐的，坚持的，而且非常容易造成玩家的流
失。例如国内有这样一种比较流行的模式：欢迎来到xxx……
——请点击人物按钮（人物按钮高亮）——请点击升级（升级按钮高亮）——请点击关闭（关闭按钮高亮）……天哪，把玩家当成了什么？玩家被当做弱智儿童一样
手把手的教育怎样操作，甚至中途还有错误反馈：“当前人物不可升级”。为什么这些低级的问题都要亲口告诉玩家呢？玩家不是傻瓜，不希望被如此“教育”，他
们渴望的是主动，是成就感，而这样的引导必然与玩家的心理期望相违背。
那么，新手引导应该遵循怎样的规则才算是成功的、合理的？我想用这样一个词语来概括：无形的指南针。
指南针的作用是帮助人们找到正确的方向，同样，新手引导的作用是帮助玩家掌握正确的操作技巧，两者的作用非常相似，如果要用指南针来形容新手引导，
前边最好再加一个定语：无形的。这好比交互设计中的隐喻，它是无形的，看不见的，就像空气，但它却真实存在，而且有着重要的作用。新手引导做到了无形，会
让玩家感觉不到他的存在，并且在无声无息中轻松掌握玩法。此时，玩家会觉得是自己的聪明才智起了作用。游戏在最初就给了玩家无限的动力与成就感，玩家也有
了莫大的激情与动力，试想，后边的高级玩法，玩家也会更有耐心的去学习了。
具体来说，一个成功的新手引导做到了哪几点就可以称之为无形的指南针了呢？
第一：通过npc对话形式嵌入游戏中。
玩家在这种轻松愉快的对话聊天的形式中逐渐学会游戏玩法。目前好多游戏都是通过这种形式，比如《怪物猎人》，初进游戏时，玩家通过与村长、铁匠等
npc的对话，就像是一个人陌生人在打听村子里的情况一样，生活场景感浓厚，不会感觉突兀。通过对话，玩家逐渐掌握了基本的生存技巧。这种形式的优点是信
息传达详细，准确。缺点是有时候过于罗嗦，对话内容过多，时间过长，不能复现对话内容，对于不能暂时掌握的人来说没有二次学习的机会。
第二：通过触发式分布引导。
对玩家触发的当前操作才给予引导，没有接触的事情先不要说。这样也比较符合玩家心理，我们通常对陌生的事物都一些抵触，也不太会关注，如果事先把所
有事情都教给玩家，势必造成他们的反感与忽略，玩家通常的做法是：“skip”。比如初进RPG游戏的玩家，关注点可能只是走路、跳跃方法，这时候我们不
需要告诉他装备的重要性和操作，只有当玩家打下了一件装备，才会想它的作用是什么，要怎样利用他，如果这时候引导装备的操作就恰如其分，玩家学习的成功率
第三，通过多种交互设计方式适当引导玩家。
交互设计师之所以不同于文案设计师，关键在于善于利用多种交互方式（更多的是图形的，动态的）适当表达一件事情，而文案设计师只会通过文字，最多有
几个擦图，这种形式死板，玩家不容易关注，学习成本高。交互设计师得表达方式是多种多样的，尤其在当今多媒体技术越来越发达的今天，传达信息的途径和方式
多种多样，视觉效果越来越好，交互设计师应该利用这些发达的技术，充分发挥想象力，设计出更好的交互方式。
其实，新手引导没有固定的形式和规则，只要充分考虑玩家感受，达到了教会玩家的目的，合情合理的设计就是成功的。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。后使用快捷导航没有帐号？
　论坛入口：
　　|　　　|　　　　|　　　|　
我要游戏程序
查看: 5202|回复: 1
分享：游戏新手引导程序框架设计3要点
设计思想/框架&
u=,&fm=21&gp=0.jpg (21.68 KB, 下载次数: 4)
18:14 上传
　　GameRes游资网授权发布 文 / 傅建钊
　　新手引导确实是个麻烦事，逻辑杂乱，而且跟界面的逻辑常常交叉在一块，弄的不好的话代码里到处都是if else,保存各种临时状态变量。但这里面其实也是有规律可循的，不说完美解决了所有问题，但至少可以提供一个框架，一种问题解决的思路。这里面有3个关注点：
　　1.引导的触发点
　　2.引导的进度
　　3.引导的表现内容
　　传统的方案实际上也是在解决这3个问题，只不过用的是生硬粗暴的硬插的方式去编写代码，代价是容易出现bug，不好维护，而且几乎不可复用。
　　就像把状态机转化为行为树一样，思想上需求去抽象各个点，然后让它们有机组合起来，形成一个模块，加入说是新手引导模块。
　　假设这个模块叫做Guide，下面分别阐述以上3个问题的解决方式。
　　1.新手引导的触发点，一般新手引导是在界面切换后发生的，那比如这个界面有个OnEnter，那一般界面都会有一个基类，所以我们可以在这个基类的OnEnter里注入一句Guide::Instance().Trigger(...界面名称等参数)，当然我们也可以在其他界面统一调度的地方去调用这个Trigger。有时候也可能需要在游戏帧里去调用Guide::Instance().Update(dt)。这一点上，不一样的地方在于以前是硬在各个界面里写触发，现在是在统一的地方写，数量上明显少了。
　　有触发入口了，然后到底是否要触发引导？这个时候就需要Guide里维护一个Trigger列表，简单比如说是List&ITrigger*&，每一个ITrigger上有一个断言方法bool CheckCondition(...参数自己定)，这样简单来说，你只要遍历这个Trigger列表的CheckCondition方法，就可以实现条件触发了。而里面的CheckCondition的实现，简单的可以直接查询Player的属性来定（比如说到10级才触发），或者当前判断当前是在什么界面，复杂的甚至可以用IPredicate，AddPredicate,OrPredicate,NotPredicate来实现一棵条件判断树，也可以触发脚本。游戏在启动的时候会通过配置或脚本加载这么一个trigger列表，已经触发的Trigger可以从列表中删掉。
　　ITrigger想要实现的话可以支持嵌套，变成一棵跟行为树一样的结构。
　　2. 引导的进度，有些引导进度是根据玩家属性相关的，比如玩家等级，这个不需要专门保存。而有些引导步骤进度通常需要保存，这些可以在服务器数据库（网游）或客户端存档（单机的话）保存一个引导表，每一行有引导Id（对应Trigger），进度Index,再附加内容。已经完成的引导可以从玩家上标记。如果只支持引导按序触发的话，那玩家身上可以保存一个当前引导Id，可以加快不少效率。如果支持非线性触发，那就从引导记录上做标记也可。
　　3.引导的表现内容，一般引导的内容就是切换界面，禁止一些按钮等等，这个在ITrigger的Run里来实现，可以由你发挥了，看是直接在里面写UI或者触发脚本什么的。
　　这样下来，就把引导的逻辑和界面逻辑隔离开了，不过实际上因为引导是强关联到界面的行为的，所以在实现引导的时候，也经常需要获取当前界面的某个按钮等等操作，不过至少清晰可维护。
　　这个方案我自己以前实践过，还算能满足需求。
　　相关阅读：
楼主，能不能鉴赏一下代码游戏策划入门修行（五）——新手引导系统的设计和常见问题分析 - 简书
游戏策划入门修行（五）——新手引导系统的设计和常见问题分析
图片来自网络
在前一篇文章中我写了基础任务系统的设计，那么与之关联紧密的引导系统又该如何配套设计呢？
引导系统带有操作上强迫性，从用户体验的角度来讲是不太友好的。但是引导系统能够帮助玩家快速适应游戏的基础操作，和熟悉游戏的特色模块的操作方式，所以一般还是会或多或少加一些引导进去。
有少部分的游戏整体系统比较简单，玩法也不太复杂，亦或是比较大众的游戏，操作与玩法比较普遍。这些游戏在做引导时不需要很复杂的流程，所以引导系统有时候会选择由程序直接写死。写死的优点在于简单粗暴且不容易出问题。
但是碰到游戏系统相对复杂的时候我们就需要一套易修改、易扩展、兼容性高、并且稳定的引导系统了。
引导系统设计
我们所期望的引导一般在这些情况下触发：新进游戏，进行到某一步任务，角色升级，新功能开启，获得某一样特殊道具等。我们整理一下这些需求点，看能否提炼出一个或者几个共通点来把它们串联起来，这样引导系统设计的线索就有了。
当然，如果实在是有些触发情况无法提炼共通的触发线索的，我们只能选择对这种情况进行特殊处理。
创建角色进入游戏后，任务系统也会同步加载上来，玩家每完成一步任务操作就会有不一样的trackID和不一样的action进程（可查看一文），所以我们引导可以选择根据任务进度来触发。
随着游戏的进行，慢慢地就会有各种玩法系统陆续开放，这个时候玩家获得经验的途径就会更多，不一定要靠主线任务进行升级。如果玩家不做主线，随着他的等级提升，我们还是期望引导系统会继续出现的。所以我们需要另外一个触发条件，所以在这里提炼出引导系统的第二条线索——等级
我们知道，有些引导需要玩家开启了某个功能之后才可以进行。我们考虑一下功能开启的条件，无外乎玩家完成某一个任务或者达到一定的等级，或者二者同时满足功能才会开启。所以关于功能开启后的引导也能通过任务和等级来控制。
如果某些引导是需要玩家获得一个特殊道具才触发的，那么我们考虑这个道具的获取条件，是否能放到任务中给，或者任务的需求就设定为需要获得这样一个道具。如果都不行，那么这一步引导就只好进行特殊处理了。
通过上面的分析，我们提炼了两个线索——任务和等级。我们的引导流程就可以根据任务和等级双重条件来控制。引导系统最好是做成有序且互斥的，不然就容易出现多个引导重叠的情况。先看一段简单的脚本配置：
needLevel：引导开启需求的等级
needTask：引导开启所需任务条件，101-3意为track 101的第3个action
buttonId：引导所指向的按钮id
message：引导提示文字
&Guide id="1" needLevel="1" needTask="101-3" buttonId="1001" message="打开包裹查看索菲亚的信物"/&
&Guide id="2" needLevel="2" needTask="102-3" buttonId="1002" message=“点击关闭包裹界面”/&
我们定义引导开启的条件为等级和任务两个条件同时满足，引导就按照配置的顺序依次执行。需要注意的是，如果引导跟功能开启相关，那么功能开启的条件就必须与引导触发的条件相同，且功能开启的系统优先级要高于引导系统。
上面只是一个引导系统的雏形，光有这些还是远远不够的。
我们还要考虑引导万一出现bug卡流程怎么办？所以需要给引导加一个是否可以手动跳过的按钮，玩家也可以根据自己的实际情况选择跳过这步引导。一旦出现某些问题，导致引导没有正常出现，我们还是希望其不影响后续引导的，所以我们给引导增加跳过机制，我比较喜欢的做法就是在下一个引导的条件达成之后自动跳过前一个引导，直接出现后面的引导。
玩家在引导的时候可能正在进行某些操作，比如打怪或者做支线任务，若完成某些操作会打开一些系统弹框或者进行场景跳转时，都容易造成引导卡断。所以我们可以给引导增加一些中断其他进程的机制，然后增加一个脚本参数，可以根据需要进行配置
对于一些比较重要的操作，而操作流程与前面的又比较类似的情况，我们可以添加一种非强制引导类型。这种引导出现时玩家可以进行其他操作，当检测到玩家没有按照引导流程执行时，就会自动跳过这个引导。
有的引导步骤相对比较复杂，可能会分为多个步骤，我们可以把这一系列的操作放到一个引导模块中形成一个引导块，这样不容易出现多个步骤循环判断导致全部跳过的情况。
经过上面的分析，我们将引导系统进行扩充得到以下结果：
needLevel：引导开启需求的等级
needTask：引导开启所需任务条件，101-3意为track 101的第3个action
buttonId：引导所指向的按钮id
message：引导提示文字
skip：值为1，意为该步引导可点击跳过按钮直接跳过
force：值为1，意为该引导为强制引导，引导出现时不可点击其他界面按钮（跳过按钮除外）
breakProcess：值为1，意为中断其他非引导相关的玩家游戏进程，如停止任务，停止打怪等
songuide：子引导
index：子引导对应的id
&Guide id="1" needLevel="1" needTask="101-3" skip="1" force="1" breakProcess=“1”&
&songuide index="1" buttonId="1001" message="点击打开包裹界面"/&
&songuide index="2" buttonId="1002" message="点击查看索菲亚的信物"/&
&songuide index="3" buttonId="1003" message="关闭界面"/&
&Guide id="2" needLevel="2" needTask="102-3" skip="1" force="0" breakProcess=“0”&
&songuide index="1" buttonId="2001" message="点击打开装备界面"/&
&songuide index="2" buttonId="2002" message="选中武器"/&
&songuide index="3" buttonId="2003" message="点击强化"/&
&songuide index="4" buttonId="2003" message="关闭界面"/&
最后就是根据具体项目的实际情况再对引导系统内容进行扩充了。
其他问题处理
按钮的响应方式
引导的操作一般都是指向具体的界面按钮的，最理想方式当然是能通过底层机制实现引导事件与按钮对应的事件同步响应的效果。一般做成这样，几乎很少会出现卡引导流程的BUG。
但实际项目中，因为引擎的使用情况，或者因为架构设计，还有游戏类型等原因达不到按钮事件与引导事件同步响应时，我们就需要通过其他机制来实现引导按钮响应了。
常见的方式是划定屏幕区域，点击划定的区域即可响应引导。在一些策略游戏当中比较常见，这种做法很容易出现以下几种bug：
按钮响应，界面成功跳转，但是引导没有响应
引导响应，但是按钮没有响应，界面没有成功跳转。
屏幕分辨率适配问题导致引导区域与按钮不匹配（这种情况可以根据按钮来创建引导区域解决）
其他引导bug
引导操作与其他界面弹框冲突死锁。比较容易出现死锁的界面有：断线重连界面，系统提示界面，充值界面等。
这是引导界面层级混乱导致的。
引导中途游戏闪退或者杀进程，导致引导异常中断，后续引导无法出现的问题。
如果我们在最开始设计的时候就增加了后续引导条件达成将会跳过前置引导的机制，这个问题就不会对后续引导产生影响了。
如果这个引导非常重要，我们可以检测引导未完成的情况下，下次登录再次重新引导一遍。
如果有的引导有一些不可挽回的操作步骤，比如第一步就是需要使用某种特殊道具，这个时候就需要服务器利记录玩家的引导步骤。当玩家再次打开到对应界面时（判断条件可以设为，玩家的游戏界面创建了该引导所对应的按钮，则引导继续）继续未完成的引导步骤。
因水平有限，有写的不对或者不够全面的地方，欢迎大家留言指正
也欢迎大家留言与我交流，有问必回
潜心修行的游戏人
个人主页：
/p/19c6f53b37832783人阅读
cocos2d-js（14）
&&&&&&想到新手引导的功能时可能很多人都会觉得头痛，难以下手。特别是在游戏本身功能或需求还不稳定的情况，更是难以应付，本人就是在这种情况下接受了一个艰巨的任务。在痛定思痛之后，开始了引导功能开发。在做的过程中一点点发现很多有意思的东西，想分享给大家。
一、痛点：新手引导制作的难点及弊端
需要在具有引导功能的代码单元插入引导代码或逻辑判断，干扰正常流程。
引导代码的加入会影响原有的代码逻辑与流程，使代码变得复杂加大维护难度。
界面或需求发生变化后引导功能需要大幅修改或重新制作。
指引（手指提示）对应的矩形区定位麻烦，特别是需要适应不同尺寸屏幕的时候更加困难。
编写引导配置文件也很头痛，需要策划、程序的高度配合。
二、期望：新手引导编程体验
& &笔者进入游戏开发应该说是手机游戏开发并不是很长时间，虽然参于过多个项目，但亲自编写新手引导这还是头一次。当时接到新人引导任务时，我们的项目只完成了：登录-&主界面-&抽卡-&布阵-&章节-&关卡-&战斗这样一个基本流程，界面美术、功能需求都极不稳定。但在公司的硬性要求下，冒着九死一生的危险开始了新手引导功能开发。在了解到传统的引导制作过程中的难点与弊端后，一直在思考没有更好的实现方式，我心中的引导编程的方式有以下几点：
不需要在每个单元中去插入引导代码，游戏代码与引导代码应该尽量分离。本人很难忍受漂亮的代码被无情引导打乱，更难忍受本来糟糕的代码被引导弄得支离破碎。
界面只发生简单UI位移、节点层次改变不需要修改引导代码。
定位指引矩形区应该尽量的简单，且自适应不同尺寸屏幕。最好能做到策划人员都可以来制作部分流程引导。
在引导需求明确、游戏功能正常的情况下，制作一个常规的引导步骤应该是非常快捷的，不会超过3分钟，快的话1分钟内就应该搞定（不是笔者说大话，确实已经实现）。& &
三、思想：引导功能的设计思路
&&&&在描述引导功有设计思路之前，有个重要的前题：命名规范。
&&&&命名规范主要有两个方面：
cocostudio中的控件名字
代码中动态创建的控件名字，以及类成员变量的名字。
& &在笔者的项目中使用了sz.UILoader来管理cocostudio的UI命名和事件。&如不了解请参见我的另外一篇blog
&&&&我们这里引入两个概念：任务与任务组。任务：把引导中的一个最小步骤称之为一个任务，比如提示点击某个按钮。任务组：把一系列的任务放在一个任务组中，当这个任务组中的任务全部完成，我们会保存一次任务进度。此时重新进入游戏将不会再执行这个任务，而是执行它的下一个任务组中的任务。可以理解任务组是引导中的一个步骤。
& & 用json格式表示如：
&&&&&&&&1: [{任务1}，{任务2}，{任务3}]
&&&&& & 3: [{任务7}，{任务8}，{任务9}]
&&&&&&&&2: [{任务4}，{任务5}，{任务6}]
& & &当从一个任务组中的任务中断后，再次进入引导 需要重新从这个任务组的第一个任务开始。
&&&&&见下图演示了一个从主界面点击召唤-&灵石召唤一次-&点击获得-&确定-&仙玉召唤一次-&点击获得-&确定-&点击空白退出召唤界面的流程。
& &上图演示的引导我分成两个任务组：灵石召唤、仙玉召唤。 任务配置如下：
& & & &&name&: &4.提示指向灵石召唤按钮&,
& & & &&command&: &手型提示&,
& & & &&tag&: &_oneMoneyButton&
& & & &&name&: &保存进度&,
& & & &&command&: &保存进度&
& & & &&name&: &5.提示指向角色确定按钮&,
& & & &&command&: &手型提示&,
& & & &&tag&: &_UILotteryHero & _confirmBtn&
& & & &&name&: &6.提示指向角色图标确定按钮&,
& & & &&command&: &手型提示&,
& & & &&tag&: &_UILotteryTimes & _confirmBtn&
& & & &&name&: &7.提示指向仙玉召唤按钮&,
& & & &&command&: &手型提示&,
& & & &&tag&: &_oneGoldButton&
& & & &&name&: &保存进度&,
& & & &&command&: &保存进度&
& & & &&name&: &8.提示指向角色确定按钮&,
& & & &&command&: &手型提示&,
& & & &&tag&: &_UILotteryHero/Panel_33/Image_10/_confirmBtn&
& & & &&name&: &9.提示指向角色图标确定按钮&,
& & & &&command&: &手型提示&,
& & & &&tag&: &_UILotteryTimes/Panel_11/Image_1/_confirmBtn&
& & &其中每个任务中的name用于调试打印的对引导本身无实际用处，在任务开始和结速都会有提示，如果出错方便定位。 command这里应该叫做指令,对应一段具体功能的代码或函数，我这里设置了两个：手型提示、保存进度。
& & &手型提示：需要配合tag字段的值，tag描述了一个当前任务状态下的一个node节点的索引。具体tag的编写方式请看下面一节&实现在节点树中定位控件&。
& & &进度保存：手动进度保存是为了确保在任务中断后，游戏流程不受影响。 在招唤这个功能里，是只能召唤一次的，如果已经召唤成功了，服务器已经更新数据 ，后面的引导都是客户端的界面显示、关闭引导。如果在召唤之后，做一次进度保存，任务中断后再次进入引导会跳过这个任务组中的任务。 & & &
& & & 在理解了任务的功能后，需要有一个上层框架来一个一个的执行这些任务。
& & &&引导框架：在任务条件满足时（比如：等级要达到多少或者无任何条件），指示用户进行某项任务（比如按钮的点击）。当任务完成后，执行下一个任务，直接到全部任务被完成。它需要具有以下几点功能：
条件检查：检查是否该执行该任务，默认为无条件执行。这需要检查任务是否有onTaskBegan函数 ，不存在或返回ture才能执行任务指令
UI & 定位：找到出当前任务中UI节点对应的矩形区。在指引任务中准确编写UI定位描述，由框架去检索UI节点，当检索到节点后调用任务的onLocateNode函数，传入节点对像，这可以让整个引导可以有更多的扩展。
指引动画：当定位成功后，引导框播放指引提示动画，提示用户操作该矩形区。
触摸限制：屏蔽定位节点矩形区外的操作全部。
事件检查：矩形区对应的UI事件是否被执行。
任务完成：通知引导框架任务完成，进入下一个任务。
四、定位：实现在节点树中定位控件
& & &以上几点中首要解决的是对UI控件的定位，对UI定位最直接有效的方法是在拿到这个UI控件对象，然后取出他的BoundingBox、锚点信息，进行座标转换。但如何才能拿到这个控件对象呢？ 这里有两种实现方式：
&&&&1. 遍历场景树，把它搜索出来。
&&&&2. 事先把这个控件对象注册到你的引导框架中。
& & & 我采取的是第一种方法来定位控件，因为我不想在到处代码中添加游戏逻辑以外的东西。而且cocos2d-js中提供有现成的函数cc.helper.seekWidgetByName，如果你做的是手机游戏是不能直接使用这个函数的。在HTML5上这个函数可以遍历整个节点树&，在jsb上只是遍历的Widget节点。 有两种方法解决这个问题：
&&&&1.把cc.helper.seekWidgetByName函数复制到自己代码文件中，重新取个名字叫：xxx.helper.seekNodeByName。在html5和jsb上都使用这个函数。
&&&&2.在c++ jsb上把cc.Helper.seekWidgetByName的参数修改成在Node节点上做遍历，或都重新封装一个jsb上的seekNodeByName函数 。
& & & 我这里偷懒还是使用第一种方法。通过上面的方法是否已经解决UI定位的问题呢？应该没那么简单吧！通过这种方法定位控件，就不用在引导配置文件里填写坐标或矩形数据，那是极其愚蠢的办法。
打住，他妈的还有问题！！！&如果一个场景树中有两个相同节点名字怎搞？
&&&&这个问题确实问的很正确。因为我们经常会有名字相同的节点存在。比如下图：&
如果他们名字都叫button，使用seekNodeByName是来定位控件的话只能找到其中一个。具体是那个是根据你addChild时
的顺序来决定的。这个问题如何解决？能唯一确定一个控件在场景树中的方法就是他的“完整路径”，
像这样一下来描述两个button:
& &&招唤界面/灵石招唤/召唤一次&
& &&招唤界面/仙玉招唤/召唤一次&
其实我们已经能定位到灵石招唤和仙玉招唤了（我这里为了方便理解使用中文名字）只需要这样写:
& &&灵石招唤/召唤一次&
& &&仙玉招唤/召唤一次&
这样也能精确定位到你想要的那个按钮。
& & 在这里我实现了一个简易的定位器描述规则，我们以后通过以下方式在任务中定位一个控件 ：
名字描述：在场景中有独一无二的名字时，直接描述控件名如：'_loginButton'。
路径名描述：在场景中需要定位的节点可能有重名时，找到其父节点，确保父节点不会有重名时使用：'parentName/button'。如果父节点也有重名，那就再向上使用其父节点名的父节点以此类推。
js属性描述：
有一种情况通过getChildByName无法直接访问的节点，如ccui.ScollView容器中的节点。我定义了一种简单的获取方式，例如 'layer1.button' 通过“.”这个符号来定位layer1下的一个属性为button。这种方式是在js中最为直接的方式。
子节点描述：使用完整路径描述一个控件时，有时会觉得比较长，例如：&'mainLayer/layer1/button'
可以简写成 'mainLayer&button' 表示定位mainLayer下一个名字叫button的子节点，有可以是1级子节点，也可能为2、3、n级子节点。
&&&& 5.&复合描述：将以上几个方式组合使用，来描述一个控件：'mainLayer&homeLayer/layer1.button' 。用人话翻译下就是：mainLayer下有一个homeLayer子节点（不管是几级）下的一级子节点layer1下的一个变量名为button的节点.
描述符号总结 ：&& &&
&&&&&/&& : 表示一级子节点
&&&&&&&&: 表示一级~n级子节点
&&&&&.&& : 表示属性名
& & & &这里就体现了为什么要注意名命规范的问题。有web开发经验的人一眼就能看出这里有一点css选择器的味道，呵呵！非常正确，正是借鉴了css选择器的思想，实现一个十分简单的选择器，我们这里可以称之为“定位器”，因为我们只需要定位出一个节点。
（未完待续）
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：57672次
积分：1015
积分：1015
排名：千里之外
原创：36篇
评论：32条
(5)(3)(1)(2)(1)(1)(5)(1)(2)(1)(1)(1)(3)(1)(2)(1)(1)(2)(1)(2)(1)(2)(1)(1)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'}