大观园 · 百人异步竞技

游戏设计文档 (GDD) v1.1

核心命题： 一座园子，百人博弈。你永远不知道谁是真心帮你，谁在背地里卖你的情报。

引擎： Godot 4.x（GDScript） 形态： Web / 移动端 异步多人社交策略游戏

目录

1. 游戏核心设定
2. 五大玩家阶层
3. 管家系统 · 资源博弈
4. 丫鬟小厮系统 · 情报经济
5. 主子系统 · 诗社与名望
6. 元老与清客系统
7. 突发事件设计
8. 清算逻辑与胜利条件
9. 技术选型：Godot 4
10. 详细开发计划表

1. 游戏核心设定

1.1 世界观

《大观园》以《红楼梦》为背景，是一款百人异步社交策略游戏。玩家扮演贾府中的各色人物，在共同的家族命运容器里，以截然不同的视角和手段，争夺资源、名声、情报与最终的生存评分。

这不是谁杀死最多人的竞技游戏，而是一个末世生存游戏。 家族的倒塌是注定的，问题只在于——你是推倒它的人，还是最后一个逃离的人？

1.2 异步博弈的时间架构

玩家不需要同时在线——每次登录，系统将"这段时间世界发生了什么"以送来的帖子、收到的眼色、流言碎片等形式呈现。

1.3 两个全局数值：末日进度条

核心博弈： 沉船派玩家希望加速内耗值，在抄家前变现离场。保家派玩家则需要花费资源降低内耗值。双方博弈贯穿全局。

2. 五大玩家阶层

阶层流动规则

• 上一局积分最高的玩家优先获得元老阶层资格
• 丫鬟达到特定条件可晋升为姨娘（主子阶层）参与下一局
• 管家威望归零可被强制降级，由备选玩家接替

3. 管家系统 · 资源博弈

3.1 公中银库

每日系统根据家族繁荣度拨发"公中银子"。管家掌握全部分配权。

分配操作表

两本账机制（新）

管家可维护明账（对外公示）与暗账（真实数据）。清算时，若调查方获得"暗账碎片"，可发起"对比审查"，瞬间暴露全部漏洞。

3.2 批条系统 · 每日行动

管家每日拥有 6点精力，以下行动均消耗精力：

3.3 查账机制

发起阶段
  └─ 任意玩家消耗 20点气数 + 至少1份账目漏洞碎片 → 发起查账请求

调查阶段（24小时异步）
  └─ 元老玩家异步审理
  └─ 管家可在此期间花费资源"销毁证据"或"拉拢证人"

裁决阶段
  ├─ 亏空 ≤ 10%   → 无罪释放，举报者损失20点气数
  ├─ 亏空 10–30%  → 管家降级，罚没当期所有私产
  └─ 亏空 > 30%   → 抄家事件提前触发

反咬机制（新）： 管家被查时，可消耗手中的"情报碎片"反咬举报者，将调查转移到举报玩家身上，拖延时间，制造混乱。

3.4 言官系统 · 民意制衡

每次管家做出重大分配决策后，全体玩家有 6小时 投票窗口：

3.5 管家双路线终局

4. 丫鬟小厮系统 · 情报经济

4.1 听壁脚 · 情报获取

丫鬟每日可选择挂机监听一个场景：

双人挂机（新）： 与另一名丫鬟结成对食或私约关系后，可同时监听两个场景，情报获取速率翻倍。但一旦有人背叛，对方可以用共同获取的情报同时出卖你。

4.2 狐假虎威 · 借势系统

弃主投靠（新）： 丫鬟可主动脱离当前主子转投他人。旧主子记录"被背叛标记"。背叛次数过多触发**"声名狼藉"**状态，没有任何主子愿意接收。

4.3 传话系统 · 信息操控

底层玩家是唯一能跨阵营私聊的桥梁，每次充当信使有三个选择：

4.4 流言工坊 · 信息战

消耗 5点精力 可发布一条流言：

0–6小时：口耳相传
  └─ 目标玩家消耗10点气数可直接压下，不留痕迹

6–12小时：人尽皆知
  └─ 需管家消耗2点精力才能平息
  └─ 目标玩家"体面值"-5

12小时后：板上钉钉
  └─ 变成"实质处罚"，名誉值-15，无法消除
  └─ 内耗值+3

流言嫁接（新）： 若手中有同一玩家的两条情报碎片，可将其合并为一条流言，杀伤力翻倍，且难以证伪。

4.5 三条逆袭路径

5. 主子系统 · 诗社与名望

5.1 海棠诗社 · 名望护城河

