#游戏开发

没有源码，怎么在别人的游戏里造自己的功能

通过两款《幻兽帕鲁》Mod 的完整开发过程，解释如何在没有官方源码的情况下，利用 Unreal Engine 运行时反射系统和 UE4SS 理解、验证并调用游戏内部接口。

种下2026/07/19 最后修剪2026/07/24 约8 分钟 常青

这几天做了两个《幻兽帕鲁》的 Mod，上传到 Steam 创意工坊后反响还不错——零宣传，三天几百人订阅，八百多独立访客。

Steam Workshop 数据截图 零宣传，三天八百多独立访客。

两个 Mod 分别解决了两个痛点：公会罗盘把队友的方向、名字和距离显示在屏幕顶部的原生罗盘上，不用反复打开地图找人；智能生产队列报一个成品就自动拆解材料依赖，从下级材料一路排产到成品。

但我想聊的不是这两个功能本身。我想聊一个更根本的问题：我没有《幻兽帕鲁》的一行源码，是怎么改它的游戏的？

这道题的答案，比 Mod 本身更有意思。

手绘风格的走廊里，几扇门上贴着代码标签，探险者举着灯在读门牌 每个房间门上都贴着标签，但房间内部看不到。

一、游戏自己把”目录”贴在了墙上

大多数人对”改游戏”的想象是这样的：拿到源代码 → 修改 → 重新编译。没有源码，理论上什么也改不了。

但 Unreal Engine 做了一件自己可能都没意识到的事。

为了支撑自己的蓝图系统、网络同步和序列化，它编译出来的游戏虽然不暴露源码，却在运行时的内存里保留了大量关于”这个游戏里有什么”的信息——每个类叫什么、有哪些函数、函数接受什么参数、返回什么类型。

这些信息不是泄露，是引擎自己运行必须携带的东西。

把它想象成一栋大楼。你拿不到施工图纸，但每个房间的门上都贴着门牌号、用途和里面的设备清单。你不需要破门——从走廊里就能看到每个房间是干什么的。

社区有一个工具叫 UE4SS，可以把自己注入到正在运行的游戏进程里，把所有这些”门牌”扫描出来，生成一份几十万行的目录——Object Dump。内容大概长这样：

PalUIConvertItemModel
Initialize()
CanStartProduction()
StartProduction()

PalUIProductSettingModel
SelectRecipe()
SetProductNumByInput()

它在说：游戏里存在一个叫 PalUIConvertItemModel 的类，上面挂着三个公开函数。

但函数体里面写了什么？不知道。它怎么扣材料、怎么跟服务器通信？不知道。能看到的只有签名——门牌上写了这个房间是干什么的，但房间内部你看不到。

二、从玩家能理解的名词反向搜索

几十万行目录不可能逐行读完。但好消息是：你不需要读懂全部，只需要找到你要的那几个房间。

方法很简单——从玩家能理解的名词出发，反向搜索。

要搞清楚生产系统，就搜 Production、Recipe、WorkBench、Remain、ItemSlot。找到候选类之后，顺着它暴露的函数和属性继续追踪。A 类引用了 B 类，B 类又持有 C 类，一层一层把调用链拼出来：

玩家看到的工作台界面
→ 界面背后有一个 UI Model
→ UI Model 绑定了一个底层的工作台 Model
→ 下层有一个专门管配方和数量的 Model
→ 它上面挂着一个检查能否开始的函数
→ 还有一个真正发起生产请求的函数

这跟程序员阅读源码时做的事情一模一样。唯一的区别是：你看到的不是实现细节，而是接口之间的引用关系。相当于你有一张”谁调用了谁”的路线图，但没有每段路内部的施工细节。

三、先只读，别碰任何东西

找到了候选接口之后，人的本能冲动是：立刻调用它试试。

但这是最危险的一步。你根本不知道这个函数被普通玩家调用时会发生什么——服务器会不会拒绝、材料会不会凭空消失、存档会不会损坏。

所以第一步永远是写一个只读探针：把运行时的对象抓出来，读取它的属性，输出到日志里。

-- 只读探针，不修改任何游戏状态
local model = FindObject("PalUIConvertItemModel")
Log("剩余生产数量: " .. model:GetRemainCreateNum())
Log("输出栏状态: " .. model:GetProductSlot())
Log("可用配方: " .. model:GetRecipes())

能读到数据，说明三件事同时成立：对象在当前场景下存在、路径正确、你有权限访问。读不到，说明至少有一个假设是错的。

这一步的意义在于：所有假设都在零风险的情况下验证。 不会扣材料、不会改存档、不会向服务器发送任何错误请求。确认读取正常后，才允许进入下一步。

四、本质上是在”替玩家按按钮”

只读验证全部通过，终于可以第一次调用一个会修改游戏状态的函数了。

但这里藏着一个最容易误解的地方：Mod 的代码并没有自己管理材料、没有自己算配方、没有自己写网络通信的代码。它做的事情比想象的简单得多——

在合适的时机，替玩家调用了游戏本来就有的接口。

uiModel:Initialize(workbenchModel)       -- 绑定当前工作台
setting:SelectRecipe(recipeId)           -- 选配方
setting:SetProductNumByInput(count)      -- 设数量

if uiModel:CanStartProduction() then     -- 检查能不能开始
    uiModel:StartProduction()            -- 开始，走游戏自己的网络请求
end

材料扣除、配方验证、网络同步、其他玩家看到状态变化——全是游戏自己的代码在完成。Mod 只是在”帮玩家按了一个原本需要手动按的按钮”。

这是整个方法论里最重要的一条原则：尽量复用游戏的原生接口，不要自己重写游戏逻辑。 你写的代码越少，越不容易和游戏更新冲突，也越不需要去处理服务器权限和网络同步这些真正复杂的问题。

五、本地说了不算，服务器说了才算

联机 Mod 还有一个特别容易踩的坑。

StartProduction() 执行成功，只说明 UE4SS 帮你把函数调用发出去了。但接下来可能发生很多事：网络波动丢了这个请求，服务器拒绝了它，服务器接受了但状态还没同步回你的客户端。

所以不能写成”调用完就认为成功了”，必须加一个确认环：

发送生产请求 → 保留一个 pending 标记
→ 等服务器把工作台的最新状态同步回来
→ 确认配方和数量跟刚才发的一致 → 成功，删除队首
→ 超过等待时间还没对上 → 保留队首，告知玩家服务器未确认

这个原则适用于所有联机 Mod：本地代码只能表达意图，服务器同步回来的状态才是最终真源。 把”我发出去了”等同于”服务器接受了”，是联机开发里最常见的 bug。

六、不是逆向，是引擎自己留了路

如果把这整个过程和传统印象中的”逆向工程”对比一下，区别是很明显的：没有用调试器逐行跟踪二进制，没有任何反汇编。

路径总结下来只有三步：

  1. Unreal Engine 的反射系统在运行时暴露了大量接口签名——这不是漏洞，是引擎自己运行必须携带的元数据
  2. UE4SS 把它们扫描成一份可搜索的目录
  3. 开发者通过名词反向搜索找到候选接口，用 Lua 探针先读后写，逐步验证

核心不是”突破了什么”，而是”发现了引擎本来就暴露了什么”。

一个反直觉的事实是：越复杂的商业游戏引擎，往往对 Mod 开发越友好。 不是因为官方特意支持，而是因为引擎架构越复杂，它需要携带的自我描述信息就越多——而这些信息，恰好成了外部开发者理解游戏内部结构的最佳入口。