怎麼確認真的能玩

技術篇

自動測試全綠，只代表測試涵蓋的路徑沒問題。這六個專案多次遇到測試通過、玩家卻一開就壞的情況，所以驗證的重點放在兩件事：走正常玩家會走的路，以及檢查最後交到玩家手上的那個檔案。

截圖不該需要顯示卡

V 代早期把繪圖綁在 Ebitengine 上，所以無頭截圖要啟動虛擬顯示、建立軟體 OpenGL 環境，再等事件迴圈呼叫繪圖。這條鏈卡住了。指令跑了五個小時沒有輸出，最後只能關掉容器。

加逾時或換 OpenGL 後端，只是讓失敗來得快一點。專案改成所有畫面都畫在 CPU 的記憶體影像上，Ebitengine 只負責上傳和收鍵盤。之後截圖變成秒級的函式呼叫，持續整合不需要顯示環境，截圖和實機畫面也共用同一份繪圖程式。

II 代的回歸測試直接發道具、瞬移到定點，一路綠燈。實際開一局才發現，新角色落在一座只連著城堡的小島上，走不到城鎮，整局卡死。修正記錄在 commit 7caeb16。

從此多了兩條驗收規則：一定要另外驗沒有除錯捷徑的正常玩家路徑；世界是否走得通，用連通分量檢查，確認出生點在最大的陸地上，城鎮和出生點相連。

V 代的測試不看譯文表，實際走「交談、輸入關鍵字、讀訊息欄」這條路，掃過 135 段對話開場和 1,307 個關鍵字回應，看有沒有英文殘留。

判斷方式也要想過。譯文裡本來就有咒語和地名，不能用「有沒有英文字母」判斷。測試找的是連續三個以上的英文單字，那是殘留句子的特徵。

III 代切換到其他平台圖塊時，畫面變成青色條紋。一開始以為是縮放鏈或目錄掃描順序的問題，一度記錄成需要專門處理的深層移植錯誤。

原因和繪圖無關。C 語言遇到沒有宣告的函式，會假設它回傳 32 位元的 int。上游呼叫 CFArrayGetValueAtIndex 時看不到宣告，回傳的 64 位元指標被砍掉上半部，目錄掃描拿到壞指標。而 clang 的警告又被編譯參數關掉了。補上函式宣告後，所有平台的圖塊都正常。

找到問題靠的是加一個環境變數 U3_DBG_IMG，印出實際載入了哪些檔案，才發現換圖塊後根本沒有載入。修法是把這些宣告集中放進 mac_shim.h，強制引入每個上游檔案。

有些問題只有打包後的檔案，在它自己的啟動方式下才會發生。

工作目錄：在 macOS 雙擊 .app，工作目錄是根目錄，相對路徑全部找不到（I 代，玩家回報）。在 Windows 雙擊 exe 也有同樣的問題，直接閃退（III 代）。測試都是先 cd 到解壓目錄才跑，所以測不出來。修法是程式啟動時先切到執行檔所在的目錄。
Windows 的 zip：V 代的檔名一律用 ASCII，因為 zip 沒有檔名編碼欄位，非法的 CP950 序列會讓解壓工具直接跳過該檔。.bat 存 CP950，.txt 存帶 BOM 的 UTF-8。這些規則由 tools/checkpkg.py 每次檢查。

容器裡測不到真實的音效卡和顯示卡。IV 代的 macOS 開頭靜音、城鎮移動卡死、Windows 音樂頓挫，都是社群朋友在自己的機器上找到並修正的。

「和原版一樣」也需要外部證據。V 代的文件直接標明：機制目前只有靜態讀碼支撐，和 DOSBox 原版並排實測還沒做過。沒做過的事就寫沒做過，讀者才知道現在的狀態到哪裡。