Transport Fever 2

After nearly 30 hours with Transport Fever 2, I have reached a blunt conclusion: its infrastructure-building interface is not merely unintuitive or dated. It is a professionally indefensible design failure at the centre of a game supposedly built around transportation infrastructure. I am precisely the audience this game should appeal to. I enjoy public transportation, railway operations, passenger flows, network planning, and interchange design. Yet Transport Fever 2 managed to drive me away—not through meaningful complexity, but through an astonishing accumulation of opaque controls, missing feedback, inconsistent snapping, and unfinished construction tools. The familiar defence that “Transport Fever 2 is not Cities: Skylines” is irrelevant. I am not asking for a city painter. I am asking a transportation game to provide competent tools for building transportation infrastructure. Roads, tracks, bridges, tunnels, junctions, and stations are not peripheral city-building features. They are the foundation of your own game. The current system repeatedly fails at the most basic level: Roads and railway tracks snap together without being asked, after which the game may immediately complain that the resulting proposal contains a collision. The interface actively creates the problem and then blames the player for it. “Not connected” is not an explanation. It is the software equivalent of shrugging. The game refuses a construction proposal while withholding whether the cause is elevation, slope, curvature, collision, snapping, node mismatch, or some hidden constraint. Expecting players to diagnose invisible internal rules through demolition and repeated trial and error is not difficulty; it is inadequate software design. A transportation game with extensive tunnel construction has no proper, persistent underground-view toggle. Underground tracks can only be partially exposed under specific construction conditions. Inspecting or editing underground junctions, signals, and broken connections becomes an exercise in fighting the camera and accidentally selecting surface objects. This omission would be embarrassing in an early-access prototype. In a finished commercial product, it is indefensible. Essential controls are hidden behind bizarre defaults with virtually no useful guidance. N/M rotate objects, comma/period control elevation, and C suppresses snapping. These bindings disregard established conventions, yet the interface does little to communicate them. Players cannot be expected to search forums to discover that a punctuation key controls one of the game’s most fundamental construction dimensions. Bridge pillars cannot be positioned intelligently. Ordinary underpasses and elevated structures frequently require manual terrain surgery, repeated demolition, collision overrides, pillarless bridge mods, node-editing tools, and decorative bridge components. Modders have effectively been forced to finish the construction system that Urban Games shipped. Fundamental information—node elevation, gradient, curve radius, clearance, collision target, and the precise reason a proposal is invalid—is absent or inadequate. Community mods such as Track/Street Builder Info and Build with Collision are not merely optional enhancements; they compensate for basic functionality that should have existed in the base game. A competent interface would provide messages such as: “Connection failed: endpoint elevation difference is 1.2 m.” “Construction failed: minimum curve radius not met.” “Construction failed: bridge pillar intersects road lane.” “Connection failed: segments do not share a node.” Instead, Transport Fever 2 frequently provides a vague rejection and leaves the player to reverse-engineer the problem. That is not sophisticated simulation. It is poor communication disguised as complexity. What makes this particularly disappointing is that there is an excellent public-transport game buried underneath this interface. Unfortunately, the construction system treats the player’s time as disposable. Nearly every routine task is made more laborious by missing diagnostics, hidden controls, arbitrary restrictions, or inconsistent behaviour. Transport Fever 3 will not deserve to call itself the “ultimate transport tycoon” if it carries forward this contempt for basic usability. A proper underground view, conventional and visible controls, optional snapping, controllable bridge placement, reliable node editing, and precise construction diagnostics are not extravagant requests. They are the minimum expected of a modern transportation game. After almost 30 hours, I stopped playing because I was tired of fighting the interface rather than designing transportation networks. That is a remarkable failure for a game whose central fantasy is building transportation networks. The modding community has demonstrated that many of these deficiencies can be mitigated. The fact that unpaid community members had to do so only makes the condition of the base game more embarrassing. I sincerely hope Urban Games studies these failures before releasing Transport Fever 3. If the next game again expects players to compensate for unfinished core tools with forum archaeology and a collection of essential mods, then it will deserve the same criticism.