关于使用铃心完成的文游功能其内部的“代码”结构介绍。
更像是一个“小黄鸭”帖子,只是我一个人的呓语而已,如果对大家有帮助,那就再好不过了。

编辑于2020.3.13 转载请注明作者

核心设计部分

基本的读取文本结构#回复块

因为文游系统是基于大量文本和模组的,因此不能全部储存在配置.ini内,需要一个外部读取标准格式文件的方案。

关于读取外部文件的方式,一般有以下几个方案,分别是:

  • 配置文件形式(对于较少和结构简单的文本)
  • JSON形式
  • 自定义文本形式(. . .嗯)

这里我采用了Json结构,并且写出了一个最简单的样例:

其中,我们需要理解几个关键词的含义

如果采用配置文件的方式,也可以构建出这样的简单回复系统,并且从某种角度上来说,用配置文件构造出来的更加方便后续的编写。

那么现在就要开发读取这个形式回复的铃心代码了。

上面的代码只能够读取reply中的的回复内容,并不能将[w]和[h]给进行变换。
而且其他的回复,虽然表面看起来是可以直接输出然后后面自动延时,但是实际上必须要用【输出流】进行输出,否则会进行同时的延时。

在这种方案下,reply内部是可以调用铃心代码的,因为在

这个读取赋值的过程中存在一个读取、一个反转义。读取的时候,会将reply内部所有的【】转化成#zzk和#yzk,而在反转义执行之后,就又会将读取到的#zzk和#yzk首先转义成【】。
紧接着,根据铃心的执行顺序,在赋值的时候就会执行一遍reply中的代码,因此此时就会产生一个结果。

但是尽管可以在reply中调用铃心的代码,但是使用很多的铃心代码难免会遇到使用[]的时候,进而导致一些难以预料的混淆情况。
为了避免出现混淆,我们可以在Json中添加一个run的代码块,在reply执行之前优先处理run中的铃心代码,然后在reply中仅仅调用【变量】之类的简单代码块,简化结构。

格式修改成这个样子之后,我们需要进一步完善上面我们已经完成的体系。

这样,基本的读取方式和执行方式我们就添加完成了!

“是”、“否”跳转结构

初步的想法就是,当输入是之后就会触发关键词,通过已知的常量进行跳转,调用上文1-1提到的基本读取执行模块就可以了!

因此有了以下的代码:

首先解释这里的【防重发开关】的作用。
要知道,以时间为推进的文游,很容易出现一种情况——机器人话还没说完,玩家就输入了下一步的“是”或者“否”,进而导致了提前触发的情况出现,最后游戏混乱爆炸——
因此,需要一个防重发开关,在检测到重发之后,就直接【返回】(相当于!null)终止掉后文的调用。
为了让防重发开关能够被正常重置,在1-1的输出流结尾应该有一个赋值常量部分

除了防重发开关之外,细心的你可能也注意到了——在最外层套了另一个开关系统。这个开关的目的是为了解决文游结束时,触发“是”和“否”对于游戏的影响。

对于“否”跳转,跟“是”跳转采用的是同样的逻辑,只是把Json读取改成了读取nt而已。

文游开始&结束声明

那么,我们有了基本的读取模块和跳转模块,剩下的就是结束模块和开启模块了。

结束模块的书写可以说是相当简单——你只需要让跳转模块最外层的开关关闭,就可以达到结束模块的目的了(当然你也可以进行一些恢复初始量的操作,不过定义初始量我还是建议在开始的时候声明而非结束)
或者你可以干脆像我一样把其作为一个保留词装在run块里

这样,只需要在run声明一个[end],整个文游就会终止于这个回复——或者说,文游就可以在此重新开始。

以下为进入文游的模块。

附加设计部分

人物状态部分

在制作这个的过程中我一直都在想怎么增加游戏性——随后我就意识到,可以让玩家随时查询对象的状态(state)来猜测对方有没有说谎之类的。为整个剧本带来更多的活力。
因此,就有了下文的代码。
注意:由于我是在编辑器上进行编写,因此函数部分仍旧是以{@}的形式表述。

在这里,制作者可以通过一个state块来声明角色的当前状态,并且将其保存在文件中。
玩家可以在任何时候查看这些state并且猜测作者的意图。
除此之外,还加入了对一些卡片的兼容。

位置卡片兼容

接着上面的想法,后续可以做一个查询人物当前地理位置的功能——又或者说让对方主动地发送位置给玩家?
不管怎么样,位置卡片会让整个游戏变得更加真实且可信,更容易产生互动感。
相类似的,制作者也可以加入音乐卡片之类的来提供BGM——不过关于BGM我更推荐将其直接放在reply中发送出去。

于是乎,我们完整的Json结构终于确定下来了:

至此,关于新版本的文游系统介绍,就可以告一段落了。


我什么都不懂,我只会现学现卖,谢谢配合。