技术进步能为国G带来什么?我们的历程:语涵编译器
远行的泥土
2025年06月05日 11:50
书写我与Galgame的故事

序言

如果你是计算机相关领域的从业者,想用技术手段改善国产 GalGame(以下简称“国G”)的现状,您会选择做什么?是参与游戏制作,打造值得被铭记的佳作?还是开发一个强大、易用的游戏引擎,统一国G开发工具的生态?又或者,尝试一条不同的路径,去做一些看似不那么“主流”,但可能同样重要的事情?

本文讲述了我选择“另辟蹊径”之后的探索过程,并重点介绍目前正在开发的项目:语涵编译器。这是一个辅助视觉小说开发的工具,核心目标是通过技术手段降低剧本录入的工作量,提高游戏制作效率。项目前身起步于2019年10月,至本文撰写时(2025年6月)已走过近六年历程。文章面向游戏爱好者与创作者,希望本文能为您带来一些思考。若能让您在阅读完本文后对语涵编译器项目感到好奇的话就再好不过了。

叠甲:本文部分观点基于我的个人经验和主观判断,有些可能并不严谨。提出它们是为了帮助解释项目选择与设计决策,而非作为通用结论。我对不同思路持开放态度,也衷心祝愿每位在不同道路上前行的探索者都能达成自己的目标。

起源与问题背景

我在初中时期曾暗恋一位同班女生,因为性格内向、不够自信,没有选择主动表达,而是决定等待自己成长后再尝试。这份感情与对重逢的期待成为支撑我多年来前行的一种精神寄托。直到2018年底(我当时研一),在一次因亲人婚礼返回家乡的契机中,我觉得时机成熟,决定表白。但结果显而易见、彻底失败,精神寄托就此崩塌。2019年时,我偶然接触到国产 GalGame《某一种青春》(以下简称《某青》),深受感动,从此入坑国G。

之后,我看到了《某青》作者长水老师撰写的制作记录,文中提到剧本内容是手动录入游戏引擎的,没有使用程序进行自动化处理。(这里简单解释一下:视觉小说的制作类似于“剧本与素材+引擎”的组合。录入就是把剧本转为引擎能读取的格式。剧本与素材(图片、音频等资源)是游戏内容,游戏引擎则像是播放器,把内容以互动形式呈现给玩家。)但把剧本变成引擎能读取的格式,并不像复制粘贴那么简单。这个过程有点像把自由写作的文章改写成法律文书或数学证明,需要严格遵守格式要求,而且不同游戏引擎之间的格式要求也不一样。录入出错的话,游戏运行就会出现 Bug,排查修改也十分耗时。据作者回忆,《某青》全篇约 15 小时的游戏时长,光是剧本录入就花了数月时间。看到这里,我开始思考:能否用程序来简化这个过程? 于是决定利用业余时间尝试编写一个工具,帮助创作者将剧本高效转化为游戏引擎所需格式。

从平常的角度看,确实也可以选择“开发一个新的游戏引擎”来简化剧本录入流程。但仔细思考后,我认为这种做法并不合适。原因在于,一个“容易录入”的新引擎,本质上其实是由两部分组成的:一个全新的引擎本体,加上一套让录入变得轻松的设计方案。但“开发新引擎”本身就是一项非常庞大且复杂的工程,外加剧本录入问题的解决方案,这样的总投入显然非常高。相比之下,更合理的做法,是尝试在已有引擎的基础上,通过工具或“外壳”来改善录入流程。这样可以大大减少开发成本,同时也避免“重复造轮子”。更进一步地思考后,我认为一个优秀的录入辅助工具,本质上应该是与引擎“解耦”的——它不应只服务于某一个特定的引擎,而应具备足够的通用性,能够适配多个常见引擎,甚至是用户自己开发的引擎。只有这样,它才算是一个真正“解决录入难题”的长期方案。基于这样的思路,我决定将主要精力投入到“录入辅助”这一问题本身,而不是进行另起炉灶式的引擎开发。

cut-off

第一代:剧本处理器

语涵编译器最早的雏形起步于 2019 年 10 月,初代项目的目标很直接:让创作者能够用自己习惯的方式编写剧本,然后由程序自动转化为游戏引擎所需的格式。

虽然每位创作者习惯的剧本书写格式都不一样,但是每个创作者自己的书写格式在一部作品(或是多部作品中)是相对统一的,因此,我设想,只要程序能够理解“创作者使用了怎样的格式来表达内容”,再结合目标引擎要求的格式规范,就能完成自动转换。举个例子:创作者可能习惯写“小明(高兴):我回来了”来表示角色发言,而游戏引擎所需的格式中可能要求包含一个立绘切换命令和一个发言命令。只要把这些对应关系告诉程序,就能批量完成转换。

