NIMBY Rails Version 1.2 beta is launching today

After two months of work the new major version of NIMBY Rails is ready for testing. It has been a massive amount of work to overhaul all the game systems so single track it not just possible (the easy part) but actually functional (the hard part) and playable (the hardest part). Switch your Steam branch to “beta” (no password required) if you want to try it, and keep in mind it’s early days for the v1.2 series.

v1.1 importer

Roughly half of the past month development was invested into the v1.1 importer, to carry over v1.1 saved games into v1.2 as fully featured as possible. Apart from the obvious advantage for v1.1 players, it has also proven to be a very useful feature in bringing up all the v1.2 systems, by using player contributed saves as real test cases. This way v1.2 has already been tested with the most complex maps v1.1 has ever seen.

Signals and signal editor

A full set of user controllable signals and a signal editor were implemented. The track editor now has two new modes, edit signal and new signal.

The new signal mode (button icons are pending) shows a signal palette and allows users to place signals by clicking anywhere on a track, automatically snapping to a valid position.

The edit signal mode allows to select signals and shows a panel editor for their properties. Some are cosmetic, like the side of the track (the game is completely agnostic about track side). Others are important and have gameplay influence, like facing direction. Here’s an introduction to the initial v1.2 signals:

One way

The one way signal forces the train pathfinder to only consider crossing over the signal point in the signal direction.

Platform stop hint

The platform stop signal is a hint for the train AI to stop the train at the signal point in station platforms. This is useful if the platform includes for example a branch trains may need to take, to force them to stop before the branching point.

Simple block

The simple block signal delimits a simple exclusive block of tracks, and it is capable of stopping trains. Every track behind the signal (up to 10km) is scanned for trains, and if any train is present, the signal is red and blocks incoming trains. The track scanning stops when another simple block signal is found, or when a block balise is found. While scanning tracks every branch is considered (including those that have the opposite direction), and every diamond intersection.

This signal DOES NOT contribute to train pathfinding in any way. This means that trains won’t take branches to avoid red block signals.

Block balise

A block balise delimits a block of tracks, but it is not capable of stopping trains. Its function is to be able to close a block of tracks without introducing another block of tracks, as it would be the case if only the regular block signals were used. Block balises enable NIMBY Rails to support signal track blocks only in the areas where they are important, like stations and switches, and avoid them in the bulk of the track network.

It is not necessary to add block signals every X meters in normal (non branched, non intersected, non station) tracks, as it is in other games and most real world track networks. This is because a head-tail train collision is not considered a collision in NIMBY Rails, and it will eventually evolve into a virtual block system like ETCS Level 3.

Re-blueprinting

It’s expected that players will want to do many tweaks to imported v1.1 maps, so the game now supports marking built tracks as blueprints. Just select one or more built tracks in the track editor and press Insert. The tracks then become blueprints and you are free to move them in any way. This may invalidate line paths, but even blueprinted platforms should remain in the line stop listing, even if they cannot have trains pathing into them.

Parallel track constraint system

A major issue with the single track project is the usability of laying parallel track. I’ve studied other modern games which are also based on freeform curves and lines, and realized they sidestep this issue by featuring track creators rather than track editors. By making track laying a single step process, it becomes possible to use snapping (and other often requested features, like seamless tracks without control points). But NIMBY Rails is built around the idea of a track editor. When the player lays a track in blueprint mode they can come back and move it any way they desire. For this reason snapping is not an option. If something “snaps”, it has to remain in place in any subsequent edit the player does to the original track.

After trying many ideas I realized the game already features a similar system in the way branches work. They are constrained tracks, in the sense their editing is constrained to what a parent track allows them to. So I decided to use the same design for parallel tracks. This way parallel tracks become another kind of constrained track, and they can move and adapt automatically to their parent track. Parallel constrained tracks automatically place their control point relative to their parent control point, given a direction and offset.

This constraint system is a bit more complicated than branches, but most of the time it just works and its details can be ignored. The new 2x mode in the track tools also make it almost as usable as laying simple track.

2x mode tools

Creating new parallel track is as easy as enabling the “2x” mode in the track editor, and it is done by default. While in 2x mode tracks continuation, branches, and links also consider any existing parallel tracks and attempt to connect to them. It’s sometimes impossible to decide properly in the face of opposite track parallel sides, so the player can use the Alt key to override the track side picked by the game while linking tracks.

2x mode platform creation has an extra set of options to automatically create signals and scissors crossovers at the track ends, and also to pick a driving side for those sets of signals.

Line service level

An often requested feature, line service levels allow to close or open a line service when the player wishes to. Newly created lines now start closed, and the player can add stations to the line without pax considering the line for their travel plans. It’s also possible to put the line in a “empty trains” mode, which runs the line trains but still makes it ignored by pax.

New line auto timing system

The line times calculator is no more. The v1.1 conclusion of this system is that it’s a bad UI/UX, and that line timing should be much more closely managed by the game.

Lines leg times are now always automatically calculated. This means that as soon as a train has been assigned to a line the timing logic will automatically calculate the leg times for the entire line, without waiting for any extra player input. Values like the service speed (former min. speed) or the line interval are now by default automatically calculated too. Players only need to select the stops, buy one or more trains, and open the line. No more calculator.

More advanced players still have tools to influence line timings. The service speed of the line and the min. stop wait time can be modified, both the default line value and a per-stop value if desired. But the interval system has undergone a deeper change. There is now only 2 possible intervals for a line stop: the default interval time (which the player can modify), or 0. By default all stops have a 0 interval and only the first stop has an interval wait. Players can switch this to have all the stops waiting on the interval, or to manually pick which stop(s) are going to wait on the interval.

The reason for these timing changes is two fold. One, as explained earlier, the old way was very advanced, but it was a UX disaster. Players keep complaining about bad AI when they just needed to click a couple buttons in the calculator (and the UI warned them to do so in multiple places). Second, it was never intended for the interval-based line timing system to be a fixed timetable system. It can be done with a lot of effort, but keeping it that way means I cannot evolve it or even fix bugs, as it happened multiple times in v1.1. With this new system I can fix bugs in the train AI and the timing system and line timings will be automatically updated. A fixed timetable system is coming in the future and it will be manually editable second by second, but the interval based line time system is not it.