360° tracklaying prototype

[PJayTycy]

I can't reproduce the "hanging". It might be a java-on-linux issue. I don't have linux installed on my pc, sorry for that. I thought java would behave the same on all pc's, but it appears not so...

I had those hangs in previous (not public) versions, and they were quite "logical" : the GUI-thread was waiting for the checker thread and vice versa. I initially thought a similar thing was happening here, but it can't :

just before return : (33,219) - (17,219) valid = true
newCheck : (50,50) - (50,50) wait = false visible = true
start checking (50,50) - (50,50)
newCheck : (50,50) - (47,45) wait = false visible = true

The first 2 lines are output from the GUI-thread. The first line is the last output from initializing the tracksection already on screen when you start the application. The second line shows you have just clicked the mouse once and tries to check the tracksection between your first click and the current mouse position. Because you have not actually clicked the mouse, the "wait" signal is false, which means the GUI thread will move on, without waiting for the result.

The third line is the checkerthread, starting to check the first work it has received.

The last line is the GUI signalling a new tracksection to check.

Those 2 threads should not be waiting for anything at this time (or atleast not untill some other output comes to the screen).

I have 3 possible causes :
1) I don't have all output that should be generated by this time. This could be because of a different implementation of System.out.println() in Java for linux.
2) I do use some locks in the code, but I always lock the objects in the same order, so deadlocks should not occur. Maybe Java for linux doesn't take this ordering as strict as it does on windows.
3) I can't find a logical error.


I do hope it's number 1. I'm now working on a version with a little more debug info (about locks etc), that uses a log.txt file instead of the screen.

[PJayTycy]

So, I have a new version again.

No extra functionality.

=> I hope to have fixed the hang Zuu mentioned (although I couldn't reproduce it)
=> Debug info is now written to 3 log files (different level of detail for each log)
=> Very big speed increase (extended debug info showed me I could do with less redrawing). On my pc, I have a framerate increase from 2-3 fps to 20-30 fps.
=> Because of the previous point, the size of the "playground" doesn't influence speed anymore, so I increase the size from 200*200 to 512*512.

If anybody still notices "hangs" or other problems, please report them here, together with the 3 log files (zipped).

Next thing todo is a little more difficult: finding/testing algorithms for automatic track laying (eg : curves, straights, Bezier, splines, connect 2 existing sections, ...).

[PJayTycy]

I'm well on my way towards the automate track laying functionallity.

First some more info about what I want to automate: you choose a starting point+direction and an ending point + direction. Then the program will generate a corresponding route.

• It starts with creating 2 circles tangent to the both the starting and the ending direction (=4 total). I plan to give the user control over the radius of each of those circles (with a certain lower limit).
• Next, the algorithm will look for straight lines, tangent to 1 of the starting circles and 1 of the ending circles.
• The end result is a row of track segments, with 1 starting turn, 1 straight section and 1 ending turn.

The first point is already done and implemented in my prototype. Today I spent the whole day calculating (and mostly simplifying) the formulas for the second point.

Two screenshots to show this progress:

[edit]

• Is there any way to change the screenshot visible in my post? I would have like the prototype one to be shown, not the math one
• The complete text for the second screenshot is this:
  2 black sections = starting and ending point+direction.
  red sections = route the algorithm should propose.
  green sections = temporary help for me to see if the circles/tangents are drawn correclty.
  
  As you can see in this screenshot, the 4 circles are already implemented and working. The big red section next to the word "tangent" still needs to be implemented.
  It seems there is an upper limit for image comments

[/edit]

[Zuu]

To make images show in forum they must be <= 640x480 pixels big.

Your proto is looking good. Althroght I dont understand all the math. But I haven't looked at it so long, anyway. ( + I'm a better programmer than mathematician. )

[PJayTycy]

Ok, this feature is (nearly-) finished.


You define a start and a stop, then you can select/modify the route between them.

