It's extraordinary to me that Minecraft is both the game that has the most robust mod community out there and that the modders were working from obfuscated, decompiled Java binaries. With elaborate tooling to deobfuscate and then reobfuscate using the same mangled names. For over a decade! What dedication.
More proof that you don't need the source code to modify software. Then again, Java has always been easy to decompile, and IMHO the biggest obstacle to understanding is the "object-oriented obfuscation" that's inherent in large codebases even when you have the original source.
First time I have heard of object-oriented obfuscation.
I get it, but in general I don't get the OO hate.
It's all about the problem domain imo. I can't imagine building something like a graphics framework without some subtyping.
Unfortunately, people often use crap examples for OO. The worst is probably employee, where employee and contractor are subtypes of worker, or some other chicanery like that.
Of course in the real world a person can be both employee and contractor at the same time, can flit between those roles and many others, can temporarily park a role (e.g sabbatical) and many other permutations, all while maintaining history and even allowing for corrections of said history.
It would be hard to find any domain less suited to OO that HR records. I think these terrible examples are a primary reason for some people believing that OO is useless or worse than useless.
For me, it's the fact that the mess of DAOs and Factories that constituted "enterprise" Java in the 00s was a special kind of hellscape that was actively encouraged by the design of the language.
Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code.
It was terrible and taught me to avoid applying for jobs that used Java.
I like OOP and often use it. But mostly just as an encapsulation of functionality, and I never use interfaces or the like.
As someone coding since 1986 it is always kind of interesting how Java gets the hate for something that it never started, and was already common in the industry even before Oak became an idea.
To the point that there are people that will assert the GoF book, published before Java was invented, actually contains Java in it.
It was so rare that the GoF though they needed to write a book to teach people how to use those patterns when they eventually find them.
But after the book was published, those patterns became "advanced programming that is worth testing for in job interviews", and people started to code for their CVs. The same happened briefly with refactoring, and for much longer with unit tests and the other XP activities (like TDD).
At the same time, Java's popularity was exploding on enterprise software.
It is probably because Java took this design philosophy (or I should say dogma) to heart as its very syntax and structure encourages to write code like that. One example: It does not have proper modules. Modules, the one thing that most people can agree upon that are a good thing, enabling modularity, literally. Another one: You cannot have simply a function in a module. Shit needs to be inside classes or mixed up with other unrelated concepts. Java the language encourages this kind of madness.
It is called packages. There is nothing on the modules as programming concept that requires the existence of functions as entity.
Again, Smalltalk did it first, and is actually one of the languages on the famous GoF book, used to create all the OOP patterns people complain about, the other being C++.
> There is nothing on the modules as programming concept that requires the existence of functions as entity.
I didn't claim it does. To make the point though: bare functions are a much simpler building block, and a much cleaner building block than classes. Classes by their nature put state and behavior in one place. If one doesn't need that, then a class is actually not the right concept to go for (assuming one has the choice, which one doesn't in Java). A few constants and a bunch of functions would be a simpler and fully sufficient concept in that case. And how does one group those? Well, a module.
In Java you are basically forced to make unnecessary classes, that only have static functions as members, to achieve a similar simplicity, but then you still got that ugly class thing thrown in unnecessarily.
In a few other languages maybe things are based on different things than functions. Like words in Forth or something. But even they can be interpreted to be functions, with a few implicit arguments. And you can just write them down. No need to put them into some class or some blabliblub concept.
From type systems theory point of view, a class is an extensible module that can be used as a variable.
As mentioned in another reply, Java did not invent this, it was building upon Smalltalk and SELF, with a little bit of Objective-C on the side, and C++ like syntax.
Try to create a single function in Smalltalk, or SELF.
It is also no accident that when Java came into the scene, some big Smalltalk names like IBM, one day of the other easily migrated their Smalltalk tooling into Java, and to this day Eclipse still has the same object browser as any Smalltalk environment.
Thankfully those days are not with us any more. Java has moved on quite considerably in the last few years.
I think people are still too ready to use massive, hulking frameworks for every little thing, of course, but the worst of the 'enterprise' stuff seems to have been banished.
I hope you are right. I really do. But I have a hunch, that if I accepted any Java job, I would simply have coworkers, who are still stuck with "enterprise" Java ideology, and whose word has more weight than the word of a newcomer. That's one of the fears, that stops me from seriously considering Java shops. Fear of unreasonable coworkers and then being forced to deliver shitty work, that meets their idea of how the code should be written in the most enterprise way they can come up with.
Always makes me think of that AbstractProxyFactorySomething or similar, that I saw in Keycloak, for when you want to implement your own password quality criteria. When you step back a bit and think about what you actually want to have, you realize, that actually all you want is a function, that takes as input a string, and gives as output a boolean, depending on whether the password is strong enough, or fulfills all criteria. Maybe you want to output a list of unmet criteria, if you want to make it complex. But no, it's AbstractProxyFactorySomething.
I'm personally rather fond of Java, but even this (or the shorter `Predicate`) still can't compete with the straightforward simplicity of a type along the lines of `string -> bool`.
> that was actively encouraged by the design of the language.
Java hasn't changed that much since the "hellscape" 00s. Is it better now? Or what is specific to the language the encourages "the mess of DAOs and Factories"? You can make all of those same mistakes in Python, C# or C++. I have used Java for about 15 years now and I have never written any of that junky enterprise crap with a million layers of OO.
> I never use interfaces or the like.
This is the first that I heard any disdain towards interfaces. What is there not to like?
It insists upon itself. That’s really the problem with Java’s design philosophy from that era; it encourages ceremony. Even if you don’t write the full-on "Enterprise™" soup of DAOs, Factories, and ServiceLocators, the language’s type system and conventions gently nudge you toward abstraction layers you don’t actually need.
Interfaces for everything, abstract classes “just in case,” dependency injection frameworks that exist mainly to manage all the interfaces. Java (and often Enterprise C#) is all scaffolding built to appease the compiler and the ideology of “extensibility” before there’s any actual complexity to extend.
You can write clean, functional, concise Java today, especially with records, pattern matching, and lambdas, but the culture around the language was forged in a time when verbosity was king.
You can't buy your way out of this, because C++ builds are only parallelizable across multiple translation units[1] (i.e. separate .cpp files). Unless you're willing to build a better single-core CPU, there's not much you can do.
The challenge with modern C++ projects is that every individual TU can take forever to build because it involves parsing massive header files. Oftentimes you can make this faster with "unity builds" that combine multiple C++ files into a single TU since the individual .cpp file's build time is negligible compared to your chonky headers.
The reason the header files are so massive is because using a templated entity (function or class) requires seeing the ENTIRE DEFINITION at the point of use, because otherwise the compiler doesn't know if the substitution will be successful. You can't forward declare a templated entity like you would with normal code.[2]
If you want to avoid including these definitions, you create an abstract interface and inherit from that in your templated implementations, then pass the abstract interface around.
[1] or linking with mold
[2] There used to be a feature that allowed forward declaring templated entities called "export". A single compiler tried to implement it and it was such a failure it was removed from the language. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n14...
That's why they're called generic parameters, not template parameters; the code is generic over all possible parameters, not templated for every possible parameter.
I was a C++ programmer for many years, but I never heard this claim. I asked Google AI and it disagees.
> does c++ have reified generics?
> C++ templates do not provide reified generics in the same sense as languages like C# or Java (to a limited extent). Reified generics mean that the type information of generic parameters is available and accessible at runtime.
Interesting I’d never picked up on this pedantic subtlety. I too thought reified meant what you could do at the call site not what you could do at runtime. Was my understanding wrong, or is Gemini hallucinating.
In any event, you have to use weird (I think “unsafe”) reflection tricks to get the type info back at runtime in Java. To the point where it makes you think it’s not supported by the language design but rather a clever accident that someone figured out how to abuse.
I have used something similar with effects in Haskell to mock "the real world" for running tests.
But if it was as convoluted to use as it's in Java, I wouldn't. And also, it's not enterprise CRUD. Enterprise CRUD resists complex architectures like nothing else.
> Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code.
Perhaps I'm not following, but dynamically loaded objects are the core feature of shared libraries. Among it's purposes, it allows code to be reused and even updated without having to recompile the project. That's pretty useful.
Interfaces are also very important. They allow your components to be testable and mockable. You cannot have quality software without these basic testing techniques. Also, interfaces are extremely important to allow your components to be easily replaced even at runtime.
Perhaps you haven't had the opportunity to experience the advantages of using these techniques, or were you mindful of when you benefited from them. We tend to remember the bad parts and assume the good parts are a given. But personal tastes don't refute the value and usefulness of features you never learned to appreciate.
> > Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code.
> Perhaps I'm not following, but dynamically loaded objects are the core feature of shared libraries. Among it's purposes, it allows code to be reused and even updated without having to recompile the project. That's pretty useful.
> Interfaces are also very important. They allow your components to be testable and mockable. You cannot have quality software without these basic testing techniques. Also, interfaces are extremely important to allow your components to be easily replaced even at runtime.
I don't think GP was saying that Dynamically loaded objects are not needed, or that Interfaces are not needed.
I read it more as "Dynamically loaded interfaces that can be swapped out are not needed".
> Also, interfaces are extremely important to allow your components to be easily replaced even at runtime.
The share of all software that actually benefits from this is extremely small. Most web-style software with stateless request/response is better architected for containers and rolling deployments. Most businesses are also completely fine with a few minutes of downtime here and there. For runtime-replacement to be valuable, you need both statefulness and high SLA (99.999+%) requirements.
To be fair, there is indeed a subset of software that is both stateful and with high SLA requirements, where these techniques are useful, so it's good to know about them for those rare cases. There is some pretty compelling software underneath those Java EE servers for the few use-cases that really need them.
Explain then what is your alternative to unit and integration tests.
> Mock are often the reason of tests being green and app not working :)
I don't think that's a valid assumption. Tests just verify the system under test, and test doubles are there only to provide inputs in a way that isolates your system under test. If your tests either leave out invariants that are behind bugs and regressions or have invalid/insufficient inputs, the problem lies in how you created tests, not in the concept of a mock.
I personally believe mocks are a bad practice which is caused by bad architecture. When different components are intertwined, and you cannot test them in isolation, the good solution is refactoring the code; the bad is using mocks.
For example of such intertwined architecture see Mutter, a window manager of Gnome Shell (a program that manages windows on Linux desktop). A code that handles key presses (accessibility features, shortcuts), needs objects like MetaDisplay or MetaSeat and cannot be tested in isolation; you figuratively need a half of wayland for it to work.
The good tests use black box principle; i.e. they only use public APIs and do not rely on knowledge of inner working of a component. When the component changes, tests do not break. Tests with mocks rely on knowing how component work, which functions it calls; the tests with mocks become brittle, break often and require lot of effort to update when the code changes.
It's not necessary to have mocks for unit tests. They can be a useful tool, but they aren't required.
I am fine with having fake implementations and so forth, but the whole "when function X is called with Y arguments, return Z" thing is bad. It leads to very tight coupling of the test code with the implementation, and often means the tests are only testing against the engineer's understanding of what's happening - which is the same thing they coded against in the first place. I've seen GP's example of tests being green but the code not working correctly a number of times because of that.
Most compilers do not use "unit" tests per se. Much more common are integration tests targeted at a particular lowering phase or optimization pass.
This is pretty important since "unit tests" would be far too constraining for reasonable modifications to the compiler, e.g. adding a new pass could change the actual output code without modifying the semantics.
>Explain then what is your alternative to unit and integration tests.
Tests against real components instead of mocks.
>If your tests either leave out invariants that are behind bugs and regressions or have invalid/insufficient inputs, the problem lies in how you created tests, not in the concept of a mock.
Nowadays external components can be very complex systems e.g dbs, messaging queues, 3rd APIs and so on
A lot of things can go wrong and you arent even aware of them in order to get mocks right.
Examples? fuckin emojis.
On mocked in memory database they work fine, but fail on real db due to encoding settings.
I'm not a fan of extensive mocking but you're conflating two rather different test cases. A test where you mock out the database connection is testing something in application code, which has nothing to do with database configuration. You should of course have tests towards the database too, but then you'd mock out parts of the application instead and not the database itself.
It's because the concepts are the same, but people get enraged by the words. What Java calls a factory would be a "plugin loader" in C++. It's the same concept. And most big C++ codebases end up inventing something similar. Windows heavily uses COM which is full of interfaces and factories, but it isn't anything to do with Java.
Java I think gets attacked this way because a lot of developers, especially in the early 2000s, were entering the industry only familiar with scripting languages they'd used for personal hobby projects, and then Java was the first time they encountered languages and projects that involved hundreds of developers. Scripting codebases didn't define interfaces or types for anything even though that limits your project scalability, unit testing was often kinda just missing or very superficial, and there was an ambient assumption that all dependencies are open source and last forever whilst the apps themselves are throwaway.
The Java ecosystem quickly evolved into the enterprise server space and came to make very different assumptions, like:
• Projects last a long time, may churn through thousands of developers over their lifetimes and are used in big mission critical use cases.
• Therefore it's better to impose some rules up front and benefit from the discipline later.
• Dependencies are rare things that create supplier risks, you purchase them at least some of the time, they exist in a competitive market, and they can be transient, e.g. your MQ vendor may go under or be outcompeted by a better one. In turn that means standardized interfaces are useful.
So the Java community focused on standardizing interfaces to big chunky dependencies like relational databases, message queuing engines, app servers and ORMs, whereas the scripting language communities just said YOLO and anyway why would you ever want more than MySQL?
Very different sets of assumptions lead to different styles of coding. And yes it means Java can seem more abstract. You don't send queries to a PostgreSQL or MySQL object, you send it to an abstract Connection which represents standardized functionality, then if you want to use DB specific features you can unwrap it to a vendor specific interface. It makes things easier to port.
I am currently being radicalised against OOP because of one specific senior in my team that uses it relentlessly, no matter the problem domain. I recognise there are problems where OOP is a good abstraction, but there are so many places where it isn't.
I suspect many OOP haters have experienced what I'm currently experiencing, stateful objects for handing calculations that should be stateless, a confusing bag of methods that are sometimes hidden behind getters so you can't even easily tell where the computation is happening, etc
But there's a real difference how easy it is to write crappy code in a language. In regards to java that'd be, for example, nullability, or mutability. Kotlin, in comparison, makes those explicit and eliminates some pain points. You'd have to go out of your way and make your code actively worse for it to be on the same level as the same java code.
And then there's a reason they're teaching the "functional core, imperative shell" pattern.
On the other hand, Java's tooling for correctly refactoring at scale is pretty impressive: using IntelliJ, it's pretty tractable to unwind quite a few messes using automatic tools in a way that's hard to match in many languages that are often considered better.
I agree with your point, and I want to second C# and JetBrains Rider here. Whatever refactoring you can with Java in JetBrains IntelliJ, you can do the same with C#/Rider. I have worked on multiple code bases in my career that were 100sK lines of Java and/or C#. Having a great IDE experience was simply a miracle.
You gotta admit, though, that a language which strongarms you into writing classes with hidden state and then extending and composing them endlessly is kinda pushing you in that direction.
It’s certainly possible to write good code in Java but it does still lend itself to abuse by the kind of person that treated Design Patterns as a Bible.
>kind of person that treated Design Patterns as a Bible
I have a vague idea of what the Bible says, but I have my favorite parts that I sometimes get loud about. Specifically, please think really hard before making a Singleton, and then don't do it.
Singletons are so useful in single threaded node land. Configuration objects, DB connection objects that have connection pooling behind them, even my LLM connection is accessed via a Singleton.
OK yeah that's a pretty good general principle. You think you only need one of these? Are you absolutely certain? You SURE? Wrong, you now need two. Or three.
A singleton is more than just, "I only need one of these," it is more of a pattern of "I need there to be only one of these," which is subtly different and much more annoying.
Separation of data and algorithm is so useful. I can't really comment on how your senior is doing it, but in the area of numeric calculations, making numbers know anything about their calcs is a Bad Idea. Even associations with their units or other metadata should be loose. Functional programming provides such a useful intellectual toolkit even if you program in Java.
Sorry to learn, hope you don't get scar tissue from it.
Not sure how many people are writing programs with lots of numeric calculations.
Most programs in my experience are about manipulating records: retrieve something from a database, manipulate it a bit (change values), update it back.
Over here OOP do a good job - you create the data structures that you need to manipulate, but create the exact interface to effect the changes in a way that respect the domain rules.
I do get that this isn't every domain out there and _no size fits all_, but I don't get the OP complaints.
I currently think that most of the anger about OOP is either related to bad practices (overusing) or to lack of knowledge from newcomers. OOP is a tool like any other and can be used wrong.
Creating good reusable abstractions is not easy. It's quite possible to create tarballs of unusuable or overwrought abstractions. That is less of a knock on OOP and more a knock on the developers.
But that is what classes does, it lets you have data lists and dictionaries implemented as a class so that your algorithm doesn't have to understand how the data structure is implemented. In functional programming the algorithm has to be aware of the data structure, I feel that is much worse.
> I recognise there are problems where OOP is a good abstraction, but there are so many places where it isn't.
Exactly. This is the way to think about it, imo. One of those places is GUI frameworks, I think, and there I am fine doing OOP, because I don't have a better idea how to get things done, and most GUI frameworks/toolkits/whatever are designed in an OOP way anyway. Other places I just try to go functional.
I agree. Neither OOP nor functional programming should be treated as a religion or as a paradigm that one must either be fully invested in or not.
OOP is a collection of ideas about how to write code. We should use those ideas when they are useful and ignore them when they are not.
But many people don't want to put in the critical thinking required to do that, so instead they hide behind the shield of "SOLIDD principles" and "best practice" to justify their bad code (not knocking on SOLIDD principles, it's just that people use it to justify making things object oriented when they shouldn't be).
I think the OO hatred comes from how academia and certain enterprise organisations for our industry picked it up and taught it like a religion. Molding an entire generation og developers who wrote some really horrible code because they were taught that abstractions were, always, correct. It obviously weren't so outside those institutions, the world slowly realized that abstractions were in many ways worse for cyclomatic complexity than what came before. Maybe not in a perfect world where people don't write shitty code on a thursday afternoon after a long day of horrible meetings in a long week of having a baby cry every night.
As with everything, there isn't a golden rule to follow. Sometimes OO makes sense, sometimes it doesn't. I rarely use it, or abstractions in general, but there are some things where it's just the right fit.
> I think the OO hatred comes from how academia and certain enterprise organisations for our industry picked it up and taught it like a religion.
This, this, this. So much this.
Back when I was in uni, Sun had donated basically an entire lab of those computers terminals that you used to sign in to with a smart card (I forgot the name). In exchange, the uni agreed to teach all classes related to programming in Java, and to have the professors certify in Java (never mind the fact that nobody ever used that laboratory because the lab techs had no idea how to work with those terminals).
As a result of this, every class from algorithms, to software architecture felt like like a Java cult indoctrination. One of the professors actually said C was dead because Java was clearly superior.
Java was probably close to 50% of the job market at some point in the 2000s and C significantly dried up with C++ taking its place. So I'm afraid everyone was right actually.
To be honest, I'm convinced the reason so many people dislike Java is because they have had to use it in a professional context only. It's not really a hobbyist language.
Just for the record, I don't think C ever dried up in the embedded space. And the embedded space is waaaay bigger than most people realise, because almost all of it is proprietary, so very little "leaks" onto the public interwebs.
tourist2d seems to have triggered some moderation trap, but wrote:
> Sounds like a problem with poor code rather than something unique to OOP.
And yeah, OO may lean a bit towards more indirection, but it definitely doesn't force you to write code like that. If you go through too many levels, that's entirely on the developer.
They use higher order types to implement subtyping as a library, with combinators. For example, you can take your fudget that does not (fully) implement some functionality, wrap it into another one that does (or knows how to) implement it and have a combined fudget that fully implements what you need. Much like parsing combinators.
It's the misuse of OO constructs that gives it a bad name, almost always that is inheritance being overused/misused. Encapsulation and modularity are important for larger code bases, and polymorphism is useful for making code simpler, smaller and more understandable.
Maybe the extra long names in java also don't help too, along with the overuse/forced use of patterns? At least it's not Hungarian notation.
Heck, I love the long names. I know, I also hate FooBarSpecializedFactory, but that's waaaay better than FBSpecFac.
A sample: pandas loc, iloc etc. Or Haskell scanl1. Or Scheme's cdr and car. (I know - most of the latest examples are common functions that you'll learn after a while, but still, reading it at first is terrible).
My first contact with a modern OO language was C# after years of C++. And I remember how I thought it awkward that the codebase looked like everything was spelled out. Until I realize that it is easier to read, and that's the main quality for a codebase.
Computers work on data. Every single software problem is a data problem. Learning to think about problems in a data oriented way will make you a better developer and will make many difficult problems easier to think about and to write software to solve.
In addition to that, data oriented software almost inherently runs faster because it uses the cache more efficiently.
The objects that fall out of data oriented development represent what is actually going on inside the application instead of how an observer would model it naively.
I really like data oriented development and I wish I had examples I could show, but they are all $employer’s.
Even with non-obfuscated code, if you're working with a decompilation you don't get any of the accompanying code comments or documentation. The more abstractions are present, the harder it is to understand what's going on. And, the harder it is to figure out what code changes are needed to implement your desired feature.
C++ vtables are especially annoying. You can see the dispatch, but it's really hard to find the corresponding implementation from static analysis alone. If I had to choose between "no variable names" and "no vtables", I'd pick the latter.
Vtables can be annoying to follow through, but try reverse-engineering an Objective-C binary! Everything is dispatched dynamically, so 99% of the call graph ends in objc_msgSend(). Good luck figuring out what the message is, and the class of the object receiving it.
Isn't that easy? The message is a string in one of the register parameters to it.
> Everything is dispatched dynamically
Well, not everything, there is NS_DIRECT. The reason for that being that dynamic dispatch is expensive - you have to keep a lot of metadata about it in the heap for sometimes rarely-used messages. (It's not about CPU usage.)
It’s all about the data model and the architecture.
I think people focus a lot on inheritance but the core idea of OO is more the grouping of values and functions. Conceptually, you think about how methods transforms the data you are manipulating and that’s a useful way to think about programs.
This complexity doesn’t really disappear when you leave OO language actually. The way most complex Ocaml programs are structured with modules grouping one main type and the functions working on it is in a lot of way inspired by OO.
You're right, it is all about the problem domain. Unfortunately, there was a solid decade where that was not the typical advice, and OO was pushed (in industry and in education) as the last word in programming, suitable for all tasks. There's a generation out there who was taught programming as "instantiate a truck object that inherits from a car object" and another generation who was required to implement math using OOP principles instead of just doing math. Programming languages that did not have object models suddenly developed them, often incompatibly with the rest of the language. So, while I think that OO has its places, I understand why there's a lot of visceral response to it online.
> I can't imagine building something like a graphics framework without some subtyping.
While React technically uses some OOP, in practice it's a pretty non-OOP way do UI. Same with e.g. ImGUI (C++), Clay (C). I suppose for the React case there's still an OOP thing called the DOM underneath, but that's pretty abstracted.
In practice most of the useful parts of OOP can be done with a "bag/record of functions". (Though not all. OCaml has some interesting stuff wrt. the FP+OOP combo which hasn't been done elsewhere, but that may just be because it wasn't ultimately all that useful.)
React is a kind of strange dysfunctional OOP pretending not to be, to appeal to people like those on this thread ;)
Function calls have state, in React. Think about that for a second! It totally breaks the most basic parts of programming theory taught in day one of any coding class. The resulting concepts map pretty closely:
• React function -> instantiate or access a previously instantiated object.
• useState -> define an object field
• Code inside the function: constructor logic
• Return value: effectively a getResult() style method
The difference is that the underlying stateful objects implemented in OOP using inheritance (check out the blink code) is covered up with the vdom diffing. It's a very complicated and indirect way to do a bunch of method calls on stateful objects.
The React model doesn't work for a lot of things. I just Googled [react editor component] and the first hit is https://primereact.org/editor/ which appears to be an ultra-thin wrapper around a library called Quill. Quill isn't a React component, it's a completely conventional OOP library. That's because modelling a rich text editor as a React component would be weird and awkward. The data structures used for the model aren't ideal for direct modification or exposure. You really need the encapsulation provided by objects with properties and methods.
React is most likely not what the author had in mind by a graphics framework. The browser implementation of the DOM or a desktop widget system is much more likely the idea.
Yeah, I agree with you, and actually like OOP where it's appropriate.
Unfortunately there were so many bad examples from the old Java "every thing needs a dozen factories and thousands of interfaces" days that most people haven't seen the cases where it works well.
I find inheritance works best when you model things that don't exist in reality, but only as software concepts, for example, an AbstractList, Buffer or GUI component.
Any modern IDE will let you immediately bring up the subclasses with a single hotkey. If you have an abstract class with only a single subclass and that's not because new code is going to be added soon then yes, it's a bad design decision. Fortunately, also easy to fix with good IDEs.
That sort of knee-jerk over-application of a technique will ruin any codebase in any language, unfortunately. It tends to reflect a lack of confidence by the developers. They aren't entirely sure how to get best results so fall back on religious devotion to 'best practices' even when it's inappropriate, in the hope that they can point the finger later if there are problems.
It's all about the problem domain imo. I can't imagine building something like a graphics framework without some subtyping.
The keyword being "some".
Yes, there are those who can use OOP responsibly, but in my (fortunately short) experience with Enterprise Java, they are outnumbered by the cargo-cult dogma of architecture astronauts who advocate a "more is better" approach to abstraction and design patterns. That's how you end up with things like AbstractSingletonProxyFactoryBean.
Tbh decompiling software and figuring out how it works isn’t easy but that is part of the fun :) - it’s the reason ive ended up following many of the weird paths in computing that I have
Agreed; modding obfuscated Java is impressive, but not quite on the level of modding in the (Nintendo) emulation community. The things that have been achieved with classic Nintendo titles are absurd, like adding high-performance online multiplayer to Super Smash Bro. Melee.
Yeah, I honestly think that the thing which would kill modding in the future won't be any kind of (overtly) hostile action, it will simply be sheer inertia. Since the new "drop" system, pretty much every minor version requires rewriting many things in your mod, and modders find it hard to keep up, and there will be point when many mods just don't bother updating to the newest version.
The game used to be simple, both conceptually and codewise but obviously, it became more and more bloated the more developers touched it and the more bureaucracy was added. Now, it's a complete nightmare, and I bet it's also a nightmare for the developers too, considering how hard it is for them to fix even basic issues which have been in the game for like a decade at this point.
indeed. with how good and cheap/free decompilers have gotten over the years my preferred way to read abstraction-happy c++ and rust code is to compile it with optimisations and debug symbols and then read the decompiler output.
Very few people use mojang mappings -- the two big modloaders, forge and fabric (and their derivatives) have their own mappings respectively, due to the restrictions of the mojang mappings. It's possible to use the mojang mappings, but much less common.
Paper isn’t a mod loader, it uses Fabric under the hood. Also, what makes you think it’s the most popular server? I thought it was fading. I switched my server from Paper to Fabric years ago.
It doesn't use Fabric under the hood, where did you hear that?
> Also, what makes you think it’s the most popular server?
Because it's the only server software that can actually scale and support a long-term server with feature and bugfix stability. Its popularity bears out in what hosting companies say people are most commonly using. Though I'm not sure if there is a specific publicly published statistic to point to to prove this - there is bStats global stats, but it is biased towards the Paper ecosystem.
Fabric is getting close with certain optimization and bugfixing mods, but it's still not there. Paper has a checklist of what optimizations and fixes must be included for a release to proceed, whereas Fabric ecosystem is still a hodgepodge of different things that are only available on specific Minecraft versions.
I've recently been setting up a velocity server network for some friends and friends of friends, and I agree with your findings. I don't have much history on Forge vs Paper vs Fabric vs..... (and found it all very overwhelming, honestly) but from what I can tell, the popular sites like modrinth have communities way more focused around Forge/NeoForge.
Paper does seem to have it's own site for plugins, hangar or something? (Don't have my web history on this PC) but the community support doesn't seem nearly as fleshed out.
It is incredible though, before 1.21 the last time I played around with MC server hosting was probably around 1.8 days, when it seemed like you only had Bukkit and a few plugins for it
Paper is custom server software and could be easily argued to be a mod loader if you consider plugins to be mods (although it’s probably a weak argument since there’s no mixin support built-in, although some large servers have added mixin support to their own Paper forks). However, it does not use Fabric under the hood (it’s based on Bukkit/CraftBukkit). By playercount, it is the largest (custom, standalone) MC server software in the world.
I tend to think the distinction between "plugins" and "server-side mods" is a little pointless these days. I would consider something a "mod" if it's in an environment where it can deeply touch Mojang code and completely transform it if needed. And before we ever had Fabric/Sponge mixins, we had reflection and ASM for doing just this. We still have that, and a lot of Paper plugins make extensive use of reflection - particularly libraries that reflect into netty to hook directly into the protocol are quite common.
You’re right, my bad, Spigot (from Bukkit), not Fabric. I got the impression it’s actually using ~~Fabric~~ Spigot code for this because you’re using plugins compiled for Spigot and both a paper.whatever and spigot.whatever config file, but after looking it up I see that they forked it.
I’m not really clear on mod vs plugin vs mixin, I was just trying to refer to whatever software does the decompilation work rather than just consuming APIs provided by projects that do.
Sounds like it’s correct that Paper didn’t do its own mod API, but incorrect that Paper doesn’t do its own decompilation work.
> By playercount, it is the largest (custom, standalone) MC server software in the world.
Do you have a source on this? Not trying to accuse you of anything, I just know that a few servers claim this, and don’t know if we have reliable numbers.
Ah, I was aware of the different Fabric (Yarn) mappings and internal names (due to the few mods like architectury) but I think Forge switched over to Mojang's?
> As of 1.16.5 [(2021)], Forge will be using Mojang’s Official Mappings, or MojMaps, for the forseeable future
Proguard can also apply optimizations while it obfuscates. I think a good JVM will eventually do most of them itself, but it can help code size and warm-up. I'm guessing as JVMs get better and everyone is less sensitive to file sizes, this matters less and less.
One of the biggest optimizations it offers is shrinking the size of the classes by obfuscating the names. If you're obfuscating the names anyway, there's no reason that the names have to be the same length.
"hn$z" is a heck of a lot smaller than "tld.organization.product.domain.concern.ClassName"
So we're not talking about runtime performance, but some minor improvement in loading times? I assume that once the JVM has read the bytecode, it has its own efficient in-memory structures to track references to classes rather than using a hash map with fully qualified names as keys
Proguard was heavily influenced by the needs of early Android devices, where memory was at a real premium. Reducing the size of static tables of strings is a worthwhile optimisation in that environment
Even a hash map with fully qualified names as keys wouldn't be so bad because Stirng is immutable in Java, so the hash code can be cached on the object.
They have to be stored somewhere, but they don't have to be what the JVM uses when it e.g performs a function call at runtime. Just having the names in memory doesn't slow down program execution.
According to the v8 devs it also can increase parsing performance
> Our scanner can only do so much however. As a developer you can further improve parsing performance by increasing the information density of your programs. The easiest way to do so is by minifying your source code, stripping out unnecessary whitespace, and to avoid non-ASCII identifiers where possible.
In 2004 I played an MMO game on a pirated server. The owner of the server somehow got a version of the server binary, and used a hex editor (!) to add new features to the binary over time.
It's the closest I've ever see to someone literally being one of the hackers from Matrix, literally staring at hexadecimal and changing chars one at a time
Presumably they were using a decompiler e.g. IDA Pro to know what characters to change in the hex editor? I've done that before to find offsets in the binary to NOP out some function calls.
I just remember when I cracked Space Empires III shareware as child. I didn't release the crack. Plus was a bit crappy, needing every time that I loaded the game, write a wrong serial so the check thought that was right serial code. I simple changed a few x86 opcodes to invert the check condition...
That approach is also super useful if you're manually flashing an image onto some embedded thing (like an ECU, or other types of boot rom). Of course on many modern systems you'll have to get around the checksum guards, but there's typically all sorts of glitch hacks to do that.
Wasn't that WoW? I vaguely recall that a lot of the private servers worked off of a copied and / or decompiled version of their own server software for years, which is also why they never went further than the WotLK expansion. (the other part of that was people didn't want to, but that's another discussion)
AFAIK the WoW server code was never leaked. All private server code bases were developed by reverse engineering network traffic, game behaviour and client asset files.
E.g. the code for AzerothCore is fully available (and very easy to run on very low spec hardware)
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
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.
> 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?
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.
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
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.
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.
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).
This is fairly common in gaming mods. I wrote some mods myself and had to work with decompiled obfuscated code to find the right hooks, injection points, reverse implementations, etc.
Java is pretty easy to decompile and it's not a huge amount of effort to poke into the generated JVM code and start doing things. If you have a decent idea of how VMs work, C-like languages work, and how object dispatch works it's really not that hard. Also the early modding scene for Minecraft was really fun. I was a huge Minecraft player at the time and was early into the deobfuscating -> modding scene and the community was one of the most fun computing communities I've been in. Due to how focused it was on the game and its output it wasn't bogged down in nearly as much bikeshedding and philosophy as most FOSS projects get. Honestly one of the highlights of the coding I've done in my life.
I am terrified by Minecraft mods always being distributed from dodgy download sites and not rarely come with their own Windows EXE installers. And as far as I know there is no sandboxing at all in the game (uhm, no pun intended) so once installed the mod has full access to your computer?
As someone whose kid has pulled me into the world of using mods (though not (yet) making them for Java Edition) I think this PSA is worth sharing of how to use minecraft mods without pain and with minimal risk, in case anyone is getting started, or has gotten started and finds it frustrating:
1. Use MultiMC to manage instances with various mods, since mods are rarely compatible with each other, and since each version of a mod only is compatible with a single specific point release of the game itself.
Never download any EXE files to get a mod, that does sound sketch AF.
2. mods are always packaged for a particular Loader (some package for multiples and some require Forge, Fabric, or NeoForge), and MultiMC can install any of them into a given instance. Aside from different startup screens there seems to be no difference so idk why we need 3 different ones.
3. Curseforge's website and modrinth both seem to be legit places to get mods from. I personally find the installable Curseforge program itself to be bad and spammy, and would never use that, but the site still lets you directly download the jars you need, and lets you check "Dependencies" to find out what other mods you need.
If you're using MuliMC or one of its various forks, you can search for and install mods from modrinth or curseforge right in the launcher. I fine it more convienent than doing it with a browser and dragging them in, but either way works.
Curseforge is OK, Modrinth is a less commercial alternative. The ten first Google hits if you search "Minecraft mods" are probably NOT OK, most Minecraft-related stuff is SEO optimized to hell by sites which are very fishy.
There are actually two versions of the Curseforge client, the "Overwolf" version that is built on that platform (and is quite bad as a result) and a newer standalone version that doesn't use Overwolf, it's much better.
> 3. Curseforge's website and modrinth both seem to be legit places to get mods from. I personally find the installable Curseforge program itself to be bad and spammy, and would never use that, but the site still lets you directly download the jars you need, and lets you check "Dependencies" to find out what other mods you need.
PrismLauncher, a popular MultiMC fork, has direct integration with Curseforge and Modrinth, while being completely ad-free. Best of both worlds.
A few mods are not available because Curseforge allows mod authors the option to force ad monetization by blocking API access, but these are few and far between.
Yeah mods are just regular Java .jars that can do anything. To circumvent this issue Mojang introduced datapacks but they are super limited in what they can do. They’re basically just Minecraft commands in a file along with some manifest files to change e.g. mob loot drop rates. These Minecraft commands are Turing complete but a huge PITA to work with directly, no concept of local variables or if statements, no network access, etc. Every entity in MC has associated NBT data that is similar to JSON that stores values like position, velocity, inventory, etc. You can change NBT with commands for mobs, but in what can only be described as a religious decision, Minecraft commands are unable to modify player NBT. So for example it is impossible to impart a velocity on a player.
One wonders why Mojang didn’t embed Lua or Python or something and instead hand-rolled an even shittier version of Bash. The only reason MC servers like Hypixel exist is because the community developed an API on top of the vanilla jar that makes plugin development easy. Even with that there is still no way for servers to run client-side code, severely limiting what you can do. They could’ve easily captured all of Roblox’s marketshare but just let that opportunity slip through their fingers. Through this and a series of other boneheaded decisions (huge breaking changes, changes to the base game, lack of optimization), they have seriously fractured their ecosystem:
- PvP is in 1.8 (a version from 2015) or sometimes even 1.7 (from 2013)
- Some technical Minecraft is latest, some is in 1.12 (from 2017)
- Adventure maps are latest version
- Casual players play Bedrock (an entirely different codebase!)
The words “stable API” have never been said in the Mojang offices. So the community made their own for different versions, servers use the Bukkit 1.8 API, client 1.8 mods use Forge, latest mods use Forge or Fabric. The deobfuscated names are of little utility because the old names are so well ingrained, and modders will also probably avoid them for legal reasons.
> I am terrified by Minecraft mods always being distributed from dodgy download sites and not rarely come with their own Windows EXE installers.
That's not their main mean of distribution, most often those sites were just third parties unrelated to the mod authors that repackaged the mod and somehow got a better SEO. But TBF back in the days the UX/UI for installing mods was pretty terrible. Nowadays there are more standardized and moderated distribution websites from which you just download the .jar of the mod.
> And as far as I know there is no sandboxing at all in the game (uhm, no pun intended) so once installed the mod has full access to your computer?
This is not the norm these days! There are popular mod loaders like curseforge that pulled from moderated repositories. It’s still not bulletproof, but a far cry from trusting some installer executable
I prefer modrinth as well, both are good but curseforge has done some things which makes us require an api etc. for true automation where modrinth is genuinely nice.
I used to use prism launcher which would just give me a search box and It on the side would have things like modrinth / curseforge etc., Usually I preferred Modrinth but there were some modpacks just on curseforge only but I never really downloaded a shady modpack from some random website aside from these two, In fact sometimes I never opened up a website but just prismlauncher itself lol
I watched one of my young children power themselves through the obfuscation to learn advanced modding. There was zeal for the knowledge and mods in that community.
Mod developers were able to get the source code for Minecraft through a developer program over a decade ago. I'm not sure that it is still the case. I think they are just de-obfuscating the compiled CLASS files so anyone can decompile them without access to the source.
This was how many Runescape bots were developed back in the OSRS days. At some point (RS2?) they made the client super thin so there were no longer methods for high level game functionality (walk to here, get amount of gold in inventory, etc.).
it's actually pretty trivial and something a single person can do I had to rebuild a server jar to source since the guy maintaining it disappeared and it had special behaviors in it that were relied upon for the game networks playability.
There is always one thing that I found so facintating with the modding scene in Minecraft. Because Minecraft does not have a modding api but the java byte code can be changed. People simply developed their own way of creating an API. There are 2 main modding APIs. Forge/Neo-Forge and Fabric.
[1]Fabric uses Mix-ins while [2]Forge uses a more event based system that is added to the source code of minecraft where they add hooks into events that users can use.
To me its just incredible. Its not often that I see that users own an abstraction instead of the developers.
I wonder from a modding perspective would it be better if all public methods are just the API users can call and they themselves create a way for mods to exist?
> I wonder from a modding perspective would it be better if all public methods are just the API users can call and they themselves create a way for mods to exist?
It's the way vintage story implemented modding. They developed the whole game as engine + modapi + hooking engine for stuff outside of hookapi.
Then most of gameplay is implemented as mods on top of engine using api and hooking. And those tools are open source, with central distribution point for mods, so servers can dispatch and send update of required mods to clients as they join.
Marvellous and elegant design. Makes running a server with client side mods a breeze, because mods are automatically pushed to the clients.
Though in the end, you can't really open all the interfaces and expect it to be stable without making some huge trade offs. When it works, it's extremely pleasing. Some mods for vintage story that are made purely using mod api can work between major game versions. Even server/client version check is intentionally loose as mismatched versions can still for the most part interact across most of mechanics.
In practice, to preserve balance of api evolution and stability, not everything in the game is in the api, and thus you have to use their hooking api, and stuff that is not exposed tends to break much more often, so mods require manual updates, just like in minecraft(though not as bad, tbh. In minecraft nowadays modders tend to support both fabric and neoforge/forge apis, targeting each for at least a few major versions. In vintage story, you only gotta support one modding api heh).
You are right! I totally forgot about Vintage Story, I only read about it briefly.
> ... you can't really open all the interfaces and expect it to be stable without making some huge trade offs.
Another game I often play with a huge open interface is Crusader Kings 3 and paradox games in general. Most of the gameplay is implemented in their scripting language for the engine. But as you said when the game gets a big update most mods simply dont work anymore.
If the support of the community dies down many mods with much work and craft dont get updated anymore and rot away as the game gets updates. Quite sad actually.
Thats why I also quite like Star Wars Empire at War mods. The game does not get any updates anymore. The API here is mostly frozen, even old mods still work.
It won't do much though. Although it will make things a bit easier. A lot of minecraft mod requires direct modification to Minecraft's core mechanism. For example in popular mods: create, immersive portal and distant horizon all taps in minecraft's collision mechanism or rendering pipeline in a quite aggressive way that unlikely there will ever an abstraction be able to handle that.
And, no. Although forge does not encourage you to use it. It also supports mixin like direct modification. It's just less polished than mixin(requires more knowledge to java Bytecode)
It's unrealistic to ask mojang to make an abstraction that you can actually change everything in the core without direct modification (let alone how do mojang know what part need to be abstracted?)
I don't even think open sourcing Minecraft would hurt them financially. People don't buy Minecraft because that's the only way to play the game; it's not, it's easy to find ways to run Minecraft for free. The reason people buy it is to join servers.
Most serious servers only allow players with valid paid Minecraft accounts to join, because it allows the server owner to ban people or otherwise keep track of people. I don't see any reason why this would change just because the game client was made open source.
You can already do that and some do. Mojang, for some incomprehensible reason, even lets you disable auth in the official server's settings (`online-mode=false`).
There's no reason for them not to. Open source launchers using the "honor system" for account verification are already established and normalized. It's trivial to just comment out that verification. The jars and assets are free to download from Microsoft's servers without needing an account. It's a trivial game to get without paying, so I don't see any downside for them to open source the engine.
Honestly, I would almost settle for Microsoft open sourcing the Minecraft Java back-end server at a minimum. This alone is long overdue. The massive fanbase could have started to maintain it in ways Microsoft could only fathom.
Notch has said a lot of things over the years. Many after the sale to Microsoft were not so great. Suddenly without purpose and more money than he would ever need in a life time, he found a new purpose that wasn't so great.
A lot of Qanon rants and other conspiracy things. Just goes to show you that some times it is best you don't get what you wish for.
I have been following him, and I think a lot of the claims about him have been exaggerated. He stopped being so edgy on twitter after watching the "this is phil fish" video. It is an interesting watch and applicable to notch.
The music is definitely considered classic, you can find tons of people online talking about how it means a lot to them - and personally, I really loved the music.
I remember the early Minecraft musics from C418 to be relatively unconventional, especially some of the jukebox discs.
I started playing Minecraft again recently and while it sounds like it’s the same artist, and it’s still somewhat contemplative, it’s not dissonant anymore.
It's not the same artist. C418 had a very good deal with Notch's Mojang, letting him keep rights. Microsoft demanded that he sign over the rights to further music as work for hire. He refused, as a result the newer music in Minecraft is made by other composers who signed on to that deal and try to make music fitting with C418's style.
It's not hard to get into the library of congress? It's purposely extremely easy. I forgot who it was, but there was one big right-wing talk show host that would end all of his segments by saying it's being added to the Library of Congress as if it's an exclusive accolade, and people rightfully called him out on his shit for how easy it is to do that
The classic Minecraft music was great. Some of the new music Mojang has added in recent years is unlistenable noise. Like "glitchcore" crap. I tried playing with music on recently and after a few hours had to give up.
Interesting, I love Minecraft's music. I do listen to it intentionally outside of the game, but it's not quite the same as having it suddenly start up during gameplay. The first I heard of someone "obviously turning off the music" was, I kid you not, yesterday, and now I'm hearing it for a second time today. Would woulda thunk!
There are soundtracks I listen to outside of their games: Castlevania Symphony of the Night, Chrono Trigger, Shadowgate,... but Minecraft would be way near the end of the list. The music is too generic to be worth the attention, yet too present to work as ambiance. It kinda reminds me of Silent Hill's soundtrack.
I turn off the in-game music while playing. I prefer to listen to my own stuff, including video essays etc, but I do still enjoy a lot of the music, and I've listened to it standalone a decent amount. I would tend to the same in most sandbox games, like factorio
> If there's one game whose music I always turn off instantly it's Minecraft.
I turn it off but only because I have great difficulty with multiple sound sources at the same time. I will happily listen to C418's output for hours whilst doing something else.
(And also Touhou because who doesn't love an electric trumpet?)
no, I think they're looking for the official game to be open sourced... that's much more appealing than a knockoff since it's the version everyone actually plays.
less appealing to who? Lots of 13 year olds learned to code by writing minecraft mods so it can't be that hard. You also get the benefit & satisfaction of it actually being in Minecraft—yes, they are both very similar games where you explore and place blocks in a procedurally generated world, but it really does matter. I can't really explain why if you don't get it but it's evident people do care even when they know about Minetest.
My kids are younger than that and play Minetest/Luanti all the time. They are well aware of Minecraft but are completely engrossed by the modding first approach of Luanti.
At this point, they could open source it, and just charge for Minecraft accounts being able to authenticate with their login servers to join authenticated Minecraft servers, and it wouldn't change sales much.
Obfuscating Minecraft code doesn't make much sense to me from an IP protection angle. It is one of the easier games to build from scratch once you see how it plays. Most of the magic is emergent behavior between many simple rule systems. Nothing in that source code would be much of a revelation. It's not like there's a nanite implementation hiding in there somewhere. It's mostly boring stuff like defining how pig or sheep walk through the scene and respond to various goals. The "scariest" part of Minecraft tech is probably chunk management.
That's all true now but none of it was true back in the alpha days.
And once there were mods and mod loaders built on the obscured source, it became easier to not disrupt the toolchains than to bite the bullet; I think Mojang now wants to make moving mods easier (someone somewhere has to be a bit sad that there are famous modpacks running old versions of Minecraft because it's easier to backport everything to 1.7.10 (including running on newer Javas) than it is to update mods).
Minecraft, Roblox, Geometry Dash, Trackmania...these are games that succeeded because of their communities. Alone, they don't provide much for the average player, but creative players build interesting things that appeal to everyone.
I think one of the reasons Vision Pro and metaverse have been struggling is because their engines are bad. Not just locked down, but hard to develop on (although I don't have personal experience, I've heard this about VR in general). If you want to build a community, you must make development easy for hobbyists and small users*. I believe this has held even for the biggest companies, case in point the examples above.
* Though you also need existing reputation, hence small companies struggle to build communities even with good engines.
You can add the Flight Simulator series to the list, which spawned a vast ecosystem of add-ons, both free and commercial.
I believe though, that what you actually need as a big or small company, is good game first and foremost; the engine is secondary. When the community around a game reaches a critical mass, the very small percentage of its members who have the skills to modify things becomes significant as well.
For instance, Richard Burns Rally was not intended to be modded at all, yet the fans added new cars, new tracks, online scoreboards, etc.
In the Luanti [1] community (a voxel games engine/platform, designed to be moddable nearly from the start), one begins to see something similar as well: notable games gets mods, others don't (the former default game is a particular case; it is not exactly good but go tons of mods because of its status, and games based on it benefit from that ecosystem). Yet all use the same engine (perhaps Roblox is similar in that respect, I'm not sure if they have "reified" whole games like Luanti did).
The thing is, Minecraft of 10 years ago (or more) wasn’t even really that great of a game. It wasn’t bad, I enjoyed it, but it wasn’t that great.
What it did do right was be very open-ended and be conducive to modding, both of which were amplified by multiplayer capabilities.
I would wager that most of the fun players have had in Minecraft is from experiences that were built on top of Minecraft, not from the game’s own gameplay.
I think you're remembering Minecraft in a poor light. Even 10 years ago Minecraft was a great game because even in the base game it encouraged creativity and the community immediately realized the potential to expand that with mods.
It was, as far as I can tell, the first game which was infinitely procedurally generated yet changeable. Huge procedurally generated games have a long history but in e.g. Elite or Seven Cities of Gold you couldn't modify the world in any meaningful way. The closest is probably dwarf fortress, but there the modifiable world is pretty small (or was when Minecraft came out).
That made it a great game. I think it was inevitable that the first game which combined these two, infinite procedural worlds and free modifiability, would be a huge success. Worth noting also that infiniminer, despite the name, didn't have the infinite part worked out!
I'm always impressed when I check it, that flightsim.com is still running, and still has everyone's mods going right back to the 90s. Just in case anyone still wants the poor quality airport I uploaded for Flight Simulator 2000 twenty-something years ago.
Not sure if I understand exactly what you mean by reified, but Minecraft has a ton of minigames based on server-side mods which clone other popular games. Sometimes popular Minecraft minigames/mods even get implemented as standalone games.
Battle royale games were almost certainly heavily inspired by the Minecraft minigame which predates them. Factorio has the old industrialcraft mod as an acknowledged inspiration. Vintage Story is basically standalone Terrafirmacraft (and by a dev from that, as I recall).
Arent battle royale games inspired by things like The Hunger Games or Battle Royale? All the server minigames like that that I recall from back in the days were named something like Hunger Games
Yes. The Hunger Games film and book inspired by the Japanese film "Battle Royale" in turn, inspired the Minecraft minigame. But later battle royale games were inspired by the minigame, not the films directly. A shrinking world border, for instance, is pretty important to make the concept work (in a film, it doesn't actually have to work!).
Last man standing formats were perfectly possible in traditional FPS formats too, but they weren't really a thing because to actually be fun, the format needs
1. Big maps and lots of players (more than the typical FPS)
2. A "searching for loot" mechanic, where you can increase your chances of survival by looking for good items, making interesting risk/reward tradeoffs and discouraging just turtling up in the most defensible location.
3. Shrinking borders, to prevent an anticlimactic endgame of powerful players searching for hiding stragglers.
Minecraft basically had all three since 2014, and there were quite popular last man standing formats like UHC even before they had world border (and before the Hunger Games film came out).
Roblox had a phenomenal engine when it came out and its terrain destruction is still unmatched.
In 2006, I could download the Roblox app and bam, I would play thousands of 3D multiplayer games for free that loaded near instantly. With fully destructible buildings and dynamic terrain. Somehow I didn't get viruses from remote code execution.
That was groundbreaking at the time. In that era, I'd have to download Steam, buy individual games like Counterstrike, and the wackiest thing would be the "surf" gamemode. Most games I'd buy on CDs. I certainly couldn't knock down entire buildings with grenades.
If you contrast with Second Life/Habbo Hotel, you could walk around and talk to people I guess?
The community that spring up around it eventually carried it into total dominance of gaming for American children, but the basic parts of the engine like "click button, load into game, blow stuff up" were a decade ahead of the curve.
> I'd have to download Steam, buy individual games like Counterstrike, and the wackiest thing would be the "surf" gamemode.
It's interesting that you chose Counter-Strike as an example, as that is a Half Life mod itself, and by 2006 there was a large ecosystem [1] of Half Life modifications using Metamod and AMX Mod (X). The last one in a weird C-like language called Small or Pawn, which was my first programming language that I made serious programs with.
Especially the War3FT mod where users gained server-bound XP in combination with a reserved slots plugins which allowed top-XP users to join a full server really created a tight community of players on my tiny DSL home-hosted server.
In many ways it remains ahead of the curve. Kids that grow up making games in Roblox rarely survive the jump to a dedicated engine because Roblox is just so much easier to develop for in nearly every aspect. One big thing I've heard is that instantly getting working, robust online multiplayer by default baked into the engine is a major plus.
I would call multiplayer out of the box the defining feature for sure.
It's challenging to get networking right, and the effort required doesn't get all that much smaller just because your game is smaller.
Most engines do come with a networking framework or layer these days but Roblox gets to assume a bunch of things an engine can't, and as such provide a complete solution out of the box.
They originally accomplished this with an interesting approach to netcode you couldn't do today.
Everything was replicated in the client and server. So you could open Cheat Engine, modify your total $$$ on the client, and it would propagate to the server and everyone else playing.
They only fixed this in 2014 with FilteringEnabled/RemoteFunctions but that was opt-in until 2018 and fully rolled out in 2021 (breaking most classic Roblox games). This also made games much harder to develop.
Roblox was tiny in 2006. I joined in 2008. It was still leading the market.
To give an example, Roblox added user-created cosmetic t-shirts as a way to monetize the platform. Developers immediately scripted their games to recognize special "VIP t-shirts" that would provide in-game benefits. And quickly created idle games called "tycoons" where you could wait 2 hours to accumulate money to buy a fortress, or buy the t-shirt to skip all that.
I don't think there were any modding systems with mtx support.
I disagree with regard to Minecraft (only game I played in that list). I bought the game while it was in alpha and even then the single player experience was outstanding and sucked me in. I still have vivid memories from 15+ years ago. The balance of creativity and survival (and friggen creepers) was perfect.
I dont think I am alone in saying this. IIRC the game was making millions while still in alpha.
Yeah, I think Minecraft definitely still would have been a hit without any modding. Though it might not have become the absolute juggernaut that it is now without it -- it's hard to say for sure.
The other reason being that nobody is asking for The Metaverse, and definitely don’t want to spend huge chunks of cash on a funny hat to wear in order to access it.
Some people are asking for The Metaverse. Currently, the entire VRChat userbase. But you're right that there is not a large population of people willing to throw cash at it outside of a minority of virtual furries
Critically, VRChat works on desktop (though it's an inferior experience), and you can incrementally enhance your experience with it by doing things like webcam face/hand tracking instead of buying an expensive headset.
Examples that demonstrate why lockdown hurts ease-of-use and therefore non-intrinsically hurts community. Meta or Apple may not realize people want on desktop want to use VR software; they may want people to spend more (although a smaller community may generate less overall revenue); they may want people to have the “true” experience (their idea of what the users want, instead of what they actually want); they may not want to spend the budget and expertise to develop webcam face/hand tracking.
If they released a cheap or impressive enough VR headset, I doubt desktop or face-tracking would matter. But I think the next best thing, a decent headset with an open platform that enabled such things, would’ve saved them.
VRChat is also consistently active with people making new worlds/maps, avatars, etc. There also used to be a client modding scene with e.g. melonloader but that got cracked down on around 2022. The "metaverse" however, does it even exist? Is there a vrchat-like, meta-built social vr environment available on quest hardware?
It's also very highly customisable without being monetized out the wazoo, allows you to host your own servers, and in general avoids the incredibly bland corporate image that meta projects.
(Meta, I think, fails to understand that the people that most want a virtual space to interact with, to the point of putting up with the limitations of VR tech, mostly want to not look like regular people in that space, because they keep pushing a vision that seems to be a uniform 'normality' even more extreme than the real world)
I think they also would not accept that variability, in both avatars and spaces. Even VRChat developers have struggled with what users do and frankly as a company that makes total sense. It's a wild west which is great for a community, nightmarish for a company with moderation liabilities, copyright concerns etc.
The VRChat community should consider forming and funding an open source group to re-implement the platform as it will eventually get regulated.
For what it's worth I don't use VRChat, I've just been around the internet for long enough to know the pattern.
Yes, while VRChat does a lot of things right, the VRChat company definitely doesn't seem trustworthy in the long run. It's an aggressively walled garden where the company has full control over both content and narrative, and we're starting to see more aggressive pushes for revenue, with the major new features in recent months being subscription-gated or addiction bait (stickers, baubles, random reward boxes, etc). I'd love to see an open, federated VR social environment, but how do you get people to use it? Many VR users aren't technologically savvy at all.
There are currently two much smaller competitors that are perfectly usable but lacking community buy-in. Chillout, which is similar to VRChat, with some improvements the community has wanted for years, but missing some of VRChat's (admittedly excellent) homemade functionality, such as better IK code, better bone dynamics, etc. And Resonite, which is more similar to SecondLife, possessing a cross-world inventory system and in-game content authoring tools.
A lot of people seem to be spending huge chunks of cash on enormous monitors, dual monitors, curved monitors, etc., and the appeal of that is mostly that it gets you a little bit closer to wearing a head-mounted display.
Makes sense that a primate with front-facing eyes that is both predator and prey would prefer to look at things at arms length rather than encase their head in a cocoon that is designed to block environmental awareness.
> I think one of the reasons Vision Pro and metaverse have been struggling is because their engines are bad. Not just locked down, but hard to develop on (although I don't have personal experience, I've heard this about VR in general). If you want to build a community, you must make development easy for hobbyists and small users*. I believe this has held even for the biggest companies, case in point the examples above.
Unity and UE have pretty good VR support nowadays, and even godot is getting there. Plus making a custom engine for VR was never that much harder than for a normal 3D game (well, once some API like OpenXR got normalized).
The big issue with VR right now is that it is more costly to develop for than normal apps and games, while having less user. It makes it a hard sell. For some indie dev, I allow them to profit from a market that is not yet saturated (right now, with no good marketing, you just get buried on steam, any app store, etc).
There are many factors that make it more costly, like having to support several mobility and accessibility features for games (for example smooth and jump locomotion, reduce fov when moving the view, etc), that you usually don't have to care for in other plateform.
And there is the issue of interactivity. UX (and in many ways UI) is still very far from ideal. Most VR apps and games just try things out, but there is still a world of pattern and good practice to build up. This makes using anything VR often an annoying experience. Especially since some issue can be an absolute no-go for some user. As an example, displaying subtitle in a 6dof environment can be tricky. Some game put it at a fix point of your view, which can cause nausea and readability problem, some move still follows the head/view but with a delay, which reduce nausea issue but can be distracting and also has readability issue (the subs can go out of view).
I think there’s a difference between “indie dev” aka either an experienced SWE trying it or some really motivated person with an established identity, credit card & income stream and a kid/teenager tinkering around.
In a “free for all” setting, anyone (including kids) could potentially learn enough (or even just download pre-made scripts) and try their hand at modding software/games.
In a modern situation with developer registration, etc someone would need some sort of established identity, potentially going through age verification, paying some nominal fee for a license, accepting an EULA and so forth. This is a huge barrier to entry for kids/teenagers just wanting to tweak the game experience for themselves/their friends. I remember my first time trying to install Apache on Windows I guess around 2008-09, and the (very well-made!) install wizard asked me for a domain name. At the time I wasn’t aware of how DNS/etc worked and was scared to continue, thinking I would either take up some other company’s name or not being “allowed” to use a random name I’d pick and get myself/my parents in trouble.
All these “regulated” ecosystems make it scarier for well-meaning but inexperienced devs to get started, while doing little to deter dedicated attackers who know the game and know actual cybercrime enforcement is both lacking and trivial to defeat in any case.
The “free for all” environment made me the developer & sysadmin (or DevOps person as the techbros call it) I am today despite no formal training/education and I am sad to see this opportunity go for the younger generations.
Agree! We saw this a lot. Launching with the Quest 3, we were often the first company to do X, Y, Z despite being months after new features had been released in the SDKs because they were poorly documented (and often even conflicting).
Diverging even slightly from the demo use case would quickly feel like Sisyphus; so close, but never succeeding in getting over the hill.
Good for marketing in certain cases (to be the first), but bad for the community of builders
The lockdown is a big part of it, though. The industry has cross-platform VR/AR SDKs like OpenXR that Apple refuses to implement. A big reason their platform isn't supported day-and-date with multiplat VR releases is Apple's insistence on reinventing the wheel with every platform they make.
If the rumors of Valve's VR headset being able to run flatscreen games are true, it's more-or-less Game Over for the Vision Pro. The appetite for an iPad-like experience with six DOF is already handled by much cheaper machines.
Many creative people don’t care about being “locked in”, since they already make mods that can be broken by updates (and often are, unintentionally) and threatened legally (for violating IP and DRM). I think the much bigger problem with locked-down engines is simply that the lockdown methods used make it harder to develop on them.
All of those were also all $0–$20. It's kind of a chicken and egg problem to build a user and developer community. Games have to build a strong playerbase with limited content, then enough gamers have to be invested enough to become creators. Enough have to be able to actually pull off the development, yes, but I think the even bigger problem is that they'll never have a reason to with the small number of users inherent with platforms that cost $500–$3500 for special hardware to get onto.
I think Valve wouldn't exist as they do now except for modding. Counter-Strike's popularity must have driven a lot of purchases early on, which allowed Valve the freedom to do things at their own pace rather than under pressure from publishers.
Fortnite has been attempting to be a platform rather than a game for years now. (Epic Games Store too, so you ridiculously have to launch one then the other before you can pick your game.)
Curious to know to what degree the "Creative" maps have fueled Fortnite's success as opposed to the 1st and 2nd party developed experiences.
I would throw Rimworld into that list as well. A fine game by itself, if a bit simplistic. But the mods make the game massively customizable and lets the player do basically whatever they want
The Meta Quest is very easy to develop for. There's tons of games of all caliber from solo devs up to full studios. The reason the Metaverse is failing is because no one wants it, even though they keep shoving it down people's throats. VR gamers just want to play games, not dick around in "worlds". Meta is tone deaf to this.
There isn't yet a game that involves all the players in one huge level, without shards, but there might be eventually. Current game engines don't support levels with that many players simultaneously. There is an interview with Neal Stephenson and Tim Sweeney on the Metaverse where Sweeney says supporting massive multiplayer is what he plans for Unreal Engine 6: https://www.matthewball.co/all/sweeneystephenson
> So one of the big efforts that we're making for Unreal Engine 6 is improving the networking model, where we both have servers supporting lots of players, but also the ability to seamlessly move players between servers and to enable all the servers in a data center or in multiple data centers, to talk to each other and coordinate a simulation of the scale of millions or in the future, perhaps even a billion concurrent players. That's got to be one of the goals of the technology. Otherwise, many genres of games just can never exist because the technology isn't there to support them. And further, we've seen massively multiplayer online games that have built parts of this kind of server technology. They've done it by imposing enormous costs on every programmer who writes code for the system. As a programmer you would write your code twice, one version for doing the thing locally when the player's on your server and another for negotiating across the network when the player's on another server. Every interaction in the game devolves into this complicated networking protocol every programmer has to make work. And when they have any bugs, you see item duplication bugs and cheating and all kinds of exploits. Our aim is to build a networking model that retains the really simple Verse programming model that we have in Fortnite today using technology that was made practical in the early 2000's by Simon Marlow, Simon Peyton Jones and others called Software Transactional Memory.
I don't think they're tone deaf, they just know that inexpensive gaming headsets can't make them enough money. They've invested something like $100 billion into VR and "only" sold 20 million headsets The revenue generated annually is almost nothing.
The Luanti client lets you search and install mods from content.luanti.org
It differentiates between mods and games. A game changes the core game to be much more different, but sometimes a game is just a collection of some other mods.
Even if they made it Source Available it wouldn't hurt them much, because Minecraft is very easy to pirate and the reason anyone pays for anything at all is because you need an account in Mojang's authentication servers (which people do not want to move off of for various reasons).
Hell, they could even make it Open Source with a clause preventing other companies from using to code to make a profit. It's too big to fail.
> The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
> No Discrimination Against Fields of Endeavor
You cannot restrict selling derivatives of the software (a field of endeaver), and the derived work must be able to be shared under a similar license.
GPL does not add any restrictions counter to that. It allows you to redistribute and sell copies if you want, you just have to respect your user's freedom by also giving them the modified source code.
> But we encourage people to get creative both in Minecraft and with Minecraft – so in 2019 we tried to make this tedious process a little easier by releasing “obfuscation mappings”. These mappings were essentially a long list that allowed people to match the obfuscated terms to un-obfuscated terms. This alleviated the issue a little, as modders didn’t need to puzzle out what everything did, or what it should be called anymore. But why stop there?
Indeed, why did they even bother with this half-measure in the first place?
I wouldn't worry too much about it breaking anything with how version-specific modding already is. And by the time the full release is out, I'm sure every tool will have updated based on the new names from the snapshots.
If my memory serves, the stated justification for not going open source was copyright and trademark protection. Apparently, that is no longer a concern, if it ever really was.
Now I'm bracing for them to drop support for Java Edition entirely and go strictly Bedrock in a couple of years.
I hope Claude Code follows the same path. It's just wrong to have such a key tool in your development toolchain obfuscated. Changes to CC reflect in the way I work. I've been modding the app for ever now. Something as simple as evalling prompt changes, or finding ways to optimize context. Just make it OSS, like Codex. To add insult to injury, Claude has coined some key industry standards, such as MCP, now Skills. It also supports plugins, inviting others to release their plugins as OSS on Github [1], while their core remains proprietary.
I got my start coding by modding Minecraft - I added a quest system; one day I wanted to add dialogue trees and slowly turn it into a RPG. I hope future generations will always have this wonderful opportunity, this low barrier to entry opportunity to do substantial personal-passion mods.
I'm pretty excited this but for a slightly strange reason. I have a little monitor for the logs that posts things like player joins and deaths to a chat room. It is fun and also encourages people to hop on the server when someone joins.
However the source information was always missing and strange in the logs making matching some messages difficult. Hopefully this will make more messages more unique so that I can easily match the ones I am interested in.
They've had plenty of opportunity to do this and haven't, so would find it incredibly unlikely they would magically start to have a problem now
Not to mention doing would basically kill game as one of the biggest reason people even still play Minecraft is the modding scene, not the minimum viable effort that have been the official updates for last number of years.
I’ll preface this by saying I’m not a lawyer, but let’s say Microsoft released an obfuscated version where the method FooBar is called FakeName instead. If I use FakeName in my mod, aren’t I hypothetically at risk of the same thing? How does the actual name matter for this argument?
Or is the argument that only source code is copyrighted, but not binaries so it only matters if the name matches the original source code? That doesn’t seem possible because it’s copyright infringement to share a retail game binary, so they’re clearly copyrighted as well.
So I’m really unclear how the risk here is any different regardless of obfuscation since the mod needs to use method names from the copyrighted binary either way.
But the mod relies on the code structure as much as it relies on the names, I think it could still be considered a derivative work, I don’t think this would be copyrightable but I find the code structure being copyrightable more plausible than the names
I was initially a little confused at your comment. I had thought the decision was against Oracle being able to sue for use of the Java API.
Reading a little closer, the decision was that even assuming the API copyright claim was valid, Google's use of the API was fair use.
> In April 2021, the Supreme Court ruled in a 6–2 decision that Google's use of the Java APIs served an organizing function and fell within the four factors of fair use, bypassing the question on the copyrightability of the APIs. The decision reversed the Federal Circuit ruling and remanded the case for further review.
I would rather see allowing creators to monetize their Java edition mods again, and to get rid of their restrictive rules on mods. The old version of the EULA actually gave people a lot of freedom, but then they changed the rules on everyone and locked it down. Obfuscation is not a true problem compared to those.
You're always welcome to just ignore the EULA and hope they don't sue you. Which they won't because the costs to them are much greater than the benefits. Even with the monetized server thing, they didn't sue them, but they did create a server address blacklist, but it only contains a minority of monetized servers.
One and only account (Mojang) that I can think of that I lost because it got taken over, and I couldn’t get support to help fix it (something about “go make another Mojang account”?)… and since I don’t really get the migration process they did or final outcome, it’s more of a “oh well losing that sucks”.
This situation was a lot more common than people might think. If you bought the game before Notch introduced the EULA (late 2011 if memory serves), what they did was also probably illegal, since they didn’t have the legal boilerplate in place that would allow them to brick the game the way that they did. There was a streamer trying to start a class action over it a few years ago, but I don’t think anything ever came of it.
What they did was illegal, and you absolutely can (and are encouraged to do so by Microsoft) sue them in small claims court for your Minecraft account back.
"Encourage" may be a strong word, but it's specifically outlined in the Microsoft Services Agreement:
> 11. Choice of Law and Place to Resolve Disputes. If you live in (or, if a business, your principal place of business is in) the United States, the laws of the state where you live (or, if a business, where your principal place of business is located) govern all claims, regardless of conflict of laws principles, except that the Federal Arbitration Act governs all provisions relating to arbitration. You and we irrevocably consent to the exclusive jurisdiction and venue of the state or federal courts in King County, Washington, for all disputes arising out of or relating to these Terms or the Services that are not heard in arbitration or small claims court.
Minecraft modding has done so much to get young people into CS. I started learning Java when I was 10 because I wanted to do modding. At university, I met so many people who had the same experience.
The tooling developed for Minecraft modding is world-class and better than what is developed during PhDs. It's very advanced, and people internalized the JVM and Java spec. One problem, though, is that Mojang's updates often change much of the foundation, and upgrading mods is very time-intensive. Mojang announced in 2012 that an official modding API is in the works. This is another step.
As I understand it way back in the early Beta days of Minecraft obfuscation was added to avoid mods being embedded into the JAR and it being released as a combination enabling piracy of the game with mods embedded.
This has been a pain to workaround for years as the modding scene has gotten bigger. Hopefully this makes modding a bit more accessible.
Yeah I still remember when you had to manually patch your minecraft.jar with mods. Always remove the META-INF directory so it works. Back then, when you installed two mods that were incompatible with each other, you had to throw away the whole minecraft.jar and start again.
This already changed A LOT when Forge and later Fabric came out, with a simple patch system akin to BepinEx and a mods folder.
The later generation mod loader use preloader and asm hooks though. So the file isn't even physically patched, just patched in memory. That is such an old day that you still need to patch the jar by yourself. (If I am not remembered it incorrectly, I think the community change happens between 1.3 and 1.5?)
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.
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...
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.
I don't really think this would be the end of the world, would it? Much of the content they've added over the past few years has been of questionable merit, at least to me. Surely at some point they'll run out of ideas that can reasonably fit inside vanilla Minecraft?
(But no, I don't think they're going to stop JE development. I'd bet it's still the far more popular version, and they probably still make plenty of money from sales)
I have to assume this runs the risk of opening the floodgates for potential vulnerabilities to be discovered now. Hopefully they're prepared to start working on a bunch of new bug reports.
Whether is obfuscated or not. Minecraft java runs most logic in java, and write the save and network handling in parse & validate style instead of serialization/deserialization style. So there isn't much "vulnerabilities" for you though. The game probably isn't best in performance, but there aren't much vulnerabilities either.
Closed-source code isn't that much less secure than open one that I think this is a legitimate worry, especially in this case where the obfuscation doesn't sound like it was effective much
Luckily I have never had to deal with obfuscation, but from what I have seen there are some grotesque things like defining every single randomly named method call in an array or map with random order or weirdly combining or tearing apart methods.
The only time I encountered it was when I was working for the government, we were working on the rules that decide who gets audited in depth by the tax police. The .jar it compiled to was obfuscated.
My decade-old recollection is also that Minecraft's obfuscation didn't do anything structural, just mangled class and method names. Think of it more like JavaScript minification than a serious attempt to thwart reverse engineering.
Minecraft - like most Java games - just used Proguard. It renames classes/fields/methods and sometimes inlines private methods, but doesn't make any substantial changes to control flow.
I have seen =tons= of obfuscation (non-minecraft). Back in the late 90s it used to be popular, unfortunately.
Most of the stuff is like naming every method a or b, and using the fact they are overloaded, given one-letter-name or a reserved keyword like 'if' to classnames (or packages) was popular, too. Pretty much constant pool modifications w/o too much byte-code-editing.
Overall cheap and unnecessary and has not stopped anyone.
It's still pretty popular. Most large smartphone applications are obfuscated to some degree. At least for Android, because it's bytecode for a VM, it's still trivial to disassemble and understand what is happening at a high level.
AFAIK it also shortens the names, which might make the jar smaller or make it take less time to do name resolution at runtime. It probably won't be very relevant though, especially after startup.
The files will be a little smaller obscured but it doesn't usually impact much other than RAM usage. The algorithms are all the same. Given the size of methods for being JIT compiled is token based not text size I don't think it even impacts that choice. So expect it to be identical.
same, except for meta space used - the class/variable names don't have pretty much any meaningful impact on java runtime, when the code is JIT'd. Even before (interpret mode) that the className/fields/methods are just references in the constant pool
I wonder what Minecraft sales are like these days. I'd imagine most of the people who are going to buy it already have. Makes me wonder if they'll ever open the whole thing up.
Just think of the untapped market of fresh 9 year olds who've never seen/played the game before. It's infinite, there will always be more people who have never played Minecraft.
Where are you getting that from? Minecraft has been comfortably above 100,000,000 monthly active users since at least 2019. The only comparable figure I can find for Fortnite claims 650,000,000 registered users, which doesn’t seem remotely possible unless at least half of them are bots. 650,000,000 is something like 1/12th of the world’s entire population. The Roblox figures I could find showed just under 400,000,000 MAU in 2024, which also seems completely beyond the pale.
So anyone who reports higher numbers than Minecraft is lying, but Minecraft's numbers are all accurate? You have literally just invented a conspiracy theory to affirm your biases around this matter.
Also note that monthly active users for Roblox and Fortnite equate to monthly revenue, whereas I doubt there are as many people buying Minecraft in-app purchases.
This does claim that 238,000,000 copies have been sold but that there are 400,000,000 registered Minecraft players in China (this would be about 1/3rd of the population so I think it’s probably a typo).
Epic is privately held so I suspect they wouldn’t bother reporting official player counts. Roblox actually does have numbers listed in their annual report, it just wasn’t showing up when I Googled it: 3.6 billion in revenue and 82.9 million daily active users. So that would put it within the wheelhouse of Minecraft’s playerbase, but still about 20,000,000 short.
It may well be that all the kids are playing it over Minecraft, though, since the document I linked above claims the average Minecraft player in North America and Europe is 27. I have no idea what those numbers look like for Roblox but from what I understand the playerbase has always skewed substantially towards minors.
> You have literally just invented a conspiracy theory to affirm your biases around this matter.
You can't compare daily and monthly active users. Monthly active users are can be many times higher than daily. Also, the numbers you are using for Roblox are two years out of date. Current DAU for Roblux is 150M [1].
> This was incredibly abrasive.
I reserve the right to be abrasive when people randomly decide to spread baseless claims.
Asking from a place of sincere ignorance: TFA says the code was obfuscated from the beginning, and that they deliberately kept it obfuscated all these years, and acknowleded the huge community that built mods for Minecraft in spite of it. But what TFA doesn't say:
Why did they keep it obfuscated for so long even after it became readily apparent that almost everyone buys Minecraft to (eventually) play the mods?
Why did they keep it obfuscated even though they acknowledged it didn't really stop modders (or anyone else) from understanding the program?
What occurred recently that caused them to change their mind?
"It does have some technical benefits for us, but it is a symbol that this game is not open source. You still can't publish the maps or the code decompiled, even using the maps."
The obfuscation in question was just name mangling, so it was probably ~zero-cost. Possibly slightly negative cost, depending on the relative verbosity of method names.
On the one hand, great; should hopefully mean the monkey-patching by mods isn't quite as fragile as it is once you get into a decent number of installed mods.
On the other, I'd assume this means that any official modding support is now stone dead and will never happen.
I haven't played minecraft in a fair while, but started with the alpha builds back when the Seecret updates were the most exciting thing going for the game.
> I'd assume this means that any official modding support is now stone dead and will never happen.
I was a bit surprised to read this because talk of modding support had been on the radar since notch days, it's wild to me that this hasn't happened yet.
I suspect Minecraft was large enough to support an effective modding community from the start regardless of official support, so that there was always some kind of third-party unofficial mechanism (ModLoader, then Forge, then now Fabric and Quilt). Mojang probably punted it down the priority list because of that, or didn't want to impose a structure and kill those ecosystems. Technically speaking, Java is reasonably easy to plug stuff into at runtime, so that was never a barrier.
The original issue with official modding support, from my perspective, has always been a legal one. But the Mojang EULA explicitly allows modding now. So I would see this decision as one in a long line of decisions by Mojang to both normalise the legal relationship with modders, and beyond that giving a "thumbs up" to the community.
It's been dead already. There's datapacks but it's been pretty obvious they're not going to make an official modding API. I think they realised that the community modloaders are already really good.
So instead they have been structuring the code in ways that help mod development, and have been talking directly to the devs of mods and mod loaders to try and reduce friction with Minecraft updates.
Proguard obfuscation, particularly when you get to aggressive renaming (there are a lot of valid characters for a java class or method), flattening, overloading and inlining, can make it very hard to understand what is actually happening.
One of my favorite mods ever across any game is Create for Minecraft. It is well-made and polished, and sparked a whole ecosystem of mods that work with it. I wonder what possibilities the de-obfuscation can bring to that ecosystem.
Maybe they should open source the loader instead of offering a solution to already solved problems so people don't have to resort to using third party loaders for on-prem gaming.
The game is still a licensed game though. You technically must pay it and go though proper verification to start the game. (Although it's a 100% public secret that how to load it as you want, and basically every single mod dev kit does that for local dev)
I guess Microsoft won't want to deal with the license issue of publishing the loader part.
Main difference for NeoForge developers will be method parameter names in the IDE, the current mapping doesn't include those. We have community mappings (Parchment) for common methods, but there are a lot of less used functions that just have decompiler names. I don't use Fabric so I'm not sure how it will affect those devs.
It's possible that the de-obfuscated symbols will be more backwards-compatible, since they don't need to change with every minor release. Though I'd imagined Forge and Fabric were supposed to provide a stable platform, yet plugins for those still need a different jar for every minor version.
In reality, Minecraft gets less Minecrafty in every update, and your baseline is whenever you bought it.
I bought the game after they added fences and fishing rods and before the Nether. The nether ruined the game, beds ruined the game, hunger ruined the game, potions, enchantments, villager trading, and hoppers ruined the game, but redstone and minecarts and dungeons didn't ruin the game because those were added before I bought it, see? If you bought it today, you wouldn't think hunger ruined the game, you'd rather think I took away a good feature if I showed you a version without hunger.
I'm not opposed to changes, but every official change Minecraft makes, narrows the design space for mods. Forestry added bees, then Mojang added its own bees which where quite different, and now Forestry's bees look more than a little odd. Sheep used to not drop meat, the witchery mod added mutton as a drop if you killed a sheep in werewolf form, and some mechanics around that. They now would look a little odd. Chocolatey added a ton of structures, among them pigmen cities, now pigmen have been rebranded as piglins and also have their bastions, which are quite different from Choco's cities. Are they better, worse? Who knows? To me what matters more is that they probably wouldn't have been made today. Mojang canonized one thing in that space.
But a lot of things Mojang has added, if they had been mods some random developer made, we probably wouldn't have been putting in our modpacks. A new tier of armor, which requires a tedious grind in the nether to get? That's like baby's first mod. Happy ghasts? Pretty fun, and impressive that you can stand on them, but like the morph mod, kinda ridiculous and definitively doesn't belong in every pack. Eventually, if they keep doing it like this, Minecraft will be as ridiculous as the old kitchen sink modpacks.
This is also true, and also why I want it to be a relatively unopinionated base engine. Unfortunately technical advancements came alongside opinionated content. 1.8 brought creative mode and fast/tintable skylight updates - and hunger and very griefy endermen and a bucnh of worldgen structures. 1.0 brought itemstack NBT - to support enchantments and potions - and gave a sandbox game an official end. 1.3 brought client/server unification allowing singleplayer commands, open to LAN, greater mod compatibility, latency in singleplayer (maybe not actually good) - and villagers and villager trading and emeralds. 1.4 brought command blocks - and local difficulty and armoured mobs and withers. 1.5 brought analog redstone - and hoppers. I think 1.7 was only upsides though - texture atlasing and a new less-broken terrain pattern. That's where I stopped.
And for what it's worth, I think I've visited The End once? What makes it a sandbox is that you can play however you want - let The End be your goal, if you'd like, or just mine and build big castles, or mess around in Creative mode. That's the brilliance of it.
When you're engaging in game design, you usually want to make a coherent sandbox. If the best way to produce electricity in your electricity mod is to enslave an army of witches to throw healing potions at each other, it's probably not your design intention. You probably wanted it to involve digging for coal, or solar panels.
In current Minecraft a lot of resources are renewable via villager trading. The best way to get many resources is to enslave some villagers and find a trading loop that nets a profit in emeralds on each cycle, then spend some of that profit on the thing you want. If you want the player to dig up coal to make electricity, they can make a trading hall or a wither skeleton farm instead. If you want the player to dig up iron to expand their factory they'll make an iron golem farm which produces it at a high rate for free. The section of the design space that you wanted to access is blocked off by the mechanics of the base game.
One reason is that all the other mods you wanted to use were redesigned to match the vanilla mechanics, so even if you use another mod to disable the vanilla mechanics, you're still suffering their consequences. They may even be redesigned in ways that require the vanilla mechanics.
You can't just remove the fields for a mob's armour items because all the mods that interact with mobs are checking what armour they have, and you'll get a runtime linking error. Best you can do is remove the code that spawns mobs with random armour so they always spawn without armour. There may still be armoured mobs spawned by mods.
In automation mods there was a concept called "sided inventory" where a machine block presents a different part of its inventory depending on which side of the block you access it from. When hoppers were added to the base game, they copied this exactly, but changed which sides accessed which part of which blocks to make them compatible with hoppers, because hoppers can only take items out of the bottom and put items into the top and sides. This affected all automation mods which, instead of using a more intuitive side mapping, use a mapping that makes sense for hoppers. Also, all other mods that add machine blocks now specify side mappings that make sense for hoppers.
Of course in principle you can rewrite the game and all your mods from scratch to match whatever vision you have, but I hope it's obvious that nobody would actually do that.
Even removing a single block or item is nontrivial. You can't remove the field because you'll get runtime linking errors from mods. You can't make it null. Even mods that don't rely on that item may be checking if a player is using it for some feature (and you'd like that check to always be false). There's a good chance many of the mods you want use it in recipes because it's available. Best you can do is remove the ways to obtain/create the item, and add a bunch of recipe overrides so it's not used in recipes either. If you have the mod that shows you a list of every item in the game, it'll still show up there.
After 15 years of playing, it still feels very much like a wonderful sandbox, which I regularly modify however I want, with very rarely any issues, including some of the exact things you've mentioned.
And thankfully, the modding scene is as vibrant as ever!
Yeah, 1.7.10 is many modders' favorite, I know. If you did stop at 1.7.10, I guess you know about the GTNH people's crazy work in keeping that version running? For a while, you could 1.7.10 with a newer version of Java than the current latest version.
I bought it like, 15 years ago, and have enjoyed most updates, though certainly not all. I would not say anything "ruined" the game; I was just making a joke about which versions mod developers support
We paid for minecraft java edition and have no desire to use the online features.
Microsoft logs us out every damn time we close the software, which means my grade schoolers have my (now guessable) MS account password (and I scorch-earthed the account, because this is so dumb I won’t trust or use their crap moving forward).
Has anyone figured out how to pirate the binaries? I’d like to remove the yellow sticky note with the password from my monitor.
Use an alternate launcher, like MultiMC, and if you're not using the online features anyway, you can just "Launch in Offline Mode", which will just be unable to authenticate with legitimate servers.
You'd still need to log in to update the game (I think), but for your purposes it'd probably work pretty well.
This is surprising. Perhaps the Minecraft devs and community are dedicated and capable enough to prevent it from being enshittified by Microsoft. It might even be open-sourced someday.
"Minecraft: Java Edition" has been obfuscated since the release. < Classic Microsoft move.
No, It was obfuscated since around 1.8 when you (Microsoft) buy up Mojang Studios. before that? meh, It wasn't. That's the main reason why JE has broader mod ecosystem from the start., result being 1.7.2 being the one of the most active modded versions since most of them can't get passed to around 1.8.
The motive behind this is probably due to them finding out people can not get their mods/server software updated in-time (due to extra work required) and this leading people being really reluctant to update their versions.
I learned to code by modding Minecraft, starting at ~1.6 a few years before the Microsoft acquisition.
It was definitely already obfuscated by then, the Microsoft acquisition had nothing to do with it.
If anything, looking back all the years, Microsoft has largely delivered on the promise to not fuck up the game and its community. They’ve mostly kept their hands off it, besides the Microsoft account stuff (which makes sense why they did it, but a lot of people are still understandably annoyed). Hell, they’ve kept up two separate codebases in fairly close feature parity for _years_. I doubt they’d have kept JE if there weren’t people in that team who genuinely cared.
> No, It was obfuscated since around 1.8 when you (Microsoft) buy up Mojang Studios. before that? meh, It wasn't.
Huh? This is not true. The very first version released in 2009 was obfuscated with ProGuard, the same obfuscator used today.
The reason Minecraft 1.7 was a popular version for modding was because Forge was taking too long to come out, and the block model system was changed in a fundamental way in the next update. Has nothing to do with obfuscation.
> The motive behind this is probably due to them finding out people can not get their mods/server software updated in-time (due to extra work required) and this leading people being really reluctant to update their versions.
Not really accurate. The Minecraft modding and custom server software ecosystem has more agility right now than it ever had in the past. In the past 5 years, a remarkable shift has occurred: people have actually started updating their game & targeting the latest version. Minecraft 1.21 has the highest number of mods in the history of the game.
It's extraordinary to me that Minecraft is both the game that has the most robust mod community out there and that the modders were working from obfuscated, decompiled Java binaries. With elaborate tooling to deobfuscate and then reobfuscate using the same mangled names. For over a decade! What dedication.
More proof that you don't need the source code to modify software. Then again, Java has always been easy to decompile, and IMHO the biggest obstacle to understanding is the "object-oriented obfuscation" that's inherent in large codebases even when you have the original source.
First time I have heard of object-oriented obfuscation.
I get it, but in general I don't get the OO hate.
It's all about the problem domain imo. I can't imagine building something like a graphics framework without some subtyping.
Unfortunately, people often use crap examples for OO. The worst is probably employee, where employee and contractor are subtypes of worker, or some other chicanery like that.
Of course in the real world a person can be both employee and contractor at the same time, can flit between those roles and many others, can temporarily park a role (e.g sabbatical) and many other permutations, all while maintaining history and even allowing for corrections of said history.
It would be hard to find any domain less suited to OO that HR records. I think these terrible examples are a primary reason for some people believing that OO is useless or worse than useless.
For me, it's the fact that the mess of DAOs and Factories that constituted "enterprise" Java in the 00s was a special kind of hellscape that was actively encouraged by the design of the language.
Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code.
It was terrible and taught me to avoid applying for jobs that used Java.
I like OOP and often use it. But mostly just as an encapsulation of functionality, and I never use interfaces or the like.
As someone coding since 1986 it is always kind of interesting how Java gets the hate for something that it never started, and was already common in the industry even before Oak became an idea.
To the point that there are people that will assert the GoF book, published before Java was invented, actually contains Java in it.
People did it, some times, when they needed it.
It was so rare that the GoF though they needed to write a book to teach people how to use those patterns when they eventually find them.
But after the book was published, those patterns became "advanced programming that is worth testing for in job interviews", and people started to code for their CVs. The same happened briefly with refactoring, and for much longer with unit tests and the other XP activities (like TDD).
At the same time, Java's popularity was exploding on enterprise software.
It was, but still the book did not magically changed from Smalltalk and C++ into Java.
It is probably because Java took this design philosophy (or I should say dogma) to heart as its very syntax and structure encourages to write code like that. One example: It does not have proper modules. Modules, the one thing that most people can agree upon that are a good thing, enabling modularity, literally. Another one: You cannot have simply a function in a module. Shit needs to be inside classes or mixed up with other unrelated concepts. Java the language encourages this kind of madness.
It is called packages. There is nothing on the modules as programming concept that requires the existence of functions as entity.
Again, Smalltalk did it first, and is actually one of the languages on the famous GoF book, used to create all the OOP patterns people complain about, the other being C++.
> There is nothing on the modules as programming concept that requires the existence of functions as entity.
I didn't claim it does. To make the point though: bare functions are a much simpler building block, and a much cleaner building block than classes. Classes by their nature put state and behavior in one place. If one doesn't need that, then a class is actually not the right concept to go for (assuming one has the choice, which one doesn't in Java). A few constants and a bunch of functions would be a simpler and fully sufficient concept in that case. And how does one group those? Well, a module.
In Java you are basically forced to make unnecessary classes, that only have static functions as members, to achieve a similar simplicity, but then you still got that ugly class thing thrown in unnecessarily.
In a few other languages maybe things are based on different things than functions. Like words in Forth or something. But even they can be interpreted to be functions, with a few implicit arguments. And you can just write them down. No need to put them into some class or some blabliblub concept.
From type systems theory point of view, a class is an extensible module that can be used as a variable.
As mentioned in another reply, Java did not invent this, it was building upon Smalltalk and SELF, with a little bit of Objective-C on the side, and C++ like syntax.
Try to create a single function in Smalltalk, or SELF.
http://stephane.ducasse.free.fr/FreeBooks.html
https://www.strongtalk.org/
https://selflanguage.org/
It is also no accident that when Java came into the scene, some big Smalltalk names like IBM, one day of the other easily migrated their Smalltalk tooling into Java, and to this day Eclipse still has the same object browser as any Smalltalk environment.
Smalltalk,
https://www.researchgate.net/figure/The-Smalltalk-browser-sh...
Which you will find a certain similarity including with NeXTSTEP navigation tools, and eventually OS X Finder,
The code browser in Eclipse
https://i.sstatic.net/4OFEM.png
By the way, in OOP languages like Python, even functions are objects,
> The code browser in Eclipse
> https://i.sstatic.net/4OFEM.png
«
Error 1011 Ray ID: 9973d6cc1badc66a • 2025-10-31 14:28:28 UTC
Access denied
What happened?
The owner of this website (i.sstatic.net) does not allow hotlinking to that resource (/4OFEM.png).
»
In java, it has to be a class in a package. Packages are sane enough. That isnt the point.
That is the point, packages the Java programming language feature for the CS concept of modules.
https://en.wikipedia.org/wiki/Modular_programming
> Languages that formally support the module concept include Ada, ALGOL, BlitzMax, C++, C#, Clojure, COBOL, Common Lisp, D, Dart, eC, Erlang, Elixir, Elm, F, F#, Fortran, Go, Haskell, IBM/360 Assembler, IBM System/38 and AS/400 Control Language (CL), IBM RPG, Java, Julia, MATLAB, ML, Modula, Modula-2, Modula-3, Morpho, NEWP, Oberon, Oberon-2, Objective-C, OCaml, several Pascal derivatives (Component Pascal, Object Pascal, Turbo Pascal, UCSD Pascal), Perl, PHP, PL/I, PureBasic, Python, R, Ruby,[4] Rust, JavaScript,[5] Visual Basic (.NET) and WebDNA.
If the whole complaint is that you cannot have a bare bones function outside of a class, Java is not alone.
Predating Java by several decades, Smalltalk, StrongTalk, SELF, Eiffel, Sather, BETA.
And naturally lets not forget C#, that came after Java.
Thankfully those days are not with us any more. Java has moved on quite considerably in the last few years.
I think people are still too ready to use massive, hulking frameworks for every little thing, of course, but the worst of the 'enterprise' stuff seems to have been banished.
I hope you are right. I really do. But I have a hunch, that if I accepted any Java job, I would simply have coworkers, who are still stuck with "enterprise" Java ideology, and whose word has more weight than the word of a newcomer. That's one of the fears, that stops me from seriously considering Java shops. Fear of unreasonable coworkers and then being forced to deliver shitty work, that meets their idea of how the code should be written in the most enterprise way they can come up with.
Always makes me think of that AbstractProxyFactorySomething or similar, that I saw in Keycloak, for when you want to implement your own password quality criteria. When you step back a bit and think about what you actually want to have, you realize, that actually all you want is a function, that takes as input a string, and gives as output a boolean, depending on whether the password is strong enough, or fulfills all criteria. Maybe you want to output a list of unmet criteria, if you want to make it complex. But no, it's AbstractProxyFactorySomething.
I don't understand these complaints.
Here is a tiny interface that will do what you need:
Now you can trivially declare a lambda that implements the interface.Example:
I'm personally rather fond of Java, but even this (or the shorter `Predicate`) still can't compete with the straightforward simplicity of a type along the lines of `string -> bool`.
It insists upon itself. That’s really the problem with Java’s design philosophy from that era; it encourages ceremony. Even if you don’t write the full-on "Enterprise™" soup of DAOs, Factories, and ServiceLocators, the language’s type system and conventions gently nudge you toward abstraction layers you don’t actually need.
Interfaces for everything, abstract classes “just in case,” dependency injection frameworks that exist mainly to manage all the interfaces. Java (and often Enterprise C#) is all scaffolding built to appease the compiler and the ideology of “extensibility” before there’s any actual complexity to extend.
You can write clean, functional, concise Java today, especially with records, pattern matching, and lambdas, but the culture around the language was forged in a time when verbosity was king.
It's very useful in C++, funnily enough. This is because I can have a non-templated interface base class, then a templated impl class.
Then my templated impl header can be very heavy without killing my build times since only the interface base class is #included.
Not sure if this is as common in Java.
Using more complex architecture (which requires more human time to understand) to merely make build time shorter is a ridiculous choice.
For a large project this could save hours of developer time.
C++ is a hell of a language.
just buy your devs faster computers to compile on
You can't buy your way out of this, because C++ builds are only parallelizable across multiple translation units[1] (i.e. separate .cpp files). Unless you're willing to build a better single-core CPU, there's not much you can do.
The challenge with modern C++ projects is that every individual TU can take forever to build because it involves parsing massive header files. Oftentimes you can make this faster with "unity builds" that combine multiple C++ files into a single TU since the individual .cpp file's build time is negligible compared to your chonky headers.
The reason the header files are so massive is because using a templated entity (function or class) requires seeing the ENTIRE DEFINITION at the point of use, because otherwise the compiler doesn't know if the substitution will be successful. You can't forward declare a templated entity like you would with normal code.[2]
If you want to avoid including these definitions, you create an abstract interface and inherit from that in your templated implementations, then pass the abstract interface around.
[1] or linking with mold
[2] There used to be a feature that allowed forward declaring templated entities called "export". A single compiler tried to implement it and it was such a failure it was removed from the language. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n14...
Java uses type erasure which are very cheap in compile time but you cannot do things like
C++ uses reified generics which are heavy on compile time but allows the above.That's why they're called generic parameters, not template parameters; the code is generic over all possible parameters, not templated for every possible parameter.
Interesting I’d never picked up on this pedantic subtlety. I too thought reified meant what you could do at the call site not what you could do at runtime. Was my understanding wrong, or is Gemini hallucinating.
In any event, you have to use weird (I think “unsafe”) reflection tricks to get the type info back at runtime in Java. To the point where it makes you think it’s not supported by the language design but rather a clever accident that someone figured out how to abuse.
I think the best description of this kind of "obfuscation" that especially afflicted Java still is Steve Yegge's "Kingdom of Nouns" rant:
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
Funny, given that interfaces are the good part (especially compared to inheritance).
I didn't mean to imply that interfaces are bad or useless. Just that I don't use them. Probably because I write most of my stuff in Python anymore.
"But but... I can swap out my entire my persistance layer since it's all just an interface!"
Has anyone ever actually done this ?
I have used something similar with effects in Haskell to mock "the real world" for running tests.
But if it was as convoluted to use as it's in Java, I wouldn't. And also, it's not enterprise CRUD. Enterprise CRUD resists complex architectures like nothing else.
> Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code.
Perhaps I'm not following, but dynamically loaded objects are the core feature of shared libraries. Among it's purposes, it allows code to be reused and even updated without having to recompile the project. That's pretty useful.
Interfaces are also very important. They allow your components to be testable and mockable. You cannot have quality software without these basic testing techniques. Also, interfaces are extremely important to allow your components to be easily replaced even at runtime.
Perhaps you haven't had the opportunity to experience the advantages of using these techniques, or were you mindful of when you benefited from them. We tend to remember the bad parts and assume the good parts are a given. But personal tastes don't refute the value and usefulness of features you never learned to appreciate.
> > Most code bases don't need dynamically loaded objects designed with interfaces that can be swapped out. In fact, that functionality is nearly never useful. But that's how most people wrote Java code.
> Perhaps I'm not following, but dynamically loaded objects are the core feature of shared libraries. Among it's purposes, it allows code to be reused and even updated without having to recompile the project. That's pretty useful.
> Interfaces are also very important. They allow your components to be testable and mockable. You cannot have quality software without these basic testing techniques. Also, interfaces are extremely important to allow your components to be easily replaced even at runtime.
I don't think GP was saying that Dynamically loaded objects are not needed, or that Interfaces are not needed.
I read it more as "Dynamically loaded interfaces that can be swapped out are not needed".
> Also, interfaces are extremely important to allow your components to be easily replaced even at runtime.
The share of all software that actually benefits from this is extremely small. Most web-style software with stateless request/response is better architected for containers and rolling deployments. Most businesses are also completely fine with a few minutes of downtime here and there. For runtime-replacement to be valuable, you need both statefulness and high SLA (99.999+%) requirements.
To be fair, there is indeed a subset of software that is both stateful and with high SLA requirements, where these techniques are useful, so it's good to know about them for those rare cases. There is some pretty compelling software underneath those Java EE servers for the few use-cases that really need them.
But those use-cases are rare.
>You cannot have quality software without these basic testing techniques
Of course you can, wtf?
Mock are often the reason of tests being green and app not working :)
> Of course you can, wtf?
Explain then what is your alternative to unit and integration tests.
> Mock are often the reason of tests being green and app not working :)
I don't think that's a valid assumption. Tests just verify the system under test, and test doubles are there only to provide inputs in a way that isolates your system under test. If your tests either leave out invariants that are behind bugs and regressions or have invalid/insufficient inputs, the problem lies in how you created tests, not in the concept of a mock.
Workman and it's tools.
I personally believe mocks are a bad practice which is caused by bad architecture. When different components are intertwined, and you cannot test them in isolation, the good solution is refactoring the code; the bad is using mocks.
For example of such intertwined architecture see Mutter, a window manager of Gnome Shell (a program that manages windows on Linux desktop). A code that handles key presses (accessibility features, shortcuts), needs objects like MetaDisplay or MetaSeat and cannot be tested in isolation; you figuratively need a half of wayland for it to work.
The good tests use black box principle; i.e. they only use public APIs and do not rely on knowledge of inner working of a component. When the component changes, tests do not break. Tests with mocks rely on knowing how component work, which functions it calls; the tests with mocks become brittle, break often and require lot of effort to update when the code changes.
Avoid mocks as much as you can.
It's not necessary to have mocks for unit tests. They can be a useful tool, but they aren't required.
I am fine with having fake implementations and so forth, but the whole "when function X is called with Y arguments, return Z" thing is bad. It leads to very tight coupling of the test code with the implementation, and often means the tests are only testing against the engineer's understanding of what's happening - which is the same thing they coded against in the first place. I've seen GP's example of tests being green but the code not working correctly a number of times because of that.
Most compilers do not use "unit" tests per se. Much more common are integration tests targeted at a particular lowering phase or optimization pass.
This is pretty important since "unit tests" would be far too constraining for reasonable modifications to the compiler, e.g. adding a new pass could change the actual output code without modifying the semantics.
LLVM has "unit" tests
I mean they run single pass with some small llvm ir input and check if the output IR is fine
>Explain then what is your alternative to unit and integration tests.
Tests against real components instead of mocks.
>If your tests either leave out invariants that are behind bugs and regressions or have invalid/insufficient inputs, the problem lies in how you created tests, not in the concept of a mock.
Nowadays external components can be very complex systems e.g dbs, messaging queues, 3rd APIs and so on
A lot of things can go wrong and you arent even aware of them in order to get mocks right.
Examples? fuckin emojis.
On mocked in memory database they work fine, but fail on real db due to encoding settings.
I'm not a fan of extensive mocking but you're conflating two rather different test cases. A test where you mock out the database connection is testing something in application code, which has nothing to do with database configuration. You should of course have tests towards the database too, but then you'd mock out parts of the application instead and not the database itself.
>A test where you mock out the database connection is testing something in application code, which has nothing to do with database configuration.
Wdym?
You're testing e.g simple crude operation, e.g create hn thread
With mocked db it passed, with real db it fails due to encoding issue.
The result is that tests are green, but app does not work.
We're talking about OO Java. You bring up shared libraries, list a bunch of things not unique to Java nor OO, then claim `etc.` benefits.
You really haven't argued anything, so ending on a "you must be personally blind jab" just looks dumb.
It's because the concepts are the same, but people get enraged by the words. What Java calls a factory would be a "plugin loader" in C++. It's the same concept. And most big C++ codebases end up inventing something similar. Windows heavily uses COM which is full of interfaces and factories, but it isn't anything to do with Java.
Java I think gets attacked this way because a lot of developers, especially in the early 2000s, were entering the industry only familiar with scripting languages they'd used for personal hobby projects, and then Java was the first time they encountered languages and projects that involved hundreds of developers. Scripting codebases didn't define interfaces or types for anything even though that limits your project scalability, unit testing was often kinda just missing or very superficial, and there was an ambient assumption that all dependencies are open source and last forever whilst the apps themselves are throwaway.
The Java ecosystem quickly evolved into the enterprise server space and came to make very different assumptions, like:
• Projects last a long time, may churn through thousands of developers over their lifetimes and are used in big mission critical use cases.
• Therefore it's better to impose some rules up front and benefit from the discipline later.
• Dependencies are rare things that create supplier risks, you purchase them at least some of the time, they exist in a competitive market, and they can be transient, e.g. your MQ vendor may go under or be outcompeted by a better one. In turn that means standardized interfaces are useful.
So the Java community focused on standardizing interfaces to big chunky dependencies like relational databases, message queuing engines, app servers and ORMs, whereas the scripting language communities just said YOLO and anyway why would you ever want more than MySQL?
Very different sets of assumptions lead to different styles of coding. And yes it means Java can seem more abstract. You don't send queries to a PostgreSQL or MySQL object, you send it to an abstract Connection which represents standardized functionality, then if you want to use DB specific features you can unwrap it to a vendor specific interface. It makes things easier to port.
I am currently being radicalised against OOP because of one specific senior in my team that uses it relentlessly, no matter the problem domain. I recognise there are problems where OOP is a good abstraction, but there are so many places where it isn't.
I suspect many OOP haters have experienced what I'm currently experiencing, stateful objects for handing calculations that should be stateless, a confusing bag of methods that are sometimes hidden behind getters so you can't even easily tell where the computation is happening, etc
You could write crappy code in any language. I don't think it's specific for Java. Overall I think java is pretty good, especially for big code bases.
But there's a real difference how easy it is to write crappy code in a language. In regards to java that'd be, for example, nullability, or mutability. Kotlin, in comparison, makes those explicit and eliminates some pain points. You'd have to go out of your way and make your code actively worse for it to be on the same level as the same java code.
And then there's a reason they're teaching the "functional core, imperative shell" pattern.
On the other hand, Java's tooling for correctly refactoring at scale is pretty impressive: using IntelliJ, it's pretty tractable to unwind quite a few messes using automatic tools in a way that's hard to match in many languages that are often considered better.
I agree with your point, and I want to second C# and JetBrains Rider here. Whatever refactoring you can with Java in JetBrains IntelliJ, you can do the same with C#/Rider. I have worked on multiple code bases in my career that were 100sK lines of Java and/or C#. Having a great IDE experience was simply a miracle.
The language Kotlin is actually developed by JetBrains
I've found that IntelliJ's refactorings don't work as well for Kotlin as Java but, also, I've avoided Kotlin because I don't like it very much.
You gotta admit, though, that a language which strongarms you into writing classes with hidden state and then extending and composing them endlessly is kinda pushing you in that direction.
It’s certainly possible to write good code in Java but it does still lend itself to abuse by the kind of person that treated Design Patterns as a Bible.
>kind of person that treated Design Patterns as a Bible
I have a vague idea of what the Bible says, but I have my favorite parts that I sometimes get loud about. Specifically, please think really hard before making a Singleton, and then don't do it.
Singletons are so useful in single threaded node land. Configuration objects, DB connection objects that have connection pooling behind them, even my LLM connection is accessed via a Singleton.
OK yeah that's a pretty good general principle. You think you only need one of these? Are you absolutely certain? You SURE? Wrong, you now need two. Or three.
A singleton is more than just, "I only need one of these," it is more of a pattern of "I need there to be only one of these," which is subtly different and much more annoying.
Separation of data and algorithm is so useful. I can't really comment on how your senior is doing it, but in the area of numeric calculations, making numbers know anything about their calcs is a Bad Idea. Even associations with their units or other metadata should be loose. Functional programming provides such a useful intellectual toolkit even if you program in Java.
Sorry to learn, hope you don't get scar tissue from it.
Not sure how many people are writing programs with lots of numeric calculations.
Most programs in my experience are about manipulating records: retrieve something from a database, manipulate it a bit (change values), update it back.
Over here OOP do a good job - you create the data structures that you need to manipulate, but create the exact interface to effect the changes in a way that respect the domain rules.
I do get that this isn't every domain out there and _no size fits all_, but I don't get the OP complaints.
I currently think that most of the anger about OOP is either related to bad practices (overusing) or to lack of knowledge from newcomers. OOP is a tool like any other and can be used wrong.
Creating good reusable abstractions is not easy. It's quite possible to create tarballs of unusuable or overwrought abstractions. That is less of a knock on OOP and more a knock on the developers.
But that is what classes does, it lets you have data lists and dictionaries implemented as a class so that your algorithm doesn't have to understand how the data structure is implemented. In functional programming the algorithm has to be aware of the data structure, I feel that is much worse.
> I recognise there are problems where OOP is a good abstraction, but there are so many places where it isn't.
Exactly. This is the way to think about it, imo. One of those places is GUI frameworks, I think, and there I am fine doing OOP, because I don't have a better idea how to get things done, and most GUI frameworks/toolkits/whatever are designed in an OOP way anyway. Other places I just try to go functional.
I agree. Neither OOP nor functional programming should be treated as a religion or as a paradigm that one must either be fully invested in or not.
OOP is a collection of ideas about how to write code. We should use those ideas when they are useful and ignore them when they are not.
But many people don't want to put in the critical thinking required to do that, so instead they hide behind the shield of "SOLIDD principles" and "best practice" to justify their bad code (not knocking on SOLIDD principles, it's just that people use it to justify making things object oriented when they shouldn't be).
I think the OO hatred comes from how academia and certain enterprise organisations for our industry picked it up and taught it like a religion. Molding an entire generation og developers who wrote some really horrible code because they were taught that abstractions were, always, correct. It obviously weren't so outside those institutions, the world slowly realized that abstractions were in many ways worse for cyclomatic complexity than what came before. Maybe not in a perfect world where people don't write shitty code on a thursday afternoon after a long day of horrible meetings in a long week of having a baby cry every night.
As with everything, there isn't a golden rule to follow. Sometimes OO makes sense, sometimes it doesn't. I rarely use it, or abstractions in general, but there are some things where it's just the right fit.
Much like Agile, or Hungarian notation. When a general principle becomes a religion it ceases to be a good general principle.
> I think the OO hatred comes from how academia and certain enterprise organisations for our industry picked it up and taught it like a religion.
This, this, this. So much this.
Back when I was in uni, Sun had donated basically an entire lab of those computers terminals that you used to sign in to with a smart card (I forgot the name). In exchange, the uni agreed to teach all classes related to programming in Java, and to have the professors certify in Java (never mind the fact that nobody ever used that laboratory because the lab techs had no idea how to work with those terminals).
As a result of this, every class from algorithms, to software architecture felt like like a Java cult indoctrination. One of the professors actually said C was dead because Java was clearly superior.
> One of the professors actually said C was dead because Java was clearly superior.
In our uni (around 1998/99) all professors said that except the Haskell teacher who indeed called Java a mistake (but c also).
Turns out everyone was completely wrong except for that one guy working in Haskell.
Tale as old as time.
Java was probably close to 50% of the job market at some point in the 2000s and C significantly dried up with C++ taking its place. So I'm afraid everyone was right actually.
To be honest, I'm convinced the reason so many people dislike Java is because they have had to use it in a professional context only. It's not really a hobbyist language.
Just for the record, I don't think C ever dried up in the embedded space. And the embedded space is waaaay bigger than most people realise, because almost all of it is proprietary, so very little "leaks" onto the public interwebs.
Believe it or not but there is plenty of Java and C++ in the embedded space. It’s far from being a C fortress.
Probably the Sun Ray computer.
https://en.wikipedia.org/wiki/Sun_Ray
This was it!
And now you know how Nvidia CUDA got so popular.
Tried to modify one boolean in a codebase a few weeks ago and I had to go thru like 12 levels of indirection to find "the code that actually runs".
tourist2d seems to have triggered some moderation trap, but wrote:
> Sounds like a problem with poor code rather than something unique to OOP.
And yeah, OO may lean a bit towards more indirection, but it definitely doesn't force you to write code like that. If you go through too many levels, that's entirely on the developer.
Sounds like a problem with poor code rather than something unique to OOP.
They use higher order types to implement subtyping as a library, with combinators. For example, you can take your fudget that does not (fully) implement some functionality, wrap it into another one that does (or knows how to) implement it and have a combined fudget that fully implements what you need. Much like parsing combinators.
(Hi Andrew)
It's the misuse of OO constructs that gives it a bad name, almost always that is inheritance being overused/misused. Encapsulation and modularity are important for larger code bases, and polymorphism is useful for making code simpler, smaller and more understandable.
Maybe the extra long names in java also don't help too, along with the overuse/forced use of patterns? At least it's not Hungarian notation.
Heck, I love the long names. I know, I also hate FooBarSpecializedFactory, but that's waaaay better than FBSpecFac.
A sample: pandas loc, iloc etc. Or Haskell scanl1. Or Scheme's cdr and car. (I know - most of the latest examples are common functions that you'll learn after a while, but still, reading it at first is terrible).
My first contact with a modern OO language was C# after years of C++. And I remember how I thought it awkward that the codebase looked like everything was spelled out. Until I realize that it is easier to read, and that's the main quality for a codebase.
Objective-C says hello in extra long names are concerned.
> CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications(allocator:sourceDescription:metadataSpecifications:formatDescriptionOut:)
https://developer.apple.com/documentation/coremedia/cmmetada...:)
Jason! Couldn't agree more.
OOP is just not how computers work.
Computers work on data. Every single software problem is a data problem. Learning to think about problems in a data oriented way will make you a better developer and will make many difficult problems easier to think about and to write software to solve.
In addition to that, data oriented software almost inherently runs faster because it uses the cache more efficiently.
The objects that fall out of data oriented development represent what is actually going on inside the application instead of how an observer would model it naively.
I really like data oriented development and I wish I had examples I could show, but they are all $employer’s.
As a reverse engineer, I totally get the phrase.
Even with non-obfuscated code, if you're working with a decompilation you don't get any of the accompanying code comments or documentation. The more abstractions are present, the harder it is to understand what's going on. And, the harder it is to figure out what code changes are needed to implement your desired feature.
C++ vtables are especially annoying. You can see the dispatch, but it's really hard to find the corresponding implementation from static analysis alone. If I had to choose between "no variable names" and "no vtables", I'd pick the latter.
Vtables can be annoying to follow through, but try reverse-engineering an Objective-C binary! Everything is dispatched dynamically, so 99% of the call graph ends in objc_msgSend(). Good luck figuring out what the message is, and the class of the object receiving it.
Isn't that easy? The message is a string in one of the register parameters to it.
> Everything is dispatched dynamically
Well, not everything, there is NS_DIRECT. The reason for that being that dynamic dispatch is expensive - you have to keep a lot of metadata about it in the heap for sometimes rarely-used messages. (It's not about CPU usage.)
It’s all about the data model and the architecture.
I think people focus a lot on inheritance but the core idea of OO is more the grouping of values and functions. Conceptually, you think about how methods transforms the data you are manipulating and that’s a useful way to think about programs.
This complexity doesn’t really disappear when you leave OO language actually. The way most complex Ocaml programs are structured with modules grouping one main type and the functions working on it is in a lot of way inspired by OO.
> grouping of values and functions
Encapsulation.
Which I think is misunderstood a lot, both by practitioners and critics.
You're right, it is all about the problem domain. Unfortunately, there was a solid decade where that was not the typical advice, and OO was pushed (in industry and in education) as the last word in programming, suitable for all tasks. There's a generation out there who was taught programming as "instantiate a truck object that inherits from a car object" and another generation who was required to implement math using OOP principles instead of just doing math. Programming languages that did not have object models suddenly developed them, often incompatibly with the rest of the language. So, while I think that OO has its places, I understand why there's a lot of visceral response to it online.
From my pov, both inheritance and encapsulation aren't great if you have to maintain code and add new one.
Also, I dislike design patterns overuse, DDD done Uncle Bob style.
Also we can think of where OOP drives many teams to:
https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
https://factoryfactoryfactory.net/
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
> I can't imagine building something like a graphics framework without some subtyping.
While React technically uses some OOP, in practice it's a pretty non-OOP way do UI. Same with e.g. ImGUI (C++), Clay (C). I suppose for the React case there's still an OOP thing called the DOM underneath, but that's pretty abstracted.
In practice most of the useful parts of OOP can be done with a "bag/record of functions". (Though not all. OCaml has some interesting stuff wrt. the FP+OOP combo which hasn't been done elsewhere, but that may just be because it wasn't ultimately all that useful.)
React is a kind of strange dysfunctional OOP pretending not to be, to appeal to people like those on this thread ;)
Function calls have state, in React. Think about that for a second! It totally breaks the most basic parts of programming theory taught in day one of any coding class. The resulting concepts map pretty closely:
• React function -> instantiate or access a previously instantiated object.
• useState -> define an object field
• Code inside the function: constructor logic
• Return value: effectively a getResult() style method
The difference is that the underlying stateful objects implemented in OOP using inheritance (check out the blink code) is covered up with the vdom diffing. It's a very complicated and indirect way to do a bunch of method calls on stateful objects.
The React model doesn't work for a lot of things. I just Googled [react editor component] and the first hit is https://primereact.org/editor/ which appears to be an ultra-thin wrapper around a library called Quill. Quill isn't a React component, it's a completely conventional OOP library. That's because modelling a rich text editor as a React component would be weird and awkward. The data structures used for the model aren't ideal for direct modification or exposure. You really need the encapsulation provided by objects with properties and methods.
React is most likely not what the author had in mind by a graphics framework. The browser implementation of the DOM or a desktop widget system is much more likely the idea.
While using a OOP language.
Yeah, I agree with you, and actually like OOP where it's appropriate.
Unfortunately there were so many bad examples from the old Java "every thing needs a dozen factories and thousands of interfaces" days that most people haven't seen the cases where it works well.
If everyone does it wrong, then that alone means it itself is wrong.
Everyone? Really, that's your take? Most code out there is OOP and I find it hard to believe that everything is wrong.
Most food out there is McDonalds.
Indeed. "The purpose of a system is what it does."
I find inheritance works best when you model things that don't exist in reality, but only as software concepts, for example, an AbstractList, Buffer or GUI component.
Really like this concept!
That's why we use depedency injection now~~!
I've always wanted my editor's go-to functionality to take me to an abstract class instead of the place where the actual logic resides. Good times.
Any modern IDE will let you immediately bring up the subclasses with a single hotkey. If you have an abstract class with only a single subclass and that's not because new code is going to be added soon then yes, it's a bad design decision. Fortunately, also easy to fix with good IDEs.
In my last project every class had a corresponding abstract class, and then we used DI to use the real class. Good to be rid of it.
That sort of knee-jerk over-application of a technique will ruin any codebase in any language, unfortunately. It tends to reflect a lack of confidence by the developers. They aren't entirely sure how to get best results so fall back on religious devotion to 'best practices' even when it's inappropriate, in the hope that they can point the finger later if there are problems.
It's all about the problem domain imo. I can't imagine building something like a graphics framework without some subtyping.
The keyword being "some".
Yes, there are those who can use OOP responsibly, but in my (fortunately short) experience with Enterprise Java, they are outnumbered by the cargo-cult dogma of architecture astronauts who advocate a "more is better" approach to abstraction and design patterns. That's how you end up with things like AbstractSingletonProxyFactoryBean.
[dead]
Tbh decompiling software and figuring out how it works isn’t easy but that is part of the fun :) - it’s the reason ive ended up following many of the weird paths in computing that I have
Agreed; modding obfuscated Java is impressive, but not quite on the level of modding in the (Nintendo) emulation community. The things that have been achieved with classic Nintendo titles are absurd, like adding high-performance online multiplayer to Super Smash Bro. Melee.
Said online multiplayer [0].
The devs also wrote a write-up here about how they handle the desyncs in netcode [1].
[0] https://slippi.gg/
[1] https://medium.com/project-slippi/fighting-desyncs-in-melee-...
Yeah, I honestly think that the thing which would kill modding in the future won't be any kind of (overtly) hostile action, it will simply be sheer inertia. Since the new "drop" system, pretty much every minor version requires rewriting many things in your mod, and modders find it hard to keep up, and there will be point when many mods just don't bother updating to the newest version.
The game used to be simple, both conceptually and codewise but obviously, it became more and more bloated the more developers touched it and the more bureaucracy was added. Now, it's a complete nightmare, and I bet it's also a nightmare for the developers too, considering how hard it is for them to fix even basic issues which have been in the game for like a decade at this point.
indeed. with how good and cheap/free decompilers have gotten over the years my preferred way to read abstraction-happy c++ and rust code is to compile it with optimisations and debug symbols and then read the decompiler output.
But you don’t understand, it enables code re-use…
You have to have Factories and inheritence..
/s
To be fair, since 2019 Mojang has been providing the mappings instead of everyone having to use community-created ones.
Very few people use mojang mappings -- the two big modloaders, forge and fabric (and their derivatives) have their own mappings respectively, due to the restrictions of the mojang mappings. It's possible to use the mojang mappings, but much less common.
PaperMC exclusively uses Mojang mappings, and it's the most popular loader for server-side modding these days.
Paper isn’t a mod loader, it uses Fabric under the hood. Also, what makes you think it’s the most popular server? I thought it was fading. I switched my server from Paper to Fabric years ago.
It doesn't use Fabric under the hood, where did you hear that?
> Also, what makes you think it’s the most popular server?
Because it's the only server software that can actually scale and support a long-term server with feature and bugfix stability. Its popularity bears out in what hosting companies say people are most commonly using. Though I'm not sure if there is a specific publicly published statistic to point to to prove this - there is bStats global stats, but it is biased towards the Paper ecosystem.
Fabric is getting close with certain optimization and bugfixing mods, but it's still not there. Paper has a checklist of what optimizations and fixes must be included for a release to proceed, whereas Fabric ecosystem is still a hodgepodge of different things that are only available on specific Minecraft versions.
I've recently been setting up a velocity server network for some friends and friends of friends, and I agree with your findings. I don't have much history on Forge vs Paper vs Fabric vs..... (and found it all very overwhelming, honestly) but from what I can tell, the popular sites like modrinth have communities way more focused around Forge/NeoForge.
Paper does seem to have it's own site for plugins, hangar or something? (Don't have my web history on this PC) but the community support doesn't seem nearly as fleshed out.
It is incredible though, before 1.21 the last time I played around with MC server hosting was probably around 1.8 days, when it seemed like you only had Bukkit and a few plugins for it
Paper is custom server software and could be easily argued to be a mod loader if you consider plugins to be mods (although it’s probably a weak argument since there’s no mixin support built-in, although some large servers have added mixin support to their own Paper forks). However, it does not use Fabric under the hood (it’s based on Bukkit/CraftBukkit). By playercount, it is the largest (custom, standalone) MC server software in the world.
I tend to think the distinction between "plugins" and "server-side mods" is a little pointless these days. I would consider something a "mod" if it's in an environment where it can deeply touch Mojang code and completely transform it if needed. And before we ever had Fabric/Sponge mixins, we had reflection and ASM for doing just this. We still have that, and a lot of Paper plugins make extensive use of reflection - particularly libraries that reflect into netty to hook directly into the protocol are quite common.
You’re right, my bad, Spigot (from Bukkit), not Fabric. I got the impression it’s actually using ~~Fabric~~ Spigot code for this because you’re using plugins compiled for Spigot and both a paper.whatever and spigot.whatever config file, but after looking it up I see that they forked it.
I’m not really clear on mod vs plugin vs mixin, I was just trying to refer to whatever software does the decompilation work rather than just consuming APIs provided by projects that do.
Sounds like it’s correct that Paper didn’t do its own mod API, but incorrect that Paper doesn’t do its own decompilation work.
> By playercount, it is the largest (custom, standalone) MC server software in the world.
Do you have a source on this? Not trying to accuse you of anything, I just know that a few servers claim this, and don’t know if we have reliable numbers.
Ah, I was aware of the different Fabric (Yarn) mappings and internal names (due to the few mods like architectury) but I think Forge switched over to Mojang's?
> As of 1.16.5 [(2021)], Forge will be using Mojang’s Official Mappings, or MojMaps, for the forseeable future
Pretty sure this applies to NeoForge as well: https://neoforged.net/personal/sciwhiz12/what-are-mappings/
(Neo)Forge primarily use either mojmaps or Parchment, which are the Mojang mappings with some extra goodies like docstrings and parameter names
It took me a while to find how to obtain the official mappings, but this article seems to have instructions: https://minescript.net/mappings
According to the article, official mappings can be found here: https://piston-meta.mojang.com/mc/game/version_manifest_v2.j...
They're also linked on the wiki page for each release, along with links to the client and server jars: https://minecraft.wiki/w/Java_Edition_1.21.5
Why do they obfuscate if they're just going to provide the mappings?
Proguard can also apply optimizations while it obfuscates. I think a good JVM will eventually do most of them itself, but it can help code size and warm-up. I'm guessing as JVMs get better and everyone is less sensitive to file sizes, this matters less and less.
And there's no way to do only the optimisation part? Surely you could optimise without messing up class and method names..?
One of the biggest optimizations it offers is shrinking the size of the classes by obfuscating the names. If you're obfuscating the names anyway, there's no reason that the names have to be the same length.
"hn$z" is a heck of a lot smaller than "tld.organization.product.domain.concern.ClassName"
So we're not talking about runtime performance, but some minor improvement in loading times? I assume that once the JVM has read the bytecode, it has its own efficient in-memory structures to track references to classes rather than using a hash map with fully qualified names as keys
Proguard was heavily influenced by the needs of early Android devices, where memory was at a real premium. Reducing the size of static tables of strings is a worthwhile optimisation in that environment
Okay but we're talking about Minecraft on desktops and laptops, where the relevant optimizations would be runtime performance optimizations, no?
Probably, but proguard tends to bundle the whole lot together
Even a hash map with fully qualified names as keys wouldn't be so bad because Stirng is immutable in Java, so the hash code can be cached on the object.
The names need to be stored somewhere because they are exposed to the program that way
They have to be stored somewhere, but they don't have to be what the JVM uses when it e.g performs a function call at runtime. Just having the names in memory doesn't slow down program execution.
At runtime this is going to be a branch instruction yes
Yeah in some ways the obfuscation and mappings are similar to minification and sourcemaps in javascript.
And minification in JavaScript only reduces the amount of bytes that has to be sent over the wire, it doesn't improve runtime performance.
According to the v8 devs it also can increase parsing performance
> Our scanner can only do so much however. As a developer you can further improve parsing performance by increasing the information density of your programs. The easiest way to do so is by minifying your source code, stripping out unnecessary whitespace, and to avoid non-ASCII identifiers where possible.
https://v8.dev/blog/scanner
Sure, but that's also just in the category improving loading a bit. It doesn't have anything to do with runtime performance.
Well, maybe that's why they're not obfuscating anymore.
In 2004 I played an MMO game on a pirated server. The owner of the server somehow got a version of the server binary, and used a hex editor (!) to add new features to the binary over time.
It's the closest I've ever see to someone literally being one of the hackers from Matrix, literally staring at hexadecimal and changing chars one at a time
Presumably they were using a decompiler e.g. IDA Pro to know what characters to change in the hex editor? I've done that before to find offsets in the binary to NOP out some function calls.
I just remember when I cracked Space Empires III shareware as child. I didn't release the crack. Plus was a bit crappy, needing every time that I loaded the game, write a wrong serial so the check thought that was right serial code. I simple changed a few x86 opcodes to invert the check condition...
That's a level of dedication that I have never devoted to anything in my life.
That's energy that could change the world if harnessed correctly.
It did change the world - it made it better for players of the game.
That approach is also super useful if you're manually flashing an image onto some embedded thing (like an ECU, or other types of boot rom). Of course on many modern systems you'll have to get around the checksum guards, but there's typically all sorts of glitch hacks to do that.
Wasn't that WoW? I vaguely recall that a lot of the private servers worked off of a copied and / or decompiled version of their own server software for years, which is also why they never went further than the WotLK expansion. (the other part of that was people didn't want to, but that's another discussion)
AFAIK the WoW server code was never leaked. All private server code bases were developed by reverse engineering network traffic, game behaviour and client asset files.
E.g. the code for AzerothCore is fully available (and very easy to run on very low spec hardware)
https://github.com/azerothcore/azerothcore-wotlk
https://doomwiki.org/wiki/DeHackEd
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.
This is fairly common in gaming mods. I wrote some mods myself and had to work with decompiled obfuscated code to find the right hooks, injection points, reverse implementations, etc.
Java is pretty easy to decompile and it's not a huge amount of effort to poke into the generated JVM code and start doing things. If you have a decent idea of how VMs work, C-like languages work, and how object dispatch works it's really not that hard. Also the early modding scene for Minecraft was really fun. I was a huge Minecraft player at the time and was early into the deobfuscating -> modding scene and the community was one of the most fun computing communities I've been in. Due to how focused it was on the game and its output it wasn't bogged down in nearly as much bikeshedding and philosophy as most FOSS projects get. Honestly one of the highlights of the coding I've done in my life.
Decompiling Java is trivial, as Java bytecode more or less maps directly to textual Java code. Deobfuscating is a monumental manual effort.
I am terrified by Minecraft mods always being distributed from dodgy download sites and not rarely come with their own Windows EXE installers. And as far as I know there is no sandboxing at all in the game (uhm, no pun intended) so once installed the mod has full access to your computer?
As someone whose kid has pulled me into the world of using mods (though not (yet) making them for Java Edition) I think this PSA is worth sharing of how to use minecraft mods without pain and with minimal risk, in case anyone is getting started, or has gotten started and finds it frustrating:
1. Use MultiMC to manage instances with various mods, since mods are rarely compatible with each other, and since each version of a mod only is compatible with a single specific point release of the game itself.
Never download any EXE files to get a mod, that does sound sketch AF.
2. mods are always packaged for a particular Loader (some package for multiples and some require Forge, Fabric, or NeoForge), and MultiMC can install any of them into a given instance. Aside from different startup screens there seems to be no difference so idk why we need 3 different ones.
3. Curseforge's website and modrinth both seem to be legit places to get mods from. I personally find the installable Curseforge program itself to be bad and spammy, and would never use that, but the site still lets you directly download the jars you need, and lets you check "Dependencies" to find out what other mods you need.
If you're using MuliMC or one of its various forks, you can search for and install mods from modrinth or curseforge right in the launcher. I fine it more convienent than doing it with a browser and dragging them in, but either way works.
Curseforge is OK, Modrinth is a less commercial alternative. The ten first Google hits if you search "Minecraft mods" are probably NOT OK, most Minecraft-related stuff is SEO optimized to hell by sites which are very fishy.
There are actually two versions of the Curseforge client, the "Overwolf" version that is built on that platform (and is quite bad as a result) and a newer standalone version that doesn't use Overwolf, it's much better.
> 3. Curseforge's website and modrinth both seem to be legit places to get mods from. I personally find the installable Curseforge program itself to be bad and spammy, and would never use that, but the site still lets you directly download the jars you need, and lets you check "Dependencies" to find out what other mods you need.
PrismLauncher, a popular MultiMC fork, has direct integration with Curseforge and Modrinth, while being completely ad-free. Best of both worlds.
A few mods are not available because Curseforge allows mod authors the option to force ad monetization by blocking API access, but these are few and far between.
PrismLauncher is excellent, it feels like it found the right level of abstraction. Automates chores without black-boxing what it's doing.
And there's a makedeb for it! https://mpr.makedeb.org/packages/prismlauncher
Indeed I finally got Prism working and it’s super cool, even installs the dependencies like a package manager!
Yeah mods are just regular Java .jars that can do anything. To circumvent this issue Mojang introduced datapacks but they are super limited in what they can do. They’re basically just Minecraft commands in a file along with some manifest files to change e.g. mob loot drop rates. These Minecraft commands are Turing complete but a huge PITA to work with directly, no concept of local variables or if statements, no network access, etc. Every entity in MC has associated NBT data that is similar to JSON that stores values like position, velocity, inventory, etc. You can change NBT with commands for mobs, but in what can only be described as a religious decision, Minecraft commands are unable to modify player NBT. So for example it is impossible to impart a velocity on a player.
One wonders why Mojang didn’t embed Lua or Python or something and instead hand-rolled an even shittier version of Bash. The only reason MC servers like Hypixel exist is because the community developed an API on top of the vanilla jar that makes plugin development easy. Even with that there is still no way for servers to run client-side code, severely limiting what you can do. They could’ve easily captured all of Roblox’s marketshare but just let that opportunity slip through their fingers. Through this and a series of other boneheaded decisions (huge breaking changes, changes to the base game, lack of optimization), they have seriously fractured their ecosystem:
- PvP is in 1.8 (a version from 2015) or sometimes even 1.7 (from 2013)
- Some technical Minecraft is latest, some is in 1.12 (from 2017)
- Adventure maps are latest version
- Casual players play Bedrock (an entirely different codebase!)
The words “stable API” have never been said in the Mojang offices. So the community made their own for different versions, servers use the Bukkit 1.8 API, client 1.8 mods use Forge, latest mods use Forge or Fabric. The deobfuscated names are of little utility because the old names are so well ingrained, and modders will also probably avoid them for legal reasons.
Bedrock has proper mod support and you can program with Typescript.
Better than datapacks overall but lacks a way to plug into the rendering pipeline or make custom dimensions. Java mods have more capabilities
> I am terrified by Minecraft mods always being distributed from dodgy download sites and not rarely come with their own Windows EXE installers.
That's not their main mean of distribution, most often those sites were just third parties unrelated to the mod authors that repackaged the mod and somehow got a better SEO. But TBF back in the days the UX/UI for installing mods was pretty terrible. Nowadays there are more standardized and moderated distribution websites from which you just download the .jar of the mod.
> And as far as I know there is no sandboxing at all in the game (uhm, no pun intended) so once installed the mod has full access to your computer?
This is totally true though.
This is not the norm these days! There are popular mod loaders like curseforge that pulled from moderated repositories. It’s still not bulletproof, but a far cry from trusting some installer executable
I prefer modrinth as well, both are good but curseforge has done some things which makes us require an api etc. for true automation where modrinth is genuinely nice.
I used to use prism launcher which would just give me a search box and It on the side would have things like modrinth / curseforge etc., Usually I preferred Modrinth but there were some modpacks just on curseforge only but I never really downloaded a shady modpack from some random website aside from these two, In fact sometimes I never opened up a website but just prismlauncher itself lol
+1 for Prism Launcher and Modrinth! I use Prism on my Steam Deck. I would’ve mentioned them both but Curseforge was the only name I could remember
Yup very common to take a popular minecraft mod, insert malware, rehost it, and seo your way into getting downloads.
Yes, much like how most software for PC has been written since the beginning of time?
I watched one of my young children power themselves through the obfuscation to learn advanced modding. There was zeal for the knowledge and mods in that community.
Mod developers were able to get the source code for Minecraft through a developer program over a decade ago. I'm not sure that it is still the case. I think they are just de-obfuscating the compiled CLASS files so anyone can decompile them without access to the source.
This was how many Runescape bots were developed back in the OSRS days. At some point (RS2?) they made the client super thin so there were no longer methods for high level game functionality (walk to here, get amount of gold in inventory, etc.).
To be fair, the tooling existed before Minecraft and they published obfuscation maps that map the obfuscated names to the non obfuscated ones.
They only published the mappings starting from 2019.
6 years ago, yes.
it's actually pretty trivial and something a single person can do I had to rebuild a server jar to source since the guy maintaining it disappeared and it had special behaviors in it that were relied upon for the game networks playability.
There is always one thing that I found so facintating with the modding scene in Minecraft. Because Minecraft does not have a modding api but the java byte code can be changed. People simply developed their own way of creating an API. There are 2 main modding APIs. Forge/Neo-Forge and Fabric.
[1]Fabric uses Mix-ins while [2]Forge uses a more event based system that is added to the source code of minecraft where they add hooks into events that users can use.
To me its just incredible. Its not often that I see that users own an abstraction instead of the developers.
I wonder from a modding perspective would it be better if all public methods are just the API users can call and they themselves create a way for mods to exist?
[1] https://wiki.fabricmc.net/tutorial:mixin_introduction [2] https://docs.minecraftforge.net/en/latest/concepts/lifecycle...
> I wonder from a modding perspective would it be better if all public methods are just the API users can call and they themselves create a way for mods to exist?
It's the way vintage story implemented modding. They developed the whole game as engine + modapi + hooking engine for stuff outside of hookapi.
Then most of gameplay is implemented as mods on top of engine using api and hooking. And those tools are open source, with central distribution point for mods, so servers can dispatch and send update of required mods to clients as they join.
Marvellous and elegant design. Makes running a server with client side mods a breeze, because mods are automatically pushed to the clients.
Though in the end, you can't really open all the interfaces and expect it to be stable without making some huge trade offs. When it works, it's extremely pleasing. Some mods for vintage story that are made purely using mod api can work between major game versions. Even server/client version check is intentionally loose as mismatched versions can still for the most part interact across most of mechanics.
In practice, to preserve balance of api evolution and stability, not everything in the game is in the api, and thus you have to use their hooking api, and stuff that is not exposed tends to break much more often, so mods require manual updates, just like in minecraft(though not as bad, tbh. In minecraft nowadays modders tend to support both fabric and neoforge/forge apis, targeting each for at least a few major versions. In vintage story, you only gotta support one modding api heh).
You are right! I totally forgot about Vintage Story, I only read about it briefly.
> ... you can't really open all the interfaces and expect it to be stable without making some huge trade offs.
Another game I often play with a huge open interface is Crusader Kings 3 and paradox games in general. Most of the gameplay is implemented in their scripting language for the engine. But as you said when the game gets a big update most mods simply dont work anymore.
If the support of the community dies down many mods with much work and craft dont get updated anymore and rot away as the game gets updates. Quite sad actually.
Thats why I also quite like Star Wars Empire at War mods. The game does not get any updates anymore. The API here is mostly frozen, even old mods still work.
> mods are automatically pushed to the clients
I'm surprised this hasn't become a malware distribution channel yet.
It has and it hasn't. There's modders in the scene who I refuse to use mods from because I know they also have developed cheats.
All of the same supply chain issues you have with packages in a programming ecosystem exist in VS's mod system.
It won't do much though. Although it will make things a bit easier. A lot of minecraft mod requires direct modification to Minecraft's core mechanism. For example in popular mods: create, immersive portal and distant horizon all taps in minecraft's collision mechanism or rendering pipeline in a quite aggressive way that unlikely there will ever an abstraction be able to handle that.
And, no. Although forge does not encourage you to use it. It also supports mixin like direct modification. It's just less polished than mixin(requires more knowledge to java Bytecode)
It's unrealistic to ask mojang to make an abstraction that you can actually change everything in the core without direct modification (let alone how do mojang know what part need to be abstracted?)
I wonder if they'll ever just open source the Java Edition on GitHub. People will buy Minecraft on every platform it is released on, just like Skyrim.
I don't even think open sourcing Minecraft would hurt them financially. People don't buy Minecraft because that's the only way to play the game; it's not, it's easy to find ways to run Minecraft for free. The reason people buy it is to join servers.
Most serious servers only allow players with valid paid Minecraft accounts to join, because it allows the server owner to ban people or otherwise keep track of people. I don't see any reason why this would change just because the game client was made open source.
People could set up 3rd party auth systems and eliminate the need for mojang
You can already do that and some do. Mojang, for some incomprehensible reason, even lets you disable auth in the official server's settings (`online-mode=false`).
It's not incomprehensible. It enabled LAN games without outside internet access.
Maybe, but the "paying" is load-bearing, because you need to prevent banned people from just creating new accounts.
Sure a different approach might be possible, but would likely also hinder adoption of such a 3rd party account system.
That already exists, but people still buy the game
There's no reason for them not to. Open source launchers using the "honor system" for account verification are already established and normalized. It's trivial to just comment out that verification. The jars and assets are free to download from Microsoft's servers without needing an account. It's a trivial game to get without paying, so I don't see any downside for them to open source the engine.
Honestly, I would almost settle for Microsoft open sourcing the Minecraft Java back-end server at a minimum. This alone is long overdue. The massive fanbase could have started to maintain it in ways Microsoft could only fathom.
the client and server are the jar file, but net.minecraft.client deleted, client has both.
[dead]
Back in 2010 Notch promised
> Once sales start dying and a minimum time has passed, I will release the game source code as some kind of open source.
https://web.archive.org/web/20100301103851/http://www.minecr...
Notch has said he would do many things and rarely follows through with them. I'm still waiting for 0x10c.
He sold the game to Microsoft, his promises kind of don't matter anymore.
I think you meant to reply to the parent comment, I never mentioned Minecraft
> Once sales start dying
Has that part ever happened?
TBF sales didn't start dying
The only upside of that game was that I taught myself assembly because of it. Even though it never released
Sales are still good though- right? It’s the no paid iOS game.
I'm pretty sure A Minecraft Movie has already made more money that the game had made when he made that promise.
Back then he couldn't have foreseen the size of the money printing factory that the game would become.
I remember when Minecraft was sold for $2 billion and people thought it was madness and would never make the money back.
Since then they've made that back on game copies alone, and god only knows how much from movie/merch rights and microtransactions.
Notch has said a lot of things over the years. Many after the sale to Microsoft were not so great. Suddenly without purpose and more money than he would ever need in a life time, he found a new purpose that wasn't so great.
A lot of Qanon rants and other conspiracy things. Just goes to show you that some times it is best you don't get what you wish for.
What is he up to recently? Did he come around?
I have been following him, and I think a lot of the claims about him have been exaggerated. He stopped being so edgy on twitter after watching the "this is phil fish" video. It is an interesting watch and applicable to notch.
https://www.youtube.com/watch?v=PmTUW-owa2w
He is developing a new voxel-like game called "levers and chests", and before that he has shown us a few cool webgl demos I find interesting.
https://www.youtube.com/watch?v=JYMy7TPsNd0
More games should be open source like doom. It doesnt effect the art assets which are still copyrighted.
Amusingly, Minecraft is a counter-example. It has very few assets and they are hardly essential to the experience.
The music and sounds play a large part into the experience though, and are much harder to replace than the textures.
The sounds maybe, but the music? If there's one game whose music I always turn off instantly it's Minecraft. Touhou Youyoumu Minecraft ain't.
The music is definitely considered classic, you can find tons of people online talking about how it means a lot to them - and personally, I really loved the music.
I remember the early Minecraft musics from C418 to be relatively unconventional, especially some of the jukebox discs.
I started playing Minecraft again recently and while it sounds like it’s the same artist, and it’s still somewhat contemplative, it’s not dissonant anymore.
It's not the same artist. C418 had a very good deal with Notch's Mojang, letting him keep rights. Microsoft demanded that he sign over the rights to further music as work for hire. He refused, as a result the newer music in Minecraft is made by other composers who signed on to that deal and try to make music fitting with C418's style.
It's even recognized by the Library of Congress!
https://www.loc.gov/static/programs/national-recording-prese...
It's not hard to get into the library of congress? It's purposely extremely easy. I forgot who it was, but there was one big right-wing talk show host that would end all of his segments by saying it's being added to the Library of Congress as if it's an exclusive accolade, and people rightfully called him out on his shit for how easy it is to do that
The classic Minecraft music was great. Some of the new music Mojang has added in recent years is unlistenable noise. Like "glitchcore" crap. I tried playing with music on recently and after a few hours had to give up.
Interesting, I love Minecraft's music. I do listen to it intentionally outside of the game, but it's not quite the same as having it suddenly start up during gameplay. The first I heard of someone "obviously turning off the music" was, I kid you not, yesterday, and now I'm hearing it for a second time today. Would woulda thunk!
There are soundtracks I listen to outside of their games: Castlevania Symphony of the Night, Chrono Trigger, Shadowgate,... but Minecraft would be way near the end of the list. The music is too generic to be worth the attention, yet too present to work as ambiance. It kinda reminds me of Silent Hill's soundtrack.
"Generic"? Ouch, lol.
I turn off the in-game music while playing. I prefer to listen to my own stuff, including video essays etc, but I do still enjoy a lot of the music, and I've listened to it standalone a decent amount. I would tend to the same in most sandbox games, like factorio
That specific coincidence is a great example of the "Baader-Meinhof phenomenon"
Ah, thank you! Never knew what that was called. Guess I could asked Chat Jippity but there's no fun in that.
I play Minecraft for the music. And for the feeling of digging myself up from the mines and breaking through to surface to hear the sound of rain.
I like Minecraft’s music. If there was a way to have it not play when the game is paused or on the title screen, I would probably keep it on.
A quick search nets this: https://modrinth.com/mod/pause-music-on-pause
> If there's one game whose music I always turn off instantly it's Minecraft.
I turn it off but only because I have great difficulty with multiple sound sources at the same time. I will happily listen to C418's output for hours whilst doing something else.
(And also Touhou because who doesn't love an electric trumpet?)
Cannot disagree more. Probably my favorite video game music of all time.
There are so many third-party texture packs for Minecraft that losing access to the official ones would hardly even be an obstacle.
Free (as in freedom) software can still be sold.
OSS would probably also just mean "read the source e.g. on github", not really specific as to all the four essential freedoms.
This is one area EA has been doing well.
They have been open sourcing some of their older IPs, they recently open sourced their Command & Conquer games for example:
https://www.ea.com/games/command-and-conquer/command-and-con...
It sounds like you might be looking for Minetest/Luanti.
no, I think they're looking for the official game to be open sourced... that's much more appealing than a knockoff since it's the version everyone actually plays.
It's much less appealing because it's much harder to mod.
less appealing to who? Lots of 13 year olds learned to code by writing minecraft mods so it can't be that hard. You also get the benefit & satisfaction of it actually being in Minecraft—yes, they are both very similar games where you explore and place blocks in a procedurally generated world, but it really does matter. I can't really explain why if you don't get it but it's evident people do care even when they know about Minetest.
IMHO, "actually in Minecraft" is roughly akin to "my shoes are actually Nike".
That said, I never had any interest in playing on a server that was populated by anyone but my small circle of friends.
Now my kids are growing up doing the same which I find great because I know exactly with whom they are interacting and have no worries about it.
It's much more appealing because it has a much more vibrant modding community.
Community can go a long way towards compensating for worse technology, yeah.
Community is the entire goal. The technology just has to meet some minimum threshold. You know any 13 year olds playing Minetest?
My kids are younger than that and play Minetest/Luanti all the time. They are well aware of Minecraft but are completely engrossed by the modding first approach of Luanti.
I don't know any 13-year-olds, but I hear that a lot of them do play Minetest.
Exactly. Why losing the time with Minecraft when there's Luanti, a free community-driven project?
At this point, they could open source it, and just charge for Minecraft accounts being able to authenticate with their login servers to join authenticated Minecraft servers, and it wouldn't change sales much.
Obfuscating Minecraft code doesn't make much sense to me from an IP protection angle. It is one of the easier games to build from scratch once you see how it plays. Most of the magic is emergent behavior between many simple rule systems. Nothing in that source code would be much of a revelation. It's not like there's a nanite implementation hiding in there somewhere. It's mostly boring stuff like defining how pig or sheep walk through the scene and respond to various goals. The "scariest" part of Minecraft tech is probably chunk management.
That's all true now but none of it was true back in the alpha days.
And once there were mods and mod loaders built on the obscured source, it became easier to not disrupt the toolchains than to bite the bullet; I think Mojang now wants to make moving mods easier (someone somewhere has to be a bit sad that there are famous modpacks running old versions of Minecraft because it's easier to backport everything to 1.7.10 (including running on newer Javas) than it is to update mods).
Minecraft, Roblox, Geometry Dash, Trackmania...these are games that succeeded because of their communities. Alone, they don't provide much for the average player, but creative players build interesting things that appeal to everyone.
I think one of the reasons Vision Pro and metaverse have been struggling is because their engines are bad. Not just locked down, but hard to develop on (although I don't have personal experience, I've heard this about VR in general). If you want to build a community, you must make development easy for hobbyists and small users*. I believe this has held even for the biggest companies, case in point the examples above.
* Though you also need existing reputation, hence small companies struggle to build communities even with good engines.
You can add the Flight Simulator series to the list, which spawned a vast ecosystem of add-ons, both free and commercial.
I believe though, that what you actually need as a big or small company, is good game first and foremost; the engine is secondary. When the community around a game reaches a critical mass, the very small percentage of its members who have the skills to modify things becomes significant as well.
For instance, Richard Burns Rally was not intended to be modded at all, yet the fans added new cars, new tracks, online scoreboards, etc.
In the Luanti [1] community (a voxel games engine/platform, designed to be moddable nearly from the start), one begins to see something similar as well: notable games gets mods, others don't (the former default game is a particular case; it is not exactly good but go tons of mods because of its status, and games based on it benefit from that ecosystem). Yet all use the same engine (perhaps Roblox is similar in that respect, I'm not sure if they have "reified" whole games like Luanti did).
[1] https://www.luanti.org/
The thing is, Minecraft of 10 years ago (or more) wasn’t even really that great of a game. It wasn’t bad, I enjoyed it, but it wasn’t that great.
What it did do right was be very open-ended and be conducive to modding, both of which were amplified by multiplayer capabilities.
I would wager that most of the fun players have had in Minecraft is from experiences that were built on top of Minecraft, not from the game’s own gameplay.
I think you're remembering Minecraft in a poor light. Even 10 years ago Minecraft was a great game because even in the base game it encouraged creativity and the community immediately realized the potential to expand that with mods.
It was, as far as I can tell, the first game which was infinitely procedurally generated yet changeable. Huge procedurally generated games have a long history but in e.g. Elite or Seven Cities of Gold you couldn't modify the world in any meaningful way. The closest is probably dwarf fortress, but there the modifiable world is pretty small (or was when Minecraft came out).
That made it a great game. I think it was inevitable that the first game which combined these two, infinite procedural worlds and free modifiability, would be a huge success. Worth noting also that infiniminer, despite the name, didn't have the infinite part worked out!
I'm always impressed when I check it, that flightsim.com is still running, and still has everyone's mods going right back to the 90s. Just in case anyone still wants the poor quality airport I uploaded for Flight Simulator 2000 twenty-something years ago.
Not sure if I understand exactly what you mean by reified, but Minecraft has a ton of minigames based on server-side mods which clone other popular games. Sometimes popular Minecraft minigames/mods even get implemented as standalone games.
Battle royale games were almost certainly heavily inspired by the Minecraft minigame which predates them. Factorio has the old industrialcraft mod as an acknowledged inspiration. Vintage Story is basically standalone Terrafirmacraft (and by a dev from that, as I recall).
Arent battle royale games inspired by things like The Hunger Games or Battle Royale? All the server minigames like that that I recall from back in the days were named something like Hunger Games
Yes. The Hunger Games film and book inspired by the Japanese film "Battle Royale" in turn, inspired the Minecraft minigame. But later battle royale games were inspired by the minigame, not the films directly. A shrinking world border, for instance, is pretty important to make the concept work (in a film, it doesn't actually have to work!).
Last man standing formats were perfectly possible in traditional FPS formats too, but they weren't really a thing because to actually be fun, the format needs
1. Big maps and lots of players (more than the typical FPS)
2. A "searching for loot" mechanic, where you can increase your chances of survival by looking for good items, making interesting risk/reward tradeoffs and discouraging just turtling up in the most defensible location.
3. Shrinking borders, to prevent an anticlimactic endgame of powerful players searching for hiding stragglers.
Minecraft basically had all three since 2014, and there were quite popular last man standing formats like UHC even before they had world border (and before the Hunger Games film came out).
Roblox had a phenomenal engine when it came out and its terrain destruction is still unmatched.
In 2006, I could download the Roblox app and bam, I would play thousands of 3D multiplayer games for free that loaded near instantly. With fully destructible buildings and dynamic terrain. Somehow I didn't get viruses from remote code execution.
That was groundbreaking at the time. In that era, I'd have to download Steam, buy individual games like Counterstrike, and the wackiest thing would be the "surf" gamemode. Most games I'd buy on CDs. I certainly couldn't knock down entire buildings with grenades.
If you contrast with Second Life/Habbo Hotel, you could walk around and talk to people I guess?
The community that spring up around it eventually carried it into total dominance of gaming for American children, but the basic parts of the engine like "click button, load into game, blow stuff up" were a decade ahead of the curve.
Also Blockland cost money, Roblox was free.
> I'd have to download Steam, buy individual games like Counterstrike, and the wackiest thing would be the "surf" gamemode.
It's interesting that you chose Counter-Strike as an example, as that is a Half Life mod itself, and by 2006 there was a large ecosystem [1] of Half Life modifications using Metamod and AMX Mod (X). The last one in a weird C-like language called Small or Pawn, which was my first programming language that I made serious programs with.
Especially the War3FT mod where users gained server-bound XP in combination with a reserved slots plugins which allowed top-XP users to join a full server really created a tight community of players on my tiny DSL home-hosted server.
[1] https://www.amxmodx.org/compiler.php?mod=1&cat=0&plugin=&aut...
In many ways it remains ahead of the curve. Kids that grow up making games in Roblox rarely survive the jump to a dedicated engine because Roblox is just so much easier to develop for in nearly every aspect. One big thing I've heard is that instantly getting working, robust online multiplayer by default baked into the engine is a major plus.
I would call multiplayer out of the box the defining feature for sure.
It's challenging to get networking right, and the effort required doesn't get all that much smaller just because your game is smaller.
Most engines do come with a networking framework or layer these days but Roblox gets to assume a bunch of things an engine can't, and as such provide a complete solution out of the box.
They originally accomplished this with an interesting approach to netcode you couldn't do today.
Everything was replicated in the client and server. So you could open Cheat Engine, modify your total $$$ on the client, and it would propagate to the server and everyone else playing.
They only fixed this in 2014 with FilteringEnabled/RemoteFunctions but that was opt-in until 2018 and fully rolled out in 2021 (breaking most classic Roblox games). This also made games much harder to develop.
how big was Roblox in 2006?
> In that era, I'd have to download Steam, buy individual games like Counterstrike, and the wackiest thing would be the "surf" gamemode.
You could also play any Source mod. Also WC3 maps were insane at the time.
Roblox was tiny in 2006. I joined in 2008. It was still leading the market.
To give an example, Roblox added user-created cosmetic t-shirts as a way to monetize the platform. Developers immediately scripted their games to recognize special "VIP t-shirts" that would provide in-game benefits. And quickly created idle games called "tycoons" where you could wait 2 hours to accumulate money to buy a fortress, or buy the t-shirt to skip all that.
I don't think there were any modding systems with mtx support.
I disagree with regard to Minecraft (only game I played in that list). I bought the game while it was in alpha and even then the single player experience was outstanding and sucked me in. I still have vivid memories from 15+ years ago. The balance of creativity and survival (and friggen creepers) was perfect.
I dont think I am alone in saying this. IIRC the game was making millions while still in alpha.
Yeah, I think Minecraft definitely still would have been a hit without any modding. Though it might not have become the absolute juggernaut that it is now without it -- it's hard to say for sure.
The other reason being that nobody is asking for The Metaverse, and definitely don’t want to spend huge chunks of cash on a funny hat to wear in order to access it.
Some people are asking for The Metaverse. Currently, the entire VRChat userbase. But you're right that there is not a large population of people willing to throw cash at it outside of a minority of virtual furries
Critically, VRChat works on desktop (though it's an inferior experience), and you can incrementally enhance your experience with it by doing things like webcam face/hand tracking instead of buying an expensive headset.
Examples that demonstrate why lockdown hurts ease-of-use and therefore non-intrinsically hurts community. Meta or Apple may not realize people want on desktop want to use VR software; they may want people to spend more (although a smaller community may generate less overall revenue); they may want people to have the “true” experience (their idea of what the users want, instead of what they actually want); they may not want to spend the budget and expertise to develop webcam face/hand tracking.
If they released a cheap or impressive enough VR headset, I doubt desktop or face-tracking would matter. But I think the next best thing, a decent headset with an open platform that enabled such things, would’ve saved them.
VRChat is also consistently active with people making new worlds/maps, avatars, etc. There also used to be a client modding scene with e.g. melonloader but that got cracked down on around 2022. The "metaverse" however, does it even exist? Is there a vrchat-like, meta-built social vr environment available on quest hardware?
No idea, which is notable because I boot into my Meta Quest 3 most nights for sim racing. You'd think I'd have seen it if they were pushing it.
I am glad they don't, the headset should be a general computing device first and foremost, launching apps you choose to participate in.
It's also very highly customisable without being monetized out the wazoo, allows you to host your own servers, and in general avoids the incredibly bland corporate image that meta projects.
(Meta, I think, fails to understand that the people that most want a virtual space to interact with, to the point of putting up with the limitations of VR tech, mostly want to not look like regular people in that space, because they keep pushing a vision that seems to be a uniform 'normality' even more extreme than the real world)
I think they also would not accept that variability, in both avatars and spaces. Even VRChat developers have struggled with what users do and frankly as a company that makes total sense. It's a wild west which is great for a community, nightmarish for a company with moderation liabilities, copyright concerns etc.
The VRChat community should consider forming and funding an open source group to re-implement the platform as it will eventually get regulated.
For what it's worth I don't use VRChat, I've just been around the internet for long enough to know the pattern.
Yes, while VRChat does a lot of things right, the VRChat company definitely doesn't seem trustworthy in the long run. It's an aggressively walled garden where the company has full control over both content and narrative, and we're starting to see more aggressive pushes for revenue, with the major new features in recent months being subscription-gated or addiction bait (stickers, baubles, random reward boxes, etc). I'd love to see an open, federated VR social environment, but how do you get people to use it? Many VR users aren't technologically savvy at all.
There are currently two much smaller competitors that are perfectly usable but lacking community buy-in. Chillout, which is similar to VRChat, with some improvements the community has wanted for years, but missing some of VRChat's (admittedly excellent) homemade functionality, such as better IK code, better bone dynamics, etc. And Resonite, which is more similar to SecondLife, possessing a cross-world inventory system and in-game content authoring tools.
Probably half the people who grew up with Instagram cat filters are furries now.
I am now instantly reminded of that clip of the cat whose human filter wasn't working. 'I'm not a cat', indeed.
A lot of people seem to be spending huge chunks of cash on enormous monitors, dual monitors, curved monitors, etc., and the appeal of that is mostly that it gets you a little bit closer to wearing a head-mounted display.
Makes sense that a primate with front-facing eyes that is both predator and prey would prefer to look at things at arms length rather than encase their head in a cocoon that is designed to block environmental awareness.
Depends on what you mean with "environmental" awareness. Awareness of reality or virtuality?
That's a function of what software you have running on it.
Monitors load my desk, not my neck.
> I think one of the reasons Vision Pro and metaverse have been struggling is because their engines are bad. Not just locked down, but hard to develop on (although I don't have personal experience, I've heard this about VR in general). If you want to build a community, you must make development easy for hobbyists and small users*. I believe this has held even for the biggest companies, case in point the examples above.
Unity and UE have pretty good VR support nowadays, and even godot is getting there. Plus making a custom engine for VR was never that much harder than for a normal 3D game (well, once some API like OpenXR got normalized).
The big issue with VR right now is that it is more costly to develop for than normal apps and games, while having less user. It makes it a hard sell. For some indie dev, I allow them to profit from a market that is not yet saturated (right now, with no good marketing, you just get buried on steam, any app store, etc). There are many factors that make it more costly, like having to support several mobility and accessibility features for games (for example smooth and jump locomotion, reduce fov when moving the view, etc), that you usually don't have to care for in other plateform. And there is the issue of interactivity. UX (and in many ways UI) is still very far from ideal. Most VR apps and games just try things out, but there is still a world of pattern and good practice to build up. This makes using anything VR often an annoying experience. Especially since some issue can be an absolute no-go for some user. As an example, displaying subtitle in a 6dof environment can be tricky. Some game put it at a fix point of your view, which can cause nausea and readability problem, some move still follows the head/view but with a delay, which reduce nausea issue but can be distracting and also has readability issue (the subs can go out of view).
I think there’s a difference between “indie dev” aka either an experienced SWE trying it or some really motivated person with an established identity, credit card & income stream and a kid/teenager tinkering around.
In a “free for all” setting, anyone (including kids) could potentially learn enough (or even just download pre-made scripts) and try their hand at modding software/games.
In a modern situation with developer registration, etc someone would need some sort of established identity, potentially going through age verification, paying some nominal fee for a license, accepting an EULA and so forth. This is a huge barrier to entry for kids/teenagers just wanting to tweak the game experience for themselves/their friends. I remember my first time trying to install Apache on Windows I guess around 2008-09, and the (very well-made!) install wizard asked me for a domain name. At the time I wasn’t aware of how DNS/etc worked and was scared to continue, thinking I would either take up some other company’s name or not being “allowed” to use a random name I’d pick and get myself/my parents in trouble.
All these “regulated” ecosystems make it scarier for well-meaning but inexperienced devs to get started, while doing little to deter dedicated attackers who know the game and know actual cybercrime enforcement is both lacking and trivial to defeat in any case.
The “free for all” environment made me the developer & sysadmin (or DevOps person as the techbros call it) I am today despite no formal training/education and I am sad to see this opportunity go for the younger generations.
The Vision Pro might be pretty lock down, but making a VR app / game on PCVR or on Pico/Meta headset is pretty "free for all"
Agree! We saw this a lot. Launching with the Quest 3, we were often the first company to do X, Y, Z despite being months after new features had been released in the SDKs because they were poorly documented (and often even conflicting).
Diverging even slightly from the demo use case would quickly feel like Sisyphus; so close, but never succeeding in getting over the hill.
Good for marketing in certain cases (to be the first), but bad for the community of builders
> Not just locked down
The lockdown is a big part of it, though. The industry has cross-platform VR/AR SDKs like OpenXR that Apple refuses to implement. A big reason their platform isn't supported day-and-date with multiplat VR releases is Apple's insistence on reinventing the wheel with every platform they make.
If the rumors of Valve's VR headset being able to run flatscreen games are true, it's more-or-less Game Over for the Vision Pro. The appetite for an iPad-like experience with six DOF is already handled by much cheaper machines.
Many creative people don’t care about being “locked in”, since they already make mods that can be broken by updates (and often are, unintentionally) and threatened legally (for violating IP and DRM). I think the much bigger problem with locked-down engines is simply that the lockdown methods used make it harder to develop on them.
All of those were also all $0–$20. It's kind of a chicken and egg problem to build a user and developer community. Games have to build a strong playerbase with limited content, then enough gamers have to be invested enough to become creators. Enough have to be able to actually pull off the development, yes, but I think the even bigger problem is that they'll never have a reason to with the small number of users inherent with platforms that cost $500–$3500 for special hardware to get onto.
I think Valve wouldn't exist as they do now except for modding. Counter-Strike's popularity must have driven a lot of purchases early on, which allowed Valve the freedom to do things at their own pace rather than under pressure from publishers.
> these are games that succeeded because of their communities
To me an interesting thing when a game succedes despite its community. As if people can endure a lot of toxicity as long as the game is good
Fortnite has been attempting to be a platform rather than a game for years now. (Epic Games Store too, so you ridiculously have to launch one then the other before you can pick your game.)
Curious to know to what degree the "Creative" maps have fueled Fortnite's success as opposed to the 1st and 2nd party developed experiences.
I would throw Rimworld into that list as well. A fine game by itself, if a bit simplistic. But the mods make the game massively customizable and lets the player do basically whatever they want
The Meta Quest is very easy to develop for. There's tons of games of all caliber from solo devs up to full studios. The reason the Metaverse is failing is because no one wants it, even though they keep shoving it down people's throats. VR gamers just want to play games, not dick around in "worlds". Meta is tone deaf to this.
There isn't yet a game that involves all the players in one huge level, without shards, but there might be eventually. Current game engines don't support levels with that many players simultaneously. There is an interview with Neal Stephenson and Tim Sweeney on the Metaverse where Sweeney says supporting massive multiplayer is what he plans for Unreal Engine 6: https://www.matthewball.co/all/sweeneystephenson
> So one of the big efforts that we're making for Unreal Engine 6 is improving the networking model, where we both have servers supporting lots of players, but also the ability to seamlessly move players between servers and to enable all the servers in a data center or in multiple data centers, to talk to each other and coordinate a simulation of the scale of millions or in the future, perhaps even a billion concurrent players. That's got to be one of the goals of the technology. Otherwise, many genres of games just can never exist because the technology isn't there to support them. And further, we've seen massively multiplayer online games that have built parts of this kind of server technology. They've done it by imposing enormous costs on every programmer who writes code for the system. As a programmer you would write your code twice, one version for doing the thing locally when the player's on your server and another for negotiating across the network when the player's on another server. Every interaction in the game devolves into this complicated networking protocol every programmer has to make work. And when they have any bugs, you see item duplication bugs and cheating and all kinds of exploits. Our aim is to build a networking model that retains the really simple Verse programming model that we have in Fortnite today using technology that was made practical in the early 2000's by Simon Marlow, Simon Peyton Jones and others called Software Transactional Memory.
I don't think they're tone deaf, they just know that inexpensive gaming headsets can't make them enough money. They've invested something like $100 billion into VR and "only" sold 20 million headsets The revenue generated annually is almost nothing.
UE5 is decent for vr.
I much prefer just writing stuff for Luanti (formerly minetest).
You can, pretty much, get the Minecraft experience by downloading mods. Or just use the VoxeLibre game mod.
https://content.luanti.org/packages/Wuzzy/mineclone2/
The mods are written in lua and you can find the source code for most of them.
One I like is Zoonami which turns the experience into a Pokemon like game.
https://content.luanti.org/packages/isaiah658/zoonami/
https://github.com/luanti-org/luanti
Zoonami will achieve what Tuxemon didn't.
does something like AllTheMods 10 exist for Luanti? Or Meatballcraft?
The Luanti client lets you search and install mods from content.luanti.org
It differentiates between mods and games. A game changes the core game to be much more different, but sometimes a game is just a collection of some other mods.
https://content.luanti.org/packages/?type=game
Personally, I find it more fun to just go and click on about 6 to 8 mods that are interesting and see how the game goes.
https://content.luanti.org/packages/?type=mod
Some of my picks are...
https://content.luanti.org/packages/ElCeejo/animalia/
https://content.luanti.org/packages/random-wizard/gear_up/
https://content.luanti.org/packages/TenPlus1/farming/
https://content.luanti.org/packages/FreeLikeGNU/goblins/
Even if they made it Source Available it wouldn't hurt them much, because Minecraft is very easy to pirate and the reason anyone pays for anything at all is because you need an account in Mojang's authentication servers (which people do not want to move off of for various reasons).
Hell, they could even make it Open Source with a clause preventing other companies from using to code to make a profit. It's too big to fail.
> Hell, they could even make it Open Source with a clause preventing other companies from using to code to make a profit
Such a clause would immediately make it Source Available not Open Source.
by that logic GPL wouldn’t be open source either since it also adds restrictions unlike the fuck license
nowadays github is filled with so-called open source projects under GPL3 but the maintainers want you to pay for a dual license
Let's look at the OSI definition since that's what people mean by Open Source (particularly when capitalized):
https://opensource.org/osd
> The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
> No Discrimination Against Fields of Endeavor
You cannot restrict selling derivatives of the software (a field of endeaver), and the derived work must be able to be shared under a similar license.
GPL does not add any restrictions counter to that. It allows you to redistribute and sell copies if you want, you just have to respect your user's freedom by also giving them the modified source code.
> But we encourage people to get creative both in Minecraft and with Minecraft – so in 2019 we tried to make this tedious process a little easier by releasing “obfuscation mappings”. These mappings were essentially a long list that allowed people to match the obfuscated terms to un-obfuscated terms. This alleviated the issue a little, as modders didn’t need to puzzle out what everything did, or what it should be called anymore. But why stop there?
Indeed, why did they even bother with this half-measure in the first place?
A lot of mod tooling was built around the obfuscated or community names for those APIs.
I wouldn't worry too much about it breaking anything with how version-specific modding already is. And by the time the full release is out, I'm sure every tool will have updated based on the new names from the snapshots.
Still is for legal reasons. Also the community names (Yarn) come with javadoc that actually explains what the function does
Hyrum's Law
If I had to guess, the legal team's brains started melting when de-obfuscation was mentioned.
If my memory serves, the stated justification for not going open source was copyright and trademark protection. Apparently, that is no longer a concern, if it ever really was.
Now I'm bracing for them to drop support for Java Edition entirely and go strictly Bedrock in a couple of years.
Perhaps Minecraft 2.0 is finally nearing release.
Actually, there was technically a Minecraft 2.0 release, but it was an april fools prank in 2013.
Relevant wiki link: https://minecraft.wiki/w/Java_Edition_2.0
I don't see that happening any time soon. Too many people at Mojang care about the Minecraft Java Edition community too much.
Perhaps it was easier? There were also probably legal reasons.
Were the mappings only a subset of the obfuscated classes/methods/etc? Basically making the mapping a sort of public API
I hope Claude Code follows the same path. It's just wrong to have such a key tool in your development toolchain obfuscated. Changes to CC reflect in the way I work. I've been modding the app for ever now. Something as simple as evalling prompt changes, or finding ways to optimize context. Just make it OSS, like Codex. To add insult to injury, Claude has coined some key industry standards, such as MCP, now Skills. It also supports plugins, inviting others to release their plugins as OSS on Github [1], while their core remains proprietary.
[1] https://www.anthropic.com/news/claude-code-plugins#:~:text=P...
I got my start coding by modding Minecraft - I added a quest system; one day I wanted to add dialogue trees and slowly turn it into a RPG. I hope future generations will always have this wonderful opportunity, this low barrier to entry opportunity to do substantial personal-passion mods.
I'm pretty excited this but for a slightly strange reason. I have a little monitor for the logs that posts things like player joins and deaths to a chat room. It is fun and also encourages people to hop on the server when someone joins.
However the source information was always missing and strange in the logs making matching some messages difficult. Hopefully this will make more messages more unique so that I can easily match the ones I am interested in.
The community obfuscation mappings unrestrictively licensed. The Microsoft ones are not. It's a trap.
But the whole point is there are no more mappings. I’m not sure what the trap is supposed to be?
Your mod uses variable name FooBar in ways Microsoft don't like, Microsoft sues you for copyright
before the judge would have to admit it was just coincident.
They've had plenty of opportunity to do this and haven't, so would find it incredibly unlikely they would magically start to have a problem now
Not to mention doing would basically kill game as one of the biggest reason people even still play Minecraft is the modding scene, not the minimum viable effort that have been the official updates for last number of years.
don't think they could do it previously because the code is not open and any names are a result of deobfuscation so clashes are accidental
I’ll preface this by saying I’m not a lawyer, but let’s say Microsoft released an obfuscated version where the method FooBar is called FakeName instead. If I use FakeName in my mod, aren’t I hypothetically at risk of the same thing? How does the actual name matter for this argument?
Or is the argument that only source code is copyrighted, but not binaries so it only matters if the name matches the original source code? That doesn’t seem possible because it’s copyright infringement to share a retail game binary, so they’re clearly copyrighted as well.
So I’m really unclear how the risk here is any different regardless of obfuscation since the mod needs to use method names from the copyrighted binary either way.
I'm pretty sure if code is obfuscated there are no usable names and so people or deobfuscator comes up with original names.
Wouldn’t the structure of the code be be more copyrightable than the names?
community makes mods, they don't duplicate game code structure, and if they do it's clearly by accident because the code is obfuscated
But the mod relies on the code structure as much as it relies on the names, I think it could still be considered a derivative work, I don’t think this would be copyrightable but I find the code structure being copyrightable more plausible than the names
Does copyright apply to variable names?
Given the Oracle v Google decision, the likely answer is yes. But then there’s a fair use argument to be made.
I was initially a little confused at your comment. I had thought the decision was against Oracle being able to sue for use of the Java API.
Reading a little closer, the decision was that even assuming the API copyright claim was valid, Google's use of the API was fair use.
> In April 2021, the Supreme Court ruled in a 6–2 decision that Google's use of the Java APIs served an organizing function and fell within the four factors of fair use, bypassing the question on the copyrightability of the APIs. The decision reversed the Federal Circuit ruling and remanded the case for further review.
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
I would rather see allowing creators to monetize their Java edition mods again, and to get rid of their restrictive rules on mods. The old version of the EULA actually gave people a lot of freedom, but then they changed the rules on everyone and locked it down. Obfuscation is not a true problem compared to those.
You're always welcome to just ignore the EULA and hope they don't sue you. Which they won't because the costs to them are much greater than the benefits. Even with the monetized server thing, they didn't sue them, but they did create a server address blacklist, but it only contains a minority of monetized servers.
One and only account (Mojang) that I can think of that I lost because it got taken over, and I couldn’t get support to help fix it (something about “go make another Mojang account”?)… and since I don’t really get the migration process they did or final outcome, it’s more of a “oh well losing that sucks”.
This situation was a lot more common than people might think. If you bought the game before Notch introduced the EULA (late 2011 if memory serves), what they did was also probably illegal, since they didn’t have the legal boilerplate in place that would allow them to brick the game the way that they did. There was a streamer trying to start a class action over it a few years ago, but I don’t think anything ever came of it.
What they did was illegal, and you absolutely can (and are encouraged to do so by Microsoft) sue them in small claims court for your Minecraft account back.
> and are encouraged to do so by Microsoft
Source? It seems that if they wanted people to get their lost accounts back, there's more efficient, less expensive ways of doing it?
"Encourage" may be a strong word, but it's specifically outlined in the Microsoft Services Agreement:
> 11. Choice of Law and Place to Resolve Disputes. If you live in (or, if a business, your principal place of business is in) the United States, the laws of the state where you live (or, if a business, where your principal place of business is located) govern all claims, regardless of conflict of laws principles, except that the Federal Arbitration Act governs all provisions relating to arbitration. You and we irrevocably consent to the exclusive jurisdiction and venue of the state or federal courts in King County, Washington, for all disputes arising out of or relating to these Terms or the Services that are not heard in arbitration or small claims court.
https://vulcanocraft-plugin-v3.onrender.com/
Minecraft modding has done so much to get young people into CS. I started learning Java when I was 10 because I wanted to do modding. At university, I met so many people who had the same experience. The tooling developed for Minecraft modding is world-class and better than what is developed during PhDs. It's very advanced, and people internalized the JVM and Java spec. One problem, though, is that Mojang's updates often change much of the foundation, and upgrading mods is very time-intensive. Mojang announced in 2012 that an official modding API is in the works. This is another step.
As I understand it way back in the early Beta days of Minecraft obfuscation was added to avoid mods being embedded into the JAR and it being released as a combination enabling piracy of the game with mods embedded.
This has been a pain to workaround for years as the modding scene has gotten bigger. Hopefully this makes modding a bit more accessible.
Yeah I still remember when you had to manually patch your minecraft.jar with mods. Always remove the META-INF directory so it works. Back then, when you installed two mods that were incompatible with each other, you had to throw away the whole minecraft.jar and start again.
This already changed A LOT when Forge and later Fabric came out, with a simple patch system akin to BepinEx and a mods folder.
The later generation mod loader use preloader and asm hooks though. So the file isn't even physically patched, just patched in memory. That is such an old day that you still need to patch the jar by yourself. (If I am not remembered it incorrectly, I think the community change happens between 1.3 and 1.5?)
You know what would make it even easier? Releasing the source code with a license that allows for modding.
I consider Microsoft to be genuinely evil as an institution, but this is still nice to see.
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.
I fear it's the first step to announcing the discontinuation of Java Edition development.
I don't really think this would be the end of the world, would it? Much of the content they've added over the past few years has been of questionable merit, at least to me. Surely at some point they'll run out of ideas that can reasonably fit inside vanilla Minecraft?
(But no, I don't think they're going to stop JE development. I'd bet it's still the far more popular version, and they probably still make plenty of money from sales)
-Surely at some point they'll run out of ideas that can reasonably fit inside vanilla Minecraft?
Exactly...? How much content is built with Bedrock edition and Marketplace Add-on's?
I'm pretty sure Bedrock Edition is far more popular if you take all platforms into account.
But I agree Java Edition is not ending any time soon.
I have to assume this runs the risk of opening the floodgates for potential vulnerabilities to be discovered now. Hopefully they're prepared to start working on a bunch of new bug reports.
Whether is obfuscated or not. Minecraft java runs most logic in java, and write the save and network handling in parse & validate style instead of serialization/deserialization style. So there isn't much "vulnerabilities" for you though. The game probably isn't best in performance, but there aren't much vulnerabilities either.
Closed-source code isn't that much less secure than open one that I think this is a legitimate worry, especially in this case where the obfuscation doesn't sound like it was effective much
They already released deobfuscation mappings years ago. Modders already have a deep understanding of the Minecraft codebase.
I'd like to see a benchmark between the obfuscated and non obfuscated version.
Probably virtually the same. If I recall, the "obfuscation" was mostly mangling
Luckily I have never had to deal with obfuscation, but from what I have seen there are some grotesque things like defining every single randomly named method call in an array or map with random order or weirdly combining or tearing apart methods.
The only time I encountered it was when I was working for the government, we were working on the rules that decide who gets audited in depth by the tax police. The .jar it compiled to was obfuscated.
My decade-old recollection is also that Minecraft's obfuscation didn't do anything structural, just mangled class and method names. Think of it more like JavaScript minification than a serious attempt to thwart reverse engineering.
Minecraft - like most Java games - just used Proguard. It renames classes/fields/methods and sometimes inlines private methods, but doesn't make any substantial changes to control flow.
I have seen =tons= of obfuscation (non-minecraft). Back in the late 90s it used to be popular, unfortunately.
Most of the stuff is like naming every method a or b, and using the fact they are overloaded, given one-letter-name or a reserved keyword like 'if' to classnames (or packages) was popular, too. Pretty much constant pool modifications w/o too much byte-code-editing.
Overall cheap and unnecessary and has not stopped anyone.
It's still pretty popular. Most large smartphone applications are obfuscated to some degree. At least for Android, because it's bytecode for a VM, it's still trivial to disassemble and understand what is happening at a high level.
For Minecraft it’s just removing names and replacing them with random strings
AFAIK it also shortens the names, which might make the jar smaller or make it take less time to do name resolution at runtime. It probably won't be very relevant though, especially after startup.
The files will be a little smaller obscured but it doesn't usually impact much other than RAM usage. The algorithms are all the same. Given the size of methods for being JIT compiled is token based not text size I don't think it even impacts that choice. So expect it to be identical.
same, except for meta space used - the class/variable names don't have pretty much any meaningful impact on java runtime, when the code is JIT'd. Even before (interpret mode) that the className/fields/methods are just references in the constant pool
I wonder what Minecraft sales are like these days. I'd imagine most of the people who are going to buy it already have. Makes me wonder if they'll ever open the whole thing up.
Just think of the untapped market of fresh 9 year olds who've never seen/played the game before. It's infinite, there will always be more people who have never played Minecraft.
They're playing Roblox and Fortnite these days, both free of course.
Where are you getting that from? Minecraft has been comfortably above 100,000,000 monthly active users since at least 2019. The only comparable figure I can find for Fortnite claims 650,000,000 registered users, which doesn’t seem remotely possible unless at least half of them are bots. 650,000,000 is something like 1/12th of the world’s entire population. The Roblox figures I could find showed just under 400,000,000 MAU in 2024, which also seems completely beyond the pale.
So anyone who reports higher numbers than Minecraft is lying, but Minecraft's numbers are all accurate? You have literally just invented a conspiracy theory to affirm your biases around this matter.
Also note that monthly active users for Roblox and Fortnite equate to monthly revenue, whereas I doubt there are as many people buying Minecraft in-app purchases.
> So anyone who reports higher numbers than Minecraft is lying, but Minecraft's numbers are all accurate?
Minecraft has made press releases detailing active player counts (“Up to”139,000,000 MAU in 2021). See here:
https://web.archive.org/web/20210809155838/https://news.xbox...
This does claim that 238,000,000 copies have been sold but that there are 400,000,000 registered Minecraft players in China (this would be about 1/3rd of the population so I think it’s probably a typo).
Epic is privately held so I suspect they wouldn’t bother reporting official player counts. Roblox actually does have numbers listed in their annual report, it just wasn’t showing up when I Googled it: 3.6 billion in revenue and 82.9 million daily active users. So that would put it within the wheelhouse of Minecraft’s playerbase, but still about 20,000,000 short.
It may well be that all the kids are playing it over Minecraft, though, since the document I linked above claims the average Minecraft player in North America and Europe is 27. I have no idea what those numbers look like for Roblox but from what I understand the playerbase has always skewed substantially towards minors.
> You have literally just invented a conspiracy theory to affirm your biases around this matter.
This was incredibly abrasive.
You can't compare daily and monthly active users. Monthly active users are can be many times higher than daily. Also, the numbers you are using for Roblox are two years out of date. Current DAU for Roblux is 150M [1].
> This was incredibly abrasive.
I reserve the right to be abrasive when people randomly decide to spread baseless claims.
[1] https://s27.q4cdn.com/984876518/files/doc_financials/2025/q3...
Asking from a place of sincere ignorance: TFA says the code was obfuscated from the beginning, and that they deliberately kept it obfuscated all these years, and acknowleded the huge community that built mods for Minecraft in spite of it. But what TFA doesn't say:
Why did they keep it obfuscated for so long even after it became readily apparent that almost everyone buys Minecraft to (eventually) play the mods?
Why did they keep it obfuscated even though they acknowledged it didn't really stop modders (or anyone else) from understanding the program?
What occurred recently that caused them to change their mind?
"It does have some technical benefits for us, but it is a symbol that this game is not open source. You still can't publish the maps or the code decompiled, even using the maps."
https://twitter.com/Dinnerbone/status/1169242801508376582
Does removing obfuscation implies any performance speed-up for Minecraft Java, or were the obfuscations done in Java with zero-cost?
The obfuscation in question was just name mangling, so it was probably ~zero-cost. Possibly slightly negative cost, depending on the relative verbosity of method names.
Ha, this explains then why MSFT dropped 4% after hours!
might be another issue: the azure outage
On the one hand, great; should hopefully mean the monkey-patching by mods isn't quite as fragile as it is once you get into a decent number of installed mods.
On the other, I'd assume this means that any official modding support is now stone dead and will never happen.
I haven't played minecraft in a fair while, but started with the alpha builds back when the Seecret updates were the most exciting thing going for the game.
> I'd assume this means that any official modding support is now stone dead and will never happen.
I was a bit surprised to read this because talk of modding support had been on the radar since notch days, it's wild to me that this hasn't happened yet.
I suspect Minecraft was large enough to support an effective modding community from the start regardless of official support, so that there was always some kind of third-party unofficial mechanism (ModLoader, then Forge, then now Fabric and Quilt). Mojang probably punted it down the priority list because of that, or didn't want to impose a structure and kill those ecosystems. Technically speaking, Java is reasonably easy to plug stuff into at runtime, so that was never a barrier.
The original issue with official modding support, from my perspective, has always been a legal one. But the Mojang EULA explicitly allows modding now. So I would see this decision as one in a long line of decisions by Mojang to both normalise the legal relationship with modders, and beyond that giving a "thumbs up" to the community.
It's been dead already. There's datapacks but it's been pretty obvious they're not going to make an official modding API. I think they realised that the community modloaders are already really good.
So instead they have been structuring the code in ways that help mod development, and have been talking directly to the devs of mods and mod loaders to try and reduce friction with Minecraft updates.
Hope the rename would not cause unintentional file deletion accident like Japan one. https://news.ycombinator.com/item?id=29734021
Proguard obfuscation, particularly when you get to aggressive renaming (there are a lot of valid characters for a java class or method), flattening, overloading and inlining, can make it very hard to understand what is actually happening.
Its great to make this step.
minecraft had none of these, it only had clean and predictable name obfuscation.
Super interesting to know. I wonder why they bothered!
Thanks for the info.
One of my favorite mods ever across any game is Create for Minecraft. It is well-made and polished, and sparked a whole ecosystem of mods that work with it. I wonder what possibilities the de-obfuscation can bring to that ecosystem.
Maybe they should open source the loader instead of offering a solution to already solved problems so people don't have to resort to using third party loaders for on-prem gaming.
The game is still a licensed game though. You technically must pay it and go though proper verification to start the game. (Although it's a 100% public secret that how to load it as you want, and basically every single mod dev kit does that for local dev)
I guess Microsoft won't want to deal with the license issue of publishing the loader part.
I doubt they care about this or that license. They just want people to upgrade.
Good move. Makes modding easier for everyone.
Maybe they'll publish javadoc jars down the line !
For those in the modding scene, what difference, if any, will this make? Will this enable anything that was previously not possible?
Main difference for NeoForge developers will be method parameter names in the IDE, the current mapping doesn't include those. We have community mappings (Parchment) for common methods, but there are a lot of less used functions that just have decompiler names. I don't use Fabric so I'm not sure how it will affect those devs.
At a guess, it will enable quicker updates on major revisions, where things move around a lot. There will be less reverse-engineering needed.
They were already releasing official mappings.
It's possible that the de-obfuscated symbols will be more backwards-compatible, since they don't need to change with every minor release. Though I'd imagined Forge and Fabric were supposed to provide a stable platform, yet plugins for those still need a different jar for every minor version.
Should make it easy to have mods running on latest releases.
But the only version that matters is 1.20.1!
In reality, Minecraft gets less Minecrafty in every update, and your baseline is whenever you bought it.
I bought the game after they added fences and fishing rods and before the Nether. The nether ruined the game, beds ruined the game, hunger ruined the game, potions, enchantments, villager trading, and hoppers ruined the game, but redstone and minecarts and dungeons didn't ruin the game because those were added before I bought it, see? If you bought it today, you wouldn't think hunger ruined the game, you'd rather think I took away a good feature if I showed you a version without hunger.
I'm not opposed to changes, but every official change Minecraft makes, narrows the design space for mods. Forestry added bees, then Mojang added its own bees which where quite different, and now Forestry's bees look more than a little odd. Sheep used to not drop meat, the witchery mod added mutton as a drop if you killed a sheep in werewolf form, and some mechanics around that. They now would look a little odd. Chocolatey added a ton of structures, among them pigmen cities, now pigmen have been rebranded as piglins and also have their bastions, which are quite different from Choco's cities. Are they better, worse? Who knows? To me what matters more is that they probably wouldn't have been made today. Mojang canonized one thing in that space.
But a lot of things Mojang has added, if they had been mods some random developer made, we probably wouldn't have been putting in our modpacks. A new tier of armor, which requires a tedious grind in the nether to get? That's like baby's first mod. Happy ghasts? Pretty fun, and impressive that you can stand on them, but like the morph mod, kinda ridiculous and definitively doesn't belong in every pack. Eventually, if they keep doing it like this, Minecraft will be as ridiculous as the old kitchen sink modpacks.
This is also true, and also why I want it to be a relatively unopinionated base engine. Unfortunately technical advancements came alongside opinionated content. 1.8 brought creative mode and fast/tintable skylight updates - and hunger and very griefy endermen and a bucnh of worldgen structures. 1.0 brought itemstack NBT - to support enchantments and potions - and gave a sandbox game an official end. 1.3 brought client/server unification allowing singleplayer commands, open to LAN, greater mod compatibility, latency in singleplayer (maybe not actually good) - and villagers and villager trading and emeralds. 1.4 brought command blocks - and local difficulty and armoured mobs and withers. 1.5 brought analog redstone - and hoppers. I think 1.7 was only upsides though - texture atlasing and a new less-broken terrain pattern. That's where I stopped.
All of those things seem like upsides to me!
And for what it's worth, I think I've visited The End once? What makes it a sandbox is that you can play however you want - let The End be your goal, if you'd like, or just mine and build big castles, or mess around in Creative mode. That's the brilliance of it.
When you're engaging in game design, you usually want to make a coherent sandbox. If the best way to produce electricity in your electricity mod is to enslave an army of witches to throw healing potions at each other, it's probably not your design intention. You probably wanted it to involve digging for coal, or solar panels.
In current Minecraft a lot of resources are renewable via villager trading. The best way to get many resources is to enslave some villagers and find a trading loop that nets a profit in emeralds on each cycle, then spend some of that profit on the thing you want. If you want the player to dig up coal to make electricity, they can make a trading hall or a wither skeleton farm instead. If you want the player to dig up iron to expand their factory they'll make an iron golem farm which produces it at a high rate for free. The section of the design space that you wanted to access is blocked off by the mechanics of the base game.
Or maybe they just wanted to mix fantasy and tech?
Or maybe it wasn't intentional, but emergent... sort of like, you know, playing in a sandbox?
Villager trading is another new(ish) mechanic I don't partake in. I know others who don't either. I don't think we're playing the game wrong.
And if a mod/pack developer doesn't want players to use vanilla mechanics, they can disable those, as many, many developers do.
It's not that simple in practice.
What isn't? Disabling Vanilla mechanics? Specifically which of those you mentioned aren't easily disabled with a data pack or simple mod?
One reason is that all the other mods you wanted to use were redesigned to match the vanilla mechanics, so even if you use another mod to disable the vanilla mechanics, you're still suffering their consequences. They may even be redesigned in ways that require the vanilla mechanics.
You can't just remove the fields for a mob's armour items because all the mods that interact with mobs are checking what armour they have, and you'll get a runtime linking error. Best you can do is remove the code that spawns mobs with random armour so they always spawn without armour. There may still be armoured mobs spawned by mods.
In automation mods there was a concept called "sided inventory" where a machine block presents a different part of its inventory depending on which side of the block you access it from. When hoppers were added to the base game, they copied this exactly, but changed which sides accessed which part of which blocks to make them compatible with hoppers, because hoppers can only take items out of the bottom and put items into the top and sides. This affected all automation mods which, instead of using a more intuitive side mapping, use a mapping that makes sense for hoppers. Also, all other mods that add machine blocks now specify side mappings that make sense for hoppers.
Of course in principle you can rewrite the game and all your mods from scratch to match whatever vision you have, but I hope it's obvious that nobody would actually do that.
Even removing a single block or item is nontrivial. You can't remove the field because you'll get runtime linking errors from mods. You can't make it null. Even mods that don't rely on that item may be checking if a player is using it for some feature (and you'd like that check to always be false). There's a good chance many of the mods you want use it in recipes because it's available. Best you can do is remove the ways to obtain/create the item, and add a bunch of recipe overrides so it's not used in recipes either. If you have the mod that shows you a list of every item in the game, it'll still show up there.
None of this is my experience.
After 15 years of playing, it still feels very much like a wonderful sandbox, which I regularly modify however I want, with very rarely any issues, including some of the exact things you've mentioned.
And thankfully, the modding scene is as vibrant as ever!
I do remember your microblocks mod.
Yeah, 1.7.10 is many modders' favorite, I know. If you did stop at 1.7.10, I guess you know about the GTNH people's crazy work in keeping that version running? For a while, you could 1.7.10 with a newer version of Java than the current latest version.
Yes and it is currently running on my computer and logged into a public server.
I bought it like, 15 years ago, and have enjoyed most updates, though certainly not all. I would not say anything "ruined" the game; I was just making a joke about which versions mod developers support
I think you typoed 1.7.10
I think you typed b1.7.3
Speak for yourself, Create supports 1.21.1 (neoforge) which is what my bloated and fragile mess of a mod pack is built on.
1.2.5, the modding golden age (probably because of nostalgia)
Could just go find the Infiniminer source code if you really wanted to have seen it before now.
These are definitely good news!!!
We paid for minecraft java edition and have no desire to use the online features.
Microsoft logs us out every damn time we close the software, which means my grade schoolers have my (now guessable) MS account password (and I scorch-earthed the account, because this is so dumb I won’t trust or use their crap moving forward).
Has anyone figured out how to pirate the binaries? I’d like to remove the yellow sticky note with the password from my monitor.
Use an alternate launcher, like MultiMC, and if you're not using the online features anyway, you can just "Launch in Offline Mode", which will just be unable to authenticate with legitimate servers.
You'd still need to log in to update the game (I think), but for your purposes it'd probably work pretty well.
This is surprising. Perhaps the Minecraft devs and community are dedicated and capable enough to prevent it from being enshittified by Microsoft. It might even be open-sourced someday.
[dead]
[dead]
[flagged]
[flagged]
"Minecraft: Java Edition" has been obfuscated since the release. < Classic Microsoft move.
No, It was obfuscated since around 1.8 when you (Microsoft) buy up Mojang Studios. before that? meh, It wasn't. That's the main reason why JE has broader mod ecosystem from the start., result being 1.7.2 being the one of the most active modded versions since most of them can't get passed to around 1.8.
The motive behind this is probably due to them finding out people can not get their mods/server software updated in-time (due to extra work required) and this leading people being really reluctant to update their versions.
I learned to code by modding Minecraft, starting at ~1.6 a few years before the Microsoft acquisition.
It was definitely already obfuscated by then, the Microsoft acquisition had nothing to do with it.
If anything, looking back all the years, Microsoft has largely delivered on the promise to not fuck up the game and its community. They’ve mostly kept their hands off it, besides the Microsoft account stuff (which makes sense why they did it, but a lot of people are still understandably annoyed). Hell, they’ve kept up two separate codebases in fairly close feature parity for _years_. I doubt they’d have kept JE if there weren’t people in that team who genuinely cared.
Minecraft has been obfuscate since the start. Even 1.7 is still obfuscated.
> No, It was obfuscated since around 1.8 when you (Microsoft) buy up Mojang Studios. before that? meh, It wasn't.
Huh? This is not true. The very first version released in 2009 was obfuscated with ProGuard, the same obfuscator used today.
The reason Minecraft 1.7 was a popular version for modding was because Forge was taking too long to come out, and the block model system was changed in a fundamental way in the next update. Has nothing to do with obfuscation.
> The motive behind this is probably due to them finding out people can not get their mods/server software updated in-time (due to extra work required) and this leading people being really reluctant to update their versions.
Not really accurate. The Minecraft modding and custom server software ecosystem has more agility right now than it ever had in the past. In the past 5 years, a remarkable shift has occurred: people have actually started updating their game & targeting the latest version. Minecraft 1.21 has the highest number of mods in the history of the game.
1.7.10 is definitely obfuscated, and 1.7 had one of the longest "lifespans" of a Minecraft version.
The best thing to happen to Minecraft is 1.7.10 backporting; the second best thing has been breaking the Forge monopoly on modding.
(The code quality of mods back in the 1.7 days ranges from "pretty decent" to "absolutely horrendous" mind you.)
This is deliberate misinformation.
You can easily see that versions prior to Beta 1.8 were obfuscated just by downloading the .jar for the older versions on minecraft.wiki.
You can even view some of the old MCP mappings here: https://archive.org/details/minecraftcoderpack
> This is deliberate misinformation.
It’s disinformation if it’s deliberate.
Heard "AI" can de-obfuscate very easily web javascript.
Probably the same with java. No point doing so with our beyond fast and powerful computers.