Design Doc

[kanerogers]

Overview

Untitled Train Game is a game about trains.

In the vein of half-remembered childhood classics like Railroad Tycoon, Transport Tycoon and The Other One, Untitled Train Game asks you to build train networks for the glory of Capital.

• There are resources on a map
• There are businesses that want those resources.
• A business will offer a contract to have one or more resources delivered, in a certain quantity, each day
• Your company will take on those contracts and build train networks and schedules to fulfil them

You will like this game if you enjoy the following:

• Trains
• Small business accounting (without all that unnecessary "taxation" stuff - is a man not entitled to the train on his brow?)
• Acquisition and allocation of capital

Contracts

The game revolves around contracts, which are an agreement between your company and a business to provide a certain amount of one or more resources per day.

Example Molly's Moist Moose Meat Mall wants 10 tonnes of moose meat per day, for a month. The contract is worth $100,000

Contracts are paid half upfront, with the final half on contract completion. But, if you fail to complete the contract, the customer gets their initial money back and you get nothing. You lose. Good day, sir.

Not every contract will be available for you to take on straight away. A contract can specify that it needs a company of at least certain size (small, medium or large) to take it on.

TODO

• Should the contract SLA be variable? eg. "you can miss 3 days per month, max"? Or just "you missed a day, sorry bud".
• How much lead time to we give to a contract? If I take it on today, do I have to deliver the moose meat tomorrow? We should have like a 7 day grace period or something
• What happens when a contract expires? Auto-renew?

Schedules

To fulfil a contract, you need to get things delivered on a daily schedule. If a customer needs 10 tonnes of something per day for a month, you can't just dump 300 tonnes of tender, moist moose flesh on their doorstep and call it a day.

This gives each schedule a maximum of 24 hours per day to complete a round trip.

A train's speed is determined by 4 factors:

• The speed of the locomotive
• The amount of weight being pulled
• The total track distance between stations
• Traffic on the line

Balancing these 4 factors allows you to service more contracts with less trains, meaning more profitability. But wait, what is profitability?

Profitability

Let's be real. The point of this game is trains. You love trains, I love trains. We all love trains. We want to see the screen filled with trains, whizzing back and forth, ferrying goods and passengers with dizzying efficiency. We want to hear the sweet click-clack-clack as they roll across the landscape, that deeply satisfying chicka-chacka-chicka-chacka as they go.. ehem.. uh.. give me a moment to compose myself.

But, nothing in life is free. Trains cost money. To get money, we need profit. To get profit, we need to spend less than we earn. We earn money through contracts (as outlined above), but we spend money in two ways:

• Capital expenditure: the upfront cost of purchasing a train, station or railway
• Operational expenditure: the ongoing cost of maintaining trains, stations or railways

[kanerogers]

Doing some back-of-the-envelope maths to figure out:

• How big should the map be?
• How spread out should resources and business be?
• How long should it take for a train to get from a resource to a business, on average?

Turns out this is all quite tricky! If I built this to scale, even a slow-ass cargo train could cover like 1,200KM in a day, and country scale terrain gen is not something I'm keen to get into

What scale would be appropriate then? Well, the perspective of the OpenTDD folks is (essentially) "it doesn't matter", so let's just make some shit up.

I reckon this should be informed by the game's core mechanic, delivering things on time. It should be pretty doable to service two businesses with a single train (so RTT <24hr), but the third one should be a stretch / too hard, prompting the player to have to think about building a new line to service the third destination.

Keeping it simple then we can say a train should be able to do a round trip of A-B-C-A in ~20 hours, .: A-B should take ~5 hours. So, let's keep it simple, say that's 50 metres, so our starting train should be able to pull cargo at 10m p/h.

We can then just say the world is 1KM wide, that should probably be fine?

[pwc]

This sounds great and I love it. Some thoughts:

Point-to-point versus integrated systems

In OpenTTD you can choose to build either point-to-point networks (connect provider A to consumer B by a single dedicated line, generally one track each way, and just add more trains, and that is enough—no single producer/consumer can come close to producing enough to need more), or complex, well-signalled, beautiful trunk-and-branch system, where many producers and consumers share the same track.

Because of OTTD’s design (or at least, its design when I was playing it), the financially-optimal approach was point-to-point, because it’s drastically simpler, you never need to worry about signalling, congestion, or throughput issues. (Fundamentally I think the design factor that drove this was mostly infrastructure and its maintenance is cheap.) (The other factor is that the terrain is highly malleable so you can just demolish a mountain if you want to.) So the only reason to do a mainline is for rôle-playing reasons.

Considerations:

• The first-time player’s first connection is generally point-to-point, because (a) they are connecting two industries, and (b) they don’t yet know about planning in advance
• I think this is also generally true for returning/experienced players because of point (a) above. Point (b) may or may not apply, depending on whether the player can gather enough information to plan ahead, but in practice I think a common case will be starting P2P and then expanding
• It’s difficult, even in OTTD where money flows freely, to start building an integrated system at the start of the game, because it’s too expensive
• Assuming I fulfill contracts in roughly most-profit order, I will build many point-to-point networks. Only once I am looking to “fill out” the network will I integrate them. (In OpenTTD this happens naturally because I might do [i] offered subsidies, [ii] coal←→power plant connections [most profitable] and then [iii] fill out between them, at which point I integrate my network. In TrainsTrainsTrains it may never happen if I don’t get the right set of contracts.)
• Therefore, it seems to me that the contract generator needs to have its “finger on the scales” to get me to join industries to my growing network, rather than start other P2P connections
• Other mechanics to achieve this might include: (a) terrain: if there is only one practical way (e.g. a mountain pass), and my contracts are often on the two sides of that range, naturally I will build a single line through the chokepoint; (b) infrastructure costs: if the infrastructure is very expensive, I will look to re-use where possible; (c) reputation: if I rely on my reputation (whatever that is), and reputation falls off with distance, I will want to take contracts close to where I am already a recognised Good Transport Company

I think that, as you have discussed, we want complicated integrated train systems whizzing around. Some thought should be given to this matter.

Difficulty scaling

Difficulty scaling seems important and, fittingly, difficult.

By this I mean, in some sense, your first connection is your hardest: I have to build the whole thing from scratch, I have to build the whole thing on budget, I don’t have any spare resources I can transfer. When building subsequent connections, the opposite is true: I can reuse part of my existing track, if I run out of money I can cross-subsidise from other lines, and if (say) I can’t afford a train, I might be able to share one with another contract. (I do now need to do more sophisticated train signalling and scheduling.)

Therefore careful thought has to be put into this, to ensure there is still an appropriate difficulty ramp. Some thoughts:

• The contract generator can again thumb-on-the-scales by giving more profitable and easy contracts towards the start of the game
• Non-perishable cargoes (e.g. coal) could be used earlier, where you can store extras, compared to perishable ones that must be delivered just-in-time
• The mix of capital and operating expenses could change over time (as “technology” advances): early in the game capital is cheap (so you can build your early connections cheaply) but maintenance is expensive; as time goes on and you earn more, perhaps you benefit from designs that are more expensive up-front but a lower operating cost
• It seems like the answer to the “contract expires” question might be here