research(hunt-sim): 10 人并发在线模拟×多 agent 设计迭代——研究设施与全套档案
研究命题（00-plan）：验证并打磨《围猎》联机纯音频体验——不是逻辑能跑通， 而是真人玩起来是什么体验、愿不愿意再来一局。 设施 web/harness/hunt-sim/（可复用，零依赖）： - arena.mjs 编排器：起真实服务器（随机端口+临时数据目录隔离），10 个拟人客户端 经真实 WS 同时在线，错峰组队、真实时长对局、局间状态跨轮维护 - sim-client.mjs：game.js 行为移植（协议+手势路由+R1-R8 音频调度逐字节对齐）， 产出「玩家耳朵听到什么」的感知时间线（语音全文/loop 方位音量档/喊话/震动） - brain.mjs：人设大脑——察觉延迟/前后判读（以真值为条件的正确率模型）/掩蔽放大/ 冷却乱滑/技能囤积/呼喊倾向/分心断网，全部随机判定用按实体 id 哈希的独立抽签 （mulberry32 流会被刷怪座位轮转结构带偏，实测造成系统性镜像反转，已证伪） - recorder.mjs：每人每局 events.jsonl 全量 + percept.md 感知转写 + 对局速览 研究档案 research/hunt-sim/： - players/：10 人配置（LLM 亲笔）+策略自述+逐局去留决策+人设终评+退游者重访 - rounds/：v1 三轮（R0 教学+R1/R2 真人快速）+ v2 复测两轮，共 48 局全记录 - analysis/01-04：数值曲线/音频信息设计/协作社交/上手留存四视角报告 - synthesis.md（S1-S9 裁定）、metrics.md/metrics-v2.md（两版对比总账）、report.md（总报告） v1 核心发现：10 人 3 轮 28 局 100% 胜率 26S/营地零损耗；击杀垄断（专家单人 30/39）； 呼喊 3 次/28 局应答 0；N/S 前后判读仅 63/69% 可命中；四种退游死因 （失衡/社交真空/交互摩擦/观光无聊）→ 详见 report.md
This commit is contained in:
@@ -0,0 +1,340 @@
|
||||
# 01 · 数值与公平性分析（Q1 难度曲线 / Q7 天花板）
|
||||
|
||||
> 分析视角：数值曲线 + 击杀经济 + 评级 + 匹配公平。数据源：28 局对局档案
|
||||
> （`rounds/*/matches/room-*.match.json`）、`metrics.md`、`players/P01|P05|P07.review.md`、
|
||||
> 对照基准 `web/server/test/hunt-balance-scan.mjs`（本次实跑 24 seeds，输出见 §0）。
|
||||
> 代码口径：`web/server/hunt-room.js`（WAVE_TABLE / BOT_TUNING_DEFAULT / gradeFor /
|
||||
> ATTACK_CD_MS / MELEE_ETA / LAYOUTS）、`web/hunt/game.js`（killBandId / 进度 best）。
|
||||
|
||||
## 0. 对照基准实跑（2026-09-18，默认参数）
|
||||
|
||||
```
|
||||
[idle 真人挂机，2 bot 独守] 胜 18/24，mean dur 3.3（负/≤3 命中 17/24；A1 B6 C11）
|
||||
[bot 3 bot 水准局] 胜 24/24，mean dur 7.5（6-9 命中 17/24；S8 A10 B5 C1）
|
||||
[optimal 人类上限参考] 胜 24/24，dur=10 ×23 / 9 ×1 → S×24
|
||||
```
|
||||
|
||||
**关键读数**：扫描的三档全部是 **1 真人 + 2 bot（3 座单人房）**；不存在 4 人档、
|
||||
不存在混合水平档。而实测翻车的恰是 3-4 真人房。**扫描口径本身是本次失衡的盲区**
|
||||
（详见发现 1.4）。
|
||||
|
||||
另一处账目勘误：`metrics.md` 称"6 局真人快速局"，房间档案实为 **5 房 / 18 人次**
|
||||
（R1: JBP5/NTGV/P5CA = 4+4+2 人；R2: 3TJY/94FQ = 4+4 人）。「快速局零损耗」结论本身成立。
|
||||
|
||||
---
|
||||
|
||||
## 1. 发现一：难度曲线失效——根因是「波次输出被团队吞吐淹没」，不是 bot 强度
|
||||
|
||||
### 1.1 现象（数据）
|
||||
|
||||
- 28 局 28 胜（胜率 100%），评级 **S×26 / A×1 / B×1 / C×0**（`metrics.md` 总账）。
|
||||
- **5 个快速房 breaches 全部为空数组**，营地耐久终值恒 10（room-JBP5/NTGV/P5CA/3TJY/94FQ）。
|
||||
- 逐波 breach 只存在于教学局（单人+2bot），真实波次合计仅 9 点伤害，散布在 w2:2 / w3:1 / w4:2 / w5:4——**没有任何一波形成压力墙**，曲线是平的。
|
||||
- 波次出清速度≈刷怪速度本身：快速局各波时长 18.6-27.2s（events.jsonl 对账），
|
||||
接近 WAVE_TABLE 的刷怪跨度（如 wave4：9 只 ×1.8s=16.2s 跨度 → 21-24s 出清）。
|
||||
怪**进入内圈后中位 0.8-1.8s 即死**（死亡 eta 中位数 2.2-3.2s，内圈窗口起点 4.0s，
|
||||
5 房明细：NTGV med 3.20 / P5CA 3.20 / JBP5 2.20 / 3TJY 2.90 / 94FQ 3.10）。
|
||||
|
||||
### 1.2 吞吐算账（根因链第一环：波次表输出 < 团队击杀容量）
|
||||
|
||||
以最难的第 5 波计：
|
||||
|
||||
| 量 | 值 | 来源 |
|
||||
|---|---|---|
|
||||
| 峰值到达率 | 12 只 / 1.5s gap ≈ **0.67 只/s** | WAVE_TABLE[5] |
|
||||
| 3 座攻击吞吐 | 3 × 1/2.5s = **1.2 杀/s**（1.8 倍冗余） | ATTACK_CD_MS=2500 |
|
||||
| 4 座攻击吞吐 | 4 × 1/2.5s = **1.6 杀/s**（2.4 倍冗余） | 同上 |
|
||||
| 旋风斩追加 | 每座每 8s 清空内圈全部（快速局实测 108 次、清走 63/195=32% 击杀） | SKILL_CD_MS=8000 |
|
||||
|
||||
且 `buildWaveScript` 按 `seat = i % seatCount` 把怪**轮转发牌到各防区**：4 座房每席
|
||||
第 5 波只分到 3 只（≈10s/只），而单席击杀容量 0.4 只/s + 旋风斩。**WAVE_TABLE 不随
|
||||
seatCount 缩放**（LAYOUTS 分 3/4 座两套，波次表只有一套）——4 人房等于把 3 人份的
|
||||
压力摊给 4 个人分担。
|
||||
|
||||
### 1.3 根因链（按因果顺序）
|
||||
|
||||
1. **波次表按「3 个 bot 水准」标定，而非按真人**：§3.4 平衡目标"solo 余 6-9（A/B）"
|
||||
的参照点是 `botDecide` 循环（hesitateP 0.8、reactBase 2.0 —— §15 裁决 10 故意调钝）。
|
||||
实测教学房（1 真人 + 2 bot）mean dur ≈ 9.1（6×10、3×9、1×8、1×6），显著高于
|
||||
扫描 bot 档的 7.5：**哪怕最弱的真人（P03，个人仅 10 杀）也净贡献 +4~6 点耐久**，
|
||||
因为真人出手 eta（3-4s）天然早于 bot 反应带（≤2-3s）。真人 ≥ bot 是设计意图
|
||||
（§7.2"给真人留出比 bot 强的空间"），但波次表没有为"真人水准"重新加压。
|
||||
2. **难度不随座位数/水平缩放**：4 座房沿用同一 39 只总盘 → 团队吞吐冗余从 1.8× 升到 2.4×。
|
||||
3. **真人房≥1 个高手即封顶**：optimal 档 23/24 = dur 10——单个最优玩家就能把耐久打满，
|
||||
房间结果 = f(最强玩家)，与队伍其余人几乎无关。5 个快速房每房至少 1 个
|
||||
（P01/P05/P07/P02/P10），于是 5/5 零损耗。
|
||||
4. **评级阈值落在饱和区**：`gradeFor` 的 S 门槛 dur≥9（≤1 点损耗），在吞吐 2 倍冗余下
|
||||
恒可达 → S 是众数（26/28）。
|
||||
5. **扫描工具无法发现上述一切**：`hunt-balance-scan.mjs` 三档全是单人房，无 4 座档、
|
||||
无混合水平档——失衡的构型（3-4 真人）从未被标定过。
|
||||
|
||||
（bot 强度本身**不是**根因：idle 档 2 bot 独守尚有 6/24 失守、mean 3.3，bot 下限合格；
|
||||
问题是波次输出对"真人+多人"这一档没有任何加压机制。）
|
||||
|
||||
### 1.4 修复提案
|
||||
|
||||
**F1（P0）波次输出按座位数缩放** — `hunt-room.js`：
|
||||
- `buildWaveScript(seed, wave, seatCount)` 内对 `WAVE_TABLE[wave]` 做有效规格换算：
|
||||
`wolf' = round(wolf × seatCount / 3)`（4 座 wave5：10→13 狼），`gap' = gap × 3 / seatCount`
|
||||
（1.5s→1.125s），熊维持绝对数（重威胁稀缺性保留）。WAVE_TABLE 常量不动，新增
|
||||
`scaleSpecForSeats(spec, seatCount)` 纯函数（可单测）。
|
||||
- 改动面：hunt-room.js（+设计文档 §3.4 加"4 座换算行"）。
|
||||
|
||||
**F2（P0）房间热度导演（水平自适应加压）** — `hunt-room.js`：
|
||||
- Room 增加 `heat`（初始 0）。每次 `waveclear`：本波零 breach 且 `dur === DUR_MAX` 且
|
||||
`wave >= 2` → `heat += 1`（上限 3）；本波有 breach → `heat = max(0, heat - 1)`。
|
||||
`startWave` 应用：额外狼 `+heat` 只、`wolfEta - 0.3 × heat`、`gap × (1 - 0.08 × heat)`
|
||||
（常量建议 `HEAT_MAX=3 / HEAT_ETA_STEP=0.3 / HEAT_GAP_FACTOR=0.08`）。
|
||||
- heat 由确定性事件（breach 有无）导出，**不消耗 rng**，seed 复现性不破坏（§3.5 纪律）。
|
||||
- 作用：高手房自动爬压（P05"P5CA 式碾压"不再恒 10），弱手房天然漏怪 → heat 归零不受罚。
|
||||
- 改动面：hunt-room.js + 设计文档 §3.4/§7 新小节。
|
||||
|
||||
**F3（P0，验收工具）扫描扩档** — `hunt-balance-scan.mjs`：
|
||||
- 新增模式 `bot4`（4 座全 bot 水准）、`opt4`（4 座 optimal）、`mix`（1 optimal + 3 挂机），
|
||||
验收口径：F1/F2 落地后 `bot4` mean 落 6-9、`opt4` mean 8-10（S 可达不恒得）、
|
||||
`mix` 落 5-8。**F1/F2 合入前不得视为完成**。
|
||||
- 改动面：test/hunt-balance-scan.mjs。
|
||||
|
||||
### 1.5 预期指标变化
|
||||
|
||||
| 指标 | 现值 | 目标 |
|
||||
|---|---|---|
|
||||
| 胜率 | 100%（28/28） | 85-95%（弱手房可输、高手房赢得有伤） |
|
||||
| 快速局零损耗房 | 5/5 | ≤1/5，房均损耗中位 0 → 2-3 |
|
||||
| 评级分布 | S 93% | S ≤30% / A≈40% / B≈25% / C+失守 5-10% |
|
||||
| 第 5 波死亡 eta 中位 | 2.2-3.2s | 保持 2-3s（高压来自数量而非读不到） |
|
||||
|
||||
---
|
||||
|
||||
## 2. 发现二：击杀垄断——「先到先得 + 出手权无协调」的结构性结果
|
||||
|
||||
### 2.1 现象（数据）
|
||||
|
||||
快速房击杀分配（killsBySlot，含旋风斩清怪归属）：
|
||||
|
||||
| 房 | 分配 | 最高份额 | 0-1 杀者 |
|
||||
|---|---|---|---|
|
||||
| R1-P5CA | **30**/1/4/4（P01） | 77% | P03=1 |
|
||||
| R2-3TJY | **27**/1/4/7（P07） | 69% | P08=1 |
|
||||
| R1-NTGV | **19**/5/15/0（P05,P07） | 49% | **P08=0** |
|
||||
| R2-94FQ | 18/0/1/**20**（P05,P02） | 51% | **P03=0** |
|
||||
| R1-JBP5 | 19/15/5（P10,P09,bot） | 49% | — |
|
||||
|
||||
教学房同理：P01 房 36/4/0（92%）。全场个人击杀 0~36 共存。
|
||||
主观侧直接踩线：P03 三局 1/0/0 杀后退出；P07 复盘"被独狼压制"、两遍
|
||||
`kill_band0`「你还没开张」；P01"我只好一人收 39 只里的 30 只"。
|
||||
|
||||
### 2.2 机制根源（四个机制叠加）
|
||||
|
||||
1. **击杀即死 + 无目标归属**：mob 无 HP（`{id, mkind, dir, eta}`），`adjudicateAttack`
|
||||
弧内取 eta 最小者即刻删除——先出手者独得，没有助攻账。
|
||||
2. **冷却在座不在目标**：`ATTACK_CD_MS` 约束的是单人频率（2.5s/杀），谁先出 cooldown
|
||||
谁先抢下一只；快速手 = 结构性垄断者。P05："出手权不在最快的手上，在系统的时钟上"
|
||||
——对他这是上限锁，对弱者是抢夺机。
|
||||
3. **感知速度差即击杀权差**：怪进内圈（eta≤4.0，MELEE_ETA）后中位 0.8-1.8s 内被杀；
|
||||
高手 loop 注册率 39/39、clean notice 中位 663-761ms（P05/P01），弱手注册率 12/36、
|
||||
notice 1368-1674ms（P03/P08/P10，brainStats）——**弱手在数学上不可能先到**，
|
||||
他听清时怪已死，声场永远是空的。
|
||||
4. **旋风斩全内圈收割 + 归属出手者**：`adjudicateSkill` 清 eta≤4 全部怪并全部
|
||||
`creditKill(slot)`。P07 三局 37 次旋风斩，3TJY 一局清走 17/39（44%）——
|
||||
高频双击者成为吸尘器，且吃掉的正是别人防区里"即将到手的怪"（P05："01:14.2 左后狼
|
||||
在我眼前被旋风斩收走"）。
|
||||
5. （放大器）**无出手权协调信道**：callout 语义是"求援"不是"这归我"，3 局 18 人次
|
||||
仅 3 次呼喊；击杀归属无播报（P01 的"熊债"：打残的熊被 bot 补刀无声无息）。
|
||||
|
||||
### 2.3 修复提案
|
||||
|
||||
**F4（P0）防区优先窗（sector yield）** — `hunt-room.js`：
|
||||
- 新常量 `SECTOR_YIELD_ETA = 2.0`。`adjudicateAttack` 选目标时：若 mob.dir 属于**另一在
|
||||
席座位的防区**（LAYOUTS 是全集划分，可 `dirOwner(dir)` 查表）且 `mob.eta >
|
||||
SECTOR_YIELD_ETA` → 跳过该 mob（弧内试下一只；全跳过走既有 miss 路径）。
|
||||
- 语义：防区主人对自家怪有 2s 优先窗（eta 4.0→2.0），过了窗任何人可补——
|
||||
「软防区」从"bot 偏置"升级为"轻出手权"，补位语义保留（主人掉线/发呆 2s 后怪仍可救）。
|
||||
- bot 侧自动受限（bot 反应带 ≤2.0-3.0，影响可忽略）；教学波怪在玩家防区（N 席 0），
|
||||
教学 bot 不再偷教学狼。
|
||||
- 改动面：hunt-room.js + 设计文档 §3.3（防区三用途 → 四用途）+ §13 断言
|
||||
（"主人存活且 eta>2.0 时跨区击杀被跳过"）。
|
||||
|
||||
**F5（P1）击杀账改「击杀+协助」双账** — `hunt-room.js` + `game.js` + §6.3/§12：
|
||||
- mob 增加 `hitBy`/`claimedBy` 追踪（首个对其出手者=协助者）；`ev end` 的 kills 之外加
|
||||
`assists`（按 slot）。旋风斩清走的怪：击杀记施放者、协助记防区主人。
|
||||
- 客户端 `killBandId`（game.js:94）改按 kills+assists 取档；进度 best 与 summary
|
||||
（§12 生成规则）加入协助数。`kill_band0` 文案改为中性（"这一夜你守多攻少"类，
|
||||
台词表 23-hunt-voice-ids.md L 组 + TTS 重生成——归音频域，列依赖）。
|
||||
- 改动面：hunt-room.js / game.js / 设计文档 §6.3（end 字段）/ §12。
|
||||
|
||||
**F6（P2）击杀归属可听化**：「怪被队友收走」短音（<1s，R5 合规）——归音频域，
|
||||
此处只登记需求：P01 熊债、P05 旋风抢怪的直接止痛点。
|
||||
|
||||
### 2.4 预期指标变化
|
||||
|
||||
| 指标 | 现值 | 目标 |
|
||||
|---|---|---|
|
||||
| 房内最高击杀份额（快速局均值） | 59%（77% 峰值） | ≤45%（≤20/39） |
|
||||
| 0 杀快速局人次 | 2/18 | 0 |
|
||||
| 弱手个人击杀（P03/P08 型） | 0-1 | 6-10（自家防区每局 ~10 只轮到名下） |
|
||||
| kill_band0 触发 | 有（且辱骂感） | 基本消失 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 发现三：bot 与真人的强度关系——「带飞」是吞吐结构，不是谁强谁弱
|
||||
|
||||
### 3.1 现象与对照
|
||||
|
||||
| 构型 | 数据 | 结论 |
|
||||
|---|---|---|
|
||||
| 教学房（1 真人+2 bot），弱手 | P03 房 bot 29/39=**74%** 杀、玩家仍 S 余9；P06 房 bot 33% | **bot 带飞**：S 白送，学习不被检验 |
|
||||
| 教学房，高手 | P01 房 bot 4/39=10%、P07 房 6/39 | 玩家吸干 bot：bot 只剩清扫 |
|
||||
| 快速房（3-4 真人，0 bot） | P5CA P01 独得 30/39；3TJY P07 独得 27/39 | **高手带飞**：同一结构换了主体 |
|
||||
| 快速房 2 真人+1 bot | JBP5 bot 仅 5/39 | bot 在混合房自动边缘化 |
|
||||
| 挂机底座 | idle 档：2 bot 独守胜 18/24、mean 3.3 | 纯 bot 下限合格（有输的可能） |
|
||||
|
||||
### 3.2 根因
|
||||
|
||||
- bot 的调参目标（§3.4"solo 余 6-9"）是**房间结果**目标，从不约束**击杀经济**。
|
||||
bot 被 `hesitateP=0.8 / reactBase=2.0` 钝化后，在击杀市场里永远是"慢清道夫"：
|
||||
房间里有任何比它快的人（= 任何真人），bot 份额就被压到边角。
|
||||
- 因此"教学局 bot 带飞"与"真人局专家带飞"是**同一个吞吐过剩问题的两张脸**：
|
||||
座位数 × 0.4 杀/s 的容量 vs 0.67 只/s 的峰值供给，剩下的人都在分剩余。
|
||||
- 副作用 1（教学）：弱手被 bot 抬到 S → 教学局 9/10 是 S，"学会与否"不可见（Q5 域，
|
||||
数值侧证据：教学房 dur mean 9.1 vs idle 档 3.3——玩家贡献被 bot 底座掩盖）。
|
||||
- 副作用 2（P05 的天花板抱怨）：bot 钝化把"比 bot 强"的达标线设得过低——
|
||||
optimal 玩家单人即 dur 10，团队协作没有数值上的必要（§1.6 风险③在多人档落空）。
|
||||
|
||||
### 3.3 修复提案
|
||||
|
||||
**F7（P1）教学房 bot 防区锁死** — `hunt-room.js`：教学段（phase=teach + 教学后前 2 波）
|
||||
bot 的 `botPickDir` 只在**自家防区**内选目标（偏置 ×∞ 或硬过滤）。玩家的 1/3 声场真正
|
||||
归玩家，教学结果反映玩家水平（P04 型 = B 而非全班 S）。改动面：hunt-room.js（约 5 行）
|
||||
+ §5 教学房规则补一句。
|
||||
|
||||
**F8（P2，观察项）bot 强度不动**：F1/F2/F4 落地后重跑扩档扫描，若 4 座 bot4 档
|
||||
mean 仍 >9，再考虑 `BOT_TUNING_DEFAULT.hesitateP 0.8→0.7`。当前无证据要求动 bot——
|
||||
先修供给（波次）与分配（出手权），再谈 bot。
|
||||
|
||||
### 3.4 预期指标变化
|
||||
|
||||
- 教学房玩家击杀份额：26-59%（弱手）→ ≥70%；教学房评级分布从 9S/1A/… → 反映真实
|
||||
水平（预期 S≤4/10）。bot 份额与玩家水平的相关斜率变平（不再"越弱越被抬"）。
|
||||
|
||||
---
|
||||
|
||||
## 4. 发现四：评级失去分辨力——单一输入（耐久）落在饱和区，且与个人表现完全解耦
|
||||
|
||||
### 4.1 现象（数据）
|
||||
|
||||
- `gradeFor(dur)`：S≥9 / A 7-8 / B 4-6 / C 1-3。实测 26S/1A/1B：**S 是 93% 的缺省值**。
|
||||
- 三局满 S 的 P05 原话："一个不稀缺的 S 等于没有评级""结算屏给我同一个 S"→ 退出;
|
||||
P01："两局都 S·营地余 10 之后，我也不知道下一局还能图什么"→ 退出。
|
||||
- **房内所有人同评级**：NTGV 房 P08（0 杀、1 次错弧出手）与 P05（19 杀、26/27 弧对）
|
||||
同为 S。评级对个人零信息。
|
||||
- 即使按扫描 bot 档（3 bot 水准），S 也占 8/24——S 门槛（≤1 点损耗）在原难度下就偏松；
|
||||
难度饱和（发现一）把它彻底推成众数。
|
||||
- 进度 best 排序键（§12：评级 > 营厂余耐久 > 击杀）里第三键从未被用到（dur 恒 10）；
|
||||
`end_rank`"猎手榜"只是一句台词（P05/P07 都点名：无名次、无分段、无历史最高）。
|
||||
|
||||
### 4.2 根因
|
||||
|
||||
1. 评级输入只有 dur 一个维度，而 dur 被吞吐冗余饱和（发现一）。
|
||||
2. 评级是房间级共享，个人击杀档（killBandId）只进播报不进评级/best——
|
||||
"30 杀带飞"与"0 杀躺赢"在存档里等价。
|
||||
3. 个人可精进轴（弧错率 22%、notice 时延、旋风时机）没有任何一个进入结算。
|
||||
|
||||
### 4.3 修复提案
|
||||
|
||||
**F9（P0，与 F1/F2 绑定验收）评级分两轴** — `hunt-room.js`（服务端权威，§3.6）：
|
||||
- **团队轴**：`gradeFor` 门槛在 F1/F2/F3 扩档扫描上重标定。建议收紧为
|
||||
`S: dur≥10（零损耗）/ A: 8-9 / B: 5-7 / C: 1-4`，验收线：bot4 档 P(S)≤15%、
|
||||
opt4 档 P(S)≥80%（S = 高手护住满血，而非缺省）。
|
||||
- **个人轴**：`ev end` 增 per-slot `contrib`（kills + 0.5×assists，F5 的账）与
|
||||
`quota = 总怪数/席位数`；个人档 `contrib/quota ≥1.2 → 主猎手 / ≥0.6 → 主力 /
|
||||
其余 → 协防`。voice 新增 3 句（23-hunt-voice-ids.md 结算链：grade_* →
|
||||
个人档 → kill_band_* → end_rank），预算 60→63 句（§10.3 核算仍有余量）。
|
||||
- 进度 best（§12）写入个人档与 contrib，summary 加个人档字段（game.js
|
||||
`_saveProgress/_betterThan` + §12 生成规则）。
|
||||
- 改动面：hunt-room.js / game.js / 设计文档 §3.6 / §12 / 台词表。
|
||||
|
||||
**F10（P1）把"榜"做成真榜**：`end_rank` 台词之后上滑可听"本房击杀对比"
|
||||
（复用 kill_band 分档 + 座次 2-3 句资产），进度 API best 已有 kills——
|
||||
跨玩家榜仍是 roadmap，但**房内对比**是 P05/P07 明确要的钩子且零协议改动。
|
||||
改动面：game.js + 台词表。
|
||||
|
||||
### 4.4 预期指标变化
|
||||
|
||||
- 评级分布见发现一目标列；S 成为"零损耗+个人主猎手"的复合稀缺品。
|
||||
- 复测口径：P05 型玩家三局结算不再全同（个人 contrib 有区分度）；
|
||||
best 更新触发率（现恒 S+10，二局后不再更新）→ 每局有可刷新字段。
|
||||
|
||||
---
|
||||
|
||||
## 5. 发现五：匹配无水平信号——悬殊同房对弱者是「无声的羞辱局」，对高手是苦役
|
||||
|
||||
### 5.1 现象（数据）
|
||||
|
||||
- `handleJoin` 快速匹配 = 找第一个有空位的 lobby（`r.phase==='lobby' && slots<4`），
|
||||
**无任何水平输入**（协议 join 也不携带，§6.2）。
|
||||
- R1-P5CA 把 P01（15 年读屏、notice 761ms、弧对 59%）与 P03/P02/P04
|
||||
（notice 1368-1575ms、注册率 12-14/36）同房：P01 30 杀，P03 1 杀，P04 4 杀 0 弧对命中杀。
|
||||
- **弱者代价**（P03 三局 1/0/0 → 退出；P08 0/1 杀）：
|
||||
- 声场被抽空：高手把怪在 eta 3.2 清掉，弱手 loop 注册率仅 1/3——游戏对他是
|
||||
"5 分钟静坐 + S 屏"；
|
||||
- 看门狗误伤：闲置提醒 4-7 次/局（P03/P04/P10，全场 93 次）——不是挂机，是**无怪可打**，
|
||||
`gd_idle` 只看自家手势 10s 窗（game.js 向导层）；
|
||||
- 结算羞辱：`kill_band0`"你还没开张"对着 0 杀弱手播（P07 转述两遍）；
|
||||
- 贡献不可见：胜利与个人 0 贡献同屏，S 变成嘲讽。
|
||||
- **高手代价**：P01"最后干脆自己全收"；P07 R1 被独狼压制后反而上头（要对手），
|
||||
但零心跳局"无聊删得比连输还快"。
|
||||
|
||||
### 5.2 根因
|
||||
|
||||
1. 快速匹配是纯填坑算法，服务端对玩家水平零知识（进度 best 只在客户端）。
|
||||
2. 悬殊房放大发现一/二：高手吞吐过剩 → 弱手零供给；数值上"团队赢"掩盖"个人零参与"。
|
||||
3. 反馈系统（看门狗、kill_band0）假设"没动作=没在玩、0 杀=没出力"，在垄断经济下
|
||||
两个假设都反向成立。
|
||||
|
||||
### 5.3 修复提案
|
||||
|
||||
**F11（P1）join 携带水平提示 + 分层匹配** — `hunt-room.js` + `game.js` + §6.2：
|
||||
- join 增可选字段 `skill: 0-3`（客户端由进度算：无 best=0，B/C=1，A=2，S 且 kills≥15=3；
|
||||
老客户端缺省 null，向后兼容 ver 不动）。
|
||||
- 快速匹配从 first-fit 改为最小极差：优先进 `max(skill)-min(skill) ≤ 1` 的 lobby；
|
||||
找不到则等待，`LOBBY_MS` 12s 到点仍回落任意房（小池子兜底，不增等待上限）。
|
||||
- 改动面：hunt-room.js `handleJoin`（约 30 行）/ game.js（算 skill 并携带）/ §6.2 字段表。
|
||||
|
||||
**F12（P2）反饥饿看门狗**（跨域登记，数值侧给判据）：`gd_idle` 触发前提改为
|
||||
"近 10s 内**自家防区**出现过内圈怪或 breach"（game.js 有本地怪表可判）；
|
||||
starving 弱手的闲置提醒 4-7 次/局 → ≤1 次。
|
||||
|
||||
**F13（P2）kill_band0 文案中性化**（并入 F5 的台词改动）。
|
||||
|
||||
### 5.4 预期指标变化
|
||||
|
||||
- 悬殊房（极差 ≥2 水平档同房）占比 → 目标 <20%（10 人池的现实约束下）；
|
||||
- 弱手侧：0-1 杀人次 2/18 → 0（叠加 F4），闲置提醒中位 5 次/局 → ≤1；
|
||||
- 高手侧：房内最高击杀份额下降后，"碾压无聊"局（零 breach 且 top-share>60%）→ 复测追踪。
|
||||
|
||||
---
|
||||
|
||||
## 6. 修复优先级表（按「玩家愿意玩下去」的影响排序）
|
||||
|
||||
| # | 修复 | 定级 | 改动面 | 直接对标的退出原因 | 预期核心指标 |
|
||||
|---|---|---|---|---|---|
|
||||
| 1 | **F1+F2 波次按座位缩放 + heat 导演**（WAVE_TABLE 换算 / HEAT_* 常量） | **P0** | hunt-room.js + 设计文档 §3.4 | P05"白给 S 就删"、P07"零心跳无聊删"、P01"没有下一局" | 胜率 100%→85-95%；快速零损耗 5/5→≤1/5；S 占比 93%→≤30% |
|
||||
| 2 | **F3 扫描扩档**（bot4/opt4/mix） | **P0**（#1 的验收门槛） | hunt-balance-scan.mjs | —（流程性：防回归） | bot4 落 6-9 带、opt4 不恒 S |
|
||||
| 3 | **F4 防区优先窗**（SECTOR_YIELD_ETA=2.0） | **P0** | hunt-room.js + §3.3/§13 | P03 零参与退出、P07 被压制+受辱、P05 被抢怪 | 0 杀局 2/18→0；top-share 59%→≤45% |
|
||||
| 4 | **F9 评级双轴**（gradeFor 重标定 + contrib 个人档） | **P0** | hunt-room.js / game.js / §3.6/§12/台词表 | P05"不稀缺的 S"、P01"S 后无可图" | S=零损耗+主猎手复合条件；best 可持续刷新 |
|
||||
| 5 | **F5 击杀+协助双账**（ev end.assists / killBandId 口径 / best+summary） | P1 | hunt-room.js / game.js / §6.3/§12 | P01"熊债"、P08 型无感参与 | 协助进结算链；0 贡献玩家归零 |
|
||||
| 6 | **F11 分层匹配**（join.skill + 最小极差选房） | P1 | hunt-room.js / game.js / §6.2 | P03 式悬殊局体验 | 悬殊房 <20%；弱手闲置提醒 ≤1/局（配 F12） |
|
||||
| 7 | **F7 教学房 bot 防区锁死** | P1 | hunt-room.js + §5 | 教学不检验学习（Q5 联动） | 教学房 S 9/10→≤4/10 |
|
||||
| 8 | **F10 房内击杀对比榜**（end_rank 后可听） | P1 | game.js + 台词表 | P07"要可听的排名" | 好胜型留存钩子（复测去留对照） |
|
||||
| 9 | **F12 反饥饿看门狗 + F13 kill_band0 中性化** | P2 | game.js / 台词表 | 弱手被骂式关心 | 闲置提醒全场 93 次→<30 |
|
||||
| 10 | **F6 击杀归属可听化**（"被收走"短音） | P2 | 台词/sfx 资产（音频域） | 熊债止痛 | 归音频域实施 |
|
||||
|
||||
**跨域依赖提示**（非本视角所有权，但数值上相关）：P01/P05/P07 三人共报的
|
||||
"冷却乱滑 666 次纯 error 震、无剩余时间反馈"（ATTACK_CD_MS 黑箱）与
|
||||
"战斗态下滑双语义误开菜单"属交互域 P0——它们与 #3 同为垄断痛感的放大器，
|
||||
复测前应与数值修复同批落地，否则弱手的"抢不到"会被 UI 挫败混因。
|
||||
|
||||
**复测纪律**（沿用 00-plan §6）：同 10 人配置不改；上述改动合入后先跑扩档扫描（F3）
|
||||
再开同阵容复测，对比指标：胜率/评级分布、房均 breach、top-kill-share、0 杀人次、
|
||||
闲置提醒次数、去留决策（重点盯 P01/P05/P07 的"白给 S/无聊"决策点是否消失）。
|
||||
Reference in New Issue
Block a user