开发了一个新手引导插件，争取做最好用的新手引导插件

Store
#21

应该用uuid 而不是id 不然中间删除id 还得去改代码

#22

你好，你说的用uuid指的是新手引导去查找目标节点时，使用节点的uuid来查找吗？这样会有问题，因为构建之后uuid就会发生改变，应该使用节点路径。

另外你说的id指的是什么 ？showGuide(1)方法中传入的数字是引导步序，不是什么id。插件生成的代码不需要用户去修改。

你是不是评论错帖子了还是我哪里没理解？ :no_mouth:

#23

是自己生成uuid 而不是用id作为顺序 我说的uuid不是node的uuid
showGuide(uuid,…)
怎么不需要修改? showGuide(5) 假如我把4删了 或 中间插入一个 不是要修改成 showGuide(4)

#24

用uuid来代表引导步序？比如这样：
第一步用：37663e76-18af-44d7-815d-5f61a535faa8
第二步用：b362122e-222c-4f6b-bf76-7931b14067ce

没开玩笑吧？

我说的不用修改指的不用去修改任何插件生成的代码。你把第4步引导内容删了，那在自定义脚本代码中把showGuide(5)改成showGuide(4)是什么耗时操作吗？还是你觉得后面的引导步序数字都要改？根本不需要，如果不需要第四步，那就直接把第四步showGuide(4)代码注释掉就好了，showGuide(5)还是原来的内容，数字完全可以不用变。

如果真用你的说的uuid不是也需要把原来第四步的showGuide(第四步uuid)这行代码删除？

#25

我给你举个更详细的例子，你在插件中生成了以下引导步骤：

  1. 点击按钮。
  2. 点击图片。
  3. 点击空白。

在脚本中你分别设置了showGuide(1)，showGuide(2)，showGuide(3)。

然后你改掉了引导内容：

  1. 点击按钮。
  2. 点击xxx。
  3. 点击空白。

在脚本中你还是设置showGuide(1)，showGuide(2)，showGuide(3)。只不过showGuide(2)的调用位置可能不一样。

你用uuid，你是不是还要专门找个文件记录下uuid对应的引导步序。。。？引导步序1,2,3数字本来就是不重复的，为什么要用更麻烦的uuid。

#26

uuid放在list里 写错了也没事 脚本indexof提示下 顺带在界面加个copy

#27

只是改个数字，多调用几个showGuide()方法，如果用uuid，也还是要多写几个调用。

我能理解你用uuid的点，但插件开发得站在大部分用户的角度。如果让用户去使用uuid来调用对应步骤的引导，就不太妥。用户要去看这个uuid对应第几步引导，如果引导不起作用，是不是uuid写错了，就要一个个去对。

// 调用第一步，
showGuide('37663e76-18af-44d7-815d-5f61a535faa8', False)

// 调用第二步，
showGuide('b362122e-222c-4f6b-bf76-7931b14067ce', False)

// 第三步引导的uuid是什么，得先去找下


// 调用第一步
showGuide(1, False)

// 调用第二步
showGuide(2, False)

// 调用第三步
showGuide(3, False)

在代码逻辑上也要专门设置一个变量或一个文件去存储uuid、步序和引导内容的关系，会让插件代码更加麻烦。

#28

uuid放在list里 写错了也没事 脚本indexof提示下
你都做成插件了 应该自动生成uuid 顺带在界面加个copy uuid的按钮
提供双接口也不是不可以的 自动生成一份uuid的ts或者js文件也不是啥难事

#29

但我真的不喜欢用uuid，为啥做成插件就一定要让引导步序用uuid。。。还要在界面加copy uuid的按钮。。。那用户不还是得去找第几步引导的uuid是什么吗。。。？

哥们要不你自己写个这样的插件吧，用uuid的。这个需求我真的不想加。

#30

只是提个建议

#31

嗯嗯好的 :smiley: :heart:

#32

实际开发中 策划确实会不定期改需求

