红名判定在两个入口各写了一份:进城闸门写 status == "red",传送闸门写恶值 > 300——两套口径看着等价,实际上恶值 301 的玩家被传送闸拦截、却被进城闸放行。逻辑重复的恶果不是多打几行字,而是"同一规则的两个副本各自演化":策划改了红名阈值,只改到其中一处,另一处变成隐藏后门。错误写法:
local function canEnterCity(actor)
actor = getplayerbyname(actor)
return getplayvar(actor, "HUMAN", "Status") == "red" == false
end
local function canTeleport(actor)
actor = getplayerbyname(actor)
return (tonumber(getplayvar(actor, "HUMAN", "Evil")) or 0) <= 300
end
规则收口成一个判定函数,两个入口都调用它——阈值要改只改一处。示例代码如下:
local function isRedName(actor)
actor = getplayerbyname(actor)
local evil = tonumber(getplayvar(actor, "HUMAN", "Evil")) or 0
return evil >= 300
end
local function canEnterCity(actor)
actor = getplayerbyname(actor)
if isRedName(actor) then
sendmsg(actor, 1, "红名禁止进城。")
return false
end
return true
end
local function canTeleport(actor)
actor = getplayerbyname(actor)
if isRedName(actor) then
sendmsg(actor, 1, "红名禁止传送。")
return false
end
return true
end
本篇的新技术点是"判定函数化":isRedName 成为红名判定的唯一真相源,所有入口引用同一个名字,阈值调整是单点手术而不是多点扫雷。
三步验证:恶值分别置 299、300、301 各测两入口,结果必须一致;把 isRedName 的阈值从 300 改成 500,重载后两入口同步变化;对照误写版,恶值 301 的玩家进城放行、传送被拦,复现矛盾。
判定函数化之后,规则升级只动一处:红名判定追加"洗名券持有者豁免",入口零改动。示例代码如下:
local function isRedName(actor)
actor = getplayerbyname(actor)
if checkitemw(actor, "洗名券", 1) then
return false
end
local evil = tonumber(getplayvar(actor, "HUMAN", "Evil")) or 0
return evil >= 300
end
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 活动排期凭感觉:周末连开三个重头活动,玩家疲于奔命参与率反跌;工作日大空窗,在线曲线断崖。玩法日历设计:以周为单位…
设计初衷 网络波动掉线让玩家损失战斗进度:世界BOSS打到一半掉线,回来残局已清;副本中掉线,门票作废。掉线补偿设计把掉线当…
底层原理 祭坛围一圈火把、世界BOSS周身一圈水晶,这类环绕阵列需要等角度分布坐标:圆心 (cx, cy)、半径 r、数量 …
设计初衷 排行榜只有顶端可见:进不了前一百的玩家在榜上查无此人,名次没有参照,追赶没有对象。影子榜设计:为每名玩家生成以自己…
业务场景 打错路线或主力减员后想重来,队长单方面重置常引发队内矛盾,误触重置的投诉也不少。投票重置封装:重置需全队表决、同意…
底层原理 存档在写入与传输中可能因意外损坏,读档前需要一道完整性判定。校验和的思路:把数据逐字节累加压缩成一个整数指纹,读档…