BLOG

Lex Universalis 项目企划书（Godot）

2026/05/03 39 min read BLOG 类 产品方案 形态 企划书 GODOT 卡牌肉鸽 游戏设计

Lex Universalis 项目企划书（Godot）

这份企划书是我作为 Lex Universalis 项目提出者，对这款 PvE 优先、未来可推导 PvP 的卡牌肉鸽游戏做出的初版规划。它不是外部资料整理，也不是单纯的技术备忘，而是我希望团队后续可以直接围绕它讨论分工、确定 Demo 边界、拆开发任务的项目说明书。

Lex Universalis 的当前项目地址是：https://github.com/emptyinkpot/Lex-Universalis。我把它规划为一款基于 Godot 4.x 开发的卡牌肉鸽。玩法主骨架参考《杀戮尖塔》，但战斗内核会更接近“玩家 vs AI 玩家”：双方都拥有卡组、手牌、能量和出牌流程。我的优先级不是一开始做完整 PvP，而是先做出一套能跑通、能扩展、能验证乐趣的“双方同规则打牌”的 PvE Demo。

一句话定位：

我想先做出一套干净的 Actor 统一抽象 + 状态机 + 数据驱动 + 可扩展效果系统，让 PvP 将来可以从 PvE 自然推导出来。

目录

  1. 人员分配与项目组织
  2. 项目概述
  3. 玩法定位与融合策略
  4. 核心系统设计
  5. 技术路线与工程结构
  6. 版本边界与 MVP
  7. 按完成度推进的开发计划
  8. 协作机制与验收节点
  9. 参考源码与拆解方向
  10. 风险控制与避坑清单
  11. 结论与后续文档

一、人员分配与项目组织

1.1 组织原则

我不打算把 Lex Universalis 按大厂式重型流程来组织。它更适合做成一个高密度小团队项目：人数不多，但每个人都有明确的负责范围。团队成员可以一人多职，但不能所有人都只参与一点边角工作。制作决策、技术架构、战斗系统和视觉方向必须有稳定 owner。

我会按下面几条原则组织团队：

  1. 项目主文档以职位为主，不先写死具体人名。
  2. 每个人都要有主职责和副职责。
  3. 每人约 70% 时间投入主职责，30% 时间承担副职责。
  4. 每个阶段必须有可试玩版本，不能只停留在讨论和材料整理。

在 GDD / TDD / 企划书里，我会写 Producer / Game Director、Tech Lead、Combat Systems Engineer、UI Designer 这类职位。真实成员对应哪个职位，可以在下面的人员姓名列或内部映射表里填写。这样后续如果人员调整，项目结构本身不用跟着重写。

1.2 计划团队结构（8 人）

职务 负责人员 人数 主职责 关键产出
Producer / Game Director / Final Owner 刘高朋 1 项目方向、功能优先级、版本决策、节奏控制、最终拍板 版本目标、功能取舍、里程碑验收
Tech Lead / Core Architect 万林炜 1 技术架构、系统拆分、风险控制、代码主链把关 架构骨架、核心接口、技术规范
Art Director / Visual Owner 王元 1 视觉方向、风格统一、关键资源把关 UI 风格、关键卡面、视觉基调
Combat Systems Engineer 申林昊 1 卡牌系统、战斗流程、效果结算 战斗主循环、目标选择、结算链路
Systems / Framework Engineer 殷丹阳 1 数据驱动、事件系统、存档、工具链 资源读取、事件系统、存档和调试工具
UI / Gameplay Engineer 周桐宇 1 手牌交互、目标选择、战斗 UI 卡牌交互、HUD、基础反馈
Map / Flow Engineer 刘高朋 1 地图节点、场景切换、奖励流程 地图推进、战后奖励、状态流转
Systems / Balance Designer 秦硕 1 战斗机制、数值模型、敌人行为、Buff 逻辑 数值表、敌人模板、机制说明
Narrative / Content / UI Visual Designer 任元丰 1 世界观、卡牌描述、事件文本、界面视觉执行 事件文本、卡牌描述、卡牌模板、图标集

如果实际团队严格只有 8 人，我会让 Producer / Game Director 兼任 Art Director / Visual Owner，或者让 Narrative / Content Designer 兼任一部分 UI 视觉执行。我的重点不是把职位数凑得很完整，而是保证每个核心模块都有人真正负责。

