https://plumephp.com/tags/%E8%A7%84%E5%88%99%E5%BC%95%E6%93%8E/Recent content in 规则引擎 on PlumePHPHugozh-CNThu, 28 Mar 2024 11:18:00 +0800https://plumephp.com/game-server-rule-script-sandbox-architecture/Thu, 28 Mar 2024 11:18:00 +0800https://plumephp.com/game-server-rule-script-sandbox-architecture/<h2 id="背景与问题">背景与问题</h2> <p>很多游戏团队都会走到这一步：策划希望不用发版就调整活动规则，运营希望写脚本批量处理玩家状态，研发希望把简单条件从代码里挪出去。脚本化确实能提高迭代效率，但它也会把生产环境暴露给不受控的逻辑。一个循环写错可能拖垮服务，一个权限放宽可能改错玩家资产，一个脚本版本丢失可能让复盘无从查起。规则脚本沙箱不是为了炫技，而是给可变逻辑装上边界、预算、审计和回滚。</p>https://plumephp.com/game-server-player-segmentation-architecture-design/Wed, 24 Jan 2024 09:42:00 +0800https://plumephp.com/game-server-player-segmentation-architecture-design/<h2 id="背景与问题">背景与问题</h2> <p>玩家画像系统一开始通常只是运营后台里的几个筛选条件：等级大于 20、七天未登录、充值金额超过 100。到了中后期，它会变成活动投放、礼包推荐、流失召回、风险隔离、A/B 实验、新手保护和客服优先级的共同底座。最容易出问题的地方不是标签算错一次，而是每个业务都自己算一份“玩家类型”，同一个玩家在活动服里是回流用户，在商城里是高价值用户，在风控里又被当成异常用户。玩家分层架构要解决的是：标签从哪里来，什么时候刷新，哪些业务可以用，出问题时如何解释。</p>https://plumephp.com/game-server-rule-evaluation-engine-architecture/Tue, 06 Dec 2022 10:19:00 +0800https://plumephp.com/game-server-rule-evaluation-engine-architecture/<p>运营和策划经常需要表达规则：等级大于 20、开服第 7 天、在某个国家地区、不是回流玩家、完成某条任务线、属于灰度组。早期项目会把这些条件写在活动代码里，每加一个活动就复制一遍。半年后，规则互相打架，性能不可控，客服也说不清玩家为什么看不到入口。规则评估引擎的意义，是把条件表达、上下文读取、结果解释和发布治理统一起来。</p>