Me too. Having only a vague familiarity with the game, I thought that mods were using some official plugin system. I had no idea that minecraft modders (presumably kids/teens?) were not only reverse engineering things but also creating an entire ecosystem to work around proguard.
Over time people learned the key APIs and classes that you needed to interact with. And obfuscated Java is like an order of magnitude easier to work with than machine code. Once someone figured out how to do something it was generally pretty easy to use that interface to do your own thing. Modders of course still often hit edge cases that required more reversing, but yeah, it was really cool to watch over the last 15+ years :)
Not only working around proguard, but Minecraft mods are built on top of an incredibly cool and flexible runtime class file rewriting framework that means that each JAR can use simple declarative annotations like @Inject to rewrite minecraft methods on the fly when their mod is loaded or unloaded. This massively revolutionized mod development, which was previously reliant on tens of thousands of lines of manually compiled patches that would create "modding APIs" for developers to use. Putting the patching tools in the hands of the mod developers has really opened up so many more doors.
Minecraft also has a plugin system based around JSON file datapacks, but it's a lot more limited. It's more at the level of scope of adding a few cool features to custom maps then completely modding the game.
The devs for Java Edition really have mods in mind nowadays.
- They left in the code debug features that they used to strip out.
- They left in the code their testing infrastructure that they used to strip out as well.
- They started making everything namespaced to differentiate contents between mods (like in this week's snapshot they made gamerules namespaced with the "minecraft:" prefix like items and blocks and whatnot)
- They are adding a lot more "building blocks" type features that both allow new /easier things in datapacks, and in mods as well.
Method patching with Mixins is less needed now because the game's internal APIs are more versatile than ever.
That's definitely true, and I think that's a testament to Minecraft / Java's strong OO design—it dovetails very nicely with the Open/Close principle. However my view is that for a mod to be a mod, there's always going to be stuff that you can't/shouldn't implement just with datapacks—whether that's complex rendering features, new entity logic, or whatever. The Mixin processor makes it really easy to build these kinds of features in a very compatible way
These tools sound very powerful, could they find use for other Java codebases?
I don't know where you'd use it besides modding, but it is a general-purpose framework: https://github.com/SpongePowered/Mixin
Other codebases don't tend to need those tools, because they already use frameworks like Spring or Micronaut which have such features built-in. Usually without bytecode rewriting and with more concern given to API definition.
For example, in Micronaut (which is what I'm more familiar with) you can use @Replace or a BeanCreatedListener to swap out objects at injection time with compatible objects you provide. If a use-site injects Collection<SomeInterface> you can just implement that interface yourself, annotate your class with @Singleton or @Prototype and now your object will appear in those collections. You can use @Order to control the ordering of that collection too to ensure your code runs before the other implementations. And so on - there's lots of ways to write code that modifies the execution of other code, whilst still being understandable and debuggable.
You still need quite a lot of mixins / modified code to actually do useful things. Mojang isn't always making things unnecessarily extensible, just extensible enough for them to keep updating the game.
They've also been working with a lot of modders on the rendering engine over the past year or two.
> I had no idea that minecraft modders (presumably kids/teens?) [...]
Players who were teenagers when the game first came out are now 29 to 35 years old. It's a pretty ancient game at this point. From my experience, most contemporary modders are in their late 20s.
We're still relying on legacy code written by inexperienced kids, though...
There is and kind of isn't. There are community led modding apis, but also datapacks that are more limited but still allow someone to do cool stuff leveraging tools, items, etc already in the game.
If you remember entire contraptions of command blocks doing stuff like playing Pokemon Red in Minecraft or "one commands" that summoned an entire obelisk of command blocks, the introduction of datapacks pretty much replaced both of those.
Datapacks kind of ruined the Java side. Instead of (metaphorically) "grass.colour = green;" now you have several layers of indirection to look up the mapping of block types to colours, in several real and virtual entity-attribute-value stores that shadow and inherit from each other, and the easiest way to make grass green becomes to write a data pack - with all the limitations of that, not to mention the obscure syntax (do you write "{"inherits":"dirt", "variables":{"colour":"green"}}" in stuff/things/blocks/grass/index.html.json?)
This is called the inner-platform effect, where in order to avoid programming in the original language, you invent a worse programming language. Apparently it used to be a big killer of enterprise software. It's also one of the reasons Minecraft needs ten times the RAM it used to. To be fair, we have fifty times as much RAM as we did when Minecraft came out, but wouldn't you rather have it put to use doing extended view distance, extended world height, and shaders?
I remember Notch saying in 2010 that he planned to add an official modding API, but it never actually happened.
---
Edit: https://web.archive.org/web/20100708183651/http://notch.tumb...
Data packs were released in October 2017! And we had command blocks in 2012 for custom maps
[flagged]
One thing I always notice about this kind of post is that it never only has one accusation of oppressing a demographic group. There's always three of them at once.
Makes it feel lightweight I think.
Turns out people who are like that rarely constrain it to one demographic.
Notch's problematic behavior and views are well-known in the community and both Mojang and Microsoft have had to distance themselves from him. To the point that they had to remove all instances of "notch" in the codebase
Here's some examples, particularly of his antisemitism to better illustrate the issues
https://xcancel.com/jacqui_Val/status/1111080126345826305
I'm sure you're fun at parties
Most modders aren't reverse engineering the game. There's a small community that are doing the obfuscation and then everyone else is effectively working from normal Java code.
It's that way for most modding scenes. Someone makes an API/mod loader which makes it easy, then a lot of enthusiastic players make mods.
I wonder how much overlap Minecraft modders have with the Android custom ROM/app-modding community, another thing that the easy "reversibility" of Java has spawned.
Yeah you got it backwards. Mojang refused to add a modding API, because Notch knew that the community has more freedom the way things currently are.
Actually more common than you might think.
Bethesda games have the same ecosystem - they do provide an official plugin system, but since modders aren't content with the restrictions of that system, they reverse engineered the game(s, this has been going on since Oblivion) and made a script extender that hacks the game in-memory to inject scripts (hence the name).
While I don't doubt that some mods are created by teens, just under half of Minecraft players are adults.