You don't seem to understand or have experience with how game code is written.
It's not written to be "modified". It's not written with a specific modular outcome in mind. It's more often than not a one-off messy code that gets the job done, because that's the requirements and the pace of the industry.
And, especially for something like Minecraft, it has to be original and even explore the problem space and ideas in the process of building it. It's not something you do based on a design carved in stone, with some cushy strict waterfall method or what have you.
Building games, and especially such games, is an explorative process, and one-off process, and a war on many fronts (e.g with time, or with tons of competing gameplay ideas).
You are only able to say what you say, because you look at the code in hindsight.
I guess it's a balance between over and under-engineering. The thing is, more often that not the person coming along to do 'external modifications' to that code is actually you, a few months after you wrote it.
You can adopt some good coding practices that ensure that the code isn't a spaghetti mess that's hard to understand when you come back and look at it. That's different than designing a system to be pluggable from the start.
So, I haven't watched any of Notch's livecoding videos, but for those who have, what kind of bad is the code? Is it bad "this is a mess and I won't remember what these variables do in 3 months" or is it just simply designed to handle the most immediate case (coded well but not with plugins in mind)?
As you build and explore, you find patterns, see repetitive code, or get frustrated at the hassle it takes to add a new feature.
This is when you refactor. It's that moment of realization when coding and you say to yourself "ah, if I had a compositional object model instead of a god object inheritance nightmare I could introduce new objects so much faster and without destroying the interface of CEntity."
You quickly also realize this means re-writing your inheritance tree, decomposing all of your object classes and reconstructing each one as a bundle of components like renderable, effects, behavior, physical (position), that communicate and interact through messages.
You finally have the flexible buildable adaptable object system to meet your building and maintenance needs. But you had to rewrite 30 classes to get there.
My take is badasses in that moment take the 20 hours and do it right. Many like Notch simply didn't bother. Everyone pays for it later.
"But it's not necessary" they say. What's necessary about being great? Nothing, but being great is Awesome. That said, one would need that attitude to bite into 20 hours of extra unnecessary work with a smile. But it's the starting recipe for a great programmer.
>What's necessary about being great? Nothing, but being great is Awesome.
Not really. It's rather pointless, time consuming, and often deleterious to one's work/life balance. Not to mention it can mean that the end result might never ship at all, in an endless pursuit of "greatness".
Sure. My whole point is you have to believe its the right thing, and be good enough to execute on a large refactor like that without getting stuck in the never-ship mud, or endless pursuits.
Being great is overcoming the reasons you are giving not to do it. Being great is having the vision to see how these decisiosn impacts your ability to deliver in the future.
Being great isn't necessary. And you've pointed that out. Your attitude ensures that the code you write meets your standards. Your standards, aren't "great."
While Minecraft was never originally designed to be modified by outsiders, unlike most games it was also never just intended to be a one-off release that would ship and that would be it either. From the start, it was always advertised as something that would get substantial new features and improvements over the years.
It's not written to be "modified". It's not written with a specific modular outcome in mind. It's more often than not a one-off messy code that gets the job done, because that's the requirements and the pace of the industry.
And, especially for something like Minecraft, it has to be original and even explore the problem space and ideas in the process of building it. It's not something you do based on a design carved in stone, with some cushy strict waterfall method or what have you.
Building games, and especially such games, is an explorative process, and one-off process, and a war on many fronts (e.g with time, or with tons of competing gameplay ideas).
You are only able to say what you say, because you look at the code in hindsight.