# 先记住这三个词

名称	作用
需求	先判断这次能不能触发
花费	触发前要扣掉什么
获得	触发成功后要增加什么

这是编辑器里最常见的一组规则。

# 最常见的用法

在控件里，你会最常看到这几个区域：

• 显示需求属性
• 点击后消耗玩家属性 或 点击后消耗对象属性
• 点击后玩家获得属性 或 点击后对象获得属性

所以可以把它理解成一条很直观的流程：

# 一个简单例子

假设有一个 制作木剑 控件：

类型	内容
需求	等级大于等于 3
花费	木材 - 5，金币 - 20
获得	木剑 + 1

这样玩家点击时，就会先判断等级，再扣木材和金币，最后发放木剑。

# 需求和花费不是一回事

这是最容易混在一起的地方。

类型	会不会真的改数值
需求	不会
花费	会
获得	会

例如：

• 等级 >= 10 只是在判断
• 金币 - 100 才是真的扣除

# 一条规则里可以设置什么

在编辑器里，一条条目通常会看到这些内容：

项目	作用
属性	这条规则针对哪个属性
比较方式	用大于等于、等于、小于来判断
目标数值 或 目标文本	具体比较值或写入内容
公式	让数值随状态变化
概率 / 权重	让这一条不是每次都固定发生
前置条件	给这一条再加一层条件

# 比较方式怎么用

在 需求 里最常用的是这三种：

• 大于等于
• 等于
• 小于 / 不包含

例如：

• 金币大于等于 100
• 身份等于 会员
• 某段文本不包含某个词

# 公式什么时候会用到

需求、花费、获得 里都可以配 公式。

这表示数值不一定是固定数字，也可以跟着当前状态变化。

例如：

• 升级花费会越来越高
• 恢复量会受加成影响
• 某个奖励会跟等级一起变大

# 获得不只会改数字

在一些位置里，获得 还可以把内容写到字符串或表格里。

例如在控件里，你会看到 点击后修改表格/字符串 这样的区域。

这类用法适合：

• 改一段文本
• 写一条说明
• 把结果存到字符串里给别的地方显示

# 对象相关的版本

如果控件绑定了对象，你还会看到对象版本的配置：

• 需求对象属性
• 消耗对象属性
• 对象获得属性

这时修改的目标就不再只是玩家本身，也可能是当前命中的对象。

# 什么时候会看到这套规则

除了控件，这套规则在别的地方也会出现，例如：

• 场景解锁条件
• 字符串状态切换条件
• 一些插件条件

虽然位置不同，但读法是一样的：先判断，再执行。

# 读一条配置时，可以这样看

1. 先看是不是有 需求
2. 再看会不会 花费
3. 最后看会 获得 什么

这样看起来会很快。

# 看完这页后

下一步通常会继续看：

1. 场景与物品
2. 字符串与图标

你可以把它理解成：

当前这条记录满足后，后面的同级条目不再继续执行。

它很适合做：

• 优先级分支
• 条件分组
• 命中一个奖励档位后停止往下掉

例如：

1. 如果评分 >= 90，给 S 奖励并停止
2. 否则如果评分 >= 80，给 A 奖励并停止
3. 否则给 B 奖励

这就很像可视化配置版的 if / else if / else。

# 13. 概率与权重不是一回事

当前每条记录都可以配置概率，而且概率还能挂公式。
这意味着概率本身也能动态变化。

例如：

• 暴击率随幸运值变化
• 掉落率随地图难度变化
• 某事件触发率随章节推进上升

而权重随机更接近：

多条都进入候选池后，按权重从候选项里选结果。

例如 20 / 20 / 40，更接近：

1 : 1 : 2

它很适合：

• 抽奖池
• 随机事件池
• 多档位奖励池
• 随机台词池

# 14. 需求关系里的“全部满足 / 任意满足”

当前很多需求列表都支持关系模式，例如：

• &&：全部满足
• ||：任意满足

这意味着你可以很自然地做出：

