Import other YAML files in config file. about ayaka HOT 12 CLOSED

我个人觉得非常有必要

（看起来目前尚无其他人，因此就形式从简改采中文做回复了，需要翻译的话我再补）

1. 目前的文件树结构把剧本、元数据和配置信息都混在同一个config文件中，缺乏层次感
2. 对长剧本而言显然不能指望它在一个脚本里就写完（毕竟正常的一部视觉小说怎么说也要三五万字，也才刚刚算小短篇吧），因此允许拆分为start/end等多个文件是必要的，但并非强制要求拆分，部分时候可能也只存在一个文件（但还是应当单独分离出文件去，原因见1，它不应是可选的）
3. 记得要求拆出来的多个脚本，要按语言代码组织文件夹，简中的start.yaml和end.yaml，一定放在zh-Hans文件夹下

@Akarinnnnn 也来说说看？可以先看一下这两个目前较为完善的例子

• https://github.com/Uni-Gal/Ayaka/blob/master/examples/Gacha/config.yaml
• https://github.com/Uni-Gal/Ayaka/blob/master/examples/Orga/config.yaml

from ayaka.

我想，如果拆分出去，有两种选择：

• 一个文件就是一个 paragraph，类似 Java 一个文件就是一个 class 的要求。这样做允许动态加载，但是考虑到文本几万字也没多大，IO 可能不是瓶颈。也就是说，选择了动态加载对于性能的提升有限，而且如果动态加载的优化不好，反而不如在一开始全读入。
• 不限制文件与 paragraph 的对应关系，加载时读取文件夹下所有的 YAML 文件。这样做只能在一开始读入所有文件。

from ayaka.

还有一个思路：引入可见性。一个文件可以有多个 paragraph，但是只有一个是 public，其它的是 private。

例如，对于 start.yaml

- tag: start
  next: foo
- tag: foo
  next: bar
- tag: bar
  next: end

以及 end.yaml

- tag: end
  next: foo
- tag: foo
  next: bar
- tag: bar

两个文件中都只能看到本文件中的 foo 和 bar，但是 start.yaml 中也能看到 end。

这样就可以允许动态加载，还可以对小文件做预加载的优化。例如小于1M的文件可以预加载到内存，而大文件则可以动态加载。

from ayaka.

• 大方向没问题。建议下次更新开始，强制使用新结构。
• 启动时预加载yaml脚本，进入章节前预加载资源。

from ayaka.

现在对于资源还没有预加载机制，但是浏览器内核可能会做一些缓存。Live2D 模型（由于前端性能差）有缓存机制。

正在做文本资源和段落文本的分离，虽然理论上可以做动态加载，但是也许可以放一放，先把全部预加载的做出来。

from ayaka.

• 启动时预加载yaml脚本，进入章节前预加载资源。

依据 #3 中 #7 (comment) 所说的，“设置某个 locale 时加载对应语言的资源和文本。这一步通常在加载设置时会触发，在设置页面切换语言也会触发”，不知道这样会不会造成切换语言的时候性能压力徒增？

（如果有可能的话其实会希望这里能把界面设置和全量的文本分离开，设置界面切换语言的时候不会同时加载新设定的语言的剧本，但是既然Berrysoft/gal#29 暂时并未有合入计划，我觉得等等再说啥的都行~~（哎呀我也好随意哦）~~）

from ayaka.

两个文件中都只能看到本文件中的 foo 和 bar，但是 start.yaml 中也能看到 end。

其实就目前来看，大部分Gal引擎里面这类标签都是全局的。我个人其实倾向于这类标签是全局可见的，可能我这点上比较保守，因此我就不过多干预了。

from ayaka.

不知道这样会不会造成切换语言的时候性能压力徒增？

只是纯文本我很怀疑会不会带来很大的压力。尽管io是同步的，但是它们都运行在异步的runtime上，至少不会导致假死

from ayaka.

我个人其实倾向于这类标签是全局可见的

如果以后要做部分文本的延迟加载，就不能全局可见。

from ayaka.

纯文本我很怀疑会不会带来很大的压力

纯文本需要的计算量应该不高

from ayaka.

确实。那，对大yaml脚本的预加载和延迟加载……看来确实不必要？（顺便就把label全局化吧）

之前我和Akarinnnnn还口嗨过4G内存的文本在32位下要溢出的问题，然后结论是怎么可能有那么多文本（扯远了）

至于对assets的预加载其实可以往后再说，而且到底是引擎主动预测式的预加载，还是用户手动指定预加载，这也是可以讨论的？（不过目前允许用户控制预加载的我倒只见过橙光）

那看来还是把决策权交回给核心开发者berrysoft吧，咋整都有出发点的（#7 你自己来合罢）

Offtopic:

from ayaka.

确实也许是不必要的，我也不太喜欢现在这样，有些额外增加复杂度。

我决定不搞延迟加载了。

不延迟加载，然后学柚子社，增加一个双语对对照功能，一会开issue。

from ayaka.