Project1

标题: 技能树如何设置会比较直观？ [打印本页]

作者: SailCat 时间: 2018-8-8 23:41
标题: 技能树如何设置会比较直观？
在开发技能树插件，其中最重要的一点是方便使用者配置自己想好的技能树。
例如以下技能树：
[001]治疗1：无前置要求
[002]治疗2：需要治疗1
[003]治疗3：需要治疗2
[004]还原：无前置要求
[005]还原X：需要还原、治疗3
[006]火1：无前置要求
[007]火2：需要火1
[008]火3：需要火2
[009]冰1：无前置要求
[010]冰2：需要冰1、治疗2
[011]冰3：需要冰2、治疗3

关于这个技能树怎么配置，有三种想法（绝不考虑写在RGSS中这种异端做法，不是所有使用第三方脚本插件的人都懂RGSS，并且知道哈希表如何构建的）
1. 通过在“角色”数据栏进行备注，内容如下：
#SkillReq: 1(0), 2(1), 3(2), 4(0), 5(3/4), 6(0), 7(6), 8(7), 9(0), 10(2/9), 11(3/10)
即通过指定每个技能的前置技能（没有前置写0）来指定

2. 通过在“角色”数据栏进行备注，内容如下：
#SkillSet: 0-1/4/6/9, 1-2, 2-3, 3/4-5, 6-7, 7-8, 2/9-10, 3/10-11
即通过指定每个条件下，能导出的技能来指定
和前一种备注方法相比，没有那个清楚，但是比那个简短

3. 通过公共事件指定，写法如下：

第一条是防止此事件被执行的，后面只需要交替使用条件分歧中的“技能学会”分支和增减技能两条指令就可以书写技能树。
这条初看上去可能比较直观，但其实做多了也没有那么直观，因为如果有20个技能导出最终技能的话，条件分歧需要写20层嵌套……

但这条最重要的特点是可以进行其他的技能树要求，因为“条件分歧”指令实在是太灵活了，稍微多写一些解析的话，就可以实现关于等级、能力值、职业限定等等。
（扩展的方法：条件分歧关于角色有个“姓名”那是可以任意输入东西的，在里面敲比如lv2, str300, class3就可以实现习得限定）

你们觉得哪种比较合适？

作者: 若得 时间: 2018-8-9 00:20
本帖最后由若得于 2018-8-9 00:22 编辑

不知为何特别想看那个20个技能导出的最终技能……
第一种比较合适的样子

作者: y967 时间: 2018-8-9 06:08
学习条件其实并不重要，主要是让低级技能不要被抛弃，技能的专属性和联动性，可以让技能发挥最大的作用，技能升级的级数尽量不要太高，5级差不多了，每一级的要求，经验或其他什么，要求高一点。

1，专属性，比如最初的技能火1，升到5级后，比中期的水技能1级的威力还差，但是这个火5有个专属性，就是对特定弱火怪有无视防御的效果，也就是说，中期有些敌人其他技能效果不好（其他属性防御很高），就可以用这个火5来打，另外，中级的火技能依然可以设置，不用取消。也可以用火5作为前置。

2，联动性，联合触发，火5和水5触发水火大招，比较简单，较复杂的联动，分支联动，低级的火技能有个分支，叫火B,低级的水技能有个分支叫水B,火B和水B可以触发分支大招，威力要比正牌水火大招小，但有一些特殊效果，比如迟滞。这种设计会让技能树很丰富，分支也多，可选择策略也丰富，但工作量也会多。

作者: 空值异常 时间: 2018-8-9 09:56
就我的感觉
实际上你一开始就已经设计好了最好的配置形式
只不过囿于各种桎梏直接忽略了这种方式

[001]治疗1：无前置要求
[002]治疗2：需要治疗1
[003]治疗3：需要治疗2
[004]还原：无前置要求
[005]还原X：需要还原、治疗3
[006]火1：无前置要求
[007]火2：需要火1
[008]火3：需要火2
[009]冰1：无前置要求
[010]冰2：需要冰1、治疗2
[011]冰3：需要冰2、治疗3

