新一代的AI游戏混搭：实用管道、上下文窗口和从Porting Minecraft Mechanics到Doom的教训。

每个人好，我最初在r/ClaudeAI上发布了一些更广泛的问题，但由于讨论没有深入到引擎架构，所以我想把它带到r/aigamedev。像很多人一样，我一直在追踪最近的病毒式突破，如开发者chasmlol将Skate 3物理、技巧图表和骨骼重定向直接注入Modern Warfare 2（2009），以及Rehan Sheikh的通用模组工具包使用Claude Code读取正在运行的引擎并在飞行时交换逻辑/资产。最近，我正在测试这些代理工作流程的实践经验——使用LLMs将 voxel/Minecraft逻辑移植到遗留C代码库，目标是将该逻辑扩展到现代、硬件加速的3D引擎。亲自遇到速率限制、上下文饱和和内存映射瓶颈让我意识到，病毒式视频和实际编译输出之间的差距可能会很大。

我想从使用Claude Code、Ghidra或自定义LLM代理管道的人开发者那里获得反馈，他们正在解决这些核心技术障碍：

  1. 上下文窗口vs. 巨大的引擎代码库管理深度架构依赖性：游戏包含成千上万个相互依赖的引擎文件。当使用代理工具如Claude Code时，如何向架构提供信息而不降低推理能力或达到上下文限制？您是否依赖严格的.claudeignore规则、符号表索引或只检查孤立函数/内存地址的代理？

模型分级：轻量级或次级前沿模型是否能够处理局部引擎逻辑（例如碰撞数学或内存钩子）如果正确地搭建了框架，还是任务如交叉引擎向量数学和骨骼重定向严格需要前沿推理？

  1. 反向工程vs. 解编译基础

原始二进制文件vs. 现有的重写：类似MW2滑板模组的项目依赖于现有的社区基础（例如IW4L Rust runtime）。当前LLMs是否能够从头开始解决闭源、剥离的二进制文件（如7世纪Xbox 360/PS3游戏）？是否有人成功将解编译器如Ghidra或IDA Pro直接集成到自动代理循环中来重构清晰的源代码，还是人工工程师仍需要做90%的反向工程工作？

  1. 跨不同引擎版本的桥梁

将逻辑扩展到更高层：从旧的架构（固定点数学、2.5D/BSP结构）到现代3D管道（浮点数、硬件加速着色器、复杂骨骼树）引入了巨大的范式转变。那些编写翻译层或将遗留标题移植到现代运行时（如Rust或现代C++）的人：您的构建修复反馈循环是什么样子的？管道中有多少部分可以通过编译器错误循环自动化，而不是手动粘合代码编写？

  1. 动态资产交换和模组管道

当工具在运行时交换或重制资产时，有多少是真正的动态生成（例如在飞行时API钩子生成真实的纹理/模型）而不是预先烘焙的扩散资产通过传统的内存钩子模组设置注入？我想从使用Claude Code、Ghidra管道或遗留引擎重新编译的人那里听到他们的经验。我们是否看到了一个真正的范式转变，使单独的开发者能够在几周内混搭和重建复杂的老式引擎，还是这仍然需要深入的领域知识，AI只是更快的自动完成？

这里是Minecraft在Doom中的最新进展 https://vm.tiktok.com/ZN8kP43g3/ https://vm.tiktok.com/ZN8kPm5j8/ https://vm.tiktok.com/ZN8kPpqYD/