• You can turn the circle outlines on/off (screen is automaticly redrawn)
• You can choose 1 of 4 proposed routes, the shortest one is selected by default (screen is automaticly redrawn).
• You can change the radius of all 4 of the circles, this gives you endless possibilities to tweak the proposed routes.

I have some example screenshots to show.

General remarks :

• I used java 1.5.0 to compile this version. I don't know if it works with older versions. Please tell me if it works or not.
• I packaged everything in 1 .jar file. In windows environments, all you have to do is double clicking the jar. I don't know if this also works in linux etc. If not, type java -jar TE3DTracks014.jar" in a console window. Please tell me if this distribution method is prefered or the old one (unpacking zip file + running bat file etc).
• More comments about this method of tracklaying would be appreciated. Do you think it would be usefull in Transport Empire?

[PJayTycy]

last image + jar file


Damn, ".jar" is not allowed. I zipped the jar...

[Zuu]

Code: Select all

$ unzip te3dtracks014.zip
Archive:  te3dtracks014.zip
  inflating: TE3DTracks014.jar
$ java TE3DTracks014.jar
Exception in thread "main" java.lang.NoClassDefFoundError: TE3DTracks014/jar
$ java -jar TE3DTracks014.jar
Exception in thread "main" java.lang.UnsupportedClassVersionError: TE3DTracks (Unsupported major.minor version 49.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:251)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:55)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:194)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
$

[CmdKewin]

Are you Using the 1.5.0 Java Virtual Machine?...

[Zuu]

Code: Select all

$ java -version
java version "1.4.2-01"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-01)
Java HotSpot(TM) Client VM (build Blackdown-1.4.2-01, mixed mode)

[PJayTycy]

Code: Select all

Exception in thread "main" java.lang.UnsupportedClassVersionError: TE3DTracks (Unsupported major.minor version 49.0)

OK, that's apparently the error message you get when not using java 1.5.0.

I removed all 1.5.0 specific code and recompiled against version 1.4 (same I used before). I tested with both java 1.5 and java 1.4, they should work both now. I'll do that always from now on.

The other 2 comments still apply:

• I packaged everything in 1 .jar file. In windows environments, all you have to do is double clicking the jar. I don't know if this also works in linux etc. If not, type java -jar TE3DTracks015.jar in a console window. Please tell me if this distribution method is prefered or the old one (unpacking zip file + running bat file etc).
• More comments about this method of tracklaying would be appreciated. Do you think it would be usefull in Transport Empire?

[Zuu]

Source/binary dist
+ a run.bat is eiser to execute than to remember the java command for the jar file


.jar dist
I dont see any positive thing with this method.


I'm not sure which method that takes least space in my home directory. Smaller is offcorce better. But if its not a big diffrens (a few %) it does not realy matter.

If you choose the jar version and if its not to much work you can include a run.sh or run.bat or whatever you call it that contains "java -jar filename.jar".

---

More comments about this method of tracklaying would be appreciated. Do you think it would be usefull in Transport Empire?

I like your last curve functions. Althroght I think we/you have to make it esier for the end user to use. Some logic that selects good parameters and optionaly (if possible) a slider that tunes the parameters in a smart way. Preferable the logic should optimize for speed. But an optional feature could be to optimize for shorter dictance. Now Im spinnig away... Maybe one side of the slider can be optimize for highest speed, and the other one optimize for shortest dictance.


And the question weather this tracklaying method will be usefull in TE. As I've probably allready have said. I think that with a grid system that is justified to the map cells that can be switched on/off I think this tracklaying aproach can be realy usefull.

We can also have a switch that restrict tracs to go in a fixed set of directions, but I dont think that is that necessary. The risk/problem is that curves won't be any good if you restrict tracs to go in 8 directions as in TTD. But that can probably be solved by making curves with tracks in "forbiden" angles and then make all track parts of the curves be deleted if one is selected for deletion. Anyway I dont think there is that big need for this, as a grid will restrict enoght to make tracklaying esier. Maybe for longer dictances a look to n degrees will be usefull. Nw Im drifting away, and if I dont stop Chris will send me to Siberia.

