當 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 文件