|
一、设计理念：预分配变量池 + 前缀编码，用最简单的方式管理最复杂的生命周期
理解 VV 引擎的变量系统，先要理解它的核心设计思路 ——预分配变量池，用变量名前缀编码类型和生命周期。
什么是预分配变量池？引擎启动时，为每种变量预分配固定数量的存储空间 —— 比如 U 变量预分配 500 个（U0-U499），G 变量预分配 1000 个（G0-G999）。这些变量的存储空间是固定的，你不需要创建或销毁，直接用编号访问就行。用就有值，不用就是默认值（0 或空字符串）。
这种设计和现代编程语言的动态变量完全不同。现代语言里你需要什么变量就声明什么，变量名可以任意取，数量不限。但传奇脚本的变量系统是固定的 —— 变量名只能是前缀加编号（比如 U1、T0、G50），数量有限（每种几百到一千个）。这种 "限制" 其实是有意为之的设计选择。
第一，访问速度极快。 变量就是数组里的一个元素，用编号直接索引，O (1) 时间访问，不需要哈希查找，不需要动态分配内存。对于脚本这种高频执行的环境，性能很重要。
第二，生命周期由引擎管理。 每种变量的生命周期是固定的 —— 哪些下线保存、哪些切换地图清空、哪些 NPC 对话结束归零，全部由引擎自动处理。开发者不需要自己写保存和加载逻辑，用对变量前缀就行。
第三，变量名自带语义。 看到 U1 就知道这是可保存的数字型玩家变量，看到 G0 就知道是全局可保存的数字变量，看到 P5 就知道是 NPC 对话内的临时变量。变量前缀本身就说明了这个变量的类型和生命周期，不需要额外注释。
第四，避免命名冲突。 变量名是前缀加编号，不存在两个变量同名的问题（只要编号不重复）。在大型项目里，多个开发者写的脚本不会因为变量名撞车而出 bug。
当然这种设计也有代价：变量数量有限，需要规划使用；变量名没有语义（U1 不知道是存什么的），需要靠注释或规划；不能动态创建变量。但对于传奇脚本这种场景，这些代价是可以接受的，换来的是简单、高效、可预测。
前缀编码是这套设计的精髓。每个前缀代表一组属性：作用域（全局 / 玩家 / 怪物）、数据类型（数字 / 字符）、生命周期（持久化 / 下线丢失 / 切换地图丢失 / NPC 结束丢失 / 每日重置）。十几种前缀，每种组合对应一种具体的使用场景。理解了每个前缀的含义，就理解了整个变量系统。
二、系统变量：A/G/I 三种，全局共享的跨玩家数据
系统变量是全局变量 —— 所有玩家共享同一份，不绑定特定玩家。适合存全服级别的数据：活动开关、全局计数、服务器配置、全服统计等。
A 变量是字符型系统变量，1000 个（A0-A999），重启服务器保存，存在 Mir200/GlobalVal.ini 文件里。字符型意味着可以存字符串，适合存全局的文本数据 —— 比如当前活动名称、服务器公告、全局配置 JSON、全服统计的字符串表示。文档里的示例就是把一个 table 转成 JSON 存在 A1 里，说明 A 变量可以存结构化数据（只要序列化成字符串）。
G 变量是数字型系统变量，1000 个（G0-G999），重启保存，也存在 GlobalVal.ini 里。数字型适合存全局的数值数据 —— 比如全服击杀 BOSS 总数、活动剩余时间、当前版本号、全局开关（0 关 1 开）、全服玩家累计充值数。数字变量做计数和开关最方便。
I 变量是数字型系统变量，1000 个（I0-I999），重启服务器不保存。和 G 变量的区别就是不持久化 —— 服务器重启后 I 变量归零，G 变量还在。I 变量适合存临时的全局数据 —— 比如当前在线人数缓存、本轮活动的临时计数、服务器运行时的状态标记。这些数据不需要跨重启保存，重启后重新计算就行。
三种系统变量的设计思路是：按数据类型（字符 / 数字）和持久化需求（保存 / 不保存）分两种维度，组合出三种变量。A 是字符 + 保存，G 是数字 + 保存，I 是数字 + 不保存。缺少的 "字符 + 不保存" 组合没有单独的变量类型，如果需要临时全局字符串，可以存在 I 变量对应的编号逻辑里或者用其他方式（不过文档里没有字符型非持久化全局变量，可能是因为全局临时字符串需求较少）。
系统变量的操作接口是 getsysvar 和 setsysvar，传变量名（比如 "A1""G0""I50"）和值。因为是全局变量，不需要传玩家对象 —— 所有玩家读写的都是同一份。
实际使用中的心得是：系统变量要规划编号，不要随便用。1000 个看起来多，但大型项目里全局变量用得很快 —— 活动系统、经济系统、统计系统、配置系统都可能需要全局变量。建议按模块分段 ——G0-G99 给活动系统用、G100-G199 给经济系统用、G200-G299 给统计系统用，每个模块留足够的空间。A 变量同理。还有，A 变量存 JSON 时注意字符串长度限制（文档里没明确说，但 ini 文件的单值长度可能有限制，太长的数据考虑用数据库或文件存储）。
还有一个重要的心得：系统变量是全服共享的，并发写入要注意。多个玩家的脚本同时修改同一个 G 变量，可能会有竞态条件 —— 比如两个玩家同时执行 "G0 = G0 + 1"，可能只加了一次而不是两次。如果需要精确的全局计数，考虑用引擎的原子操作（如果有的话）或者在单一线程 / 定时器里做计数，不要在玩家脚本里直接累加全局变量。
三、玩家变量：十三种前缀，覆盖从临时到持久化的全部需求
玩家变量是绑定到具体玩家的变量 —— 每个玩家有自己独立的一份，互不干扰。这是变量系统里最庞大的部分，有十几种前缀，每种的生命周期和用途都不同。
第一类是对话级临时变量 ——P 变量。 P 是数字型个人变量，1000 个（P0-P999），仅在当前 NPC 对话有效，当 Close 对话时所有 P 变量归零。这是生命周期最短的玩家变量 —— 只在一次 NPC 对话过程中有效，对话一关就没了。
P 变量的设计目的非常明确：做 NPC 对话内的临时状态。比如玩家点 NPC 打开对话，选择了某个选项，需要记住这个选择供后续对话使用，就用 P 变量存。对话结束后这些临时状态不需要保留，自动归零，不会占用持久化空间，也不会污染下一次对话。这是一种非常干净的设计 —— 最短生命周期的变量用最短的前缀，开发者看到 P 就知道 "这个只在本次对话里有用"。
第二类是会话级临时变量 ——S、N、D 变量。 这三种都是下线不保存的玩家变量，玩家下线后归零，重新上线后是默认值。区别在于：
- S 是字符型，1000 个，存临时字符串
- N 是数字型，1000 个，存最常用的临时数字
- D 是数字型，1000 个，文档里标注 "摇骰子变量"
D 变量被特别标注为 "摇骰子变量"，说明它可能有特殊的用途或行为（比如和摇骰子系统关联，或者有随机数相关的特殊处理）。虽然本质上也是下线不保存的数字变量，但引擎给了它一个独立的前缀，可能是为了和普通临时变量区分开，避免摇骰子相关的逻辑和其他临时变量冲突。
这三种变量适合存玩家在线期间的临时状态 —— 比如当前的任务进度缓存、临时的 buff 计数、在线活动的参与状态、计算过程中的中间值。这些数据只在本次在线期间有用，下线后不需要保留。用 S/N/D 变量而不是可保存变量，可以节省数据库空间，也避免了不必要的持久化开销。
第三类是地图级临时变量 ——M 变量。 M 是数字型个人变量，1000 个（M0-M999），下线不保存，而且切换地图时清空。比 S/N/D 更严格 —— 不只是下线，连换地图都会丢失。
M 变量适合存和当前地图相关的临时状态 —— 比如玩家在副本里的进度、在活动地图里的积分、在当前地图的任务标记。换地图后这些状态就失效了，自动清空，不需要你手动处理。这种 "切换地图清空" 的设计很贴心 —— 很多和地图绑定的临时数据，换地图后本来就该失效，引擎自动帮你清了，避免残留状态导致 bug。
第四类是持久化玩家变量 ——U 和 T 变量。 这两种是可保存的玩家变量，存在 SQL 角色数据库里，玩家下线后再上线数据还在。
- U 是数字型，500 个（U0-U499），最大值 21 亿
- T 是字符型，500 个（T0-T499），最大 1000 字符长度
U 和 T 是玩家变量系统里最重要的两种 —— 所有需要跨上线保留的玩家数据都存在这里。任务进度、玩家称号标记、累计计数、特殊状态、自定义数据，全部靠 U 和 T。500 个数字 + 500 个字符，对于大部分版本来说够用，但大型项目需要仔细规划。
U 变量最大值 21 亿（应该是有符号 32 位整数的上限 2147483647），存一般的计数和数值足够了。T 变量最大 1000 字符，存短文本、JSON 配置、列表数据够用，但不要存太大的结构化数据。
第五类是每日重置持久化变量 ——J 和 Z 变量。 这两种也是可保存的，存在 SQL 数据库里，但有一个特殊行为：每晚自动 12 点重置。
- J 是数字型，500 个（J0-J499）
- Z 是字符型，500 个（Z0-Z499）
每日重置的设计非常实用 —— 很多游戏数据是 "每日刷新" 的：每日任务进度、每日签到、每日抽奖次数、每日副本次数、每日活动积分。这些数据需要持久化（玩家下线再上线还在），但每天零点要自动重置。如果没有 J/Z 变量，你需要自己写一个每日零点的定时任务，遍历所有玩家重置变量 —— 既麻烦又耗性能。有了 J/Z 变量，引擎自动帮你每日重置，省了大量工作。
文档里特别提醒 "合区或关停服务器请错开 00:00 点"—— 因为每日重置是在零点执行的，如果在零点附近合区或关服，可能会导致重置逻辑异常或者数据丢失。这个细节很重要，做运维操作时要注意避开零点。
第六类是个人标记。 整数型个人变量，可保存，只有 0 和 1 两种状态。这本质上是布尔变量 —— 只有开 / 关两种状态，适合做任务完成标记、功能解锁标记、条件判断标记。
个人标记没有前缀字母，用 getflagstatus 和 setflagstatus 接口访问，索引范围 1-800。800 个 0/1 开关，对于任务系统来说非常够用 —— 每个任务一个标记，完成了设 1，没完成是 0。
为什么有了 U 变量（数字型可保存）还需要个人标记？因为个人标记更节省空间 —— 一个布尔值只需要 1 位，而 U 变量是整数（4 字节）。800 个布尔值只需要 100 字节，而 800 个 U 变量需要 3200 字节。对于大量的开关型数据（任务标记），用个人标记比用 U 变量更节省数据库空间。而且个人标记只有 0/1 两种值，语义更明确 —— 看到 getflagstatus 就知道是在判断一个开关，看到 getplaydef (actor, "U1") 还得想一下 U1 存的是什么。
十几种玩家变量看下来，设计思路非常清晰：按生命周期从短到长、按数据类型数字 / 字符、按是否持久化、是否每日重置，正交组合出各种变量类型。每种变量对应一种具体的使用场景，开发者根据数据的生命周期和类型选择对应的变量前缀，引擎自动处理保存和清除。这种设计让变量的使用变得可预测 —— 你选对了前缀，就不用担心数据该保存的时候没保存、该清除的时候没清除。
四、自定义临时变量：N\(/S\)前缀，突破固定数量限制
固定数量的变量虽然有规划上的好处，但有时候确实不够用 —— 或者你想要一个有语义的变量名，而不是冷冰冰的 "N123"。VV 引擎提供了自定义临时变量来解决这个问题。
- N$ 开头：自定义数字变量
- S$ 开头：自定义字符变量
用法和普通变量一样，用 setplaydef 和 getplaydef 读写，只是变量名不是固定的编号，而是你自己取的名字 —— 比如 "N\(任务进度""S\)当前目标名称 "。
setplaydef(actor, "N$变量1", 1)getplaydef(actor, "N$变量1")
自定义变量的生命周期应该和 N/S 变量类似 —— 下线不保存（文档里没有明确说，但从命名来看 N\(对应N变量、S\)对应 S 变量，应该都是临时的）。它们的价值在于：
第一，变量名有语义。 "N$ 已接取的任务 ID" 比 "N47" 清楚得多，代码可读性大幅提升，不需要额外注释说明这个编号存的是什么。
第二，数量不受限。 固定变量只有 1000 个，用完就没了。自定义变量可以动态创建，理论上数量不限（受内存限制），不用担心编号不够用。
第三，可以用动态变量名。 比如变量名可以根据运行时数据拼接 ——"N$ 任务_"..taskId，这样每个任务有独立的变量，不需要预先分配编号。做动态内容时非常方便。
但自定义变量也有局限：它们是临时的（下线不保存），不能替代 U/T 变量做持久化存储。而且自定义变量的性能可能比固定编号变量稍差（因为需要哈希查找而不是数组索引），高频访问的变量还是用固定编号更高效。
文档里还给出了一个 getVarCache 函数的示例，展示了如何从 T 变量（字符型持久化变量）里解析键值对数据 —— 把多个键值对存在一个 T 变量里（格式 "key1=value1,key2=value2"），用的时候解析出来。这是一种在变量数量有限的情况下扩展存储能力的技巧 —— 一个 T 变量可以存多组数据，相当于把一个变量当字典用。虽然 T 变量只有 500 个，但每个都可以存结构化数据，实际能存的信息量远大于 500 条。
这个示例也反映了传奇脚本开发的一个常见技巧：在固定数量的限制下，用序列化和编码来扩展存储能力。变量数量不够？那就一个变量存多个值，用 JSON 或自定义格式序列化，读写时解析。这种技巧在 U/T/J/Z 变量数量紧张时非常有用。
五、怪物变量：Q 和 W，给怪物用的临时变量
Q 和 W 变量比较特殊 —— 它们是可以给怪物使用的变量。
- Q 是数字型变量，200 个（Q0-Q199），下线不保存，可给怪物使用
- W 是字符型变量，200 个（W0-W199），下线不保存，可给怪物使用
"可给怪物使用" 意味着这些变量不只是玩家能有，怪物对象也能有自己的 Q/W 变量。这在做怪物 AI、怪物状态、副本怪物逻辑时非常有用 —— 比如给 BOSS 存一个阶段标记（Q0=1 是一阶段，Q0=2 是二阶段），给怪物存一个目标玩家 ID，给怪物存一个特殊技能的冷却计数。
为什么怪物变量只有 200 个而玩家变量有 1000 个？因为怪物的临时状态通常不需要那么多 ——BOSS 的阶段、技能冷却、目标标记这些加起来也就几十个，200 个足够了。而且同屏可能有很多怪物，如果每个怪物都有 1000 个变量，内存开销会很大。200 个是在功能和性能之间的平衡。
Q/W 变量的生命周期是下线不保存 —— 对于怪物来说，怪物被清除或服务器重启后变量就没了，这符合怪物临时状态的需求。怪物的持久化数据（如果有的话）应该存在怪物表或数据库里，Q/W 只存运行时的临时状态。
实际使用中的心得是：怪物变量用 getplaydef 和 setplaydef 访问时，传怪物对象而不是玩家对象。接口名虽然叫 playdef，但 "可给怪物使用" 意味着传怪物对象也能工作。做怪物脚本时，把怪物对象传给 setplaydef/getplaydef，就能读写该怪物的 Q/W 变量。
六、应用场景：变量系统在实际开发中的用法
把十几种变量过完，结合传奇脚本的开发实践，总结几个最典型的应用场景。
任务系统是变量系统最大的用户。任务接取状态用个人标记（0 未接、1 已接），任务进度用 U 变量（比如杀了几只怪），任务完成标记用个人标记，每日任务进度用 J 变量（每日重置）。任务系统的变量使用量很大，800 个个人标记 + 500 个 U 变量，大型任务线需要仔细规划编号。
活动系统是另一个大户。全局活动开关用 G 变量（全服共享），活动剩余时间用 I 变量或 G 变量（看是否需要跨重启保存），玩家个人活动积分用 U 变量或 J 变量（看是否每日重置），玩家活动参与状态用 N 变量（临时），活动内的临时计数用 P 变量（NPC 对话内）。活动系统通常同时用到系统变量和玩家变量，全局状态用 G/I，个人状态用 U/J/N。
经济系统用变量做计数和限制。玩家每日充值额度用 J 变量（每日重置），玩家累计消费用 U 变量（持久化），全服经济指标用 G 变量（全局持久化），交易临时状态用 P 变量（对话内），摇骰子相关用 D 变量。
副本系统用 M 变量（切换地图清空）存副本进度。玩家进副本时在 M 变量里记录进度，副本内的操作更新 M 变量，出副本（换地图）后 M 变量自动清空，下次进副本重新开始。这种设计非常干净，不需要手动清理副本状态。
新手引导用 N/S 变量存引导进度。玩家当前引导到第几步存在 N 变量里，引导的临时文本存在 S 变量里，下线后重置（新手上线后重新开始引导或从持久化的进度继续）。
怪物 AI 和 BOSS 战用 Q/W 变量。BOSS 的阶段标记、技能冷却、目标记录、特殊状态全部存在 Q/W 变量里。怪物脚本里读写这些变量来控制 AI 行为。
这些场景的共同特点是：根据数据的生命周期和作用域选择对应的变量类型。需要跨上线保存的用 U/T，每日重置的用 J/Z，临时的用 N/S/D，地图相关的用 M，对话内的用 P，全局的用 G/A/I，怪物的用 Q/W，开关型的用个人标记。选对了变量类型，开发就顺了；选错了，要么数据丢失，要么空间浪费，要么需要手动处理本应自动处理的生命周期
| 