程序组我倾向于拆成：

1 个核心战斗
+ 1 个框架架构
+ 2 个功能实现

1.3 按职务拆解的 ownership

Producer / Game Director

这个角色负责项目方向和最终体验。我会让它承担版本边界、优先级、阶段试玩验收和功能取舍，尤其要负责决定哪些内容暂时不做。

Tech Lead

这个角色负责主架构和技术边界。我会让它守住数据驱动、逻辑/UI 解耦、核心模块接口和系统耦合风险。

Combat Systems Engineer

这个角色负责战斗主链路，包括卡牌播放、目标选择、结算顺序，以及伤害、防御、抽牌、召唤等效果调用链。

Systems / Framework Engineer

这个角色负责底层支撑，包括事件系统、数据读取、存档、调试工具和资源组织。

UI / Gameplay Engineer

这个角色负责战斗界面的可用性，包括手牌展示、hover / 拖拽 / 点击交互、目标反馈和基础表现。

Map / Flow Engineer

这个角色负责战斗外流程，包括地图生成、节点跳转、战后奖励、场景切换和状态保存。

Systems / Balance Designer

这个角色负责卡牌数值表、敌人模板、状态效果规则和难度曲线。

Narrative / Content / UI Visual Designer

这个角色负责卡牌描述、事件文本、世界观设定、UI 文案、卡牌排版和玩家反馈语气。

二、项目概述

2.1 项目目标

我希望 Lex Universalis 的第一目标是做出一个 3 个月内可展示、可试玩的完整 Demo。这个 Demo 不追求商业版内容量，而是要证明三件事：

  • 双方都能按同一套规则抽牌、获得能量、出牌和结算。
  • 敌人不只是脚本怪，而是 AI 控制的规则玩家。
  • 技术骨架足够干净，后续可以扩展到卡组构筑、肉鸽外壳，甚至 PvP，而不是 Demo 做完就推倒重来。

2.2 项目类型

我把项目类型定为：

  • 游戏名称：Lex Universalis
  • 项目仓库：https://github.com/emptyinkpot/Lex-Universalis
  • 类型：PvE 优先的卡牌肉鸽，后期保留 PvP 推导空间
  • 战斗形式：回合制
  • 核心循环：玩家回合出牌、敌人 AI 回合出牌、双方结算、胜负判定
  • 目标体验：先验证“玩家 vs AI 玩家”的双方打牌是否好玩，再扩展卡组构筑、地图推进和特色机制

2.3 技术选择

我计划优先使用 Godot 4.x。

选择 Godot 的原因是：

  • GDScript 2.0 适合快速写系统原型。
  • Resource 很适合描述卡牌、效果、敌人和遗物。
  • Control UI 系统足够支撑手牌、HUD、目标选择和战斗界面。
  • 项目规模适合中小团队，不需要一开始引入更重的商业引擎工作流。

三、玩法定位与融合策略

3.1 基础玩法定位

我会把 Lex Universalis 的第一阶段定位成：

  • PvE 优先。
  • 回合制战斗。
  • 玩家和敌人都拥有卡组、手牌、能量和出牌流程。
  • 敌人由 AI 控制，但底层结构和玩家一致。
  • 后续再加入卡组构筑、地图推进、Boss 和特色机制。

这里的关键不是“一开始做 PvP”，而是先做“双方都按同一套规则打牌的 PvE”。换句话说，我现在要做的不是完整玩家对战，而是让敌人也打牌。

3.2 PvP 的正确位置

我会把 PvP 设计成从 PvE 推导出来的后期形态，而不是和 PvE 同时开工。

项目会按三层推进：

  1. 层 1：玩家 vs 规则驱动敌人
    敌人先有卡组、手牌和基础 AI，但决策可以很简单。

  2. 层 2：玩家 vs 完整规则玩家
    敌人拥有和玩家一样的卡组结构、能量、抽牌、打牌逻辑，本质是“AI 控制的另一个玩家”。

  3. 层 3：真正 PvP
    等前两层稳定后，再考虑联机、异步对战、匹配、同步、回放等问题。

这个顺序能把复杂度控制住。PvP 的本质会变成控制权切换：Player = Actor（人操作），Enemy = Actor（AI 操作），未来的 RemotePlayer = Actor（远端玩家操作）。

3.3 融合方式