The downside with this way of creating curves is probably that it is more cpu intense than having prebade curve sections.

[PJayTycy]

Source/binary dist
+ a run.bat is eiser to execute than to remember the java command for the jar file

I didn't know .bat could be executed on linux OS'es. If that's the case (and .jar can't be executed), I'll use the .bat method again.

I like your last curve functions. Althroght I think we/you have to make it esier for the end user to use. Some logic that selects good parameters and optionaly (if possible) a slider that tunes the parameters in a smart way. Preferable the logic should optimize for speed. But an optional feature could be to optimize for shorter dictance.

The current algorithm gives you the shortest distance as default (assuming 36 "units" as minimum radius for turns). You might have noticed, there are always 4 possible routes, and the algorithm selects the shortest one everytime you change the circle's radiusses.

The "fastest" track is more difficult: imagine 2 stations with track running top-bottom, one station on the left and one station on the right of the map. What would be the fastest route ?

• A sharp 90° turn => long straight section across the map => sharp 90° turn.
• One big turn so you end with a very big half-of-a-circle on your map

If you want to do such speed optimization, you have to know the acceleration and general speed properties of the train + the speed at the beginning of the section + the speed at the end of the section. A sharp turn just before or just after a station stop isn't that bad, but a sharp turn when the train is at full-speed is bad.

If anybody wants to test such an algorithm in this prototype, I will certainly help wherever I can. If somebody has an idea about how to do it, please tell me. One thing I have often noticed myself doing is enlarging the circles till they just touch each other (see example in previous screenshots).

----

I think that with a grid system that is justified to the map cells that can be switched on/off I think this tracklaying aproach can be realy usefull.

I guess that's the same as what I thought of. Maybe for a next version, I could actually draw the map grid too + some "occupied by buildings areas" (so we have a better feeling of space / scale). Right now, I'd think of anything between 8 and 64 track units / cell. This would make the length of 1 tracksection between 2 cells and 1/4 of a cell.

I don't really understand how you could turn this on/off by a switch though. What I described above, would you call that on or off? And what would the other option be ?

1 trackunit / cell would be very ugly and un-usefull in my opinion. (1 tracksection would be +/- 16 cells long).

Anyway I dont think there is that big need for this, as a grid will restrict enoght to make tracklaying esier.

Now I'm even more confused about what you have in mind about this grid. But, do you think the current implementation makes tracklaying too difficult?

The downside with this way of creating curves is probably that it is more cpu intense than having prebade curve sections.

Currently it's not really CPU intensive, but it certainly needs a lot of memory. Each point on the map is a datastructure with a linked list of tracksections that are connected to it (this list is ofcourse empty for 99% of the points). This makes it a lot faster to search for existing tracksections (ie : for the angle-checking, drawing routines, collision detection ...)

[Steve]

Looks complicated. Maybe not to us bright minds, but to the average gamer.. they just want a track from a to b, not to be messing around with circles. The idea is great, but i think it would be best to hide all the details and make the algorithm make the choice about the radii for the user.
If your going for fastest route, could you not presume the train accelerates the same rate no matter what the track type? Then measure times for the corners and straights.. should be simpilish. Unless your not going to do constant accel.. in which case you guys are going insanely overboard!

[Steve]

After a nice sleep i had some thoughts concerning how track would actually be built. The main problem with trying to work out the fastest route between 2 sections is that you don't know how fast the train will be entering and leaving the section. If it's just starting off, then you can have a tight corner but you'd need wide corners to conserve speed later on. It's probaly best to just ignore such things and give a single option on the relevant control panel for curviness, which then changes all the circles together for the sake of simplicity.

Useless info: An ellipse would be better at a station entrance rather than a circle, as if you put the tight end on the station, with it pointing in the direction you want to go, the max speed of the curve would be similar to it's acceleration, so you wouldn't lose efficiency from speed loss or extra distance travelled.

