RUDPFramework/CodeX-TODO.md

45 lines
3.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## 当前修补目标:客户端移动抖动
### 已确认的主要问题
1. 客户端当前把 `PlayerState.Tick` 当成“已确认输入 tick”用于 prediction buffer 修剪与重放,但服务端当前发出的 `PlayerState.Tick` 实际上是广播 tick不是最后确认的 `MoveInput.Tick`
2. 客户端本地预测速度来自登录 UI / `LoginResponse.Speed`,服务端权威移动速度来自 `ServerAuthoritativeMovementConfiguration.MoveSpeed`,两者当前没有强约束保证一致。
3. 客户端本地预测按 `FixedUpdate + Time.fixedDeltaTime` 积分,服务端权威状态按外部传入的 `elapsed` 积分;一旦服务端主循环步长与客户端固定步长不一致,转向移动轨迹会持续偏离。
4. 客户端收到权威状态后当前仍采用“直接硬回写位置/旋转/速度,再重放”的纠正策略;当对账 tick 或积分条件不一致时,会直接表现为频繁拉扯和可见抖动。
### 修补目标
- 让客户端 reconciliation 使用明确的“已确认移动输入 tick”而不是复用广播 tick。
- 统一客户端预测参数与服务端权威参数至少保证移动速度、转向速度、tick 语义一致。
- 明确服务端 authoritative movement update cadence避免客户端与服务端长期运行在不同积分节拍上。
- 在完成语义统一后,再决定是否需要补充更平滑的本地纠正策略,而不是先靠插值掩盖逻辑偏差。
### 实施计划
1. 先调整协议或状态表达:为客户端对账提供明确的 movement ack tick禁止继续用 `PlayerState.Tick` 兼任广播序号和输入确认序号。
2. 修改 `ClientPredictionBuffer` / `MovementComponent` 的 reconciliation 逻辑,使 prediction buffer 按 ack tick 修剪,只重放真正未确认的输入。
3. 统一客户端与服务端移动参数来源,收敛 `LoginRequest.Speed` / `LoginResponse.Speed``ServerAuthoritativeMovementConfiguration.MoveSpeed` 的职责,避免双源真相。
4. 检查并修正服务端 authoritative movement 的生产主循环,确保 update cadence 可预测、可配置,并与客户端调试信息可对照。
5. 补充或更新回归测试,覆盖:
- 广播 tick 与 ack tick 分离后的 reconciliation 行为
- 客户端 / 服务端速度不一致时的保护或拒绝策略
- 固定 cadence 下的本地预测与权威状态收敛
6. 在语义正确后,再评估是否需要把本地 controlled player 的硬纠正改成阈值纠正、渐进纠正或混合策略,以进一步降低视觉抖动。
### 修补优先级
- P0tick 语义分离,修正 prediction buffer 错账问题。
- P0统一移动速度来源消除客户端预测与服务端权威结果的常量偏差。
- P1统一或约束 authoritative movement update cadence。
- P2在逻辑正确前提下优化 controlled player 的视觉纠正体验。
## 验收标准
- 上层只依赖统一的 `ITransport`
- `KcpTransport` 是唯一可靠传输实现。
- 客户端与服务端都能正常建立 KCP 会话。
- 登录、心跳、输入、状态同步链路可正常跑通。
- 非主线程不再直接访问 Unity 对象。
- 会话超时、断线、重连有明确状态与日志。
- 高频移动同步在丢包 / 抖动场景下仍可用。