Minecraft

在我上小学一年级（大概是2012年左右）的时候，我在一本从书店买的游戏期刊中了解到了《Minecraft》这款游戏，我便立刻对它产生了兴趣。那时没有电脑，我就在我妈的手机上下载了Minecraft pe版，这是我人生中第一次接触这款游戏。后来我们家买了台电脑，我就下载了mc pc版又猛玩了一段时间（我记得我一直玩的是1.7.10，虽然这是个mod大版本，但当时还不知道mod这个东西，就挺巧的），但是随着玩的次数越来越多，我逐渐没有了当初对这款游戏的热情。也就在我快要弃坑的时候，我翻到了网上那些主播玩mc的实况视频，好奇为什么他们这么多东西我的游戏里面都没有，后来经过了解才知道那是他们加了mod。我开始尝试自己加mod，发现玩到了很多跟以前不一样的东西，于是从那时开始，算是我第一次真正了解了这个游戏，也让我重燃了热情。其实我当初学计算机的想法也很纯粹，是为了有朝一日能玩到自己写的独一无二的mod。这篇博文就用来保留和分享我当时写mod的一些经验和感受吧

（本文基于neoforge模组加载器，游戏版本为1.21.1，neoforge版本为21.1.217）

官方开发文档

Neoforge-docs
Neoforge-docs
https://docs.neoforged.net/docs/1.21.1/gettingstarted/

注：如要看游戏版本为1.21.1的文档，别忘了把文档的版本改为1.21.1，否则在开发过程中总会出现一些令人头疼的bug

官方脚手架生成

Neoforge-generator
Neoforge-generator
https://neoforged.net/mod-generator/

你可以选择使用官方网站生成脚手架，也可以选择在github上拉取项目或者在idea中生成脚手架（推荐官方生成或idea生成），这里我使用idea进行生成

创建项目后要交给idea来进行项目的初始化，期间要占用的时间估计会很长，期间可能还会有多次的构建失败的情况，在这种情况下只能一直保持魔法上网或者换maven国内镜像源

关于mod文件

官方文档中有关一些mod文件的说明十分详细，比如有关gradle.properties中就包含了模组各种常用属性比如mod的版本和id，gradle会把这些文件中的值读取出来内联到其他位置，这样只需要在这里改动配置，其他地方就会自动应用（说实话这个设计确实方便），而且大多数的属性在官方文档里都给出了解释，这里不过多赘述

构建mod时要注意的一些问题

这里官方文档开头便建议你注意使用恰当的包结构和一些类的命名规范，这会使你的项目有更强的可维护性（在一个项目中可读性是很重要的）。

一个常规的包结构应由顶级域名、子域名和modid构成，例如:com.example.modid.一个包结构目录内不允许出现同名的类或文件，否则游戏启动时就会崩溃。正确的做法是将同名的类放到不同的包目录下，这样便不会出现游戏崩溃的问题。

在顶级包之下还要创建子包来对类加以区分，比如方块可以放在block包下，实体可以放在entity包下；或者还可以通过逻辑来区分，比如你要加个拆解台，你就可以把拆解台的方块类，菜单类和有关的一些物品放到这个名为拆解台的包中

类的命名规范也有讲究。如果你创建的类是一个方块，就在这个类的后面加上一个”Block“（比如我要加个幸运方块，那这个类就是LuckyBlock）；同样地，如果你要加的是一个物品，那就在类名后加上”Item“；如果是菜单，则加上”Menu“

版本控制

游戏版本号

每个neoforge mod的jar包名称除了模组名以外，还包含了游戏以及mod版本号等信息。Minecraft自1.0发布以来，版本号1一直沿用了下来，期间命名规则改变频繁，曾出现过 a1.1(Alpha 1.1)、b1.7.3(Beta 1.7.3)甚至infdev版本等，这些版本都没有遵循一个很清晰的版本号规则，但有一点值得肯定的是，这种情况不会轻易发生改变——起码在之前这是个毋庸置疑的观点…但就在几天前，mojang官方官宣了新的版本命名规则，他们决定采用年份+编号的方式，以年份为首段，后面为此年发布的第几个重要版本（其实有点像快照的版本命名方式），而第一个要以此命名规则面世的版本为26.1，之后会是26.2，然后是26.3…27年就是27.1，27.2…即便对版本命名突如其来的改变有点爷青结的感觉，但这种命名确实更清晰更合理了些，毕竟总是要做出一些改变

