adventure-table

Adventure Table — 規格企劃

本文件是 Adventure Table 的產品/玩法規格單一事實來源。它描述網站要支援的跑團方式、Human 與 AI 如何參與、各系統必須呈現的產品行為,以及第一版明確不做的內容。

判準:如果這份文件的一句話不同,DM/Player 的實際跑團方式可能就不同。 DB schema、API endpoint、MCP tool 拆法、service boundary、event queue、transaction persistence 等技術細節不在本檔逐項綁死;實作只要忠實滿足本檔產品行為即可。

最後更新:2026-09-13

首發規則集:D&D 5e 2014
Built-in Content:SRD 5.1
專案性質:朋友間私人使用,非預計商品化平台
核心特色:外部 AI 可透過 MCP / Site Tools 正式進入桌內當 DM 或 Player。


本檔範圍與邊界

類型 規則
產品定位、玩法、跑團流程 以本檔為準
UI / UX 第一版行為 本檔已定義者直接實作;未定細節由實作者按本檔原則補齊
D&D 規則行為 以本檔明列的 D&D 5e 2014 規則與 Structural Validation 為準
DB / API / MCP / service / persistence 由實作者自行設計,不反過來限制 DM 或玩家
非 SRD 內容 依實際需要,由使用者提供資料後逐步補入
尚未拍板的重大產品問題 只有真的會改變跑團方式、核心權利或規則玩法時才回來討論

討論與實作分流原則:產品行為先定,技術實作服從產品;不要為了資料結構方便,反過來要求真人 DM 多填資料或改變桌上跑團方式。


〇、產品基線

以下是全系統共用的硬原則:

  1. 桌上跑團優先:先想真人實際怎麼跑,再決定網站怎麼支援。
  2. 不包山包海:網站只處理需要共享、同步、計算、保存、權限控制或 AI 接入的資料。
  3. Optional 不變 Mandatory:Quest、Scene、NPC Notes、Position Note、Shop Listing 等輔助資料,不得因為存在資料結構就變成必填工作流。
  4. Server 是唯一真實狀態來源:Human UI 與 AI Tool 使用同一套 Game State / Game Actions;AI 不直接操作 DB raw fields。
  5. AI 是正式桌上 Actor:AI 可以是 DM 或 Player,但權限由 Role 決定,不因 Controller 是 AI 而變成另一套規則。唯一例外是 AI DM 不得修改 Player Character 的 Build,詳見〈DM 修改 Player Character〉。
  6. 秘密靠 Server 隔離:不能靠 Prompt 要 AI「不要偷看」;不該看的資料根本不送。
  7. DM 保留裁定權:敘事、即興、例外、邊界規則與無法合理自動化的空間/世界判定,由 DM 決定。
  8. 重要世界變化要寫回:AI DM 不得只 narrate;真正改變世界或資源的事情要進入 Server State。
  9. 不要做成 CRPG:網站協助跑桌,不用 Victory Screen、Auto Loot、Point-and-Click 動詞清單等電子遊戲式強制流程。
  10. 朋友自己能講好的事,不做大型制度:角色歸屬、跨 Session 換玩家/換 DM、Adventure 命名衝突等,不建立商業平台級仲裁流程。
  11. 網站本身不接 LLM API:所有 AI 能力都由使用者的外部 AI Session 透過 MCP / Site Tools 提供。網站不自備 API key、不代付費、不在後端自行呼叫模型。
  12. 支援繁體中文與英文兩種語言:介面、規則名稱與系統文字都提供繁中與英文兩套,使用者可隨時切換,切換只改顯示語言,不動角色資料。使用者自己輸入的文字不翻譯。第一版只做這兩種語言。
  13. Web 是 Room-first;Standalone 是 Character-first:Web 版所有 Character / Builder Draft 都在某個 Room workspace 內建立與管理,不再有跨 Room 的全域 Character Workshop;M03 standalone 則保持完全沒有 Room 的獨立 Character Workshop。

一句話產品摘要:一個輕量、桌上跑團優先的 D&D 5e 2014 VTT。真人 DM 可以像實體跑團一樣主要靠口頭描述,只在需要時使用網站工具;AI 則透過 MCP / Site Tools 正式加入桌內當 DM 或 Player,與真人使用同一套規則、狀態和權限系統。Adventure 只是起始模板,真正的 Campaign 世界會隨玩家行動持續變化並被保存。Web 版以 Room 作為朋友共用資料的工作區;Standalone 只保留 Character 系統。


一、產品定位、內容範圍與非商品化原則

產品定位

這不是要做成 Foundry VTT 那種包山包海的平台,也不是把 D&D 做成 CRPG。

核心定位:

最重要的產品原則:

先從實際桌上跑團的方式思考,不要為了軟體結構反過來限制 DM。

不包山包海原則

網站只處理:

需要共享、同步、計算、保存、權限控制或 AI 接入的資料。

真人 DM 本來靠嘴巴就能完成的事情,不必強迫填資料。

以下都應該是 optional:

例如:

DM:「你們進城後,守衛說北邊最近有商隊失蹤。」
玩家:「那我們去查。」
DM:「好。」

網站完全不建立 Quest、NPC、Campaign Fact、Scene,也能繼續跑。

只有真的阻止功能的資料才要求,例如:

規則內容與 Licensing

Built-in 首版:SRD 5.1,CC BY 4.0。

SRD 不等於完整 D&D。例如:

Rules Engine 可以支援更完整的機制,但非 SRD 官方內容由使用者自行提供/匯入。

Custom / 非 SRD Content

本專案不是預計商品化的平台,主要是自己開發並與朋友跑團,所以內容採逐步擴充:

第一版不需要:

使用者提供的非內建資料,由使用者自行管理來源與使用方式。


二、Human、AI、Seat、Role 與權限

Human UI 與 AI Tool

Human UI 和 AI Tool 不做兩套遊戲邏輯:

                ┌─ Human Web UI
                │
Backend Services ┼─ MCP / Site Tools
                │
                └─ Future API Agent

Human 點 Attack;AI 呼叫 attack();最後都進:

GameAction
↓
Permission / Rules Validation
↓
GameTransaction
↓
Campaign State

AI 不直接操作 DB raw fields。

Room Authority、Seat Role 與 Controller 分開

第一版不要把「誰有 Room 管理權」與「今天在桌上坐哪個位置」混成一個欄位。

Room access authority:

owner
dm
member

Seat Role:

dm
player
optional spectator

Controller:

human
ai
none

因此一個 Owner 今天可以坐 DM Seat,也可以坐 Player Seat;Owner 身分本身不是 gameplay role。DM Key 代表有 DM authority,但一場 Session 的真正 DM Controller 仍由本場 DM Seat 固定。

AI 是正式參與者,不是旁邊的聊天 Bot;AI 進桌後同樣以 Seat Role + Controller scope操作。

多 AI Session

同 Room 可同時:

ChatGPT Session A = DM
ChatGPT Session B = Mira
Codex Session C = Borin

每個 AI Session 透過 scoped Seat / Join Token 識別。不能用 OpenAI account、generic browser cookie 或 AI 廠牌識別角色。

Role 權限

AI DM 與 Human DM 的桌上 Role 權限相同;AI Player 與 Human Player 同理。Controller type 不改變 Role permission。

Server 依 Room authority、Seat Role 與當下 scope 過濾資料。

AI Player 絕不收到:

不能依靠 Prompt 要 AI「不要偷看」,Server 根本不要送。

DM 不做 Session 中途 Human ↔ AI 交接

一個 Session 開始後,DM Controller 固定。整場 Human DM 或整場 AI DM。

第一版不支援:

Human DM → AI DM → Human DM

下一個 Session 如需換 DM,再重新指定。

Player Character 可 Human ↔ AI 接手

Player Character 必須支援 Human / AI 控制權交接。

Mira
Controller = Human

玩家離席:

Controller = AI

AI 操作同一隻 Mira:同 HP、Inventory、Spell Slots、Position、Knowledge、Character Sheet、Roleplay profile。不是建立一隻 AI Mira。

玩家回來:

Controller = Human

Player AI 接手流程

Human → AI:

Let AI Control
↓
產生 scoped Seat Token
↓
AI 透過 MCP join
↓
Server 驗證
↓
Controller = AI
↓
取得 Character Context

AI → Human:

Take Back Control
↓
若有 committed transaction 先完成
↓
撤銷 AI 控制權與舊 Token
↓
Controller = Human

舊 AI Token 後續操作必須被 Server 拒絕。

Controller 與 Connection 分開

合法狀態:

Controller = AI
Connection = Offline

