There are several steps involved in creating a random demand deck. First, we have to be able to decide what the payoff should be for a given commodity at a given destination. Second, we have to decide which demands to include in the deck. Third, we have to combine the demands into sets of three to form the cards. Finally, we have to shuffle the cards, and determine where in the deck the Taxes event should arise (possibly more than once).

In a few cases we treat part of the map as impassable to eliminate the possibility of track that, though cheaper, would never reasonably get built. (An example is Nippon track that "turns the corner" from Fukui to get to Matsue without going through Osaka. Another example is the Canadian route from Winnepeg to Sudbury on the Empire Builder map.)

If the cost of the cheapest track is not $1 per pip, the payoff varies a bit to account for this, but distance is still the main factor unless the difference is large.

Note: Building costs do not include the cost of building into cities, since in most cases you will already have track to at least one of the cities. Track using a ferry includes the cost of the ferry, but in computing the distance of that track the ferry is treated as 6 pips (1/2 turn for a super). See our rules variants for a suggested variant for ferry movement.

There is no random element. The payoff for a given good to a given city is always the same in every deck. Some destinations pay off a bit extra to encourage going there. Some of these bonuses are computed automatically based on "how far in the dingles" a city is; some are added by hand. Similarly, a few goods may pay an extra dollar or two to encourage picking up those goods. However, there are roughly the same number of demands for each good, so there is no bonus for "rarely demanded" goods such as tobacco in Empire Builder.

The early formula paid too much for particularly long runs, so we reduced the payoff for long runs. This compensates for the value inherent in not having "dead time" while you fetch new loads or toss cards.

The formula is:

D | = | distance of cheapest track | |

C | = | cost of cheapest track | |

R | = | ratio of cost to distance = C / D | |

B | = | basis of payoff, computed thus: | |

if R <= 1: | B = D * (1 - (R-1)^2) | ||

if sqrt(2) >= R >= 1: | B = D * (1 + (R-1)^2) | ||

if R >= sqrt(2): | B = C * 2 * (sqrt(2) - 1) | ||

P | = | payoff = 7/9 * B - D^2 / 1000 + 1.85 + dingles, rounded down |

For example, in Empire Builder, Fish to Cincinnati pays $10 by our formula. The best source is Norfolk, and the cheapest route from there to Cincinnati (ignoring the cost of cities) is straight to Pittsburgh, then northwest to finish going around the river, then over to Cincy, a distance of 11 mileposts costing $13. Using the above formula, R = 13/11, so B = 11 plus 11*(2/11)^2 = 11.364 (i.e., slightly more than just the distance of 11, because the track costs slightly more than 11), and the payoff is then 7/9 * 11.364 - 0.121 + 1.85 + 0 (no dingles element) = 10.567, rounded down to $10.

