With the summer coming to its end, we finally have a new content update ready in the testing branch. It took us more time than we initially expected. And the reason was not the summer vacations Mišo and I took with our families but the number of changes we did “under the hood.” We already mentioned some of the features in the 1.1 update, but here are the other ones (and I probably forget some of them).

Input System

We have switched from the Unity legacy input system to the new one. We would like to support touch screens and controllers in the future and also allow you to customize the controls in the options. Our only excuse was we were in the early access, but the feature was requested by our community a lot. We somehow thought that doing that with the old system was not the best approach. What we did not expect was the number of issues we had after the switch. It seems the system is still under heavy development, so we needed to take care of many bugs. There are still a few left to be solved during our testing period on the unstable branch. For example, the scroll wheel under Linux is heaving a minimal sensitivity. This kind of issue.

Performance

Another chunk of changes from the under-the-hood category were the performance optimizations. We are looking at the game performance from time to time, and it has already been some time since our previous iteration. The performance optimizations are somehow different from other changes to the code. Because you can create a lot of “side effects,” you cannot forecast. At first, you think you can, but the reality is usually different. We have many unit and integration automated tests in Rail Route, but they were not enough to catch everything. The good thing is we are having “the game is more smooth” feedback from our community. And that’s why we did that! It seems the effort paid off. Hopefully.

Refactoring

We were not sure if the game would be 3D at the early stages of our prototypes. That’s why we were still using a mixture of 3D colliders and 2D colliders. I took the time to remove 3D physics from the game altogether and replace that with 2D only. We do refactoring quite a lot to maintain the high quality of code. That helps us to implement new features much faster while reducing the cost of maintaining the old code. This time, I was wrong with the expected effect. At first, I hoped the code would be better without any 3D physics, but the reality was different. I got substantial performance problems and issues with 2D physics. That’s the price for the refactoring. We also manage to improve code quality in other areas, but that’s not so important.

Urban Trains

We hope the players will benefit from all the changes mentioned above, but we realize they are not features they will enjoy. So we brought a surprise: Urban Trains. We never spoke about them, so it was a surprise even for our alpha testers when they first touched 1.1.0. We hope they will bring more variability mainly to the endless game due to their unique scoring model: their schedule is not explicitly defined when accepting the contract.

The trial train creates it while traversing the map. The reward is computed based on the number of unique stations the trial visits. They never leave the map and should end in the same station they originated from. It is up to the player; are they representing tram & underground lines with dedicated tracks, or are they sharing the tracks with other trains like S-Bahn does in Germany? The goal is still the same: to connect as many stations as possible in the shortest possible time.

 

Sensors on Autoblocks

Many times we saw how players pursued their own goal to automate a map fully. Many times we saw the suggestions regarding our automation. One of the most prominent was the need to automate the exit of the autoblocks. Indeed one can put a routing sensor in the front of the entrance, but for long autoblocks, the tracks become occupied for a long time without use. Now, routing sensors can be built in autoblocks. Like departure sensors on platforms, they control both signals of the autoblock (but only if they are not manual). Unlike them and routing sensors built on tracks, they trigger as trains enter the last segment before exiting the autoblock, no matter of direction. (So they act as two unidirectional routing sensors built near both exits of the autoblock).

Now we have an everlasting discussion if this iterative approach – just to add sensors where needed – is the right one. It seems that the sensors shall interact. If there is a routing sensor and an arrival sensor next to each other (both controlling the same signal), the trains handled by the arrival sensor shall not fire the routing sensor, for example.

There are various alternatives, mainly:

• Enabling the player to build multiple sensors in the same place.
• Enable the player to build one sensor (e.g., Train Run-over Sensor or Train Departure Sensor) and buy multiple automation modules (e.g., Long-distance Routing module, Arrival-to-Platform Routing module, Reversing module, …)
• Completely splitting the sensing logic (sensor triggering an event, e.g. a train is here) and the automation logic (actuator operating signals and switches according to the event). Here we have an idea that the events could be color-coded according to player’s configuration. E.g., in a particular sensor, trains going to London trigger red event while trains going to Liverpool and Manchester trigger blue event. Then, the actuators would create routes according to event colors (red to this track and blue to that). It would enable the player to combine the colors visually to build complex logic from basic elements (e.g., route freight trains differently despite heading to the same station, apply and logic operations and much more).

But that’s maybe for the future article. I’d suggest you peek into unstable branch at the moment if you are brave enough. We will release this update into the stable branch once all major issues will be solved.

By the way, we are still working hard on a new tutorial! We would like to bring it in the next update. But it’s taking us more time as we really want to do it right this time!

Happy Dispatching
Mišo & Angel