網站不能假設能主動喚醒一個 ChatGPT conversation。AI Offline 時玩家仍可直接 Take Back Control。

Player AI 不做戰術人格模式

不做:

Aggressive
Defensive
Support
Balanced
Risk Tolerance
Resource Conservation

AI 像真人玩家一樣依據 Character Sheet、HP / resources、Party / enemy situation、Conditions、Character Knowledge、Roleplay Guidance、Current Scene、Recent Relevant Events 自行決定。

一次性 AI Handoff Instruction

Let AI Control 時可 optional 輸入:

Temporary instruction:
「保護法師,最後一個二環法術先不要用。」

這不是 Character Note,也不是 Campaign Fact;AI → Human 後失效。

AI Player 不能因代玩而修改 Build

AI 代玩可以:Attack、Move、Cast Spell、Use Potion、Inspiration、Inventory normal use、Roleplay、Reactions。

不能因 Controller 身分進行:Level Up、Multiclass、換 Feat、改 Ability Score、Respec、改 Biography / Roleplay Guidance。

明確要求 AI 幫忙升級時,才走 Character Builder MCP workflow。

AI Event / Reconnect

網站不能假設可以喚醒 idle AI。Server 保存 durable event queue。

AI 可:

get_pending_events()
wait_for_event(timeout)

Reconnect 後可重建:Current turn、Pending RollRequest、ReactionRequest、Private event、Current game context。

未來 persistent API agent 也只需要持續 wait_for_event()

Authentication

MVP 可先不做完整帳號。

Room Password
DM Key
Owner Key
AI Join Token

Character Ownership / 非 Session 控制權

本專案是朋友間使用,不建立商業平台式 Character Ownership 系統。

不需要:Ownership Transfer Wizard、玩家間所有權仲裁、角色買斷/轉移紀錄、複雜永久 owner_user_id 工作流、玩家離群後的正式 ownership 流程。

誰平常使用哪一隻角色,由使用者自己講好。

但「不管 Ownership」不代表 Server 接受任何寫入。Server 仍需保證:

具體 Token、Scope、Lock、Concurrency 實作由技術層自行決定。

DM 修改 Player Character

DM 可以在有需要時調整 Player Character 的全部主要資料,包括:HP、Max HP、AC、Ability Scores、Skills / Saves、Conditions、Temporary Effects、Inventory、Currency、Equipment、Spell Slots、Prepared Spells、Spellbook、Features、Feats、Class / Class Level、Subclass、Biography、Roleplay Guidance 等。

正常跑團習慣仍是 Current State 經常調整,Class、Feat、Ability、Subclass 等 Build data 大致不隨便更動;但這是使用習慣,不是產品硬鎖。

DM 可以改 Build,不代表能建立內部矛盾或破損資料:

如果 DM 要做非標準規則:

DM 有高修改權限,但 Server 仍維持資料結構完整性。

Build 類重大修改宜透過 Character Version / Draft / Confirm 保留版本;Current State 類修改可走一般 GameTransaction / DM Edit。

AI DM 的 Build 修改限制

上述高修改權限只給 Human DM

AI DM 可以改 Player Character 的 Current State(HP、Temp HP、Conditions、Temporary Effects、Spell Slots、Inventory、Currency、Consumables 等),但不得修改 Build data:Class / Class Level、Subclass、Ability Scores、Feats、Features、Skills / Saves proficiency、Spellbook / Known Spells、Max HP、Biography、Roleplay Guidance。

這是「Controller type 不改變 Role permission」的唯一例外,理由是 Build 屬於玩家自己的角色設計,人類 DM 之間可以口頭講好,AI 不宜自行判斷。

AI DM 若認為某個 Build 需要調整,只能提出建議,由 Human 執行。

玩家對自己角色的 Current State 修改

Player 可以直接調整自己 Seat 所控角色的 Current State,實務上最常見的是扣 HP:

DM:「哥布林打中你,7 點傷害。」
玩家自己在 Player Card 上扣掉 7。

預設由玩家自己扣,DM 不必每筆傷害都代勞。

AI DM 可以在 resolve 傷害時代玩家扣 HP,不必等玩家自己動手;AI Player 代玩時同樣照上述 Player 權限操作自己的角色。

DM 代理 Player Seat

真人跑團時,某個玩家不在座位上,DM 就直接幫他打完那回合。網站照做。

DM 可以代任何 Player Seat 執行該 Seat 的操作,不論該 Seat 目前是:

代理操作:

DM 代理不需要事先取得授權流程,也不需要對方同意——這是桌上常態,不做成制度。


三、Room、Campaign、Session 與 Party Roster

Room / Campaign / Session

Room
├─ Character Workspace
│  ├─ Characters
│  └─ Builder Drafts
├─ Monster Templates
├─ Battle Maps
├─ Adventures
└─ Campaigns
   ├─ Party Roster → references Room Characters
   ├─ Campaign State
   ├─ Quest State
   ├─ Scene State
   ├─ Knowledge
   ├─ NPC / Monster Instances
   └─ Sessions
      ├─ Dialogue
      ├─ Rolls
      ├─ Checks
      ├─ Combat Events
      └─ Timeline

Room 是持久桌面/資料庫,也是 Web 版所有角色資料的 workspace / namespace。一個 Room 可有多 Campaign,但 MVP 同時只需要一個 active_campaign_id 作為目前選中的 Campaign。

Web Room-first / Standalone Character-first

Web 版:

Homepage
↓
Create Room / Enter Room
↓
Room
↓
Character Workshop / Campaigns / 後續 Room Assets

Web 不提供跨 Room 的 global Character Workshop,也不建立「先做一隻 global 角色,之後再決定放哪個 Room」的流程。

Standalone 版完全相反:

Standalone
↓
Character Workshop

Standalone 沒有 Room / Campaign / Session / Seat,Character / Draft 直接存在本機 SQLite。這不是「假的單人 Room」;Character Core 本身必須能脫離 Room 工作。

Room Hard Delete

Owner 可永久刪除整個 Room,需強確認。

Room Hard Delete 代表刪除整個 workspace:

不留下 orphan Web Characters。重要角色要保留,先 Export。

Campaign

Campaign 是持續存在的實際遊戲世界。

狀態:

draft
active
completed
archived

Adventure 是起始模板,不是限制玩家行動的腳本。

Room 可有多個仍在進行的 Campaign;room.active_campaign_id 只是目前 UI / Lobby 選中的 Campaign,不代表其他 ongoing Campaign 必須變 completed。

Session

Session 只是「今天坐下來玩的那一段」,不是關卡。

狀態:

active
ended
abandoned

Session End 不會:回滿 HP、回滿 Spell Slots、結束 Combat、清除 Conditions、清 Pending Action、重設位置。Campaign / Character Current State 原封不動保留。

Lobby / Session Start

Enter Room
↓
Active Campaign
↓
Player Seats
↓
DM 看人差不多到了
↓
Start Session

不強制 Ready,不要求所有角色在線。

例如:

Mira        Connected
Kael        Connected
Borin       AI Connected
Serena      Offline

DM 仍可 Start。

Start 背後:建立 Session、記錄 participants、記錄 controllers、固定每個 Player Seat 本場 Active Character、記錄 Session Start boundary、載入目前 Campaign / Character State。

完整 Snapshot / Restore subsystem 屬後續 Snapshot Phase;該 subsystem 到位後,Session Start boundary 會自動建立 Session Start Snapshot。P2 不為了這句產品需求提前做一套半成品 Snapshot store。

Late Join

Human / AI 都可 late join。DM 自己決定敘事上角色怎麼進場。網站不要要求 Spawn Point,除非正處 Tactical Combat 才需放 token。

Session End

DM 按 End Session,最多一次確認。

可以停在:

Combat Round 6
Mira's Turn
ReactionRequest pending

下次照樣續。

End 背後:

status = ended
記錄 Session End boundary
封存/保留本場 history references
記錄 participants
撤銷 session-scoped AI tokens(AI subsystem 存在後)

完整 Snapshot subsystem 到位後,Session End boundary 同時建立 End Snapshot。

End 不改 Gameplay State。

Session Resume Context

不需要 AI 寫小說式摘要。可直接從 structured state 產生:

Location: Old Mill Basement
Combat Round 6
Mira's Turn

Mira 8/32 HP · Concentrating
Borin Poisoned

Pending:
Opportunity Attack reaction

新的 AI Session 依 Server State 接手,不依賴舊 conversation。

尚未存在的 subsystem 不要輸出假資料;例如 P2 尚未有 Combat / Pending Roll 時,Resume 先顯示 Campaign、Session、Seats、Characters 等已存在 truth,後續再 additive 擴充。