#33

是的，理解 :heart:

#34

可能他的意思是每个步骤生成一个唯一的标识ID，不知道你的步骤是否是根据1、2、3这样顺序执行的，如果是的话那你增删步骤的时候其他步骤的id都要变动，还有一点你的引导是否支持跳转比如引导做到一半退出了第二次进入的时候是否能恢复，最后还要考虑一点是否能保证步骤的确定性比如引导数增加了但是游戏内容却没有实际同步导致再次进入游戏可能卡死在引导中当然这点要服务器配合

#35

差不多是这个意思

#36

可能他的意思是每个步骤生成一个唯一的标识ID，不知道你的步骤是否是根据1、2、3这样顺序执行的，

插件生成的引导，可以连续执行，也可以分步执行，比如showGuide(1, False)执行第一步，然后直接showGuide(3, False)执行第三步。


还有一点你的引导是否支持跳转比如引导做到一半退出了第二次进入的时候是否能恢复

用户如果完成了引导可以用localStorage()在本地记录是否已完成新手引导。如果进入游戏发现没有对应的本地记录，应该重新开始引导。


最后还要考虑一点是否能保证步骤的确定性比如引导数增加了但是游戏内容却没有实际同步导致再次进入游戏可能卡死在引导中

如果要改变引导的话，那必然会在插件面板中修改引导内容，那插件最后生成的代码也会有所改变。用户只需要在自定义的脚本中调整showGuide()方法即可。

目前以上讲的几点插件都有考虑到。


如果是的话那你增删步骤的时候其他步骤的id都要变动

这一点的话，如果使用uuid，确实可能会好一些，不需要修改那么多的数字。但是uuid确实看上去没有数字简洁，而且我个人目前认为让用户修改数字和让用户使用uuid比起来，我还是更喜欢让用户使用简洁一点的接口。

各有利弊吧，这样讨论挺好的。谢谢两位 :heart:

#37

用户如果完成了引导可以用localStorage()在本地记录是否已完成新手引导。如果进入游戏发现没有对应的本地记录，应该重新开始引导。

举个例子 新用户200金币 步骤4 5 6 跳转商店购买商品 花光了200金币
或者把456改成 789 就导致重复了步骤 或者重置到0了
或者需求修改了 直接卡流程 然而你不能判断用户的热更是从哪个版本跳上来的

#38

所需策划改需求 导致整个游戏改崩了 然而流程改了几个版本 不好做判断和抢救措施

#39

存在本地那是肯定不行的问题太多了，首先存在本地用户会删就算不误删他换部设备玩游戏你怎么办，还有在举个例子你步骤存在本地我猜测你调用showGuide的时候步骤就存起来了,好了现在你步骤是存起来了但突然发生不可预知的错误或者断网玩家的实际操作确没有同步，游戏前期特别是引导阶段很多资源是相互依赖的你这步引导没有做那么就得不到下一步的资源，现在你步骤是保存了资源没获取是不是这引导就进行不下去了卡死了诸如此类还有等等问题！
总结你直接把步骤保存在本地很不稳定很容易出问题建议提供接口保存在服务端与服务端同步，当然也不必每一步都同步可以只同步有对游戏资产或者属性进行操作的步骤。当你只保存一些关键步骤的时候那么引导就要提供随意跳转的功能以便恢复引导。。。

#40

你举得例子有点乱我没看懂，不过你提到了热更，我觉得你提的uuid有点道理。

但是，你可能有点把我这个插件的功能想得太多了，我才开发了一个月不到。目前我只是想让这个插件实现游戏中的新手引导。如果你要让这个插件考虑热更，那代码量远不止这些。

另外，我觉得也没有必要让这个插件支持新手引导热更什么的，如果你一定要判断版本，为什么一定要用这个插件中的新手引导代码完成？自己另外加下不就可以了吗。

我还是喜欢简洁，太多的功能反而让用户摸不清头脑。