Fyrox 1.0 登場，Rust 遊戲引擎終於穩了

7 年後，Fyrox 終於到 1.0.0。這不是小修小補。上一條主線還停在 0.36，現在它直接把自己推到穩定版。對 Rust 遊戲開發來說，這種節點很少見。

更有意思的是，Fyrox 不是只有引擎。它還有原生編輯器 FyroxEd，支援 Windows、Linux、macOS 和 WebAssembly。講白了，它想做的是一套能真的拿來做遊戲的工具鏈，不是只有 API 文件的半成品。

我覺得這次 1.0 的重點，不在於「終於發了大版本」。重點是它把很多 Rust 遊戲引擎常見的痛點，一口氣收斂到可用狀態。這對台灣開發者很實際，因為你不用先當引擎維護者，才能開始做內容。

Fyrox 1.0 到底改了什麼

Fyrox 自己把它定位成 2D/3D 引擎，而且帶場景編輯器。以前這句話比較像願景。現在有 1.0 撐著，這句話才比較像承諾得起的產品描述。

這次最醒目的變化，是物理式渲染流程補齊了不少。它加了 image-based lighting、environment mapping、reflection probes。畫面表現會更接近現代 3D 工具鏈，但團隊也很坦白，global illumination 還在後面，會放到 2.0 方向處理。

這種節奏其實合理。很多引擎一開始就想把所有圖形名詞塞滿，結果最後卡在維護地獄。Fyrox 先把穩定版做出來，再往更重的渲染功能推，這種順序比較像工程，而不是行銷話術。

• 1.0.0 是 7 年後的正式穩定版
• 前一個大版本線是 0.36
• 新增 image-based lighting、environment mapping、reflection probes
• global illumination 仍排在後續版本
• 支援 Windows、Linux、macOS、WebAssembly

另一個很實際的改動，是把 scene 和 UI entity 的 handle 從 untyped 改成 strongly typed。這聽起來像小事，但做過大型專案的人都懂，錯拿物件參照會害你 debug 半天。

現在 handle 有型別，腳本可讀性會好很多。更重要的是，錯誤更容易在編譯期被抓出來。這很 Rust，也很對味。它不是在包裝既有資料，而是在把型別安全往引擎核心推進。

編輯器這次真的有感

FyroxEd 是 Fyrox 很大的賣點。很多 Rust 遊戲專案偏 code-first。這對喜歡掌控底層的人很爽，但對要做內容的人就很硬。你總不能每改一個物件位置，就重跑整個流程吧。

1.0 版對編輯器下了不少功夫。最有感的是 asynchronous scene loading。場景載入時，編輯器不會整個卡死。這種體驗差異很直接。你一用過，就知道工具是不是能長期待著。

Fyrox 團隊也更新了官方書籍，Fyrox Book 已經對齊 1.0.0，截圖和章節都在補齊中。對開源引擎來說，文件不是加分題，是生存題。沒有文件，很多人根本不會試。

“The final stable build landed in late March.”

這句話很直白，也很重要。它代表團隊沒有為了卡日期硬上 1.0。原本規劃是接近引擎第 7 週年，也就是 2026 年 3 月 19 日左右，最後是經過兩個 release candidates 後才正式落地。

這種做法看起來慢，但其實比較像成熟團隊。先把候選版放出去，讓人測，讓人回報，再收斂到穩定版。對遊戲引擎這種工具來說，穩定性比氣勢重要太多。

為什麼這版不太像一般的 1.0

Fyrox 不是大公司養的專案。團隊自己也提過，開發期間幾乎沒有資金。這會直接影響節奏。你不能像大廠那樣同時開十條戰線，只能一條一條收。

所以 1.0 的意義，不只是版本號。它是在說：底層已經夠穩了，可以開始拿來做比較認真的專案。這種訊號對開發者很重要，因為沒人想把產品壓在一個還在大改 API 的引擎上。