The following is how i imagine building track such as this in the game. You won't be making a single line from station to station, you would instead build the route in segments. After opening the relevant stuff, you click a starting point and then move your mouse where you want to go. A line will be drawn as a guide to where it'll build the track so you can see what's going on. Setting starting and ending directions may be helpful too. When your happy with that segment, you click on it's destination and a ghost version of the track appears.
Now, this isn't the final draft. One of the more annoying aspects of TT and Loco is that once you've built something, if it's wrong you have to delete it and start again. Instead, you can drag on points between bits of track on the ghost model to reroute the segment. Using the start and end points as anchors, altering over track pieces to maintain some kind of smooth corner.
Then click the big red button and it'll be built for real.

This system only really works for flat ground. If you want to go through a hill, then the entrance and exits are important. So you'll build a segment up to the hill (show a special symbol to show that the next segment will be underground). You then build a underground piece or several, to get back to the surface. Continue as normal.

Running over hills can probaly just be built into the main route, any gaps under rails can be raised automatically, so it looks a bit like my earth slopes for loco.

Bridges.. now i'm not too sure. Perhaps similar to tunnels, you finish a segment where a bridge should start, click the big bridge button and choose the type and choose the exit on the other side of the obstacles. It could automatically make it high enough to get over other tracks and buildings and then you can fine tune the ghost form.

Yea.

[PJayTycy]

It's probaly best to just ignore such things and give a single option on the relevant control panel for curviness, which then changes all the circles together for the sake of simplicity.

I agree, it's unnecessary to provide options for the 4 circles. As each route only uses one at the start and one at the end, we only really need 2 sliders for the same functionallity : one for curviness at the start and one for curviness at the end.

An ellipse would be better

I know. It's not difficult to put it in the game technically, but how to make it easy to use is another thing. (Splines/Bezier/... are technically possible too)

The following is how i imagine building track such as this in the game. You won't be making a single line from station to station, you would instead build the route in segments. After opening the relevant stuff, you click a starting point and then move your mouse where you want to go. A line will be drawn as a guide to where it'll build the track so you can see what's going on. Setting starting and ending directions may be helpful too. When your happy with that segment, you click on it's destination and a ghost version of the track appears.

What you describe is exactly how tracks are laid in Railroad Tycoon 3, except for the starting/ending directions. A lot of people (including me) were annoyed by the lack of control. Annoyances included :

• No control of ending direction of the track (ie: the game proposed a wide 20° turn when you really wanted a sharp 90° turn)
• No control of "branch" point : when you wanted a junction, track would often follow the main line longer than you wanted.
• In general : not enough control over what will really be build.

One of the more annoying aspects of TT and Loco is that once you've built something, if it's wrong you have to delete it and start again. Instead, you can drag on points between bits of track on the ghost model to reroute the segment.

That should be possible (and usefull).

This system only really works for flat ground.

To cope with hills, there are some differences in how some games work. Railroad Tycoon 3 will try to follow the ground level untill a max slope%, if the slope is too big, a tunnel or bridge will be automaticly build. Here again there were a lot of complaints because there was not enough control over where exactly a bridge or tunnel should be build. Trains & Trucks Tycoon (or 3DTT) uses a not-ever-changing slope %. You define the height for the starting point and the ending point of the segment, and the whole segment uses one constant slope (automaticly creating bridges/tunnels/cuttings when needed).

If you want to go through a hill, then the entrance and exits are important. So you'll build a segment up to the hill (show a special symbol to show that the next segment will be underground). You then build a underground piece or several, to get back to the surface. Continue as normal.

I guess you're thinking too much Rollercoaster Tycoon here Tracks should be able to have any slope/height. If they are close to the ground, either a small hill or a cutting should be made automaticly. If they are high above the ground, a bridge should be drawn, if they are below ground-level, a tunnel should be drawn automaticly. Something which annoys me in TT is how bridges/tunnels are so "special". You can't place signals in/on them, you can cross tunnels, you can't make a turn on a bridge/tunnel, ... I would like to treat briges/tunnels in our game just the same as normal track.

