故事

平安夜凌晨的
兩次建置

逆向遊戲檔案時，偶爾會挖到不是資料的東西 —— 開發者電腦上的資料夾路徑、每個檔案編譯完成的那一秒。 把 anims.big 裡 243 個封包的時間戳排起來， 可以看見 2004 年那個團隊做完這款遊戲動畫的最後幾小時（遊戲本體的執行檔要到將近一個月後才編譯完成，見下方訂正）。

先說這些資料哪來的

遊戲的動畫全部裝在一個 anims.big 裡，解開有 730 個子檔。 其中 244 個副檔名是 .axt —— 打開一看，是純文字的編譯清單：

為什麼是 244 而不是 243：243 個封包各帶一份自己的編譯清單， 另外還有一個叫 Banklist.axt 的總表（只有 42 個位元組， 列著 5 個庫名），它不屬於任何一個封包。所以下文講封包時是 243， 講 .axt 檔時是 244。詳見動作庫那頁。

[Version 0.03]
	1103890691	Dec 24 2004 04:18:11

[Bank]
	CLOSE_UP

[Directory]
	D:/mvp2004/artwork/anims

[Files] 84
	u_readyidle          1103876064	Dec 24 2004 00:14:24
	sb_strike04          1103875954	Dec 24 2004 00:12:34
	sb_strike03          1103875954	Dec 24 2004 00:12:34
	...

這是 EA 的動畫工具在打包時自動寫進去的：這個封包叫什麼、來源資料夾在哪、 裡面有幾個動畫、每個動畫是什麼時候編譯的。它從 2004 年一直躺在遊戲檔案裡到現在。

那台電腦上的資料夾

順帶一提：資料夾叫 mvp2004，但遊戲叫 MVP Baseball 2005 —— 體育遊戲通常以發售季命名，開發期則落在前一年。

兩個階段，中間隔了四小時

把所有時間戳排出來，會看到很清楚的兩段：

2,024 個動畫在八分半鐘內全部編譯完，然後隔了大約四小時， 243 個封包在兩分半鐘內打包完成 —— 平均每秒 1.56 個。

那天凌晨零點五分

這批動畫的編譯時間，是12 月 24 日的凌晨零點五分到零點十四分。

那是平安夜的凌晨。四小時後、清晨四點多，最後一次打包完成。

封包裡有什麼

243 個封包不是平均分配的。最大的一個裝了超過一半的動畫：

SIGB 是什麼？打開一個就知道了

編號 SIGB0014 這個封包裡有 15 個動畫，名字是這樣的：

b_ichirotobpreswing      ← 進入預備動作
b_ichirowiggle           ← 那個著名的擺動
b_ichiroswinglos         ← 揮棒(低外角)
b_ichiroswinglis         ← 揮棒(低內角)
b_ichirotostance         ← 回到打擊姿勢

是鈴木一朗。EA 給了他一整組專屬動畫 —— 從進打擊區、招牌擺動、到不同球路的揮棒軌跡。

而這樣的封包有 66 個（打擊姿勢庫）加 59 個（投球姿勢庫）， 合計 125 個專屬動作庫。把這 125 個庫的動作檔名全部列出來看， 通篇掛著球員名字的是 102 個；另外 23 個裝的是通用姿勢與投法。 也就是說，這款 2005 年的遊戲裡，有 102 位球員擁有自己的動作，不是共用同一套動畫。

訂正2026-09-06：本頁原本在這裡寫的是 「125 位球員擁有自己的動作」，那是把庫的個數當成球員人數。 125 是 SIGB 66 ＋ SIGP 59 的庫數，其中 23 個庫裡一個球員名字都沒有 —— SIGB0000–SIGB0006 是共用的打擊擺動、SIGP0000–SIGP0009 是投法通稱（高壓、側投、下勾這類），再加 cooperstown01–03 的泛用填充打擊、投球各一組。 細節見動作封包那頁。

⚠️ 那不是遊戲的最後一次建置 —— 本站 2026-08-28 訂正

還有一個小東西：換行符號是混的

那 243 個封包檔全部在 2 分 36 秒內產出，看起來是同一支工具跑完的一批。 但打開來看換行符號：

這張表數的是 244 個 .axt，比封包數多一個 —— 多的就是上面那個 Banklist.axt（它是 CRLF）。 只算 243 個封包自己的清單檔的話是 CRLF 199、LF 44。

兩組的時間戳互相交錯（LF 那組落在 12:18:50–12:20:32， CRLF 那組 12:17:57–12:20:33），所以不是先跑一批再跑另一批。

未解 為什麼同一次批次裡會混兩種換行符號，本站沒有答案。 一個沒有證據的猜想是：打包工具把來源檔的內容原樣抄過去， 而來源檔來自不同人的機器。本站沒有量到任何東西支持這個猜想，所以只寫到這裡。

