iT邦幫忙

2026 iThome 鐵人賽

DAY 29
0

走到 Day29,終於可以把一句話說出口:《九重燼》正式公開了。

這裡的「公開」不是指專案已經變成商業正式版,也不是說所有路線都沒有風險。它比較像一個可以對外交付的里程碑:玩家能打開 Portal,讀懂這是什麼作品,按下「進入遊戲」,從序章一路玩到第八章,看到結局,通關後再回來玩番外,甚至到鮮花與雞蛋榜投一票。

先講目前真正公開了什麼

目前 repo 裡的 src/narrative/main.ink 已經接入:

  • chapter_00.inkchapter_08.ink
  • Demo 結局 endings_demo.ink
  • 正式結局 dispatcher
  • END_01END_02END_04END_11
  • 六位女主角的感情結局 romance_*.ink
  • 番外一到番外九 extra_01extra_09

但我不想把公開講成完美

Day27 已經說過,目前跨瀏覽器自動化測試還沒有補齊,Playwright 只有 Chromium smoke test,Lighthouse / axe 也還不是 gate。

換句話說,公開不等於「再也不會修」。公開代表我可以把作品放到玩家面前,並且知道目前的強項和缺口在哪裡。

玩家會先看到 Portal

Day28 談過官方 Portal。正式公開時,它的角色更明顯了。

玩家不會先讀 docs/CHOICE_BRANCHES.md,也不會先看 src/narrative/main.ink。他會先看到 index.html

  • 故事背景
  • 遊戲特色
  • 主線與番外章節
  • 角色介紹
  • 素材圖鑑
  • 結局圖鑑
  • 開發歷程

Portal 裡面放了 9 個主線章節、9 個番外、6 位女主角、34 位其他角色/陣營人物、20 個結局,以及 411 筆素材圖鑑資料。

這個頁面做的不是劇情運算,而是把作品翻譯成玩家入口。它讓一個還沒玩過的人知道:這不是單純的皇子爽文,也不是只有戀愛線的文字遊戲;它是帶著宮廷權謀、角色關係、制度改革、戰爭與代價的互動敘事。

遊戲本體:Ink、Vue、Pixi、Pinia 疊在一起

遊戲真正開始後,架構就回到前面 20 多天陸續談過的那套。

Ink 管劇情。main.inkchapter_00_start 開始,透過 INCLUDE 串起主線、結局和番外。現在 src/narrative.ink 檔,VAR 宣告,選項行,其中帶 # choice: 標籤的選項。

Vue 管 UI。對話框、選項、存讀檔、設定、證據、結局畫面、Portal 和排行榜都在 DOM 層處理。角色立繪也是 Vue DOM 呈現,這是前面幾天已經調整過的取捨:角色不是 Pixi Sprite,方便跟文字 UI、RWD 和可及性一起管理。

PixiJS 管舞台。背景、CG、VFX、轉場在 Pixi 層負責,PixiStage 用 1920×1080 作為基準尺寸,resize 時依容器比例縮放並置中。這讓遊戲畫面可以維持固定構圖,不會每個裝置都重新算一套座標。

Pinia 則是遊戲狀態的集中點。src/stores/story.ts 開頭就寫得很直接:UI 元件和 Pixi 畫面都讀 store,不直接碰 inkjs。Ink 變數透過 _syncVariables() 拉回 UI,UI 操作則在適當時機寫回 runtime。這個邊界讓專案後期還能繼續加章節和番外,不至於每個元件都直接伸手改劇情狀態。

存檔:公開版本最不能壞的地方

對文字冒險來說,存檔是信任問題。

目前存讀檔以 IndexedDB 為主,StorageAdapter 開了 saveSlotssettingsunlocksmetadata 四個 object store;如果 IndexedDB 不可用,才 fallback 到 localStorage。SaveManager 負責建立存檔 payload,加上 schema version、story version、asset version、更新時間和 checksum。

現在的 SAVE_SCHEMA_VERSION 是 4,STORY_VERSIONASSET_VERSION 都是 0.1.0。讀檔時會先驗 checksum,再檢查版本相容性;舊版可升級就透過 migration 升級,過新的存檔則擋下來。

這一段沒有什麼戲劇性,但公開版本最需要它。玩家可以原諒一張 CG 晚一點補,也可以接受某個支線之後再打磨;但如果玩了兩小時,隔天讀檔壞掉,那信任就很難回來。

正式公開後的互動:鮮花與雞蛋榜

/ranking 是這次公開很有趣的一塊。

它不是遊戲本體必要功能,但它讓公開後的互動不只停在「玩完、關掉」。玩家可以替喜歡的角色獻花,也可以對讓自己牙癢癢的角色丟雞蛋。

https://ithelp.ithome.com.tw/upload/images/20260829/20183394aaZmT71Kde.png

測試與發布檢查

目前自動化測試的核心是 npm run test,它串了 22 支 tsx scripts/test-*.mjs

  • 存檔管理與版本遷移
  • StoryRuntime
  • Ink tag parser
  • StoryCommandRouter
  • Demo / 正式結局 resolver
  • 番外解鎖
  • CH00 到 CH08 分支測試
  • 證據系統
  • 角色事件
  • PixiStage
  • 場景材質/display object 生命週期
  • BundleRegistry 執行期章節注入

Day27 已經講過,這批測試強在劇情邏輯和分支。真正公開前,我會至少跑:

npm run typecheck
npm run test
npm run validate:story
npm run validate:assets
npm run test:e2e
npm run build

這裡也留一個註記:自動化能擋很多錯,但目前手機真機、Safari、Firefox、社群分享預覽、Lighthouse 分數,還需要繼續補。

28 天到底堆出了什麼

如果只列功能,這 28 天看起來很像一張 checklist:

  • Ink + inkjs 劇情核心
  • Vue 3 + Pinia UI 狀態
  • PixiJS 場景與特效
  • IndexedDB 存讀檔
  • 四通道音訊:BGM、Ambience、SFX、Voice
  • 主線序章到第八章
  • Demo 結局、正式結局、六位女主角感情結局
  • 番外一到番外九
  • Portal、素材圖鑑、結局圖鑑
  • 鮮花與雞蛋榜
  • Vercel 部署設定、Edge Config 章節鎖、Upstash Redis 投票
  • 22 支邏輯與分支測試

但真正讓我有感的不是數量,而是這些東西終於能放在同一個入口裡運作。玩家不是在看一堆檔案,而是在進入一個世界。

這也是 Day29 最值得記下來的地方。公開不是終點,是專案從「我自己知道它能跑」變成「別人也能進來碰它」的那一刻。

接下來要做的事反而更清楚:補跨瀏覽器 E2E、補社群分享標籤、整理回饋入口、繼續清正式結局與手機裝置的風險。下一篇 Day30,我會回頭談整個 30 天裡 AI 到底幫了什麼,以及哪些地方還是只能靠人慢慢磨。

《九重燼》官方 Portal


上一篇
Day28 打造《九重燼》官方 Portal
下一篇
Day30 AI 改變了我的遊戲開發:30 天打造《九重燼》的總結與未來規劃
系列文
《九重燼》Vue3 + PixiJS + Ink.js 視覺小說遊戲開發全紀錄30
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言