Minecraft Forums

I won't criticize, just offer some advice as a fellow software developer:

Minecraft clearly suffers from a lot of regression bugs, much more than non-regressions. The sheer volume of functionality in the game, its gradual evolution, and its growing team of developers are all factors that make the code prone to this. In my experience, this only gets worse without a change in process. Eventually you will be spending all your time fixing bugs and everyone will be afraid to touch the code.

Automated testing is the ideal way to prevent regressions. Admittedly, testing realtime simulations is particularly tricky, as is adding tests this late in the project lifecycle, but it's doable. If you can spare the resources, you might dedicate a developer to creating a framework to instrument the game for tests. You could even spin something like that into a side product or an open source project.

A less ideal but much better than nothing solution is manual regression testing. Have dedicated QA people run through a list of manual tests on every release. Whenever you add a feature or fix a bug, add appropriate items to the list. It's tedious work so be real nice to these people.

As well, you should certainly be doing general QA on the game now that its in beta. Users who are playing the game for fun won't find and/or report all the bugs. You need dedicated people hammering on every piece of code trying to break it or tons of minor bugs will pass under the radar.

Apologies if I'm stating the obvious. I don't mean to be patronizing, but nothing seems to universal in the software industry.

Good luck and here's looking forward to 1.0!

BTW anybody found a good way to collect saplings since the halloween update? They seem to be pretty scarce now.

Example of the "push up" phenomenon:



At least, I'm guessing that's what happened here. It could just be a tall tree. But I'm nearly certain that you get a lot more giant trees when they are packed close together.

I make tree farms in a grid of 3x3 squares (so 2 squares between each tree) and they all grow fine. In fact, the ones that grow later seem to get pushed up higher by the ones already there and are more likely to be "jumbo" trees with branches.

http://extension.ws/minecraft/mobber.png

Light the two netherstone blocks on fire and put blocks above the flames. Build the rest of the room at least three blocks high. The water will push mobs into the fire and kill them pretty fast, without destroying their item drops.

I'm not concerned about realism per se, but certainly MC could use more variety underground. Homogenously distributed resources and random maccaroni caves get dull pretty fast. Some sort of "geology" system to make interesting formations underground and concentrate resources in logical places would be great, even if it didn't resemble reality much. The overworld is basically just Perlin noise but turns out to be pretty convincing.

Quote from Palidin »

Thirdly, what would look like an elevator in your diagram would be quite incompatible with the current game code i assume, unless they are an entity rather than a block.

The key feature that would have to be added to the engine is "voxel entities" i.e. multiple block grids with arbitrary translations. Since they could get quite large, they would most likely require more advanced space partitioning than what is in the code now. But it can certainly be done.

I know the idea of machinery has come up before, but the past proposals that I've seen have been overly complicated and not very well fleshed out. I wanted to come up with a system that follows some basic principles:

[*:213eu8q6]Allows elaborate machines to be built by the player, from very simple components. Minecraft is a sandbox game. It's fun because you can shape the world with your imagination, out of blocks of raw material. A machinery system should be equally basic, versatile, and limitless.
[*:213eu8q6]Technically feasible without tearing the code apart. I don't know exactly how the Minecraft engine works, but I can use my ~20 years of programming experience to make a pretty good guess, and to design a machinery system that can probably be implemented without rewriting the game from scratch.
[*:213eu8q6]Integrates with existing game mechanics, rather than bolting on an entirely new game. Machinery should play a part in the things you already do in the game: exploring, mining, building, fighting, etc.
[*:213eu8q6]Behaves intuitively, so the player can easily grasp it and believe in it. There shouldn't be any arbitrary magic that can only be learned from huge wiki pages, as with e.g. redstone torches.

With those points in mind, this is what I came up with.

Motion

The first component is something that is already in the game: a bar (or pole/stick/rod/whatever). The existing bar is made of wood, but you would probably want to add metal bars too. Bars would become blocks that can be placed in the world. They automatically orient themselves to line up with any adjacent bars. They look something like this (the cube outlines are just for illustrative purposes):



A bar is not very useful on its own. What you would need next is a "nut" block, which is a block with a hole through it. A nut can be placed like any other block, but it can also be placed on a bar. A nut placed on a bar can move freely along the bar. You can attach other blocks to the nut block to create an entire moving structure.



