164 lines
12 KiB
Markdown
164 lines
12 KiB
Markdown
|
||
|
||
# 《"36字花" 数字竞猜游戏功能需求与详细流程规格说明书 (PRD)》
|
||
|
||
**文档版本**：V 1.0 (最终定稿版)
|
||
**项目定位**：高频（30秒/期）、高爆率、多国本地化数字竞猜平台
|
||
|
||
## 一、 系统全局架构与底层规范
|
||
|
||
### 1.1 多币种与游戏币体系（统一结算层）
|
||
为支持多国市场无缝拓展，系统底层不直接使用法币（如 RM、IDR）进行业务流转：
|
||
* **充值兑换**：用户使用本地法币充值，资金到账后，系统根据实时/固定汇率自动转化为平台统一的**游戏币（Coins/Credits）**。
|
||
* **前端展示**：所有下注、余额、开奖金额均显示为统一的“游戏币图标 + 数值”（如 💎 100）。
|
||
* **提现结汇**：提现时，系统将游戏币按提现国的当前汇率反向换算为本地法币打款。
|
||
* **技术优势**：代理分佣、AI算票引擎完全剥离汇率波动，仅对游戏币进行纯数学计算，极大降低系统复杂度。
|
||
|
||
### 1.2 分布式站点架构
|
||
系统拆分为三个独立的前端与一个核心后端服务：
|
||
1. **用户前端 (User Portal)**：H5/Web响应式，面向玩家游玩。
|
||
2. **代理后台 (Agent Portal)**：面向总代理/子代理的数据与分佣端。
|
||
3. **总控后台 (Admin Portal)**：面向平台运营方的全局管控端。
|
||
|
||
### 1.3 域名与防封安全架构
|
||
* 采用 **方案A（反向代理 + CDN 隐藏源站） + 方案D（域名轮换池 Domain Pool）** 的组合方案。确保源站IP完全隐藏，入口域名被封时可秒级切换备用域名。
|
||
|
||
---
|
||
|
||
## 二、 核心玩法与游戏机制
|
||
|
||
### 2.1 36字花字典对照表
|
||
系统包含36个字号，分为生肖、猛兽、飞禽、虫蛇、神兽五大类。前端需展示“编号+名称+专属插画”。
|
||
|
||
| 编号 | 名称 | 编号 | 名称 | 编号 | 名称 |
|
||
| :---: | :---: | :---: | :---: | :---: | :---: |
|
||
| 01 | 鼠 | 02 | 牛 | 03 | 虎 |
|
||
| 04 | 兔 | 05 | 龙 | 06 | 蛇 |
|
||
| 07 | 马 | 08 | 羊 | 09 | 猴 |
|
||
| 10 | 鸡 | 11 | 狗 | 12 | 猪 |
|
||
| 13 | 狮 | 14 | 象 | 15 | 鹿 |
|
||
| 16 | 熊 | 17 | 狼 | 18 | 豹 |
|
||
| 19 | 鹰 | 20 | 鹤 | 21 | 孔雀 |
|
||
| 22 | 鸳鸯 | 23 | 鸵鸟 | 24 | 天鹅 |
|
||
| 25 | 蟾蜍 | 26 | 蜘蛛 | 27 | 蝙蝠 |
|
||
| 28 | 蜈蚣 | 29 | 蝎 | 30 | 蛇蜥 |
|
||
| 31 | 麒麟 | 32 | 凤凰 | 33 | 青龙 |
|
||
| 34 | 白虎 | 35 | 朱雀 | 36 | 玄武 |
|
||
|
||
其中 01-12 为十二生肖，13-18 为猛兽类，19-24 为飞禽类，25-30 为虫蛇类，31-36 为神兽类。
|
||
|
||
### 2.2 游戏节奏（30秒循环制）
|
||
每局精确耗时30秒，分为两个绝对阶段：
|
||
|
||
* **【常态阶段 / 下注期】 (0-20秒)**
|
||
* 倒计时 20 秒启动，接收玩家下注。
|
||
* **UI表现**：前端界面的 36 个格子上的高亮光圈，呈现**持续不断、不规则、快速的随机跳动**，营造强烈的赌场氛围。
|
||
* **【封盘开奖期】 (20-30秒)**
|
||
* **第 20.0 秒**：准时锁盘。在此之后到达服务器的任何延迟请求（如因网络卡顿），直接**拒单退回（提示：已封盘，下注失败）**。
|
||
* **第 20-22 秒（AI算票）**：AI 引擎瞬间完成全网盈亏计算并得出结果。
|
||
* **第 22-25 秒（开奖动画与异步派彩）**：后端在第 22.0 秒得出结果后，立刻将派彩结算指令打入 MQ 异步执行。同时前端高亮光圈加速跳动，配合紧张心跳音效。在3秒内不规则快速跳动后，“啪”地一声**定格**在最终中奖号码上。
|
||
* **第 25-30 秒（结算展示）**：前端通过轮询/推送接收到余额更新通知，开始播放中奖者全屏/半屏的**金币喷洒动画（伴随爆金音效）**，弹出醒目提示【恭喜获得 💎 XXX】。
|
||
|
||
### 2.3 下注交互与限制
|
||
* **便捷筹码**：提供 💎1, 5, 10, 25, 50, 100 的快捷筹码按钮。
|
||
* **下注限制**：默认每场最多选 **5个数字**（后台可配）。单局内所选的每个数字，下注金额必须一致。
|
||
* **单注上限**：后台须配置“单号最高下注额（Max Bet Limit）”（如 💎500），以对冲超级连赢带来的数学风险。
|
||
* **快捷操作**：
|
||
* **重复上一注 (Re-bet)**：一键复制上一局的选号和金额并提交。
|
||
* **自动托管 (Auto-Spin)**：允许设定连续下注 N 局。采用**服务端执行、逐局扣款**机制。开启后，服务器将在每局的 **00:00 - 00:10 秒之间（引入随机抖动，防止并发风暴）**平滑地为所有托管玩家自动扣款下注，直至局数完成或余额不足。
|
||
|
||
---
|
||
|
||
## 三、 连续中奖 (Streak Bonus) & 大奖 (Jackpot) 规则
|
||
|
||
### 3.1 赔率累加机制
|
||
* 基础赔率为 **1:33**。
|
||
* 玩家连续中奖时，赔率累加：第1场 1:33；连中2场 1:66；连中3场 1:99... 依此类推。
|
||
* 只要某场未中奖（中断），连续记录清零，赔率重置为 1:33。
|
||
* **【跳局处理规则】**：出于提高活跃度和平台流水考虑，**连胜必须基于系统的“连续期号”判断**。若玩家在连胜期间，主动跳过了某一局（未下注），则连胜状态**直接强制清零**。
|
||
|
||
### 3.2 连赢期间的“换注限制”
|
||
为了防止玩家利用连赢的高赔率恶意“洗盘梭哈”：
|
||
* **下注金额锁定**：若第 N 轮中奖，则第 N+1 轮的**总下注金额上限**严格锁定为第 N 轮的实际总下注额。（如：上轮总共下了💎100，本轮最多只能下💎100；若本轮只下了💎10并中奖，下一轮上限将降为💎10）。
|
||
* **选号策略自由**：在总金额不超限的前提下，**允许玩家改变选字的数量**。例如：上一轮花💎100买了5个字，本轮可以花💎100全押在1个字上。
|
||
|
||
### 3.3 Jackpot 百万大奖触发
|
||
* 当玩家连续中奖达到 **10 场** 时触发。
|
||
* **触发门槛与限红**：为防止利用极小注额套取大奖，系统设定【Jackpot资格最小下注额】（如单注连续 ≥ 💎50）。若连胜中有任何一局未达大奖基准入场额，连胜仅享受常规多倍赔率，**不触发额外 Jackpot 大奖**。
|
||
* **派发逻辑（额外叠加）**：达标玩家正常获得第10场应得的常规连赢派彩，系统将在此基础上，**额外发放 Jackpot 大奖（如 💎100万）**。
|
||
* 触发后，连续中奖场次重置为0。
|
||
|
||
---
|
||
|
||
## 四、 AI算票风控与开奖系统
|
||
|
||
### 4.1 自动开奖引擎（利润最大化 + 随机放水）
|
||
* **第一优先级**：AI在封盘后遍历36个数字的全局赔付（包含当前所有人的连胜倍率计算），优先开出让平台**总赔付最少（利润最大）**的数字。
|
||
* **RTP 全局风控放水池**：
|
||
* 系统累积平台抽水利润的固定比例进入“放水池”。
|
||
* 当开出某个高赔付（如触发别人连胜或大奖）造成的亏损 **小于** 当前放水池余额时，AI 有一定概率（后台可配，如15%）主动开出该数字，制造真实大奖作为营销案例。
|
||
|
||
### 4.2 手动开奖机制
|
||
* 管理员在后台一键切换至“手动模式”。
|
||
* 为了避免 10 秒开奖期的操作延误，管理员必须在**下注倒计时期间（前20秒内）**提前选定本局必开数字。20秒锁盘后，系统直接开出预设号码。
|
||
|
||
### 4.3 灾难恢复 (Disaster Recovery)
|
||
* 若系统在某局运行中途（如第25秒）遭遇断电或宕机崩溃。
|
||
* 服务器重启后的首要动作是自动执行 **“作废退本 (Void & Refund)”** 脚本：该期残局作废，退回所有玩家本局投注的本金，杜绝暗箱操作嫌疑。
|
||
|
||
---
|
||
|
||
## 五、 代理体系：普通刷水代理与联营合营代理双轨制 (Agent & Affiliate System)
|
||
|
||
为了适应不同渠道的推广需求，系统代理账号不开放前台自助注册（必须由后台人工创建或通过专属代理邀请码裂变），并支持**两条平行的代理分佣路线**：
|
||
|
||
### 5.1 普通刷水代理（以流水分桶为导向）
|
||
这是一种不承担玩家赢钱风险的基础代理模式。
|
||
1. **大盘盈亏判断**：周期结算时，优先计算全平台总盈亏。若全平台整体亏损或平局，则该周期内所有此类代理不分佣。
|
||
2. **计算流水占比**：若全平台盈利，则按某代理整条线下注流水占全平台总流水的百分比，分配资金池。（*应分红 = 平台总盈利 × 该线下注流水占比%*）。
|
||
3. **无负结转优势**：即便该代理名下的玩家赢了钱，只要全平台大盘是盈利的，其依然可按流水占比分佣。
|
||
|
||
### 5.2 多级拨比机制
|
||
在上述“分桶利润分配”算法中，系统支持无限线代理树的极差分账。例如：GM 给出的盘口总分红给到顶部总代的是 80%，当这个总代拿手上的分红比例拨给下级时，若他给 70%，则这位下级能拿单线利润基数的 70%，总代由于极差卡段，自己这条线只能拿到 10%（80%-70%）的差额利润。这个级差裂变能一直往下分直到没有 % 为止。
|
||
|
||
### 5.3 联营代理模式 (Affiliate Agent / 客损占成分成)
|
||
这是专为有强大客源且愿意与平台**“共担风险、共享高利润”**的高级代理设计的模式（即行业标准的**联营 / 占成代理**）。
|
||
* **角色定位**：联营代理脱离于普通流水池，直接对其名下所有会员的总客损（净输赢）负责。
|
||
* **净亏损分润**：结算时，系统统计该联营代理辖区内的【玩家总输赢】，扣除平台抽水与通道费后得出【净客损】。联营代理按配置的**占成比例**（如 50%）直接分走这笔客损。
|
||
* **负结转 (Negative Carryover)**：这是联营核心机制。如果该联营代理名下的玩家在当期大赢，导致结算时客损为负（代理亏钱），该亏损数字将“结转”至该代理的下期账单中。在后续周期里，必须先用玩家的输额填平该负结转账单后，代理才能恢复分红提现。
|
||
|
||
---
|
||
|
||
## 六、 用户与财务风控流程
|
||
|
||
### 6.1 用户交互与注册
|
||
* 只需手机号/邮箱+密码注册，**无需 KYC 实名认证**。
|
||
* **路子图 (走势图)**：前端界面底部提供类似百家乐大路/珠盘路的走势图。以数字区分：单数使用**红色图标**（Odd），双数使用**蓝色图标**（Even），仅保留最近30期。
|
||
|
||
### 6.2 平台公告与运营触达流程
|
||
为保证由于赔率调整、节日活动或临时维护等重要信息能 100% 触达玩家，前端具备两级触达机制：
|
||
* **静默收件箱 (Silent Mailbox)**：常规活动或系统通知直接派发至用户的【公告信箱/站内信】，UI 仅显示红点提示，不中断玩家游戏体验。
|
||
* **强阻断强制公告 (Pop-out Notification)**：具有最高优先级。运营在后台下发此级公告后，无论玩家在任何界面、或者新用户首次登录，系统立即在屏幕中央弹出该公告弹窗。玩家**必须手动勾选“已阅读并同意”**后才可关闭弹窗并继续游戏下注。
|
||
|
||
### 6.3 财务风控与提现
|
||
* **提现门槛**：用户必须完成历史总充值额 **1倍流水** 的有效下注方可提现，防止恶意洗钱。
|
||
* **提现限制**：最低提现 💎100，系统自动扣除 0.5% 手续费。
|
||
* **人工审核强阻断**：任何触发 **100万 Jackpot** 或达到系统设定的超大额提现标准的资金，不会直接进入可用余额，而是进入“冻结/审核中”状态。必须由总后台管理员核查 IP 与下注流水，点击【通过】后方可打款。
|
||
|
||
### 6.4 历史数据展示限制
|
||
* 前端的下注记录、开奖记录仅展示**最近 1 个月**的数据。
|
||
* 历史更久远的数据前端做隐藏处理，减少数据库连表查询压力。
|
||
|
||
---
|
||
|
||
## 七、 技术性能要求规范
|
||
|
||
由于“30秒/期”属超高频高并发场景，系统架构必须满足以下规范：
|
||
|
||
1. **冷热数据分离架构**：
|
||
* 必须引入 **Redis** 内存数据库，用于存放最新30期开奖记录、当前进行中的下注队列、以及玩家当前的连赢（Streak）状态。确保 AI 引擎 2 秒内完成算票。
|
||
* 引入 **ElasticSearch 或 ClickHouse** 存储海量历史注单与资金流水，与交易主库隔离开来。
|
||
2. **异步派彩机制**：
|
||
* 开奖后的批量资金入账、连胜进度更新、以及站内信发送，必须采用 **消息队列 (Kafka / RabbitMQ)** 异步削峰处理。严禁在 10 秒结算期内使用数据库同步强锁表，防止并发雪崩。
|
||
3. **API 频控 (Rate Limiting)**：
|
||
* 用户端及代理端所有核心 API（如下注、提现申请）必须配置严格的频率限制，防止恶意脚本撞库或刷单。 |