ADV.JS 又一个遥遥无期的大坑。

GitHub: https://github.com/YunYouJun/advjs
Demo: https://advjs.elpsy.cn

按照惯例，开坑前先来三问。是什么？为什么？怎么做？

ADV 是个啥？

冒险游戏（Adventure Game，缩写为 AVG 或 ADV）是电子游戏中的最早的类型之一。此类型游戏采取玩家输入或选择指令以改变行动的形式。强调故事线索的发掘及故事剧情，主要考验玩家的观察力和分析能力。该类游戏有时候很像角色扮演游戏，但不同的是，冒险游戏中玩家操控的游戏主角本身的等级、属性能力一般是固定不变并且不会影响游戏的进程。
通常 galgame 类型为 ADV 形式的，不是纯剧情+CG+选项的，而带一些其他方式操作，比如游戏里有卡牌对战或者战斗场面（例：恋姬无双）。
—— 摘自「百度百科 - ADV」

简而言之，平时我们常见的 Galgame / 视觉小说便是 ADV/AVG 的一种。

Galgame（日文假名：ギャルゲーム，平文式罗马字：Gyaru Gēmu，又称美少女游戏）是一种玩家可以与动画美少女进行互动的电子游戏，其受众主体曾经是日本男性，但现在的全年龄 GalGame 剧情面向受众已经不分男女。Galgame 的游戏类型大多数是 VNG（视觉小说）但是也有交互式的 Galgame。
—— 摘自「百度百科 - Galgame」

一般情况下，Galgame ∈ ADV = AVG。

ADV、AVG 和 Galgame 有什么区别？

为啥要做 ADV 游戏引擎？

ADV/AVG 的游戏引擎已经有很多，但都各有千秋。

视觉小说引擎列表 - 维基百科

以下是个人的调研（搜索）简要评估，仅为个人观点，欢迎指正。

• 吉里吉里: C++，老牌 AVG 游戏引擎，著名的 Fate/stay night 便是用其制作。但是上一个稳定版本已经是十年前，很久没有更新了。
• Ren’Py: Python，代表作「心跳文学部」(我老婆的 Twitter)，开源万岁，并且直到现在更新也很活跃，如果喜欢 Python，是个不错的选择。不过需要预编译，剧本与程序未分离。（定位于浏览器端的话，JS 更有优势。）
• NScripter: C++，非商业免费，Windows 平台，代表作「寒蝉鸣泣之时」，上一个稳定版本发布于 2015 年。
• AVG32、RealLive、SiglusEngine：Visual Art’s 公司开发，Key 社游戏「CLANNAD」等均用此开发，但很明显这种商业级咱接触不到。
• BKEngine: C++，面包工坊，非商业免费、跨平台，但是制作工具不跨平台（只有 Windows）。
• AVG.js：JavaScript，开源，基于 Pixi.js 与 React，Web 端运行。但是作者 Icemic 是个大 🐦，所以已经几年没有更新了。（不过作者也在 BKEngine 的面包工坊。）
• Librian: Python，开源，跨平台，Galgame | Visual Novel 引擎，作者 还有在做 Vtuber，可惜是个变态。
• 橙光制作工具：免费易操作，只有 Windows 平台，但是因为 如何看待橙光游戏签约合同中版权永久属于橙光，而作者仅保留署名权？，好感直线下降。

以上便是我目前大致了解到的 ADV/AVG 相关的游戏引擎。

那么已经有这么多的引擎，为什么还要执意造轮子呢？

因为自己日常开发使用 Mac，所以必须得支持跨平台，基本可以排除掉大半，去掉过于古老的，去掉客户端开发的，再排除掉鸽子和变态（开玩笑，当然这个不是主要原因，难道是次要的？？？）。

我想要制作一个更偏向于前端、轻量可扩展的 AVG 游戏引擎（框架？），尽可能使用 HTML/CSS 本身属性效果替代 Canvas 绘制。（当然，后续 Canvas 可以用于一些复杂的 3D 场景、模型之类的展示。）

目前尚未发现同类型项目，其次，即便功能相似，对于不同语言的偏好者或不同的应用场景也有其存在的意义，就不算重复造轮子，有了 Spring Boot，同样也有 Express/Koa/Nest.js、Laravel、Django 的诞生。

（至于跑在浏览器，又有什么比得过 JavaScript 的天然优势呢？）

近年来，也有云游戏的概念诞生，但此多基于视频流。对于 AVG/ADV 类型游戏来说，显然是不划算的，我们完全可以将压力不大的运算放到用户浏览器，将需要额外加载的图片/音频等资源放至云端的 CDN，只预加载临近的资源。既降低了带宽压力也不用担心操作的延迟。

浏览器自带的控制台、可选中的元素、可扩展的前端 UI 与背靠 Node.js npm 庞大生态的程序也很适合做 Meta Game - 元游戏。

metagame 是什么？ - 知乎

技术之外的原因

高中时，朋友向我推荐了「Fate/stay night」，并借我 U 盘拷贝。但家里的古董电脑不知为何总是安装失败，好不容易解决了玩了没多久便报了各种兼容错误。所以至今我也未曾进一步了解 Fate 系列的作品。

第一次看完「CLANNAD」的时候，我在宿舍感动地泪流满面，以至于怅然若失。便想要找来游戏以备日后重温，游戏大小 2/3G，加之宿舍带宽才 2M（是的，你没看错，是个位数！很老的线路，后来才有新的线路铺来），再者电脑系统那时都已经 Win8 及以上了。

