№ · 完成设计 CH.06.21
主页 · ✅ 完成设计 · 同福擂台赛 / 比武招亲设计文档

同福擂台赛 / 比武招亲设计文档

📅 2026-06-21 · 📦 10.1 KB · ✅ 完成设计 · 📝 MD 文档 🏷️ 时间🏷️ 设计🏷️ 会话🏷️ 联机

目标：把 App v1.5.0 的“比武招亲”随机事件系列，升级为可长期扩展的“同福擂台赛”系统。后续开发必须按子会话拆分推进，避免一次性把事件、UI、存档、联机全部揉在一起。

设计定位

“同福擂台赛”是活动系统名，“比武招亲”是首个活动主题。它不是完整格斗玩法，而是把客栈门口搭擂、围观客流、江湖名声和店内秩序压进经营主循环里，让玩家在热度、秩序、收益、名声之间做取舍。

系统应保持三个边界：

  • 轻量活动：由时间和事件驱动，复用随机事件弹窗与总览页，不在第一版新增复杂战斗页面。
  • 经营调度：玩家关注谁来镇场、是否收报名费、是否报官、是否转成客栈庆典，而不是逐招操作。
  • 长期扩展：TournamentState 只保存主题、阶段和核心指标，为后续角色分支、资源消耗、联机助阵预留空间。

setup -> qualifier -> final -> cooldown 玩家循环

setup：触发与筹备

  • 白天或傍晚更容易触发“门口红绸”“江湖客围观”等事件。
  • 高声望提高报名和围观概率，低治安提高闹事、踢馆、旧账上门概率。
  • 玩家选择是否正式挂擂、收报名费、请捕快维持秩序、准备茶水熟食。
  • 筹备结果决定初始热度、秩序压力和第一笔收益。

qualifier：初擂与筛选

  • 围观人群形成，江湖客、书生、厨艺挑战者、熟客开始报名。
  • 玩家选择一名店员或一种客栈策略应对。
  • 郭芙蓉偏武力镇场，白展堂偏暗中化解，李大嘴偏厨艺热闹，吕秀才偏文斗口碑。
  • 阶段结果会推进 roundsCompleted，并把角色焦点写入 featuredStaffId。

final：决擂与收束

  • 根据前序热度、秩序和角色倾向，出现正向或风险事件。
  • 玩家选择公开扬名、低调收场、报官维稳或转化成经营庆典。
  • 公开决擂给高名声和高热度，但会继续压低秩序；官府见证更稳，但收益较低。

cooldown：余波与冷却

  • 发放铜钱、名声、清洁、治安，以及后续版本可能加入的熟食、柴水、银票。
  • 记录短期状态，例如“擂台余热”“门口混乱”“江湖关注”。
  • 冷却期内降低再次触发概率，避免玩家连续被同一活动打断。
  • 冷却结束后回到 idle，等待下一次主题活动触发。

TournamentState 建议结构

第一版复杂擂台赛建议新增一个可选存档字段：

export type TournamentTheme = 'martial_matchmaking';
export type TournamentStage = 'idle' | 'setup' | 'qualifier' | 'final' | 'cooldown';

export interface TournamentState {
  theme: TournamentTheme;
  stage: TournamentStage;
  dayStarted: number;
  heat: number; // 0-100，越高越能带来客流和名声
  order: number; // 0-100，越低越容易闹事
  featuredStaffId?: StaffId;
  roundsCompleted: number;
}

存档兼容要求

  • 字段必须是 gameState.tournament?: TournamentState，旧存档缺省时自动补 idle。
  • 默认值必须稳定：theme: 'martial_matchmaking'、stage: 'idle'、heat: 0、order: 100、roundsCompleted: 0。
  • 读档补齐逻辑必须容忍旧存档缺少 theme、stage、heat、order、roundsCompleted 中任意字段。
  • 如果只做随机事件增强，不写入长期状态，则不提升 SAVE_SCHEMA_VERSION。
  • 一旦引入 TournamentState 并持久化，必须提升 SAVE_SCHEMA_VERSION 并在 docs/version-history.md 写明默认值。
  • 新字段不能让旧存档进入非 idle 阶段；旧玩家第一次读档只能看到“尚未开擂”的默认状态。

指标含义

擂台热度 heat

  • 来源：声望、宣传、围观、公开接招、厨艺擂、文斗。
  • 正面：提高客流、铜钱、名声、特殊客人出现概率。
  • 负面：提高混乱、盗贼、旧账上门概率。

擂台秩序 order

  • 来源：治安、捕快巡场、白展堂暗中处理、郭芙蓉镇场。
  • 高秩序：降低闹事和清洁损失。
  • 低秩序：触发踢馆、打坏桌椅、门口拥堵等事件。

角色焦点 featuredStaffId

  • guo：武力守擂，强治安，风险是清洁和名声波动。
  • bai：江湖旧账，强控场，风险是引来暗线。
  • li：厨艺热闹，强收益，风险是后厨和清洁压力。
  • lu：文斗口碑，强名声，风险是收益较低、耗时较长。
  • tong：掌柜调度，均衡路线，风险较小但爆发收益低。

事件节点

setup：挂红绸

  • 触发文案：门口红绸被误会成招亲擂。
  • 选项：
    • 正式挂擂：热度上升，秩序下降。
    • 澄清误会：热度小升，秩序上升。
    • 收报名费：铜钱上升，名声下降，秩序下降。

qualifier：初擂报名

  • 触发文案：江湖客、书生、厨艺挑战者、熟客围到门口。
  • 选项：
    • 郭芙蓉守擂：治安上升，清洁下降。
    • 李大嘴办厨艺擂：铜钱上升，清洁下降。
    • 吕秀才办文斗：名声上升，铜钱小升。
    • 白展堂暗中筛人：秩序上升，热度下降。