于是,初代项目的设计逻辑是:创作者告诉程序“什么格式代表什么含义”,程序根据这些信息完成剧本格式的转换。项目使用 C++ 与 Qt 开发界面,整体设计在 2019 年底多次推倒重来,直到 2020 年初形成较稳定的设计,并于当年 6 月完成第一个功能完整的原型。

但很快,问题暴露出来了。尽管原型功能齐全,但项目最终未能满足实际使用的要求,经过多次迭代改进仍然没有彻底扭转状况,于是在 2021 年初正式停止维护。以下是最核心的两个问题:

首先,程序难用。虽然程序本身的目标是“让不会写代码的创作者也能用”,但实际使用中却仍然需要创作者向程序描述他们所使用的剧本格式。这种“告诉程序你是怎么写的”其实本质上就是一种编程行为,只不过换了表达方式而已。即便我在设计上花了大量精力让输入方式尽量易于理解、尽可能降低学习成本,但对没有编程背景的创作者来说,这仍然是一道难以跨越的门槛。一旦格式描述有误,调试过程也需要理解程序的内部逻辑,这对于非程序员几乎是不可能完成的任务。

其次,程序太慢。由于需要支持“几乎任意格式”的剧本输入,初代程序采用了我自行设计的算法逻辑。这种灵活性带来的代价是处理效率极低——在实际测试中,处理几百行剧本就可能耗时近一分钟。这样的速度显然难以支持数千行、甚至数万行剧本的项目需求。

(2020年6月演示视频截图)剧本格式信息界面

(2020年6月演示视频截图)导出面包引擎(《某青》所使用的引擎)脚本的结果

除此之外,项目后期进行复盘时还发现更多深层次的问题:

  1. 缺乏风险预判。当初没有尽早识别出哪些部分是“最有可能失败的关键”,也没有在项目初期用最小可行版本验证这些环节是否可行。我反而投入了大量精力在界面外观、拖拽功能、剪贴板支持等“非核心部分”上。整个开发过程中,我用了大量时间争取把每个部分(包括次要的)做好。结果,当关键算法和易用性无法满足要求时,这些工作全成了无用功。
  2. 对问题本质的理解不够深入。在最初的设计中,我对“剧本录入”这一任务的实际复杂性认识不足。现实中的剧本往往并不会完整地标注所有信息——比如“谁在说话”“何时切换立绘”等,很多细节默认由人脑补。但对程序而言,这些缺失的信息必须通过某种规则补全,否则无法正确转化为引擎可执行的格式。而这些补全规则如果完全交由创作者设定,既抬高了使用门槛,也使程序逻辑变得异常复杂。最终形成的局面是:创作者用不起来,程序也难以维护,设计目标与实际体验出现严重偏差。
  3. 目标过于理想化。除了视觉小说剧本录入外,我一度还希望将该工具扩展为通用的文本处理器。但结果是,在文本处理方面被现有工具(如 Python 脚本、正则表达式等)全面碾压,反而本职功能也没做好。

初代项目的失败让我体验了一次完整的“从理想到现实”的碰撞。但也正是这个失败,为后续语涵编译器的发展奠定了方向基础。

cut-off

第二代:语涵编译器

第一代项目失败后,我在 2021 年大部分时间里都在重新思考方案、写代码试水。第一代项目还暴露出我“闭门造车”的问题,因此在语涵编译器项目初期,我主动参与部分游戏开发,去了解创作者工作流程与剧本书写习惯,并将经验用于程序设计。不断迭代之后,现在语涵编译器的基本路线基本确立。“语涵编译器”的名字也在这个阶段确定下来,代码仓库在2021年11月建仓,延续至今。

相比前代的“让程序支持任意剧本格式”,语涵编译器采取了更务实的思路:不再完全交给创作者设定格式,而是由本项目提供一套“默认格式”(在程序设计中称为“语法”)。这套格式设计时会尽量贴近创作者已有的写作习惯,从而让录入过程尽可能自然、少量修改即可完成。这样,创作者可以继续使用自己熟悉的工具(如 Word)进行创作,只有在需要将剧本导入引擎时,才借助语涵编译器完成格式转换。

除了理念上的变化,语涵编译器在程序设计上也做了重要调整。语涵编译器借鉴了现代主流编译器的设计理念,特别是 LLVM 和 MLIR 等成熟框架的模块化思路。这样的设计使得后续可以方便地增加对新引擎的支持,并且便于改善程序的自动演出效果。同时,程序也针对视觉小说的特点做出了一些特别设计,例如:支持剧本文档中内嵌图片等资源的处理能力,以及灵活可扩展的剧本读取机制。鉴于第一代项目使用 C++ 时开发速度较慢、难以更早完成原型的经历,语涵编译器转为使用 Python 开发,牺牲部分运行效率,换取更高的开发效率和灵活性。优先确保功能可用,再进行优化打磨。