Nuts have a fixed orientation (they don't spin) and they can only move along one axis. However, bar-nut assemblies can be built *on* moving structures, thus allowing compound, multi-axis motion.

Moving structures collide with mobs, and with other blocks. Moving structures are affected by the same basic forces as mobs e.g. gravity, water currents, and pushing from other moving objects. A player/mob standing on a moving structure moves with it. A moving structure has a calculated mass (based on the quantity and type of blocks attached) which is used to approximately simulate inertia, friction and restitution.

A nut can't slide off the end of a bar and a bar block can't be destroyed when part of a nut is covering it. A nut can only be removed from a bar by destroying it, which raises the issue of blocks that are attached to the nut when it is destroyed. Also, it should probably not be allowed to have floating blocks in a moving structure as that could get very confusing. There are a few potential options to handle these cases:

[*:213eu8q6]Instantly destroy any blocks that become disconnected
[*:213eu8q6]Make blocks indestructible if they are holding the structure together
[*:213eu8q6]"Snap" disconnected blocks to the parent grid (weird, but could be useful for relocating large structures)

Sliding block structures are the fundamental way that the machinery system interacts with the rest of the game world. It's the simplest kind of motion with which you can build a decent amount of things: elevators, doors, drawbridges, pressure switches, traps, canons, and so on.

This is probably also the most difficult part to implement, particularly the block-block collision. I'm hoping that the single-axis, fixed-path movement constraint will allow for simplifications and optimizations.


Connectors

Connectors are entities rather than blocks. They are placed by right clicking on two different block faces in sequence, thus attaching one end of the connector to each face. If those two blocks can move relative to each other, the connector constrains their position in some way, specifically:

Rod - keeps the two blocks at a fixed distance

Spring - like the rod but has some elasticity in both directions

Chain - limits the maximum distance between the blocks



When placing connectors, the second click can be held down and the mouse dragged to change the length of the connector.

Connectors can be in any position or orientation, as compelled by their attached blocks. They don't collide with anything, they only affect the two blocks they are connected to (unless someone really wants to implement that).


Wheels

Another fundamental component is the wheel. It can be placed on a bar, like so:



Wheels are (effectively) one meter thick and can only be placed on a bar block. They are always axis aligned and have a fixed position and collision hull. A wheel can rotate freely about the axis of the bar and its rotary angle is part of its dynamic state. Multiple wheels placed on the same bar all share the same angle.

A single wheel is one meter in diameter. However, placing another wheel on an already placed wheel increases the diameter by one meter. By placing multiple wheel "units" on the same spot, arbitrarily large wheels can be created.



Two wheels with one meter or less between their edges will be locked in counter-rotation at speeds proportional to their sizes i.e. they act like engaged gears. This works even if the wheels are at right angles to each other, or if they are attached to seperate sliding structures (the latter detail is important for making mechanical switches).

Chains can be wrapped around wheels to create belts and pulleys (haven't yet worked out the UI for this).



Wheels have 24 attachment points on each side, around their circumference (perhaps less or more for different size wheels). Connectors (rods, springs, chains) can be attached to these points in the same way they are attached to block faces. The attachment point is offset one meter from the plane of the wheel, on the respective side.




Other Parts

Screw - works like the bar block but moves any attached nuts when it turns

Drill/Ram - Some rotating/pounding attachment that can mine blocks or hurt mobs.


Generating Power

A small wheel can be manually cranked by the player, with a limited amount of force, by right clicking on it and circling around with the mouse.

Players will want to make water wheels. They could just be plain wheels or maybe they are crafted from wheels. Some change to water mechanics would also be good so there aren't just portable sources of infinite power all over the place. Springs and waterfalls should be scarce and difficult to move.

Windmills would be great if they were affected by terrain and biomes. Finding/building an optimal place for them would be an interesting challenge.

Ideally, there wouldn't be any canned power generating items. Rather, there would be raw forces of nature -- sun, wind, gravity, geothermal, fossil fuels, etc -- and the player would have to invent machines to harness power from them. Without rotating structures, those machines will have to be fairly unconventional, but if the physics engine is generous enough, I'm sure it can and will be done.


Conclusion

If you think the game is addictive now, just wait until you can build mining machines, caves full of booby traps, monorails, transforming fortresses, and other insanely awesome stuff. If Minecraft today is like LEGO then this would be LEGO Mindstorms. I'm pretty sure I would DIE of fun if this idea were implemented. So please implement it. Thank you

It seems you can work around this by disconnecting from the net and then running the game. It will detect that you are offline and offer to skip the login.