The key premise of Subway Builder, its big "wow factor," is its simulation. It claims to have a robust dataset of commuting data sourced from trustworthy sources like the U.S. Census. And honestly, it delivers quite well on this. The simulation and the demand statistics are indeed quite polished, especially when compared to other similar games like NIMBY Rails. I've seen a lot of people compare it to NIMBY Rails, especially, what with how NIMBY Rails currently only has population data for demand.

However, I do still have a few complaints about this. The wayfinding algorithm seems rather rudimentary, I've seen passengers take illogical transfers like getting off one stop before a transfer with another line, only to walk 10 minutes to a different station on the said line. Further, the way demand is processed is quite frankly, just weird. Passengers are clumped into bigger blobs, so now I have 100 people all going from the same home to the same office building via the exact same route. Another side effect of this is that in times and/or areas of low demand, you don't have one or two passengers on a train; instead, you almost always have the train being empty except for a short burst of 100 passengers.

I'm guessing this was done for optimization, but NIMBY Rails is able to run at a decent framerate on my machine even with individual passenger processing. To be fair, NIMBY Rails is currently on version 17, and had many different optimizations implemented to make that work, but still, it seems like the pathfinding algorithm seems rather poorly-implemented.

In short, if you're looking for a game where you build a subway in one city and want as realistic a simulation of the commuter flow in that subway network, this game is for you. If that's not what you're looking for, oh boy do I have quite a list of downsides for you.

Now, to be fair, as stated before this is an early build and NIMBY Rails is a much more mature project. But, even considering that, this game runs agonizingly slow.

If you want to add stops? Sometimes adding a single stop might take a few seconds for the game to update and process the new routing, especially if your line is very long. You might think this was on some massive build but this was on a build where I only had two lines in Detroit that were each ~70 km long. The simulation itself is also agonizingly slow, and the pathfinding algorithm -- as mentioned before -- is obviously quite lacking.

Even on that aforementioned two-line map, the game was visibly stuttering, running at maybe 15fps? Compare that to NIMBY Rails, where my latest build currently has 1513 trains running on 427 lines across South Korea, and yet this monster still manages to run smoothly at over 200 fps. 

What's more? The game supports 3D buildings, because of course it would. Why wouldn't it. It looks cool, I guess, but what other purpose does it serve? It's not like the height of a building matters for your metro anyways. Another thing to suck up memory and resources that could've been dedicated to pathfinding and calculations. The 3D buildings and roads don't even render in at lower zoom levels, so it's often quite easy to get lost trying to find a specific place to start when you load up a new map.

There's a weird focus on making the game look nice with 3D buildings and such when the underlying features like pathfinding and route selection are still in dire need of revisions and fixes.

This game offers very limited freedoms in a lot of systems, almost like an Apple product.

For example, if you want to run a "heavy metro," the minimum number of cars is 5, and you can only adjust the number of cars in multiples of 5. So if you want 8-car, 6-car, or 4-car heavy metros, you're out of luck, which is a big shame because these lengths are actually quite common across the world. Even for light metros, the minimum number of cars is 2, and you can only adjust the number of cars in multiples of 2. So if you want a 3-car light metro like the Copenhagen trains, you're also out of luck. These limitations just feel... weird? Like, there is no need for these limitations to be in place, there's no way these are technical limitations, so why are you guys forcing your players to use these weird intervals of train lengths?

As another example, if you want to run a line at 10 minute frequencies, there just isn't an option to do that. I mean, you can if your line's round-trip duration just so happens to be a multiple of 10 or close enough to it. But if your line takes, say 35 minutes round-trip, then you can either run 3 trains at 12 minute frequencies, or 4 trains at 9 minute frequencies. Compared to NIMBY Rails, which lets you have trains stop longer at certain stops to make up for the difference to get it to exactly 40 minutes, then run 4 trains at 10 minute frequencies, this is rather annoying if you're just a regular player, and outright maddening if you want to have clockface timetabling.

The game also defines "high demand," "medium demand," and "low demand" times for you, and gives you no way to change them. If you want to run trains past 10 pm you better be ready for 24 hour operation because the game isn't gonna give you an option to terminate services in the middle. You can also only specify how many trains you want to be running on the line at certain those points in time, you can't actually concretely nail down departure times or anything like that. As you can imagine this makes timed overtakes and timed transfers literally impossible to make.

Another is that there are only two train types, after all. You can build and operate either a "light metro," or "heavy metro." That's it. You can't build a ridiculous line that uses Acelas just to connect a dinky suburb. You can't even build trams, a baffling omission considering how many American urban rail systems are light rail systems with at-grade corridors.

