兩條路：重寫引擎，或在原版上疊中文

《青色枷的詛咒》和《光芒之池》是重寫整個遊戲。做到第三款時，作者認為成本太高，改寫一個只負責執行原版的 DOS 模擬器，再把畫面輸出換成中文。後六款都走這條路。

第一條路：用 Go 重寫

金盒子遊戲的劇情和事件寫在一種叫 ECL 的腳本位元組碼裡，圖、地圖和腳本都裝在 DAX 資料檔。重寫的做法是把這些格式全部解開，用 Go 和 Ebitengine 重新實作規則、戰鬥和畫面。

可以重用的機制放進獨立的共用引擎（golden-box-remake-engine，private repo）：DAX 解碼、ECL 虛擬機、AD&D 共用規則、存檔基礎。每款遊戲的劇情、座標、翻譯都寫成 JSON 的 game pack，引擎裡不能出現任何作品專屬的名字或數字。

這條路的好處是畫面和操作完全自主，可以做原版忠實與現代主題兩種版面，手冊和攻略也能自然接進去。代價是規模。《青色枷的詛咒》有 498 個 Go 檔、142,653 行，反組譯台帳 2,874 個函式，規格文件超過一千份。

第二款也不能照搬。兩款共用同一套系統，但 ECL 的位址基準不同：《青色枷的詛咒》是 0x8000，《光芒之池》由原版載入器算出來是 0x9900。運算元個數也隨各作的直譯器版本而變。所以共用引擎只保存第二款驗證過的形狀，作品常數一律留在作品自己的 repo。

為什麼換路

最近在老遊戲重製上碰了些挫折。我一直想把遊戲完整重製，但燒了不少 Token，進展卻仍然有限。這次受挫，也讓我重新想了一遍：我最想完成的，究竟是什麼？

答案其實很簡單：讓老遊戲能用中文玩，打破當年阻擋玩家的語言隔閡，也把那個年代的電玩文化用中文保留下來。

靈感來自葉俊宏的《叛變的克朗多》中文化，那個專案在 DOSBox 內攔截繪圖函數來呈現中文。這個方法可行，但處理流程還要配合 DOS 與原遊戲的記憶體管理，想擴充時會受原有架構限制。所以作者換個方向，不把自己限在 DOSBox 裡。

第二條路：dosgolem

dosgolem（DOS 魔像）是一個無頭、決定性、可以當 Go 套件 import 的 DOS 執行器。它原本是為了和原版對拍而寫的：DOSBox 為人坐在前面玩而設計，要觀察只能截圖，dosgolem 則可以直接回答「原版跑到這一步時這個變數是多少」。同樣的能力也能用來攔截遊戲的文字輸出。

以《拯救地球》為例，架構分三層：

• 前端：把鍵盤轉成 BIOS 按鍵字組，把滑鼠左鍵換算成 DOS 座標。說明、倍率、靜音、全螢幕和截圖由前端自己處理，不送進遊戲。
• dosgolem：把按鍵放進 int 16h 鍵盤緩衝，把滑鼠狀態交給 int 33h，依機器時脈推進原版程式，並以唯讀方式回報每步進入點、畫面寫入與聲音事件。
• 遊戲專屬層：辨識原版的印字呼叫，用英文原文查 TSV 譯文表，在覆繪層畫中文。原版之後重寫同一格時，覆繪自動移除。

規則有一條不能動：譯文只影響顯示，不進入條件比較、資料查找、檔名或存檔。英文原文是穩定的比對鍵。只有經原版追蹤證實的呼叫位置、原文與畫面區域，才能觸發覆繪。沒辨識到的輸出保留英文，不猜著補。

這條路省下規則和戰鬥的重寫。《銀色匕首之謎》從立項到 v.1.0.0 是 2026-10-22 到 10-23，前提是沿用前幾款累積的工具。限制是規則和存檔都留在原版，能改的只有呈現層。還沒量到的輸出路徑會露出英文，《拯救地球》的第 5 章之後就是這樣。

Go 畫布接管繪圖

早期做法是原版先畫完整畫面，再蓋上中文或 HD。原版字有可能先露出來，切換時會閃。《黑暗之后》和《黑暗之池》往前多走一步：已經掌握的繪圖命令在原版像素迴圈之前就交給 Go 畫布，跳過對應的原版繪圖。圖片、字形、遮罩、填色、清屏和搬頁都由 Go 處理，遇到未知或越界的命令才保留原版一次。

《黑暗之池》的標題、完整片頭、讀檔介面、戰鬥 DEMO 和正常存讀檔等六條路線，共 15,073,225 個畫面位元組全由 Go 演算法計畫寫入，原 x86 像素寫入為 0，狀態、畫面與存檔維持一致。這個結果只涵蓋走過的路線，沒走過的場景不外推。

選哪一條

來源：青色枷的詛咒 README、Gold Box 系列重用邊界、光芒之池技術總覽、拯救地球 README、dosgolem README。《黑暗之后》與《黑暗之池》的數字來自各自的專案文件（private repo）。