一个玩家放技能,服务器的广播如果发给全地图,千人地图的每次动作就是千倍放大。AOI 视野内的增量推送把广播的范围收敛到九宫格视野,再对视野内的接收者做增量过滤——只需要知道的才发,带宽按数量级下降。
---广播范围收敛:以动作为圆心的视野格
local VIEW = 8 -- 视野 8 格
function Broadcast.area(mapId, x, y, msg)
local sent = 0
for _, actor in ipairs(Map.onlineActors(mapId)) do
local dx = actor.x - x
local dy = actor.y - y
if dx * dx + dy * dy <= VIEW * VIEW then
sendmsg(actor, 3, msg) -- 类型 3:当前地图定向
sent = sent + 1
end
end
Broadcast.metrics(mapId, sent)
end
广播按距离平方过滤:只有动作点 8 格内的玩家收到,千人地图的一次技能广播从 1000 份收敛到视野内的二三十份。sendmsg 的类型 3 即当前地图定向播报,引擎层的地图消息与本层的距离过滤叠加使用。距离的遍历曾经是全地图在线列表的线性扫,AOI 九宫格的桶查询让候选集从千人缩到几十人,过滤本身的成本也降了数量级。
---状态快照:只推变化的角色数据
setontimerex(60, 1)
function Broadcast.deltaTick(mapId)
for _, actor in ipairs(Map.onlineActors(mapId)) do
local snap = Snap.of(actor)
local prev = Snap.prev(actor)
if snap.hp ~= prev.hp or snap.buff ~= prev.buff then
local view = Snap.viewOf(actor)
for _, watcher in ipairs(view) do
Msg.send(watcher, "STATE", snap.id,
snap.hp, snap.buff)
end
Snap.save(actor)
end
end
end
状态广播走快照对比:血量与 BUFF 状态没变就不发,变化才对视野内观察者推增量。站桩挂机的玩家零广播,战场上的活跃角色才产生流量——带宽的分布跟着战斗的分布走而不是跟着人数走。消息的合并窗口再省一档:同帧内同一目标的多次变化合并成一条,洪峰的碎片消息被整形。实测沙巴克攻城:全量广播方案的带宽是增量方案的 11 倍,弱网玩家的掉线率差出一倍。
广播份数与字节数的分位监控,视野外收到消息的计数必须恒为零;快照对比的漏推检测,观察者视角的状态抽样比对。
视野半径曾经配 12 格,广播份数翻倍而视觉收益不明,8 格的实测平衡点写回配置。快照的清理曾经遗漏下线玩家,ID 复用后新旧玩家的快照串号,快照随会话销毁。合并窗口曾经 200 毫秒,血量变化的反馈延迟可感,窗口压到 50 毫秒。
视野半径与合并窗口进地图配置,竞技场景与开放场景可配不同值。广播的计数器按消息类型分档统计,哪类消息吃带宽一目了然。AOI 的桶结构与广播的范围查询共用一套格子系统,两套实现的漂移是浪费。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 停机 4 小时该补多少?影响 200 人还是全服该有区别吗?事故补偿没有分级标准时的两种结局:运营拍脑袋发多了一 …
底层原理 递归遍历嵌套表(装备的强化树、行会的组织树)最大的风险是循环引用:A 引用 B、B 引用 A,普通递归永远出不来,…
设计初衷 BOSS 刷新预告是信息触达里最微妙的一类:不预告,玩家靠蹲点与外挂猜,普通玩家永远慢一步;预告太精确,刷新瞬间主…
设计初衷 大部分玩家的活动地图不足服务器总地图数的三成:熟悉的比奇与盟重之外,毒蛇山谷、封魔谷常年无人问津。开图奖励把"第一…
底层原理 元表的 __index 与 __newindex 各管一端:__index 在读取不存在的键时触发,可以返回默认值…
底层原理 全局 math.random 是一条被全服共享的随机流:爆率系统、转盘系统、挖矿产出都在同一条流上取数。任何系统调…