Party Roster / Character / Seat

每個 Campaign 維持一份 Party / Character Roster,保存目前冒險中的 PC、暫時未參與 Session 的 PC、暫時離隊 PC、退休 PC、死亡但需保留歷史的 PC。

Roster 只能 reference 同一 Room 的 Character。Roster 不擁有 Character Build / Current State,也不建立 Campaign-specific Character copy。

角色不因為「今天沒有出席」就離開 Roster。Session 出席與 Character Campaign status 是兩件事。

第一版 Character Campaign Status:

active
inactive
retired
dead

不要因為玩家某場沒來,就自動把角色改成 inactive。

同一 Room 的 Character 可跨多 Campaign,但 State 共用

例如:

Room A
├─ Campaign 1 → Mira
└─ Campaign 2 → Mira

這是同一隻 Mira:同一 Build chain、同一 Current State、同一 Inventory、同一 HP / Prepared / Resources。

如果想要「同一起始角色進兩條不同世界線,各自受傷、拿不同裝備」,就先 Duplicate / Export+Import 成第二隻 Character identity,不建立 Campaign-specific CharacterState。

Session Active Character

每一個 Player Seat 在一場 Session 中預設對應一隻 Active Character:

Player Seat
→ Session Active Character
→ Controller

例如:

Seat 1
Character = Mira
Controller = Human

Seat 2
Character = Kael
Controller = AI

Seat 是本場桌上的操作位置;Character 是本場正在操作的角色;Controller 決定由 Human 或 AI 控制。三者不要混成同一個概念。

一個玩家可有多隻 Campaign Character

同一名實際玩家可以在同一 Campaign 中保留多隻角色,例如 Mira、Luna。某場選 Mira,下一場可換 Luna。

不需要刪除角色、搬移角色、建立新 Campaign 或正式 Ownership Transfer。

同一真人同場控制多隻角色

第一版不建立額外「一人多角模式」。如果同一真人要同場控制兩隻角色:

Human A
→ Seat 1 → Mira
→ Seat 2 → Luna

一個 Human Controller 可以同時控制多個 Player Seat;每個 Seat 仍只有一個 Active Character。不要讓單一 Seat 同時綁多隻角色。

Session Start 選角與 Late Join

Start Session 前,Player Seat 從 Campaign Roster 選本場 Active Character。

只有 status = activeinactive 的角色可以被選為 Session Active Character。

retireddead 不出現在選單中。如果 DM 真的要讓退休角色回鍋或死者復活,先把 status 改回 active,再選。系統不做「復活流程」,只是狀態改回來。

不要求所有 active PC 出席、所有 Seat 都有人、所有角色都在線。

同一 Character 不可同時出現在兩個 Active Session

因為 Current State 是 Character 本身唯一的一份 live state,所以:

Campaign A / Session active → Mira
Campaign B / Session active → Mira

不得同時成立,即使兩個 Campaign 都在同一 Room。

Server 必須在 Start Session / Late Join 時阻止第二場取得同一 Character;第一場 End / Abandon 後才釋放。

這不是 Ownership 規則,而是防止兩桌同時扣 HP、消耗 Spell Slot、改 Inventory 造成資料 race。

Session 中途不換角

Session 一旦開始,Player Seat 的 Active Character 固定,中途不可更換。

角色本場陣亡時,該 Seat 就空著或由 DM 安排敘事處理,新角色下一場再上。

想讓新角色本場就加入,用 Late Join 開一個新的 Player Seat,不是換掉既有 Seat 的角色。

Late Join:

  1. 加入 Player Seat。
  2. 從 Campaign Roster 指定本場 Character。
  3. Character 不得已被另一 active Session 使用。
  4. Exploration / Quick Combat 不要求 Spawn 流程。
  5. Tactical Combat 才需要放 Token。

敘事上角色怎麼出現由 DM 處理。

角色死亡、新角色與換角

角色死亡後:Character 保留、History 保留、Timeline / Session references 不破壞、status 可標 dead

玩家之後可建立新 Character、加入 Campaign Roster、下一場改用新角色。網站不做「死亡後自動建立替代角色」。

AI 接手哪隻角色

AI 接手永遠針對:

目前 Session
→ 某個 Player Seat
→ 該 Seat 的 Active Character

AI 不從 Campaign Roster 自己挑角色。Human Take Back 也回到同一個 Seat、同一 Character。Session 結束後不保留「AI 永久擁有這隻角色」的概念。

跨 Session 的 DM / Player / Character 安排

跨 Session 換 DM、換玩家、換角色,由朋友自己協調。

不需要:Transfer Ownership request、Accept Transfer、Approval chain、角色永久轉讓 UI、DM succession workflow。

新的 Session 可重新決定:

只要不違反「同一 Session 的 DM Controller 固定」即可。

如果某真人玩家永久離開,他的 Character 可以留在 Roster、變 inactive、變 retired、由另一真人使用、轉成 NPC、或完全不再出場。不需要正式 Ownership Transfer。

DM 中途離線

實體跑團 DM 突然消失,桌子就是停在那裡等他回來。網站照做。

第一版不做:

DM 斷線後:

Campaign 建立

第一版:

Create Campaign

Name
Ruleset = D&D 5e 2014
Adventure = optional(Adventure subsystem 存在後)

[Create]

不要要求:world history、starting town、main quest、party name、world map、start/end level、NPC list。

Campaign 可以完全沒有 Adventure;可先玩,之後再 Attach Adventure。Attach 代表增加可用資料,不覆蓋既有 Campaign Runtime。

P2 尚未有 Adventure subsystem 時,不需要為了 optional 欄位先造假的 Adventure identity;先完成 Name + Ruleset Campaign。

Campaign Level / Rules

Campaign 不固定 party level;不同等級角色可一起,網站最多提醒。

Campaign Rules 只做真正會改變 Rules Engine 的少數設定,例如:

Ruleset = D&D 5e 2014
Leveling = Milestone
Diagonal = 5/10 alternating

不要把所有 House Rule 都做成 Setting。

Session Resume / Reconnect UX

重新進入 Active Campaign / unfinished state 時先顯示 compact Resume Card,例如:

Old Mill Basement

Combat Round 6
Mira's Turn

Mira 8 / 32 HP
Concentrating

Borin
Poisoned

Pending:
Opportunity Attack Reaction

不要求 AI 先產小說式「上回提要」。核心資料直接從 structured state 顯示。

可提供 Recent Events,顯示最近幾個真正重要事件,但不是 mandatory recap workflow。

AI / Human reconnect 後直接重新取得目前可見 Current State;若有 Pending Roll、Reaction、Current Turn、Private Event,就恢復到正確 UI,不依賴舊 conversation memory。


四、主要 UI 與 Exploration

Homepage

Web:Room-first。

Enter Room
Create Room

可有 Recent Rooms。

Web 首頁沒有 global Character Workshop。要創角、看角色、匯入角色,先進某個 Room。

Standalone:Character-first。

Standalone
↓
Character Workshop

Standalone 不顯示 Enter Room / Create Room。

Room Workspace

Web 進 Room 後,第一版至少有:

Room
├─ Characters
└─ Campaigns

後續 Phase 再加入 Adventures / Maps / 其他 Room assets。

Characters 進入該 Room 專屬 Character Workshop,顯示該 Room 的 Drafts、Characters、Archived Characters,不顯示其他 Room資料。

Main UI

┌─────────────────────────────────────────────┐
│ Player Cards                                │
├──────────────────────────────┬──────────────┤
│         MAIN STAGE           │ Chat         │
│                              │ Dice         │
│                              │ Log          │
├──────────────────────────────┴──────────────┤
│ Quick Action Bar                            │
└─────────────────────────────────────────────┘

Main Stage 與右側 panel divider 可水平拖曳。Zoom / layout preference 可 localStorage。

Player Cards

最多約 6 張卡。6 指的是場上角色數,不是真人數——一個真人控制多個 Seat 時,每個 Seat 的角色各佔一張卡。

Compact 顯示:HP、Temp HP(有才顯示)、可選 AC、Condition icons、Combat Action / Bonus / Reaction。

點卡:Player → Character Sheet;DM → Quick Panel。

Character Sheet

已定案只有三頁:

1. 屬性 / 技能
2. 法術
3. 道具

Header 常駐:Name、Level、HP、AC、Conditions。

不再增加 Features、Biography 等獨立 tab。

第一頁包含:Ability Scores、Skills、Saves、Passive Perception、Hit Dice Available / Total(multiclass 依骰型分列)、Features / Traits、Conditions、Temporary Effects。Roleplay / Biography 放底部折疊。

