We were hoping to have the gamma26 build tested and live before the Daily Deal today, but unfortunately what I thought was going to be just a few days improving the passenger AI turned into a couple of weeks. So business as usual. 🙂
We’ve worked our way through every bit of the decision-making code and found and fixed numerous small errors that would result in railcars leaving stations partially full or overfull, passengers making dubious decisions about which trains to board, passengers of the same shape making different decisions at the same station, and all sorts of other odd behaviour. It’s gone through testing here, but I don’t feel comfortable pushing it live just yet given it hasn’t had any public testing. So if you’re game, please switch to the test branch and give it go. If you think you’ve can see anything dodgy, please take a screenshot and send that and as detailed a description as possible to peter@dinopoloclub.com.
There are a couple of AI issues that I’d like to go over. The first is that in order to make the passenger decisions more consistent, we’ve had to remove the old hack that would encourage passengers to leave overcrowded stations immediately if a train was available, even if that train took a much slower route to their destination. The way we got those passengers to prioritise the longer route then had to have another hack to avoid them flip-flopping routes, so the whole system is much more robust with both those hacks gone. We’re working on a replacement system to discourage passengers taking routes that involve waiting at overcrowded stations instead; this will have the same result as the old code, but it’ll work much more elegantly with the AI’s search algorithm.
The second issue is that we’ve found that high-risk connections can pose a real problem with the way passengers make decisions about which route to take. By high-risk I mean passengers deciding to take a route involving a tight transfer onto a different line to get to their ultimate destination. If they miss that transfer due to either an optimistic estimate of their original train’s arrival time at the transfer station, or a pessimistic estimate of the connecting train’s arrival time, then the cost is potentially very high. If the connecting train is the only train on its line, or if the line is very long, then the passenger will likely flip to a completely different path once it realises it won’t make the connection. This can lead to passengers going back-and-forth as they try to catch different trains. We’ve done what we can to address this issue by building in a threshold for tight connections that goes up and up as the search algorithm tries to predict further and further into the future. For example, if we’re predicting a transfer 30 seconds in the future, then the passenger has to predict it’ll get to the station at least 3 seconds before the connecting train, otherwise it assumes it’ll miss the train and cost that particular route accordingly. This is as much as we feel comfortable doing without either adding state to the passenger AI (at a cost of robustness), or improving the train location prediction (at a significant cost of development time, and no doubt introducing a litany of new bugs).
Ultimately this is a problem given the odd timescale the game runs at, with few railcars hitting stations infrequently, compared to actual metros that have many more cars with far greater frequency of station visits.
Anyway, I know this has been a little long-winded, so thanks for reading through! I figured some players would appreciate a peek behind the scenes of what is by-far the most complicated algorithm in Mini Metro.
Slight non-sequitur back to gamma26; we’re aware of some rendering issues on the Linux build, (the in-game UI elements are flickering on our Ubuntu machine) so we have to at least get those resolved before pushing this build out to the default branch.
Keep those cities moving!