# 全部满足型

• 有钥匙
• 等级够
• 不在战斗

# 任意满足型

• 法师可进
• 圣职可进
• 有通行证也可进

这让你不写脚本也能做出不少条件分支。

# 15. 字符串模式也是属性转化的一部分

这点很容易被忽略。

当前总属性条目不只能写数值，还可以切到字符串模式，把结果写到字符串目标上。

这意味着同一套规则体系不仅能：

• 扣血
• 加钱

还可以：

• 改提示文案
• 改状态标签
• 改公告栏文本
• 写入动态字符串目标

所以属性转化其实也是内容更新系统的一部分。

# 16. 事件和控件为什么都在用这套结构

因为从系统设计上看，它们本质都在做相同的事：

• 先判断
• 再执行

区别只在于“谁来触发它”。

触发源	常见用途
控件	玩家主动点击
事件	系统自动触发
AI 智能体	输入前校验、结果写回、额外联动
其他插件入口	把某个系统动作接进现有规则层

也就是说，属性转化更像一套通用执行模型：

• 控件拿它做主动规则
• 事件拿它做自动规则
• AI 和其他系统拿它做结果落地

它们只是触发源不同，底层心智是一致的。

# 17. 和对象系统结合时会再多一层

当前项目里还有对象版的需求 / 花费 / 获得。
也就是说，规则目标不一定是玩家普通属性，还可以是：

• 对象属性
• 对象筛选结果
• 对象数量或对象状态

这一步会把玩法从“简单数值游戏”推进到“有实体结构的系统游戏”。

# 18. 什么时候该从属性转化升级到脚本

如果你已经遇到下面几类场景，很多内容就会开始交给脚本处理：

• 需要多层 if / else
• 需要遍历对象列表后再决定扣什么、给什么
• 需要把表格、字符串、对象状态一起拼起来判断
• 需要在成功后继续触发弹窗、特效、AI、跳转
• 需要把一次触发拆成明显的前置、执行、后置阶段

常见分工是：

• 需求 / 花费 / 获得：负责基础门槛和基础结算
• 组合属性 / 动态字符串：负责衍生数值和衍生文案
• 脚本：负责复杂分支、多系统编排、前后置流程
• AI / 特效 / 弹窗：负责解释、反馈、呈现已经发生的结果

# 19. 一个更贴近当前版本的理解

把属性转化看成：

项目规则的声明式骨架。

它最擅长的是：

• 规则显式
• 结构稳定
• 可视化配置
• 便于非程序思维维护

而脚本更适合承接：

• 特殊分支
• 跨系统流程
• 动态模板
• 复杂对象遍历

两者不是替代关系，而是“骨架 + 扩展”的关系。

# 20. 一种常见写法

如果你要做一个复杂控件，很多内容会按这个顺序整理：

1. 先写全局需求
2. 再写必须真实扣除的花费
3. 再写获得结果
4. 只在必要时给单条加子条件
5. 最后再看需不需要概率、权重或脚本

这样规则、配置和排查顺序会更清楚。

# 21. 一个常见的整理方式

做 LP 配置时，可以始终问自己三句话：

1. 这件事发生前，门槛是什么？
2. 它发生时，真实要付出什么？
3. 它发生后，系统要留下什么结果？

这三句话，基本就对应：

• 需求
• 花费
• 获得

# 进一步阅读

• 想看这些规则最常挂在哪里：看场景与物品和事件系统
• 想把数值规则升级成更复杂计算：看公式和组合属性脚本
• 想把结算结果变成动态文案：看字符串与图标和动态字符串脚本
• 想在对象上下文里做差异化规则：看类与对象和对象与物品
• 想把执行成功后的反馈做成画面表现：看客户端特效系统和交互特效脚本
• 想理解 AI 智能体结果怎样回写项目状态：看AI智能体插件和AI 智能体脚本

占位图：总属性条目编辑器，可展示“比较模式、目标属性、固定值、公式、概率、子条件、权重模式”的完整布局。