语涵编译器发言部分剧本格式

语涵编译器在 2023 年夏天完成了最小可行产品(MVP)的开发,并在同年 8 月首次参加 CnGal 周年茶话会,向创作者们展示其功能。但从反馈来看,项目仍存在不少现实挑战:

  1. 认可度低:许多创作者以为语涵编译器是又一个新的视觉小说游戏引擎,对其缺乏兴趣。
  2. 缺乏亮点:对于已经使用程序脚本或搜索替换等手段实现自动录入的创作者而言,语涵编译器在效率上没有形成明显差距,因而缺乏使用动机。
  3. 功能太少:当前仅支持基础剧本录入,诸如“好感度系统”等常见要素尚未支持,无法满足完整开发需求。
  4. 使用门槛:包括缺乏教程文档、早期 UI 设计复杂、程序不易获取(需从 GitHub 下载)等问题。

语涵编译器这一阶段的经验说明,技术上的创新,若不能有效转化为“对用户真正有用的价值”,其作用将极为有限。也正因如此,我随后重新调整项目定位,并继续迭代至如今的版本。

cut-off

现在:体系化,不止剧本

在总结前一阶段的反馈后,我得出一个明确的结论:仅凭语涵编译器目前提供的“剧本录入辅助”功能,尚不足以提供足够的使用价值。因此,项目定位也随之发生变化。语涵编译器不再局限于将剧本转为引擎所用格式,而是拓展为以“快速构建游戏原型”为核心目标的视觉小说开发辅助平台。

在新的目标下,语涵编译器致力于降低开发门槛,实现“剧本一写好,游戏就能跑”:即使创作者只有一个剧本文档,也可以迅速生成一个可运行的游戏原型。不需要提前准备立绘、背景等素材,程序提供内置素材,以便创作者“零资源起步”。这样一来,创作者可以尽早验证自己的剧本,观察剧本在游戏实机中的表现,尽早发现发现计划中不合理的地方,从而更合理地规划项目方向、减少后期返工。待剧本内容基本成型后,创作者再逐步替换掉语涵编译器提供的默认素材,完成向正式游戏的过渡。于此同时,语涵编译器将提供分析功能,帮助创作者避免潜在问题。比如程序可以统计各个素材的使用率并找到使用率太少的素材,创作者可以去掉它们减少成本,又或是在其他位置使用它们、改善游戏体验。我以上述定位于2024年成功发表了一篇短论文,由于内容偏技术向,在此不多赘述。

快速构建游戏原型,打一点点字去“撬动”语涵编译器内置素材,“召之即来”。上图为剧本文档内容,下图为从该剧本导出的 Ren’Py 游戏工程实机。

为了实现上述目标,语涵编译器项目当前正围绕以下几个方向展开:

  1. 素材准备。已完成抽象背景3组(带可定制区域的泛用室内、室外背景)、实际背景14组(卧室、教室等),立绘完成两组(短发、长发女生)。这两组立绘由于初期图层拆分说明不明确导致眼部拆分不能切换;已记录经验教训并计划后续重制。
  2. 素材使用情况分析功能。目前程序已实现该功能,能统计每个角色立绘或背景在游戏中出现的频率(以发言数为单位),但由于报告格式不够直观、统计口径尚不统一,仍在持续优化中。
  3. 新版界面与用户文档编写。除分析功能外,核心功能如游戏工程导出、内嵌资源浏览已基本打通。文档方面已完成初步版本,正在扩充教程与使用指引。

这些只是实现全新定位的第一步。即使上述任务全部完成,语涵编译器距离“真正降低视觉小说创作门槛”的目标仍有不少距离。未来几年内,项目还将继续探索更多功能支持,包括游戏 UI、背景音乐、音效等部分,并持续优化核心逻辑。我也将继续倾听反馈,努力让这个平台成为创作初期最可靠的助力。

cut-off

结语:永远在路上

从项目诞生之初,语涵编译器就注定是一项高风险、不确定性强的长期工程。受限于个人精力和国G环境,它始终以低成本、小规模、慢节奏的方式推进。截至目前,项目仍主要由我一人主导整体设计与开发,美术资源与部分程序开发则通过外包方式完成。所有参与者都以现实生活中的主业为重,只在空闲时间投入项目开发。这种开发模式虽然牺牲了短期推进速度,但换来了项目的可持续性。我也希望借助这种“留有余力”的方式,让语涵编译器项目能走得更远。

