v1.2 started development in April but it is not public

All the changes and new features mentioned in this post are already implemented at the time of writing, but they are not available in any public released version of the game.

Station-train pax flow review

The 1.1 development saw many independent tweaks and fixes to the station flow code, and it arrived to a point where too many checks and special conditions were being applied. A full review and a rewrite was required. This was highlighted by the late 1.1 bug with full train leaving pax on the station that could have boarded.

1.2 has a new system for loading and unloading trains at stations. Like the latest development in 1.1 it is based on sorted lists of pax by destination and keeping the last considered destination as a bookmark into the list, but unlike 1.1, it is now performed from the POV of the train, not the station. This means trains iteration over the station pax are independent of any other train in the same station. Additionally the station flow (the pax/s considered by the pax loading AI) has now been made more robust and independent of game speed and other train activity. And finally it has been made generic enough that the same semantics are applied for all 3 kinds of flows (station new pax, station transfer pax and train unloading).

Static vertex buffers for track tile cache

Players keep building larger and larger networks and the game needs to adapt to support them. 1.1 already moved to draw tracks using cached geometry for a speed improvement, but said geometry was being stored as dynamic buffer. Dynamic buffer space is limited and thus some players were able to hit the limit. 1.2 is now able to promote track tiles into static buffers and upload them to the GPU after some time has passed since their last edit, keeping the dynamic geometry limit only for the tiles being actually edited. This has also made it possible to re-enable the fix for missing slivers of tracks around tile limits.

Preliminary work for track mods

The game doesn’t have anymore a predefined set of tracks. Instead tracks are expressed as another rules data object, like trains are, and it’s able to consider any number of them. A dynamic texture cache system has also been implemented, like the one used for trains. This is not mod support for tracks, but it’s the required previous step.

A decision had to me made about track layering, and now the game has 3 conceptual track layers: viaduct, ground and tunnel. Track rules declare to which layer they belong to, and how they react versus the other 3 layers (ignore, collide or diamond intersection).

Single track

After the previous set of changes was implemented, it was time to enable single track. It took a grand total of ten minutes, since as I’ve explained in the past, all the track in the game is actually single track with a double track texture and special “two trains allowed” rules in the pathfinding, train collision and train display code. These special rules were removed and the game is now single track. But this is just the trivial first step of making single track playable, and much work remained for the month (and still does).

Most of the remaining work is in the UI/UX of the game, and in the 1.1 importer. Single track will require an improved track editor to make it easier to build parallel track

New track textures

The super low resolution track textures used by the game in version 1.1 were always a placeholder until single track was implemented. I remade them to represent a single track, and to have the same pixel density of train textures.

Track textures have 4 layers: border, base, sleepers and rails. These are displayed and overlapped in the correct order to make things like branching tracks or diamond intersections look much better than with the old textures. Also by matching the train texture scale it’s possible to reproduce real world railways at the correct gauge. The bundled game textures reproduce the 1435mm UIC gauge (minus a couple cm to keep the rail pixel borders sharp).

Single anchor point, no limits branches

Track branches have been reviewed and most of their limitations have been removed. The most important change is that branches are now anchored to their parent at a single point. This makes it possible to start a branch at any track position. In turn this means a branch doesn’t really care about its parent geometry so it can be as short as desired. For example here is a very short parent track segment with a branch (which in turn also has a very small curve radius, another top request):

This work also enables blueprint branches to have their anchor point moved to any valid parent track segment, with automatic snapping, even after being created:

Diamond intersections

Track vs track hit conflicts are no more. Every instance of a track conflict is now a diamond intersection, and it won’t block construction of tracks.

Diamond intersections are not track switches. Trains cannot change tracks when they cross over a diamond intersection. But they enable the 2D collision case, like branches do, and ideally they must be regulated by signals to avoid train collision.

The old conflict mode is still supported by the game, and mods will be able to opt their tracks into it if desired.

Started work on signals

v1.2 now has the beginnings of a user signal system.

Signals are required in v1.2 to restrict track direction and reproduce the semantics of 1.1 builds. But rather than doing some special flag just for v1.1 compatibility, the foundations for the final signal system will be put in place. This requires data and some minimal visualization parts, already done, and a new track editor mode for editing signals, which will be implemented soon.

v1.2 will be released (in some form) in May

Most of the game model and rules code for v1.2 is ready. What’s missing is track editor tools (along with a general track editor review) and to finish already started work in the 1.1 importer. I hope to have some form of v1.2 release ready for May. “Some form” here means that it’s possible the first builds of v1.2 will be done in a “developer preview” form, with major UI blocks and saving disabled, to focus testing in the new areas that require it.