距离上一次在M1 MacBook上优雅地游玩Minecraft已经过去了整整一年的时间。昔日的姐妹们多半已经入职,Minecraft服务器就算开着也无人问津。

我一直以为这个周末会和夏天所有的周末一样,在炎热与焦躁不安中度过,却没想到又收到了姐妹的微信,问还有没有MC的整合包。

翻箱倒柜找到去年的目录,文件都还在,只是已经忘记了如何打开——在M1上原生运行Minecraft一直都是个头疼的事儿。

容我再研究研究。

# 世事如常

“世事无常”,Hello Minecraft! Launcher (HMCL)已经支持调用自定义库文件,LWJGL 3.3.0往后已经出厂自带macOS-ARM64原生组件,ManyMC启动器实现库文件替换自动化。

一眼望去,似乎日新月异,欣欣向荣。只可惜金玉其外,败絮其中,世事如常尔尔。Minecraft至今未有动过为1.19以前的Java版本支持macOS-ARM的念头。想要原生运行Minecraft还得“吃自助”——自己解决LWJGL原生库。

# 自力更生

曾经又有一位哲人曾经说过,“靠自己,靠别人是没有幸福的”。多亏yaoxi-std,HMCL要想支持调用动态库文件已经有了现成的解决方案,但调用JAR库文件似乎还没有头绪,每次手动复制也不是办法,万一有哪次忘记关闭“检查游戏文件”,就是前功尽弃。

yusefnapora的MultiMC自动脚本的脚本给了我启发,HMCL的包装命令(Wrapper Command)功能同样可以实现每次启动时根据版本修改JVM参数,加载相应的原生库文件。

来活了。

# M1 HMCL Hack

为什么M1 MultiMC Hack历史已经如此悠久,HMCL就不能有M1 HMCL Hack?是牌面不足吗?今天我就要打破这一魔咒,M1 HMCL Hack今日Debut。

好像押韵了。

包装命令可以自动识别Minecraft版本,将原有JVM启动参数中的库文件路径替换为正确的原生库文件路径。使用方便,如假包换。

友情提示:虽然咱们名字叫M1 HMCL Hack,从理论上来说M2应该还是兼容的。

# 安装使用

# 第一步:下载Java与HMCL

Zulu Java OpenJDK Download

首先至Azul官方网站下载Zulu JDK,下载时可以选择.dmg安装包直接安装。架构需要选择ARM 64-bit,另外,由于HMCL需要调用OpenJFX,包类型需要选择JDK-FX。Java版本则需要依据Minecraft版本来选择。经过我的实际测试,Minecraft与Java的兼容性大致如下。

MinecraftJavaLWJGL
1.19>= 173.3.1
1.18>= 173.3.1
1.17>= 173.2.3
1.16>= 83.3.1
1.12>= 8, <= 112.9.4
1.1082.9.4
1.782.9.4

JDK的各个版本间可以共存,我全都要党胜利依旧。

接下来,下载HMCL,落笔时,最新版为3.5.3.211。

# 第二步:克隆仓库

克隆M1 HMCL Hack的仓库到本地。

git clone https://github.com/DotIN13/m1-hmcl-hack.git

# 第三步:设置包装命令

打开HMCL,下载或者导入一个Minecraft实例。

然后进入实例设置,勾选“启用游戏特定设置”(Enable per-instance settings)。

再根据上文中的表格选择合适的“Java路径”(Java Path),注意选择第一步中安装的ARM架构Java版本。

Java Mr. Right

向下滚动页面,找到高级设置中的“包装命令”(Wrapper Command),填入/usr/bin/ruby /path/to/index.rb,此处/path/to/index.rb应为index.rb文件在本地的路径。运行游戏时,HMCL会将当前目录切换到.minecraft目录下,因此,如果填写相对路径,因当以.minecraft作为起点。

Setting Up the Wrapper Command

最后,由于HMCL默认禁止在ARM架构的macOS中使用ARM架构Java启动Minecaft,因此需要在页面最底部勾选“不检查JVM与游戏的兼容性”。

No JVM Compatibility Checks

至此,点击开始游戏,Minecraft就可以以Nosetta(No-rosetta)状态运行了。对于任何新安装的Minecraft版本,只需要重新操作第三步,即可继续纵享丝滑。

# 爱好者开发制

你可能会问我为什么要做HMCL Hack。我可能会回答你,我想让更多和我一样拥有Apple Silicon,喜欢HMCL的玩家玩上更加流畅的Minecraft。但这一切都有必要吗?或者说,在实然上确实有必要,那么在应然的角度上来看呢?

Microsoft应该带头解决Minecraft的兼容问题。GLFW应该在小版本更新时考虑到向后兼容性。LWJGL应该对旧版本进行重发布来兼容ARM架构而不是通过大版本更新来解决,以免导致使用旧版库的所有应用都无法在macOS ARM-64bit上运行。

对于Minecraft这个特别的游戏来说,每个游戏版本无论新旧都有庞大的玩家群体,向后兼容性至关重要。但即便如此,整个上下游依旧各自为阵,到今天为止也只解决了最新版本的兼容性问题,对旧版本选择了全然无视。

实然与应然有如隔海,理想的家园不知所在。开源的本质是爱好者的分享,这也就好比计算机软件的拥有者与掌握者与使用者签订了契约,将使用和修正的权力赋予用户。但与一般意义上的社会契约不同,用户缺少了推翻“统治者”的权力。虽然开源隐喻着开放,但代码的维护者依旧保有着全部的权力,即便用户可以修正他们所使用的计算机软件,他们也不能对其他用户所使用的软件造成实质的影响,缺乏公信力、缺乏共享渠道,导致了这些用户进行的修正最终只能停留在自娱自乐。这就好比用户只是一个制造假币的小丑,而币制的制定权依旧掌握在某些“爱好者”的手里。

开源不是一个完全去中心化的过程,它只是将中心进行了转移,从邪恶的大厂手中,转移到了另一部分人手中。如果这些开发者与用户的想法背道而驰,那么失去替代选项的用户也只得言听计从。

你一言我一语自然是不能成事,但开源是不是也只是“少数人的暴政”披上了羊皮?