我不会把《杀戮尖塔》《炉石》《邪恶铭刻》平均混在一起。我的融合顺序是：

  • 主骨架：杀戮尖塔
  • 战斗扩展：双方同规则打牌 + 目标选择
  • 风味增强：邪恶铭刻 的献祭、卡牌进化、叙事感

具体执行上，我会先保留《杀戮尖塔》的战斗节奏，但把敌人从“写死行为”升级为“AI 控制的规则玩家”。单位、献祭、进化这些差异化机制后置，等双方打牌的基础战斗成立后再加。

3.4 我会保留和后置的元素

《杀戮尖塔》侧，我会保留：

  • 能量系统。
  • 抽牌 / 弃牌 / 牌库循环。
  • 回合制节奏。
  • 战后奖励和地图推进，但不进入最小 MVP。

对战结构侧，我会先保留：

  • Actor 统一抽象。
  • 双方卡组、手牌、能量、出牌。
  • 极简敌人 AI。
  • 目标选择。

这些内容后置：

  • 单位系统。
  • 献祭机制。
  • 卡牌进化。
  • 元叙事事件。
  • 永久性卡牌变化。

后置不代表不做，而是不能压过当前第一目标：验证“双方都能打牌”的战斗是否好玩。

四、核心系统设计

4.1 Actor 统一抽象

我会把 Actor 作为战斗系统最核心的抽象。玩家和敌人都不是两套系统，而是同一种规则实体，只是控制方式不同。

class_name Actor
 
var deck: Array[CardData]
var hand: Array[CardData]
var discard_pile: Array[CardData]
var energy: int
var hp: int
var max_hp: int
 
func draw(amount: int) -> void:
    pass
 
func can_play(card: CardData) -> bool:
    return energy >= card.cost
 
func play_card(card: CardData, target: Actor, context) -> void:
    pass

在这个模型下：

Player = Actor（人操作）
Enemy = Actor（AI 操作）
Future PvP Player = Actor（远端玩家操作）

这一步决定 Lex Universalis 后续能不能自然扩展到 PvP、回放、AI 调参和多种对战模式。如果我一开始把 Player 和 Enemy 写成两套逻辑，后面做 PvP 会变成重写战斗系统。

4.2 卡牌数据

我会把卡牌做成资源对象，而不是把卡牌数值和效果写死在代码里。

extends Resource
class_name CardData
 
@export var id: String
@export var name: String
@export var cost: int
@export var description: String
@export var effects: Array[EffectData]
@export var target_type: int

每张卡牌至少要描述：

  • cost
  • effect
  • target
  • 关键词 / 标签
  • 稀有度、升级态等扩展字段

4.3 效果系统

效果系统是我最优先保证干净的部分。我不打算把卡牌逻辑写成大量 if/else，而是让不同效果各自实现 apply。

extends Resource
class_name EffectData
 
func apply(source, target, context):
    pass

例如：

class_name DamageEffect
extends EffectData
 
@export var amount: int
 
func apply(source, target, context):
    target.take_damage(amount)

以后无论是伤害、护甲、抽牌、上毒、多段攻击、召唤单位还是献祭触发，都可以沿这个方向继续扩展。

4.4 实体系统

Actor 负责“谁在打牌”，Entity 负责“谁能承受伤害或拥有生命”。第一版里玩家和敌人可以直接作为 Actor 参与战斗；如果后面加入单位系统，单位也可以共享实体能力。

class_name Entity
 
var hp: int
var max_hp: int
 
func take_damage(amount: int) -> void:
    hp -= amount

在此基础上再分：

  • Player
  • Enemy
  • Unit

第一版不会优先做复杂 Unit，但我会保留这个方向，避免后续引入单位时和当前战斗模型冲突。

4.5 战斗状态机

我会尽早建立 BattleManager，不把战斗流程散落在 UI 或卡牌脚本里。

enum BattleState {
    START,
    PLAYER_TURN,
    ENEMY_TURN,
    RESOLVE,
    END
}

BattleManager 负责：

  • 双方开局抽牌。
  • 当前 Actor 回合控制。
  • 出牌校验。
  • 结束回合。
  • 敌人 AI 行动。
  • 持续效果结算。
  • 胜负判定。

基础循环先定为：

Start Battle
→ Player Actor Draw
→ Player Turn: play cards
→ End Player Turn
→ Enemy Actor Draw
→ Enemy AI Turn: play cards
→ Resolve Status / Buff
→ Next Round

