Webgal杂谈：苹物语#

大家好，我是琴泠。

严格来说，这是我第一篇正儿八经的博客文章，真是有些令人感慨啊。

请忽略那些吐槽版的回复，现在我们来讲一些正经的话题。

在2025年的4月19日，我在小红书上正漫无目的的刷着帖子——彼时的我正刚和社团的同学们讨论完avg文游的制作任务分配，正在盘算到底使用哪个引擎好。

在最开始的讨论中，我首先将目光放在了unity，renpy和webgal上。Unity的成绩无需多言，丰富的社区生态，完备的插件功能，对于任何游戏开发者来说都是极好的引擎。不过对于高度集成化模块化的视觉小说游戏品类，针对视觉小说所研发的引擎也很具潜力。我想先对没有接触过程序开发的朋友多说两句，对于没有接触过的东西，理所当然的认为很困难是正常的…但只要选对工具，开发的难度就会比想象中要简单很多。

只要你愿意，PPT也可以用来当视觉小说的引擎，只不过跨平台兼容性就大打折扣了，而且没办法打包成应用程序（话说…好像也有可以把PPT转化为视觉小说的引擎吧？）

说过头了，在过去相当长的时间里，renpy几乎是业界最受欢迎的视觉小说引擎，在使用热度上仅次于unity（Unity由其在团队合作上的远程便利性，而小成本的单人开发则完全不需要用到这些繁重的功能），热度在renpy以后的引擎，例如GameCreator和RPG maker，都具备着一个显然的劣势——它们是商业引擎。

如果您熟悉unity的开发，应该对前不久的收费政策忽然变卦的事情有所印象。那件事让我坚定的相信小型游戏必须要使用开源的引擎去制作，即便要自己造一些轮子…商业引擎是难以信任的。

事实也正如我所预料的那样，作为商业引擎的Unity，GameCreator，RPG maker的使用率在25年时总计下降了5.27%，而开源免费的Renpy和Webgl使用率却在上涨，仅Webgal就上涨了3.5%（请留心这个增幅。Webgal近两年非常火，有相当多的游戏都使用webgal的进行开发，甚至b站有一些百万级别粉丝的博主，也使用webgal做小剧场前段。（你问我怎么知道的？🤓我冲浪的速度还是很快的，不要小看我的情报网啊.jpg））。

我想，这些游戏制作人们应该有意识的发现，小型游戏并不能太过依赖商业引擎。这也是后来让我决心深度研究webgal这个引擎的关键原因。

虽然和学弟学妹们共创的那个企划后来遗憾离场了（没关系，每个制作人都会经历这样的事情），但在那个下午，我刷到了一个美术留学生——纳豆拌饭老师求问文游程序的帖子。

此时的我刚完成三个引擎复杂度的调研，于是顺便私信给别人推荐了Webgal。当时我的想法很简单：

• 纳豆拌饭老师提的需求并不复杂，没必要看小红书上这些人坑她的钱，而且这些人能不能做出来也是一回事，纳豆拌饭老师的目的需求是做毕业设计，很容易被有心之人恶意抬价。

• 而且纳豆拌饭老师完全没接触过代码，而Webgal有零代码的视觉编程功能。考虑到当时我还在跟同学讨论另一个游戏，跟我同一个企划的其他人基本上也没有编程经验，在这方面Webgl是明显要优于renpy和unity的。（但我不得不承认，renpy内置的图形库所能达到的上限确实不是现阶段Webgl能实现的。）

• 此外我想借对方之手测试一下Webgal的潜力，此时的我对这个引擎并不算很熟悉，也不清楚一些深度定制的功能，不花额外成本的情况下，让别人帮我测试是一个极好的选择——再怎么说，webgal也比unity强的多，而对于程序外行来说，webgal的视觉化功能也比renpy内置的脚本语言强。

或许是ddl的压迫感太重，或许是纳豆拌饭老师所用的mac电脑的适配性不友好，大约一星期后，纳豆拌饭老师就垂头丧气的跟我说：

