交易行解决「我有货卖给谁」,求购行解决「我想要谁来卖」:挂出求购单,持有者看到订单直接出售,交易的方向反过来。求购行的引擎自带三段触发——上架前、上架成功、出售前,脚本在触点做核验与记账。
---beforeaddqiugou: 求购上架前触发
---actor:玩家对象 itemName:求购物品 needNum:数量 price:总价
function beforeaddqiugou(actor, itemName, itemIdx,
needNum, price)
-- 等级门槛:50 级才能发布求购
if getbaseinfo(actor, 6) < 50 then
messagebox(actor, "角色等级小于 50 级,无法发起求购")
return false
end
-- 单价的合理性:不低于市场指导价的一半
local ref = Market.refPrice(itemName)
if price < ref * needNum * 0.5 then
messagebox(actor, "求购价过低,请参考市场价")
return false
end
return true
end
上架前的触发是求购的守门员:getbaseinfo 的第 6 项读等级做 50 级的门槛,求购总价与市场指导价的比对拦下恶意压价的捣乱单。messagebox 的弹窗反馈让被拒的玩家知道原因——拒绝要有解释,规则的透明减少客诉。返回 false 的核验直接阻止求购的上架,返回 true 交还引擎继续走流程。
---addqiugou: 求购上架成功触发
function addqiugou(actor, itemName, itemIdx,
needNum, price)
local player = class(actor)
if not player then return end
QiuGou.record(actor, itemName, needNum, price)
sendmsg(actor, 1, "求购已挂出:" .. itemName ..
" x" .. needNum)
end
---beforesellqiugou: 出售前触发,核验卖家的货
function beforesellqiugou(actor, itemName, itemIdx,
needNum, price)
-- 出售者的货物必须是未绑定状态
if checkitemstate(Sell.itemOf(actor, itemIdx), 1) == 1 then
messagebox(actor, "绑定的物品无法出售给求购单")
return false
end
return true
end
上架成功的触发做求购的登记:求购单进撮合的池子,持货的玩家在求购列表里看到订单——撮合的方向是货找单而不是单找货。出售前的触发核验卖家货物的合规:绑定的物品不能卖给求购单(绑定体系不被求购绕穿),数量的足额在出售时二次确认。求购的保证金在挂单时冻结,成交或撤单时解冻——资金托管让求购单是真实的购买力而不是空头邀约。
求购的挂单量与成交量对比撮合的效率,长期无成交的求购单提示价格偏离市场;绑定的拦截量监控,绕过的尝试进风控样本。
上架的触发曾经在改参数的界面上重复触发,一次求购记了三次账,触发的幂等标记修复。出售的核验曾经漏了数量,三件的需求被一件的货凑数成交,数量的足额校验补上。保证金的冻结曾经在撤单后不退还,玩家白锁了资金,撤单的解冻流程补齐。
求购的门槛等级与单价下限进配置,捣乱单的门槛随版本调整。求购列表的排序按总价与挂单时间双维度,买家的诚意可视化。求购的成交播报带买卖双方的名字,撮合的荣誉双向公示。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 公告的敌人不是玩家没看到,是玩家看麻了:全服喇叭一天 40 条,玩家把公告通道整体静音,真正的停机公告也被淹没在里…
设计初衷 数值通胀是长线服务器的慢性病:每个版本都想给玩家"更强的爽感",三年后伤害翻一百倍,老装备一夜归零,平衡体系整体崩…
底层原理 合成一件装备要动三个变量:合成计数、幸运值、材料锁。写到一半失败,逐个手写还原是事故高发地——五个变量的事务,手工…
设计初衷 烈火剑法 1 到 3 级是战士战力的分水岭,升级曲线要回答三个问题:每一级值多少、贵多少、什么时候点。设计立场是增…
业务场景 主播直播喊口令"祖玛教主首杀庆典",玩家在世界频道打出该口令即领奖。三个约束:口令只在直播中口头公布、有效期 60…
底层原理 战力榜每 5 秒重算一次,单次重算 200 毫秒,期间前端仍在拉取榜单——直接在原表上改,读到的就是半新半旧的混合…