诗社每旬举办一次，全体玩家均可参与评赏：

名望的实际价值

• 名望 ≥ 80：管家搜检你时消耗双倍精力
• 名望 ≥ 120：可发起"联名谏言"，强制撤销管家某项决策
• 名望 ≥ 150：元老被动关注你，赏赐概率大幅提升
• 名望 ≤ 20：任何人可以随意诋毁你，不受惩罚

5.2 代笔黑市（新）

才情值低的玩家可以花钱雇丫鬟玩家代笔投稿。代笔方可以选择：

• 真心帮忙：收钱，主顾名望提升
• 故意写烂诗：让雇主出丑，赚取额外的"坐收渔利"分数

6. 元老与清客系统

6.1 元老系统 · 审判生态

• 定夺权： 两个玩家产生不可调和纠纷时，案件进入元老异步审批后台
• 厌弃机制： 可对任意玩家施加"厌弃"状态，被厌弃者所有公共场合收益减半
• 额外赏赐： 决定谁能获得系统随机刷新的顶级道具

6.2 清客系统 · 搅局生态

刘姥姥进大观园事件（新）： 当清客玩家在园内蹭饭次数达到阈值，触发全局事件——所有主子必须接待，消耗宴席资源。若礼遇得当，获得"民间口碑"加成，降低家族内耗值。

7. 突发事件设计

突发事件是打破固定节奏的关键机制，每旬随机触发 1–2 个，要求全体玩家在48小时内做出异步响应。

稀有事件

🏮 元妃省亲

• 管家需在72小时内完成"接驾预算"，亏空值+25
• 主子阶层需准备才艺（诗词/题额），名望争夺激烈
• 丫鬟小厮差使全开，精力消耗翻倍但薪酬也翻倍
• 隐藏博弈： 管家可在接驾预算里侵吞5–15%作为"跑腿费"，因为此时没人有空查账

⚰️ 大出殡（秦可卿/贾敬薨逝）

• 家族进入丧期，禁止娱乐活动（诗社暂停1旬）
• 月例暂停发放
• 开启"奔丧来客"机制：外来玩家（清客）可携带外部资源进入家族循环

🔥 抄检大观园

• 当内耗值达到80%时随机触发
• 对全部玩家进行强制搜检，所有背包内容全部曝光
• 本局的"大洗牌时刻"，是最高风险也是最高收益的时间节点

中等事件

🔍 贾政大检查

• 所有玩家背包中的违禁品须在24小时内转移或销毁
• 管家若收到贿赂可以"放水"跳过某些房间的检查

👵 刘姥姥进大观园

• 所有主子必须腾出资源接待
• 接待分足够高：获得"民间口碑"奖励，内耗值-8
• 背地里嘲笑刘姥姥的玩家若被情报碎片记录，名望-10

8. 清算逻辑与胜利条件

8.1 最终评分公式

最终得分 = (命运逆转分 × 命运系数) + 社交资本 + 个人财产 - 业障清算 + 结局彩蛋加成

8.2 五个评分维度

9. 技术选型：Godot 4

9.1 为什么选 Godot 4

9.2 推荐技术架构

Godot 4 (前端 + 游戏逻辑)
    │
    ├── 场景树
    │   ├── Main.tscn          # 主入口，处理登录状态
    │   ├── Hub.tscn           # 大观园主界面（导航中心）
    │   ├── Treasury.tscn      # 银库界面（管家专用）
    │   ├── Inbox.tscn         # 门房收件箱（批条/帖子）
    │   ├── IntelBag.tscn      # 情报背包（丫鬟专用）
    │   ├── RumorBoard.tscn    # 流言广场
    │   ├── PoetryHall.tscn    # 诗社（主子专用）
    │   └── Settlement.tscn    # 清算结算界面
    │
    └── 后端 (Firebase Realtime Database)
        ├── /games/{game_id}   # 全局游戏状态
        ├── /players/{uid}     # 玩家数据
        ├── /treasury          # 公中账本（明账）
        ├── /actions_queue     # 待处理批条队列
        ├── /rumors            # 流言及发酵状态
        └── /events            # 突发事件日志

9.3 关键技术点

异步通知（Godot + Firebase）

# 监听流言发酵状态变化
func _ready():
    Firebase.Database.get_node("rumors").child_changed.connect(_on_rumor_updated)

func _on_rumor_updated(snapshot):
    var rumor = snapshot.get_value()
    if rumor["ferment_stage"] == 3:
        # 触发实质处罚，扣除目标玩家名誉值
        apply_reputation_penalty(rumor["target_uid"], 15)

精力系统（本地计算 + 服务器验证）