Neoforge mod也有一套专门的版本命名规则，一般地，如果还是测试版本（开发版本），则版本号为0.x.x，直到正式版发布则升到1.x.x(实际上大部分开发项目都会采用这种形式)。次版本号负责发布新功能，补丁版本号负责错误修复（但是这条规则经常在实践中被忽略…）

“简化”语义化版本号

这样的语义化版本控制还可以进行“简化”，旨在只使用主版本号+次版本号来对小型模组进行版本控制，这些模组织添加少量简单的对象，因此很少需要更新（除非要兼容新版本的Minecraft），通常只停留在1.0版本

“扩展”语义化版本号

有了“简化”的方式，理应还有“扩展”。“扩展”语义化版本号，或“四部分”语义化版本号，由四个数字组成（例如 1.0.0.0 ）。根据模组的不同，格式可以是 major.api.minor.patch ，或 major.minor.patch.hotfix ，或者完全不同的格式——这没有一个统一的标准

对于 major.api.minor.patch ， major 版本号与 api 版本号是分离的。这意味着 major 版本号（功能）和 api 版本号可以独立更新。这通常被那些向其他模组开发者开放 API 的模组所采用。例如， Mekanism 目前的版本是 10.7.17.83（撰写本文时）

对于 major.minor.patch.hotfix ，补丁级别被分为两部分。这是 Create mod 所采用的方法，其最后使用此命名方式的版本为 0.5.1j（撰写本文时）。请注意，Create 使用字母而不是第四位数字来表示热修复补丁，这样可以保持与常规语义化版本控制的兼容性

Alpha, Beta, Release Alpha、Beta、正式版

与 Minecraft 本身一样，模组制作通常采用软件工程中常见的经典 alpha / beta / release 阶段，其中 alpha 表示不稳定/实验版本（有时也称为 experimental 或 snapshot ）， beta 表示半稳定版本， release 表示稳定版本（有时称为 stable 而不是 release ）

Mod jar包命名

一个完整的mod jar包命名应该包括mod名称、mod加载器、Minecraft版本号以及mod版本号。就拿jei来说，jei-neoforge-1.20.2-16.0.0.28 、 jei-1.20.2-neoforge-16.0.0.28 或 jei-1.20.2-16.0.0.28-neoforge 都是有效的写法。对于其他模组加载器，则需要将 neoforge 替换为 forge 、 fabric 、 quilt 或您正在使用的其他模组加载器（例如，与 NeoForge 一起使用的加载器）

开始

讲了这么多代码之外的事情，虽然我尽力用自己的话来解释了一遍这些命名或是注意事项，但可能对某些人来说还是有些难懂。不用担心，下面也该正式进入写代码的环节了

打开你的idea（java编程常用的IDE，如果没有，请尝试去网络上了解并下载。也可以使用其他IDE，但这里我个人还是推荐idea，毕竟idea的许多功能简化了我们的java开发），并在idea中打开你生成的脚手架（或者在idea中安装minecraft development插件，然后直接在i新建一个neoforge项目）。初次打开项目idea会自动初始化gradle，第一次时间稍微有点长（并非稍微），期间也有可能多次报错，大多数这样的情况就需要你换个网络环境或者换个魔法节点然后再试一次，实在不行就多次尝试（反正我就是重复了很多次才终于下完所有东西的），初次构建好了之后，后面再打开项目就会很快了

构建好以后项目文件目录大致是这个样子（block、entity、item包是我后来加的，所以刚开始没有.PS:当时我写的mod名为Something Simple）

mod类

