兑换码是线下发福利的标准手段:直播口播、海报印刷、渠道包推广都靠它。码表必须不可预测,核销必须防重放防并发,传奇开服团队在渠道推广时一次投放的兑换码动辄十万张。
local CODE_CHARS = "ABCDEFGHJKLMNPQRSTUVWXYZ23456789"
function Redeem.gen(prefix, count)
local codes = {}
for i = 1, count do
local s = {}
for j = 1, 10 do
local k = math.random(#CODE_CHARS)
s[j] = CODE_CHARS:sub(k, k)
end
codes[#codes + 1] = prefix .. table.concat(s)
end
return codes
end
码体 10 位去混淆字符,去掉 0O1I 易混字母,前缀区分投放渠道。生成后整表入库,明码只在导出的那一刻存在,库内只存哈希,库泄露也刷不了奖。
function Redeem.redeem(plr, code)
local hash = QF_Sha1(code)
local row = codeTable[hash]
if not row then return false, "兑换码无效" end
if row.usedBy then return false, "已被使用" end
row.usedBy = plr.id
row.usedAt = os.time()
QF_GiveItem(plr, row.itemId, row.count)
QF_LogRedeem(plr.id, code)
return true
end
核销先查后改在同一段同步逻辑内完成,并发提交同一码只有一人成功。每码限一账号,同 IP 每日核销上限 20 次防脚本扫码。兑换码支持有效期与单码奖励配置,活动码与渠道码走同一张表。客户端兑换入口放在设置页,兑换成功弹出奖励明细。
核销成功率与失败原因按小时统计,无效码尝试突增即告警扫描行为。
早期的码表用时间戳派生,被逆向出规律后一夜被扫走三千个码,换成随机生成加哈希存储才算真正封堵。导出的明码表也发生过管理事故,一份渠道码表被外传,追查靠的是每批次码的独立前缀,批次追溯让外传源头一刻钟内定位。
兑换码的奖励内容支持配置化组合:单道具、道具包、限时buff三类模板覆盖绝大多数投放需求,运营自助配置无需研发介入。核销接口与风控联动,同账号一分钟内的失败尝试超五次触发验证码挑战,人机分流在核销入口就完成。兑换记录对玩家可见,什么时候用了什么码拿了什么奖励,流水清晰,这让兑换相关的客诉几乎消失,因为每一笔都查得到。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
实战应用:用在哪里 脚本的规范靠人盯盯不过来:命名风格漂移、全局变量乱用、缩进混着来——风格检查器把这些规则的执行自动化。提…
实战应用:用在哪里 拍卖行的出价是一场与时间的博弈:出价的按钮、倒计时的紧迫、截拍瞬间的悬念——拍卖界面的要点是出价的流程、…
实战应用:用在哪里 强化连败七次是什么体验?幸运值机制给失败的玩家一个隐性的承诺:每次失败累加幸运值,幸运值越高下一次的成功…
实战应用:用在哪里 审计日志的价值在于不可抵赖:被改过的日志比没有日志更危险——纠纷的追溯、内部的追责都建立在「日志没被动过…
实战应用:用在哪里 活动结束给 3 万玩家发奖励:一次性群发让邮件表瞬间多 3 万行、投递的队列堵塞正常的通信。批量邮件的分…
实战应用:用在哪里 面对面的交易是传奇最经典的交互:两人面对面、各自放入物品与金币、双方确认后成交。交易的协议要点是会话的建…