設計規範

§1 以下項目須遵守本規範：

• 任何透過 MMOitems 製作的裝備（盔甲套裝、飾品）
• 任何特殊武器（劍、斧、弓、弩、三叉戟等非原版附魔武器）
• 任何特殊工具（稿子、鏟子、鋤頭等非原版附魔工具）
• 任何帶有自訂數值的消耗品、捲軸、材料
• 活動獎勵、兌換物品中涉及上述類別者
• 伺服器官方舉辦的各類活動（常駐、限時、比賽、社群）
• 自訂物品紋理（MMOitems、ExecutableItems 等插件使用的自訂模型與貼圖）
• 伺服器資源包（整體 resource pack，含 UI 介面、環境方塊、音效替換、語言檔案等）

§2 以下項目不適用本規範：

• 純原版 Minecraft 物品（僅含原版附魔）
• 純裝飾性物品（無戰鬥或生產數值影響）
• 稱號、聊天框等非道具類獎勵
• 玩家個人使用的客戶端材質包（OptiFine CIT 等本地替換）
• 原版 Minecraft 內建的材質變種（如方塊隨機模型）

§3 數值基準線

• 所有特殊裝備的數值必須基於原版同類物品做為起點
• 標示的附魔等級（如效率、保護）必須與實際效果一致，不得標示高於實際數值
• 插件（MMOitems）與原版的計算方式不同，數值設計前必須實測驗證，不可直接套用原版公式

§4 階梯限制 — 特殊裝備的數值不得超過以下天花板（相對原版滿附魔）：

以上數值為建議基準，實際數值應視取得難度與經濟狀況調整。任何超過天花板上限的設計，需經伺服主親自批准。

§5 連動效應檢查

• 設計前必須考慮：搭配捲軸、烽火台效果、套裝組合後數值是否超標
• 與防礦透、反作弊等插件的交互影響需一併確認
• 工具類裝備需確認與連鎖挖掘等機制的疊加效果

§6 分流限制

• 分流二不支援 MMOitems，所有特殊裝備在分流二均不可使用
• 設計時需考慮：玩家在分流一取得裝備後到分流二的行為影響

§7 兌換經濟平衡

• 兌換材料的取得途徑與取得速率必須納入設計考量，不可只看裝備本身的數值
• 若兌換材料可透過大量採集取得（如獄髓等礦物），需評估玩家大規模開採對經濟的衝擊
• 建議兌換材料優先使用受控產出途徑（任務幣、活動獎勵、簽到等），減少可被大量刷取的開放材料

§8 提案階段 — 設計師提出物品方案，須包含以下內容：

§9 審核與測試

• 方案提交後，至少須有一位非設計者的管理人員 review
• 審核重點：數值是否在規範範圍內、取得難度是否匹配、連動風險是否可控
• 通過審核的物品，須在測試環境或小範圍驗證實際效果
• 正式上線前須發佈公告，說明物品數值、取得方式與設計理念

§10 調整原則

• 先觀察，再動刀 —— 上線後至少觀察 1 週再評估是否需要調整
• 小幅度優先 —— 每次調整幅度不超過 20%
• 向下兼容 —— 優先調整取得門檻，而非直接砍已發放物品的數值

§11 補償與退回機制

• 因數據問題導致物品下架的，玩家可申請 100% 退回兌換資源
• 因平衡調整而下調的，應視影響程度提供部分補償
• 已透過該裝備獲得的遊戲利益（如加速挖礦獲得的資源）不追溯

§12 緊急處理

• 發現嚴重數據問題（如數值溢出、功能異常）時，可先緊急下架並公告說明
• 緊急下架後 48 小時內須發佈正式說明與後續處理方案
• 緊急處理僅限伺服主或技術人員執行，一般設計師不得自行下架

§13 適用範圍 — 以下類型的活動須遵守本章規範：

• 伺服器官方舉辦的限時活動（節慶、比賽、挑戰等）
• 常駐活動的新增、改版或獎勵調整
• 管理團隊自行設計的小型活動
• 玩家提案經核准後執行的活動

