今日进展：怪物吃方块系统的实现

今天在性能压测训练游戏中取得了第一个关键进展——实现了基础的怪物生成和方块吞噬系统。这个系统旨在为后续的性能优化测试创造高负载场景，同时也是一个有趣的可视化演示。

系统设计概述

  • 方块布置：在游戏场地上均匀放置了白色小方块，布局为每行25个方块，共60行，总计1500个方块。这些方块作为怪物的”食物”目标。
  • 怪物生成：每0.5秒在场地外围随机位置生成一个怪物，怪物会自动寻找并移动到最近的方块位置进行”吞噬”。
  • 核心逻辑：怪物生成后通过路径查找算法导航至方块，接触后方块消失，模拟吞噬效果。

技术实现要点

虽然代码细节后续会分享，但关键逻辑包括：

  • 使用对象池管理怪物实体，避免频繁内存分配
  • 简单的随机生成算法确保怪物分布均匀
  • 基于距离的目标选择策略，优化性能

效果与观察

当系统运行时，场景非常有趣：

  • 怪物一个个从边缘涌现，像潮水般向内推进
  • 白色方块逐渐被”吃掉”，场地变得空旷
  • 随着时间推移，怪物数量积累，创造了密集的实体环境

录屏演示

以下是怪物吃方块的录屏演示，展示了系统的实际运行效果：

视频：怪物吃方块的动态效果演示 - 可以看到怪物从边缘生成并逐渐吃掉白色方块的过程

目前初步测试显示，同时存在数十个活跃怪物时，系统运行流畅，但为达到性能压测目标（10,000+实体），还需要进一步优化。

性能压测突破：DrawCall极限测试

在基础系统稳定后，我进行了一次极端的性能压测实验，将怪物生成频率从0.5秒调整为0.01秒，并修改了怪物行为逻辑：

压测配置

  • 生成频率：0.01秒/个（比原设计快50倍）
  • 怪物行为：到达目标位置后停止移动，不再”吃方块”
  • 目标：创造密集的静态实体场景，测试渲染性能极限

惊人发现：DrawCall飙升到1400+

当怪物从四周向中间不断生成并停驻时，场景中迅速积累了数千个怪物实体。通过性能监控工具，我观察到：

  • DrawCall数量：从初始的几十个逐渐攀升至1400+
  • 内存占用：随着怪物数量增加，内存使用量线性增长
  • 渲染瓶颈：DrawCall成为明显的性能瓶颈

录屏演示：DrawCall极限测试

以下是这次极限压测的录屏演示，展示了怪物从四周向中间聚集，DrawCall逐步攀升的过程：

视频：DrawCall极限测试 - 怪物以0.01秒频率生成，从四周向中间聚集，DrawCall逐步攀升至1400+

技术分析：为什么DrawCall如此重要？

DrawCall是图形API（如OpenGL、DirectX）中每次调用绘制命令的次数。在游戏渲染中：

  • 每个怪物通常对应至少一个DrawCall
  • DrawCall过多会导致CPU向GPU发送命令的瓶颈
  • 现代GPU虽然计算能力强，但DrawCall处理能力有限

优化方向探索

基于这次测试，我确定了几个关键的优化方向：

  1. 批处理渲染：将多个相似怪物合并到一个DrawCall中
  2. 实例化渲染：使用GPU实例化技术大幅减少DrawCall
  3. LOD系统：根据距离使用不同细节级别的模型
  4. 视锥体剔除：只渲染屏幕可见范围内的怪物

下一步计划

  1. DrawCall优化研究：深入研究批处理和实例化技术
  2. 性能监控完善：添加DrawCall实时监控和性能分析
  3. 渲染架构重构：基于测试结果重新设计渲染管线
  4. 网络同步功能：为多玩家测试做准备

这次极限测试不仅验证了系统的稳定性，更重要的是揭示了真正的性能瓶颈所在。1400+的DrawCall数字成为了我接下来技术攻关的具体目标——如何将这个数字降低到可接受的水平，同时保持数千个实体的渲染效果。

