The merits or flaws of such systems is discussed in depth, and so I don't wish to go into that at this point, that's not the purpose of this thread. The purpose of this thread is to put forward a suggestion for the mechanism through which tracks are placed and used. To put it another way, if trains or mine carts are to be incorporated into the game, here is an idea about how it could be done.
The core of my idea is that you have Track blocks that can be placed, and they must be placed at least two horizontal squares away from any other track block (not one square away, like most blocks).
Track blocks shown here as boards with a hole in the middle, because I am too lazy to make a proper looking track block example. The surrounding blocks wouldn't actually turn red, this is just an illustration to show where the game would prevent you from placing a track block.
The blocks themselves would store information about which way their tracks are pointing using the 4 bits available in the current block system (left over from the full byte of information after lighting data is stored, if I'm understanding the system.) The track can only be recorded as bending at a 135 degree angle (Although it can connect to other tracks in more ways, which I'll go over) allowing only 13 positions to be possible. Since 4 bits is 16 combinations, the remaining three could be used to symbolize no tracks, diagonal crossroads , or vertical/horizontal crossroads.
These could be changed with a right-click, which would choose other POSSIBLE configurations (that is, not pointing arbitrarily in directions where no track objects exist, simply alternating through different possible track combinations.)
once the direction is set, if the direction is right-angled, north east south or west, the track assumes that it connects Directly to another track block two squares away
if it's on a diagonal, it chooses one of the possible three combinations for blocks two squares away, as shown:
Since the three possibilities are all touching each other, the game wouldn't have to worry about multiple options existing for a diagonal connection.
because of this, the REAL maximum angle a track can bend at is 112.5 degrees, but this wouldn't be stored in the block.
In both these scenarios, approximate diagonal and directly connecting horizontal/vertical, the game will check for blocks above and below the current block, too, so they don't all have to be lined up vertically. Perhaps it'd make sense to prioritize one or the other. If there is a lower block that works, choose that every time.
For the connections themselves, I'm proposing a string of entities to act as tracks, just as a graphical representations of where the cart will be going. They won't do anything, they won't have any programmatic purpose, but they connect two Track blocks in a way that demonstrates to the player which way the tracks are facing. Example
The final step is to have a vehicle entity, the cart, or the train, that will travel, when prompted, from track block to track block, rotating and traveling in a straight, fluid line from one to the designated next, assuming there's proper vertical space for it. This way, having it go in straight lines, it gives the illusion of following the non-block track entities, which also are following straight lines.
That explains it all. If there are bits of this that are unclear I'll try to explain. if anyone can see potential problems with this system I'll be glad to consider that, as well, and see if it can be solved.
I'd just have it so that trains (I include carts as trains) can only be controlled to move on rail blocks. Then I'd have them figure out their facing based on their spatial relationships... In other words, what the tracks look like would be entirely aesthetic and superficial, and they really could be facing any direction, they just serve the purpose of allowing the cart to get to places.
Rollback Post to RevisionRollBack
This may be a fad, but I love dragons, so why the heck not?
I'd just have it so that trains (I include carts as trains) can only be controlled to move on rail blocks. Then I'd have them figure out their facing based on their spatial relationships... In other words, what the tracks look like would be entirely aesthetic and superficial, and they really could be facing any direction, they just serve the purpose of allowing the cart to get to places.
It is ornate, yeah, although that's part of what I like about it. The issue that comes up with adjacent rail blocks is the challenge of figuring out how it behaves when trying to go up or down. I considered that tracks could always stay horizontal, but this seems unnecessarily restrictive. I have seen the idea of having the track go up like stairs, but the difference between being square at one point and then angled at another seemed awkward. This method is elegant (or ornate, yes) and allows for vertical movement to be integrated without causing anyone to think twice.
I must admit, your design IS beautiful, if not the most functional. And, being an artist, it does have a lot of attraction because of that... However, I'm still trying to think of how players will be interacting with carts, and then the carts with the rails.
To make this work:
1. The rails themselves would need to be a type of entity. Otherwise hundreds of individual models for just rails facing different angles will need to be placed.
2. When you place a rail block, and have another rail block selected, and horizontal surfaces 2 steps away from the placed rail block should be highlighted somehow, showing where you can place the next rail block, to make it go.
3. This system does not allow for intersections of any kind. The best method I can think of, is to make some sort of unique intersection block to handle that issue.
Rollback Post to RevisionRollBack
This may be a fad, but I love dragons, so why the heck not?
I must admit, your design IS beautiful, if not the most functional. And, being an artist, it does have a lot of attraction because of that... However, I'm still trying to think of how players will be interacting with carts, and then the carts with the rails.
To make this work:
1. The rails themselves would need to be a type of entity. Otherwise hundreds of individual models for just rails facing different angles will need to be placed.
2. When you place a rail block, and have another rail block selected, and horizontal surfaces 2 steps away from the placed rail block should be highlighted somehow, showing where you can place the next rail block, to make it go.
3. This system does not allow for intersections of any kind. The best method I can think of, is to make some sort of unique intersection block to handle that issue.
These are good points. And I have answers to them.
as for 1, yes, this was my intention. The blocks are blocks, the graphical rails on them are simple entities, designed to give a visual indication of how blocks are connected, but existing completely as entities that don't go anywhere.
2 makes sense. I wasn't sure about this because nothing else in the game does this... but it would make it more clear, instead of having people trying to place them side-by-side for an hour before figuring it out.
3- I figured two of the remaining 3 bit combinations could be used for 90 degree intersections, which is displayed on my little graphic there. I haven't played with the idea too much, but it seems like it would work just fine. No Y-shaped tracks, though...
Right, if an intersect block were made, there'd be a way to make 5-pointed star intersections if we wanted, because it would be using the same directional system as the regular tracks, but it would connect to EVERY block in it's connecting radius in an outward radiating pattern, rather than maintaining a line. But we wouldn't be able to connect intersection blocks, or they'd just crash stuff.
Also, once a regular rail block is part of a line, it shouldn't be able to link to other rail blocks any more. So we could set three lines of tracks parallel to one another without them interfering with each other.
Rollback Post to RevisionRollBack
This may be a fad, but I love dragons, so why the heck not?
The rails themselves would need to be a type of entity. Otherwise hundreds of individual models for just rails facing different angles will need to be placed.
Overlays would be even easier to make and handle, methinks. But then all diagonal stuff would look pretty weird.
Do you mean elevator blocks? Sure ,that could work, but it's clunky. my reason for suggesting this particular system is that it smoothly and elegantly works both with horizontal links and going up and down.
Actually as nice as it would be to have the extra versatility this may give us, it seems slightly arbitrary to the whole minecraft 'theme', that everything is sort of... square. It'd make more sense (in my mind) to have the tracks be a tile which connects to all others around it.
As to "elevation blocks" I think he actually meant elevation, not elevator. As in ramps. Elevators would also be nice, but I think perhaps a little overdoing it - plus if we can only make ramps that gives you the challenge of having a mine which the cart can actually navigate.
So when you place a track block, it checks around itself for, in order:
- A single-height hop up, such as a stone block you're placing it next to
- Other track blocks
If it finds the hop up, it will become a ramp and ignores track blocks to what are now its sides.
If it doesn't find a change in elevation, it will check all four directions for other track blocks (including ramps on the level below). Then, based on which blocks it finds, it will become a straight, corner, T or X intersection.
In the case of T/X intersections, how do you decide which way a mine cart goes? The answer is, right clicking the track. This will toggle amongst the available directions. In the case of the T intersection:
The X intersection not supporting any corners also means that you will need to plan ahead a bit, I suppose. It's more because it would be silly to have it support everything, that many rails would be ridiculous. :laugh.gif:
Also, if a rail is connected to only one other rail, it becomes a buffer; these are the points at which mine carts stop.
As for the carts themselves, I would have them act as an inventory with a 'Send' button that starts the cart rolling. If the cart is already rolling, right-clicking it to interact should stop it, in which case it will go to the next tile in its route before stopping. If a cart is stopped on a ramp it should also roll down it.
If two carts collide moving opposite directions, I suppose it would cause a derailment; if they collide and one is stopped, the other will simply stop, and if they're moving the same direction it's not really a 'collision' at all.
Pretty pictures would probably have been a good idea, I'm paranoid this will get tl;dr'd or just be hard to understand. :oops:
The system appeals to me. It sounds like it would be more intuitive to use than to describe. In the absence of ramps, this is probably the next best thing.
The system appeals to me. It sounds like it would be more intuitive to use than to describe. In the absence of ramps, this is probably the next best thing.
Right. It's funny that this thread was brought to life when it was, really. I've been working on an applet to demonstrate this, and was going to post this today or tomorrow. Since the topic has come up anyway, I may as well post it today.
After playing around with it, I discovered that the system I originally described ended up being rather complex. Complex to code, complex to use. So instead, I came up with a system that has tracks only moving in one direction. This is not quite as useful as before, since now you have to make tracks in a loop if you want a cart to return, but there's ways to make it work both ways, I just haven't got there yet.
click on the grid to create a track, and click on the track to rotate it. right click rotates the opposite way.
once your tracks are set up, drag-and-drop a cart from the top corner onto one of your tracks, if you feel so inclined.
As before, I'm figuring that this would look, and work, well with tracks that go one block up or down for each new rail, to allow for (gentle) inclines
I'll probably keep tweaking this, since it is less than perfect, and it's good practice either way.
Oh, I also removed those restrictions I had mentioned before. They were just asthetic, and didn't strike me as particularily useful once I disbanded the old design.
Thoughts based on using the applet:
A track connecting more than 90 degrees off from its original direction is probably not needed. That sharp of a turn is ugly, and the extra combinations you save by eliminating them can be put to otehr uses.
Tracks should connect to valid track pieces automatically by default. I should be able to lay down a long track simply by placing start points along the way. This applies for connecting to existing tracks and for unconnected tracks responding to new blocks.
I believe you mentioned it in the post, but it didn't make it into the applet, but it should only point to valid track connections. An unconnected track should for a standard 'end of rail' barrier.
Makes sense. I'm not sure how to implement it in this example right away. Until I do, pretend that it finds valid squares to connect to automatically, and clicking just changes the choice it makes.
As well as a resource-transportation cart - basically just a chest which can move along the track - perhaps there should be a passenger cart in which the player can ride? Perhaps, even, carts could be linked together and moved as one train?
[*:z6qzpm7n]Resource cart - comes in several capacities, each costing a different amount of resources
[*:z6qzpm7n]Passenger cart - has a seat, so a player can ride it. Perhaps also bigger carts with three or four seats in a row.
[*:z6qzpm7n]Flat cart - nothing on it. Comes in different lengths, you can put blocks on top.
[*:z6qzpm7n]Possibly an engine, unless all carts have individual propulsion.
[*:z6qzpm7n]Other kinds? Perhaps a cart with some sort of weapon, kinda like in Zelda Spirit Tracks?
There are six types of quarks, known as flavors: up, down, charm, strange, top, and bottom.
hehehe... The true Quantum Mechanics of minecraft :laugh.gif:
...I'm sorry. I'm waiting for Water...
*Puts on hat of seriousness*
Quote from 00Davo »
Okay, so we'd have several "flavours" of carts:
[*:5jjxltvd]Resource cart - comes in several capacities, each costing a different amount of resources
[*:5jjxltvd]Passenger cart - has a seat, so a player can ride it. Perhaps also bigger carts with three or four seats in a row.
[*:5jjxltvd]Flat cart - nothing on it. Comes in different lengths, you can put blocks on top.
[*:5jjxltvd]Possibly an engine, unless all carts have individual propulsion.
[*:5jjxltvd]Other kinds? Perhaps a cart with some sort of weapon, kinda like in Zelda Spirit Tracks?
Resource: What everyone wants, and probably what we will get.
Passenger: This would be fun, but not sure if Notch would ever implement it. (Me wants to use bows with this!)
Flat: A use please? (Besides, making a visible block move would require even more entities: I don't like this idea.)
Engine: Goes slow, but you don't have to follow it where it is going e.g., send it to another town for deliveries?
Amoured: Like passenger, but with iron roof. To avoid getting shot at.
Auto Turret: Shoot arrows automatically. (costs arrows (obviously) and perhaps coal? (fuel))
viewtopic.php?f=1&t=6195
and viewtopic.php?f=1&t=9987
The merits or flaws of such systems is discussed in depth, and so I don't wish to go into that at this point, that's not the purpose of this thread. The purpose of this thread is to put forward a suggestion for the mechanism through which tracks are placed and used. To put it another way, if trains or mine carts are to be incorporated into the game, here is an idea about how it could be done.
The core of my idea is that you have Track blocks that can be placed, and they must be placed at least two horizontal squares away from any other track block (not one square away, like most blocks).
Track blocks shown here as boards with a hole in the middle, because I am too lazy to make a proper looking track block example. The surrounding blocks wouldn't actually turn red, this is just an illustration to show where the game would prevent you from placing a track block.
The blocks themselves would store information about which way their tracks are pointing using the 4 bits available in the current block system (left over from the full byte of information after lighting data is stored, if I'm understanding the system.) The track can only be recorded as bending at a 135 degree angle (Although it can connect to other tracks in more ways, which I'll go over) allowing only 13 positions to be possible. Since 4 bits is 16 combinations, the remaining three could be used to symbolize no tracks, diagonal crossroads , or vertical/horizontal crossroads.
These could be changed with a right-click, which would choose other POSSIBLE configurations (that is, not pointing arbitrarily in directions where no track objects exist, simply alternating through different possible track combinations.)
once the direction is set, if the direction is right-angled, north east south or west, the track assumes that it connects Directly to another track block two squares away
if it's on a diagonal, it chooses one of the possible three combinations for blocks two squares away, as shown:
Since the three possibilities are all touching each other, the game wouldn't have to worry about multiple options existing for a diagonal connection.
because of this, the REAL maximum angle a track can bend at is 112.5 degrees, but this wouldn't be stored in the block.
In both these scenarios, approximate diagonal and directly connecting horizontal/vertical, the game will check for blocks above and below the current block, too, so they don't all have to be lined up vertically. Perhaps it'd make sense to prioritize one or the other. If there is a lower block that works, choose that every time.
For the connections themselves, I'm proposing a string of entities to act as tracks, just as a graphical representations of where the cart will be going. They won't do anything, they won't have any programmatic purpose, but they connect two Track blocks in a way that demonstrates to the player which way the tracks are facing.
Example
The final step is to have a vehicle entity, the cart, or the train, that will travel, when prompted, from track block to track block, rotating and traveling in a straight, fluid line from one to the designated next, assuming there's proper vertical space for it. This way, having it go in straight lines, it gives the illusion of following the non-block track entities, which also are following straight lines.
That explains it all. If there are bits of this that are unclear I'll try to explain. if anyone can see potential problems with this system I'll be glad to consider that, as well, and see if it can be solved.
I'd just have it so that trains (I include carts as trains) can only be controlled to move on rail blocks. Then I'd have them figure out their facing based on their spatial relationships... In other words, what the tracks look like would be entirely aesthetic and superficial, and they really could be facing any direction, they just serve the purpose of allowing the cart to get to places.
It is ornate, yeah, although that's part of what I like about it. The issue that comes up with adjacent rail blocks is the challenge of figuring out how it behaves when trying to go up or down. I considered that tracks could always stay horizontal, but this seems unnecessarily restrictive. I have seen the idea of having the track go up like stairs, but the difference between being square at one point and then angled at another seemed awkward. This method is elegant (or ornate, yes) and allows for vertical movement to be integrated without causing anyone to think twice.
To make this work:
1. The rails themselves would need to be a type of entity. Otherwise hundreds of individual models for just rails facing different angles will need to be placed.
2. When you place a rail block, and have another rail block selected, and horizontal surfaces 2 steps away from the placed rail block should be highlighted somehow, showing where you can place the next rail block, to make it go.
3. This system does not allow for intersections of any kind. The best method I can think of, is to make some sort of unique intersection block to handle that issue.
These are good points. And I have answers to them.
as for 1, yes, this was my intention. The blocks are blocks, the graphical rails on them are simple entities, designed to give a visual indication of how blocks are connected, but existing completely as entities that don't go anywhere.
2 makes sense. I wasn't sure about this because nothing else in the game does this... but it would make it more clear, instead of having people trying to place them side-by-side for an hour before figuring it out.
3- I figured two of the remaining 3 bit combinations could be used for 90 degree intersections, which is displayed on my little graphic there. I haven't played with the idea too much, but it seems like it would work just fine. No Y-shaped tracks, though...
Also, once a regular rail block is part of a line, it shouldn't be able to link to other rail blocks any more. So we could set three lines of tracks parallel to one another without them interfering with each other.
Overlays would be even easier to make and handle, methinks. But then all diagonal stuff would look pretty weird.
Because, nebb, like explained, if this happens, going up or down becomes weird.
Do you mean elevator blocks? Sure ,that could work, but it's clunky. my reason for suggesting this particular system is that it smoothly and elegantly works both with horizontal links and going up and down.
As to "elevation blocks" I think he actually meant elevation, not elevator. As in ramps. Elevators would also be nice, but I think perhaps a little overdoing it - plus if we can only make ramps that gives you the challenge of having a mine which the cart can actually navigate.
So when you place a track block, it checks around itself for, in order:
- A single-height hop up, such as a stone block you're placing it next to
- Other track blocks
If it finds the hop up, it will become a ramp and ignores track blocks to what are now its sides.
If it doesn't find a change in elevation, it will check all four directions for other track blocks (including ramps on the level below). Then, based on which blocks it finds, it will become a straight, corner, T or X intersection.
In the case of T/X intersections, how do you decide which way a mine cart goes? The answer is, right clicking the track. This will toggle amongst the available directions. In the case of the T intersection:
And for the X intersection:
The X intersection not supporting any corners also means that you will need to plan ahead a bit, I suppose. It's more because it would be silly to have it support everything, that many rails would be ridiculous. :laugh.gif:
Also, if a rail is connected to only one other rail, it becomes a buffer; these are the points at which mine carts stop.
As for the carts themselves, I would have them act as an inventory with a 'Send' button that starts the cart rolling. If the cart is already rolling, right-clicking it to interact should stop it, in which case it will go to the next tile in its route before stopping. If a cart is stopped on a ramp it should also roll down it.
If two carts collide moving opposite directions, I suppose it would cause a derailment; if they collide and one is stopped, the other will simply stop, and if they're moving the same direction it's not really a 'collision' at all.
Pretty pictures would probably have been a good idea, I'm paranoid this will get tl;dr'd or just be hard to understand. :oops:
Right. It's funny that this thread was brought to life when it was, really. I've been working on an applet to demonstrate this, and was going to post this today or tomorrow. Since the topic has come up anyway, I may as well post it today.
Track Laying simulation applet
After playing around with it, I discovered that the system I originally described ended up being rather complex. Complex to code, complex to use. So instead, I came up with a system that has tracks only moving in one direction. This is not quite as useful as before, since now you have to make tracks in a loop if you want a cart to return, but there's ways to make it work both ways, I just haven't got there yet.
click on the grid to create a track, and click on the track to rotate it. right click rotates the opposite way.
once your tracks are set up, drag-and-drop a cart from the top corner onto one of your tracks, if you feel so inclined.
As before, I'm figuring that this would look, and work, well with tracks that go one block up or down for each new rail, to allow for (gentle) inclines
I'll probably keep tweaking this, since it is less than perfect, and it's good practice either way.
Oh, I also removed those restrictions I had mentioned before. They were just asthetic, and didn't strike me as particularily useful once I disbanded the old design.
A track connecting more than 90 degrees off from its original direction is probably not needed. That sharp of a turn is ugly, and the extra combinations you save by eliminating them can be put to otehr uses.
Tracks should connect to valid track pieces automatically by default. I should be able to lay down a long track simply by placing start points along the way. This applies for connecting to existing tracks and for unconnected tracks responding to new blocks.
I believe you mentioned it in the post, but it didn't make it into the applet, but it should only point to valid track connections. An unconnected track should for a standard 'end of rail' barrier.
If minecarts are implemented in an appropriate manner, it could be fun to ride a cart down into your epic town stretching over the land and yonder.
-The Point: -
If we can ride in minecarts, we already have trains. :biggrin.gif:
A simple suggestion on geology here.
~~~
Slaves of the Coal Mine
An interesting Novel to pass the time.
[*:z6qzpm7n]Resource cart - comes in several capacities, each costing a different amount of resources
[*:z6qzpm7n]Passenger cart - has a seat, so a player can ride it. Perhaps also bigger carts with three or four seats in a row.
[*:z6qzpm7n]Flat cart - nothing on it. Comes in different lengths, you can put blocks on top.
[*:z6qzpm7n]Possibly an engine, unless all carts have individual propulsion.
[*:z6qzpm7n]Other kinds? Perhaps a cart with some sort of weapon, kinda like in Zelda Spirit Tracks?
hehehe... The true Quantum Mechanics of minecraft :laugh.gif:
...I'm sorry. I'm waiting for Water...
*Puts on hat of seriousness*
Resource: What everyone wants, and probably what we will get.
Passenger: This would be fun, but not sure if Notch would ever implement it. (Me wants to use bows with this!)
Flat: A use please? (Besides, making a visible block move would require even more entities: I don't like this idea.)
Engine: Goes slow, but you don't have to follow it where it is going e.g., send it to another town for deliveries?
Amoured: Like passenger, but with iron roof. To avoid getting shot at.
Auto Turret: Shoot arrows automatically. (costs arrows (obviously) and perhaps coal? (fuel))
Hows that?
A simple suggestion on geology here.
~~~
Slaves of the Coal Mine
An interesting Novel to pass the time.
I'm thinking it's just a crate with track-wheels, basically. Possibly with several different sizes available, each with differing capacity.
Agreed. AWESOME.
Mobile bases and other constructions? Granted, that would probably be incredibly laggy. I mostly included these because real trains have them.
So normal trains/carts will only go if you're actively using them? That works. Alternately, it goes fast, but it requires fuel to operate.
Ooh, good one. Crafted just like a passenger cart, except you need to add some iron. Perhaps also diamond roofs for even better protection?
In addition, you can board it and fire it manually, saving the fuel but still using up the arrows. Perhaps.