Background Mechanical:Skills、Tools、Languages、Starting Equipment、Background Feature。

Roleplay optional:Alignment、Personality、Ideal、Bond、Flaw、Biography、Goals、Relationships、Roleplay Guidance。Alignment 不限制玩家行為。

Roleplay Guidance 對 AI Player 特別有用,例如:

Personality:
冷靜、好奇、不太信任權威

Speech Style:
話少,先觀察再回答

Goals:
找到失蹤老師

Relationships:
Kael — 信任,但覺得太衝動

完全 optional。

不做 Private Notes 系統

明確排除:玩家私人記事本、Wiki、Campaign 百科、NPC 關係圖、玩家 ToDo、自動整理筆記。玩家自己記。

但 DM Notes 要做。

DM Notes 是掛在既有 Entity 上的 dm-only 欄位(Scene、NPC、Monster、Item、Quest、Adventure section 等),不是獨立的記事本應用:

差別在於:DM Notes 是附著在世界資料上的秘密欄位,不是「給人打日記的地方」。不要因此長出獨立的筆記頁面、標籤系統或搜尋介面。

Exploration

Main Stage 是舞台展示,可:Image + Text、Image only、Text only。

Stage ≠ Chat。Stage 是目前世界畫面;Chat 是桌上人物說話。

Exploration Input 可用:Character、Action、Check、Whisper DM、OOC。

也保留 slash commands:

/action
/check
/search
/whisper
/ooc

Player 描述想做什麼;DM 決定需不需要 Check、用什麼 Skill、DC。

Exploration 不做 Point-and-Click

Interactable 可以顯示,例如:

Stone Door
[Use in Action]

但不要一點就出 10 個動詞。玩家直接說想做什麼。

Exploration 不追角色 Scene Position

Party narrative split 時,不建立 MMO-style:

Mira.current_scene
Kael.current_scene

DM 像面團一樣輪流處理。探索 map 可以 Show,但不做 grid exploration movement。

DM Toolbar

保持小:

Scene | Check | Combat | Map | Add | More

這些全是工具,不是必填工作流。

Exploration Check UX

Player 直接描述行動,例如「我仔細看看這扇門有沒有陷阱」。DM 判斷需要 Investigation Check 後,可在 Player Action 上按 Request Check,或從 DM Toolbar 的 Check 建 RollRequest。

Request Check 最低欄位:

DM 不需要先建立 Scene、Interactable、Trap entity 才能 Request Check。Check 是桌上工具,不是資料填寫流程。

Group Check:同一 RollGroup 下建立多個 RollRequest,UI 顯示已 Roll / Waiting / Result,最終 fiction result 仍由 DM 決定。

Secret Check:DC 與 dm-only 結果不送 Player,Server 直接過濾,不靠 UI 或 Prompt 保密。

Roll 完成後 DM 可直接敘事、套 state change,或使用高階 resolve_action()。不做固定 Success / Failure consequence template。

DM Quick Add UX

Add 打開小型 Quick Add Menu:NPC、Enemy、Item、Scene、Quest、Fact、Loot / Container、Other / Freeform。

採 Progressive Disclosure:先填最少資料就能用,其他之後補。

不要一點 Add 就打開大型後台。

Stage / Chat / Log / Timeline UX

Stage 是「現在世界正在呈現什麼」,可顯示 Scene image、Scene description、Combat view、Tactical map、Quick Combat situation。不是聊天紀錄。

Chat 用於 Character speech、Action text、OOC、Whisper DM。避免把大量機械事件塞滿 Chat。

DM Narration 可作為獨立 narration entry 顯示並同步成 Timeline 的 Narration event;不是每句 Narration 都改 Stage。

Log 顯示 compact mechanical / formal event,例如:

Mira hits Goblin #2 for 7 damage.
Kael moves 20 ft.
Borin fails CON save.

預設 compact,展開才看骰子、modifier、source、transaction detail。

Timeline 是跨 Session 可回查的 durable history。Secret event 必須在資料層直接過濾,不能先送到 Player 再靠 CSS 隱藏。


五、Character Workshop、Builder、版本與法術

Character Workshop

功能:Create、Manage、Level Up、Import / Export、Version History。

Web:Character Workshop 是 Room 內功能。

Enter Room
↓
Room Characters
↓
Character Workshop

Standalone:同一套 Character Core 保持 Room-less。 Windows portable zip 的 Character Workshop / Builder / Sheet / Level Up / Version History / Import / Export 直接使用本機 SQLite,不含 Room / Campaign / Session / Seat。

Character JSON

Character JSON 是 Character 自身交換格式,不是 Room package:

M03 出貨時 schema 為 unstableP2 起鎖成 Character JSON v1。P2 importer仍接受最後 M03 unstable格式並 normalize;從 v1 起新的 Adventure Table 版本必須持續能 import v1,後續變更不得任意改既有欄位語意。

Builder 首版

第一版就支援:D&D 5e 2014、Multiclass、Subclass、Level-by-level progression。

Built-in 內容先 SRD 5.1;非 SRD 內容用 user supplied / custom / imported content。

概念流程:

1. Basic
2. Race + Background
3. Class Build
4. Ability Scores + Skills
5. Equipment + Spells + Review

直接建高等角色,也等效跑 Lv1 → target level progression。

Character Level / Class Levels

分開保存:

character_level
class_levels

Proficiency Bonus 用總等級;Feature / Subclass / ASI 看職業等級。Multiclass progression 需保存加職順序。

Subclass

底層統一叫 subclass,不管官方名稱是 Martial Archetype / Arcane Tradition / Divine Domain。

Subclass timing 是 Structural Rule,不能 Override。

Builder Override

Override 只允許 numeric values。

可:STR、HP、AC、Speed、Numeric bonus。

不可用 Override 改:Subclass timing、Level dependency、Feature eligibility、Selection count、Structural prerequisite、Class progression。

例如 Lv1 Fighter 不能硬選 Lv3 subclass。

Numeric Override UI:

STR
Calculated: 18
Current: 19 ⚠

頁面可顯示 ⚠ 2 Non-standard values,點開看 calculated / current / override origin。

Structural Prerequisite

例如 Feat 需要 DEX13,DEX12 時不可選。即使 prerequisite 是數字,因為它控制 eligibility,仍屬 Structural Validation。

如果 DEX numeric override 成 13⚠,才可合法選。

ASI / Feat

ASI 依 class progression,不依 total character level。

ASI:

+2 one ability
or
+1 two abilities

Feat:enforce prerequisite;built-in SRD;架構支援 custom/imported。

Character Version / Level Up

Character Version = immutable Build Version。 它保存角色永久 Build 在某個時間點的完整 snapshot,不是整隻角色的 live save state,也不是 diff。

Build Version 包含例如:Class / Level progression、永久 Ability Scores、Skills / Saves proficiency、Features / Feats、Spellbook / Known / Always-prepared 等長期 Spell Access、Hit Dice 總數與骰型、Max HP 所需的 level-by-level HP progression、Starting Equipment build choice、Roleplay、Numeric Override、Custom Build data。

不放進 Character Version 的 live Current State:Current HP、Temp HP、Prepared Spells、目前 Spell Slots / Class Resources、Available Hit Dice、目前 Inventory / Currency / equipped / attuned 狀態、Conditions、Temporary Effects、Concentration、Death Save、Inspiration 等。

Level Up:

Current Build Version
↓
Level Up Draft
↓
Validate
↓
Confirm
↓
New immutable Build Version

Current State
↓
沿用到新 Build,必要的合法性/上限 reconciliation 由 Level Up workflow 處理

因此玩家今天重新準備法術、撿到一把劍、喝掉 Potion、換裝備、扣 HP,都不會建立新的 Character Version。

升錯不刪版本,標 superseded 並建立 corrected version。

第一版 Milestone,不做 XP。

Spell 核心

Spell Slot 是資源;Spell Access 是會不會/能不能準備;Prepared 是目前準備了什麼。三者分開。

每個施法職業有獨立 Spellcasting Profile。長期 Spell Access entry 至少知道:

spell_id
source_class
source_feature
access_type

Build 的 access_type 可表示 Known、Spellbook、Always Prepared / Granted 等長期取得方式;一般 prepared 不屬於 Build access type

Wizard:Spellbook 屬 Build;目前 Prepared selection 屬 Current State;冒險途中 Add to Spellbook 是 Build change,需走對應 Character Build workflow。

Cleric / Druid 類:可準備範圍依 class / level / feature 決定;目前 prepared_spells[] 屬 Current State。

Sorcerer / Bard / Ranger:Known Spells 主要在 Build / Level Up 改。

Always Prepared / Granted:

always_prepared = true
counts_against_prepared_limit = false

這種長期能力屬 Build,不需要玩家每天把它重新塞進 prepared selection。

Multiclass Slots 與各職業 Spell Access 分開。同 spell 可能不同 source,因此需知道用哪個 spellcasting ability。

Warlock Pact Magic 用獨立 SpellResourcePool,不把角色寫死只有一套 slots。

Build vs Current State

Build:Class、永久 resolved Ability Scores、Features、Feats、Spellbook / Known / Always-prepared 等長期 Spell Access、Hit Dice 總數與骰型、Max HP 所需的 level-by-level HP progression、Starting Equipment build choice、Roleplay、Numeric Override。

Current State:Current HP、Temporary HP、Current Slots / resources、Available Hit DicePrepared Spells、Concentration、Conditions、Temporary Effects、Death Save 進度、Inspiration、整份 live Inventory / Equipment / Currency / Consumables

Ability Scores 在 Build 中保存的是永久 Build 效果全部解析後、Numeric Override 前的 score。Race、ASI、Feat 等永久效果已反映在保存值中,Rules Engine 不可在每次 Character Sheet 計算時再重複套一次;Numeric Override 再從這個 Build Score 產生 effective score。

Starting Equipment 是 Build choice,但只用來建立角色最初的 live Inventory。之後撿到、丟掉、消耗、Equip / Unequip 物品都只改 Current State,不反向改 Starting Equipment,也不建立 Build Version。

Max HP 的 level-up 基礎結果必須可重建:每個 Character Level 實際採用的 base HP gain 屬 Build。系統資料表示要能承載 fixed value 或 rolled result;P0 標準 fixture 使用 fixed value 只是測試基準,不代表全產品只能 fixed HP。永久 CON modifier 改變時,Max HP 依規則對所有 Character Levels 重新反映;Numeric Override 最後套用。

Temporary HP

Temp HP 與 Current HP 分開保存,不是加在 HP 上。

行為依 5e 2014:

UI:Player Card 與 Character Sheet header 顯示為 24/32 (+5) 之類的形式,有 Temp HP 才顯示。

Hit Dice

Hit Dice 總數與骰型屬 Build(依各職業等級累加,multiclass 分別保存各職業的骰型);目前可用數量屬 Current State

Character Builder UX

Builder 採單一 Wizard + Summary。


六、Combat Engine、Quick Combat 與 Tactical Combat

Combat Modes

兩種:

Quick Combat
Tactical Combat

共用同一 Combat Engine。

第一版戰鬥開始後不可 Quick ↔ Tactical 中途切換。

Quick Combat

本質:Exploration UI + Combat State

不做 precise geometry。可用文字描述怪與位置,例如:

Goblin #1
北側樓梯,正在射箭。

Goblin #2
東側木箱後,和 Kael 近戰。

Boss
堵住南側出口。

Position note optional;真人 DM 可以全部口頭講。

Quick Combat 不做假座標/Zone System。

以下由 DM 判:Distance、Range edge cases、Cover、AoE affected targets、Opportunity Attack、movement feasibility。

網站處理:Initiative、Rolls、Damage、HP、Conditions、Concentration、Action / Bonus / Reaction、Death Saves、Resources。

Quick Combat 自動化、Turn 與敵人資訊

Quick Combat 的自動化邊界固定為:常見且可可靠結構化的戰鬥規則由 Server 處理;複雜、敘事型、罕見或依賴世界/空間判定的能力交給 DM。

Server 至少正式處理:Attack / Saving Throw、Damage / Healing、Critical、Advantage / Disadvantage、Action / Bonus Action / Reaction economy、Conditions、Concentration、Death Saves 與可明確消耗的 resources。特殊 Monster ability、複雜 Feat、敘事型 Spell 等可以 partial structured + description + DM adjudication;第一版不為此建立 generic rules DSL。

一般 Attack / Spell 在 target、roll 與必要裁定都已確定後,由 Server 直接完成 outcome → damage / healing / effect → state change;不要求每一擊都停下來給 DM 再按一次批准。 只有 Quick Combat 無法自行知道的 range、cover、AoE affected targets、Opportunity Attack trigger 或其他特殊判定,才等待 DM 裁定後繼續 resolve。

Turn / action economy 也是正式規則:一般 Action / Bonus Action 只在該 combatant 的 Current Turn 使用;Reaction 透過合法 ReactionRequest / reaction window 使用。DM 代理 Player Seat 時消耗的是該 subject combatant 自己的 action economy;Freeform Action 仍保留 DM 裁定彈性,不因為沒有專用按鈕就阻止特殊桌上處理。

敵人資訊依權限過濾:

Quick Combat 不追移動距離

Quick Combat 完全不追蹤移動距離,沒有 speed 預算、沒有剩餘移動力、沒有 used / remaining 顯示。

DashDisengage 在 Quick Combat 只是敘事宣告 + Action 經濟記帳

移動距離、速度預算、OA 幾何判定只存在於 Tactical Combat。

Tactical Combat

多出 precise spatial state:Grid、Token coordinates、Movement path、Distance、Range、AoE、Walls、Doors、Terrain、Automatic OA detection。

其他 Combat Engine 與 Quick 共用。

Tactical Token / Camera

Token:simple shapes、distinct colors;Boss outer border 只作視覺。

Map 支援 bounded zoom、pan、wheel / pinch、drag empty space、middle mouse、Fit Map、optional Center Party。

Zoom / pan 是 per-client UI state,不進 Campaign。

Movement

Plan
→ Confirm
→ Execute

Draft 不改 server true position。

Preview 顯示 Path、Used、Remaining、Warnings、OA warning。Confirm 才 commit。

Diagonal

使用 5/10 alternating:

orthogonal = 5 ft
diagonal = 5,10,5,10...

同一 Turn 內 diagonal count 不因 Attack 重置。支援 split movement、Dash。

OA / Reaction

Tactical:Committed path 離開 reach 時 Server 建 ReactionRequest,暫停 movement,處理後再續。

Quick:無 geometry,由 DM trigger。

Ready 使用同一 Reaction system。自由文字 trigger 由 DM 判,不做 scripting DSL。

Actions

第一版常見:Attack、Cast Spell、Dash、Disengage、Dodge、Search、Ready、Grapple、Shove、Freeform Action。

Movement 獨立。Extra Attack 支援 Attack → Move → Attack。

Attack / Spell

Tactical:

Action
→ Target
→ Preview
→ Confirm
→ Resolve

Ranged 可算 normal / long / out of range。Cover 第一版 DM 判。

Nat20 double damage dice,不 double modifier;Nat1 auto miss。支援 Advantage / Disadvantage。

AoE Tactical 可 preview cells/tokens;Quick 由 DM 指定 affected list。

Spell Skeleton

第一版支援:Spell Attack、Saving Throw、Auto Effect、AoE、Concentration、Upcasting。

Complex narrative spells → DM adjudication。

Concentration server tracked;新 concentration 結束舊的;damage 觸發 CON save;Combat End 不自動清。

Conditions / Effects

支援 2014 Conditions:Blinded、Charmed、Deafened、Frightened、Grappled、Incapacitated、Invisible、Paralyzed、Petrified、Poisoned、Prone、Restrained、Stunned、Unconscious、Exhaustion levels。

Conditions 有機械效果,不是 icon only。

Temporary Effects 另外處理:advantage/disadvantage、+N、AC、Speed、Attack、Save、Check、Damage。

Complex effect 可 partially structured + notes;不做 generic DSL。

Grapple / Shove

2014 規則。

Grapple:replace one attack;Athletics vs Athletics/Acrobatics;size/free-hand constraints;GrappleLink;dragging usually half speed;escape Action。

Shove:opposed;push 5 ft or Prone。

Hazard / cliff → DM。

0 HP / Death Saves

PC 0 HP:

HP=0
Unconscious
Prone

Death Save:10–19 success;2–9 failure;Nat20 → 1 HP;Nat1 → 2 failures;3 success → stable;3 failure → dead。

Healing >0:remove Unconscious,Prone remains。

Death Save 進度屬 Current State,在 End Combat 時清除

End Combat 時,0 HP 且仍 active 的 PC
→ Death Save 成功/失敗計數歸零
→ status = stable

角色仍是 0 HP、Unconscious、Prone,只是不再繼續擲 Death Save。後續恢復意識靠治療或 DM 裁定。

這是本專案刻意採用的預設,比 5e 2014 原文寬鬆(原規則需持續擲到 stable 或 dead)。理由:戰鬥結束後隊友本來就會去穩定傷者,不值得為此逼桌上多擲幾次骰。DM 想維持原規則時,自行不 End Combat 即可。