§14 設計原則

• 公平性 — 活動門檻不應造成新舊玩家的過大差距，獎勵不應只對特定玩家群體有利
• 可參與性 — 活動時間應考量不同時區玩家，至少提供 3 天以上的參與窗口
• 趣味優先 — 活動的核心應是好玩，而非單純刷材料或重複勞動
• 資源可控 — 活動產出的資源量必須經過經濟影響評估，避免通膨
• 透明公開 — 活動規則、獎勵機率（如有隨機性）、參與條件須在公告中完整說明

§15 活動分類

§16 獎勵階梯 — 活動獎勵應分層設計，避免單一大獎造成過度競爭：

§17 獎勵平衡限制

• 活動獎勵中的裝備、武器、工具，數值必須符合第二章的道具設計規範
• 限時活動的獎勵不應永久性地改變伺服器經濟結構
• 排名獎勵的戰鬥數值增幅不得超過同期常駐活動裝備的 120%
• 消耗性獎勵（經驗、貨幣、材料）的單次活動總產出需經經濟影響評估
• 純外觀獎勵（特殊粒子效果、限定皮膚、獨特稱號）不受數值限制，可作為高排名獎勵

§18 限定與回歸機制

• 限時活動的獎勵可以標註「限定」，但應規劃未來可能的回歸管道
• 完全絕版的獎勵會造成 FOMO 焦慮與新玩家劣勢，不建議常態化
• 若限定獎勵回歸，應以不同形式呈現（例如：換色版本、同等替代品），尊重原始參與者

§19 前置準備

• 活動上線前須在測試環境完整跑過一遍流程，確認無重大 bug
• 預先準備異常處理方案：伺服器崩潰、玩家異常取得獎勵、活動進度遺失等情況
• 活動公告須包含：時間、規則、獎勵、參與方式、注意事項，至少提前 24 小時發佈

§20 防刷與反作弊

• 設計時需考慮小號刷活動的可能性，必要時設置帳號等級或遊玩時數門檻
• 重複性活動任務應設置每日/每帳號上限，避免 24 小時掛機刷取
• 排行榜類活動應有異常數據監控（如短時間內不合理的完成速度）
• 發現作弊行為時，參照管理規則處理，活動獎勵可追溯取消

§21 活動結束與善後

• 活動結束後須在 48 小時內發放完畢所有獎勵
• 活動結束後保留至少 7 天的申訴窗口，處理遺漏或異常情況
• 限時活動結束後，活動區域（如有特殊建築）應妥善處理：保留觀賞、移除或轉為常態
• 活動結束後進行復盤：參與人數、玩家回饋、經濟影響，記錄供下次參考

§22 活動提案須包含以下內容：

§23 審核標準

• 小型活動（影響範圍有限、獎勵價值較低）：至少一位管理人員核准即可
• 中型活動（涉及特殊裝備獎勵或大量經濟資源）：需兩位以上管理人員 review
• 大型活動（全服參與、含稀有獎勵或排名機制）：需經伺服主批准
• 所有活動審核時，應同時確認獎勵物品是否符合道具設計規範（第二章）

§24 解析度限制

• 標準解析度為 16×16 像素，與 Minecraft 原版風格一致
• 特殊 UI 元素（如自訂選單背景、活動封面）最高可使用 32×32，但須確保在預設 GUI 縮放下清晰可辨
• 嚴禁使用非正方形像素比例（如 16×32 的拉伸貼圖）
• 所有像素必須為整數對齊，不得出現子像素偏移或抗鋸齒模糊

§25 檔案格式與大小

整體資源包壓縮後大小建議控制在 10MB 以內。過大的資源包會導致玩家首次載入延遲，影響加入體驗。每次更新應記錄壓縮後體積變化。

§26 命名規範與目錄結構