# PlayerState.gd - 单例
var stamina: int = 6
var last_refresh_time: int

func get_current_stamina() -> int:
    var elapsed = Time.get_unix_time_from_system() - last_refresh_time
    var recovered = int(elapsed / 7200)  # 每2小时恢复1点
    return min(stamina + recovered, 6)

流言发酵定时器（服务器端 Cloud Functions）

// Firebase Cloud Function
exports.fermentRumors = functions.pubsub
  .schedule('every 30 minutes').onRun(async () => {
    const rumors = await db.ref('rumors').once('value');
    rumors.forEach(rumor => {
      const age = Date.now() - rumor.val().created_at;
      if (age > 43200000) { // 12小时
        applyRumorPenalty(rumor.val());
      } else if (age > 21600000) { // 6小时
        updateFermentStage(rumor.key, 2);
      }
    });
});

10. 详细开发计划表

总周期预估： 约 22–28 周（兼职开发约 6–7 个月）

最小团队： 1名开发（你） + 1名美术（可后期引入）

原则： 先跑起来，再做好看。先10人，再100人。

第零阶段：桌游验证（2周）

目标： 在写任何代码之前，手动跑通一局游戏，发现规则漏洞。

具体任务：

• 招募 8–10 名朋友，建立微信群
• 用腾讯文档创建共享"账本表格"，模拟公中银库
• 你扮演凤姐（管家），手动处理所有"审批请求"（朋友发消息 = 递简子）
• 设定流言规则：朋友可在群里发流言，12小时内没人回应就"生效"
• 跑完一局（3–5天），记录以下内容：
  • 哪些规则太复杂，实际执行混乱？
  • 哪些时刻让玩家最兴奋/最愤怒？
  • 数值是否需要调整？（月例多少？精力几点？）
• 整理成"规则修订笔记"，更新本文档数值

本阶段产出：

• 经过真实验证的核心规则
• 确定 MVP 范围（哪些系统先做，哪些暂时砍掉）

第一阶段：环境搭建与脚手架（1周）

目标： 让项目可以跑起来，但不做任何游戏功能。

具体任务：

• 安装 Godot 4.x，建立项目结构（按上文场景树组织）
• 注册 Firebase 项目，开启 Realtime Database
• 集成 Godot Firebase 插件（GodotFirebase 或 gut-firebase）
• 实现用户注册 / 登录 / 角色选择（最简单的UI即可）
• 建立 Firebase 数据库基础结构（建所有表，先填假数据）
• 实现一个"数据读写测试"：玩家点击按钮，银库数字-10，刷新后持久

本阶段产出：

• 可登录的空项目
• Firebase 读写通畅

第二阶段：管家系统 MVP（3周）

目标： 一个人可以完整体验管家的核心循环（发月例、克扣、被查账）。

Week 1：银库界面

• 建立 Treasury.tscn 场景
• 展示公中银两总量、当日应发数额、历史发放记录
• 实现"月例发放"界面：列出所有玩家，可逐一设定发放金额
• 实现"暗中克扣"逻辑：实际发放金额与明账记录可以不同
• 在服务器端记录明账与暗账两份数据

Week 2：批条系统

• 建立 Inbox.tscn 场景（管家的审批后台）
• 实现"精力系统"：每日6点，每次行动消耗对应精力
• 实现"采办物资"、"差使分派"两个行动（先做这两个）
• 实现"预支批条"：允许玩家提前支取，写入Firebase，亏空值增加

Week 3：查账流程

• 实现"账目漏洞碎片"道具（当管家克扣超过阈值，自动生成碎片放入某个丫鬟的背包）
• 实现"发起查账"按钮：消耗气数，提交碎片，进入24小时等待
• 实现"裁决"逻辑：计算亏空比例，执行对应处罚
• 实现"言官投票"：分配决策发布后，展示投票界面，6小时后统计

本阶段产出：

• 可完整体验管家核心循环的功能原型

第三阶段：丫鬟系统 MVP（3周）

目标： 丫鬟玩家可以体验情报获取 → 出售/使用 的完整流程。

Week 1：情报背包

• 建立 IntelBag.tscn 场景
• 实现"挂机监听"：玩家选择一个场景，设置挂机时长
• 实现情报碎片生成逻辑（基于其他玩家最近的行动记录随机生成）
• 实现背包展示：情报碎片列表，可查看内容，可选择"使用/出售"

Week 2：传话与交易

• 实现"传话系统"：选择收件人 → 写内容 → 选择是否篡改
• 实现"蜂腰桥集市"：一个专属丫鬟阶层的异步交易板
• 实现情报出售：卖给对应阵营玩家，换取银两或气数
• 实现"对食/私约"关系绑定：两名丫鬟可申请结为搭档

