Recently I started playing a game on my own, featuring some LL-RR main network. When I had to build my first ever 4-way hub for double tracks, I first took a look at the Junctionary just to find out that all hubs were designed quite different and hardly any of them follow all necessary rules (curve length, double bridges/tunnels, merge after split). I then started wondering if there’s a universal way of thinking about hubs.
There are only a few rules to follow when designing a hub with n ways:
- Every line that goes in goes out n-1 times (n times if you allow turning around)
- Merge after split – merge as late as possible
In addition there are a few OpenTTD-specific building rules:
- Curve length must be considered for all curves
- Bridges and tunnels must be doubled for flow
- When doubling bridges and tunnels make sure the lengths are the same (“syncing”)
There is nothing magical about these rules. But once you start building, you’ll find out that most of them are hard to obey, especially because usually there are lots and lots of crossings in a hub. Furthermore all those hubs tend to become unmaintainable, leading to jammed connections that nobody knows how to solve. So is there a way to get rid of the crossings and get a more clean design?
Let’s take a look at the image above: it shows a 4-way single-line hub following the general rules (without the building-specific ones): every line that goes in goes out n-1 times. Merging occurs right after the hub, allowing for easy balancing or whatever you desire.
The magic of this design is that it is really easy to understand and it is extensible. You can use this to build a 6-way or even an 8-way hub – it just makes the hub bigger, but not more complex!
This image shows the same technique applied on a 6-way hub. You can see that there is no difference to the 4-way hub but a bigger number of lines going around.
The building principle is as simple as it can get: inject an incoming line to the innermost ring and lead out all lines in parallel when building an exit. The outermost line leaves the ring completely when it has reached the n-1st exit.
Casting this into real rails
To test my theory I’ve designed 4×1 hubs and 4×2 hubs without signals but with doubled bridges and a curve length of 8.
The image above shows a single line 4-way hub using the given schema. Of course there’s room for improvement, e.g. saving space by bypassing the first exit and thus saving a row of bridges:
I left out the merging in my design, to show that any kind of merging (just connecting the lines or building load-balancers) can be applied separately for each exit.
The usual #openttdcoop hub is at least for mainlines of 2 tracks. So of course I had to build 4×2 hubs too:
As you can see inserting 2 tracks at once is absolutely the same as inserting 1 track. Taking the tracks out just requires more rows of bridges. Of course there’s also an optimized version of this hub:
The given hub design is quite similar to the roundabout hubs frequently used by inexperienced players (or if the network load is not too high), but without the merge-before-split disadvantage. I decided to name the hub design spiral hub (because the lines move 1 step outward at each exit).
- Easy to understand, easy to build and maintain
- Can be used for any sensible amount of tracks and entries/exits
- No jamming inside the hub if merger/load balancer is far enough outside
- Never ever merge before split
- Allows for easy exit-specific load balancing
- Quite compact regarding the used area (you can build them around mountains, towns, lakes, …)
- Can be used with mixed mainlines (e.g. rails + maglev)
- Can be built to allow turning around (just take out the lines one exit later)
- Fits anywhere where you can put some parallel lines with long curves
- Quite a big overall footprint
- Longer travel distances than e.g. for straight east-west lines
After building a few of these hubs I think the general way of designing them should be as follows:
- Build the hub according to the general schema
- Optimize it to use shortcuts where you really need them to improve performance
As long as the general schema is not broken, the hub will always work as expected.
I’m looking forward to testing this design in one of the oncoming Public Server games. Comments are welcome!