• 所有自訂紋理使用統一前綴 sw_（seawind 縮寫），避免與原版或其他資源包衝突
• 目錄結構遵循 Minecraft resource pack 標準：assets/minecraft/textures/... 或 assets/seawind/textures/...
• Custom Model Data 使用有組織的編號區段，避免隨意指定造成衝突：

  編號區段	用途
  1000–1999	魚套系列裝備
  2000–2999	風汐系列工具
  3000–3999	活動限定物品
  4000–4999	副本 Boss 專用
  5000–5999	會員專屬外觀
  9000–9999	UI 介面與系統用

• 新增編號區段時須先在本規範中登記，避免多人同時設計時撞號

§27 透明度與圖層規範

• 物品貼圖背景必須完全透明（alpha = 0），不得殘留白邊或半透明雜訊
• 半透明效果（如發光、粒子拖尾）應使用獨立圖層，alpha 值建議在 64–192 之間
• 物品在物品欄中的可讀性優先：即使有花俏的裝飾，物品輪廓必須在 16×16 縮放下辨識得出

§28 風格定位

• 海風資源包以 Minecraft 原版像素風格為基底，不偏離原版的色彩飽和度與光影邏輯
• 允許在原版基礎上添加伺服器專屬特色（如海風主題色調、專屬標誌），但不應過度突兀
• 嚴禁使用真實照片、AI 生成圖片、或非像素藝術風格的素材直接貼入

§29 色彩原則

• 主色調參考 Minecraft 原版 palette，保持與遊戲環境的自然融合
• 伺服器主題色可適度融入（如海風的品牌藍 #9dafff、薄荷綠 #a8e6cf），但僅作為點綴，不應覆蓋整體色調
• 同一系列的裝備紋理應有統一的色彩語言（如魚套以水藍/青綠為主、風汐系列以灰白/淡紫為主）
• 避免使用純黑（#000000）或純白（#FFFFFF），改用帶有色調的深色/淺色，更自然

§30 像素藝術規範

• 線條：使用明確的輪廓色（outline），輪廓色應比填充色深 2–3 個色階
• 光影：光源方向統一為左上方，與 Minecraft 原版一致
• 陰影：使用至少 2 層陰影（主陰影 + 深陰影），避免平面感
• 高光：在受光面加小範圍高光點（1–2 像素），提升立體感
• 動畫材質：幀數不超過 24 幀，每幀間隔不小於 2 tick（100ms），檔案命名為 檔名.png.mcmeta

§31 版本管理

• 資源包須在 pack.mcmeta 中標註版本號，格式為 Major.Minor.Patch
• 每次伺服器大版本更新（如 1.21 → 1.22）時，Major 版本 +1
• 新增或修改紋理時，Minor 版本 +1；修正錯誤時 Patch 版本 +1
• pack_format 須與 Minecraft 版本對應（如 1.21.x → pack_format 46）

§32 更新流程

• 新增紋理：設計師提交 PNG/JSON 檔案 + 說明用途，管理人員確認無衝突後合入資源包
• 修改紋理：須說明修改原因（修正錯誤 / 風格調整 / 數值對應更新），舊版紋理備份保留
• 移除紋理：僅在對應插件物品已被刪除時才能移除，避免遊戲中出現紫黑棋盤格錯誤貼圖
• 每次更新後須在客戶端完整測試，確認無紫黑格、模型偏移、透明度異常等問題

§33 強制載入與相容性

• 伺服器資源包透過 server.properties 設定為強制載入（resource-pack + resource-pack-sha1）
• 強制載入的資源包不得覆蓋玩家日常會看到的原版紋理（如泥土、石頭），除非是活動期間的限時替換
• 自訂物品紋理僅在持有對應 Custom Model Data 的物品時才會載入，不影響一般遊戲體驗
• 每次更新 SHA1 雜湊值須同步更新，否則玩家端不會觸發重新下載

§34 品質檢核

• 所有新紋理上線前須經過至少一人非設計者的 review，確認辨識度與風格一致性
• 在不同 GUI 縮放倍率（自動 / 小 / 大）下測試，確保可讀性
• 深色與淺色環境下各看一次（部分紋理在暗處會糊掉）
• 多人同時在物品欄瀏覽時，不同物品的紋理應有明確區別，不可太相似導致混淆