1. 性能原则#
本册不再给游戏永久绑定一组未经验证的实体数或毫秒数。性能目标由硬件、内容规模、存档状态和构建版本共同记录。所有结论用 P50/P95/P99、峰值内存和分配次数表达。
2. 分级基准#
| 档位 | 实体量 | 设施量 | 用途 |
|---|---|---|---|
| 基础 | 10,000 | 2,000 | 普通首发存档 |
| 高负载 | 50,000 | 10,000 | 大型玩家存档 |
| 极限 | 100,000 | 25,000 | 压力与回归测试 |
3. 帧与结算预算#
第一轮工程目标是保持交互帧稳定、让普通与高负载结算的 P95 阈值由实机基准报告确定、让常规存档加载保持在可接受范围，并确保后台保存不阻塞输入。所有阈值都是待压测目标，不是预先宣称已经达成的事实。
4. 优化手段#
首版建造不使用每格 Node。楼格使用压缩位图或稀疏区间，结构检查只在放置、删除、结构修改或点击“检查结构”后批处理，施工进度不触发重扫。
首版建造不使用每格 Node。楼格使用压缩位图或稀疏区间，结构检查只在放置、删除、结构修改或点击“检查结构”后批处理，施工进度不触发重扫。
| 问题 | 方案 |
|---|---|
| 大量实体遍历 | 连续数组、Chunk、dirty 标记、批量系统 |
| 远处世界开销 | 聚合模拟、降低更新频率、暂停不活跃区 |
| 内存碎片 | 对象池、稳定 slot、分块分配 |
| 查询卡顿 | 索引、分页、只读 DTO、缓存 |
| 线程竞争 | 不可变快照、revision 校验、主线程提交 |
| 内容启动慢 | manifest 索引、按激活包加载、延迟解析 |
5. Profiling 合同#
每次性能测试必须保存构建号、Godot 版本、编译器、CPU/GPU/内存、内容包哈希、MOD 清单、实体数量、运行时长和测试脚本。没有这些上下文的单次“感觉流畅”不算性能证据。
6. 失败处理#
任何优化都必须保留正确性基线。C++、多线程或压缩路径发生错误时，测试构建可切换到校验实现；结果不一致时拒绝提交并写入诊断日志。
7. 性能门禁#
P0 只要求完成基准框架、数据导入、单线程正确性和第一档压力报告；在没有真实报告前，不得把任何规模数字写成游戏承诺。