final：决擂收束

  • 触发文案：围观人群达到顶峰，必须决定怎么收场。
  • 选项：
    • 公开决擂：热度与名声大升，秩序承压。
    • 官府见证：秩序大升，收益下降。
    • 转为客栈庆典：消耗熟食，获得铜钱和名声。
    • 低调散场：风险最低，奖励最低。

cooldown：余波

  • 正向余波：客流提高、稀有客人概率提高、同福口碑提升。
  • 负向余波：门口拥堵、清洁下降、盗贼概率提高、江湖旧账来访。

UI 方案

第一版不做新大页面，优先复用现有系统：

  • 总览页增加一块“擂台状态”小卡。
  • 随机事件弹窗继续承载阶段选择。
  • 日志输出阶段变化，例如“比武招亲进入初擂”。
  • 如果进入 setup/qualifier/final，右侧总览展示热度和秩序条。

后续版本再考虑独立页：

  • 擂台横幅
  • 报名名单
  • 店员助阵选择
  • 阶段奖励预览

版本拆分

当前实现状态

  • App v1.6.0 已完成最小闭环：TournamentState、旧存档默认值、阶段事件链、总览状态卡和本地构建验收。
  • App v1.7.0 已完成角色与资源深化基础：店员等级影响擂台结果，事件效果支持柴、水、熟食、关中银票、山寨赃物，初擂加入镖师和旧友路线，冷却余波影响客流、稀客和盗贼概率。
  • App v1.8.0 已完成联机助阵与活动化：好友可派店员助阵，赶集日/夜市日会影响开擂概率与初始压力，擂台结清可生成可分享战报。
  • 这版仍保留的后续工作只剩内容细化和表现打磨，不再把 v1.8 当作未完成主线。

App v1.6.0：复杂擂台赛最小闭环

目标：做出 setup -> qualifier -> final -> cooldown 的单条链路。

范围：

  • 新增 TournamentState。
  • 新增状态推进工具函数。
  • 总览页显示热度、秩序、阶段。
  • 复用随机事件弹窗推进阶段。
  • 首批只支持“比武招亲”主题。

验收：

  • 旧存档能自动补默认擂台状态。
  • 玩家能从随机事件进入擂台链路。
  • 至少能完成一次完整擂台并进入冷却。
  • npm run lint、npm run build 通过。

App v1.7.0：角色与资源深化

目标：让不同角色路线产生更强差异。

范围：

  • 店员等级影响擂台结果。
  • 事件效果扩展到柴、水、熟食、银票。
  • 加入更多参赛者类型：江湖客、书生、厨师、镖师、旧友。
  • 冷却余波影响当天客流和盗贼概率。

验收：

  • 郭芙蓉、李大嘴、白展堂、吕秀才至少各有 1 条专属分支。
  • 资源消耗在 UI 中可预期，不出现沉默扣除。
  • 冷却余波能被日志和总览看见。

App v1.8.0：联机助阵与活动化

目标：把擂台赛接入轻量联机和周期活动。当前这一版已落地，作为擂台系统的活动化基础。

范围：

  • 好友可派一名店员助阵。
  • 助阵推进联机共同目标。
  • 加入赶集日、夜市日等时间事件对擂台触发的加成。
  • 擂台完成后可生成可分享战报。

验收：

  • 联机助阵有发送、接收、日志反馈。
  • 不在线也不会破坏单机擂台流程。
  • 活动加成在总览或日志中可见。

当前结论：这三个验收点已完成，后续若继续扩展擂台，应另起 v1.9 主题，而不是继续占用 v1.8 名义。

子会话拆分建议

子会话 A：状态与存档

负责文件：

  • src/types.ts
  • src/utils/tournament.ts
  • src/App.tsx 中存档读写的最小接入
  • docs/version-history.md

交付：

  • TournamentState 类型和默认值。
  • 阶段推进纯函数。
  • 旧存档兼容补齐。

子会话 B：事件链路

负责文件：

  • src/App.tsx
  • src/components/RandomEventPopup.tsx
  • docs/story-event-nodes-v1.md

交付：

  • setup/qualifier/final/cooldown 事件节点。
  • 事件选择与当前随机事件池共存。
  • 事件结果能推进 TournamentState。

子会话 C：总览 UI

负责文件：

  • src/components/LedgerSummaryTab.tsx
  • 可能新增 src/components/TournamentStatusCard.tsx

交付：

  • 总览显示擂台阶段、热度、秩序。
  • 提供清晰的下一步提示。
  • 不挤压现有资源和时间信息。

子会话 D：验收与发布

负责范围：

  • 跑 npm run lint
  • 跑 npm run build
  • 检查旧存档兼容路径
  • 如达到可验收，再发布 Cloudflare Pages

交付：

  • 验收结果。
  • 发布地址。
  • 版本历史补充。

风险控制

  • 不要在 v1.6.0 同时做联机助阵。
  • 不要在第一版擂台里做复杂战斗动画。
  • 不要让事件效果直接扣资源但 UI 不展示。
  • 如果引入存档字段，必须同步 SAVE_SCHEMA_VERSION 和读档默认值。
  • 每个子会话只负责自己的写入范围，避免互相覆盖。

当前可复用基础

  • GameEvent.eventSeries 已能标记“比武招亲”。
  • GameEvent.timeAffinity 已支持时段亲和。
  • 随机事件弹窗已支持系列标签与时辰标签。
  • 当前已有 4 个比武招亲单次事件，可作为复杂擂台赛的素材来源。