语涵编译器项目将长期保持开源、免费。所有内置的美术素材也都可商用、无需署名,创作者可自由使用。未来,我们将继续朝着最初的目标前进——构建一个真正有用、能为创作者减负的辅助平台,而非一个仅仅“有技术含量”的实验性项目。

cut-off

写在最后,一点个人想法

近年来,随着工具日渐成熟、教程资源变多,越来越多的人开始尝试参与国G创作。然而,可能绝大多数的制作组注定无法完成第一部作品,剩下的制作组完成第一部作品后(甚至多部作品后)也很可能没有足够的正反馈(销量、口碑等)去支撑他们继续下去。有一件很有意思的事,我在设计背景素材时,曾想在场景的广告牌上加入一些“给创作者的鼓励的话”,于是向其他创作者征集相关内容,结果收到的大多是类似“快跑”这样的劝退话语。但矛盾的是,从他们身上,我并未看到真正的放弃——他们依旧在坚持创作。从理性上讲,新的小团队做视觉小说/Gal 大概率是件吃力不讨好的事,那么为什么仍然有这么多新人加入、仍然有大量制作组在继续坚持?

在我看来(基于身边统计学),除了一些可能更在意“创作者身份”本身的群体之外,剩下的创作者中有一部分是真的相信自己的作品能够打动人心、想把游戏做出来给玩家,还有部分创作者是在“为了自己”而创作。对他们而言,创作可能是一种自我治愈的方式,也可能是圆自己的一个梦想。不管是怎样的创作者,我都希望语涵编译器项目的“低成本构建游戏原型”的理想能够提早让创作者获得正反馈(由游戏原型完成带来的成就感),同时让创作带来的成就感不再奢侈,也能让其更侧重对创作者自身的意义。

但是请注意,我并不鼓励所有的人去创作。部分创作者将国G创作作为在一地鸡毛的现实里获得自信和他人关注的途径。对于这样的创作者,我想谨慎地提醒,也许值得重新思考是否选择了最高效、适合的方式。如果创作主要是为了获取关注或自信,那么制作国G一定是效率和成功概率都很低的方式;换另一个方式,比如花时间去学习、精通一门实用的技能,收获基本一定会比做国G更高。另外,我不推荐学生花过多的精力在国G创作上。因为我相信,正如厉害的程序员强的不只是写代码,优秀的剧本作家强的也不只是写作技巧;他们一定经历过更多或是阅读过更多,才能写出别人写不出的东西。在学生阶段,时间和经历都十分宝贵,打好基础、积累广度,往往比短期投入创作更具长远价值。所以,对于学生而言,好好感悟生活、积攒更多对这个世界的经验才是更高效的成长途径。我也非常遗憾地见证过了由学生主导的制作组在中途解散、投入打水漂的情况。

在这里我也想分享一些关于家人支持的想法。我第一次将本项目告知自己的父母是在2021年年底左右。在此之后,父母多次表达过对本项目的不满,劝阻我不要过多投入。2023年夏天,我请假回家(疫情开始后没回过家。研究生是种工作、没有暑假)冲刺开发进度(赶语涵编译器二阶段的最小可行产品),父母态度转为中立、观望。2024年夏天,语涵编译器项目论文投中后,家人才开始支持本项目。在这个过程的初期,我逐渐意识到:家人往往不是反对创作本身,而是担心它会影响现实生活的稳定和前景。我的父母认为本项目是拖累我的无用事务,希望项目不要影响到正常的毕业进度。理解这一点,是沟通的关键。于是为了获取父母支持,我的策略是(1)正常推进现实中的工作,维持住正常节奏;(2)寻求外部认可,改变父母“本项目无用”的想法。策略1下,父母的反对仅局限于提起此事时的口头劝诫。论文投稿的事证明策略2有效;我自己并不需要论文发表来证明本项目的价值,但是我的父母很需要。(在写论文准备投稿的过程中,我也有幸获得了几位大佬的帮助,对项目的发展方向也有了新的思考,在这里也再次感谢各位大佬。)如果小伙伴也想干个大项目但是没有获得家人支持的话,我推荐也做类似的思考和尝试,摸清家人到底想要什么,然后针对诉求采取相应的行动。归根结底,现实中自己的能力和价值是推进这样的副业(或者追求其他任何自由)的坚实基础。

最后,曾经有一个问题,我挣扎过许多次,父母也“拷打”过很多次,就是如果语涵编译器到最后还是没有人用、项目失败的话怎么办。这里想引用一下我尊敬的前一位领导的话,哪怕当时参与的项目的想法不被认可,项目被砍、团队解散,甚至最后论文也没投中,“我仍然为这个项目中我们的努力和成果而骄傲”。我也是。

评论 7
赞与转发