当 The Funkin’ Crew 宣布要暂停内容更新、从底层重写 Friday Night Funkin’ 时，很多玩家的第一反应都是不理解。旧版明明还能跑，为什么要花这么大力气去推倒重来？
这篇文章会从结构层面解释这次 FNF V-Slice 重写：旧项目为什么逐渐撑不住，输入链路是如何一步步演进的，以及官方为什么要建立自己的原生 Mod 体系。
面向读者：新玩家
最后核对时间：2026-07-01
核对版本：桌面版 v0.8.4（2026-03-26）与 Android v0.8.5 hotfix（2026-04-06）
1. Ludum Dare 原型基础已经不够用了
Friday Night Funkin’ 最初诞生于 2020 年 10 月的 Ludum Dare 47。对一个 jam 原型来说，先做出来最重要，但当项目持续变大之后，这套“快速搭起来”的基础就会逐渐暴露维护问题。
到 2022 年前后，官方已经明确表示，旧版代码越来越难以安全扩展。在 Tha V-Slice 里，他们就用过 “duct tape” 这种说法来形容旧引擎状态。
问题主要集中在两方面：
- 资源和内存处理不够稳，大型自定义内容更容易把游戏推向卡顿或崩溃
- 内容和核心代码耦合太深，想加歌、换素材、改 UI，往往都要直接动核心工程
如果 FNF 要继续往 PC、移动端以及长期商业化版本发展，就必须变得更模块化。V-Slice 的核心目标之一，就是把引擎逻辑和游戏内容拆开，让项目能继续扩展。
图 1 - 作者自制示意图，用来说明从强耦合结构转向更模块化的变化。
2. 输入系统不是一次性完成，而是分阶段演进
在节奏游戏里，输入体验的重要性几乎不需要解释。只要判定和按键响应有波动，玩家会立刻感觉出来。
旧版 FNF 依赖更早期的 HaxeFlixel 输入路径，玩家长期以来都在反馈密集谱面或性能波动下出现“吞键”之类的问题。
而官方在 V-Slice 时代对输入的改动，是分阶段完成的，不是一步到位。
图 2 - 作者自制时间线，依据官方发布说明整理。
第一阶段：v0.3.0 的 V-Slice 首发
2024 年 4 月上线的 V-Slice 首发版，并不是直接跳到 SDL3。它首先是在 SDL2 路线上做了大量重构，目的是尽量降低渲染波动对输入注册的影响。
第二阶段：v0.8.4 升级到 SDL3
在 v0.8.4（2026-03-26）中，官方桌面版从 SDL2 迁移到 SDL3。官方更新说明把这次变化描述为更灵敏、更精确的输入，同时也改善了控制器支持。
这意味着：即便同样都属于 V-Slice 时代，早期 v0.3.x 和后来的 v0.8.4+，在手感上依然可能存在明显差异。
3. 官方原生 Mod 体系是怎么建立起来的
在 V-Slice 之前，官方基础版本并没有成熟的原生 Mod 沙盒，这也是为什么大量创作者会转向 Kade、Psych 这些社区引擎。
V-Slice 之后，官方逐步明确了自己的 Mod 路线，核心是两样东西。
Polymod
Polymod 为官方版提供了一层沙盒式文件加载机制。和早期那种直接覆盖原始文件的方式不同，Mod 资源可以从 mods/ 目录中动态注入。
这样做的好处是：
- 安装更安全
- 出问题更容易撤回
- 更适合随着官方版本长期演进
从 v0.3.2 开始，官方版还支持直接加载 ZIP 形式的 Mod，但前提仍然是 _polymod_meta.json 必须位于压缩包根目录。
图 3 - 作者自制概念图，用来说明 Polymod 的资源注入方式。
HScript
很多社区引擎习惯使用 Lua 做玩法脚本，而官方 V-Slice 体系使用的是 HScript。它更贴近 Haxe 本身，也更符合官方代码体系。
对玩家和创作者来说，这带来几个直接结论：
- Psych / Kade 的 Mod 不能直接搬到官方版里用
- 官方引擎 Mod 预期使用的是 Polymod 打包方式与 HScript 行为扩展
- 官方路线追求的是“和官方引擎深度一致”，而不是“和所有社区引擎互通”
参考资料
官方来源
- Tha V-Slice - funkin.me 博客（2023-02-10）
- v0.8.4 发布说明 - SDL3 输入升级
- GitHub issue #4748 - 控制器输入与 SDL3 讨论
- Using HScript - 官方 Mod 文档
- Polymod metadata 文档