這件事對改檔的人有實際意義：本站在 版面檔那頁反覆警告「.fel 全部是 CRLF， 編輯器統一成 LF 會讓檔案壞掉」。動畫封包不適用那條警告 —— 它本來就兩種都有。「這個遊戲的文字檔都用 CRLF」是錯的。

為什麼這些東西還在

這些時間戳和路徑對玩遊戲毫無用處。它們留在檔案裡， 單純因為那是打包工具的預設輸出，而沒有人特地把它清掉。

二十年後，它讓我們能還原那天凌晨發生的事： 兩千多個動畫在八分半鐘內編譯完成，四小時後打包 —— 而遊戲本體的執行檔要再過 28.5 天（2005-01-22）才編譯完成。

如果你想自己看：這些資料在 data\anims\anims.big 裡的 .axt 檔。 打開方法見 BIGF 格式， 判斷檔案類型見 五秒看穿一個檔案。

📌 重點整理

• 一句話 anims.big 裡 243 個動畫封包留著 2004 年開發現場的資料夾路徑與逐檔編譯時間戳，二十年後還能把那個團隊做完動畫的最後幾小時排出來。
• 那幾小時的數字 2,024 個動畫在 12 月 24 日 00:05:50 到 00:14:26 之間編譯完，只花 8 分 36 秒；隔了約四小時，243 個封包在 04:17:57 到 04:20:33 打包完成，2 分 36 秒，平均每秒 1.56 個。時區是從檔案裡同時記著的 Unix 時間戳與人類可讀時間正好差 8 小時推出來的，那台電腦設在 UTC-8。
• 那台電腦上的資料夾 243 個封包全部指向 D:/mvp2004/artwork/anims。資料夾叫 mvp2004 而遊戲叫 2005，是因為體育遊戲通常以發售季命名，開發期落在前一年。
• 102 位球員有自己的動作 共用庫 DEF_BANK 一個封包就裝了 1,052 個動畫、佔全部的 52%，剩下近半分散在 66 個打擊姿勢庫與 59 個投球姿勢庫，合計 125 個；其中 102 個庫的動作檔名掛著球員名字，另外 23 個裝的是通用姿勢與投法（2026-09-06 訂正：原本寫「125 位球員有自己的動作」，那是把庫的個數當成球員人數）。打開 SIGB0014 看到的是鈴木一朗，從進打擊區、招牌擺動到不同球路的揮棒軌跡都有。
• 同一個團隊做了相反的決定 動作走個性化，臉部材質走可互換：剛安裝好的原版 models.big 裡 504 個球員臉皮，504 張全部是同一種像素格式、同一個內部標記，零例外（三份剛安裝好的原版都量過）。2026-09-05 訂正：本頁原本引用的 894 / 890 / 893 量的是本站測試機那份裝過模組的 models.big，那份裡的 4 個與 1 個「例外」才是 EA 出貨時用的規格，是後來被換掉的，不是 EA 留下的。
• 最大的一次訂正（2026-08-28） 這一頁原本叫「平安夜凌晨的最後一次編譯」，但它從頭到尾沒有量過遊戲本體。去讀執行檔自己的建置時間戳才發現，官方英文版 mvp2005.exe 是 2005-01-22 才編譯完（動畫打包完之後 28.5 天），官方繁體中文版又晚了 25.5 天。頁面裡每一個數字都是對的，錯的是標題替那些數字加上了一個沒有量過的結論，而「最後一次」是全稱宣稱，要成立就得證明沒有更晚的。
• 換行符號是混的 243 個封包自己的編譯清單檔是同一次批次、2 分 36 秒內產出的；連同不屬於任何封包的 Banklist.axt 一起數的 244 個 .axt 裡，有 200 個用 CRLF、44 個用 LF（只算 243 個封包的話是 CRLF 199、LF 44），兩組時間戳互相交錯，所以不是先跑一批再跑另一批。這件事對改檔的人有實際意義：本站在版面檔那頁反覆警告「.fel 全部是 CRLF，編輯器統一成 LF 會讓檔案壞掉」，動畫封包不適用那條警告，「這個遊戲的文字檔都用 CRLF」是錯的。
• 本站沒驗的 時間戳只說明「什麼時候編譯」，不能證明當時有人坐在電腦前，建置伺服器在凌晨跑批次是業界常態，「有人熬夜趕在假期前收工」很容易想像，但檔案裡沒有任何東西能證實；封包的用途是看名字推測的；為什麼同一次批次會混兩種換行符號未解，那個「來源檔來自不同人的機器」的猜想本站沒有量到任何東西支持。

接下來

• 五秒看穿一個檔案 —— 自己去挖挖看還有什麼
• 遊戲檔案地圖 —— 224 個封裝檔分別裝什麼