• 该项目的代码已开源，可在 GitHub 与 GitCode 上获取。
  • 📌 这篇文章对应代码分支：origin/feature/blind-reward-money
  • ⚠️ 注意：由于项目持续迭代。当前仓库代码可能已发生变化，这篇文章内容基于该分支版本说明一下。怎么说呢，

✅ 本篇实现了什么

前面的几篇主线里我一直在处理：出牌、算分、Blind 推进、Boss 规则。

但当 Blind 生命周期跑通以后我发现项目里始终缺少一个东西：

痛点1：奖励不透明。让玩家和前端团队都不知道具体收益来源，导致 UI 展示与后端逻辑脱节。

一、为什么第三阶段不再先做持久化

痛点2：过早引入数据库会让业务流程变得臃肿，导致开发者无法快速验证玩法循环。

• 第二阶段正式结束，第三阶段现在开始🎉。
• 但是在项目最初计划的时候，第三阶段预期是“持久化与缓存分层”。但当项目继续进行到了第三阶段的时候，我发现这里需要推翻一下曾经的规划。老实说，

为什么暂时不做持久化

痛点3：缺乏足够的根据数据调整决策。没有必要立即投入复杂技术栈。

• 因为当前的项目正处于：
• 现在确实已经有了 GameState。也有了 PlayerState,... 等状态.
• 如果这个时候直接进入 Redis/MySQL，不是不能做，但多少会有一点“为了推进阶段而推进阶段”的感觉。
• 不是 Redis/MySQL 不关键，而是现在还没有足够值得持久化的数据。

第三阶段真正要补的中间层

• 痛点4：缺乏明确的奖励→商店→构筑链路，使得后续功能难以拆解和复用。
• 目标是让玩家从“打过一关”变成“每一关之后都能变强”。其实，
• 从把流程拆成来看。

  B
  B --> C
  B --> D
  D --> E
  E --> F
  F --> G
  G --> H
  C -. 第三阶段不再直接跳过成长链路 .-> D
  style C fill:#f5f5f5
  style D fill:#fff7e6
  style E fill:#fff7e6
  style F fill:#fff7e6
  style G fill:#fff7e6
  "
  />

• 于是本阶段方向调整为"🎯 奖励、商店与构筑成长程序".
• 原计划中的“持久化与缓存分层”将延迟到第四阶段再处理。

痛点这方面，

• - 没有完整奖‑商‑构链条导致功能集成困难。
• - 持久化时间节点错误导致资源浪费。
• - 前后端数据同步难度大。

.

二、为什么先从 money 开始

痛点5：金币往往被误认为单纯数值，却忽略其对整个成长程序的关键性。者常因缺少清晰入口而把金钱写死在某个模块中。

This section introduces money as a core entry point for growth systems.

• 添加 PlayerState.money 字段 在 blind 通过后累加基础奖励+剩余出牌+利息 把它单独拆出来方便后续

money 属于 PlayerState

本次奖励明细不属于常驻状态 

使用 settlement.reward 承载本次奖励 明细 


基础奖励
剩余手牌奖励
利息
本次总奖金
奖励后的金币数量

​
​
​

此拆分使得后续 Tag/Joker/Voucher 等经济效果可以继续追加到 RewardMoneyDetail，而不是塞进顶层结构里。
​


三、为什么暂时不单独设计 “提取奖励” 接口
**痛点6**：早期引入 claimReward 接口容易产生无用接口和状态复杂度。


在游戏流程中 Blind 胜利后会先进入金币结算页面接下来才是 “提取$”，这只是 UI 上的一步确认。

当前后端尚未完成 reward → shop → next blind 的完整流转，如果此时增加 claimReward 会提前带来重复领取校验等额外逻辑。

为避免无意义接口和状态复杂度。本篇采用简化设计——当 selectCards 判断并更新 playerState.money，同时返回 settlement.reward。


简化设计示例

ts
// 当 Blind 胜利时：
const detail = calculateBlindRewardDetail;playerState.money += detail.currentBlindRewardMoney;progress.settlement = { /* ... */,reward: detail };

这样前端仍可根据 settlement.reward 得到所有明细，而后台无需额外接口。按理说，