Week 3：流言系统

• 实现"发布流言"：消耗5点精力，选择目标，编写内容（或从碎片中选）
• 实现"流言发酵"：Firebase Cloud Function 定时更新发酵阶段
• 实现"流言广场" RumorBoard.tscn：所有玩家可见的流言墙，带倒计时
• 实现"平息流言"：管家消耗精力使流言作废
• 实现流言到期后的自动惩罚结算

本阶段产出：

• 管家 + 丫鬟两个阶层可以互动博弈的完整原型

第四阶段：10人内测（2周）

目标： 邀请10名玩家真实游玩，收集反馈，修复核心问题。

Week 1：准备

• 完善角色选择系统（先只开放管家和丫鬟两个阶层，各5人）
• 添加最基础的新手引导（第一次登录的说明弹窗）
• 添加游戏内通知系统（"你收到一封帖子"、"你的流言即将到期"）
• 部署到 Godot Web Export + Firebase 线上环境

Week 2：内测与修复

• 邀请10人测试，观察他们的真实行为
• 重点收集：哪些操作让人困惑？哪些时刻最有趣？数值是否合理？
• 修复前5个最影响体验的bug
• 更新数值平衡（精力消耗、月例金额、亏空阈值等）

第五阶段：主子与诗社系统（2周）

• 建立 PoetryHall.tscn 场景
• 实现诗社题目系统（管理员定期发布题目）
• 实现作品提交 + 匿名点赞/差评
• 实现名望值计算与展示
• 实现名望对管家行为的影响（双倍精力消耗逻辑）
• 实现"联名谏言"功能：高名望玩家可发起联名，达到阈值撤销管家决策
• 实现"代笔黑市"：丫鬟可接受代笔委托

第六阶段：元老、清客与突发事件（3周）

Week 1：元老系统

• 实现元老角色的"厌弃"与"赏赐"功能
• 实现纠纷仲裁后台（元老审批界面）
• 实现"额外赏赐"随机道具系统

Week 2：清客与预言系统

• 实现清客"依附"机制：清客需附着于高权力玩家
• 实现"预视"功能：查看下旬事件类型提示
• 实现"扎小人"Debuff
• 实现"刘姥姥进大观园"特殊事件触发逻辑

Week 3：突发事件系统

• 建立突发事件框架：每旬随机抽取1–2个事件
• 实现"元妃省亲"事件完整流程
• 实现"贾政大检查"事件
• 实现"抄检大观园"事件（内耗值≥80%触发）
• 实现"大出殡"事件

第七阶段：清算系统与结局（2周）

• 实现完整的分数计算逻辑（五个维度）
• 实现命运逆转分：对比玩家角色与其原著命运的差异
• 实现社交资本统计："亲信/爱慕"名单的双向统计
• 实现业障清算：追踪全局背叛/陷害记录
• 建立 Settlement.tscn 清算场景
• 为每个结局路线（贤能管家/末世枭雄/首席丫鬟/赎身出府等）编写结局叙事文本
• 实现下一局阶层继承逻辑（积分最高者获得元老资格等）

第八阶段：视觉打磨与30人公测（3周）

Week 1：美术风格化

• 确定视觉方向：仿宣纸纹理、朱砂红配色、古风字体
• 替换所有占位UI为正式美术资源
• 添加关键动效：批条飞出、银两滚动、流言扩散涟漪
• 音效：古琴背景音、翻阅账本音效、流言传播音效

Week 2：体验细节

• 完善新手引导（分阶层的引导流程）
• 添加角色台词文本（每次行动有符合性格的旁白）
• 移动端适配优化（触屏操作，UI尺寸）
• 性能优化（减少Firebase读取频率，使用本地缓存）

Week 3：30人公测

• 开放全部5个阶层，邀请30名玩家参与
• 建立玩家反馈渠道（Notion表单或问卷）
• 收集并处理反馈，重点修复影响公平性的bug
• 评估是否准备扩大规模

第九阶段：100人正式公测（持续迭代）

• 优化服务器架构（Firebase并发处理能力评估）
• 添加排行榜和历史战绩系统
• 添加游戏内攻略和帮助文档
• 制作宣传内容：将游戏内真实发生的"剧情故事"整理为小红书/微博推文
• 建立社群（Discord或微信群）
• 持续根据玩家行为数据调整数值平衡

附录：核心数值参考表

文档版本：v1.1 · 引擎：Godot 4.x · 后端：Firebase