In Lunar Rails and Martian Rails, the "D^2 / 1000" term is reduced to account for the faster engines available (i.e., a set of long runs doesn't keep the train busy for as many turns). There's also an across-the-board 15% bonus added to all Lunar/Martian payoffs in order to generate the cash needed for building on such hostile terrain. This bonus brings our average payoffs up to where they approximately match the average payoffs in the decks that come with the games.

For each major city, note the cost of building from it to the destination.
For each pair of major cities, sum the cost of building to the destination
from both cities, and subtract the cost of building directly between the
two major cities. Take the minimum of all these costs (for single or
paired major cities); this is the preliminary dingle metric. Also compute
an "access metric" which is the sum of the costs of building to the destination
from *all* major cities.

Next, reduce the dingle metric at the city based on the goods available there. For each good produced, examine all sources of the good to find the one with the lowest access metric. Divide this lowest access metric by this city's access metric. Subtract three times the cube of this ratio from this city's dingle metric. (Thus, in particular, if a city is the most accessible source (possibly the only source) of some good, the city's dingle metric is reduced by 3. The "cube" part of this computation was added in February, 2005 to accomodate the Russian map; see here for more about what changed.)

For each map we manually choose a dingle threshhold T and a rate of increase I. If a destination has a dingle metric of M, then if M < T there is no added payoff. Otherwise the payoff is increased by

1 + (M - T) / I .The card generation program has a mode in which it computes the dingle metrics and displays them, so we can decide on values for T and I.

In addition to the dingles adjustment, we sometimes toss in a small adjustment (up or down) to the payoffs depending on the commodity and/or the destination, to try to fine tune the values for a particular map. For instance, we pay an extra $1 for deliveries to Calgary in Empire Builder or Matsue in Nippon Rails, and we subtract 2 from the already lucrative Jute payoffs in British Rails.

First, we decide on the goods. Start by taking an equal number of each
good, such that the total is as close to 360 as possible. If the total is
not exactly 360, we add or remove enough **different** goods to bring
the total to 360. (The goods added/removed are chosen randomly from the
full complement.) Then, to get just a bit of variety, we take the list of
goods, omitting those that were added/removed to adjust the total, and for
1/4 of them we remove one from the mix, and for 1/4 of them we add one to
the mix.

Again, we may adjust the number of each good slightly, to try to fine tune for a particular map. So far we do this only for British Rails, slightly reducing the number of payoffs for Jute, Chemicals, and Oats, while increasing the number for Oil, Fish, Sugar, and so forth, to try to pull people away from the standard western corridor.

Having chosen which commodities to use, we now pick the destinations. One of the features we're going for in this step is that cities that are useful as sources for goods tend to appear less often as destinations, while cities that are not useful as sources receive more deliveries than other cities of the same size.

We start by giving the cities relative weights based on their size. It helps if the sum of the weights is about 360; it means the numbers give a first approximation of how often each destination will be used in a 120-card deck. In Empire Builder and Nippon Rails we use 11-8-6 for major-medium-small, but for Eurorails we use 9-7-5. (In each case, we may make small adjustments to tune the decks.) These numbers are the "city weights".

We then track a "usage total" for each city, starting the total at zero for all cities (except as modified below). Each time we need a destination, we pick the city with the lowest usage total, breaking ties randomly. The destination's usage total is then increased by 1 over its city weight. Thus if the cities are chosen in the proportion indicated by their weights, the final usage totals will be all equal.

As mentioned earlier, we want to adjust the city mix so that a city that is useful as a source of goods is not chosen as often to be a destination. How useful a city is as a source depends somewhat on where its good is being demanded, but as a first cut we make an adjustment based solely on how often each good appears in this deck's mix of goods. For each good available at a city, we increase the initial usage total at that city by (number of times the good appears in this deck) times 0.25, divided by (number of cities where the good is produced), divided by the city's weight. The 0.25 means that if a city is the unique source for a good, then for every 4 demands for that good there will be one less demand using this city as a destination.

Now, taking the 360 goods in a random order, pick a destination for each. To pick a destination, find the city with the lowest usage total, ignoring cities that either (a) are within 2 pips of a source for the good or (b) have already been chosen as a destination for the same good earlier in this deck. (A city is also ignored if the payoff there would be below some minimum; on most maps this minimum is $3, but we noticed that the deck that comes with India Rails has no payoffs lower than $7, so we made that the minimum for our India Rails decks as well.) If there is a tie for lowest usage, break the tie randomly. Then adjust the usage total for the destination as follows: First, add 1 over the city weight, to reflect the city's use as a destination. Next, for each city that produces the good we just used, adjust the usage totals for all sources of that good. At each source, subtract 0.25 divided by the number of possible sources, divided by the sources's city weight. (This reverses the initial increment to usage totals caused by this good.) Then compute the sum, across all sources, of 1 over (distance from source to this desti- nation). Call this S. Finally, for each source, increase the usage total by 0.25 times (1 over the distance to the destination), divided by S, divided by the source city's weight. E.g., if there are two sources at distances 10 and 20, the nearer source gets (0.1 / (0.1+0.05)) = 2/3 of the usage increase and the further source gets 1/3, compared to the 1/2 and 1/2 that they got in the initial usage totals (before the actual destination was known).

Over time, we came up with various constraints limiting which demands can appear together on a single card. For starters, we require that each card have a "small" payoff and a "large" payoff. The dividing line is chosen to be the median payoff (across these 360 demands), plus 1. Of the payoffs less than or equal to that amount (typically about 190 to 200 of the 360 in the deck), we choose 120 and assign them to different cards. Then we take the demands with higher payoffs and assign one to each card, making sure we don't violate any of the pairwise constraints (described below). (In the unlikely event we come to a small payoff for which no remaining large payoff will work, we replace the small payoff with one of the unused ones.) Finally, we take the remaining 120 demands and assign them to cards, making sure we don't violate any pairwise or triplewise constraints.

It often happens that we get to the last card or two and find that we cannot assign the last demands to the remaining cards without violating a constraint. If so, we back up and swipe the third demand from an earlier card, and then see if we can fulfill the scavenged card using the remaining demands. This process typically settles down after only a few iterations.

The pairwise and triplewise constraints we've developed so far are as follows. Random sampling shows that about 80% of all possible pairs of demands pass the pairwise constraints, while about 40% of all possible triples pass the full constraints. Not everyone will agree with all the constraints we've chosen to use, but we're making the decks, so we make the rules!

- As noted above, each card must contain at least one payoff that is no more than $1 above the median, and at least one payoff that is more than $1 above the median.
- The middle-sized payoff on each card must be at least $6, and must be greater than 1/5 of the largest payoff on the card. (Cards with payoffs of $4, $4, $19, or of $4, $7, $62, feel too lop-sided.)
- No card can have two demands for the same good.
- No card can have two demands for the same destination, nor for two destinations within 3 of each other.
- The three destinations must not all be within 12 of each other (by the "length of cheapest track" metric). Also, the sum of the pairwise distances between destinations must be at least 30. E.g., destinations of Denver, Omaha, and Oklahoma City (distances 9, 10, and 11) would violate the first constraint, while Atlanta, Raleigh, and Philadelphia (distances 7, 7, 14) would violate the second.
- The closest source cities for the three demands must all be different. E.g., Iron to Philadelphia and Steel to Miami could not go on the same card because the best source for both demands is Birmingham.
- No two demands can have source cities that are "good enough" and "too
close to each other". Specifically, if cities S1 and S2 are
*potential*sources for destinations D1 and D2, then the distance from S1 to D1, plus the distance from S2 to D2, minus the distances from the*nearest*sources to those destinations, plus 4 times the distance between S1 and S2, must be at least 24. As a special case, the "best" sources for the demands must be at least 6 apart. The idea is that being in "the right general area" should not give you a choice of two reasonable ways to lock the same card. For example, Steel to Norfolk cannot be on the same card as Bauxite to Phoenix. Though Pittburgh is the best source for Steel to Norfolk, Birmingham is only 7.12 pips worse (after adjusting the actual distance based on building costs: 5 pips $7 from Pittsburgh => 5.8, 13 pips $12 from Birmingham => 12.923), and Birmingham is 4 away from Memphis (Bauxite), and 4*4+7.12 < 24. - No card can have two demands that "require" building to the same dingles. A demand "requires" building to dingles if the destination is a dingle, or if all sources are in the dingles, or if all sources that are outside the dingles are more than 12 further away than the nearest source. Two dingles are the "same dingles" if their dingles metrics were based off of the same major city or pair of major cities.
- No card can have two demands for which the destinations are "near" each
other
*and*the nearest sources are "near" each other. E.g., we don't want Cars to Los Angeles and Tourists to San Francisco on the same card. The specific rule is: Find the best (nearest) source for each demand. Take the distance between the two sources. (If there was a tie for nearest source for a demand, use the source that is closest to the best source for the other demand.) Take the distance between the two destinations. Thrice the larger of these two distances must be at least as great as the sum of the lengths of the two runs. In the example given, Detroit to Chicago is 4, L.A. to S.F. is 6, and 3x6 is less than 39.23 + 38.32 (the lengths of the runs). A more borderline example is Steel to Minneapolis (from Pittsburgh, distance 17.00) and Tobacco to St. Louis (from Savannah, distance 16.00). Pittsburgh to Savannah is 9.44, Minneapolis to St. Louis is 10.40, and 3x10.40 is less than 17+16. - If two runs on a card are both "distance" 12 or less, then for at least one
of those runs the best source must be more than 12 from the
*other*destination. This is to avoid have a card containing two short runs that use roughly the same track in opposite directions. Long runs in opposite directions are okay. Thus, Copper to Omaha and Swine to Santa Fe is fine, though they use similar track, because they're long enough that you don't really have a choice of which way to do it from most starting points. But Lead to Omaha and Swine to Cheyenne cannot be on the same card. - The sum of the pairwise distances among the three destinations, plus the sum of the pairwise distances among the best sources, must not be less than the sum of the lengths of the three runs. This was one of the first constraints we used, and over time it appears that the other constraints are such that it's hard to find an example of a card that would violate this constraint without also violating others. On the Empire Builder map, the closest we can find is Detroit Uranium (from Regina), Chicago Lead (from Denver), Tampa Sheep (from Billings). The distances between sources sum to 31.111, between destinations sum to 46.190, and the runs sum to 79.017. This violates this constraint, but it also violates the next constraint shown below. For a valid example where this constraint still matters, we must turn to the Eurorails map with, e.g., Copper/Iron/Ham (from Wroclaw/Kaliningrad/Warszawa, pairwise sum is 29.405) to Zurich/Napoli/Valencia (sum 97.040): runs sum to 129.828. To see how close this is to violating other constraints, note that you could switch Zurich to Bern and still violate only this constraint, or you could switch Valencia to Bilbao, but if you switch both then Bilbao Ham and Bern Copper violate a pairwise constraint (the sum of the two runs is more than thrice the distance between Bilbao and Bern).
- The sum of the pairwise distances among the destinations,
*or*the sum of the pairwise distances among the sources (whichever is greater), must be at least 2/3 the sum of the lengths of the runs. For example, consider the triple: Detroit Bauxite, Chicago Tobacco, Boston Rice. The runs are length 13.077, 14.083, and 28.448, respectively, total 55.608. Detroit to Chicago is 4, Detroit to Boston is 14.071, Chicago to Boston is 18.056, for a total destination distance of 36.127. The source distances are New Orleans to Memphis (7), New Orleans to Raleigh (15.750), Memphis to Raleigh (13.929), total 36.679. Since 36.679 is less than 2/3 of 55.608, these three runs are considered to be "not sufficiently separated".

In Lunar Rails and Martian Rails, where players start with $60 but can spend only $40 before the first turn of movement, the initial runs are limited to those that can be built using $50, which means that at least the track to the starting city can probably be built for the initial $40.

To do this, the program finds all cards containing demands that cannot be
done in the beginning, and sets those aside. It then shuffles the rest,
and picks 5*N* to start the final deck. It then shuffles the remainder
back in with those that were set aside, and sticks them after the initial
cards.

Having shuffled the deck, the program decides where the taxes card would be
if there were a real card for it. For each card (not counting the first
3*N* cards, which are dealt out before any building is done), it gives
a 1/*k* chance of the card being preceded by the taxes event, where
*k* is initially the number of cards remaining in the deck at the point
the given card is being drawn. When a card does turn out to be preceded by
taxes, it checks a further 1/*k* chance that the deck is
"reshuffled" at that point (after first resetting *k* to be at least
half the deck if it was smaller). Note that you should not actually reshuffle
the deck; the program merely simulates the effect by using a larger value for
*k* when computing whether taxes occurs before subsequent cards.