Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Notice they're only doing this after the game is ensloppified (they make their money from merch and movies now, not from game sales) and after the game code suffers from so much inner-platform effect that modding it directly isn't as useful any more.

The inner platform effect is when, in an effort to make it so people don't have to use the original programming language because programming is complicated, you create a worse programming language and make people use that. In Minecraft, it's data and resource packs. The Java code isn't just a function on the block that renders it, any more - there's a bunch of indirection through resource packs, and they've gone abstraction hell with that too, adding unnecessary abstractions in the way of the actual abstraction they want.



Their model seems to be to keep Java Edition reasonably pure and close to the original spirit (with most of the original developers working on that), but do all the minebux exploitation on Bedrock, where a big majority of the children players are. The main evil thing they've done to Java players is the account migration, but even that was sort of understandable given how questionable Mojang's original account system was.


> modding it directly isn't as useful any more.

Can you elaborate on this? This seems like a strange way of saying, "it's easier to mod little things with data/resource packs" - and mods are still absolutely necessary, as data/resource packs can't do everything. But they're great for, say, adding tags to random items (something I do regularly) or - the most obvious usecase - texture packs


Previously if you wanted to create a simple block type you would write something like this (very roughly and excusing HN not supporting code formatting):

public class MyBlock extends Block {public Icon getTexture() {return 0;} public String getTextureAtlasPath() {return "/mymod.png";}}

Later it was

public class MyBlock extends Block {Icon icon; public void registerIcons(IconRegistry r) {icon = r.register("mymod:myblock");} public Icon getTexture() {return icon;}}

You need a little bit more code and you have to know that "mymod:myblock" really means "/assets/mymod/icons/blocks/myblock.png" but it's not too bad. (Why not specify the actual path?)

But now it takes the Java class, plus about 5 different JSON files that are magically linked based on strings like the above (interpreted differently in each context), and if you want to simply set the icon in a few lines of code like before, you can't because all the code is specialized for handling JSON files. https://docs.minecraftforge.net/en/1.12.x/models/files/

You could argue it's better because it handles more block shapes, but the story for shapes isn't much better - you used to be able to write if(thingAboutItem) renderCertainWay(); but now you can write {"when":{"certain_condition":"true"}, "apply":{"model":"certain_model"}} and there's a whole bunch of code to write to map "certain_condition" to the condition you want, and woe betide you if your model isn't a bunch of textured axis-aligned cuboids. https://docs.minecraftforge.net/en/1.12.x/models/using/ https://docs.minecraftforge.net/en/1.12.x/models/advanced/ex...

If you know the inner-platform effect, it's the inner-platform effect: creating a poor replica of part of your programming environment in the quest for "configurability" or "no-code". https://en.wikipedia.org/wiki/Inner-platform_effect https://thedailywtf.com/articles/the_inner-platform_effect https://news.ycombinator.com/item?id=39412321

Modding with data packs is harder than modding with Java used to be, and modding with Java now is also harder than modding with Java used to be, because of data packs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: