众多Gal引擎中，我们做了个不一样的NarraLeaf

毕竟是视觉小说（GalGame），引擎选择多了去了……

所以说在如今这么多视觉小说引擎的情况下，我们应该选择什么呢？我想无论选择什么都是正确的，但我们不能只看眼前，更要看未来，那么未来又是什么呢？

让我们想象一下，游戏项目刚立项时，一切都很美好。一个人、一个文本编辑器、一份脚本，第一幕Demo很快就能跑起来。可一旦项目开始变大，开始向更多字数，更多游戏流程发展，那又会是什么样呢？

剧本写到第十万字，想找一句台词得用全局搜索才能看见；美术换了一版立绘，不知道哪几个场景还在引用旧图；两个写手同时改了同一章，合并时对着一屏文本差异发呆；翻译发来一份表格，谁也说不清哪些句子在原文改过之后已经过时；要发体验版、完整版、再加一个 Steam 版，只能复制出三份工程……

这些问题，大多不是“写剧本”的问题，而是“管理一个软件项目”的问题。成熟的软件团队早就有一整套工具来维持这份纪律：搜索替换、引用查找、版本管理……而传统视觉小说引擎往往把这些交给开发者自己想办法。

而NarraLeaf注意到了这一点，因此，我们想做一个不同的视觉小说引擎，一个让团队无需考虑过多事情的引擎，我们的目标就是要让各位像构建现代软件一样构建视觉小说。

何为NarraLeaf

NarraLeaf 由两部分组成：

• NarraLeaf React： 底层引擎，基于React和TypeScript开发的视觉小说框架，我们已在《前端人想做视觉小说？这个 React 框架有点离谱！》这篇文章中提及，在此不过多赘述。
• NarraLeaf Studio： 也就是这篇文章的主角，一个桌面端的视觉小说集成开发环境（IDE）。集剧本创作、界面编辑、资源管理、本地化、版本管理与打包发行等功能放在同一个软件内，全程都不需要写任何的代码。

NarraLeaf React面向会写代码的开发者，而NarraLeaf Studio就像是一辆准备好的车，即使不会写代码，也能完成视觉小说游戏的创作。

像现代软件一样构建

我们没有另起炉灶发明一门脚本语言，而是站在现代前端技术栈上：引擎基于React与TypeScript，Studio基于Electron。这些技术将带来什么好处呢？

Studio的开发模式和最终打包出来的游戏跑的是同一套运行时，预览就是在真实地运行游戏，你可以从剧本的任意一行直接启动，并随时查看当前变量的快照。

它有清晰的分层：剧情、界面、逻辑、资源各自独立存储、各自编辑，而不是全部塞进一份越写越长的脚本文件里。改变界面的UI不必动剧本，重写剧本也不会弄坏界面。

Studio拥有完整的插件体系，插件可以贡献蓝图节点、界面控件、语言包、测试和原生辅助进程，并出现在与内置功能相同的位置。插件需要的权限也会在安装时主动确认，目前，我们在Studio内置了一些插件，而针对于Steam 成就功能，在插件市场中安装即可使用。

这就是我们认为现代软件该有的样子，核心稳定且边界清楚，能力可以按需接入。

易用与灵活，小孩子才做选择

我们发现，视觉小说引擎长期面临一个两难：基于脚本语言的引擎，上限虽然高，但要是想让策划、写手参与到开发过程来，就要让他们学会编程。一些纯可视化的工具呢？门槛低，但项目一旦复杂就容易碰到天花板。

Studio的答案是分层：让写手用最顺手的方式写剧本，做UI、UX的人能用足够强大的工具做这些。

在经过长时间的打磨之后，最后交上这份满意的故事编辑器：在Studio里，一个场景由一行一行的内容组成，直接打字就是对白，在行首敲下一个“/”（简体中文输入法下也可以直接敲 @），就可以调用大约五十种故事命令：显示角色、切换背景、播放音乐、设置变量、分支选项、条件判断、镜头运动、转场特效等……每一条指令都支持中文写法，输入时自动补全，参数错误当场提示，以防运行的时候才发现出了问题。完成的场景可以直接切换到流程图视图，一眼便知故事的分支，从哪里跳到哪里。已有的剧本文稿，只要符合格式，Studio就能引导你把这个故事完成导入。

做出真正属于你的游戏界面，来用界面编辑器和蓝图吧！标题画面、存读档、设置、对话框……这些界面都是在画布上摆放控件做出来的，操作方式更接近于Figma、JSDesign这些原型设计工具。我们内置了十六种控件，从文本、图片、按钮、滑条到对话框、选项列表、NVL 文本框一应俱全。控件可以保存为可复用的组件，属性可以绑定到游戏运行中变化的数值上。

