| name | mc-align |
| description | 基于测试驱动的开发(TDD),将当前项目的代码与 Minecraft 原版代码对齐,确保功能和逻辑都能准确复刻 Minecraft。 |
任务
请你先阅读相关readme文件,以初步了解此次任务内容和范围,然后启动5~12个子代理,彻查用户指定路径(或者用户指定的某个子系统)下的代码。审查依据:
- 是否准确复刻
D:\Minecraft\MC研究\Minecraft1.21.11源码\net\minecraft下的算法、逻辑、时序等,与原版任何一点点偏差都会导致偏离预期。对于精确度要求极高的逻辑(如渲染、区块生成相关),必须在写文件之前阅读对应mc源码!但需要注意,对于随机数算法、f32还是f64、i32还是i64等区别,这些就不用对齐了,没有太大意义。
- 是否完整,没有遗漏类、文件、函数、数据、结构、逻辑分支等;是否留有TODO、临时的简化实现、被注释掉的逻辑等
- 如果已经很完整了,建议再多启动几个子代理,每个子代理的任务都是同时阅读本项目和mc的代码来做对比diff,看看是否有任何细节上的偏差(请仅仅关注和对齐算法、逻辑、时序等抽象层面的东西,不要关注函数名、类名、类的结构等架构层面上的东西,因为本项目和mc源码本来在这些方面就有一定区别)
- 是否闭环、是否完整集成到游戏逻辑当中,没有形成无法被调用的“孤岛代码”
上述5~12个子代理要求不能在后台运行,而是必须阻塞等待它们完成。它们完成之后,请你接着启动3~5个子代理,根据之前那5~12个子代理的需求,专门负责探索项目中已有的对应基建,以实现完美的、最高程度的复用。不要限制子代理的输出字数,让它们尽可能详细地输出它们的探索结果。
子代理的配置项必须如下:
run_in_background: false,
model: haiku,
isolation: 不要配置
注意本项目基建已经相当完善(代码量已经110w行),各种常数、常用工具函数、音频系统、粒子系统、资源包系统、命令系统、实体系统、物品系统、物理系统、碰撞、tick调度、存档等都已经有了相当完善的实现(另外world对象上面也挂了相当多的工具方法以便访问世界、操作世界等),务必充分探索以实现复用,避免重复实现,或者以未实现为理由留下TODO。
上述全部子代理结束后,请你再启动1~2个子代理负责探索测试用例的覆盖情况,看看是否有遗漏的测试用例,或者测试用例不够复杂无法暴露问题的情况。
善用README
几乎每个目录下都有一个简体中文编写的 README.md,它很重要,在你探索项目实现的时候,提前看看它,能节省不少多余的文件查找与查看,节省不少上下文开销。
【重要】为了节省上下文,请你尽量阅读各级目录的 README.md 来获取你需要的信息,而不是直接查看代码文件。
例如:当你修改想修改或查看src\common\world\chunk\ChunkLoadTicketManager.cpp,你必须提前依次查看目录链上的各级目录上的readme文件:
- 项目根目录的 README.md
- src\common\README.md
- src\common\world\README.md
- src\common\world\chunk\README.md
请你不仅自己要严格遵照上述要求,而且在给子代理的prompt中也要要求它们先查看相关目录链上的README.md来获取信息,而不是直接查看代码文件。
实现要求
- 阻塞等待所有子代理完成(禁止子代理在后台运行)。所有子代理完成之后,请你进入计划模式,列出出一个详细的对齐报告,列出所有不对齐的地方,并且给出详细的逐步修复建议和单元测试编写建议(特别是细节部分不要省略)。然后不要停下来,而是继续立即开始一步步执行!
- 测试驱动的开发:不要编写业务代码,而是先编写和完善测试用例。测试用例需要充分的覆盖。写完所有测试之后再编写业务代码来实现它们。测试用例的编写也必须参考mc源码,确保测试用例能够覆盖到mc的各种边界情况、各种特殊情况、各种复杂情况等,以便暴露问题。
- 当你完成一个任务后,不要停下来,请继续做后面的任务,直到任务清空你才能停!就算任务很复杂,也绝对不允许中途停下来!
- 你时间充足、上下文也充足,先把所有任务代码一口气写完,最后再编译
- 务必尽可能复用项目中已有的基建!
- 在任务执行过程中,你可以随时派出子代理来帮你完成一些子任务,比如说探索项目中已有的对应基建、探索项目中需要依赖的某个子系统是否存在、甚至帮你编写代码!
关于代码
【重要】必须参考下面mc源码!
windows环境源码位于 D:\Minecraft\MC研究\Minecraft1.21.11源码
macos环境源码位于 ~/MC_Dev/Minecraft1.21.11源码
- 必须优雅、考虑到未来拓展、结构清晰美观整洁、架构强大,必须参考mc源码(主要是为了学习mc真实游戏逻辑而非架构。mc的架构水平和代码质量并不高!),但不要照搬,必须根据cpp的特性和当前项目的架构进行合理的架构设计和调整。
- 当前项目是一个复刻项目,目标是完全使用cpp尽可能一致地复刻java版mc的游戏体验,并在存档、数据包等层面上尽可能兼容和复用现有java版minecraft生态。务必要有清晰、优雅、能让人赏心悦目的目录结构,不要把很多文件全部堆在一个目录下,要划分好细分的子目录。
- 务必要有清晰、优雅、能让人赏心悦目的目录结构,不要把很多文件全部堆在一个目录下,要划分好细分的子目录!
## 任务结束后
任务结束之后,请你进行严格的多轮自查并运行测试,检查是否完整实现、是否留有TODO、是否未完整集成到现有游戏流程中导致形成“孤岛代码”、测试用例是否完备且合理且足够复杂以便暴露问题、没用了的旧代码是否彻底清除、相关文档(readme)是否更新等。
自查完成之后,执行`/mc-simplify`命令,进行代码简化,去除冗余、合并重复、提升可读性、提升性能等。
最后,生成简体中文提交信息并提交代码。
注意,本项目很多类和变量、方法的命名与原版mc不一样,因此当你发现疑似不存在的方法、类时,务必仔细搜索,看看它们是否被命名成了其他名字,或者被拆分成了多个类和方法,或者被合并到其他类和方法里了。不要轻易就认为它们不存在、需要补充了!
【重要】不要启动plan agent,你必须亲自起草计划!
【重要】不要启动plan agent,你必须亲自起草计划!
【重要】不要启动plan agent,你必须亲自起草计划!
【重要】不要启动plan agent,你必须亲自起草计划!
【重要】不要启动plan agent,你必须亲自起草计划!