1.整体架构
对于modder来说写Mcmod的的时候，我总是想着Java怎么就不提供个直接能覆盖掉MC原类的关键字呢？Mc源代码在部分层面的逻辑非常混乱，后面慢慢吐，不急。Mc的混乱不在于不同程序员间的代码风格迥异（当然也是因素之一），更在于Mc与他的“历史遗留问题”。打个比方说一个孩子在搭积木，他开始用了方形的结构磕磕绊绊的搭了好几层，后来，他发现三角形结构更加稳定。但是他那时偷了点懒，在方形的基础上构造一层层稳固的三角形。积木越搭越高，却也越来摇摇欲坠。当孩子望着这些积木打算着手修改时，却发现问题早就树大根深了。Mc就是这样Notch早期很明显的以小项目为基础考虑而构建的代码、逻辑结构很大程度上或多或少祸害了如今的Mc。不是说Notch开始不对，是说Mc在还来得及的时候没有痛下决心重写项目。后来的程序中，当然不乏漂亮的逻辑，但是这都有一个蹩脚的点为根基。从根本上讲Mc“根本”不行。由于当初小项目开发的前瞻性不足，如今留给mod开发者抑或是Mojang的开发空间十分狭隘。得亏有了ASM得以使开发者在源码上凿开空间。
2.Truck
你你你……我我我……唉:-(！
Mc效率差的原因之一。这样吧这部分我先静一静，有机会说说哈。
3.绘制
有答案已经提了，直接给数据什么的……不提效率，反问Mojang团队自己看不看得懂自己在写什么！
4.逻辑
为什么一个方块有4种得到掉落物的方法，还附赠一个掉落物品的方法？为什么纵使每种物品方块几乎都有class，指定他们的硬度等参数还要在init里？这么说吧，我植物这方面做的比较多，如果你的植物不属于换了材质的小麦，基本就是要继承Block再造轮子了。没办法原版植物谁用谁知道。
5.GUI
又要造一波轮子。个人想法：mc的GUI本身的鼠标部分写的太次了！完全没有继承价值，属于重载了super都不带一句那种。自带的GuiButton就是个摆设。
6.硬编码
Mojang喜欢硬编码跟见了亲人一样。比如物品Id、方块Id、子物品、RenderType……分配一个，用registry很难吗？
/==================
专门来一篇Minecraft的介绍。先声明这里只是普通的Moder。
1.Minecraft的地图生成算法
Minecraft的地形算法是基于PerlinNoise的2-pass过程。关于PerlinNoise的，可以看看git上我写的版本（链接：https://github.com/kaaass/JavaPerlin直到目前尚未完成）。第一次：基本生成，确定biome，建立基础地形。第二次：特性生成，从layout开始（河流等等），然后是洞穴、树、村庄什么的。由于存在先后多次生成，就会偶尔遇到村庄位于峡谷上等等奇葩景观。
2.Minecraft的Block
方块具有很多特性，这里只讲一点。先是metadata，诸如植物（单指Corp）不同的生长状态都是不同的metadata决定的。TileEntity，entity是实体，诸如玩家、怪物都属于entity。metadata的存储数据量对部分方块，比如箱子。所以引入了TileEntity的形式。暂时就说辣么多。
3.物品
物品具有和block相似的机制。存储状态使用damage值决定。没错很多时候物品就是用名字上叫“耐久”的值存储状态的。然后是subitem的机制，就是子物品。比如染料（dye），染料很多，但是其实物品id是一样的。