这套循环看起来仍是 PvE，但底层已经是“两个 Actor 轮流按同一规则打牌”。这就是后续 PvP 的基础。

4.6 敌人 AI

第一版敌人 AI 不做复杂。它只需要证明“敌人也能用卡组打牌”。

MVP AI 规则：

按手牌顺序扫描
→ 找到第一张当前能量足够的牌
→ 选择合法目标
→ 打出
→ 重复，直到没有可打牌或选择结束

后续 AI 再逐步增加：

  • 低血量优先防御。
  • 玩家低血量优先攻击。
  • 能量利用率更高的出牌顺序。
  • 毒、抽牌、多段攻击等策略权重。

4.7 事件系统

我会预留事件系统，因为后续 buff、触发技、连锁效果、抽牌触发、单位死亡触发都会依赖它。

signal card_played(actor, card)
signal turn_started(actor)
signal damage_taken(target, amount)
signal actor_defeated(actor)

事件系统的目的，是把卡牌、Buff、Relic 和角色特性解耦开。

4.8 后置系统：单位与 Roguelike 循环

单位系统、地图、奖励和 Boss 都是重要内容，但不进入最小 MVP。等双方打牌成立后，地图第一版只做够用的结构：

Start
├─ 战斗
├─ 商店
├─ 随机事件
└─ 精英

我先解决三个问题：

  • 节点怎么生成。
  • 节点怎么跳转。
  • 战后奖励怎么发。

复杂单位规则、复杂分支图、大量事件文本和超长 meta progression 都不进入第一版 Demo。

五、技术路线与工程结构

5.1 项目结构

我会从一开始拆开逻辑层和表现层。

res://
├── core/              # 核心逻辑，不放 UI
│   ├── battle/
│   ├── card/
│   ├── entity/
│   ├── effect/
│   └── relic/
│
├── data/              # .tres / .res 等数据资源
│   ├── cards/
│   ├── enemies/
│   └── relics/
│
├── scenes/
│   ├── battle/
│   ├── map/
│   └── ui/
│
├── ui/                # 纯 UI 逻辑
└── utils/

我会遵守这几个边界：

  • core/ 只负责规则。
  • ui/ 和 scenes/ 只负责表现。
  • 卡牌和敌人尽量用资源描述，不把数值写死在场景里。
  • 不把规则逻辑写进 UI，避免后续改规则、测试和扩卡都变困难。

5.2 项目主文档体系

我会先维护三类文档，不做过重的文档矩阵。

GDD（Game Design Document）

GDD 面向全员，写规则和体验，不写代码实现：

  • 游戏概述。
  • 核心玩法。
  • 卡牌系统。
  • 战斗系统。
  • Roguelike 结构。
  • 敌人与 AI。
  • 项目职务与 owner。
  • 开发路线图。

TDD（Technical Design Document）

TDD 面向程序组，写技术结构和边界：

  • 核心模块划分。
  • 关键类与数据流。
  • 状态机。
  • 资源组织方式。
  • 事件系统。
  • 存档与配置边界。

Art Guide / UI Guide

视觉和 UI 规范面向美术与 UI 执行：

  • 卡牌尺寸与版式。
  • HUD 结构。
  • 字体与颜色方向。
  • 图标风格。
  • 角色、敌人、卡牌视觉关系。

六、版本边界与 MVP

6.1 第一验收 MVP 目标

我会把第一验收 MVP 锁定为“双方都能打牌的一场战斗”，不把它做成完整商业化版本，也不在第一阶段做完整 PvP。后续 Demo 可以继续向卡组构筑和 Roguelike 外壳扩展，但只有这个 MVP 先成立，后面的地图、Boss 和差异化机制才有意义。

开始战斗
→ 玩家抽牌、获得能量、出牌
→ 敌人抽牌、获得能量、AI 出牌
→ 双方循环结算
→ 胜负判定

MVP 必须包含：

  • 双方都有卡组。
  • 双方都有手牌、抽牌、能量和出牌。
  • 玩家初始牌组约 10 张。
  • 敌人卡组约 5 到 8 张。
  • 极简敌人 AI：优先打出第一张能打的牌。
  • 5 到 8 张基础卡牌：攻击、防御、抽牌、毒、多段攻击。
  • 一场完整的玩家回合 -> 敌人回合 -> 胜负判定流程。