界面的行为交给蓝图，也就是可视化逻辑系统。Studio 提供六百多个蓝图节点，覆盖存读档、音频、本地化、输入、截图、回想日志、网络请求等方面，不写一行代码也能搭出一套完整的游戏系统。不想从零开始的话，还可以去界面模板商店直接套用现成的模板。

角色演出，我们支持PSD的分层立绘，可按表情、服装等维度组合差分，同时也允许接入Live2D和Spine模型（出于授权原因，需自行寻找导入对应的SDK/Runtime）。Studio也提供了现成的转场效果与镜头特效。

为团队协作而生

独立创作者可以靠记忆去管理项目，但对于一个制作组来说，答案肯定是不行的。

如今的项目管理，多半是外置的Git，对于Git不熟悉的用户，还可能要花更多的时间去处理项目冲突，如何推送这些问题。因此，在Studio中，我们将版本管理放在了软件里面。Studio自带完整的版本历史，不使用Git而是基于Epic Games开源的Lore版本控制系统，你可以随时提交一个版本，Studio也会定时自动存档，团队成员不需要学Git，也不需要安装任何额外的工具。

更重要的是，Studio不只是会告诉你改了什么文件，还会告诉你改了什么地方。差异视图会直接列出哪个场景、哪一行、哪个角色或是哪个资源发生了变化。如果两个人改到了同一处，Studio提供了专门的冲突处理界面，远比一堆看不懂的符号强。

NarraLeaf Team是一个可以放在自己内网或云服务器上的协作服务，团队可以共享同一个项目。团队成员可以在项目内发起讨论，留下评论。实时协作功能目前仍在完成开发。

为长期做准备

一部商业视觉小说的开发周期往往以年计。项目越久，越需要工具帮你记住那些人记不住的事情。

• 项目检查： 七十一条检查规则，覆盖剧本、蓝图、界面、变量、资源等方面。跳转目标不存在、资源丢失、变量未定义等问题在打包前就会被拦下来，不必让玩家当试错的小白鼠。
• 全局搜索： 剧本文本、资源、变量、界面文案、蓝图节点，都能在搜索框中找到。
• 引用反查： 任何一张使用的图片，一段音频，都能查到它在哪里被引用，在删除之前心里有数。
• 项目仪表盘： 项目规模、各角色台词量、本地化进度、每日字数、构建记录，项目进展一眼可见。

还有命令面板、自定义快捷键、可自由调整的面板布局……这些现代 IDE 有的，Studio 也会有。

面向商业发行

做完游戏只是开始，发行才是商业项目真正的考验。我们在本地化、配音管理、多发行以及发行平台上做足了准备：

本地化是一条完整的流程：剧本、界面文案、角色名都可以翻译。Studio 提供翻译和审校两种工作模式；原文改过之后，对应的译文会自动标记为过期，不会悄悄漏掉。翻译稿允许使用CSV、XLIFF、PO、JSON 格式导出，交给译者或翻译平台，再原样导回。玩家在游戏里可以即时切换语言。

配音有专门的管理方式。每一句台词的原文、译文和语音用同一个标识关联在一起，批量导入语音文件后，逐条对应、逐条确认。配合可嵌套的音频总线（背景音乐、音效、语音，以及每个角色单独的音量），混音既能由作者设定，也能留给玩家调节。

通过“构建变体”，同一个项目可以打出体验版和完整版：体验版在指定位置结束，之后的剧情和只被那部分使用的资源都不会打进安装包。游戏发售后的剧情修订、翻译更新、语音补充，可以通过补丁推送给玩家，不需要重新安装。

六大平台，一下搞定。Studio提供Windows、macOS、Linux、Web、Android、iOS，共八种打包格式；Studio 也支持各平台的代码签名，并提供可选的资源保护功能。它还可以在没有界面的情况下从命令行构建，并输出结构化的构建报告，方便接入团队的自动化流水线。

不如实战试试

功能介绍说得再多，也不如真刀真枪做一次。我们向先前合作的一个制作组申请了一份授权，把他们已经完成并发行的Ren’Py作品完整移植到了NarraLeaf Studio当中。不过这次迁移交给了AI Agent完成，由Agent阅读原作的脚本等代码，将其转换到Studio内。移植后的工程规模如下：

• 剧本： 约一万行，共五个结局
• 角色： 30+个角色，包括4位主要角色共400+套立绘差分
• 资源： 1500~个资源文件，300+条配音完全对应到台词
• 鉴赏： 30+CG全部进入鉴赏模式
• 界面： 20余个游戏界面，10余个可复用组件，300多张蓝图

