No Im not talking about the type of training that usually involves something called a pbag and a attack verb. Im talking about actual trains.
Im working on a game, and in this game I plan too have public transport. This will mean adding buses, trams, and naturally trains.
Now Im faced with a problem, how do I make the trains work? Ive got the basics written up. How to get on, how to get off, how too pay to get ride, ect.
The only thing I need to figure out now is how too make them actually run along the tracks.
I have a few ideas, so I figured you guys could give me some feedback.
1) Just make it so that a train mob will always move on to the nearest track peice (Other then the one it was just on), and if that peice is a station it will stop and wait for a few seconds for people to get on and off.
2) Just make it so that a train mob will constantly move in the same direction, unless it enters a station (Causing it to stop for a bit), or a corner (Causing it to turn).
3) Just build the path into the train mob. This could work out pretty well since it will probably be how the buses operate. Although it probably wont be good if the city ends up being large.
Anyway, thanks for the help.
ID:153694
 Apr 27 2003, 2:40 pm
|
|
|
Apr 27 2003, 4:50 pm
|
|
Elorien
 |
Instead of making the train move, why not make the track move the train? o.o Setting up the tiles next to the track to not let people walk ont he track (so they dont get stuck on it) would prolly be a good idea too ^^; then just stick in a delay for the stations to let people get on and off
|
You know how popular Model Trains are?
I wonder how successful a game would be to lay your own tracks and build your own Model Train sets in BYOND? Then you could invite and allow others to move around as spectators to view. LJR | |
That would be a pretty good game too see. With enough differnt track types, train types, saving, and turrain types it could be a rather fun toy tooo play with.
| |
http://www.auran.com/trainz/ =) (Okay, so it's not a BYOND game, but it is a model trains game. <font size=-3>And guess which country it comes from? Aussie! Aussie! Aussie! So it must be good. ;-)</font> )
Back on topic... I'd just make the train move itself to the next piece of track. To work out which piece is the next one, have a var that points to the next piece. To make it easier to set up, though, you could just make the train move forward if the piece of track it's on doesn't define a "next" piece - i.e. the var is null. (You also might want to make sure that there's always a piece in front of the train before it moves forward; that way you avoid the train going off the rails if the track hasn't been set up properly.) If you wanted to let the trains go both ways on the same piece of track (a potential recipe for disaster, though! =P), then just have two vars - one that points forwards, and one that points backwards. You could even make the track "autojoin" itself by automatically working out which piece is the next one and which is the previous one. It might just be easier to set it up by hand, though. =) | |
I can imagine that it would be easier in creating and in setting up using auto-joining. you can simply make a proc to check what the turfs name is and then you know which directions it can go.
| |
That would be ridiculously difficult.
Here's the method that I would recommend. Train checks turf immediately forward from its current direction (get_step(src, dir)). If a track exists there, Move() into that turf. Otherwise, train checks the turf immediately to the left of its current direction (get_step(src, turn(dir, -90))). If a track exists there, train checks the turf immediately to the right of its current direction as well (get_step(src,turn(dir, 90))). If a track exists there too, train Move()s into a random one (pick(left_turf, right_turf)) -- more complex selection of directions can be done too. If a track doesn't exist there, train Move()s into the left_turf. If a track doesn't exist to the left but exists to the right, train Move()s into the right_turf. Otherwise, train reverses direction and goes the other way -- the train reached a dead end. No need to check if there's a track behind it because it's obvious that if a train reached the dead end, then it arrived on a track. Different track pieces would have "accelerator" objects nearby. When a train engine passes an accelerator, it speeds up or slows down to the speed given on that accelerator. Thus, by placing accelerators all over the tracks, you could simulate the train speeding up and slowing down to make turns, turn around, or arrive at a station. You just need to remember that an accelerator can be passed in both directions, so placing accelerators should always include accelerators of the same speed as the train is going before slowing down -- that'll produce the desired effect of speeding up to the same speed when going in the other direction. When the train arrives at a station, its speed is set to zero for 15 seconds. After ten seconds, a little whistle blows, and after fifteen seconds, its speed gets set to 1 again and off it goes on its merry way. | |
That sounds like a winner. Although it gets into a little bit more detail then I need with the accelerator objects, but if someone made a Toy Train set on BYOND they would have to include that.
Thanks Spuzzum. | |
I'll probably add slowing down to enter a station but it shouldnt look too strange in the setting Im using it in. After all the game isnt about trains at all, I just thought it would be nice too have public transport in to help people zoom around town.
| |
That would be ridiculously difficult. I don't know about you, but I don't find that method particularly difficult. A simple autojoining algorithm - not unlike your method, in fact (they both choose which way to go based on surrounding conditions) - would connect the track up, and away you go. It would take a similar amount of programming effort to do either. It's not "wrong", it's just different. Just a matter of style. | |
Crispy wrote:
That would be ridiculously difficult. But the way you originally had it, it wasn't an autojoining algorithm -- I believe you specified in there somewhere about building the track manually. And *that* would be ridiculously difficult. Besides, that method would also not be easily modifiable at run-time -- that is, once the tracks are down, trying to place new tracks would necessitate recalculating all of the adjacent tracks within a radius of 1: the method I suggested has no need to autojoin tracks because the train identifies its current situation automatically and takes action upon it. It's not "wrong", it's just different. Just a matter of style. Who said anything about wrong? Certainly not me. ;-P | |
Spuzzum wrote:
Crispy wrote: Not difficult exactly, just extremely tedious. =P Besides, that method would also not be easily modifiable at run-time -- that is, once the tracks are down, trying to place new tracks would necessitate recalculating all of the adjacent tracks within a radius of 1: the method I suggested has no need to autojoin tracks because the train identifies its current situation automatically and takes action upon it. Recalculating the tracks wouldn't be too hard, but I see your point. It's not "wrong", it's just different. Just a matter of style. I'm sure I saw the letters "w", "r", "o", "n", and "g" in there somewhere... whether or not they're next to each other is completely irrelevant for my purposes! =P I guess I got a little cheesed off at the "ridiculously difficult" bit. =) | |