MVP 暂不包含：

  • 完整 PvP。
  • 联机、匹配、同步、回放。
  • 地图。
  • relic。
  • 单位系统。
  • 献祭。
  • UI 美术打磨。
  • 多敌人战斗。
  • 多角色开局。
  • 长剧情分支。
  • 复杂 Meta 成长。
  • 大量可收集外围系统。

我判断 Demo 成功与否，不看内容是否很多，而看“双方同规则打牌”这件事是否成立、是否有基础乐趣。

6.2 MVP 分级

V1

我先做一场最小“双方打牌”战斗：

  • 玩家和敌人各一个 Actor。
  • 玩家 10 张卡组。
  • 敌人 5 到 8 张卡组。
  • 双方都有手牌、能量、抽牌、出牌。
  • 敌人 AI：优先打出第一张能打的牌。
  • 胜负判定。

V2

我再把战斗变得可读、可玩，并开始形成构筑感：

  • 10 张左右基础卡牌。
  • Buff / Debuff。
  • 敌人卡组模板。
  • 简单敌人 AI 权重。
  • 简单奖励选择。

V3

我最后补肉鸽外壳：

  • 3 到 5 场连续战斗。
  • 简单地图。
  • 1 个 Boss。
  • 战后加卡。

只要 V1 做扎实，我就能判断 Lex Universalis 的核心方向是否值得继续推进。单位、献祭、进化都放在 V3 之后再评估。

6.3 开发顺序

我的开发顺序是：

  1. 玩家能打牌：出牌、扣血、回合切换、3 到 5 张基础卡牌。
  2. 敌人也能打牌：Enemy 变成 Actor，拥有 deck / hand / energy / AI 出牌。
  3. 战斗可玩化：卡牌扩展、Buff / Debuff、敌人卡组模板。
  4. 卡组构筑：战后加卡、简单卡池、初步平衡。
  5. Roguelike 外壳：3 到 5 场战斗、简单节点地图、一个 Boss。
  6. 差异化机制：单位、献祭、进化。
  7. 未来 PvP：联机或异步对战。

七、按完成度推进的开发计划

我不按日期或周数安排 Lex Universalis 的项目目标。这个项目更适合按“系统完成程度”推进：前一个系统没有达到可试玩标准，就不进入下一个系统。这样可以避免表面上排期推进了，但核心玩法其实没有成立。

每个阶段都必须满足三类条件：

  • 可运行：不是文档完成，而是游戏里能跑。
  • 可试玩：不是只在调试台通过，而是玩家可以实际操作。
  • 可判断：完成后能判断这个方向是否值得继续投入。

7.1 完成度 1：玩家能打牌

这一阶段只追一个目标：玩家作为 Actor 可以完成一轮基础出牌。

核心实现

  • 建立 Godot 项目基础结构。
  • 确定 CardData / EffectData / Actor / BattleManager 四个核心入口。
  • 玩家拥有 deck / hand / discard_pile / energy / hp。
  • 实现抽牌、出牌、扣血、弃牌、结束回合。
  • 做出 3 张最基础卡牌：攻击、防御、抽牌。
  • 放入 1 个临时敌人，先作为可被攻击的目标。

完成标准

  • 玩家进入战斗后能抽牌。
  • 玩家能看到手牌和能量。
  • 玩家能打出至少 3 类卡牌。
  • 出牌能正确消耗能量。
  • 攻击牌能造成伤害，防御牌能产生防御，抽牌牌能改变手牌。
  • 战斗能判断胜利或失败。

阶段产出

  • 最小战斗场景。
  • 首版 Actor。
  • 首版 BattleManager。
  • 3 张基础卡牌资源。
  • 一份最小卡牌数据表。

暂不处理

  • 敌人卡组。
  • 敌人 AI。
  • 地图。
  • 战后奖励。
  • 美术风格。

7.2 完成度 2：敌人也能打牌

这是整个项目最关键的阶段。完成这一阶段后，敌人不再是脚本怪，而是 AI 控制的规则玩家。

核心实现

  • 玩家和敌人都统一成 Actor。
  • 敌人拥有自己的 deck / hand / discard_pile / energy / hp。
  • 敌人回合开始时抽牌并获得能量。
  • 敌人能调用同一套 play_card()。
  • 敌人使用和玩家同一套 CardData 与 EffectData。
  • AI 先只做最小规则：按手牌顺序打出第一张能打的牌。