If bridges/tunnels are automaticly created based on the height of the track, the only problem that remains is: how to let the user set this height easily.

In my prototype, everything is still flat though

[Zuu]

Source/binary dist
+ a run.bat is eiser to execute than to remember the java command for the jar file

I didn't know .bat could be executed on linux OS'es. If that's the case (and .jar can't be executed), I'll use the .bat method again.

They cant be executed right on the way. First I have to give it right permisions

Code: Select all

$ chmod u+x run.bat

and then I can execute it. Unix/Linux doesn't care about what you call the file but what permissions it has.

I like your last curve functions. Althroght I think we/you have to make it esier for the end user to use. Some logic that selects good parameters and optionaly (if possible) a slider that tunes the parameters in a smart way. Preferable the logic should optimize for speed. But an optional feature could be to optimize for shorter dictance.

The current algorithm gives you the shortest distance as default (assuming 36 "units" as minimum radius for turns). You might have noticed, there are always 4 possible routes, and the algorithm selects the shortest one everytime you change the circle's radiusses.

The "fastest" track is more difficult: imagine 2 stations with track running top-bottom, one station on the left and one station on the right of the map. What would be the fastest route ?

• A sharp 90° turn => long straight section across the map => sharp 90° turn.
• One big turn so you end with a very big half-of-a-circle on your map

If you want to do such speed optimization, you have to know the acceleration and general speed properties of the train + the speed at the beginning of the section + the speed at the end of the section. A sharp turn just before or just after a station stop isn't that bad, but a sharp turn when the train is at full-speed is bad.

If anybody wants to test such an algorithm in this prototype, I will certainly help wherever I can. If somebody has an idea about how to do it, please tell me. One thing I have often noticed myself doing is enlarging the circles till they just touch each other (see example in previous screenshots).

----

Thats true. I didn't thought about how to implement it, just what would be usefull.

I think that with a grid system that is justified to the map cells that can be switched on/off I think this tracklaying aproach can be realy usefull.

I guess that's the same as what I thought of. Maybe for a next version, I could actually draw the map grid too + some "occupied by buildings areas" (so we have a better feeling of space / scale). Right now, I'd think of anything between 8 and 64 track units / cell. This would make the length of 1 tracksection between 2 cells and 1/4 of a cell.

I don't really understand how you could turn this on/off by a switch though. What I described above, would you call that on or off? And what would the other option be ?

1 trackunit / cell would be very ugly and un-usefull in my opinion. (1 tracksection would be +/- 16 cells long).

What I meant with switch on/off grid was to switch on/off snap to grid.

I want to have a grid system where one cell is somewath the same size as in TTD. Why? Becuse I love to build complex junctions. And when buildning junctions you dont want to be able to build each track part from virtually any spot to any other spot. That would mean that you wont be able to reproduce a junction. Creating double track (2 paralell tracks) manually would be would be a nightmare.

So I want to have a snap to grid which as in TTD lets me create advanced junctions, but limits me too. I dont know if I cant explain it better without paper.

Anyway I dont think there is that big need for this, as a grid will restrict enoght to make tracklaying esier.

Now I'm even more confused about what you have in mind about this grid. But, do you think the current implementation makes tracklaying too difficult?

See previous comment.

The downside with this way of creating curves is probably that it is more cpu intense than having prebade curve sections.

Currently it's not really CPU intensive, but it certainly needs a lot of memory. Each point on the map is a datastructure with a linked list of tracksections that are connected to it (this list is ofcourse empty for 99% of the points). This makes it a lot faster to search for existing tracksections (ie : for the angle-checking, drawing routines, collision detection ...)

Does the tracks take lot of memory when the tracks are laid, or just when laying them?

[Steve]

Let me just say i've never played Railroad Tycoon. Never.

What you describe is exactly how tracks are laid in Railroad Tycoon 3, except for the starting/ending directions. A lot of people (including me) were annoyed by the lack of control. Annoyances included :

