如何程序化地调用WebGAL的API

[linonetwo]

例如作为中间件嵌入已有的游戏，实现类似明日方舟塔防之前有过场剧情的效果。

然后更新剧本时，应该只使用编辑器导出的game文件夹里的内容即可。还需要通过 API 选择当前播放的是哪个剧情片段。

[linonetwo]

逛了一下源码，看到 Core 里大部分内容其实不涉及 react 和 pixi，能不能将它们发成一个包，这样在希望体积较小的场景里，可以避免引入 react 和 pixi，而只使用逻辑部分了。

[MakinoharaShoko]

API 的调用我认为是可以有的，只不过我们一直没时间做。而提取 WebGAL 的内核单独发一个包，可能要等到下一次重写内核。目前 WebGAL 的人手以及开发时间都是相当有限的，所以大版本更新重写内核这样的事情可能需要很久。

[linonetwo]

那我先自己打包一个 JS 放到 https://tiddlywiki.com/ 上面用。这个环境因为是纯浏览器笔记应用，对大小要求比较严格，react 是抽成单独的插件为所有其它插件共用的，所以我得改改 vite 的配置。如果 Core 和 react UI 部分，能分成两个 npm 包，就可以在用户侧再编译，在用户侧配 esbuild 的配置而不是在这个仓库里改 vite 配置了。

我也得想办法把 react 部分和 Core 部分分开 build，这样我可以在使用时自由组合 react 部分，跳过初始界面等直接从别的游戏玩法进入剧情。

[linonetwo]

要作为库使用的话，initializeScript 需要从 react props 里读取信息，例如获取资源获取器，从而让 assetSetter 能从内存获取已经被主游戏加载好的资源，或使用主游戏的资源加载器。

由于要改的地方比较多，我先假设很长一段时间内编辑器和 Core 之间的接口不会变化，所以我先 fork 一个版本，把 Core 改造一下，然后 react 部分用轻量的 wikitext 重写，Core/gameScripts 里调用 redux 的地方也改为调用我的状态管理库，以便嵌入 Tiddlywiki。

如果要正式抽象为库的话，和 redux 、资源获取有关的地方应该都得允许用户注入逻辑了。

[MakinoharaShoko]

是的。由于在设计之初没有考虑过单独把 Core 拿出来用的情况，所以 Core 里面出现了许多和 View 耦合比较深的逻辑。按理说这些都应当从外部注入。如果要改造的话，可能是一个很麻烦的过程。