尝试AI辅助逆向马拉松前哨地图

本文系用户投稿，不代表机核网观点
本文含有AI生成，请注意甄别
⚠️ 未经作者授权禁止转载
 0 成果展示

马拉松的游戏原始地图

在工作中往会遇到拆解某个游戏地图的客观需求，同类型游戏地图的设计规律是制作新地图、机制、玩法等设计的重要参考，也是作为关卡策划重要的成长和训练方式。
一 目前在拆解地图上的尝试：
如果有现成的逆向工具，那么就可以直接逆向获得其余游戏的场景的模型甚至是工程文件，在这个基础上再进行关卡白模的整理、分析等，可以做到既准确又高效。如果没有逆向资源，往往通过大量游戏游玩截图以及分析攻略找到地图尺寸、动线、Metrics等关卡设计的关键要素。本次选择了Bungie最新pvpve搜打撤游戏《失落星船：马拉松》前哨地图进行拆解。主要原因有两点：
1. 对于逆向拆解这件事而言，Bungie系列难度极大，从光环到命运再到马拉松，都是使用了Bungie的祖传Tiger引擎，不同于已经广泛应用的UE，资料甚少，全网乃至外网能拆解更是少之又少，能充分发挥AI的价值。
2. 作为最新的搜打撤新作，在关卡设计上确实有不少创新，可以通过AI还原进一步分析设计。
总体的输入输出：
输入：直接从steam下载的马拉松版本PKG 包
输出：Blender等主流模型软件重构地图模型
工具：cursor，claude4.6
效率：
前期试错时间较长，多次对话尝试方案失败。但是完成跑通完成技术文档编写之后，大概3-5小时可完成一张地图
具体实践流程：
01获取游戏资源文件
直接从 Steam 游戏安装目录中定位游戏的核心资源包文件。游戏的所有美术资源（3D 模型、贴图、场景数据、音效等）都被打包压缩存储在 .pkg 格式的文件中。这些文件不能直接打开，需要通过专门的工具进行解析。 
主要输出结果：
文件数量：128 个包文件
数据规模：约 85 万个数据条目
压缩方式：Oodle 算法（需要专用解压库）
提示词输入：
你是一名专业的游戏工程师，目前本地有一游戏项目文件，现需要你针对游戏项目的包体文件进行初步的逆向分析。
1. 现在给予你权限该文件权限，D:\Program Files   (x86)\Steam\steamapps\common\Marathon可以任意操作该目录下的任何文件，禁止操作其余文件；2. 请阅读文件目录，重点了解该文件夹下package和bin文件的架构和内容。3. 请首先分析其整体文件数量、数据规模以及项目压缩方式。4. 想要在引擎Ue项目里面打开，可以转化成fbx或者 dcc能够读取的文件格式，如何实现？请以文件夹中outpost的pkg文件为例，进行思考
02 解包与数据索引
对所有包文件进行解压解码，识别每个数据块的类型，建立完整的数据索引。每个包文件内部包含成千上万个数据条目，每个条目都有类型标记。这一步需要遍历所有包，给每个条目建立索引——区分哪些是 3D 模型数据、哪些是场景布局、哪些是贴图纹理。同时解析条目之间的"引用关系"（类似超链接），为后续追踪做准备。
核心工作：解压 → 分类 → 建索引 → 解析引用关系
使用工具：marathon-extractor（自研 Rust 程序）
AI整理的主要数据类型：

提示词输入：
根据之前的分析。现在需要你针对上述目录对所有包文件进行解压解码，并且识别每个数据块的类型，建立完整的数据索引关系：1. 尝试自己制作解码工具对包体文件进行解码；2. 解码成功后可以将资源类文件进行整理，包括场景、模型、贴图、材质；
这一步发现，自己制作解码工具，消耗时间与token过久，于是重新输入：
自己制作消耗较大，请改变思路：尝试直接遍历github上所有可能相关的解码文件，整理可能的解压——提取方案；
产出结果
这里AI通过遍历Github上可能工具的方法，整理出三个方法：
这里使用的工具基本都是UE项目无关的工具，因此我并不了解；根据AI提供的信息，方案一使用新工具，可能可行；马拉松不是UE项目，大概率会出问题，方案三之前尝试过在Ninja Ripper，通过截帧扫描，大概率效果不好，且消耗极大，因此果断选择方案一直接进行尝试；

03提取 3D 模型
从原始数据中还原每一个独立的 3D 模型，导出为通用格式文件。游戏中的每个物件（一面墙、一根柱子、一台设备）都对应一组顶点坐标和三角面数据。但这些数据散落在不同的包文件中，且通过多层引用关系间接关联。这一步的核心工作是：顺着引用链追踪到实际的几何数据，再将其转换为 Blender 能直接读取的标准 OBJ 格式。
同时，由于游戏引擎和 3D 软件使用不同的坐标系（游戏中 Y 轴朝上，Blender 中 Z 轴朝上），需要在导出时做坐标轴转换，确保模型方向正确。
核心工作：追踪引用链 → 提取几何数据 → 坐标转换 → 导出 OBJ
产出数量：3,568 个独立 3D 模型文件
成功率：98.2%（少量特效/粒子类无法提取）
提示词输入：
请选择方案一进行尝试。目前需求针对前哨这一张具体的地图，提取相关模型，并且转化成fbx或者 dcc能够读取的文件格式，便于后续在在blender中里面打开。 1. 请聚焦解压D:\Program Files (x86)\Steam\steamapps\common\Marathon\packages中命名带有“OutPost”的相关文件，2. 保留文件的存储以及相互引用关系，方便后期调用

