Yeah, I think with Minecraft's basic mechanics, massive moving objects would be quite difficult. There would have to be so much updating of things going on. Sometimes I think it would be nice if some built structures were randomly distributed on the map, far away though, so you really had to go search for them. That would be difficult/impossible to do so it's not almost always the same structures and working with the "random" terrain generator though. Might just have to play MP for that.
i'm kind of hoping he gives us differant colored glass, be nice to get a stain glass window sort of thing
Yeah, using dyes to color wood or glass would be great. Also random ruins scattered around the landscape (with spawners and treasure chests) as well as additional rare plants. Give players a more incentive to go out and explore their world.
Does the game have some way to fly? What about having balloons. As long as you hold onto them you can float. To make them you'd need a rubber material, which would have many other uses, such as the ability to make bouncy castles.
Unfortunately, no. There are no flying vehicles. You can make cannons, though, to launch yourself over a distance.
On the moving of built things like a ship. I don't think that would be possible due to how the game is made. (I'm gonna be making assumptions again^^). I assume that the world works as blocks, as in there's only one way for a block to be in the world which is to be places in a set spot. These sports are not variable, but in a fixed grid and you can't be placing them outside the grid. Moving a ship about like that just wouldn't work too well, it'll be jumpy and basically unfun. But what could be done is the creation of an object like the current boat, something that's free moving across the world. It's possible to add new ones to the game as shown in an plane mod (don't know the name, but it was shown on Yogscast's Youtube channel a while back). So what we need is someway of 'tagging' blocks so that they become 'fixed' into a new object. It should be doable, but I've got no idea how much work it would take.
We already know blocks can move due to gravity, and the Piston Mod takes it a bit further. What I think we haven't seen is a large collection of blocks moving in tandem, which is what would be needed to make it work. You are probably right that there are technical reasons why this wouldn't work well. The game never has a lot of blocks moving at once, and in fact if you quickly destroy a lot of blocks (such as with TNT) game performance drops dramatically. Given the number of constant chunk updates that would be required, it is probably not feasible. Ah well.
I expect moving blocks have been implemented by having a location property, and a target location property, and the block moves in a straight line from one to the other over time. When a block moves, it will add surrounding blocks to a queue, so that you get a cascade effect for the gravel or lava, or whatever. Having a large object moving would mean turning it into a sprite, rather than terrain, as it has to be capable of rotating and moving independent of the terrain grid. Boats could also be made in funny shapes, and funny shaped things are hard for collision detection. Imagine if you made lots of boats that were tangled/knotted together. How would you handle that? Too may collision tests would cripple the engine. It may not be programmed efficiently. If it uses a single function to destroy a block, and add surrounding ones to a queue, it could be making a huge queue by destroying all blocks within the blast radius. It would be more efficient to have a separate two stage function for TNT: first stage is to remove the blocks in the blast radius, and the second stage is add only the perimeter blocks to the queue.
Well, this is why it wouldn't work. A block is a block is a block. There is no distinction between "terrain" and "not terrain" blocks. The game world is divided into 16x16x128 "chunks," and if you destroy/place/move a block within a chunk, that's a "chunk update." I could see moving collections of blocks becoming exponentially less efficient due to the number of chunk updates that would be required. Say you had a boat that was 5x5x5 and it moves at a rate of 1 block per second. That's 125 chunk updates per second. Of course, that's not very big at all. More realistically, you might have a boat that's 40 blocks long by 15 blocks wide by 20 blocks tall. If it moves at the same rate, you are updating 12,000 blocks per second. Other than blocks affected by gravity (which have relatively simple gravity physics which are only activated in proximity/on a chunk update, not all the time), the only things that can move are entities: mobs, vehicles, inventory items. And that works because an entity just has a single x,y,z coordinate, so it's pretty trivial to update the position/direction/speed. The only alternative I can think of is maybe turning your custom vehicle into an entity, which would eliminate all of its block properties. So, you build a ship, define its boundaries, turn it into an entity--and then you cannot destroy any of its blocks or place blocks in it. It could use very dumb bounding box collision detection which would be sufficient for most purposes. Unfortunately, the "entity" method would rule out having a mobile crafting/storage platform, as nothing in it would be considered a block anymore. If Notch ever releases the source code (which he says he will) I would love to get down into the guts and see if it's possible to do any of this.
This is what I meant by 'sprite'. I'll guess that moving blocks (gravel) are also sprites while they are moving. chunk update sees that gravel can fall --> delete gravel block -> create gravel sprite -> sprite moves to destination. When sprite arrives at destination --> delete sprite --> create gravel block Not necessarily. The boat-made-of-blocks could be a second instance of the game grid, and the engine renders both game grids ~ superimposed... as long as Notch hasn't defined the game grid using the dreaded singleton pattern.
I'm honestly not sure how the gravity is done. What I do know is that only sand and gravel are affected by gravity, and gravity is only activated when an adjacent block is modified. I don't think it's necessary to turn those blocks into entities since what gravity does is very limited--the block simply falls straight down, accelerating at the rate of gravity. Minecraft gravity has been found to be inconsistent for blocks vs. entities, and even more inconsistent when you bring inclined minecart tracks into the mix. So, I don't think blocks get turned into entities when they are affected by gravity. I think a simple gravity loop just gets activated for each block that needs to fall. I think that would be both memory- and computationally-prohibitive. The game map also appears to be a singleton: moving between the overworld and the Nether requires a map swap, as though you cannot have two maps running at once. Nevertheless, Notch is working on having the Nether in multiplayer, but I suspect this will be done by having separate map threads and just letting players move between them. Throwing another map into the mix (a constantly-updating set of moving block collections) sounds like an awful lot of overhead.
Yeah, the only things that actually move are doors, buttons, levers, and small boats and minecarts etc. Nothing at a big scale, and they're mostly moving on axis points.. It would likely be possible to group certain blocks together to get them to move on an axis, like say, if you build something like a waterwheel and have it turn on an axis and be powered by a waterfall. Robert's right though. These kind of things require for objects to be defined. To make things like this work, you'd have to select block groups and define them as either terrain or vehicle or moving object, etc. Something that the engine just doesn't do.. I would love to be able to have larger scale boats similar to the small ones though, as that might be possible. Or, I just thought of something. I think we've been complicating things. We're all thinking in terms of terrain; moveable terrain. The way to look at it is objects. The whole gameplay is made up of objects and crafting them. We already have something with a floating property; the boat. What's to stop notch from being able to combine several boats together to get a bigger one? Say, 9 boats could make up a large boat. 6 Boats could make up a square raft. Make enough rafts and join them together to make them even bigger surface area; a surface area that could be built on. Anything built onto it would automatically become part of the raft and be thought of as one object, not several, reducing lag.
^ What I really want is small-scale moving parts, like waterwheels as you mentioned. I think it'd be especially interesting if that was the best way to generate power—it'd be cool to build power plants and the like.
Yeah, especially when waterfalls are naturally occurring. One only needs to take advantage of it, and in that sense, electricity becomes a resource, much like anything else that can be used.
It seems like you could create a "block group" of some sort which interacts with the world as a unit, passing the interaction down to its component parts only once the larger object has determined some interaction exists at all. It's a well-known problem in computer graphics, I'd think that a game like this could incorporate similar ideas.
I've looked around and there are mods that allow you to craft small flying vehicles. Airplanes in one, and a small steampunk airship in the other. We're only talking like 4-8 blocks though.
Been playing around a bit with some basic powered rail layouts. They seem to work pretty well actually. At least as long as the gold holds out. Only bit I need to work on is the carts tendency to hit the end of the line, bounce off the stone brake block onto the launcher and shoot off back the way it came. Guess I'll have to wire up an off switch for the upcoming launcher a short ways up the track. Hmm, wonder if a Detector rail would do the trick?
You can put a powered rail at the very end of the rail line and leave it off, then the cart will always brake there. If you connect a stone button up to it and press it, because the cart can only go in one direction (due to the block on one side) it will move away. It's very handy and doesn't involve any cart pushing.
Right now I'm following the sugggestion on the Minecraft wiki. Stone block with switch on top/powered track/regular track/4 powered tracks. When the cart comes into a stop, it hits those 4 powered ones and gets a hard boost into the switch block. If I'm not fast enough and miss hitting the off switch, the cart will slam into the switch block, then rebound backwards onto the 4 powered blocks and off I go again. I wonder if putting the 4 powered ones further down the track would do the trick.