显然这么写是最清楚的
为了程序上更好写正则
可以拟定一套标准化格式

治疗2=治疗1+
治疗3=治疗2+ // 双斜杠后面算注释
还原=
还原X=还原+治疗3+

然后规则文本随便写在什么地方
通过程序读取就好啦
比如指定 10038 号公共事件中
只能写显示文章指令
读取其中的所有文章
拼接以后以字符串一行一行地解析

至于特技数据库该怎么编辑
还是按照原来的方式编辑
只不过编辑完成后
对应修改 10038 号配置的指令即可

需要注意的是
一定要在游戏开始的时候
对配置指令做校验
出错立即提示并终止程序
有利于排除错误

作者: 灯笼菜刀王 时间: 2018-8-9 10:20
本帖最后由灯笼菜刀王于 2018-8-9 10:33 编辑

技能树这种还是能直观设置的比较好, 毕竟对于大多数人来说, 技能都是想加就加为所欲为, 在小地方备注比较难修改和浏览。

所以咱推荐放公共事件, 可以通过角色备注关联至某个公共事件作为这个角色的技能树。

然后要使用技能名还是ID, 咱推荐用ID, 虽然ID不太直观,但是名字可能会随时修改, 比较容易引起BUG,

最后, 如何设置,  使用备注如何

1 - 2 - 5 - 7 - 8
1 - 3 - 4 - 10
   1 - 6 - 10
      9 - 10

左边是右边的前置, 有多个前置就重复写, 让设置的人自己拟个树状结构, 这样 20层设置也是前面多几串数字吧XD

作者: 空值异常 时间: 2018-8-9 10:27
话说回来
关于 20 层嵌套的问题
倒是有迂回的技巧可以稍微缓解一下

RUBY 代码复制

# 多层嵌套的写法
if(cd1)
  if(cd2)
    if(cd3)
      if(cd4)
        obj.doSth
 
# 迂回的写法
while(true)
  if(not cd1)
    break
  if(not cd2)
    break
  if(not cd3)
    break
  if(not cd4)
    break
  obj.doSth
  break

# 多层嵌套的写法


if(cd1)


  if(cd2)


    if(cd3)


      if(cd4)


        obj.doSth


 


# 迂回的写法


while(true)


  if(not cd1)


    break


  if(not cd2)


    break


  if(not cd3)


    break


  if(not cd4)


    break


  obj.doSth


  break

……我本来是这么想的
然后看了下 RM 的事件编辑器
eeeemmmmmmmm……
语法要素太匮乏了
连逻辑非操作都要好几行才能模拟
不过至少把 20 层嵌套压成了两三层的样子

作者: Kenshin001 时间: 2018-8-9 10:57
比较喜欢第一种，但是感觉在“职业”备注栏可能更好一点，技能树根职业对应，给职业设置完技能，然后旁边直接对照着备注
对技能加限制的话，在“技能”备注栏做类似操作可能更直观
对于第三种，太过直观了，一旦对某个技能或限制条件进行修改，对萌新来说，出错率可能比较高

作者: 89444640 时间: 2018-8-9 11:48
看了半天……除了一条直线的，
A1-A2-A3-A4
B1-B2-B3-B4
其他我想不明白ORZ

感觉可以这样试一下，随便画个树状结构，

用两种写法分别写一下的话，哪个能扔几天还能看明白，就是哪个直观。

作者: 越前リョーマ 时间: 2018-8-9 23:59
你写个备注来读取都好，这样事件设计反而容易麻烦

作者: 片灬翼の鳥 时间: 2018-8-11 04:45
看你什么技能数，普通角色等级（经验值）走的就是树状图结构，加点的就是8L那种，职业的不仅需要角色固定等级还有的需要对应角色属性（包括转职技能等等。。）

欢迎光临 Project1 (https://rpg.blue/)