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.

These all seem like issues that are obvious in hindsight but may not have been obvious at the time. It's much easier to look at an existing, established codebase and point out all the flaws that it is to anticipate all the future challenges. In other words, you're monday-morning quarterbacking.

Maybe Notch didn't start building it with the idea that anyone would want to mod it. Heck, maybe he didn't even anticipate that it would be popular enough to require great performance. If he expected the game to be played primarily by him and a few friends then he could forego performance for beefier machines.

If he started out trying to build a game that would need to be extremely easy to mod and be performant on millions of machines of varying performance capabilities, he probably wouldn't have gotten around to actually writing it in the first place. It's called over-engineering, and it kills more projects than anything else, IMO.

Definitely the case. The great programmer, the moment they realize that modding is the future, make their next release to get the modding interface done right. They don't decide "eh, I'll just add a bunch of items I've been thinking about instead."

Was minecraft supposed to be modable from day 1? I know from my own experience that if you design a large monolithic application and then decide afterwards that you want a pluggable system, it's never easy if you don't have time to refactor the whole thing.

Also network programming and game/graphics programming are different disciplines with their own challenges. Big studios might assign different people to these tasks, so I wouldn't expect somebody to be amazing at both.

No, it wasn’t written that way at all. Notch never intended it to be moddable and he had no idea at all that modding would be such a big deal for Minecraft. In the very beginning Notch was even (slightly) opposed to modding. I think it was more like a gut reaction: People are doing things with my stuff I didn’t expect and I don’t like it. (Not that he ever even began to consider taking legal steps against it or something awful like that.)

He came around to it, though. By the time he handed Minecraft off he was fully in the “modding is great for Minecraft” camp. But the game was never developed for that. A real modding API has been in the works for quite some time now, but it seems to be quite hard to pull that off.

Could you provide more specific examples and possibly detail how you would do it better? If Notch is making these errors you speak of, other programmers probably are too. You've got the perfect platform here to correct the problem.

It's very simple:

-Don't make up things where existing tech would do (ala NBT, entity metadata, etc)

-Don't use a signed number if negative values don't make sense in that context

-Include versioning if something needs to work across versions

-Choose consistent scemantics for data encoding (and anything else you can)

All of this will make it easier for you, too. Focus on reducing internal code reuse, maximizing external code reuse, and simplifying things.