这里成功导出了大量模型

04 解析场景布局
从游戏的场景文件中读取每个模型在地图中的精确位置、旋转角度和缩放大小。一张游戏地图并不只是"一堆模型文件"——同一个模型可能被复用几百次（比如走廊两侧重复的墙壁模块）。游戏引擎通过一份"布局数据"来记录：哪个模型放在哪个位置、朝哪个方向、缩放多大。这份布局数据就像一份"施工图纸"——它告诉我们 127,730 个物体实例各自的精确坐标。我们将其解析并导出为 JSON 格式，供下一步使用。
核心工作：解析场景文件 → 提取变换矩阵 → 建立模型-实例映射 → 导出 JSON
实例总数：127,730 个（其中 124,530 个有对应模型）
每个实例包含：位置坐标 + 旋转四元数 + 缩放系数 + 模型引用
产出文件：outpost_scene.json（21MB）
提示词输入：
 目前我看到已经将马拉松的美术资产转换成了OBJ，现在需要尝试找到场景中所有mesh的对应的世界坐标以及与mesh的映射关系：1. 以Outpost这张地图为例，试着分析这些mesh在场景中存储信息，尤其是transform信息；2. 逐步还原场景中的模型对应的映射关系，肯定会存在一个模型多次调用的情况，将这部分将场景的布置数据导出为json文件，方便之后调用

05 3D 场景重建
用自动化脚本驱动 Blender，将所有模型按照布局数据逐一放置，还原完整地图。最后一步是在 Blender 中执行一个 Python 脚本。脚本自动读取上一步导出的场景 JSON，然后逐一加载每个 3D 模型文件，按照记录的位置、旋转、缩放信息放置到场景中。为了提升效率，相同模型只加载一次（缓存复用），127,730 个实例全部放置完成后，就得到了完整的 Outpost 地图 3D 场景。
核心工作：读取 JSON → 批量导入模型 → 自动放置 12.7 万个实例
使用工具：Blender 5.1 + Python 脚本
操作方式：一键运行脚本，全自动完成
最终产出：可 360° 交互查看的完整 3D 地图
提示词输入：
目前已经成功获得了场景布置的json文件，请根据这份json文件以及之前导出的模型，
 在blender中重建这张地图：1. 请写出一份在blender中还原马拉松Outpost地图的脚本以及使用指南；2. 注意修改模型导入的方向，blender中是z轴朝上请喝模型的坐标轴对应。
主要产出：

📷blender实际写入的时候耗时很久，尽管已经放弃了模型的材质。基本需要5-6个小时完成127,730 个模型实例的重建，这里采用了局部优先重建的方法，先重建局部看看效果、大小是否正确，再重新全部重建剩余的。
最终产出：

总结：
主要使用到的的技术栈：
提取工具: Rust 编写的 marathon-extractor，依赖 tiger-pkg 库读取 PKG 格式，Oodle 解压（结合AI本人多次提示词试错）
中间格式:从pkg文件中找到 JSON（场景布局 + 模型映射）和各个模型在场景中的位置+ OBJ（mesh 几何体）（这里AI直接一步到位）
还原端: Blender Python 脚本（）（多次提示词调整并且多次修正）
提示词执行流程：
1. 认知包体——让AI提前了解整个文件范围、架构
2. 找到解析工具——尝试从0制作解析工具失败，遍历github找到可能方向
3. 解析模型资产——选定范围，寻找解析工具，解析场景模型3,568个
4. 解析场景映射关系（这个部分需要）——选定范围，分析场景实例 12.7 万个并且得到映射关系的.json文件
5. Blender中重建——生成执行python脚本在blender中调用重建
仍存在的问题：

二. 手动完善补充模型
需求上，希望根据已经有了真实场景尺寸的模型，分析其白模。
这里通过手动的方式补齐缺失的墙体和地面：
我尝试在模型软件中提取局部——二阶段风轮基地的模型，拆解白模并且分析其关卡构成：

由于已经有的大部分真实游戏场景比例模型，并且通过关卡连接处、缺口，直接在UE中补齐缺失的墙体、地面以及部分墙体，这里手动在引擎或者模型软件中中补齐，将大致的房间和墙体分割出来

根据信息完善结构：

分析结构以及设计思路：

三.未来的想法
我认为，得到1：1的游戏地图并不重要，而是通过这类方法，总结白模并且分析其中的设计思路，再才是重中之重，因此我也产生了一个想法：
——能不能借助AI工具
从拆解地图——形成白模——控制白模——生成地图
完成一次AI从分析输出、结合人工设计，再到制作关卡的闭环。
就这次尝试来说，只是完成了第一部分，第二个部分因为需要大量的观察以及对游戏本身的经验积累，目前由我手动补齐，如何借助AI完成这一步需要进一步尝试。
在通过白模进行设计这块，目前以视频表达为例已经有了很多应用，比如Image2，但直接生成可用的地图目前还缺乏一个较为合理的流程，这里先给自己挖个坑，下次见！