完成标准

  • 敌人不是固定攻击脚本。
  • 敌人可以从自己的卡组抽牌。
  • 敌人可以消耗能量打牌。
  • 敌人能打攻击、防御、抽牌类卡牌。
  • 玩家回合和敌人回合能循环。
  • 一场战斗能以双方同规则出牌的方式结束。

阶段产出

  • EnemyActor 或等价的 AI 控制 Actor。
  • 极简 AI 决策器。
  • 1 套敌人基础卡组。
  • 敌人出牌日志或战斗内反馈。
  • 一场完整“玩家 vs AI 玩家”战斗。

暂不处理

  • 聪明 AI。
  • 多敌人。
  • PvP。
  • 单位系统。
  • 复杂状态连锁。

7.3 完成度 3：基础卡池成立

这一阶段的目标是让双方打牌不只是能跑，而是开始有选择和差异。

核心实现

  • 把基础卡扩到 8 到 10 张。
  • 覆盖攻击、防御、抽牌、毒、多段攻击、增益或减益。
  • 为每张卡补齐名称、费用、效果、目标类型和描述。
  • 初步建立卡牌稀有度或类型标签。
  • 让玩家卡组和敌人卡组共享同一套卡牌效果系统。

完成标准

  • 玩家不再只是在重复打同一种攻击牌。
  • 敌人可以通过卡组表现出不同倾向。
  • 卡牌效果能通过 EffectData 组合，而不是写死在单张卡里。
  • 玩家能从战斗中感受到“出牌顺序”和“能量分配”的差异。

阶段产出

  • 8 到 10 张基础卡。
  • 首版卡牌平衡表。
  • 2 到 3 套敌人卡组模板。
  • 首版关键词说明。

暂不处理

  • 大量卡池。
  • 稀有卡复杂机制。
  • 卡牌升级系统。
  • 献祭、进化等特色机制。

7.4 完成度 4：构筑感出现

这一阶段的目标是让玩家不只是在打一场固定战斗，而是开始对卡组产生管理感。

核心实现

  • 战斗胜利后出现卡牌奖励。
  • 奖励采用三选一或类似的简单选择。
  • 选择的卡能加入玩家卡组。
  • 下一场战斗使用更新后的卡组。
  • 保留玩家血量或其他基础状态。

完成标准

  • 玩家能在战斗后改变自己的卡组。
  • 卡组变化会影响下一场战斗。
  • 奖励选择不是纯装饰，而是能改变打法。
  • 至少能连续完成多场战斗。

阶段产出

  • 战后奖励界面。
  • 卡组增删逻辑。
  • 简单卡池抽取规则。
  • 连续战斗流程。

暂不处理

  • 商店。
  • 遗物。
  • 复杂事件。
  • 长线 Meta 成长。

7.5 完成度 5：Roguelike 外壳成立

这一阶段才开始做地图和一局流程。它不是 MVP 的前置条件，而是 MVP 成立后的外壳。

核心实现

  • 3 到 5 场连续战斗。
  • 简单节点地图。
  • 普通战斗节点。
  • 奖励节点。
  • 1 个 Boss 节点。
  • Boss 拥有独立卡组和更明确的战斗节奏。

完成标准

  • 玩家能从起点推进到 Boss。
  • 每场战斗之间的卡组状态能保留。
  • Boss 战和普通战斗有明显差异。
  • 一局可以完整结束，而不是只停在单场战斗。

阶段产出

  • 首版地图流。
  • 首版 Boss。
  • 3 到 5 个敌人或敌人卡组模板。
  • 一局 Demo 闭环。

暂不处理

  • 大地图分支。
  • 商店经济。
  • 大量剧情事件。
  • 复杂 Meta progression。

7.6 完成度 6：差异化机制选择

只有当双方打牌、基础卡池、构筑和一局外壳都成立后，我才会考虑差异化机制。这里不能贪多，只能先选一个方向验证。

候选方向：

  • 单位系统：让部分卡牌召唤单位，形成场上持续压力。
  • 献祭机制：通过消耗单位、卡牌或资源换取更强效果。
  • 卡牌进化：让卡牌在一局中发生永久或半永久变化。

