跳轉到

D-20260528-02｜B 軸：UGC 資產 schema 版本系統

背景與驅動力

起點是使用者一問：「場地有 open4wd_track_version，零件是不是也要？」——既然上傳 ／ 編輯 ／ 上鏈流程已統一，分類與版本也應統一，討論遂演變成整套 UGC 資產 schema 版本系統。與既有 A 軸（client build 六欄位 checkCompatibility）區分，新立 B 軸：每顆 GLB 的 extras 符合哪版 schema。

考慮過的選項

  • 沿用場地專屬 marker、零件另立各自 marker：識別欄位碎片化，廢除 open4wd_track_version。
  • 最低支援版寫成 client 靜態常數：無法反映生態實際遷移進度，改為 ledger 衍生動態值。
  • 統一 marker＋ 生命週期 ＋ 動態 min（採納）。

決定

  • 識別 marker 統一為 open4wd_version（Root Extras、per-type 命名空間）＋ type enum（8 零件 ＋ track）；loader 三分支：無 marker 拒載 ／track／ 零件。
  • 生命週期：活躍 → 棄用（仍可用；含棄用件則該 type 全場降版本）→ unusable（picker 不出現、仍可被 fork）。bump 原則：破壞性變更 → 棄用；非破壞 → 只提示。
  • 升級三分類（自動 ／ 需手動編輯 ／ 無法升級）；每道破壞牆附雙向遷移描述。
  • 降版本運算只換 per-asset「extras → 物理輸入映射」、跑當前引擎、不綁 Rapier；跨資產聚合一律走 derive_logic（A 軸全場一致）。
  • 動態最低支援版：ledger 衍生，DEPRECATED_TO_UNUSABLE_THRESHOLD＝3（數不同創作者、單調 ratchet），以 deriveStateAt(checkpoint) 對進房 pin 的檢查點計算。
  • 經濟與血緣：版本後繼升級上鏈免費（限真後繼）；版本後繼血緣不是 fork、不新增分潤層，評分 ／ 使用次數 ／fork 樹位置在血緣節點層 aggregate。
  • ledger 新增 AssetVersionUpgradeEvent（新 CID → 舊 CID 後繼邊）與 AssetVersionDerivedState。

後果與影響

版本規範.md 自此有 B 軸專章，成為 UGC schema 演進的權威；replay 明列暫不實作的已知相依。後續 D-20260703-02 把整套機器掛上 client major 發版軸並收斂升級通道，D-20260703-03 釘死房間 pin 的檢查點對象與時效。