對於modder來說，寫Mc mod的的時候，我總是想著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的地形算法是基於Perlin Noise的2-pass過程。關於Perlin Noise的，可以看看git上我寫的版本（鏈接：/kaaass/JavaPerlin 直到目前尚未完成）。第壹次：基本生成，確定biome，建立基礎地形。第二次：特性生成，從layout開始（河流等等），然後是洞穴、樹、村莊什麽的。由於存在先後多次生成，就會偶爾遇到村莊位於峽谷上等等奇葩景觀。
2.Minecraft的Block
方塊具有很多特性，這裏只講壹點。先是metadata，諸如植物（單指Corp）不同的生長狀態都是不同的metadata決定的。TileEntity，entity是實體，諸如玩家、怪物都屬於entity。metadata的存儲數據量對部分方塊，比如箱子。所以引入了TileEntity的形式。暫時就說辣麽多。
3.物品
物品具有和block相似的機制。存儲狀態使用damage值決定。沒錯很多時候物品就是用名字上叫“耐久”的值存儲狀態的。然後是subitem的機制，就是子物品。比如染料（dye），染料很多，然而其實物品id是壹樣的。