选择标准：

  • 是否能增强“双方打牌”的核心，而不是抢走核心。
  • 是否能用现有 Actor / CardData / EffectData / BattleManager 承载。
  • 是否会让敌人 AI 复杂度失控。
  • 是否能用少量内容验证玩法价值。

阶段完成标准：

  • 只加入一个差异化机制。
  • 该机制至少有 2 到 3 张卡能体现。
  • 玩家和敌人都能在规则上使用或应对该机制。
  • 如果机制破坏基础战斗节奏，就回退到上一阶段。

7.7 完成度 7：体验打磨

这一阶段不扩功能，只把已经成立的 Demo 打磨到能给别人试玩。

核心实现

  • 出牌反馈。
  • 受击反馈。
  • 抽牌、弃牌、能量变化反馈。
  • 敌人出牌可读性。
  • 基础音效。
  • 错误提示和不可出牌提示。
  • 战斗结束结算。

完成标准

  • 不看代码的人也能理解当前轮到谁、能做什么、发生了什么。
  • 敌人出牌不是“突然扣血”，而是能看到卡牌和效果。
  • 玩家能独立完成一局 Demo。
  • 试玩反馈能集中在玩法问题，而不是“看不懂怎么操作”。

7.8 完成度 8：未来 PvP 预留

PvP 不进入当前 Demo 的目标范围。只有当 Actor、BattleManager、卡牌效果、AI 玩家和一局流程都稳定后，我才会考虑 PvP。

PvP 预留方向：

  • 异步对战。
  • 联机对战。
  • 匹配。
  • 同步 / 回放。
  • 远端玩家控制的 Actor。

我不会为了未来 PvP 现在就做网络层。当前只需要保证战斗内核不是写死的单机脚本，而是能从 Actor 控制权自然扩展。

八、协作机制与验收节点

8.1 阶段推进节奏

阶段开始

每进入一个阶段前，我会明确当前唯一目标、负责 owner、完成标准和明确不做项。没有完成标准的阶段不启动。

阶段推进中

同步时只讲三件事：当前阶段完成了什么、下一步要补什么、卡在哪里。讨论不能跳到后续阶段抢跑。

阶段验收

每个阶段结束必须产出一个可试玩版本。全员试玩后，只记录真实问题，不开散会式脑暴。

8.2 完成度验收点

验收点 1：玩家必须能打一局

如果玩家抽牌、出牌、扣血、回合切换、胜负判定这条链路还没有完成，就不能进入敌人打牌阶段。

验收点 2：敌人必须能打牌

如果敌人还只是写死行为，而不是拥有卡组、手牌、能量和 AI 出牌，我会暂停外围内容，优先补齐 Actor 统一结构。

验收点 3：构筑必须影响下一场战斗

如果战后加卡不能影响后续战斗，说明卡组构筑还只是界面装饰，不能进入 Roguelike 外壳阶段。

验收点 4：必须有一局流程

如果还不能完成连续战斗、战后加卡、Boss 结算，就不继续扩差异化机制。

验收点 5：Demo 必须可被外部试玩

最终 Demo 的完整标准是“双方同规则打牌”成立，并且玩家能看懂、能操作、能完成一局。它不是 PvP、单位、献祭或复杂地图都完成。

九、参考源码与拆解方向

我会把参考源码当作拆解对象，而不是寻找一个可以直接照搬的完整成品。Lex Universalis 自己的代码仓库是主项目真源，其他仓库只用于学习结构、交互和工程拆法。

9.1 Lex Universalis 仓库

Lex Universalis

我会把这个仓库作为唯一项目源码主线。参考源码里的结构、交互和实现方式，只能在理解后吸收进 Lex Universalis，不能直接让参考代码反过来主导项目结构。

9.2 核心逻辑 / 架构参考

Slay the Web

我主要看它的：

  • 卡牌肉鸽核心结构。
  • 地图、战斗、卡组的拆分方式。
  • 逻辑层和 UI 的解耦。
  • 数据驱动组织方式。

重点价值：

  • GameFlowManager 这类流程控制思路。
  • Card / Player / Enemy 分离建模。
  • 事件系统与可复现 RNG。

Slay the Spire C++ 复刻 / 同类高校项目

我主要看它的：

  • 面向对象建模方式。
  • Buff / 状态系统。
  • 工厂模式、事件系统、对象生成。

我不会照搬 C++ 实现，而是借它理解卡牌对象怎么抽象、Actor 怎么统一建模、状态叠加怎么避免写成一堆 if/else。