而 CLANNAD 的平台则分别是 Windows 98/Me/2000/XP(初回限定版/通常版)，Windows 2000/XP/Vista/7(完全语音版/全年龄对象版)。期间自又有一番曲折。

过了感伤的时段，也很难再在宿舍中静下心来回顾，到了排队等各类需要消磨时间的情况时，又会想着要是能在手机上游玩就好了。（看官您可能要说了，装虚拟机啊等等的方式应有尽有。但因为贫穷，手机容量本就捉襟见肘，套壳的各类体验也未必佳。）所以除此之外，从根本上有一种更为便捷的方式该有多好。

我始终觉得 AVG/ADV 一类对性能不敏感（但占用空间较大、CG/语音动辄数 G）的文字冒险游戏，将其放在云端是最好的选择。用户随时随地可以跨平台游玩，而无需过高性能的机器、充足的本地空间。而已有的此类型游戏的大部分演出效果，在浏览器端也基本可以实现。（当然，这也可能与近年来前端技术大爆炸有关。）

但我一直很奇怪为何很少此类型游戏的诞生。即便有，也是少数兴趣之作的 Demo。

当然，我能想到的有旧时代浏览器性能特性不足、服务器成本高、网速慢、游戏资源无法加密等。不过放到现今，却可排除大半，Chrome 无须多言，游戏的静态资源无需频繁更改，商业级别的话 CDN 平均下来相对游戏售价来说成本并不高，5G 时代网速还行，游戏资源本就有各类技巧提取，此外对于正版验证，反而线上账户更有利。

我很早前便有此想法，几年前发现了 AVG.js ，认识了 Icemic，但没想他一鸽便鸽至如今。后来又发现了 Librian，认识了到了 RimoChan 的变态，但终究与我期望的想法与设计偏好有所冲突。

除此之外，我也未能在开源社区，找到类似定位与功能的 AVG/ADV 引擎。

回顾起来，自己写过不少玩具项目，也干过不少活，提过些无关紧要的 PR，混了些 Star。
但就像东一榔头，西一棒槌，没有一个持之以恒的施力点。

虽然此前还整过个机器人项目，但因为依附 QQ 与腾讯的垄断策略而行走在灰色边缘，也亲眼见证了晨风作者被抓、酷 Q 关闭等风声鹤唳。我仍旧会坚持维护（毕竟自己有在用），但也很难再投入过多精力于其上。

真让我拿出一个自鸣得意、有完善生态体系的大项目，我反倒无言以对。

社区中见到的大牛们也多是专注围绕一个点，展开自己的工作，并持之以恒。譬如 尤雨溪与 Vue.js、Mike Bostock 与 D3.js、mrdoob 与 Three.js……（你问我为啥提这三个？因为感觉好像刚好可以用到。）

而写 AVG/ADV 引擎的上限可以很高，可以研究的内容也很多。我也有将自己无人问津的小说游戏化的打算。

至此，我决定从零开始，遵循本心，面向未来，开始这一项目。

且慢，万事开头难，起名最优先。

为了凸显大气，并避免与 AVG.js 重名，我决定将其命名为 ADV.js。（不过似乎少了很多个性化的感觉，所以还不确定是否是最终的名字。有啥好的建议欢迎提出！）

其次是因为「命运石之门」等一系列 5pb 作品，官方将之称为科学 ADV 系列，索性便也取此 ADV 之名。

目前预定的技术栈是 TypeScript + Vue3。

规范开发，上 TypeScript 已经无须异议。（虽然还是会有很多 any 的样子。）

而 Vue3 正式版总算姗姗来迟，且本身便使用了 TypeScript 重写，对 TS 的支持也有了提升。（次要原因则是练习一下 Vue3 啦。👴 学不动了）

为什么不用 React？AVG.js 便是基于 React，翻新这件事应该原 🐦 本人来做，而我用 React 重写类似功能一来未必胜过原作，二来也未必有必要，三则设计理念与最终目的也不尽相同。此外个人 Vue 相比 React 要熟悉一些。并打算更面向未来。

本身想要在浏览器端实现各种效果，必然要使用许多新特性。（Chrome 天下第一，兼容 IE 是不可能的，这辈子不可能的。）

为了面向未来，也顺带直接上 vite。踩了不少坑（等咱这基本完善了，它也差不多稳定了吧），但一个字，快！

游戏内容无需也不应该考虑 SEO，本身内容演出也全部通过直接请求文本并实时解析。（面向未来，axios 都没有安装，直接用了 fetch，_(:з」∠)_ 虽然可能后续还是会用到）

这样对于编剧来说，只要简单的更改文本，而无需重新构建。

但是在此之前，我们应当有一个剧本文本解析器，用于解析按照一定格式编写的剧本。

目前打算兼容 Markdown 语法，并采用 TS 编写，ES6 打包成 Browser/Node.js 库，可在浏览器端调用并展示实时解析的效果。

至于剩下的……，等我先写完当前的再说吧！

后续可能有（🐦）的其他内容，自定义配置文件（支持 JSON/YML ?）、多设备适配、支线选项控制、音乐系统（BGM 与配音）、摄像机系统（镜头）、立绘与 Live2D、front-matter 与更多兼容 Markdown 的剧本语法及自定义脚本、进度存储读取槽（本地 localStorage/ 网络 MongoDB）、场景路由、背景管理（融合 3D）、人物小传/关系、UI 主题、资源一键 CDN/预加载……

其他 Todo。

To Be Continued.