遊戲保存需要一條可驗證的界線
上週在公司做舊 NPC 模組的移植評估，我們拿 200 個行為腳本跑新版 runtime。AI 很快就把能執行的版本拼出來，半天完成過去大概需要一週的工作。第一輪看起來很漂亮，真正進測試後，角色在戰鬥結束的第 43 秒會重複觸發同一句台詞，存檔讀取也有 7 個 case 壞掉。
這讓我想到現在一批用 AI 反編譯老遊戲的專案。原本要靠社群花幾年整理的程式，現在幾天就能跑起來。2011 年的 Flash 遊戲甚至可以被搬到原生 C++，從 30FPS 拉到 165FPS。對遊戲保存來說，這個進展很難不興奮。很多數位版遊戲等伺服器關掉後，玩家連自己買過的內容都進不去。
但「跑得動」和「可以公開」中間，缺了很大一段工程。我的觀察是，日本遊戲公司對這類案子最在意的通常有三件事：來源能不能追、行為有沒有對齊、權利範圍能不能說清楚。AI 產出的 code 如果無法對應到輸入素材與轉換紀錄，後面的人就很難判斷它是 clean-room 重建，還是把商業程式換了寫法。
我會把保存專案拆成一張很笨但實用的表：每個模組記錄原始 binary 的版本、輸入證據、AI 生成批次、人工修改 commit、功能測試與權利狀態。權利不明的內容只能留在本地研究環境；可公開的部分再進 release branch。驗證也不能只看畫面像不像，至少要跑存檔相容、輸入延遲、固定亂數種子的 replay，以及 30 分鐘以上的穩定測試。
有人會覺得這樣太慢，既然 AI 幾天就能做完，何必再補這些文件。可是一個保存專案若只能靠作者口頭保證乾淨，它可能在第一封下架通知來時就消失。速度省下來的時間，應該拿去建立可驗證的來源鏈。
我其實很希望這類工具繼續進步。京都不少小型工作室手上有十幾年前的作品，原始建置環境早就不存在，連當年的 middleware 授權也找不到。AI 可能真的能救回一批原本注定失傳的遊戲。只是保存做得越快，界線要寫得越清楚。否則最後得到的可能是更強的 DRM，玩家和小工作室都更難保存自己的作品。
作者：嵐山貓