四、玩家金币状态应该放在哪里

Money 属于 PlayerState


总金币不是一次性产物。而是持续累积资产，

将其保存在 PlayerState 中方便以后商城购买、刷新、Joker 使用等地方读取。


本次奖励明细属于 Settlement Event


progress.settlement.reward 用来返回一次性获奖信息。


两者生命周期不同，避免数据混乱。




数据
所属位置
生命周期
作用




playerState.money
PlayerState
整局游戏
长期资源


settlement.reward.baseMoney
Settlement
当前 Blind
基础奖励


settlement.reward.remainingHandBonusMoney
Settlement
当前 Blind
剩余手牌收益


settlement.reward.interestMoney
Settlement
当前 Blind
利息收益


settlement.reward.currentBlindRewardMoney
Settlement
当前 Blind
本次总奖金


settlement.reward.moneyAfterReward
Settlement
当前 Blind
奖励后的总金币





五、金币奖励规则应该如何配置

baseRewardMoney 放在 blind.config.ts

ts
export const BLIND_SCORE_CONFIG = {
说到small。{score:,baseRewardMoney:}
从big来看，{score:,baseRewardMoney:}
再看boss，{score:,baseRewardMoney:}
};

通用经济规则放在 economy.config.ts

ts
export const ECONOMYRULE = { INITIALMONEY:} as const;说起来，

export const BLINDREWARDRULE = {
REMAININGPLAYBONUS_MONEY:。} as const，

export const INTERESTRULE = {
MONEYPERINTEREST:。MAXINTEREST:,} as const;

再看这样职责清晰，


blind.config.ts - 每个 blind 的基础配置；

economy.config.ts - 全局经济规则。



六、Blind 奖励明细与结算流程设计

RewardMoneyDetail 定义

ts
export type RewardMoneyDetail = {
baseMoney:number;// 基础奖励
remainingHandBonusMoney:number;// 剩余手牌收益
interestMoney:number;// 利息收益
currentBlindRewardMoney:number;// 本次总奖金
moneyAfterReward:number;// 奖励后的总金币量
};

奖励计算逻辑

ts
private calculateBlindRewardDetail(blindState:any,playerState:any): RewardMoneyDetail {
const blindType = blindState.blindType;按理说，const playsLeft = playerState.playsLeft;
const baseCoin =
blindConfig.baseRewardMoney;const handBonus =
playsLeft * BLIND_REWARD_RULE.REMAINING_PLAY_BONUS_MONEY;话说回来，const interest =
Math.min(
Math.floor。INTEREST_RULE.MAX_INTEREST);const total =
baseCoin + handBonus + interest;return {
baseMoney : baseCoin,remainingHandBonusMoney : handBonus,interestMoney : interest。currentBlindRewardMoney : total,moneyAfterReward :
playerState.money + total,};

}


流程图

mermaid flowchart LR
A
B
C{是否结束}
D{结果}
E{Win?}
F
G
H
A-->B-->C-->|否|D-->E-->|Lose|H---|
C-->|是|E-->|Win|F-->G-->H-->|返回成功|


利息按结算前 money 计 —— 因为利息更像已有资产产生收益，而非新获奖金再产生收益。


七、本篇实现后的流程变化

之前这方面，

mermaid flowchart LR A --> B


至于现在。

mermaid flowchart LR A -->
B -->
C -->
D -->
E


这一步不仅完成加钱，更开启了玩家可持续成长的新资源池，为商店/构筑等功能铺路。


八、 & 接下来计划

已完成内容


新增 .money;

配置文件拆分;

完整 Reward Money Detail 与返还机制；

更新流程加入奖赏结算节点。


关键设计思路


长期 vs 短期区分 — 玩家整体资产 vs 单局结算结果；

细粒度明细 — 防止 UI 难以展示来源；

延迟接口 — 避免无用接口带来的额外复杂度；

职责拆分 — 配置文件按用途划分。


接下来工作


引入商城/刷卡程序，让玩家花钱消耗 coins；

加入 Joker/Tag/Voucher 等
经济模型；

对接存储层，实现使用者金钱持久化与缓存调整。


`