這次 release candidates 也塞了不少實用東西。除了 typed handles，還有新的 export-cli crate，讓專案管理器的 build 可以走命令列匯出。這對 CI 很友善，也比較符合正式開發流程。

• 先發 2 個 release candidates，再上 1.0.0
• 新增 export-cli，方便命令列匯出
• 官方文件已更新到 1.0.0
• 主要 bug fix 會持續，但大功能先暫停幾個月
• 編輯器與 runtime 的整合更完整

我覺得這個暫停也合理。很多小團隊最慘的問題，就是一邊修穩定性，一邊硬塞新功能，最後兩邊都做不好。Fyrox 團隊至少講得很誠實：先休息，再繼續補 bug。

這種節奏不炫，但很務實。尤其是做工具軟體的人都知道，真正難的不是 demo，而是每天都能用。能用 8 小時，比能展示 8 秒重要多了。

跟其他 Rust 引擎比，差在哪

Rust 遊戲開發現在有幾條路。每條路都不一樣。有人走 ECS，有人走底層元件拼裝，有人直接選有編輯器的引擎。Fyrox 明顯站在後者。

如果你要的是最高自由度，那你可能會偏向自己組工具。但如果你要的是「有編輯器、能拖拉、能匯出、能做 2D/3D」，Fyrox 1.0 的答案就比以前硬很多。

這裡最大的分水嶺，不是效能，而是工作流。引擎不是只有跑幀率。它還要影響關卡設計、資產管理、除錯流程，甚至團隊分工。Fyrox 的賣點，就是把這些東西一起包進來。

• Bevy：ECS-first，偏 code-driven
• Fyrox：內建原生編輯器，偏 scene workflow
• Godot：編輯器成熟，但不是 Rust-native
• Fyrox GitHub repo：原始碼、release notes、文件入口

如果拿數字來看，7 年才到 1.0，時間很長。但這也代表它熬過了最容易散掉的階段。很多開源引擎死在 0.x，不是因為技術差，而是因為方向一直飄。

所以現在的問題不是「它有沒有 1.0」。而是「你要不要把下一個專案押在一個有編輯器的 Rust 引擎上」。這個答案，會比版本號更重要。

Rust 遊戲引擎這條路，現在走到哪了

Rust 做遊戲引擎，這幾年一直有熱度，但也一直很分裂。有人愛它的型別系統，有人嫌它內容工具太少。說白了，程式語言很香，不代表做遊戲就會順。

Fyrox 的存在，剛好補了這個洞。它不是只給你 runtime。它還給你 editor、export、book，還有跨平台支援。這些東西加起來，才比較像一套能進團隊流程的方案。

更大的背景是，Rust 在遊戲圈一直在找自己的位置。Rust 很適合做高安全性、低層級控制的系統，但遊戲產業看的是整條 pipeline。只要工具不夠完整，開發者最後還是會回去用熟悉的引擎。

Fyrox 1.0 至少把「可以試試看」變成「可以正式評估」。這差別很大。前者是玩票，後者是選型。

接下來該看什麼

如果你已經在用 Fyrox 0.36，先看 release candidate 的遷移說明。typed handles、編輯器行為、匯出流程，這幾個地方最容易踩雷。別直接硬升，省得半夜陪 bug 熬。

如果你是新專案，1.0 讓 Fyrox 少了一個很大的心理門檻。以前你可能會想，這東西還在 0.x，等穩一點再說。現在這個理由少很多了。

我自己的判斷很簡單。接下來 3 到 6 個月，才是 Fyrox 1.0 真正的測試期。不是看它發了什麼大新聞，而是看有多少團隊真的把它放進原型、工具鏈，甚至正式產品。

如果你在找 Rust 遊戲引擎，現在很適合做一件事：直接開一個小專案試 Fyrox 1.0。別只看介紹。跑一次編輯器，試一次匯出，再碰一下 typed handles。你會很快知道它是不是你的菜。