(from the Introduction to Transportation Engineering Series)
I have spent too much time in the last month playing the highly addictive Mini Metro, by Dino Polo Club.
The game pitches itself as managing the growth of a metro (rail) system, but given the pliability of networks, it is probably better to think of it as a bus network, since lines can easily be moved and reconfigured, as well as extended.
The game has a number of attributes:
Nodes of activity (larger white shapes, outlined in black) appear pseudo-randomly over time. Development occurs randomly with some contiguity, new nodes are likely to appear near existing existing nodes and lines, allowing a line extension or diversion to serve them. .
Notably, they get demand even without being added to the network (so you better add them). Sometimes they show up on the network, sometimes they appear to be on the network, but are bypassed by the network, which is really annoying, since the queue for this is subtle and not obvious on a busy screen.
Each node both produces and attracts trips. It attracts trips in the shape of the node, and produces demands of every shape but its own (internal trips can presumably satisfied without using the network). These demands are the little black shapes next to the node, which must get delivered to nodes of the same shape.
There are different types of demand (shapes). I like to think of them as squares representing downtown/employment, circles as residences, triangles as retail, and a bunch of one-time special generators (plus – hospital, wedge (intercity train station), star (airport), pentagon (stadium)). Circles are most common.
Demand grows in an inflationary way to ensure you lose in the end. I.e. you cannot respond fast enough to changing markets (there is no pause while I rework my network) button. I can’t figure out the exact formula for this, except it is too fast. It seems it is a function of accessibility or connectivity, though I am not clear how this is measured.
Each Sunday (after a week) you get a new locomotive. Sometimes you can build a new line, and connect more points, sometimes tunnels, sometimes carriages (2 of 3). It appears you get 2 of 3, but I can’t determine how you get one rather than the other. There are a maximum number of locomotives (4 per line), and lines in the system. Locomotives can have additional carriages.
You need to balance node shapes along the route, to minimize transfers. So your route should contain as many different shapes as possible, intermixed as much as possible. A chain of circle nodes is not helpful since circles don’t generate circle demands.
You need to balance the number of lines vs fewer (longer) lines with more locomotives and carriages. Long lines with few locomotives have long headways, and thus more crowding. I am not sure the extent this feedsback and dampens demand. I have lately taken the strategy of maximizing capacity on one line before opening the next.
Locomotives add frequency, carriages add capacity. Locomotives are more valuable, but carriages are a second best.
Tunnels cost money. Since all the game-boards have rivers, some tunnels are necessary, but if you choose the tunnel, you forego either the line or the carriage, so choose wisely.
Long lines with limited locomotives have longer headways between vehicles. In other words, frequency is endogenous.
No obvious architecture of system works best as far as I can tell (Grid, radial, U-shaped lines) though I am favoring circle lines now, with two locomotives going clockwise and two counter-clockwise. The key question seems to be how interconnected you make the lines, how many lines intersect with each other, and how to minimize transfers, especially at crowded platforms.
Extending lines is free by adding links, except that it adds to headways without also adding locomotives. Lines longer than 9 long are trouble, especially without additional locomotives.
Bus bunching occurs, and is endogenous. It appears vehicles can overtake, I am not clear on that.
I try to make lines connect on non-circles and non-triangles, since those are more special places, likely to have their own special demands, and I want to minimize transfers. However, geometry won’t always allow that since demands keep popping up which need to be served.
There seems to be some sort of reasonably intelligent transit passenger routing algorithm, determining which passengers take which trains (transfers vs. direct). They don’t just jump onto the first train.
Design of the network is very much like the Traveling Salesman Problem.
The game ends when one of your stations suffers over-crowding. In short, it’s too busy, we shouldn’t provide any service. Perhaps it should not be the end of the system, just the end of the manager, who gets fired. My high score on the Steam version is 2006: 6666 passengers over 322 days in Sao Paulo.
The game is still in Beta, and being actively developed, so wishes are useful.
The game is very aesthetically appealing, especially in this new post iOS7/MacOS 10.10 (Yosemite) era, and the beautiful interface fits right in. It is impressive what they can do with an interactive web-game, though it requires a plug-in.
This version includes Multiple cities: London, NYC, Sao Paulo, Saint Petersburg, Paris, and Hong Kong (as of yesterday) with more coming.
It has Leaderboards, so you can compare your pathetic score with others. The Leader has over an amazing 8000 points.
Importantly there is both the Commuter mode (with crowding) and a Scenic mode, (with Free play, and without a crowding penalty.)
This is one of the most abstractly realistic, playable transportation games out there. There are more complex games to be sure, but none which seem to capture so much of the fundamental essence.
(Continuing my series of videos from my Introduction to Transportation Engineering class, discussed previously)