【讨论】会呼吸的消息系统

免费打工仔

Orz客户端是非常强调消息系统的，认为所有实体之间的函数调用都可以用消息替换。

但是最近有一些朋友，在制作过程中开始怀疑消息系统分发的效率问题。

虽然我认为这些朋友的项目，效率瓶颈都不在消息分发上，但是我仍然考虑在今后如果制作巨多量实体和巨多量消息的情况下，是否需要避免消息系统对效率的浪费呢。

很直观的，我们会想到用另外一个线程去分发消息，这是个不错的想法，消息数量和接收消息的处理器的数量都不会影响渲染主线程的效率。如果消息太多了，可能会延后几帧处理——这是每秒60帧的系统，延后10帧不过完处理0.15秒而已，而且现实的世界上消息的传递理所当然有滞后性的
（我叫你的名字，产生声音，空气传播，进入你的耳膜，神经传递，反映，回馈）。

在深入一点来想，可以把消息分优先等级，比如用户的操作要立刻反应，而游戏内部的传递可以延迟一点。

进一步深入，我们可以在消息分发和处理中做一些均衡的操作，如果系统繁忙就把不重要的消息向后移动滞后处理。那么我们不就可以反过来通过消息系统来提高游戏效率了么？

我们知道，如果游戏逻辑让渲染“卡”，一定是在某一帧处理了太多的事物。在一个60fps的游戏中每帧之间的处理的逻辑事务不能超过0.015秒。

假如有以下逻辑时间（随便举例，不要挑毛病啊）
用户输入 a豪秒
检测状态 b豪秒
射击动作 c豪秒
计算弹道 d毫秒
检测目标状态 e毫秒
更新目标状态 f毫秒

如果我们在同一帧处理的话总共耗时a+b+c+d+e+f毫秒。如果这个结果大于0.015秒，那么就会卡。
但是如果我们通过“会呼吸的消息系统”，把其中某些逻辑处理滞后处理，那么就有可能改观。更好玩的是，我们可以通过检测用户的及其渲染性能，动态的调整消息分发的具体数量和时间（但这样做最大的问题是会导致每次运算结果会有区别，对于同步或者录像来说这是一个问题<但可以处理>）。

当然，你可以用独立的线程来处理逻辑，这样做应该是更高级的方案。不过要和渲染啊物理啊同步，可能又是头痛的事情。我们在框架级别做了一些优化，对这些对多线程苦手的开发者（比如我），算是福音了。



这样做，让消息系统的分发，不仅不会游戏的渲染速度，还会提高游戏的综合效率。真是很爽歪歪。

原文

OSFG

好文。

chenepnghui

看不懂

batistuta237

学习了