有关理想的新手指引思考及框架设计实现
游戏新手引导的设计目的是通过帮助用户掌握游戏玩法，从而提高留存率。经历过几个项目的新手指引，总是感觉做起来很痛苦，静下心来做一下总结吧。
一、新手指引的地位
新手指引的设计初衷，一定是引导玩家，特别是新玩家了解整个游戏系统和操作。它运行的时间段，恰恰是玩家对这一款游戏建立印象的时间段，对于如此重视游戏留存的今天，可以说很重要。但在实际的开发中，新手引导的地位却比较尴尬。
首先，它的真实作用是存疑的，主要问题在于有多少玩家会认真地去理会每一步的意义？点了这一步会产生什么变化？是否记住了操作步骤？引导中的剧情是否真的增强了代入感？我见过的很多玩家，尤其是常玩游戏的玩家，新手引导过程都是快速点过的，有多快点多块，根本不走心。等新手引导结束后，再回来慢慢体验游戏。像这种玩家完全就是把新手引导当成了负担，当然，在长时间的点击中，会留下一些印象，但是这肯定不是我们设计者所希望的。
其次，新手引导的开发时间往往比较紧张。要做新手引导，游戏系统要完整，前期的游戏内容也要完成，这样才能确定指引的内容和步骤。游戏的操作要定型，UI要完成，这样才能确定引导过程的操作对象。因此，新手引导需要在游戏开发的后期才能开始做。而游戏项目往往是后期的时间最紧张，如果开发者再不够重视新手引导，那最后就会选择用最省力的方式去完成开发。表现出来的就是粗制滥造。
现在大部分的手游都采用了比较省力的方式，那就是强制引导的方式。玩家从开始游戏，就只能完全按照指引来操作，屏蔽掉其他所有的操作可能，一直操作到指引结束。这种做法之所以比较省力，就是只要编写顺序，把游戏前期的所有内容一步步展示出来即可。玩家的操作，系统的反应，资源的投放都是确定的。玩家只能按照这个顺序点击，其他所有的操作全部屏蔽。如果不这样，那需要考虑的东西就很多，一不小心就会有漏洞。例如：某一步需要玩家有100金币，但是如果玩家在指引之前把金币花掉了，就会导致指引进行不下去。这样的指引，感觉越来越鸡肋，记得第一次玩《放开那三国》让我一步步点了好长时间，才能自由操作。说实在的，如果不是当时好游戏少，真的忍不了。
二、有关理想的新手指引思考
1、指引应该是精简的
首先，要让玩家玩明白游戏，最重要的是把游戏本身的交互系统做好。人性化的UI其实是不需要指引的，玩家会很自然得找到所求，在不容易理解的位置，要有解释文本，Tips，气泡等等，要让玩家不明白了随时可以看到，而不是寄希望于玩家通过指引了解这些信息，并记住。即使是为了新玩家，那指引也只需要进行关键的几步即可。除非是特别依赖剧情的RPG游戏，否则解释对话也应该尽量少。
2、指引应该是动态的
游戏比传统的艺术形式的最大优势就是可交互，如果用一套新手指引作为剧本，让玩家一路看下来，那叫自我阉割。
指引要理解为一种交互，他应该是动态出现的。玩家打到了第一件装备，然后再跳出更新装备的指引。玩家点进了酒馆，再跳出招募的指引。就是要让玩家去探索，探索到了，然后告诉他这里是什么，应该怎么玩。
例如《海岛奇兵》的指引就很优秀。开始游戏的时候，屏幕上就只有一个按钮，这个时候不需要指引，玩家也知道应该点什么地方。随着游戏的进行，按钮是一个个跳出来的，这样不需要指引，玩家也会好奇点进去看看。前期的大框架是自由的，只是当满足了一些开启条件后，才跳出一个很简单的指引过程。像这样的指引给人的感觉会是惊喜，而不是负担。3、指引应该是开放的
强制玩家只能点击指定的按钮，其实是很不友好的。你可以用很显眼的效果去提示我应该点哪，但是不应该剥夺我点其他位置的权利。现在大家之所以这样做，原因上面已经说了，就是怕玩家乱搞，导致指引进行不下去。
下面是《Clash Royale》的指引：
同时出现了两个可以升级的卡片，而这个时候，玩家是可以任意操作的，你可以选择升级这张卡片，也可以不升级，甚至当你选择升级万箭齐发的时候，手指也会跟过去。这说明，他们的指引做的非常细致。
4、指引的开发
指引的开发应该尽量提前，在系统定型，UI设计完成后，就应该着手进行了。从策划，到程序都要由专人负责，而不是随便抽一点余力搞一搞。
按照程序员的思维习惯，都是希望能够做一套通用的系统，把所有的指引可能都囊括在这个系统下，然后让策划去通过配表完成制作。我觉得在做指引的时候应该摒弃这种想法。首先，指引是一项很不稳定的功能，几乎牵扯到了所有的游戏系统。任何一点改动，都会引起指引的变化。这些变化是很难预期的，程序员往往很反感，最后相互抵触妥协折中，就搞出了一些不伦不类的结果。
所以经过几个项目的尝试，我不太支持用配置文件的方式去做指引，hard code反而更适合。这种工作就是应该程序策划坐在一起，慢慢打磨出来。
当然，这并不是说程序完全不做结构设计，把指引相关的代码分散到各个系统和界面里。还是需要通过良好的设计，把指引相关的代码集中在一起，与游戏系统做好隔离。
三、设计思路
如果说具体的做法，针对我做过的一些游戏类型，大概梳理了一下思路：
1、拆分成指引小组
把指引步骤，尽量拆分的细一些。比如，虽然创建英雄祭坛和招募英雄是连续的步骤，但是，应该拆分成两组指引，创建，招募各代表一组。最理想的情况是，每一步只跟服务器进行一次信息同步。这样，就比较容易进行断点返还。
每一个小组有一个编号 比如 1000，每一个小组中的每一步都有一个小步骤编号如1，2，3。这样每一步的指引就有一个唯一的编号=小组编号 +步骤编号， 如1001。
2、每一步的触发条件
指引系统的每一步，不应该自己一步步驱动，也不应该通过计时控制，而应该是有游戏的业务逻辑驱动的。触发条件会有这几类：
- 进入场景
- 打开界面
- 收到数据包，并成功
- 关闭界面
为了不让指引代码散落在游戏代码各处，难以维护，我们在这些位置，让他们抛出一些通用的消息。然后在指引系统中设置监听。并处理逻辑。当然为了优化，可以在一个指引小组开启的时候，再设置监听，小组结束后清除这个小组的所有监听。
3、限定条件
因为触发条件是一条通用消息，这种消息发出的很频繁（比如打开英雄界面，每次打开都会发送这样一条消息），所以指引需要用一定的条件去判断这条消息是不是真的触发这一条指引。
这里存在两种情况：
1）小组内的指引，这种比较简单，因为小组已经开始，所以收到消息之后，只需要判断当前当前的小组对不对，还有上一条指引的ID是不是匹配，就可以断定，应不应该出这一条指引。
2）小组开始的指引，这个判断会比较麻烦，判断条件大概会分为下面几类：
- 当前是不是在指引中（确保不会同时出现两个指引小组）
- 第一次打开，或者进入某某某
- 某功能是否开启
- 玩家等级
- 基地等级
4、断点返还机制
每一个指引小组，有两种可能，开启断点返还，和不开启断点返还。前者只要关键步骤没有进行过（例如，指引创建建筑过程中，创建成功的服务器回包），那如果再次满足条件，还会开启指引。后者是只要指引开启过了，那就不会再次指引了。
实现方式，以指引小组为单位，在服务器或者本地记录一个bool值，记录这个指引小组是否开启过。需要开启断点返还的指引步骤，在关键步骤结束后，就将这个bool值置为true，它将会成为这一步指引是否开启的判断条件。对于不使用断点返还的指引小组，在指引开始的第一步就置为true即可。
如果一个指引，需要的前提条件比较多，指引繁复，那为了保险起见，还是做成不支持断点返还的为好。
四、程序框架设计
新手引导有的时候会逻辑杂乱，而且跟界面的逻辑常常交叉在一块，弄的不好的话代码里到处都是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上有一个断言方法bool CheckCondition(...参数自己定)，这样简单来说，你只要遍历这个Trigger列表的CheckCondition方法，就可以实现条件触发了。而里面的CheckCondition的实现，简单的可以直接查询Player的属性来定（比如说到10级才触发），或者当前判断当前是在什么界面，复杂的甚至可以用IPredicate，AddPredicate,OrPredicate,NotPredicate来实现一棵条件判断树，也可以触发脚本。游戏在启动的时候会通过配置或脚本加载这么一个trigger列表，已经触发的Trigger可以从列表中删掉。
ITrigger想要实现的话可以支持嵌套，变成一棵跟行为树一样的结构。
2、引导的进度
有些引导进度是根据玩家属性相关的，比如玩家等级，这个不需要专门保存。而有些引导步骤进度通常需要保存，这些可以在服务器数据库（网游）或客户端存档（单机的话）保存一个引导表，每一行有引导Id（对应Trigger），进度Index,再附加内容。已经完成的引导可以从玩家上标记。如果只支持引导按序触发的话，那玩家身上可以保存一个当前引导Id，可以加快不少效率。如果支持非线性触发，那就从引导记录上做标记也可。
3、引导的表现内容
一般引导的内容就是切换界面，禁止一些按钮等等，这个在ITrigger的Run里来实现，可以由你发挥了，看是直接在里面写UI或者触发脚本什么的。
这样下来，就把引导的逻辑和界面逻辑隔离开了，不过实际上因为引导是强关联到界面的行为的，所以在实现引导的时候，也经常需要获取当前界面的某个按钮等等操作，不过至少清晰可维护。
这个方案我自己以前实践过，还算能满足需求。
关注 GameRes游资网
微信扫一扫关注公众号
