最近忙成狗。 因为⾼层的决策， 导致我们年前需要在⼤部分东西都没有的情况下， 硬⽣⽣的怼出⼀个⽐较正常， 且能玩， 美术效果还不错的版本， 所以加班是特别厉害。 ⽽且因为TeamLeader启⽤了 敏捷开发模式 scrum 的项⽬管理模式。 也是折腾的够呛，这个模式对开发⼈员要求⽐较⾼，主要是要求团队成员的主观能动性特别强，能⼒越强越能感受到累，因为你平时开发的时候时间都是⾜够充⾜的，因为启⽤了scrum，你可能会被指定为⼀个sprint的程序的负责⼈，那么需要你去督导这个sprint中其他的⼈的开发情况。⽽且⾃⼰做完了之后⼤概率会马上⼜从sprint中⼜挑⼀个活接着做，所以最后特别的累。
在分功能模块的会议中，分配给我做的是新⼿引导模块， ⽽且距离我们分模块到过年只有短短的12天。
12天的时间， 开发⼀个⽐较完善的新⼿引导模块，也不是不可以，但是这种情况下的新⼿⼀般是硬写的， 我上⼀个项⽬的新⼿引导，⼤概写了 5天（不是我实现的）， 然后通过 配表， 完整的实现了⼀个简单的新⼿引导， 之前的项⽬新⼿引导⽐较简单， 基本就只有逻辑点击这样的流程。属于⽐较简单的类型。 但是后来当策划需要简单修改下流程的时候， 有部分时候，程序得陪着⼀起改。这在我看来是不太合理的地⽅。 因为会消耗⼤量的⼯时进⼊到⾥⾯，⽽且还⾯临着随时都会修改的问题。
所以在⽬前这个项⽬的新⼿引导， 虽然时间⽐较紧， 但是还是和teamleader商量之后， 我和他都⼀致觉得我们应该通过开发编辑器的模式， 让策划直接参与到新⼿引导的开发， 只要我们编辑器开发的⽐较完善， 那么以后需要我们去修改的东西也就越少。
罗列⼀下开发新⼿引导编辑器需要⾯临的问题和困难：
开发⼀个完善的编辑器
定义⼀套完整流程，以⽀持编辑器编辑器出来的数据的运⾏
编辑器编辑的引导流程之间的衔接
跟服务器之间的交互
教会策划使⽤编辑器
与其他模块之间的交互
⼀套完善的事件系统的需求，⽤于触发新⼿引导与处理新⼿引导逻辑
开发⼀个完整的编辑器
因为我们使⽤的是Unity， 所以我们直接使⽤的Unity来进⾏开发。所以我们⾯临编辑器的难点有⼏个：
1. ⼀个简单的数据的序列化和反序列化的功能，要⾜够好⽤，当我新增功能的时候， 不⽤为他单独的去写导出之类。
2. ⾜够完善的Editor渲染功能， ⾜以⽀撑我们写出⼀个⽐较正常的代码逻辑， ⽽不是为了配合渲染模块，⽽牺牲代码的结构。
3. ⾜够好⽤的编辑功能， ⾄少保证策划的吐槽也就卡在某⼀个级别。 不要难⽤到所有策划都抗议的级别。
对于数据的导出和导⼊， 因为是使⽤Unity编写， 所以是使⽤的C#， C#完善的反射机制能够帮我们实现的这个功能。
⾸先我们能通过反射拿到 数据项的类型， 然后我们能够通过⾃定义C# attribute 来定义数据项的存储的键值等，⽤于在反序列化的时候使⽤。 因为TeamLeader之前的项⽬中已经做过这个⼯作了， 所以直接就拿过来使⽤， 他是通过 反射+attribute ⽣成Json脚本。 我之前也写过⼀个场景编辑器， 也是
基于Unity的，功能和实现都差不多， 不过我是⽣成的是 lua脚本。 因为我们项⽬⽬前暂时没有启⽤lua， 所以直接采⽤他的版本。
对于Editor的渲染问题， 也是有⼀套现成的拿UnityApi封装的好的东西来使⽤， 因为之前有写场景编辑器， 所以也可以直接拿过来使⽤。（我们的场景编辑器是直接编辑xml的表格数据）
⾜够好的编辑器功能， 这个是直接使⽤Teamleader提供框架的功能，是他们原有项⽬中使⽤的。 满分10分， 我可以给个5分。 所以我觉得策划应该勉强能接受。
定义⼀套完整的流程，⽀持数据的运⾏
我们⼤概把新⼿引导分为3个级别： 脚本 > 步骤 > 节点 脚本
⼀个脚本是编辑器的基本单位， 策划每次进⾏编辑的⼀个完整的流程就是⼀个脚本，⼀次引导流程就是⼀个完整的脚本。 脚本由 ⼀些步骤组成。
步骤
步骤是脚本的基本单位， 步骤之间⽀持任意跳转，节点之间是串⾏的，⼀次只会有⼀个步骤在运⾏。 步骤由⼀些节点组成， 节点之间并⾏的， 当⼀个步骤被执⾏的时候，该节点下的所有的节点都会被执⾏。
节点
节点是最基础的组成部分， ⼤量节点的各种组合， 就形成了⼀个新⼿引导的流程。
节点分为 普通节点， 事件节点
普通节点不会有触发事件， ⽐如 SetActiveNode， 这个就是⼀个普通节点， ⽤于显⽰和隐藏某个Game object。 之后就不会有特殊的逻辑了。
事件节点为带有触发事件的节点， 当他条件被满⾜的时候， ⾃⾝就会被触发， 触发之后会根据配置的跳转的步骤的tag， 跳转到其他步骤。 ⽐如 GuiClickNode 指引玩家去点击某个UI元素， 如果玩家点了之后， 那么就触发已经配置好跳转事件。
跳转tag，可以配置为多个， ⽐如让5分钟玩家打死某只怪物， Succeed： step2
Failed： step3
做⼀个分⽀跳跳转。
在这个地⽅我和我们的teamleader有⼀些分歧， 分歧在于。我觉得有⼀些节点， 我们可以定义为通⽤节点。 ⽐如 GUIClick节点， ⽐如SetActive节点， ⽐如ShowMask节点。 这种可以跨项⽬通⽤的节点。 或者是整个新⼿流程通⽤的节点。
然后有⼀些特殊的节点： ⽐如强制玩家在某个区域建⼀个建筑，因为包含⼀些特殊流程， ⽐如， 我需要修改玩家的合法建造区域，得以让他只能在某个区域建造。 这种与原有逻辑违背的节点，叫做特殊节点。
但是Teamleader的意思是， 新⼿引导本来就是⼀个特殊的东西， 他的所有的东西都是特殊的，所有不存在什么通⽤节点和特殊节点。 不需要去做这个抽象， 这样会增加策划和程序员的理解难度。
我能理解他想表达的意思， 他的观点也是正确的。 这个主要是看法不同， 我⽐较倾向于让策划去理解， 在这个地⽅你就要特殊的事情了，所以和平时还不太⼀样。
体现到结构上⾯就是：
⼀个特殊的建造节点， 采⽤不抽象的⽅法的话， 他就是⼀个单独的节点， 没有什么特殊的东西。
如果采⽤带⼀层抽象的⽅式去做的话， 那么应该是先有⼀个通⽤节点 叫做 Command节点， 然后在Command中定义⼀个特殊的类型，就是这个特殊建造，
确实有增加了理解成本。⽽且实现起来也会⽐较⿇烦，所以我也没有纠结这个， ⽽是直接以⽂件夹放 Special ⼀个放 Common区分。不管怎么样，程序层⾯应该有这么⼀个区分。
通过这上⾯3种元素， 我们就能得到⾜够多的组合， 这样就能够完成新⼿引导的完整流程。 对于⼀些特殊的逻辑， 我们就为他单独开发⼀些特殊的节点， 这种东西没有办法， 就算是使⽤编辑器也没有办法做到完全通⽤， 毕竟确实新⼿引导本⾝就是⼀个很特殊的东西。 但是假如我们抽象的⾜够好， 特殊的节点也不是不能通⽤。
在这⾥我们也想到了⼀些问题， ⽐如假如玩家掉线了之后如何去做好再次上线之后的引导的衔接问题。 我估计每个做引导的⼈都会碰到这个头疼的问题。因为我们是demo阶段， ⽽且这次⼜特别紧， 所以这次定的策略是 我们指定某⼏个引导是 属于 保护期引导 ， 在第⼀次会议上， 我们定义的是 在这个期间如果玩家掉线， 那么服务器直接把玩家重置到这个引导流程开始的状态， 因为刚开始出来的时候都是强制引导， 所以玩家是不能操作游戏的， 这个逻辑应该能⾛通， 但其实特别⿇烦， 后来我们⼜修改成 当玩家掉线， 那么直接清号， 让他数据重置。 再次进⼊直接以刚登陆开始。 这样特别简单， 服务器和客户端都暂时不⽤做太多的东西， 先以Demo能跑为主。
但其实对于这种类型东西的处理，我也⼤概寻思过解决⽅案：
1.我们可以开发查询节点， ⽤于在⼀个脚本开始的时候，对玩家的当前的⼀些信息进⾏查询， 然后根据查询的返回结果，跳转到对应的 步骤， 这样可以跳过已经执⾏完成的步骤。
以指引玩家造⼀个建筑的例⼦举例：
我们提供⼀个GetBuildingStateEvenNode 这样的节点， ⽤于获取玩家的建筑的状态， 然后根据返回状态跳转到不同的节点：
NotBuild goto step1 （还没有建造，直接从step1开始）
WaitForHarvest goto step5 （我们的建筑需要点击收取， 从step5开始，指引玩家点击收取）
BuildOk goto step8 （已经建好，但是服务器没有当前记录的引导ID切换为下⼀个， 执⾏最后⼏步逻辑（展⽰⼏个⽂字框，然后告诉服务器我已经结束， 需要切换到下⼀步引导））
2.假如我们开发查询节点， 并⽀持跳转， 那么会出现⼀个流程错乱的问题， 简单的情况，
在上⾯那种情况下的 玩家建筑处于 WaitForHarvest 的时候， 正常流程， 玩家需要打开⼯具界⾯，
然后选中锤⼦， 然后敲击建筑，才能收取。 如果我出现跳步骤的时候， 那么我就需要去复现玩家从正常流程到现在的⼀个基本流程。
所以节点应该新增⼀个接⼝： OnSkip， 在OnSKip函数中，我们需要去处理⼀些，这个Node被跳过之后的情况， ⽐GUIClick节点， 可能我们就需要直接⽤逻辑去模拟玩家点击这个界⾯流程。这样就能还原玩家在退出之前的状态。但因为之前设计的步骤之间是可以随意跳转的， 所以可能我们并不能知道那些步骤被跳过， 这个时候可能就需要策划去添加属于被跳过，且需要执⾏Skip步骤。
这个过程我们其实可以简单归于掉线场景的还原。 对于⼀些需要玩家复杂的场景我们直接应该拆成⼏个新⼿引导流程。
⽽且每个节点的开始，尽量不要依赖上⼀个步骤的结束，⽽是直接以⼀个新的流程开始。
⽐如每个新⼿引导流程都从主界⾯开始， 我觉得从策划层⾯应该是可以办到的。 如果是 事件触发类型， ⽐如 等级到9级触发某个引导，但是这个时候并不知道玩家当时处于什么状况，我们可以直接关闭玩家的所有界⾯， 同时屏蔽掉玩家的所有输⼊事件，开始我们的新⼿引导流程。
这个其实还有简单问题是， 每个流程的Skip有可能并不是⼀个⼀帧之间能完成的事情， ⽐如打开好友界⾯， 可能我们在打开好⽤界⾯的时候， 需要向服务器请求数据才能打开，如果未请求到数据是不能打开。 所以对于Node的 Skip流程，也有顺序的要求。
写了这么多， 发现这样好像对策划的要求⽐较⾼。。 但是这个是没办法的事情，如果要做⼀个完备的编辑器， 从⽽脱离该改改的境地， 这个是必须做的事情， 要不然只能策划⾟苦， 要不然就是程序⾟苦。 但是程序⾟苦的话，其实还是策划去推动的结果， 所以还不如策划直接去⾟苦得了。
最后在说⼀个我和Teamleader在Node设计的时候的理念的不同情况
他在设计编辑器的时候， 倾向于把策划当傻⽠， 每个节点都是傻⽠式的节点， ⽐如⼀个简单的例⼦， CloseUIInput节点， 这个节点的作⽤是 关闭UI输⼊， 所有UI的点击事件，全部不响应，但是 Raycast的事件是可以响应的。
对于这种节点，我倾向于封装2个节点， ⼀个 CloseUIInput 节点，⼀个 OpenUIInput节点。 由策划⾃⼰去组合节点，达到⼀个在某个时间点开启UI输⼊， 然后某个时间点关闭UI输⼊， 说⽩了，我⽐较倾向于让策划以编程的思维去做新⼿引导流程的编辑。
如果是以他的理念去封装， 应该是 CloseUIInput 在Init的时候，关闭UI输⼊， 因为我们的node是并⾏的时候，所以在⼀个节点，我们加⼊这个节点，会被执⾏。 然后在步骤切换的时候，会调⽤ 节点的Reset ， 在Reset函数中 去重置， 开启UI输⼊， 这个过程策划⽆法⼲预， 如果有4步需要屏蔽UI输⼊， 那么策划需要在这4步中都要添加上这个节点。
这2种理念各有各的好处， 以他的想法去写的话， 策划在编辑流程的时候可能会⿇烦⼀点， 但是⾜够清晰，不容易出错，因为每个步骤需要什么， 你不能指望上个步骤给你遗留什么，因为都是原⼦的， 你需要⾃⼰给⾃⼰准备。 所以相当于强制初始化，检查的时候会特别⽅便。
以我的想法去写的话， 策划在编辑流程的时候，会更加的灵活，在我们编程的时候其实也⼀样， 组合的⽅式能够让程序的可变性和可扩展性变得格外的强， 但是缺点就是流程不太好检查。 出了错debug的代价会⽐较⼤， 但是我觉得这个不是特别⼤的问题。因为这个难度其实也不是特别⼤， 如果策划在新⼿引导的时候脑⼦是清晰的， 能够简单的画个流程图，把各种情况预先过⼀遍，其实完全没问题的。
最后⼀个问题， ⼀套完善的事件系统，这个我估计每个项⽬都应该会有， 主要有个问题是， 新⼿引导的事件以和业务模块的事件耦合在⼀起呢，还是应该单独独⽴出来， 做⼀个新的事件系统。 我个⼈⽐较倾向于独⽴出来， 因为这套事件系统应该主要给新⼿引导， 任务， 成就等使⽤， 独⽴出来能好⼀点， 这个仁者见仁智者见智。 随便怎么样都⾏
突然发现，有些东西还是要⾃⼰写出来， 思路才清晰。。就是时间花的多， 我这个基本没排版， 不知道别⼈写博客还要考虑排版问题， 还要截图， 粘贴代码的 ⼤概花了多长时间。。
新⼿引导其实还有好多细碎的东西， ⽐如基础节点的开发， 如： 指引点击⼀个控件， 指引 遮罩某个
物体， 或者指引 遮罩某块区域等，这些⽹上有多很教程，我也就不写。 我还是⽐较喜欢写⼀点⼼得之类的东西，因为做东西，其实思路最为重要，想通了就是下笔如有神。
本来以为这篇⽂章到这⾥就完了， 但是其实还没完， 第⼆系列⽂章问详细阐述⼀下再实际应⽤场景下， 遇到的⼀些问题.
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议