Godot 官方 Demo 项目

我主要看它的：

  • Godot 4.x 项目组织方式。
  • 场景、输入、UI、资源加载的官方写法。
  • Control UI 和 gameplay 场景之间的拆分方式。

这个仓库不是卡牌肉鸽源码，但可以作为 Godot 工程习惯和基础写法的参考，避免 Lex Universalis 一开始就写出不符合引擎习惯的结构。

9.3 卡牌 UI / 交互层参考

Card Framework（Godot）

我主要看它的：

  • 手牌展示。
  • 卡牌 hover / 拖拽 / 排列。
  • 目标选择和交互反馈。

这类项目更偏表现层，不是核心玩法框架。我会把它当作 Lex Universalis 的卡牌 UI 与交互反馈参考，而不是战斗规则参考。

9.4 参考方式

我不会期待找到一个完整成品来改，而是分模块学习：

  • 用一个项目学战斗主循环。
  • 用一个项目学 Godot 资源驱动。
  • 用一个项目学卡牌 UI 交互。
  • 用一个项目学 Buff / 事件系统。

最终我要做的是系统拼装 + 自己的玩法选择，不是简单 clone。

十、风险控制与避坑清单

10.1 项目管理风险

没有唯一拍板人

如果没有唯一拍板人，项目会持续讨论但无法收口。所以我会把 Final Owner 写进团队结构。

没有技术 owner

如果没有技术 owner，后期系统很容易越做越乱。所以我会让 Tech Lead 对架构和系统边界负责。

设计和程序脱节

卡牌系统做出来不等于游戏好玩。我会把阶段试玩作为验收方式，避免设计和实现长期分离。

人人都做一点

如果所有人都只做一点边角，核心模块就没人真正负责。所以我会按 owner 拆任务。

一直加功能，不关版本边界

Lex Universalis 最大的风险不是做不出来，而是做太多。我会用 3 个月 Demo 边界限制功能扩张。

10.2 技术风险

把逻辑写进 UI

如果规则逻辑写进 UI，后续改规则、测试和扩卡都会变困难。所以我会从目录结构上先拆开 core/ 和 ui/。

卡牌逻辑写死成 if/else

前几张牌写 if/else 能跑，但二十张以后会失控。所以我会优先建立 EffectData 和效果派生结构。

没有事件系统

如果没有事件系统，relic、被动、状态触发和连锁效果都会变得难维护。所以我会在早期就预留事件机制。

太早做复杂地图

地图过重会拖慢战斗验证。所以我会先做简单节点推进，复杂地图和大量事件文本后置。

一开始就做完整 PvP

完整 PvP 会立刻引入联机、同步、匹配、回放和公平性问题，复杂度会把 Demo 压垮。所以当前阶段我只做“AI 控制的规则玩家”，让 PvP 以后从 Actor 控制权切换自然长出来。

一开始就完整炉石化

完整炉石化会让站位、单位交换和复杂场面效果同时爆炸。所以我只先做双方卡组、手牌、能量、目标选择和基础出牌，不在 MVP 做单位系统。

十一、结论与后续文档

11.1 决策摘要

我对 Lex Universalis 的当前决策是：

  • 引擎：Godot 4.x
  • 类型：PvE 优先、未来可推导 PvP 的卡牌肉鸽
  • 主骨架：杀戮尖塔
  • 核心战斗：玩家 vs AI 玩家，双方都按同一规则打牌
  • 架构重点：Actor 统一抽象、资源驱动、效果系统、事件系统、战斗状态机
  • 开发顺序：玩家能打牌 -> 敌人也能打牌 -> 卡组构筑 -> Roguelike 外壳 -> 差异化机制 -> 未来 PvP

一句话版本：

我现在要做的不是完整 PvP，而是先做出“双方都按同一规则打牌”的 PvE；未来 PvP 只是 Actor 控制权从 AI 切换到玩家。

11.2 后续文档优先级

接下来我会优先补这些文档：

  1. 内部职位到真实成员的映射表。
  2. GDD：双方打牌规则、胜利条件、卡牌类型、敌人卡组模板。
  3. TDD：Actor、BattleManager、AI 决策、数据结构、事件协议。
  4. Art Guide / UI Guide：卡牌模板、HUD、字体、颜色、图标风格。