Monster 0 HP / Combat End

Monster HP0 不自動 Dead。DM 可決定 Dead、Unconscious、Surrendered、Other。

Combatant statuses 可簡化:

active
unconscious
stable
dead
surrendered
fled
withdrawn
removed

只有 DM 能 End Combat。即使沒有 hostile,也只提示,不自動結束。

End Combat 清:Initiative、Round、Current Turn、Action / Bonus / Reaction、Movement bookkeeping、Surprise、Ready Action、Death Save 計數(0 HP 者轉 stable)、combat-only temp bookkeeping。

保留:HP、Temp HP、Slots / resources、Available Hit Dice、Persistent conditions、Concentration、Inventory、Death state、Monster/NPC outcomes、Map / World State。

不做 Victory Screen。

Initiative / Combat Start

Initiative:d20 + DEX,用 RollGroup + RollRequest。

支援 monster group initiative、ties、surprise、mid-combat entrant。

Combat Start:

Start Combat
→ Quick / Tactical
→ Party auto include
→ Add enemies
→ Tactical map/place
→ Surprise if needed
→ Initiative

不要求 EncounterTemplate。

Tactical Map 建立

目標:30 秒內開一張能打的地圖。

選:Blank Grid、Existing Battle Map、Upload Image。Blank Grid 是一等公民。

上傳 Image 只需簡單 grid size / offset,不要求 DPI/PPI。

第一版 semantic map:Wall、Door、Terrain、Token、Free Drawing。

Color 純 visual,不代表 semantic。

Hidden / Fog

支援簡單 hidden token / hidden door + Reveal。

第一版不做 Fog of War、Dynamic Lighting、Vision Radius、Darkvision rendering、Vision cones、LOS polygons、Elevation、3D。

Quick Combat UX

Quick Combat Main Stage 顯示:Combat Header(Round / Current Turn)、Initiative List、Combatants(Name / Conditions / Action / Bonus / Reaction / optional Position Note;HP 與其他數值依前述權限規則顯示)、Main Situation / Description、Quick Action Bar。

Position Note 完全 optional。

Player 選 Action,若需要 Target 就選 Target;涉及 Quick Combat 無法自動判定的空間問題,等待 DM 裁定。

Quick Combat 不顯示假精準資訊,例如「距離 27 ft」「Cover 1/2」「AoE 自動命中 3 人」,除非 DM 明確輸入/指定。

DM 可以直接裁定:In range、Out of range、Advantage、Disadvantage、affected targets、OA triggers,再由 Server resolve。

AoE 例如 Fireball:

Cast Spell
→ DM / acting user 選 affected targets
→ Saving Throw RollGroup
→ Damage
→ Resolve

不建立假的 AoE geometry。

Tactical Map Editor UX

Toolbar 第一版:Select、Wall、Door、Terrain、Token、Draw、Erase、Undo、Fit Map。

Blank Grid 只需 Width、Height、Grid Size / Cell Size。

Upload Image:顯示 grid overlay → 調 grid size → 調 X/Y offset → Confirm。

Wall:click start → click end,或連續畫線;Wall 是 semantic object,blocks movement。

Door 放在線段/格線位置,快速切 Open / Closed / Locked / Broken;Hidden door 由 DM visibility 控制。

Terrain 用 brush / cell paint:Normal / Difficult / Blocked。

Token 可 Drag、Select、Place、Hide / Reveal、Assign Character / Monster Instance。正式 Combat movement 仍走 Plan → Confirm → Execute;DM 佈置移動與 Player Turn movement 要區分。

Free Drawing 純視覺,可畫圈、箭頭、註記,不影響 Rules Engine。


七、Adventure、Campaign Runtime 與 AI DM 世界維護

Adventure

Adventure 是起始世界模板,不是 script。

可包含:Sections、Scenes、NPCs、Monster refs、Items、Secrets、DM Notes、Suggested Checks、Maps。

Adventure Importer

來源:TXT、Markdown、pasted text、PDF、DOCX、URL(可存取時)。

流程:

Source
→ AI Parse
→ Draft
→ Review
→ Confirm
→ Adventure Definition

AI parse 不直接正式化。

AI Parse 由外部 AI 執行

網站不接 LLM API,後端沒有模型可以呼叫。

AI Parse 這一步由使用者的外部 AI Session 透過 Importer MCP 完成:使用者在自己的 ChatGPT / Claude / Codex 裡讓 AI 讀取 source,再由 AI 呼叫 import_adventure_source() / update_import_draft() 把 Draft 寫回網站。

因此:

同一原則適用於全站:AI DM、AI Player、Character Builder 協助、resolve_action() 的敘事,全部由外部 AI Session 發起。網站永遠是被呼叫的一方。

Import Review / Interview

不確定要標出,不亂補。

例如原文沒寫 DC:

Resolution: DM decides
⚠ No explicit DC

缺真正必要資料才問。

可標 provenance:

source_document
user_explicit
user_approximation
ai_generated

保留 Source Reference / page / section。

Adventure Import MCP

Adventure Importer 同樣暴露 MCP,例如:

import_adventure_source()
get_import_draft()
resolve_import_warning()
answer_import_question()
update_import_draft()
finalize_adventure()

Character Builder / Level Up 也要 MCP。Human UI 與 AI MCP 共用 backend logic。

Adventure Definition vs Campaign Runtime

Adventure Definition
= 原始模板
= 不修改

Campaign Runtime
= 這一團實際玩出的世界
= 可新增 / 改變

例如 Adventure:Innkeeper Neutral;Campaign:Innkeeper Hostile。不要改 Adventure 本體。

Campaign Runtime Additions

可新增:Runtime Scenes、Runtime NPCs、Runtime Items、Runtime Quests、Runtime Secrets、World Facts、Adventure State Overrides。

AI / Human DM 即興出的內容,重要時可正式寫入 Campaign。

Campaign Fact

用於沒有必要建立完整 Entity、但未來要記住的事,例如:

The north bridge collapsed.
The mayor believes Mira is a royal investigator.
The party promised Elara protection.

不要把每個小動作都存 Fact。

AI DM 必須能寫回世界

AI 不能只 narrate。

如果說「門被撞壞」要更新 Door state;說「找到銀鑰匙」要建立/移轉 Item;即興的新 NPC / Scene / Fact 後續重要時要持久化。

AI Context

不要整本 Adventure 塞進 context。

常駐小 Context:Campaign、Current Scene、Current Party、Current Situation、Pending Events、Active Combat。

Scene Context:NPCs、Secrets、Interactables、Hazards、Relevant Notes。

按需:NPC roleplay context、source excerpt、old timeline、quest history、monster details。

AI Context 不是 truth;Server Current State 才是 truth。

Attach Adventure 衝突

當 Campaign 已有 Runtime content,後來再 Attach Adventure:

不做自動 entity matching、自動判斷同名 NPC 是否同一人、自動合併 Scene、自動覆蓋 Campaign Runtime、Conflict Resolution Wizard、大型三方 merge UI。

第一版假設使用者自己處理命名與內容衝突。若 Campaign 與 Adventure 都有 Mayor Elara,系統不用猜是否同一人;可以先作為不同資料存在。

若 DM 認為是同一人,可自己修改、移除多餘項目、調整 Runtime,或未來再增加簡單 linking 工具。

Attach Adventure 只是增加可使用的 Adventure Definition;Campaign Runtime 仍是這團世界的真實狀態。

AI DM Write-back Policy

AI DM 不得只講故事,也不能把每句敘事都結構化保存。第一版分三層:

A. Ephemeral Narration:只影響氣氛、不需未來記住,例如酒保皺眉、雨聲變大、房間有霉味。不建立 Campaign Entity / Fact。

B. Session-Relevant State:這場可能繼續使用,但未必值得成為長期世界資料,例如門暫時被桌子堵住、NPC 本場躲樓上、臨時敵人的位置描述。依資料類型寫入 Current State。

C. Campaign-Persistent State:明確改變世界且之後合理需要記得,例如門永久撞壞、北橋倒塌、玩家取得銀鑰匙、NPC 死亡/離城、新 NPC 成為長期角色、Party 做出重要承諾、Adventure 原始狀態被玩家改變。應更新 Entity state、Item ownership、World Fact、Runtime NPC / Scene、Adventure State Override 等。

避免過度保存:不要每句話建 Fact、每個路人建完整 NPC、每次描述建 Scene、每個小物件建 Item Entity。

needs_review=true 只用於影響很大、有歧義、來源互相矛盾、或可能需要 DM 確認的變化;不要每次 write-back 都卡 DM Review。

Adventure Importer Review UX

