posts
在线联机原型第 32 章导航：玩家驱动经济系统
本章把「经济」当作一个可观测、可调控的活体系统来验证：当产出的每一枚货币都由玩家行为产生、每一笔交易都由玩家之间撮合时，通胀会从哪里冒出来、又该用什么手段压回去。本页给出第 32 章玩家驱动经济系统（Player-driven Economy）的定位、六个核心验证目标（双账簿、市场平衡、通胀调控、交易幂等、离线结算、防刷风控）、推荐技术栈与真实文章入口，并串起前后相邻章节与相关专题。
第 32 章紧接世界事件之后，把镜头对准游戏里最容易失控、也最难回滚的一层：经济。上一章解决的是「世界会变」，这一章要解决的是「世界变了之后，玩家手里的钱会怎么变」。玩家驱动经济的本质是把货币发行权交给玩家行为——打怪、采集、交易都会造币，也会销毁币，系统要做的是让这条曲线不要指数上扬。这一章适合已经做完掉落与商店、正被「通胀」和「工作室刷金」折磨的策划与服务端，也适合想先看清经济系统要多少张表、多少个定时任务再决定要不要做的团队。
本章定位
| 项目 | 内容 |
|---|
| 全集层数 | 第 4 层（概念原型层） |
| 难度梯度 | 进阶。经济系统是第 4 层里最容易踩到数据一致性坑的一章，建议先完成第 18 章城市经营与第 25 章市场系统再读 |
| 前置章节 | 第 10 章 mini-SLG、第 18 章城市经营、第 21 章异步远征、第 25 章市场系统、第 31 章世界事件与动态天气 |
| 后续章节 | 第 40 章元宇宙市场与创作经济、第 48 章平台经济系统、第 53 章自组织联盟与自治经济 |
| 原型代号 | proto-32-玩家驱动经济系统 |
| 形态 | 通胀调控型，单篇文章的完整 PRD，覆盖架构、状态机、接口与验证清单 |
这一章的关键判断是：经济系统的正确性不靠单点校验，而靠「任何时刻全服货币总量都能被算出来」。因此双账簿（账本加流水）不是可选优化，而是最低要求。
核心验证目标
| 验证点 | 要回答的问题 | 判定标准 |
|---|
| 双账簿 | 余额与流水是否始终对得上 | 任意时刻余额可由流水重算得出，差额为零 |
| 市场平衡 | 买盘与卖盘如何撮合、价格如何形成 | 撮合结果确定、无重复成交、无自成交套利 |
| 通胀调控 | 货币超发如何被检测与回收 | 可定义产出速率上限并触发回收手段 |
| 交易幂等 | 网络重试或断线重连后订单是否重复扣款 | 同一订单号重复提交结果一致 |
| 离线结算 | 玩家不在线时的挂机收益如何结算 | 结算可重放、可审计、可补偿 |
| 防刷风控 | 异常账户如何被识别与拦截 | 高频同构交易可被规则或模型标记 |
技术栈建议
- 语言：Go、Rust、Python 三者任选，账本与撮合建议用 Go 或 Rust 保证并发下的确定性与低延迟。
- 协议：WebSocket over HTTPS 推送价格与成交，gRPC 承载下单、查询与对账。
- 存储：PostgreSQL 作为账本与订单的权威存储，靠事务与唯一约束守住不变量；Redis 缓存行情与热点余额；Kafka 或消息队列承载成交事件流，供风控与统计消费。
- 定时：以固定周期跑通胀指标计算与回收策略，周期长度要与世界事件周期错开。
- 可观测：账目对账任务、资金流大盘、异常账户告警三项缺一不可。
本章文章
这篇文章内部按八个部分展开，阅读时可以直接跳到关心的那一段：
| PRD 小节 | 内容 |
|---|
| 一、概述 | 通胀调控的一句话定义与本章要验证的能力 |
| 二、核心玩法与系统目标 | 产品体验、功能目标与四类验证重点 |
| 三、系统架构设计 | Gateway、经济 Service、State Manager、Event Bus、Persistence 五层划分 |
| 四、功能模块详解 | 基础通信、状态同步、输入校验、日志与监控 |
| 五、状态机与流程图 | 订单状态机与成交事件的时序图 |
| 六、事件与接口定义 | WebSocket 消息类型与 REST 会话接口 |
| 七、性能指标与优化 | 延迟、并发、吞吐、内存四项目标值 |
| 八、验证清单 | 可直接当作验收用例的五条清单 |
与相邻章节的关系
相关专题