The game also has a very narrow definition of the metropolis in a lot of cases. I'd imagine this was quite necessary since they did meticulously craft demand and 3D building data for each metropolis, but out of two cities that I tried to build a network in, Detroit and Houston, I felt that both included not enough area in the map to truly simulate the metropolis. Heck, Houston map doesn't even include my parents' home! For the Detroit map? It includes Ann Arbor, which is generally considered to be "near Detroit" but also kind of its own thing, while excluding thousands of homes in the northern suburbs, north of Pontiac. There are SMART bus lines that run into areas that the game fails to include, for crying out loud.

On one hand I can imagine most of these were done to simplify the gameplay experience, especially for new players, but a lot of these are baffling omissions in my eyes.

The game has a tutorial, at least, but other than that the game is really obtuse about a lot of stuff. Take, for example, directionality. All tracks have some directionality. Even though they give you the option of "single track," you better only use that in some junction or one-way loop because you're not gonna be able to run trains both ways on one track. But this isn't communicated to the player at all. When you build a single track section there is no real way to know what direction that goes in without trying to connect to it and seeing which directions tracks like to connect to. Is it really that hard to draw little arrows along the track to communicate that each piece of track has a certain directionality to it?

Another example would be track height. The game has a very detailed system of track height where the price of construction changes gradually in steps as you dig deeper or build higher. The track elevations are incredibly detailed in increments of meters and the game even calculates collision between tracks with pseudo-3-dimensional height clearance calculations. This is a great system, except, the height of any given track is not communicated at all to the player. And you might think that's excusable, until you remember that the game offers a goddamn 3D view with modeled buildings, and that even in 3D mode the tracks are just flat on the surface of the map.

What annoys me more is that the problem of track height is basically a solved problem. Even if 3D-rendering the tracks dynamically was prohibitively processing-intensive and impossible to implement, you could use what Rollercoaster Tycoon (a practically ancient game by now) did and just label points of tracks with height marks. Or, you could make some overlay layer that color-codes tracks based on their height. Or, you could make it so that different forms of tracks, the cut-and-cover, the "standard tunnel." the deep-bore, the at-grade, and the viaducts show up in different ways on the screen. There are a million ways to solve this problem and they took none of them. There isn't even any visual difference between two tracks crossing at-grade and two tracks crossing while being separated by height. Wonderful!

The track builder is, frankly, one feature that NIMBY Rails delivers really well, so it is naturally quite hard for any game to measure up to it, especially early-access software like Subway Builder. But honestly Subway Builder's system is so bad that I'd rather use Cities:Skylines 1's track builder than this crap.

There's no shortcuts to quickly select different modes. There is no way to select tracks that you've laid down, even blueprints. You can only demolish them and rebuild them. There is no way to ensure that a track is straight. There is no way to build curved stations. There is no way to change the tracks if you started laying down a blueprint in heavy metro but changed your mind and now want a light metro. Really, this track builder system offers not much more than a simple polyline tool you can use on Google MyMaps (or maybe even less, by some metrics, since in Google MyMaps you can at least change the color and stroke style after laying it down).

And for some reason, they decided that the demand overlay shall be a specific mode that you have to turn on, instead of being a layer on the map that you enable and can build on. If you want to build toward some big demand, your best choice is to identify where that demand point is, and then remember that that's where you want to build to as you switch to the build tool.

The problem of gameplay pacing plagues many games, especially tycoon or simulation games where you are expected to accumulate wealth to be able to carry out projects. A sandbox mode naturally solves this but obviously not everyone wants to play with infinite money. However, the problem of gameplay pacing in this game is particularly bad. The starting fund of 3 Billion Dollars sounds like a lot until you build out a network with those 3 Billion Dollars and realize how slow it is to earn money. You're often gonna be waiting at max simulation speed for hours just to get enough money for a small extension project.

What does NIMBY Rails do to solve this problem? They offer a superspeed option where rendering is disabled and the game simulation is run as fast as possible. You can have the game set to this max simulation mode overnight and come back to having a year's worth of income in your bank. And in NIMBY Rails, if you feel that you are not able to make enough of a profit to stay afloat in normal mode, you can always switch to infinite money.

Some other games also solve this by implementing loans or grants. City Bus Simulator does this quite well, where you can sign up for contracts with government agencies and entities to operate special subsidized routes. Loan is an almost-universal option in a lot of games, including Cities Skylines, City Bus Simulator, Rollercoaster Tycoon, and once again, NIMBY Rails, which has had a basic loan system from very early versions (your starting fund is actually a default loan).