看着怪物们从四周慢慢挤满整个场地，就像看着性能指标一步步走向极限，这种直观的视觉反馈让性能优化变得异常具体和有趣！

DrawCall深度研究：从1400+到10的优化历程

今天我对DrawCall问题进行了深入研究，通过系统性的实验和分析，成功将DrawCall从1400+降低到了10，实现了质的飞跃。

性能数据基准

内存占用情况

  • 进入游戏场景前：124MB
  • 进入游戏场景后：173MB
  • 游戏进入稳定状态后：194MB

渲染性能指标

  • 怪物数量：1944
  • DrawCall数量：1432
  • 三角形数量：8204

核心问题：为什么DrawCall数量那么高？

DrawCall是CPU向GPU发送渲染指令的过程，每个DrawCall都有固定的开销。当场景中存在大量独立的渲染对象时，DrawCall数量会急剧增加，成为性能瓶颈。

探索过程记录

第一阶段：动画组件影响测试

  • 取消怪物动画，移除cc.Animation组件
  • 结果：怪物数量1981，DrawCall 1480
  • 结论：动画组件不是DrawCall高的主要原因

第二阶段：内存缓存限制分析

  • 怀疑是内存或缓存大小限制导致DrawCall猛增
  • 发现关键参数：BATCHER2D_MEM_INCREMENT

第三阶段：BATCHER2D_MEM_INCREMENT参数调优

参数说明： Batcher2D中内存增量的大小（KB），决定了当场景中存在的2D渲染组件顶点数量超过当前batcher2D可容纳的顶点数量时，内存扩充的增加量。

默认值分析：

  • 默认值144KB，在标准格式下可容纳4096个顶点
  • 2000个怪物，理论顶点数：2000 × 3 × 2 = 12000个顶点
  • 理论需求：12000 / 4096 ≈ 3倍默认值

测试数据记录：

BATCHER2D_MEM_INCREMENT 怪物数量 DrawCall 三角形数量 效果
1024 1950 10 - 优秀
512 - 10 - 优秀
422 1968 10 - 优秀
400 1964 10 - 优秀
350 - 10 - 优秀
300 1959 10 - 优秀
289 1956 10 - 优秀
288 1972 10 - 优秀
270 1963 74 8256 一般
256 1948 214 - 较差

精确计算验证： 基于三角形数量计算：

  • 8204 × 9 × 4 / 1024 = 288.42KB
  • 设置289KB时效果良好
  • 设置270KB时DrawCall升至74

第四阶段：动画组件重新测试

  • 重新启用cc.Animation组件
  • 结果：DrawCall保持10
  • 结论：cc.Animation不会影响DrawCall

技术结论

  1. BATCHER2D_MEM_INCREMENT是关键参数：适当增大此值可以显著减少DrawCall
  2. 顶点数量是决定性因素：需要根据实际渲染的顶点数量设置合适的内存增量
  3. 动画组件不影响批处理：cc.Animation不会破坏渲染批处理
  4. 临界值效应明显：当内存不足时，DrawCall会急剧增加

优化建议

  1. 动态内存调整：根据游戏状态动态调整BATCHER2D_MEM_INCREMENT
  2. 顶点优化：减少不必要的顶点数据，优化模型复杂度
  3. 材质合并：尽可能使用相同材质的渲染对象
  4. 监控机制：实时监控DrawCall变化，及时发现性能问题

突破性成果

通过这次系统性的研究，我成功将DrawCall从1400+降低到了10，性能提升了140倍！这个优化不仅解决了当前游戏的性能问题，更重要的是建立了系统的性能优化方法论：

  • 从现象到本质：通过逐步排除法找到真正的问题根源
  • 数据驱动决策：基于精确的性能数据进行参数调优
  • 系统性思维：理解渲染管线的完整工作原理

这次技术探索让我深刻体会到，性能优化不仅仅是技术问题，更是思维方式的问题。通过科学的方法论和耐心的实验，即使是看似棘手的技术难题也能找到优雅的解决方案。

DrawCall优化将成为本系列后续的重点研究课题。

本文为训练游戏开发日志系列的第一篇，后续会持续更新进展。