结果是：原作九成以上的剧本语句都能在 NarraLeaf 中找到直接对应；Studio 的项目检查没有报出一个错误，所有场景全部编译通过。少数依赖 Python 自定义逻辑的系统，则改用蓝图重新搭建。

这件事说明了两点：

第一， NarraLeaf 的表达能力足以承载一部完整的商业视觉小说，不只是能做出示例小品。

第二， NarraLeaf 的工程结构清晰到 AI 能读懂、能写对。剧情、界面、逻辑分层存储，每一处改动都有检查兜底，Agent 生成的结果就能被逐项验证。而且整个移植过程可以重复执行：调整了某条转换规则，重新运行一遍，得到的仍是同一份工程，版本差异干干净净。对手里已经有 Ren’Py 项目、又想换个工作方式的团队来说，这是一条走得通的路。

从一个骨架开始

看到这里，你可能会觉得：功能这么多，上手会不会很难？

其实不用从一张白纸开始。在 Studio 里新建项目时，选择“骨架”模板，你拿到的就是一部已经能玩的小型视觉小说，包含三个场景、一次分支选择，六个完整的游戏界面以及中文、英文、日文三个版本。按下预览，它就能从标题画面一路玩到结尾。你可以把它当成一份活的教程：看看一行故事命令是怎么写的，一个存档按钮背后的蓝图是怎么连的，然后把角色、立绘、剧本逐一换成你自己的。对新手来说，这是最快的起点。

选择

我们尊重每一款优秀的引擎。Ren’Py 和 TyranoScript 都支撑过大量出色的作品，也有 NarraLeaf 目前无法比拟的成熟生态。下面展示的表格不是好坏对比，只是一个取向：

对比维度	Ren’Py	TyranoScript / TyranoBuilder	NarraLeaf Studio
创作方式	专用脚本语言 + Python	标签式脚本 / 可视化编辑器	命令式故事编辑器 + 可视化蓝图，无需写代码
界面定制	Screen 语言与样式代码	脚本、HTML/CSS	可视化界面编辑器 + 组件 + 数据绑定
团队协作	依赖外部工具（如 Git）	依赖外部工具	内建版本控制，按内容显示差异，可自托管协作服务
项目管理	以脚本文件组织	以脚本文件组织	分层工程，项目检查、全局搜索、引用反查
本地化	支持，基于脚本提取	支持程度视插件与方案而定	内建翻译 / 审校流程，过期检测，四种交换格式
扩展方式	Python	JavaScript 插件	React / TypeScript 插件体系
成熟度	非常成熟，社区庞大	成熟，日本社区活跃	早期阶段，快速迭代中

简单来说：如果你是个人作者，想快速做一部短篇，Ren’Py 和 TyranoScript 依然是非常好的选择；如果你是一个制作组，要做一部开发周期长、需要多人协作、要多语言、多平台发行的作品，NarraLeaf Studio 就是为这种场景设计的。

NarraLeaf Studio更适合谁？它更适合有明确分工的制作组，编剧、美术、程序、翻译、配音各司其职；适合规划长期开发、持续更新的项目；需要多语言、多平台发行的商业作品，以及适合对复杂互动叙事有需求的团队。NarraLeaf都是不二的选择。

在最后

我们做 NarraLeaf，不是想再做一个“更好的 Ren’Py”，而是想回答一个问题：如果视觉小说用现代软件工程的方式来构建，它会是什么样子？如果考虑到未来维护，视觉小说应该怎么做？

NarraLeaf Studio 是我们目前的答案：让写故事的人专心写故事，让做系统的人有足够强大的工具，让整个团队在同一个工程里协作，让一个项目能够健康地走完从立项到发售、再到长期更新的全过程。

NarraLeaf Studio 现以 MPL-2.0 协议开源（除资源保护组件），长期免费使用及维护。

NarraLeaf 项目历经两年研发，如今正式发布，却仍在快速迭代。部分功能仍在开发中。在初期发布的时间里，我们诚邀所有视觉小说开发者，以及对视觉小说、GalGame开发感兴趣的朋友体验 NarraLeaf Studio，并与我们一起完善这个属于创作者的工具。

• 下载： https://www.narraleaf.com/download
• GitHub： https://github.com/NarraLeaf/NarraLeaf-Studio
• 文档： https://www.narraleaf.com/docs/studio
• NarraLeaf React： https://github.com/narraleaf/narraleaf-react
• QQ 交流群： 632485390
• 问题反馈： https://go.mewbaka.cn/nl-feed

欢迎下载试用，也欢迎来群里和我们聊聊你的项目。也许下一部作品，就从这里开始。