Many people have expressed a desire for ships made of blocks, and Notch has said on livestream that he wanted to include things like that if he can figure out the technical side. These are my thoughts on how to do this, both from a coding and a balance standpoint. Much of this could be applied to other block-based creations, while some of it is more boat-specific. It should be obvious which is which.
Part 1: Block-grid Entities
The foundation of this idea is what I'll refer to as a Block-grid entity, or a Block-grid for short. This is a collection of blocks, built identically to how blocks are normally placed in the world, that can move and operate as an entity, while retaining its block-based properties.
To start, the Block-grid will have a array of the blocks that are part of it. Players should be able to build on them and delete them like they normally would, by attaching blocks to blocks already present on the structure. When the structure is finished, it will under-go a "baking" stage, where it will be optimized. It will have a virtual bounding box, which can be used for extremely quick, macro-level tests to see whether an entity needs to deal with the micro-structure of the Block-grid. The outer-edges of the blocks will be baked into several lists, one for each direction, which can be used to detect collisions. This allows it to only check collisions on edges in the direction of movement. Other optimizations can occur at this stage, like simplifying the graphics so edges between 2 blocks don't need rendered and other such tweaks.
If an entity is within the bounding box, then its coordinates and orientation are transformed to match up with the block-grid. At that point, all interactions between the entities and blocks in the block-grid can occur exactly as they would in the normal world. The only needed addition is friction, so if the Block-grid is in motion, the entity can ride it. You can build onto the block-grid, and remove blocks normally. This will require the changes to update the optimizations.
Within the block-grid, block to block interactions should occur normally. This includes things like growing a tree, if the block-grid is large enough to contain it. Collisions between the block-grid and the normal grid may result in Block-grid blocks being broken, depending on speed of impact and strength of material.
Addendum:Rendering water
In order to compensate for the need to alter the rendering of water near the ship, so the ship does not render water inside, some slight alterations need to be made.
First, every chunk needs a flag to tell if a Grid-entity is in it(or perhaps more importantly, if a block-grid is intersecting water; this flag can be used to mark any other special rendering cases that may be needed). If the flag is false, then it renders normally. If it is set, it will perform extra checks when rendering to determine if it is inside the block-grid, and if so, alter the rendering appropriately. This will leave the vast majority of the world rendering normally. The inner-chunk checks may be able to be optimized as well.
Part 2: Ships
Ships need extra work in the baking phase. Starting from the bottom layer, and working up, it will be analyzed. The perimeter of the layer will be found, and the contained volume calculated. The total weight of all blocks, based on type, is also calculated. It will also check to see if there is a vertical opening to the layer below, where water would flow in if it is submerged too far. This data can be assembled into a table, to determine how deep in the water the boat will float relative to carried weight. Hence, the more weight on the boat, including the boat itself, the lower it will float, and the bigger the boat relative to the weight, the higher. The boat can then dynamically change its water-line based on load.
If the water-line has an area that it can flow down into, then the lower sections of the boat will need to start filling with water, with a speed depending on the number and size of the holes. The extra water adds weight to the ship, lowering its water-line, which can easily sink the ship. However, compartmentalizing the ship so there is a limited amount of volume the water can take up can make the ship resistant to sinking. Holes can be plugged, and the water bailed out with buckets, to counteract your ship sinking.
Wood should have weight to volume ratio low enough that it will float by itself. This would mean a basic raft would work, but have a very low wight limit before sinking. Iron ships may be possible, but very difficult to keep afloat. An iron-clad design would probably be more successful, but be very expensive to make.
Now that the ability of the ship to remain afloat can be determined, we can move on to speed. Weight also affects your speed, but so does drag. To calculate drag, you assign every front-back row below the waterline a constant amount of drag. you then search backwards in the ship. The first block in each row adds an amount of drag based on how many open rows near it and the drag in its column. It adds additional drag to the columns near it. This means the a shape like this:
[]
[] []
[]
<-front
Has a lot more drag than
which has a lot more drag than
[] []
[]
[]
[] []
Hence, ship-shapes have the least drag (which is why ships are built that way IRL)
You can also factor in building material into the drag, so cloth, while being light, is fragile and has high-drag, making it a poor boat material.
Combining drag and weight tells you how much speed you get for a given propulsion. Propulsion can could come from several sources:
1. Manpower: A craftable oar should allow you to manually add propulsion to your boat. A many-man canoe with several people rowing should actually be able to get decent speeds. The current boat should probably be converted to use this method.
2. Sails: Sails could be dynamically created using a drag calculation going back-to-front, above the water. This would make cloth the best material, since you want high surface area, and cloth is light-weight, and high-drag, so it is most efficient. A wood sail works, but is heavy, and the added weight would make it very ineffective. You can allow for multiple sails by allowing wind to build up after the first sail, but at a lower power, based on the distance between the two sails.
3. Propulsion blocks: A catch-all for any block that would add speed, such as a hypothetical propeller block, a magical propulsion stone, or whatever.
Player's perspective
These ruled may seem complex from a detailed view, but in practice they should be very intuitive. You build a wooden ship with a cloth sail, and it will perform similar to what you expect. The ships with bigger sails tend to go faster, and streamlined ships are faster than boxy ships. Bigger ships can hold more than smaller ships, and stone ships tend to sink while wood boats float. By applying common sense to your boat-building, you achieve the expected results. Cannons, when added, would be mountable on ships, and attacking the other ship would work as you expect: cannonballs put holes in the other ship, which can lead to them sinking. If you have a leak, you need to plug it, and start bailing out water. If you shoot somebodies sails, they will become less effective, and they sill slow down. If you run you ship into rocks (or icebergs) you will break holes in your ship, causing it to sink.
In short, it will behave very intuitively, so you do not need a detailed understanding of the system to create good ships. Many different arch-types of ships are possible.
Addendum: Other uses of Block-grid entities
There are other possible uses of Block-grid entities. I will cover several; I am not saying any of these ideas are good or bad, just possible(though I think some of these would be really cool):
1. Improved tree mechanics
If a tree is converted to a block-grid entity when chopped, it can tip over like a real tree. This eliminates floating-partial trees. The tree will still have to be harvested after it falls, so this does not increase the power of the axe. The only way it makes tree harvesting easier is by making it so you do not have to build to harvest the tops of tall trees.
2. Elevators
Notch mentioned that a possible use for a system like this would be to make customizable elevators. This may fit into the below category, but I mention it separately due to Notch's specific mention.
3. Drawbridges and other mechanisms
This offers a flexible means to implement movable mechanisms, like floodgates and drawbridges. A drawbridge could be made of wood, iron, or whatever else, and be able to drop down and be raised. A lowerable staircase could be made, or a retractable ladder.
4. Other vehicles
Many people have requested airships or hot air balloons, which could also be a facet of the Block-grids. These would bear many similarities to ships
5.Rubble
Certain things(primarily explosions) might be able to knock blocks loose, and force Block-grids from them. This would allow contiguous chunks of rubble to fall, ceilings to collapse, and create strewed blocks.
6. Enemy uses
Some enemies could take advantage of these in various ways. For instance, there could be a golem that grabs dirt or stone from the landscape and throws boulders of it at the player. Some enemies could also be made out of several block-grids, so you can go up and destroy its leg, and it will fall over, or take off its arm to reduce its ability to attack.
I remember something like this (I think it was you) posted in some OTHER boat thread... Hmmmm. I'm just worried about floating fortresses, even if made of wood. Does it just check how many "Heavy" things are part of the boat or does it account every block's weight?
And of course we'll need bigger oceans for this.
I remember something like this (I think it was you) posted in some OTHER boat thread... Hmmmm. I'm just worried about floating fortresses, even if made of wood. Does it just check how many "Heavy" things are part of the boat or does it account every block's weight?
And of course we'll need bigger oceans for this.
A floating fortress would not be that much more secure than a land-based one. It is easier to destroy since it can easily be sunk.I also suspect their will be a maximum size. Notch said he was thinking about doing something similar to this on livestream, and he said 16x16x16 as a size.
It counts the weight of every block.
Notch said on livestream that he might make oceans bigger now that we have boats.
Also, with this system it may be possible to engineer a submarine. It would be tricky to engineer, since you have to control the buoyancy in some manner and such, but it would be awesome if somebody pulls it off.
I... Vaguely agree with you. This is a very generalized statement of how it would need to be done, and it doesn't address the some major issues of it's implementation. I need to do diagrams to explain my position here, but I only have 15 minutes, so it'll have to wait until I finish work.
Rollback Post to RevisionRollBack
This may be a fad, but I love dragons, so why the heck not?
It'd all be worth it the first time you see some enormous iron-clad battleship sailing past you. Or destroying your fortress/base/town/house.
Well going by Mystify's principals a ironclad should be impossible (okay maybe not quite), at least if the full square meter blocks are given an accurate weight for a square meter of iron. Would also be really stupid hard to move, as it should.
Maximum size should work, and yeah a floating fortress could easily sink, but if they made it correctly it would sink and become an island fortress, which would be rather awesome. Would need better water flow and disappearing blocks (or at least water gates) for subs I think.
It'd all be worth it the first time you see some enormous iron-clad battleship sailing past you. Or destroying your fortress/base/town/house.
Well going by Mystify's principals a ironclad should be impossible (okay maybe not quite), at least if the full square meter blocks are given an accurate weight for a square meter of iron. Would also be really stupid hard to move, as it should.
Maximum size should work, and yeah a floating fortress could easily sink, but if they made it correctly it would sink and become an island fortress, which would be rather awesome. Would need better water flow and disappearing blocks (or at least water gates) for subs I think.
If real world densities are used you won't be able to make a seaworthy vessel out of iron in a 16³ area.
Rollback Post to RevisionRollBack
Never attribute to malice what can adequately be explained by incompetence.
True, an full-out ironclad would be impossible with true measurements. However, measurements do not need reflect reality perfectly. If we fudge the numbers so iron is much lighter, then it may be possible. Full-metal ships are likely to be impossible, but strategically armored ships may be.
Quote from A.I. »
Maybe it's not solid iron, then. Would a wood ship clad in iron (hence "iron-clad") suffice? I believe it's been done before.
If you consider that a meter cubed of iron has 9 pieces of iron in it, which is enough for 3 pickaxes, the thought that it is not solid seems plausible. In that case you could justify it being light enough to use as armour. ]
If you consider that a meter cubed of iron has 9 pieces of iron in it, which is enough for 3 pickaxes, the thought that it is not solid seems plausible
Or your character isn't a blacksmith and ends up wasting a ton of iron in the process.
But for reference, you'd have to make it around 2.3 times less dense in order to make something that is, at best, neutrally buoyant. Actually, what sounds like fun is implementing this boat algorithm and having a genetic algorithm design optimal boats in a given region. I've been doing calculations with open top boxes and varying the dimensions and this sounds more interesting and more fun. Maybe I will do it.
Rollback Post to RevisionRollBack
Never attribute to malice what can adequately be explained by incompetence.
You can make a completely, not buoyant cast iron bathtub(with the hole plugged up) float. It's about the shape of the boat containing a massive air pocket, not if the material floats or not.
You can make a completely, not buoyant cast iron bathtub(with the hole plugged up) float. It's about the shape of the boat containing a massive air pocket, not if the material floats or not.
Yes, thats how my system works - it uses the volume contained, not the buoyancy of individual materials.. However, the sheer weight of a cube of iron makes it difficult to make boats out of it. Metal ships don't have meter thick hulls for a reason
You can make a completely, not buoyant cast iron bathtub(with the hole plugged up) float. It's about the shape of the boat containing a massive air pocket, not if the material floats or not.
Yes, thats how my system works - it uses the volume contained, not the buoyancy of individual materials.. However, the sheer weight of a cube of iron makes it difficult to make boats out of it. Metal ships don't have meter thick hulls for a reason
Aircraft carriers and submarines do, and they retain bouyancy.
Though I see your point. It would be annoying to get in a cannon fight with someone who has one, or even THREE layers thick metal or diamond armor on their boat. Oh, and it should be said that boats made of hacked in adminium shouldn't even work at all.
Metal ships don't have meter thick hulls for a reason
They're also a hell of a lot bigger than 16m. Volume scales with the cube of length whereas surface area (which weight is proportional to for the most part) scales only with the square.
Aircraft carriers and submarines do, and they retain bouyancy.
I'm pretty damn sure they don't. It's difficult for me to find numbers, but hull plating thickness is measured in inches, not meters. Meter thick hull plating would be ridiculously expensive and heavy and provide little benefit. It would also severely reduce the carrying capacity of a carrier.
Rollback Post to RevisionRollBack
Never attribute to malice what can adequately be explained by incompetence.
Thing is, Iron must be hollow cause It only took 9 ingot of it to make.
Here is an image of some ingots. (These are aluminium, but that doesn't matter. Iron would be the same size as well.) *Image*
9 of those makes a meter thick cube... I highly doubt it. It would have to be rather hollow, which would explain why it's just as easy to destroy with some TNT.
I think hybrids would be the best bet: A Iron front and rear, or maybe just front would protect it from cannon fire when approaching the vessel or harbour.
Some flaws in this system: regarding the buoyancy bit, if a entity goes underwater, it fill up with water. If one were to bucket the water out of the boat, you would just be bucketing the sea, which will replicate more springs. To get a good, sectioned ship you need to have water not 'flood' into the ship when it's underwater, as everything inside the ship will technically be inside water blocks, making them drown.
If one makes the air inside a ship part of it's design, you might be able to counter this. But again, to make water flood into the ship like on land will require the ship itself to change and make Entity grid water springs and all sorts of drama, but the water will be bucket-able.
I think a simple (in my eyes) system would be to have the Entity air blocks to override spring blocks, except when there is a leak. Then you'll need a system for checking what parts of the ship are leaky, and making them lose their buoyancy, then allow the water to override the air, giving a natural feel as the ship sinks don and fluently floods up.
However, you can't bucket the water out.
So now that my bucket rant is over, I praise you! This system is good, and even allows for Non-boat structures, like a... well....
Part 1: Block-grid Entities
The foundation of this idea is what I'll refer to as a Block-grid entity, or a Block-grid for short. This is a collection of blocks, built identically to how blocks are normally placed in the world, that can move and operate as an entity, while retaining its block-based properties.
To start, the Block-grid will have a array of the blocks that are part of it. Players should be able to build on them and delete them like they normally would, by attaching blocks to blocks already present on the structure. When the structure is finished, it will under-go a "baking" stage, where it will be optimized. It will have a virtual bounding box, which can be used for extremely quick, macro-level tests to see whether an entity needs to deal with the micro-structure of the Block-grid. The outer-edges of the blocks will be baked into several lists, one for each direction, which can be used to detect collisions. This allows it to only check collisions on edges in the direction of movement. Other optimizations can occur at this stage, like simplifying the graphics so edges between 2 blocks don't need rendered and other such tweaks.
If an entity is within the bounding box, then its coordinates and orientation are transformed to match up with the block-grid. At that point, all interactions between the entities and blocks in the block-grid can occur exactly as they would in the normal world. The only needed addition is friction, so if the Block-grid is in motion, the entity can ride it. You can build onto the block-grid, and remove blocks normally. This will require the changes to update the optimizations.
Within the block-grid, block to block interactions should occur normally. This includes things like growing a tree, if the block-grid is large enough to contain it. Collisions between the block-grid and the normal grid may result in Block-grid blocks being broken, depending on speed of impact and strength of material.
Addendum:Rendering water
In order to compensate for the need to alter the rendering of water near the ship, so the ship does not render water inside, some slight alterations need to be made.
First, every chunk needs a flag to tell if a Grid-entity is in it(or perhaps more importantly, if a block-grid is intersecting water; this flag can be used to mark any other special rendering cases that may be needed). If the flag is false, then it renders normally. If it is set, it will perform extra checks when rendering to determine if it is inside the block-grid, and if so, alter the rendering appropriately. This will leave the vast majority of the world rendering normally. The inner-chunk checks may be able to be optimized as well.
Part 2: Ships
Ships need extra work in the baking phase. Starting from the bottom layer, and working up, it will be analyzed. The perimeter of the layer will be found, and the contained volume calculated. The total weight of all blocks, based on type, is also calculated. It will also check to see if there is a vertical opening to the layer below, where water would flow in if it is submerged too far. This data can be assembled into a table, to determine how deep in the water the boat will float relative to carried weight. Hence, the more weight on the boat, including the boat itself, the lower it will float, and the bigger the boat relative to the weight, the higher. The boat can then dynamically change its water-line based on load.
If the water-line has an area that it can flow down into, then the lower sections of the boat will need to start filling with water, with a speed depending on the number and size of the holes. The extra water adds weight to the ship, lowering its water-line, which can easily sink the ship. However, compartmentalizing the ship so there is a limited amount of volume the water can take up can make the ship resistant to sinking. Holes can be plugged, and the water bailed out with buckets, to counteract your ship sinking.
Wood should have weight to volume ratio low enough that it will float by itself. This would mean a basic raft would work, but have a very low wight limit before sinking. Iron ships may be possible, but very difficult to keep afloat. An iron-clad design would probably be more successful, but be very expensive to make.
Now that the ability of the ship to remain afloat can be determined, we can move on to speed. Weight also affects your speed, but so does drag. To calculate drag, you assign every front-back row below the waterline a constant amount of drag. you then search backwards in the ship. The first block in each row adds an amount of drag based on how many open rows near it and the drag in its column. It adds additional drag to the columns near it. This means the a shape like this:
[]
[] []
[]
<-front
Has a lot more drag than
which has a lot more drag than
[] []
[]
[]
[] []
Hence, ship-shapes have the least drag (which is why ships are built that way IRL)
You can also factor in building material into the drag, so cloth, while being light, is fragile and has high-drag, making it a poor boat material.
Combining drag and weight tells you how much speed you get for a given propulsion. Propulsion can could come from several sources:
1. Manpower: A craftable oar should allow you to manually add propulsion to your boat. A many-man canoe with several people rowing should actually be able to get decent speeds. The current boat should probably be converted to use this method.
2. Sails: Sails could be dynamically created using a drag calculation going back-to-front, above the water. This would make cloth the best material, since you want high surface area, and cloth is light-weight, and high-drag, so it is most efficient. A wood sail works, but is heavy, and the added weight would make it very ineffective. You can allow for multiple sails by allowing wind to build up after the first sail, but at a lower power, based on the distance between the two sails.
3. Propulsion blocks: A catch-all for any block that would add speed, such as a hypothetical propeller block, a magical propulsion stone, or whatever.
Player's perspective
These ruled may seem complex from a detailed view, but in practice they should be very intuitive. You build a wooden ship with a cloth sail, and it will perform similar to what you expect. The ships with bigger sails tend to go faster, and streamlined ships are faster than boxy ships. Bigger ships can hold more than smaller ships, and stone ships tend to sink while wood boats float. By applying common sense to your boat-building, you achieve the expected results. Cannons, when added, would be mountable on ships, and attacking the other ship would work as you expect: cannonballs put holes in the other ship, which can lead to them sinking. If you have a leak, you need to plug it, and start bailing out water. If you shoot somebodies sails, they will become less effective, and they sill slow down. If you run you ship into rocks (or icebergs) you will break holes in your ship, causing it to sink.
In short, it will behave very intuitively, so you do not need a detailed understanding of the system to create good ships. Many different arch-types of ships are possible.
Addendum: Other uses of Block-grid entities
There are other possible uses of Block-grid entities. I will cover several; I am not saying any of these ideas are good or bad, just possible(though I think some of these would be really cool):
1. Improved tree mechanics
If a tree is converted to a block-grid entity when chopped, it can tip over like a real tree. This eliminates floating-partial trees. The tree will still have to be harvested after it falls, so this does not increase the power of the axe. The only way it makes tree harvesting easier is by making it so you do not have to build to harvest the tops of tall trees.
2. Elevators
Notch mentioned that a possible use for a system like this would be to make customizable elevators. This may fit into the below category, but I mention it separately due to Notch's specific mention.
3. Drawbridges and other mechanisms
This offers a flexible means to implement movable mechanisms, like floodgates and drawbridges. A drawbridge could be made of wood, iron, or whatever else, and be able to drop down and be raised. A lowerable staircase could be made, or a retractable ladder.
4. Other vehicles
Many people have requested airships or hot air balloons, which could also be a facet of the Block-grids. These would bear many similarities to ships
5.Rubble
Certain things(primarily explosions) might be able to knock blocks loose, and force Block-grids from them. This would allow contiguous chunks of rubble to fall, ceilings to collapse, and create strewed blocks.
6. Enemy uses
Some enemies could take advantage of these in various ways. For instance, there could be a golem that grabs dirt or stone from the landscape and throws boulders of it at the player. Some enemies could also be made out of several block-grids, so you can go up and destroy its leg, and it will fall over, or take off its arm to reduce its ability to attack.
And of course we'll need bigger oceans for this.
A floating fortress would not be that much more secure than a land-based one. It is easier to destroy since it can easily be sunk.I also suspect their will be a maximum size. Notch said he was thinking about doing something similar to this on livestream, and he said 16x16x16 as a size.
It counts the weight of every block.
Notch said on livestream that he might make oceans bigger now that we have boats.
Also, with this system it may be possible to engineer a submarine. It would be tricky to engineer, since you have to control the buoyancy in some manner and such, but it would be awesome if somebody pulls it off.
Well going by Mystify's principals a ironclad should be impossible (okay maybe not quite), at least if the full square meter blocks are given an accurate weight for a square meter of iron. Would also be really stupid hard to move, as it should.
Maximum size should work, and yeah a floating fortress could easily sink, but if they made it correctly it would sink and become an island fortress, which would be rather awesome. Would need better water flow and disappearing blocks (or at least water gates) for subs I think.
If real world densities are used you won't be able to make a seaworthy vessel out of iron in a 16³ area.
If you consider that a meter cubed of iron has 9 pieces of iron in it, which is enough for 3 pickaxes, the thought that it is not solid seems plausible. In that case you could justify it being light enough to use as armour. ]
Or your character isn't a blacksmith and ends up wasting a ton of iron in the process.
But for reference, you'd have to make it around 2.3 times less dense in order to make something that is, at best, neutrally buoyant. Actually, what sounds like fun is implementing this boat algorithm and having a genetic algorithm design optimal boats in a given region. I've been doing calculations with open top boxes and varying the dimensions and this sounds more interesting and more fun. Maybe I will do it.
Yes, thats how my system works - it uses the volume contained, not the buoyancy of individual materials.. However, the sheer weight of a cube of iron makes it difficult to make boats out of it. Metal ships don't have meter thick hulls for a reason
Aircraft carriers and submarines do, and they retain bouyancy.
Though I see your point. It would be annoying to get in a cannon fight with someone who has one, or even THREE layers thick metal or diamond armor on their boat. Oh, and it should be said that boats made of hacked in adminium shouldn't even work at all.
They're also a hell of a lot bigger than 16m. Volume scales with the cube of length whereas surface area (which weight is proportional to for the most part) scales only with the square.
I'm pretty damn sure they don't. It's difficult for me to find numbers, but hull plating thickness is measured in inches, not meters. Meter thick hull plating would be ridiculously expensive and heavy and provide little benefit. It would also severely reduce the carrying capacity of a carrier.
Here is an image of some ingots. (These are aluminium, but that doesn't matter. Iron would be the same size as well.)
*Image*
9 of those makes a meter thick cube... I highly doubt it. It would have to be rather hollow, which would explain why it's just as easy to destroy with some TNT.
I think hybrids would be the best bet: A Iron front and rear, or maybe just front would protect it from cannon fire when approaching the vessel or harbour.
Some flaws in this system: regarding the buoyancy bit, if a entity goes underwater, it fill up with water. If one were to bucket the water out of the boat, you would just be bucketing the sea, which will replicate more springs. To get a good, sectioned ship you need to have water not 'flood' into the ship when it's underwater, as everything inside the ship will technically be inside water blocks, making them drown.
If one makes the air inside a ship part of it's design, you might be able to counter this. But again, to make water flood into the ship like on land will require the ship itself to change and make Entity grid water springs and all sorts of drama, but the water will be bucket-able.
I think a simple (in my eyes) system would be to have the Entity air blocks to override spring blocks, except when there is a leak. Then you'll need a system for checking what parts of the ship are leaky, and making them lose their buoyancy, then allow the water to override the air, giving a natural feel as the ship sinks don and fluently floods up.
However, you can't bucket the water out.
So now that my bucket rant is over, I praise you! This system is good, and even allows for Non-boat structures, like a... well....
Maybe a custom minecart? :\
A simple suggestion on geology here.
~~~
Slaves of the Coal Mine
An interesting Novel to pass the time.