策划与数值设计
策划是游戏的"灵魂"，数值是游戏的"骨架"。服务端开发者理解策划思路和数值系统，才能设计出合理的架构、做出合理的技术决策。
参考书籍：本章核心概念参考《游戏编程模式》（Robert Nystrom）中的游戏循环与状态模式、《游戏服务器架构与优化》中的数值系统设计章节，以及《百万在线》中的经济系统平衡实践。
1. 为什么服务端需要懂策划
很多服务端开发者认为"策划的事跟我无关"，这是一种危险的误解。策划的每一个决策——经验值曲线、抽卡概率、活动时间——最终都会变成你需要处理的数据结构和计算逻辑。如果你不理解策划为什么这样设计，你就无法判断一个需求是否合理、是否存在技术风险。
举一个真实案例：某卡牌手游的数值策划设计了一个"装备强化概率递减"系统——每次强化成功率从 80% 逐级降低到 5%，但强化失败装备不消失。结果玩家发现通过反复失败+重试，可以用少量材料把装备升到满级。数值策划认为"概率已经很低了"，但服务端如果理解了概率系统的数学本质，就能提前预警：当成本期望值低于直接购买时，这个系统会变成一个变相的折扣商店。
服务端开发者需要理解策划的思维框架，才能做到：在需求评审阶段就发现技术风险，而不是在上线后被玩家利用漏洞。
1.1 策划的职责与协作
| 策划类型 | 核心工作 | 与服务端的关系 | 服务端需要关注什么 |
|---|---|---|---|
| 系统策划 | 设计游戏系统（背包、公会、邮件） | 接口设计、数据结构 | 数据模型是否可扩展、并发安全 |
| 数值策划 | 设计数值公式（伤害、属性、经济） | 计算逻辑、配置表 | 公式是否有溢出风险、配置是否可热更 |
| 关卡策划 | 设计关卡内容（副本、地图） | 关卡配置、怪物刷新 | 关卡数据量、加载策略 |
| 战斗策划 | 设计战斗系统（技能、AI、平衡） | 战斗逻辑、同步方案 | 计算量是否可控、是否需要帧同步 |
| 运营策划 | 设计活动和运营策略 | 活动系统、奖励发放 | 活动数据隔离、并发发放安全 |
关键认知：服务端不是策划的"工具人"，而是策划的"技术顾问"。当你发现一个策划方案在技术上不可行或者存在风险时，可以考虑主动提出来，而不是默默实现然后在上线后擦屁股。
2. 属性系统：数值计算的基础
属性系统是所有 RPG 类游戏的基础。理解属性计算的层次关系，对于设计合理的服务端数据结构至关重要。
2.1 属性计算的三层架构
游戏属性的计算通常分为三层，从内到外依次是：基础属性 → 百分比加成 → 固定加成。这个顺序非常重要，因为不同的计算顺序会导致完全不同的结果。
基础属性来自角色等级和成长值，是"出生就确定"的底子。百分比加成来自装备、buff、被动技能等，它放大基础属性。固定加成是最终叠加的"附加值"，比如"攻击力+50"这种。
为什么这个顺序很重要？因为它直接影响数值膨胀的速度。如果百分比加成和固定加成的顺序搞反，高等级玩家和低等级玩家的差距会被指数级放大，导致游戏平衡崩溃。《游戏服务器架构与优化》中特别强调：属性计算公式需要在服务端执行，客户端只做展示，否则就是给外挂留后门。
| 属性 | 说明 | 典型公式 |
|---|---|---|
| HP | 生存能力 | (base + growth × level) × (1 + 百分比加成) + 固定加成 |
| ATK | 伤害输出 | (base + growth × level + 装备基础) × (1 + 百分比加成) |
| DEF | 减伤能力 | 同上，影响伤害公式的减伤部分 |
| SPD | 行动顺序 | base + buff加成，通常不参与百分比计算 |
| CRIT | 暴击概率 | base + 装备加成，通常有上限（如 75%） |
2.2 为什么数值要服务端计算
一个常见的错误是让客户端计算属性值，服务端只是"记录"结果。这看起来省事，但后果很严重：
- 作弊风险：客户端可以伪造任何属性值，你无法验证
- 数据不一致：不同客户端版本可能计算结果不同
- 热更困难：修改公式需要客户端更新
合理的做法是：客户端只负责展示，服务端负责计算和验证。 客户端可以缓存计算结果用于本地显示，但所有涉及游戏逻辑的属性值需要来自服务端。
3. 伤害公式：策划设计的核心
伤害公式决定了战斗系统的手感和平衡性。不同游戏类型使用完全不同的伤害模型，理解这些模型有助于你设计合理的战斗服务。
3.1 四种主流伤害模型
模型一：简单减伤（适合休闲游戏）。伤害 = 攻击力 - 防御/2，最低为 1。优点是简单直观，缺点是防御力的收益是线性的，高等级时防御力要么完全没用（攻击力远大于防御），要么过于强大（防御接近攻击力的两倍）。
模型二：百分比减伤（适合卡牌游戏）。伤害 = 攻击力 × (1 - 防御/(防御+K))。这里的 K 是一个常数，决定了防御力的"饱和点"。当防御力等于 K 时，减伤 50%。这个模型让防御力的收益递减，更合理。
模型三：乘算减伤（适合 MMO）。在百分比减伤的基础上叠加多个减伤来源（装备减伤、buff 减伤、被动减伤），用乘法而非加法合并，避免减伤率超过 100%。
模型四：最终伤害 = 基础伤害 × 暴击 × 技能倍率 × 随机浮动。这是大多数商业游戏使用的模型，各个乘区独立计算，策划可以精确控制每个乘区的权重。
伤害计算流水线：
攻击力 × 技能倍率 → 基础伤害
↓
基础伤害 × (1 - 防御减伤率) → 减伤后伤害
↓
减伤后伤害 × 暴击倍率 → 暴击后伤害
↓
暴击后伤害 × (1 ± 随机浮动) → 最终伤害3.2 伤害公式的服务端实现要点
伤害计算看似简单，但在服务端实现时有几个需要注意的坑：
浮点精度问题：不要用浮点数做最终的伤害值。浮点运算有精度误差，可能导致"1点伤害"和"0点伤害"的判定出错。实践中发现全程用整数运算（比如伤害值乘以 1000 存储，展示时除以 1000）。
随机数种子：服务端需要使用确定性随机数，否则帧同步模式下不同客户端的战斗结果会不一致。
伤害溢出：如果攻击力和技能倍率都很高，乘积可能超过 int32 的范围。使用 int64 或在计算前检查溢出。
伤害封顶：策划通常会要求"单次伤害不超过最大生命值的 X%"，这个限制需要在服务端实现。
4. 经济系统：游戏的命脉
经济系统决定了游戏的长期生命力。一个设计良好的经济系统可以让游戏运营数年，而一个糟糕的经济系统可能在几个月内就让游戏崩溃。
4.1 货币体系设计原则
游戏货币体系通常呈金字塔结构：顶层是付费货币（钻石），中层是游戏货币（金币），底层是活动货币（代币）。设计原则是：
- 货币种类不超过 3-4 种：太多会让玩家困惑，太少会限制设计空间
- 每种货币有明确的产出/消耗场景：不能让一种货币"万能"
- 付费货币和游戏货币不能逆向转换：否则会影响付费意愿
4.2 产出-消耗平衡的数学模型
经济平衡的核心公式是：每日净流量 = 总产出 - 总消耗。这个值应该略大于零（让玩家有"赚到了"的感觉），但不能太大（否则通胀），也不能小于零（否则通缩，玩家觉得"越玩越穷"）。
一个简单的监控模型是检查每种货币的"消耗/产出比"：这个值在 0.8 到 1.2 之间是健康的。低于 0.8 意味着产出过剩（通胀风险），高于 1.2 意味着消耗不足（玩家囤积，后续释放会造成冲击）。
4.3 通胀控制的四种武器
| 控制手段 | 原理 | 适用场景 | 副作用 |
|---|---|---|---|
| 产出控制 | 每日产出上限 | 所有游戏 | 影响玩家体验 |
| 消耗设计 | 装备强化递增消耗 | RPG/MMO | 新手门槛高 |
| 回收机制 | 装备分解、道具回收 | 有装备系统的游戏 | 需要设计回收价值 |
| 价值锚定 | 关键道具固定价格 | 有交易所的游戏 | 限制自由度 |
真实案例：某 MMO 上线半年后，金币通胀达到 300%，一把普通武器的价格从 1000 金币涨到了 30000 金币。原因是策划设计了太多金币产出途径（日常、副本、活动），但消耗途径只有装备强化（而且强化到高等级后消耗增长不够快）。最终的解决方案是引入"金币税"——交易时收取 10% 的手续费，同时开放"金币兑换材料"的限时活动。这个案例说明：经济系统需要在上线前就做好数学模型验证，不能等到出了问题再修。
5. 概率系统：玩家最敏感的领域
概率系统是游戏中最容易引发玩家投诉的领域。中国法律规定抽卡概率需要公示，服务端的实现需要经得起审计。
5.1 概率的类型与心理效应
| 概率类型 | 说明 | 心理效应 | 典型应用 |
|---|---|---|---|
| 固定概率 | 每次概率相同 | 期望值明确 | 抽卡 1% 出 SSR |
| 保底概率 | 达到阈值必出 | 降低挫败感 | 90 抽保底 |
| 动态概率 | 概率随次数变化 | 越抽越兴奋 | 软保底机制 |
| 条件概率 | 满足条件才触发 | 增加策略性 | 暴击、连击 |
5.2 保底机制的设计与实现
保底机制是现代抽卡游戏的标配。它的核心思想是：给玩家一个"最坏情况"的预期，降低随机性带来的挫败感。
保底机制有两种：硬保底（达到次数必出）和软保底（达到次数后概率大幅提升）。软保底通常从第 75 抽开始，每抽增加 6% 的概率，到第 90 抽时概率接近 100%。这种设计比纯硬保底更"丝滑"——大部分玩家在 75-85 抽之间就能出，但极少数运气差的玩家也能在 90 抽保底。
服务端实现的关键：保底计数器需要存储在服务端数据库中，不能信任客户端。客户端发送"我抽了多少次"是不可信的——外挂可以伪造这个数字来"跳过"保底计数。
5.3 概率公示的法律要求
根据中国《网络游戏管理暂行办法》和《关于规范网络游戏运营加强事中事后监管工作的通知》，抽卡概率需要公示：
- 每个品级的基础概率
- 保底机制的详细说明
- 概率提升活动的额外概率
- 概率计算的随机种子说明（可选）
服务端需要做到：概率计算在服务端完成，概率结果有日志记录可追溯，保底计数准确且不可被刷。
6. 掉落系统：随机性的艺术
掉落系统是概率系统的具体应用。一个好的掉落系统应该让玩家觉得"努力就有回报"，而不是"纯看运气"。
6.1 掉落类型的选择
| 掉落类型 | 说明 | 适用场景 | 玩家心理 |
|---|---|---|---|
| 固定掉落 | 必定掉落 | 金币、经验 | 稳定感 |
| 随机掉落 | 概率掉落 | 装备、材料 | 期待感 |
| 首通奖励 | 首次通关额外 | 稀有道具 | 成就感 |
| 保底掉落 | N次必出 | 稀有装备 | 安全感 |
6.2 权重掉落的设计
权重掉落是最常见的随机掉落实现方式。每种物品有一个"权重"值，权重越大越容易掉落。计算方式是：物品掉落率 = 该物品权重 / 所有权重之和。
这种设计的优点是策划可以直观地调整概率——把某个物品的权重从 100 改成 50，它的掉落率就减半。但要注意一个陷阱：当物品数量很多时，稀有物品的权重会被大量普通物品"稀释"。如果策划想让 SSR 的概率保持在 1%，但又添加了大量新的 R 级物品，SSR 的实际概率会低于 1%。这需要一个自动化检查工具来监控。
7. 玩家心理学：设计的底层逻辑
理解玩家心理学不是策划的专利，服务端开发者也需要理解——因为你需要实现这些心理机制对应的技术系统。
7.1 自我决定理论（SDT）
SDT 理论认为人类有三种基本心理需求：自主性（自由选择）、胜任感（掌控感）、归属感（社交连接）。好的游戏设计会同时满足这三种需求。
对应到服务端：自主性需要提供多种玩法入口和自由度；胜任感需要难度匹配系统和成长系统；归属感需要公会、组队、聊天等社交系统。
7.2 变比率强化：最强的成瘾机制
变比率强化（Variable Ratio Reinforcement）是心理学中最强大的成瘾机制——奖励的出现是随机的，但长期来看有稳定的期望值。这就是赌博让人上瘾的原理。
在游戏中的应用：抽卡（随机 SSR）、怪物掉落（随机装备）、宝箱（随机奖励）。服务端实现时需要注意：概率需要服务端计算，保底机制需要准确，概率需要公示。这不仅是技术要求，也是法律要求。
7.3 损失厌恶：让人"不敢走"的设计
损失厌恶是指：失去 100 元的痛苦 > 得到 100 元的快乐。游戏利用这一点设计了大量"限时"和"每日"机制：
- 限时活动："错过就没了"的紧迫感
- 每日签到："断签损失"的恐惧
- 体力系统："不用就浪费"的心理
服务端需要实现的对应系统：活动倒计时、签到记录与补签机制、体力恢复与溢出处理。这些系统的共同特点是时间敏感——服务端需要精确记录时间，处理时区差异，防止客户端篡改时间。
8. 版本更新对经济系统的冲击
每次版本更新都是一次经济体系的"地震"。新玩法、新道具、新活动都会打破原有的产出-消耗平衡。服务端需要提前做好预案。
8.1 经济影响评估
版本更新前，应该做一次经济影响评估：新增了多少产出途径？新增了多少消耗途径？预计通胀变化百分比是多少？哪些道具会受到冲击？
一个简单的评估模型是：净流量变化 = 新增日产出 - 新增日消耗。如果净流量变化导致通胀率超过 15%，就需要调整方案。
8.2 经济失衡的修复工具箱
| 失衡程度 | 修复策略 | 执行速度 | 副作用 |
|---|---|---|---|
| 轻微（通胀<10%） | 微调产出/消耗参数 | 快（热更新） | 低 |
| 中等（通胀10-30%） | 新增消耗途径+降低产出 | 中（版本更新） | 中 |
| 严重（通胀>30%） | 紧急回收+市场干预 | 慢（需多版本） | 高 |
| 崩溃（恶性通胀） | 货币改版/合服 | 极慢 | 极高 |
9. 链游经济设计的特殊挑战
链游（GameFi）将游戏经济搬到区块链上，带来了全新的设计挑战。传统游戏的经济系统是中心化控制的，服务端可以随时调整参数；但链游的经济规则写在智能合约里，一旦部署就很难修改。
9.1 双代币模型
链游通常使用双代币模型：游戏内代币（中心化管理，用于游戏内消耗）和治理代币（去中心化，用于交易和治理）。这种设计的目的是将"游戏内经济"和"链上经济"解耦，降低游戏内经济波动对链上价格的影响。
9.2 死亡螺旋：链游的最大风险
死亡螺旋是链游最可怕的噩梦：新玩家减少 → Token 价格下跌 → 老玩家抛售 → 价格进一步下跌 → 更多玩家离开 → 经济崩盘。
Axie Infinity 就是死亡螺旋的典型案例：SLP 代币从最高 $0.36 跌到几乎归零。根本原因是产出远大于消耗——玩家不断产出 SLP，但游戏内没有足够的消耗途径。
预防死亡螺旋的关键：设计多元化的消耗途径、设置产出上限、建立回购机制、控制新玩家增长节奏。但最根本的是：游戏需要有"可玩性"作为基础，而不能纯粹靠"赚钱"吸引玩家。
10. 服务端开发 Checklist
接到策划需求时，先问这 10 个问题：
□ 1. 这个系统的状态需要持久化吗？
□ 2. 这个操作需要事务保证吗？
□ 3. 这个计算应该在客户端还是服务端？
□ 4. 这个功能的并发安全性如何？
□ 5. 这个系统的性能瓶颈在哪里？
□ 6. 这个功能需要跨服支持吗？
□ 7. 这个功能的反作弊策略是什么？
□ 8. 这个功能的数据量预估是多少？
□ 9. 这个功能的上线/下线方案是什么？
□ 10. 这个功能需要灰度发布吗？下一步
- 理解伤害公式和属性系统的设计逻辑
- 掌握概率系统和保底机制的实现要点
- 理解经济系统的产出-消耗平衡模型
- 学习玩家心理学在技术系统中的应用
- 了解链游经济的特殊挑战和风险