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

编辑于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结构终于确定下来了：

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