• No control of ending direction of the track (ie: the game proposed a wide 20° turn when you really wanted a sharp 90° turn)
• No control of "branch" point : when you wanted a junction, track would often follow the main line longer than you wanted.
• In general : not enough control over what will really be build.

Well, if we add a direction thing at the end and then when you build a track that you want to junctionize, you just end it on the main line exactly where you want it to join. May be nice to extend the planning mode, so you can plan multiple segments together before committing to a build, helpful for sorting out all the different routes on a junction.

I guess you're thinking too much Rollercoaster Tycoon here Tracks should be able to have any slope/height. If they are close to the ground, either a small hill or a cutting should be made automaticly. If they are high above the ground, a bridge should be drawn, if they are below ground-level, a tunnel should be drawn automaticly. Something which annoys me in TT is how bridges/tunnels are so "special". You can't place signals in/on them, you can cross tunnels, you can't make a turn on a bridge/tunnel, ... I would like to treat briges/tunnels in our game just the same as normal track.

If bridges/tunnels are automaticly created based on the height of the track, the only problem that remains is: how to let the user set this height easily.

But tunnels and bridges are A LOT more expensive that building a little embankment. You really shouldn't make them automatically. True, make little cuttings or hills to put the track on the ground and allow track to make small hills. But for big hills, you'd select a bridge properly.
For setting the height, you could just have a key press combo in plan mode, hold shift and the point moves vertically rather than horizontally. And on the bridge panel a general height property could be used. If you want some bits high, some bits low, you could always make the bridge in 2 segments (depending on bridge type).

In fact, this may allow easy use of both strict size bridges (like a suspension bridge) and free form (brick bridges).

[PJayTycy]

I want to have a grid system where one cell is somewath the same size as in TTD. Why? Becuse I love to build complex junctions. And when buildning junctions you dont want to be able to build each track part from virtually any spot to any other spot. That would mean that you wont be able to reproduce a junction.

I see your point. Exactly recreating a previous junction might be difficult / impossible when you have more freedom. More restrictions would also require more thinking/planning ahead, maybe you could say a freeform system would be too easy / not challenging enough ?

Creating double track (2 paralell tracks) manually would be a nightmare.

I've thought of this one before, and I think it's possible to do that automaticly.

Do the tracks take lot of memory when the tracks are laid, or just when laying them?

The tracks themselves don't take a lof of memory, the grid (=the points) does. Not because of the amount of data stored for 1 point, but because there are so many points for this system.

[Lega-C]

i see your point. Exactly recreating a previous junction might be difficult / impossible when you have more freedom.

unless if you can choose from a list of junctions to create the exact same junction and it also helps the ones who are not so good at building junctions... well at least the most complex should be choosable at the list!

thats just my opinion

[Steve]

I want to have a grid system where one cell is somewath the same size as in TTD. Why? Becuse I love to build complex junctions. And when buildning junctions you dont want to be able to build each track part from virtually any spot to any other spot. That would mean that you wont be able to reproduce a junction. Creating double track (2 paralell tracks) manually would be would be a nightmare.

So I want to have a snap to grid which as in TTD lets me create advanced junctions, but limits me too. I dont know if I cant explain it better without paper.

I disagree so much.. what's the point of using an old limited system? If you want to create TTD junctions, do it in TTD! This game shouldn't just be Transport Tycoon 2, it should be so much different that it is something completely new and yet just as easy to play.
Junctions would take up A LOT more space due to the curviness of curves, but we can balance that with much bigger maps, move towns and such further apart. That would give us more realistic (and much more fun to watch) junctions and still allow us to make complex and crazy junctions.

In theory, they could be more complex. I remember a program on Discovery about the new transport route through Boston (i think). They couldn't just demolish things that were already there, they had to weave between them. They had to dive deep under a canal and then squeeze a new bridge into the city and such, before they could think about removing old ugly highways. This kind of thing simply isn't possible with a square based system but it's something i'd just love to try and deal with.