that’s exactly my thought. also: if you could connect BC waterproof pipes directly with a generator you could create very efficient watermill-generator-blocks or geothermal-powerplants in the nether by pumping lava from the ocean and store the energy in lapotron crystals or lava in cells. doing something similiar today requieres a lot of manual labour.

Did i mention i’Ve gotten access to the SMNC beta? 😛

I agree with you completely. Really, there’s nothing more to say there :). The initial approach to MC made it possible, but it has to change soon if MC is going to be anything near maintainable or extendable.

But I think the frequent new features are what keeps MC alive at the moment. I don’t think masses’ attention spans can outlive an exclusive rewrite from scratch or a major refactoring; that’s why Notch has to keep coming up with new features and someone has to keep implementing them to try them out.

Honestly, in Notch’s case, I think he started out Minecraft the right way: throw features at it, see what works, see what doesn’t. However, as a solo coder, you don’t have much motivation to clean up your code, just like many people don’t like cleaning their rooms. You remember where you put everything last, why organize it?

Then he started getting cash and hiring more dudes. At this point, also legit to keep throwing new features in, since the game is still half-baked. However, some time should’ve been spent towards code quality, not code quantity. Towards the end (I’m thinking 1.6, maybe 1.7), some dedicated resources should’ve been allocated to looking at old abstractions and doing hard, tedious, painful refactors of large chunks of code, so that they would be cleaner and more organized for the future. Working at a company where this has had to happen repeatedly, I can tell you it is *well* worth it, but you have to have the programming cajones to push through and actually finish. You can’t ‘halfway’ fix things, that seriously just leaves them more broken than before.

On a side note, I think the ‘magic numbers’ floating around might be due to the fact that javac optimizes out final constants and just writes their value all over the place. It definitely does constant folding and dead code elimination, so I wouldn’t be surprised if it did that as well.

The problem with *Java* is that you can get away with writing *terrible* code, and code that might be good but performs *terribly*, and still get by. Other languages that don’t hold your hand as much get two advantages over Java: a) better compilers to machine code (the JVM does JIT, and does it well, but it’s not the same), and b) because you’re forced to think about more ‘machine specific’ things, like memory in the C/C++, you sorta think about performance more overall anyway. It is, for lack of a better way of saying it, harder to write poorly performant code in C/C++ that also does the job you want it to do.

Frankly, I’m amazed at how performant minecraft is overall, given that it’s written in Java and how horrendous the code looks (I’ve taken a look at it a couple of times, I shudder just remembering it).

Like Robots, Laser cannons, and other over the top devices is nice and dandy but i feel like allot of mods are avoiding Cars/Tanks/Planes/Motorized Boats, which would be awesome and I can think of an awesome way to make a car from using elements of each part of technic pack.

Biofuel or Liquid Fuel as a Combustable Agent
IC2 Generator to move the car or (Engine)
Container in rear for storage/.

The code quality sadly reflects MC’s humble beginnings. Notch is an excellent game designer, IMO, but if MC’s code quality reflects his top coding skills, he’s not such a good coder. Note how reluctant I was to make the second point; various factors impose lots of limits on a coder, and dare I say, every coder I know writes code that is below their standards.

I agree with you on that MC’s code is a mess. This may be a decompiler artifact, but I see a lot of magic numbers flying around. Many aspects of the game are hard-coded, and I see a tendency for favoring quick fixes that save the day rather than deep changes that save more time in the long run. For example, the lighting code has leaf- and stairs-specific portions, and the rendering code makes exceptions for grassy dirt.

I’ll explain the problem briefly for non-programmers. Imaging you have lighting working for fully transparent or fully opaque blocks, which is all you have. Now imagine you want to add leaves, which are semi-transparent. You have two options: either add exceptional cases to the code to handle the “transparent, but not fully” case for leaves, or implement a whole subsystem to support semi-transparency. The latter is harder and more time-consuming to design and to code because it is more general. However, it saves time in the long run if you are going to add other semi-transparent blocks. With the former solution, you’d have to add more exceptions every time you wanted a new semi-transparent block. You’d also have lighting code that mentions grass, and soon a tangled mess of interlocking systems.

Minecraft has opted for the former, quicker solution and now we have lighting bugs with the stairs. Should they keep on doing this, soon the development speed will grind to a standstill, and they’ll be introducing more bugs with every code change. I don’t even think any kind of helpful modding API is possible with the code as it currently is. It needs major refactoring.

I’d like to think they’ll hire a new team to write the whole code from scratch while the current one keeps experimenting with new features, but I’m too experienced to be an optimist.

Another option is spending more time than needed on bugfixes and slowly refactoring the messy code into maintainable modules and subsystems as they go. If anyone is following the recent changes in code, I’d like to know if they’ve already started doing this.