没有什么问题的话，我们打开类名为你mod id的那个类，你会看到脚手架已为你自动生成了一百多行代码，现在先不用管它们都是什么意思，你只要知道代码第40行的那个MODID十分重要，并且它的值也有不少限制（这也是我为什么不推荐github直接拉取的原因之一，因为你需要给示例代码改动很多地方，而直接生成就不需要），MODID的值中不能出现大写字母、数字、空格，符号只有” _ “可以出现，所以你需要保证你的MODID只有小写字母和” _ “组成，而且还要注意的一点是你的MODID在游戏中不允许重复，否则可能会使游戏崩溃，MODID作为你mod的唯一标识出现，你需要给它组合出一个不易重复、独特的字符串。除此之外，有许多示例代码现在还不需要，为了简化学习，我删掉了一部分示例代码，这是我改动以后的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// The value here should match an entry in the META-INF/neoforge.mods.toml file
@Mod(Somthing_simple.MODID)
public class Somthing_simple
{
    // Define mod id in a common place for everything to reference
    public static final String MODID = "somthing_simple";
    // Directly reference a slf4j logger
    private static final Logger LOGGER = LogUtils.getLogger();

    // The constructor for the mod class is the first code that is run when your mod is loaded.
    // FML will recognize some parameter types like IEventBus or ModContainer and pass them in automatically.
    public Somthing_simple(IEventBus modEventBus, ModContainer modContainer)
    {
        // Register the commonSetup method for modloading
        modEventBus.addListener(this::commonSetup);

        // Register ourselves for server and other game events we are interested in.
        // Note that this is necessary if and only if we want *this* class (Somthing_simple) to respond directly to events.
        // Do not add this line if there are no @SubscribeEvent-annotated functions in this class, like onServerStarting() below.
        NeoForge.EVENT_BUS.register(this);

        // Register the item to a creative tab
        modEventBus.addListener(this::addCreative);

        // Register our mod's ModConfigSpec so that FML can create and load the config file for us
        modContainer.registerConfig(ModConfig.Type.COMMON, Config.SPEC);
    }

    private void commonSetup(final FMLCommonSetupEvent event)
    {
        // Some common setup code
        LOGGER.info("HELLO FROM COMMON SETUP");

        if (Config.logDirtBlock)
            LOGGER.info("DIRT BLOCK >> {}", BuiltInRegistries.BLOCK.getKey(Blocks.DIRT));

        LOGGER.info(Config.magicNumberIntroduction + Config.magicNumber);

        Config.items.forEach((item) -> LOGGER.info("ITEM >> {}", item.toString()));
    }

    // Add the example block item to the building blocks tab
    private void addCreative(BuildCreativeModeTabContentsEvent event) {

    }

    // You can use SubscribeEvent and let the Event Bus discover methods to call
    @SubscribeEvent
    public void onServerStarting(ServerStartingEvent event) {

    }

    // You can use EventBusSubscriber to automatically register all static methods in the class annotated with @SubscribeEvent
    @EventBusSubscriber(modid = MODID, bus = EventBusSubscriber.Bus.MOD, value = Dist.CLIENT)
    public static class ClientModEvents
    {
        @SubscribeEvent
        public static void onClientSetup(FMLClientSetupEvent event) {
        }
    }
}

gradle.properties

如果是github拉取的项目，只要改动后面的mod信息，正确填写就行；如果是生成的脚手架，那基本不用做任何修改，要改的话可以把mod_version的值给改成0.0.1

Vanilla源代码

在mod开发中我们不可避免地需要看一些mc香草版本（Vanilla，指没有添加任何插件和模组的基础游戏版本）的源代码，但是我们无法直接查看香草的源代码，这源于mc的代码混淆机制，以对mc的源代码进行保护。

那么我们如何查看香草源代码呢？

如果你足够细心，会发现idea右侧的工具栏中有一个gradle的logo（形状是一头大象），点击它，它会给你弹出：

点击Download Sources

它会自动给你下载源码，下载完成之后，打开任意香草版本类文件，代码最上方会有一行蓝色的文字，右边有个attach sources，点击它，这样你就可以查看香草源代码了

启动游戏

这些准备工作做好之后，你就可以尝试启动你的游戏客户端了。选择Client并运行

等待一段时间直至游戏加载完成，在主界面中打开模组，你就会发现你的mod已经成功在游戏中加载了

至此，我们已成功踏进了neoforge mod开发的大门！

说些什么吧！

waline