The design and development of Steel & Steam is extremely data-centric.  All the stops and spaces have names and latitude and longitude coordinates.  All the payoff amounts are based on shortest-path algorithms that take into account the cumulation of track mileage between the lat/long coordinate positions. All the property values are based on their ability to connect to cities, weighted by the number of other connections to that city, and their ability to connect to other valuable properties (ie: networkability).

Sometimes, reliance on analytics can get out of control. Or, the algorithm is so complex that the value of the data you’re trying to get may not be worth the effort of getting that data.

It can start with a simple premise: let’s define an alternate victory condition within Steel & Steam where a player can be the first to connect 21 out of 27 special cities (marked in gold on the map) into a single rail network.

If the original victory condition is to reach a net worth of $N, then what is the cheapest way ($C) to connect 21 out of the 27 special cities on the map? This value will tell us whether or not the alternate victory condition is as difficult as the original. If $C/$N == 1.0, or near enough, then it is a valid and competitive victory condition. (Actually, cheapest may not be the valid benchmark, but for the sake of this discussion, it will serve.)

The problem here is that we start dealing with combinations.  If the victory conditions calls for 21 out of 27 cities, how many combinations are there? Well, 27 items taken 21 at a time yields 296,010 combinations, or 296,010 possible ways to victory. Already, we can see that this may be too flexible. That said, what is the cheapest way to connect all combinations of 21 of these cities into a single rail network?

This, too will involve combinations. However, it won’t be as easy as that. We don’t initially know the size of the property set, though that data is easy enough to figure out. We also don’t know how many subsets of the property set will connect all 21 cities in a single network. And each subset may be a different size. We are talking combinations of different size on a property set that will need to be recalculated for every one of the 296,010 city set combinations.

This is becoming a daunting task, all to figure out if a 21 out of 27, or 24 out of 27, will make a good victory condition. It might be easier just to play test the darn thing.