Thursday Apr 26, 2018 at 12:08 am
Because it’s a topic I care a lot about, I’m going to nitpick the Minecraft mod bits:
Bukkit is a server plugin abstraction layer, designed so that you don’t even need to touch Minecraft code to make a plugin (in theory, the API can be ported to run on any other game engine, and plugins will adapt without issue). Mojang has seemed fairly supportive of the project, to the point of hiring the main developers, and at some point buying the project or something. That had a downside, however, because Bukkit is GPL, didn’t have a Contributor License Agreement, and one asshole who was a major contributor didn’t like that Mojang got involved. So they DMCA’d CraftBukkit, saying that as soon as the GPL’d bukkit API was combined with proprietary Minecraft code to actually implement the API, the resulting project broke the GPL terms. I guess they hoped to force Mojang into releasing Minecraft as open source, but in the end all it did was kill Bukkit after all of the support the project had received.
Beyond hiring the Bukkit team, Mojang also hired the MCP team (MCP being the underlying toolset that makes mod creation practical) much more recently.
Next, IDs. Vanilla switched to string IDs long ago, keeping numeric IDs for compatibility with old command blocks and mods for some versions. By now, the latest version has no concept of user-visible IDs left. After Vanilla added that feature, Forge backported string ID support so that mods could transition, and even preserve worlds (as much as a modded world can transition between versions without major losses). String IDs are in 1.7.10, which is the oldest version still regularly played.
On C++ Minecraft: “Compiled” Java code is stored in unoptimized and very straightforward bytecode, which makes it possible for mods to easily patch new behaviours and interaction points into existing Minecraft code, and the JVM is expected to perform optimization at runtime. That can’t work in C++, because x86_64 assembly does not logically map back to the source code cleanly, templates have already been specialized into many slightly-altered duplicates, then independently optimized based on those parameters (so entire code branches may have been deleted as unreachable, so if a mod changes a branch condition it will need to manually re-insert the entire branch into every copy. It would be almost impossible for two mods to even touch the same part of the code without clobbering each other and making the game unplayable). In order to support such a wide variety of mod behaviour, they would need to manually insert impossible-to-optimize-away decision points all throughout the codebase, anywhere that a mod might want to interact with the code flow, at which point everything will be running much slower. The JVM is able to speculatively optimize code (no class currently extends that method, the third parameter here is always false), then when more code is loaded deoptimize those assumptions away. From that alone, I doubt C++ Minecraft will ever be able to support in-depth mods performantly. Unless it ends up like Factorio or the Elder Scrolls engine, where there is a very limited set of hard-coded behaviours, and most scripting is figuring out clever ways to patch things together to approximate the desired behaviour without the player noticing.
Reply to this»