从别家引擎迁到 Blue：最容易改错的五类命令

引擎迁移有两种做法：一种是整套版本重写，一种是保留脚本只换引擎。多数人选第二种，因为成本低。但第二种的坑在于，脚本能加载不等于行为正确，很多命令两边写法一样，效果却差一点，这一点差异在开区之后会被放大成事故。

一、先分清“能跑”和“跑对”

迁移完第一步是启动成功，第二步是每个功能点都跑一遍。很多人做到第一步就以为完成了，结果开区当天玩家反馈一堆“点了没反应”“数量不对”“重复领取”。

所以迁移要有一个功能清单，按模块逐项验证：对话、条件、给物品、扣货币、传送、定时触发。每个模块挑一两个代表脚本测，不用全测，但必须覆盖五类。

下面这五类，是迁移时最容易出问题的。

二、第一类：对话框与标签

这类问题最直观：对话框显示不全、按钮点了跳到错的页面、返回之后回不到主菜单。

不同引擎对换行符、按钮标签、跳转目标的解析有细微差别。有的引擎要求标签必须大写，有的允许小写；有的对行尾空格敏感，多一个空格就断行。

迁移时不要整段复制，先拿一个最简单的 NPC 试。三行文字加两个按钮，跑通了再往复杂里加。整段复制过来调试，出了问题根本不知道是哪一行。

还有一个常见现象是中文标点。标签里混进全角括号或全角逗号，引擎解析失败但不报错，只是这个按钮失效。

三、第二类：变量与条件

变量类命令是最容易“看起来正常、实际算错”的一类。

比如一个判断等级的条件，两个引擎都支持，但取值的边界不一样：一个是大于等于，一个是大于。差一个等号，玩家刚好卡在边界等级时行为完全不同，测试时很难发现。

再比如变量作用域。有的引擎里变量是全局的，换个 NPC 还能读到；有的引擎里是脚本内的，出了这个脚本就清空。迁移之后，原来能用的变量可能读出来是空值。

验证方法很土但有效：写一个测试 NPC，把关键变量的值直接显示在对话框里，点一遍看数字对不对。数字对了，逻辑才可能对。

四、第三类：物品与货币操作

给物品、扣物品、加货币、扣货币，这四类操作在迁移时最危险，因为它们直接连着玩家的资产。

常见错误有三个：数量参数的单位不一致（有的按个，有的按组）、扣物品时没判断背包是否足够、以及给物品失败时没有回滚。

第二个错误最容易造成事故。玩家背包满了，脚本还是扣了货币，东西没给出去，玩家直接投诉。迁移时要把每一个“先扣后给”的脚本都检查一遍，改成先判断再扣，或者给出失败提示。

第三个是原子性问题。多步操作中间失败，前面的已经生效，后面的没执行，数据就脏了。这类脚本迁移后必须手动测一遍失败分支。

五、第四类：地图与传送

传送类命令的差异主要在坐标和地图编号的写法上。有的引擎用地图名，有的用编号，迁移时混用会出现“传送到了但位置不对”或者“传送失败没提示”。

还有一个隐蔽的问题：安全区判定。传送落点如果落在安全区外，玩家可能被怪围住；落在安全区内，又可能影响某些需要战斗的玩法。

迁移时把每个传送点实测一遍，记录落点坐标。不要只看配置里写了多少，实际落点可能因为地图尺寸不同而偏移。

六、第五类：定时与活动触发

定时任务是迁移里最容易被忽略的。它在后台跑，平时没感觉，直到开区当天活动没开、BOSS 没刷、公告没发。

不同引擎的定时精度和触发方式不一样。有的按秒轮询，有的按整点触发；有的在引擎启动时重置计时，有的从上次时间继续。迁移之后，原本“每天二十点开活动”的脚本可能变成“启动后二十小时开”。

验证方法：把定时改成一分钟后触发，实际等一分钟看有没有执行。跑通了再改回真实时间。这一步花五分钟，能避免开区当天最难堪的事故。

七、迁移的正确顺序

第一步，只迁一个 NPC，跑通对话、条件、给物品三件事。

第二步，迁一套完整功能，比如回收系统，测正常流程和异常流程。

第三步，迁定时类脚本，用缩短时间的方式验证。

第四步，全量迁移，按功能清单逐项打勾。

每一步都要在一个干净的测试服上做，不要直接在正式服上改。正式服改坏了，回滚的成本比重新搭一个测试服高得多。

八、验收清单

迁移完成前，这五项必须全过：所有 NPC 按钮都有反应、所有条件判断在边界值上正确、所有物品操作在背包满时不吞货币、所有传送落点正确、所有定时任务按预期触发。

五项之外再加一条：找三五个玩家实际玩半小时。玩家的操作路径和测试不一样，他们能点出你想不到的角落。

迁移本身不难，难的是承认“能启动”只是开始。把这五类过一遍，迁移才算完成。