“我好像弄了半天都没搞懂，时间紧张，价不是问题，然后技术方面会写你的名字。”

坦白的说，没有任何一个乙方看到这句话能不心动，清晰的时间需求，充足的预算，还有超棒的尊重。（这是我非常想吐槽的，那之后和那之前我约稿时，经常会遇到不署名的情况…）

于是我们很快签订了电子合同，开始干活。有个意外的插曲，对方的原始剧本写的非常意识流，而且篇幅太短（完全没办法作为毕业项目），纳豆拌饭老师在看到我还有文手业务后，就干脆连文章也一块发给我处理了。

由于剧本的原型是对方的oc，因此我没有在剧情上做太多改动，只是略微扩写了一下句子，改文的工作很快就完成了。接下来是硬骨头：webgal。

Webgal的脚本语言非常简单，基本的台词格式是这样的：

1
角色名:台词;

是的。游戏绝大多数篇幅都是这样简单的形式，只要按部就班的填入台词，就能够实现最基础的演出效果。而其他比较基础的功能同样并不复杂，也是一句代码可以写完的。

我很快就完成了程序的开发部分，其中还遇到了很有意思的麻烦：

游戏有两条线路，每条线路都对应着三个结局，我处理结局的跳转逻辑是通过变量累积来处理的，进入哪条线路由最开始的选项决定，进入哪个结局由玩家所选的选项对应的变量决定，例如：

1
satVar:line_1_he ++
2
//he＝ happy ending，线路一的好结局变量值+1
3
setVar:line_2_be ++
4
//be = ban ending，线路二的坏结局变量值+1

很快我发现了一个令人相当无语的问题：这个脚本语言居然不支持++这种语法，如果你想写自增，得老老实实写

setVar:line_1_be = line_1_be +1;

不过这并不算什么麻烦的问题，调试这个问题也很简单，在每次变量增加后，都在其后方加一个输出打印，就能够检测变量的变化：

角色名:line_1_be的值是{line_1_be}

大括号内加变量名就可以输出变量的值，这个语法能让你写出很多神奇的效果，例如，不过在此之前我们还要先熟悉另一个语法-when

1
setVar:有病吧。 -when=fa=0
2
setVar:你是大笨蛋！ -when=fa=1

when语类似“if then”，当后，续变量的判定条件满足时就执行当前的内容，否则什么也不发生。

1
getchar:你的名字叫什么？ pname
2
//pname is player name

只要在这里记录下了玩家的名字，就能在以后的任何地方使用这个名字，例如：

1
{pname}:真希望我们能一直成为朋友;

纳豆拌饭老师的美术功底十分扎实，绘制了相当多好看的图片，我也勉强是个人，在规定的时期内完成了游戏程序的开发。不过因为是毕设，还要做英语版本，本人英语苦手无力协助，加上彼时引擎的多语言功能并不完善，只能帮忙协助导入文本了。

所以chatgpt老师的翻译实在是太好用了阿23333333

尽管现在已经可以通过 setVar temp = ($userData.optionData.language) 来获取ui语言，然后使用 when 来跳转到对应的语言版本，不过我们当时还是不会弄这些，一番纠结之下我也是相处了一个神人的解决办法：

“要不导出两个版本吧！”

坦白说！我这辈子绝对不会再弄这么搞的了！

回顾整个项目，虽然一开始略有曲折，而且做的并不算很精致，但借此让我深入了解了webgal这个引擎。我必须指出这个引擎还存在很多不足，但web的兼容性也是无法忽视的优势，几乎可以在任何平台完美播放。此外，web原生的css动画也是一大优势，这意味着用户只要简单编写css代码，解释器就会做出非常丰富的动画效果，这一点是远远比其他引擎强大的。Scss编写的ui样式上限也极高，可以配合自带的脚本语言实现丰富的效果，用 applyStyle: -when= 来实现复杂样式的实时切换，能够实现不逊于renpy引擎的演出效果。

本文已获得 纳豆拌饭 老师同意。