Time-Limited Pass Item Design¶
概念概覽
「可無限使用」的判斷條件¶
核心知識¶
「可無限使用」的判斷條件¶
限時道具是否可無限使用，不由單一枚舉決定，而是由兩個欄位共同判斷：
SecondaryType（次要類型枚舉）：標記此道具屬於哪種特殊類型（如StaminaPass）- 時間欄位（過期時間戳）：道具是否仍在有效期內
缺少任一條件（例如類型符合但已過期）則判定為無效，不可豁免。
同類型道具的獨立性¶
相同 SecondaryType 但時間戳不同的道具，在後端是**獨立實體**：
- 後端不自動疊加（例如兩張「1小時無限體力」不合併為「2小時」）
- 前端可自行將同類型通行證的剩餘時間相加後顯示，純 UI 層處理
- 此設計對玩家體驗較不友好，但後端實作簡單、邏輯清晰
經驗教訓¶
-
判斷限時道具有效性必須同時檢查類型枚舉與時間戳，缺一不可
-
後端「不疊加」+ 前端「合併顯示」是遊戲道具系統的常見折衷方案
-
道具獨立性設計需在需求階段明確告知企劃與前端，避免後期誤解
常見陷阱¶
-
只判斷 SecondaryType 而忘記檢查時間戳，導致過期通行證仍被視為有效
-
後端嘗試自動疊加同類型道具，增加實作複雜度且容易引入 race condition
相關概念¶
- Game Item Exemption Resource Architecture
- game-stamina-system----dangling---
- luban-config-system----dangling---
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- GameData Flag Semantics (BooleanBackpack vs BooleanAutoOpen) — 共享：
game-design,item-system/ 獨特：bug-diagnosis,gamedata - Pool Resource Stamina Routing — 共享：
game-backend/ 獨特：honest-boundary,pool-resource - PendingEvents Middleware Pattern for Real-time HUD — 共享：
game-backend/ 獨特：event-driven,eventstore
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-18 | fb39b34e-2ba6-4c2c-9f93-26e1e73d0371 | 明確了限時通行證的後端判斷模型：SecondaryType + 時間欄位雙重條件，同類型不同時間戳為獨立實體不疊加 |