Review 採「左來源、右 Draft」或等效雙區設計。

Source:原文、page / section、source excerpt。

Draft:Parsed Scene、NPC、Monster、Item、Secret、Suggested Check、Notes、Warning。

Warning 分級:

原文沒寫的規則資訊不要假裝來源有寫。例如「門很難撬開」但沒 DC,就顯示 Suggested Resolution: DM decides + No explicit DC in source,不要默默存成 DC 15。

每個 parsed section 可 Accept、Edit、Ignore、Mark uncertain、View source、Answer question;不要求逐項按 Accept 才能完成整份 Import,應允許「大部分沒問題,只處理 warnings」。

Finalize 後建立 Adventure Definition,並保留 provenance、source reference、warning / approximation origin。


八、NPC、Monster、Scene、Knowledge 與 Roll System

NPC

NPC 是世界/RP Entity。可只有:Name、Role、Personality、Motivation、Knowledge、Important Memories、Attitude。Combat profile optional。

Monster

Monster Template 是戰鬥模板。

核心:Name / Size / Type、AC、HP、Speed、Ability Scores。

Optional:Saves、Skills、Resistances、Immunities、Condition Immunities、Senses、Languages、CR。

Combat:Traits、Actions、Bonus Actions、Reactions、Multiattack、Save Actions、Recharge、Spellcasting、Lightweight Legendary Actions。

複雜能力保留 description + DM adjudication。

Monster Instance / Quick Enemy

Instance 保存:current HP、initiative、conditions、effects、position / position note、reaction、recharge/resources、visibility、status。

Quick Enemy 只填:

Name
AC
HP
Speed

就能上場。需要攻擊時再加:

Club +4, 1d6+2

可之後 Save as Template。

NPC / Monster / Combatant

不把 NPC 和 Monster 完全合併:

NPC = world/RP
Monster Template = combat template
Monster Instance = encounter state
Combatant = Combat Engine common interface

NPC 突然被打:Use Quick Stats / Choose Template。

Monster 變長期角色:Promote to NPC。

Roll System

核心:

RollGroup
RollRequest

AI 不自己捏正式骰子結果,Server roll。

Visibility:

public
roller+DM
dm-only

Formal physical dice input 要記 raw die,不只 total。

Quick Dice 不完成 formal pending request。

PendingAction / ActionWindow

Normal chat 即時。

Formal action 可建 PendingAction:

pending
processing
waiting_for_roll
resolved
cancelled

Exploration 不依 arrival timestamp 決定 fiction order,由 DM 排。

ActionWindow 可在「大家現在要做什麼?」時使用,但不是 exploration turn system。

Scene / Hazard / Knowledge

Scene 可只有 Name + Description,其他 optional。

SceneDefinition 是 Adventure;SceneState 是 Campaign mutable。

Hazard / Trap 可有 trigger、visibility、area、state;Tactical hidden trap 在 committed movement 才觸發,不在 draft preview 觸發。

Knowledge 分:DM、Character、Public。

真正秘密才建 KnowledgeFact,不把每句話都轉 Fact。

DM → Player Whisper 要有;Player ↔ Player private 可延後。

NPC / Monster Quick Creation UX

Quick NPC 最低只需要 Name;可選 Role、Short Description。Personality、Motivation、Knowledge、Memories、Attitude、Combat profile 都之後補。

NPC 突然進 Combat:Use Quick Stats 或 Choose Monster Template,不要求所有 NPC 一開始就有 Combat Stat Block。

Quick Enemy 最低只需 Name、AC、HP、Speed。需要攻擊時再 Add Attack:Name、Attack Bonus、Damage。

臨時 Enemy 之後若會重複使用,可 Save as Monster Template;Instance current state 與 Template 分開。

怪物變成故事角色時可 Promote to NPC,保留需要的 reference / history,但不把 NPC / Monster Template 底層完全合併。


九、Timeline、GameTransaction、還原與 Snapshot

Session Timeline

Timeline 是真正可能需要回看的遊戲事件。

要記:Session Start/End、Dialogue、Narration、Formal Player Actions、Rolls / Checks、Combat、Movement、Attack、Damage / Healing、Spell、Condition、Item、Quest、Important World Change、Scene Change、Rest。

不記:hover、tab switch、character sheet open、zoom/pan、draft drag、AI read tools、getter calls、debug logs。

Timeline Privacy / UI

Secret Event 必須在 Timeline 層就做 visibility filtering。

Chat Message 與 Session Event 不完全相同。

右側 Log 顯示 compact summary,例如:

Mira hits Goblin #2 for 7 damage.

展開才看細節。

AI 可:

get_recent_timeline()
search_campaign_history()

不要一次讀全部 Session 歷史。

GameTransaction / Resolve

正式 action 以 transaction 包:Attack、Spell、Item Use、Movement Commit、Check、Rest、DM Edit、Quest、World Change。

AI DM 可用高階 resolve_action() 同時完成 narration、state changes、optional runtime content、optional persistent facts、timeline,避免只講故事忘記更新 state。

還原:用 DM Direct Edit,不做 Undo 機制

第一版不做 Undo Transaction。 點錯了就由 Human DM 直接改回來。

理由:實體跑團本來就是這樣處理的——算錯傷害就把血加回去,不會有人去回捲時間軸。做一套 Revert Transaction 機制要求每個寫入路徑都可逆,成本遠高於它解決的問題。

DM Direct Edit 可還原的範圍就是 DM 本來就能改的資料:

也就是:已經扣掉的血可以加回來,已經用掉的法術位、道具、行動可以改回來。

Player Draft(移動草稿、未 Confirm 的 action)仍可 Cancel,那不是 Undo,只是還沒送出。

DM Direct Edit 本身就是一筆記錄在 Timeline 的正式改動,不會偷偷改掉歷史。

AI DM 主持時不可還原

AI DM 的 Session 沒有還原功能。 場上沒有 Human DM,所以沒有人有還原權限——旁邊的真人玩家也沒有。

AI DM 判錯或算錯時,就當作桌上真的發生了,繼續往下跑;真的無法接受,就結束 Session 由 Human DM 重開。

這是刻意的簡化:AI DM 的 write-back 可能一次改動多處,開放還原會需要一整套追蹤機制,不值得。

Snapshot

Snapshot 保留,因為它只是整包存檔,不要求寫入路徑可逆。

Automatic:Session Start、Scene Change、Combat Start、Combat End、Session End。

Manual:DM Save Point。

Restore 後 Active State 回到該存檔點,後續 history 保留為 archived,不刪除。UI 不做 Git 式分支操作。

Restore 是「整場退回某個時點」的重手段,跟上面的 DM Direct Edit 是兩種不同尺度的修正工具:小錯改資料,大錯回存檔。

P2 只建立 Session Start / End 的 lifecycle boundary與未來 Snapshot hook;真正 Snapshot payload / Restore 仍在對應 Snapshot Phase 實作,不提前做半套。


十、Inventory、Loot、Shop、Quest、Rest 與 Campaign Changes

Inventory / Loot

Inventory 類:Equipment、Consumables、Quest / Misc、Currency。

角色目前的整份 Inventory 是 Current State。 Build 只保留 Starting Equipment 的創角/Build 選擇作為初始 Inventory 的來源;初始化後,撿到、失去、轉移、消耗、Equip / Unequip Item 都只改 live Inventory State,不建立 Character Version。

列表即可,不做背包拼圖。Weight optional,不強制 Encumbrance。

Loot 可重用 ItemContainer:Corpse、Chest、Ground、Table、Hidden Cache。

不做戰後 Auto Loot / Victory Screen。

Combat Equipment ≠ Loot

Monster stat block 有 Sword / Bow,不代表死後自動產 Item。玩家真的要拿,才 Create Item from Equipment,避免垃圾 Inventory。

Loot 操作

DM optional:Add Loot、Reveal、Hide、Identify。

Player:Take、Give、Drop、Use、Equip。

Currency:Take、Party Fund、Split。

未鑑定 Item 可只顯示外觀名稱。

Shop

不做 economy simulation。

核心:

Quick Buy
Quick Sell

DM 報價,Server 處理 money + item transaction。

Optional Shop Listing 只是方便清單。Stock 預設 unlimited / unspecified,只有特殊情況才追數量。

不做 dynamic economy、merchant wallet、restock、reputation price、bargain minigame。

Quest / Journal

很輕,完全 optional:

title
description
status
visibility
optional objectives
optional related NPC/Scene
optional DM notes

狀態:inactive、active、completed、failed、abandoned。

不做 progress %、自動 completion、reward engine、MMORPG Quest UI。

Campaign 可以跑 20 Sessions 而 Quest records = 0。

