REX与RE Engine到底什么关系REDox开源后卡普空的技术谱系终于清晰了【免费下载链接】REDoxHigh-performance, token-based structured data engine for .NET. A core component of REX, the technology behind CAPCOMs next-generation game engine.项目地址: https://gitcode.com/gh_mirrors/redox/REDox当卡普空在技术分享中首次公开REX项目的定位时玩家和开发者们的第一反应都是困惑REX 是一个全新的引擎还是 RE Engine 的改名这套已经孕育了《生化危机》重制三部曲、《鬼泣5》、《怪物猎人》与《街霸6》的引擎为什么突然需要一个新的代号答案就藏在最近开源的一个仓库里。卡普空旗下技术开发部门CAPCOM TD在 GitHub 上开源了REDoxRE:Dox项目描述写得很直白High-performance, token-based structured data engine for .NET. A core component of REX, the technology behind CAPCOMs next-generation game engine.而仓库 README 的结尾同样有一句关键的话*RE:Dox is developed as part of REX Technology for CAPCOMs next-generation game engine.*一句话总结RE Engine 是现在REX 是它的下一代演进路线而 RE:Dox 是这条演进路线中已被开源的核心组件之一。本文结合社区情报与仓库源码把这个技术谱系彻底拆清楚——包括 REX 到底在解决什么问题、RE:Dox 在 REX 架构里处于哪一层、以及它对第三方开发者意味着什么。一、先分清三个名字RE Engine、REX、RE:Dox要理清关系首先要接受一个事实卡普空从未说过 REX 是从零写的新引擎。公开报道的表述口径是一致的——REX 是让 RE Engine 为 AI 时代做好准备的持续改进项目目标是把现有引擎的开发环境改造成能与 AI 共同开发游戏的形态。换言之REX 不是 RE Engine 2.0而是RE Engine 面向下一代开发范式的一次系统化演进引擎管线、数据层、工具链都要重排为生成式 AI 辅助开发、大规模自动化内容生产预留接口。在这个演进计划中数据层是一个绕不开的瓶颈。现代游戏引擎里配置、关卡、存档、本地化、热更新、事件系统……所有东西都是结构化数据。一旦引入 AI 来批量产出和修改内容数据读取、编辑、序列化的性能与一致性就决定了整条生产线的天花板。RE:Dox 正是在这个位置切入的它不碰渲染、不碰物理、不碰音频只负责一件事——用统一的 token 模型承载多种结构化格式并为读写两端提供极致性能。这也是为什么卡普空敢把 RE:Dox 单独摘出来开源它是 REX 技术栈里内聚性最强、可复用性最高、也最适合社区共建的模块。开源一个数据引擎不会泄露《生化危机》或《怪物猎人》的任何资产管线秘密却能换来整个 .NET 社区的测试、基准与修复。这是AI 时代游戏引擎最合理的第一块拼图。二、REDox 在 REX 架构中的层级定位从格式到对象的中枢神经打开仓库根目录的 README.md第一张架构图就给出了 RE:Dox 的分层逻辑JSON / JSON5 / CBOR / MessagePack / TOML / XML / HTML / CSV / INI / DOX ↓ Compact token DOM / IR ↓ Reader / Writer / Serializer / Deserializer ↓ .NET objects, JSON, CBOR, MessagePack, TOML, XML, HTML, DOX, ...这个定位非常关键。RE:Dox不是一个 JSON 序列化库尽管它的 JSON 实现足够优秀。它把解析和序列化拆成了三件事格式层十种格式JSON、JSON5、CBOR、MessagePack、TOML、XML、HTML、CSV、INI以及自有的二进制格式 DOX各自解析/编码中间表示层所有格式解析后都汇入同一个紧凑的token DOM / IR——这是 REX 数据层的核心抽象读写层Serializer/Deserializer不直接面对任何具体格式而是面对这个 token IR。这一设计的直接后果是一次解析处处复用。同一个文档模型同时承担紧凑的解析结果与各序列化器、转换器共享的结构层两个角色。跨格式转换因此变成一件顺理成章的事——JSON → CBOR、JSON5 → JSON、CBOR → MessagePack全部走 token IR 中转README.md 里就有现成的 API 示例using REDox.Cbor; using REDox.Json; using var doc JsonDocument.Parse(json); byte[] cbor CborDocument.Encode(doc.RootElement);源码层面的证据同样清晰REDox.Cbor、REDox.MessagePack、REDox.Toml、REDox.Xml等子项目都被声明为InternalsVisibleTo到核心程序集见 src/REDox/REDox.csproj它们共享同一套 token 模型与转换器基础设施。这就是一个数据引擎喂十种格式的架构底气也是 REX 引擎内部数据管线的缩影游戏主程写一次转换逻辑存档、配置、网络同步、工具导出都能复用。统一转换器写给格式无关的抽象README.md 中给出了转换器的设计关系DataConverterT │ DataReader / Writer / | \ JSON CBOR MessagePack ...DataConverterT面向格式无关的DataReader/DataWriter编写而不是绑定某一种具体格式。源码中 Serializer.cs 的反序列化入口正是new DataReader(element)后走reader.ReadValueTValue(...)转换器逻辑与具体格式完全解耦。这对 REX 的意义在于引擎里的类型转换逻辑只需要实现一份JSON 配置、CBOR 网络包、DOX 存档共用同一套语义——格式不同行为一致。这同时也为未来的 AOT / 源生成器支持预留了基础。三、源码级解剖64 位双模 token 与可写磁带 DOM如果说架构图回答的是RE:Dox 在 REX 里处于哪一层那么源码回答的是它凭什么站在这一层。RE:Dox 的设计核心集中在两个被反复强调的概念上64 位双模 token与可写磁带 DOMmutable tape DOM。一个 token 装下所有类型在 src/REDox/DToken.cs 中DToken是一个 64 位结构体扩展位extension bit决定载荷的解释权属于文档/格式层还是 RE:Dox 自身控制 token 则承担插入、删除、替换等编辑状态。类型体系由两个枚举精确编码DTokenType.cs 定义粗粒度类型Ignore、Literal、Number、ExtNumber、Text、Binary、Map、ArrayDTokenKind.cs 定义细粒度类别Control、Trivia、Boolean、Null、Integer、Float、BigNumber、InlineFloat、String、Symbol、ByteString、TimestampDTokenVariant.cs 进一步组合出上百个具体变体比如StringMultilineSingleQuote、IntegerHexadecimal、TimestampOffsetDateTime——连 JSON5 单引号字符串、十六进制整数这类格式风味都被 token 化保留。从 src/REDox/DToken.Internal.cs 可以看到这套编码的工程细节MakeExtendInlineInteger把 52 位有符号整数直接塞进 token 的载荷位InlinePayloadMask 0x07000000_00000000L连小整数都无需外部位域访问MakeArray/MakeMap把容器长度直接写进 token 高 4 位之后的计数位。这意味着绝大多数标量值读取零间接寻址token 数组本身就是 cache-friendly 的扁平结构——这正是 README 宣称同时获得System.Text.Json.JsonDocument的磁带解析速度与JsonNode的可编辑性的物理基础。可写磁带 DOM编辑但不重建传统磁带 DOMtape DOM是只读的因为逻辑结构被拍平成一条 token 序列任何插入删除都要重排整条序列。RE:Dox 的做法是在容器视图DArray、DObject、DMap上加入间接层每个容器维护一个可重新链接的值槽数组空闲槽由 free list 回收见 src/REDox/DContainer.cs 与 src/REDox/DArray.cs 中的Free/InsertInternal/RemoveAt实现。删除元素时token 槽被标记为空并入 free list而不是整体搬移后续 token插入则复用空槽或追加。这样既保住了顺序 token 表示的缓存友好性又获得了就地编辑而不重建整个文档的能力。对 REX 工具链而言这几乎是刚需关卡编辑器里对一个几 MB 的配置文件改一个字段如果每次都要全量重建 DOM编辑延迟和 GC 压力都是灾难。RE:Dox 让读时极快、改时也轻成为可能。读写不对称一个引擎两条路径README.md 还披露了一个容易被忽略的架构决策——读写不对称Serialize : DataWriter, one pass, written directly to the output buffer (information is known → no look-ahead, no intermediate DOM) Deserialize : DataReader over the token DOM, random access by token id (information is unknown → look-ahead, out-of-order, context lookup)写路径上值已经已知DataWriter用WriteValues批量写、WriteProperty*融合写属性直接吐到输出缓冲不建任何中间对象树读路径上结构未知于是先建紧凑 token DOM然后利用结构完全可寻址这一优势实现一串 README 里明确列出的能力数组与集合预分配容量物化之前就拿到每个元素的 token id$type无论出现在对象何处都能解析Newtonsoft 式的位置无关类型元数据构造函数参数乱序收集、一次性绑定支持 record 与主构造函数基于全文档上下文的$id/$ref循环引用解析自动选择顺序或并行反序列化字符串与数字按需解码未变更的值复用原始源切片。这些特性在 src/REDox/SerializerSettings.cs 里都能找到对应的设置项PreserveReferencesHandling、ConstructorHandling、ObjectCreationHandling、ParallelOptions等并且测试套件 tests/REDox.Tests/DoxDocumentTest.cs 与 tests/REDox.Tests/JsonElementCompatibility.cs 对这些行为做了逐项验证。自动并行反序列化把 token 优势直接变现一个能说明token DOM 带来什么的杀手级特性是自动并行反序列化。因为解析后文档结构已知反序列化器可以在物化对象之前检查每个数组的元素数量与 token 区间数组足够大时先收集各元素 token id再把每个元素并行地反序列化到对应下标小数组保持顺序执行以避免调度开销。阈值参数在 src/REDox/Serialization/ParallelDeserializeOptions.cs 中暴露默认MaxDegreeOfParallelism 4、MinimumNumberOfElements 4、MinimumNumberOfTokens 1000开发者可以通过DoxSerializerSettings.ParallelOptions精确调参。注意一个细节src/REDox/Serialization/Converters/ArrayConverter.cs 中并行路径仅在PreserveReferencesHandling None时启用——因为跨元素引用需要全文档上下文这正是结构已知带来正确性约束的典型例子。DOX为深拷贝而生的二进制格式RE:Dox 家族里还有一个自有格式DOX在 src/REDox/DoxDocument.cs 中实现文件头以D | O8 | X16魔数标识版本 1.0。它的二进制布局刻意紧密镜像内存中的 token 数组因此从 DOX 构造文档几乎不需要结构性重建。这带来一个独特能力基于序列化的深拷贝——DoxSerializer.DeepCopyT()把对象序列化再反序列化产出的是独立、可编辑的副本而不是共享的只读视图见 src/REDox/DoxSerializer.cs 的DeepCopy/DeepEquals实现。这正是社区情报中DOX 格式秒级实现对象深拷贝一文的主题对快照、存档、撤销栈这类场景DOX 的往返序列化成本远低于 JSON 反射方案。当然 README 也给出了明确的安全边界DOX 只应接受可信输入因为它不是为防御恶意数据设计的解析器——面向不可信来源时必须退回 JSON 等文本格式。四、性能数字不是营销话术是可复现的基准性能是 RE:Dox 最容易被量化的部分。仓库在 benchmarks/REDox.Json.Benchmarks 下内置了基于 BenchmarkDotNet 的基准工程对标System.Text.Json含JsonTypeInfo预编译路径与 Utf8Json数据集使用simdjson-data子模块提供的canada.json、citm_catalog.json、twitter.json见 tests/README.md 的第三方组件说明 与 benchmarks/REDox.Json.Benchmarks/JsonDeserialize.cs。官方测得的相对加速比如下README 中的汇总表数据集反序列化反序列化并行序列化canada.json1.68x2.84x1.06xcitm_catalog.json1.77x2.25x1.62xtwitter.json1.36x2.34x1.42x分配数据更有冲击力在canada.json反序列化基准中RE:Dox 约分配2.62 MB而 System.Text.Json 约分配8.73 MB——差距约 3.3 倍。对服务器端批量处理和引擎内高频加载来说GC 压力的差距往往比时延更致命。需要强调的是README 明确声明这些比率只描述展示的基准数据集不是普适的性能承诺。性能取决于数据形态、目标类型、运行时、CPU 与序列化选项任何工程决策都应该用dotnet run -c Release --project benchmarks/REDox.Json.Benchmarks在自己负载上复现验证——这也正是仓库把测试数据作为 git 子模块external/simdjson-data、external/JSONTestSuite、external/json5-tests、external/toml-test随仓库分发的原因可复现性是可信性能声明的底线。五、对第三方开发者意味着什么跳开卡普空自己的引擎这层光环RE:Dox 开源对 .NET 生态的现实意义同样值得评估。1. 一个真正开放的引擎数据层范本游戏引擎的组件鲜有开源而 RE:Dox 恰好开源的又是最有普适价值的一块。它不是渲染器、不是资源管理器而是一个通用结构化数据引擎十种格式统一 IR、跨格式转换、可写 DOM、并行反序列化、深拷贝专用二进制格式。这套架构对任何需要高性能数据层的场景——游戏工具链、文档服务、游戏服务器、本地化管线——都是可以直接借鉴甚至直接使用的参考实现。2. 生态姿态Apache-2.0 现代 .NET许可证Apache-2.0见 LICENSE商用友好无传染性义务运行时要求 .NET 10 及以上src/Directory.Build.props 中TargetFrameworknet10.0紧跟微软当前主线版本版本节奏核心程序集版本为 1.0.1NuGet 包 ID 统一采用CAPCOM.REDox.*前缀见 src/REDox/REDox.csproj 与 README 的包清单CAPCOM.REDox核心 JSON JSON5 DOX、Cbor、MessagePack、Dynamic、DataContractJson、Ini 已标记为 PublicTOML、XML、HTML、CSV、SystemTextJson/NewtonsoftJson 兼容层则处于 Preview 状态API 可能继续演进。这意味着第三方开发者可以从第一天就用dotnet add package CAPCOM.REDox接入而不必等卡普空内部的稳定期结束——README 里 30 秒上手示例即展示了完整的序列化、反序列化、解析与就地编辑 API。3. 兼容层降低迁移成本的关键棋README 花了专门篇幅介绍三套兼容层CAPCOM.REDox.Serialization.SystemTextJson适配JsonSerializerOptions如PropertyNamingPolicy CamelCase、CAPCOM.REDox.Serialization.NewtonsoftJson适配NullValueHandling等 Newtonsoft 语义、CAPCOM.REDox.Serialization.DataContractJson。它们让现有代码库的序列化配置可以平移到 RE:Dox 之上再逐步享受 token IR 的性能红利。对于把存量 .NET 代码迁移到 REX 工具链、或者反过来把 REX 思想带回 .NET 项目的双向旅程这套兼容层都是低成本入口。4. 明确的安全与并发边界工程可信度体现在文档愿意把边界写清楚。README 的 Security 一节明确两点DOX 仅限可信输入DOX 是为速度设计的非防御性解析器禁止反序列化来自网络客户端、用户上传等不可信来源的 DOX不可信输入请用 JSON 等文本格式线程模型分层DElementAPI 只读可多线程并发引用但DValue/DObject/DMap/DArray内部状态可能因看似只读的操作如GetPath而改变不得多线程并发使用需要外部同步或为每个线程深拷贝一份。这两条边界直接对应 REX 引擎的部署场景存档与配置加载在单线程工具链里跑DOX 深拷贝用于撤销栈而服务器端需要并发时用DElement只读视图或DeepCopy隔离副本。5. 共建路径已经铺好仓库把贡献路径做成了自证式的external/子模块提供行业标准测试套件JSONTestSuite、json5-tests、toml-test、simdjson-datadotnet test REDox.slnx -c Release一键跑一致性测试基准用 BenchmarkDotNet 且强制 Release 配置代码风格由scripts/cleanupcode.sh/cleanupcode.batReSharper 命令行统一构建时要求git clone --recurse-submodules拉全子模块。这意味着贡献者提交的每一处性能改动都能在同样的数据集、同样的对照基线下被量化验证——这正是开源性能库该有的样子。结语技术谱系至此清晰把拼图放回原位卡普空的技术谱系已经非常清楚RE Engine当前世代引擎支撑了 Capcom 近十年的 3A 产品线REX不是新引擎而是 RE Engine 面向 AI 协作开发时代的下一代演进计划——升级工具链、重构数据与内容生产管线RE:DoxREX 技术栈中已被开源的核心数据组件负责十种格式到统一 token IR 之间的全部读写转换性能与架构俱佳。RE:Dox 的开源让我们第一次从公开源码层面确认了 REX 的工程方向AI 时代的内容生产需要一条格式无关、结构可知、可写可改、极速往返的数据中枢。对 .NET 开发者而言这既是一次观摩卡普空引擎技术的机会更是一个可以直接拿来用的高性能数据基础设施——毕竟引擎的数据层与引擎的渲染魔法不同它是可以、也应该被全行业共享的。【免费下载链接】REDoxHigh-performance, token-based structured data engine for .NET. A core component of REX, the technology behind CAPCOMs next-generation game engine.项目地址: https://gitcode.com/gh_mirrors/redox/REDox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考