Rest

Short Rest:DM starts / approves;Player spend Hit Dice;recover short-rest resources。

Long Rest:DM starts;optional 4 watches;can interrupt;DM decides completion;recover resources。

Long Rest Watches

固定四班:

Watch 1
Watch 2
Watch 3
Watch 4

每班 watchers[]。一般 PC watch_capacity=1;特殊 race/feature 可 watch_capacity=2;NPC 可值班;同班可多人。

可直接:

Uneventful Night / Skip Watches

守夜不是 mandatory minigame。

Campaign Clock

可以有 day/time,但 optional。沒有 Campaign Clock 也能 Rest。敘事時間由 DM 決定。

Inspiration / Temporary Modifiers

2014 Inspiration:boolean。DM grant,Player spend → Advantage。

One-roll modifier:Advantage、Disadvantage、+N。

持久效果走 Temporary Effect。

Campaign Changes

可有簡單 DM View:Campaign Changes

看 Runtime NPCs、Runtime Scenes、Runtime Quests、Important items、World Facts、Adventure State changes。

不是 Wiki。AI 可標 needs_review=true,但不要所有變化都要求 DM review。

Inventory / Equipment Automation

只自動化最常用、明確、能省掉大量手算的部分,不把 Inventory 做成完整 CRPG 裝備模擬器。

Item 可有 equipped = true / false;必要時有 equipped slot / usage、attuned、quantity。

已裝備 Weapon 可直接產生 Attack option:Attack Bonus、Damage Dice、Damage Type、Range、Properties。

Armor / Shield 可參與 calculated AC;若角色有 Numeric Override,顯示 calculated / current 差異,不偷偷覆蓋 override。

Potion、Scroll、Ammo 等若有 quantity,正式 Use 時可扣 quantity;但不是所有故事物品都強迫追數量。

Ammunition 可追 quantity,但不因為沒填箭數就禁止所有 ranged attack。只有 Ammo item 明確啟用 tracking 時自動扣數量。

可保存 attuned state;第一版可做 warning,不需要大型 attunement management system。

常見明確 Item Effects 可結構化;複雜魔法物品用 description + partial structured effect + DM adjudication,不做 generic effect scripting DSL。

Rest UX

Short Rest:DM Start;Player Card 顯示 Current HP、Hit Dice Available;玩家可 Spend Hit Die;Server roll Hit Die + CON modifier並更新 HP;完成後恢復 short-rest resources。

沒有人要花 Hit Dice 時,DM 可以直接完成 Short Rest,不因某個人沒按 Ready 卡住。

Long Rest:DM Start;顯示 Party、Optional Watches、Rest status。

Watches 預設四班,DM 可拖/點角色加入;也可直接 Uneventful Night / Skip Watches

Long Rest 被中斷時,進入 Exploration 或 Combat;事件處理後 DM 決定 Continue Rest、Restart Rest、Abandon Rest、或在規則與敘事允許時 Complete。Server 不自動判 fiction。

Complete Long Rest 前可顯示 Recovery Preview:HP、Spell Slots、Hit Dice、Class Resources 等;DM Confirm 後才 commit。


十一、資料生命週期與 Export / Import

資料生命週期

原則:被歷史引用的資料優先 Archive,不 Delete;Room Hard Delete 是 Owner 對整個 workspace 的明確 destructive exception。

Campaign:Draft 且未跑過可 Delete;有 Session history → completed / archived,不 hard delete破壞 reference。

Adventure:Import Draft 可 Delete;未引用 finalized 可 Delete/Archive;已被 Campaign 用 → Archive。

Character:

Session:不正常 Delete;誤開/無法繼續 → abandoned。

Room:Owner 可 Hard Delete,需強確認;會永久刪除整個 Room workspace與其 Characters / Drafts / Campaign history / assets。MVP 不做 recycle bin。

Export

Character:JSON;Character exchange格式是 Room-neutral。

Character Sheet:HTML;單向、只給人看的呈現輸出,永遠不可 Import。它不是第二種序列化格式,機器往返一律走 Character JSON。使用者自選兩種範圍:

角色配置(Build only)  — 不隨遊戲變動的部分
當前快照(Current copy)— 加上這一刻的 Current State

角色配置不輸出目前 HP、剩餘 Hit Dice/法術位/職業資源、狀態、已準備標記與物品欄;上限與總量照常輸出。當前快照兩者都輸出。輸出檔自足、離線可開、可列印,內容只包含請求者本來就看得到的資料。

Adventure:structured package;不含 Campaign runtime;original source files optional。

Campaign:完整 portable package,包括 Characters、Adventure、Runtime World、Sessions、Timeline、Snapshots、Assets。

Room:完整備份。

不 Export:Room Password、Owner Key、DM Key、AI Tokens、API credentials、current web sessions。

Character 跨 Room

不共享同一 Character identity:

Room A Character
→ Character Export
→ Room B Import
→ New Character ID

兩邊之後各自有自己的 Build Version / Current State。

Import

一定先 Preview。

Package 帶:

schema_version
ruleset
export_type

Importer 做 ID remapping。

第一版不做 Merge:

Import → New copy

Web Character Import一定在 target Room context執行;Standalone Character Import直接進本機 Character Workshop。

P2 Character JSON v1 lock時,仍接受 M03 unstable legacy Character export;normalize後正式落地,再次 export時輸出 v1。

Owner-scoped MCP 才可做管理型 Campaign / Room Import/Export。


十二、第一版明確不做


十三、文件維護、後續設計與討論規則

技術討論方式

技術部分由實作者/Assistant 自己設計,不需要逐項討論,例如:

只把真正影響跑團體驗、產品行為、UI/UX、規則選擇,而且尚未定案的問題拿回來討論。

後續討論原則

每次提出下一題前先確認:

  1. 是否真的還沒討論過?
  2. 是否影響實際跑團?
  3. 若只是技術細節,直接自行決定。
  4. 若只是輔助功能,不要變 mandatory workflow。
  5. 是否開始包山包海?如果是,優先砍掉。
  6. 每次只討論一個主題。

可直接定第一版的範圍

以下內容後續不需要逐項詢問使用者:

直接先做合理第一版。

什麼情況才需要再問

只有當問題符合以下條件時才拿出來討論:

  1. A / B 選擇會明顯改變實際跑團方式。
  2. 會影響 DM 或 Player 的核心權利/責任。
  3. 會改變既有規則玩法。
  4. 會造成很難逆轉的產品方向。
  5. 從本文件既有規格無法合理推導。

純技術或一般 UX 問題不要逐條開會。

預設設計原則

遇到未明確寫出的細節時,優先遵守:

目前待決事項

目前沒有需要在本檔中保留的已知重大待決產品題目。

已定案並收錄的項目包括:原 handoff 的 Party Roster / Character 加入退出;2026-08-29 增補的 AI DM Build 修改限制、玩家自行扣 HP、DM 代理 Seat、Session 選角與中途不換角、DM 中途離線、Temporary HP、Hit Dice、Quick Combat 不追移動、Death Save 於 End Combat 清除、不接 LLM API、介面語言、DM Notes 保留;2026-09-06 拍板的 Web Room-first Character Workspace、Draft 同樣 Room-scoped、Standalone 保持 Room-less、同 Character 不跨 Room共享、同 Room多 Campaign共用同一 Character State、同 Character不可同時進兩個 active Session、Character JSON P2 起鎖 v1;以及 2026-09-13 拍板的 Quick Combat 核心自動化邊界、一般命中直接 resolve、不逐擊等待 DM 批准、Turn / Reaction economy、敵人精確 HP / AC / hidden resources 對 Player 隔離

後續若實作時遇到缺口:


十四、開發接手原則

交給新的 ChatGPT / Claude / Codex Session 或實作者時,遵守:

  1. 不重新討論本檔已定案項目。
  2. 不把產品擴張成包山包海的 VTT。
  3. 真人 DM 必須能像實體跑團一樣,很多事情只靠口頭描述,不需要填資料。
  4. AI DM / AI Player 透過 MCP / Site Tools 使用同一個 Server Game State。
  5. 技術細節自行設計,不逐項回問。
  6. 只有真正影響跑團體驗、UI/UX、產品行為,而且本檔無法推導的重大問題才回來討論。
  7. 首發規則為 D&D 5e 2014;Built-in Content 先 SRD 5.1。
  8. 新提議若與本檔衝突,先指出衝突,不得默默推翻既有規格。
  9. Optional 輔助功能不得變成 mandatory workflow。
  10. 實作若發現規格有洞,先判斷是否能依既有原則自行補齊;只有重大產品分歧才回來詢問。