I'm making an economic kind of game, and one of the things I'm simulating is the transportation of resources to a central depository, e.g. moving metal from a mine to the city (so it can be turned into swords). I want it to behave so that a producer farther away from the city is considerably less efficient, but the player can bring the efficiency back up by assigning additional carters.

The function I have right now is:

efficiencyPercent = 100 - pow(9 * travelTime, 4/3)*pow(2/3, carters)

However, this doesn't have the behavior I want; carters are too powerful, either because pow(2/3, carters) converges to 0 much too fast, or because pow(9 * travelTime, 4/3) grows too slowly, or both, I'm not sure. No matter how big travelTime is, the player can overcome it by assigning a reasonable number of carters. I want it to work so that modest travelTime is defeatable by a reasonable number of carters, but once it gets too high it takes an absolutely incredible number of carters to defeat it.

What's a better sort of function that will have this behavior? I think I need the inefficiency to be exponential in travelTime but I don't know what to do about carters. Please help!

EDIT: DeadMG suggests that I have combined two effects (effect of travel time & effect of carters) that would be better off separated. I'm not sure I agree, but I'm not sure I disagree either, so I'm restating the question in support of this theory.

What I'm looking for is some kind of mechanic, involving carters and travel time, with the following behavior:

An iron mine can generate iron at a rate dependent on the number of laborers assigned to the mine; for example, 40 miners produce a maximum of 10 iron per month. This is strictly linear and I'm not changing it at this point. No matter how many carters you assign, there should never be a way to convince the mine to provide more than this amount.

In order to be used, the iron has to be transported to a city. The miners are willing to do this to some extent, but they become less willing the farther they have to carry it. If the mine is right in the middle of town, no carrying is necessary and the miners work at full power; farther away and they are forced to take time off to haul wagons. In the interest of concreteness, the miners shouldn't be willing to carry a significant amount of stuff farther than 5 days away. (I can fiddle with the exact balance later).

You can assign additional laborers (from the city's pool) as carters, allowing the miners to get on with their proper jobs. Dedicated carters are far better at moving things than miners moonlighting as teamsters. Assigning more carters should have diminishing returns. For concreteness in fiddling with constants, a mine 5-7 days away should be restored to 95% efficiency by roughly 10 carters.

The farther away the mine is, the more carters it should take to achieve a given efficiency improvement. Mines that are too far away (for concreteness, 14 days or so) should require a completely impractical amount of carters to increase the efficiency to usable levels. Ideally, in this situation the player would rather build a new city, closer to the mine, than assign such an incredible amount of workforce simply to cart things around.

The formula I have satisfies all of these except the last, which is the one I'm having trouble with. I'm particularly looking for a mechanic that provides all of these features in a "smooth" way, without arbitrary breakpoints or funny corner cases, because I want to be able to change the constants depending on the empire's technology levels. Whether this is two separate formulae as DeadMG suggests, or a single combined one like I have now, or any other kind of mechanic, I don't care. Any suggestion, up to and including the simulation of little carter automata moving around the map, is what I'm looking for.

I'm not sure that, as stated, your problem is posed correctly. The only thing that effects the metal produced of a mine is the number of laborers free to mine (you stated as much in 1). The "efficiency" of making iron should be independent of both the distance to a center and the number of transports available--after all, you've got plenty of metal, it just hasn't left the mine yet!
–
ChrisEMay 3 '11 at 19:54

Your second point about allowing miners to carry things complicates the calculations further. I'd just model it as saying that miners mine, and when they are done mining, they deliver the goods unless someone else is in place to handle transport. This naturally creates periodic deficits (real ones!) in mining capacity if you don't have transport to prevent these miners from switching tasks.
–
ChrisEMay 3 '11 at 19:59

Your fourth point makes no sense, if you agree with my earlier assertion about mine capability: The mine is completely effective at producing iron at its site. It makes no difference whether you have 10 carters or 10,000--you can only move so much ore to the top of the mine. It makes no sense to add more carters past what the mine is able to produce, and so that issue is done away with completely: you use as many miners as the mines will support, and you use as much transport as the ore production requires.
–
ChrisEMay 3 '11 at 20:03

The diminishing returns you seem to want to model are best handled elsewhere in your system, where they would make sense. Adding additional carters requires more housing, in turn requiring more roads. Failure to add roads results in congestion, slowing movement for all units. Failure to add housing results in slower carters (can't rest, grumpy, etc.) or fewer carters (simply can't support them). Building up enough infrastructure to have a constant bucket brigade to a mine is fine, but if the mine fails to produce carters perhaps don't get paid, and in turn cause damage by rioting or something.
–
ChrisEMay 3 '11 at 20:06

If the player can create a mine and its associated infrastructure, and can create a carter infrastructure, and both things scale linearly (as described above), then there is no reason it would make sense for the system to become less efficient as you increase scale. Your suggested model to me seems broken. If you are trying to regulate this, let other things have effect: competition from better tech lets some other type of carter outperform the player's chosen type, or glut in the market supply for iron makes the mines less profitable in turn lowering carter wages in turn increasing crime.
–
ChrisEMay 3 '11 at 20:09

3 Answers
3

I tend to say 'if you can't find an explicit solution, seek an implicit one' (compare my anwer to this question).

Have you thought about simulating miners, carters and stockpiles as agents?

Taking your example numbers, you could go like this: A miner mines .25 units of iron in 30 days (i assume uniform month-length for the sake of brevity). If this miner has to push a cart across the country, he can not mine, so for a five-day-trip, he is out of the mine for 10 days (five days to there, five days back again), so there is your inefficency. So, let the miners mine to a stockpile at the mine.

Let a cart have a limited maximum load, eg 2 units. A carter needs the same 10 days for a round trip, picking up up to 2 units of iron at the main after five days. A single carter would thus be able to pick up 6 units of iron from the mine per month (3 trips of 10 days with a load of 2 units each). A second carter could then be assigend to pick up the rest of the iron mined, but he might have to go back (half)empty or wait for the miners if there isn't enough iron in the stockpile to fill his cart.

Essentially, this would be like the gathering logic in RTS-games, without the fancy graphics.

The implementation depends on the granularity of your game. As you didn't mention it in your question i assume a turn based approach, with one turn being one month - so you would have to simulate 30 days of mining and carting for each turn.

I sure have thought about it. Simulating carter automata has benefits in other areas of the game (specifically, it makes it easier for me to decide that an enemy army is camped out on the road and stealing your iron), but it seems very expensive. I still might go with it though, it does seem to have most of the behavior I'm looking for.
–
Paul ZMay 3 '11 at 18:30

I had started an economic model for one of my games, and wanted distances between factories and towns to matter. I tried to model the person's commuting and working hours. Suppose they're willing to work+commute 12 hours in a day and have 4 hours leisure/eating and 8 hours sleep. Some of that 12 hours goes into the commute to work and some of it goes into actual work. The farther you are from town, the more goes into the commute. There's a hard cutoff at 12 hours of commute time — you just don't get any work done anymore.

time_worked = 12 - time_commuting

and then

time_to_complete_job = constant / (12 - time_commuting)

If you plot this on a graph you'll see it's reasonable for the first 6 hours commute time (any factory within 3 hours of the town is the same efficiency) but then it starts going up after that, and it's twice as expensive around 9 hours commute time, and starts going up very quickly. At 12 hours it goes to infinity. That corresponds to your 14 days = impractical.

I don't know if this behaves the way you want but given that you have some distance you want to be impractical, I think this type of function probably gives you better results than pow().

Ultimately, I think that you're dramatically over-complicating the situation at hand. You want to achieve a simple effect- resources further away are more expensive. You should aim to reflect this in the simplest way possible- an increase in the cost, either recurring or initial, of obtaining the resource production. Once this is done, then it doesn't matter what you decide to do about stacking carters, because all mines produce the same amount once they're paid for, and you can balance the distance of resources and the power of carters independently.

No, the whole point is to have carters included in the formula as well, because carters take labor and there are other things you probably needed that labor for (like, farming). It's supposed to be a balancing act.
–
Paul ZMay 3 '11 at 0:11

@Paul Z: Check my edit. Your problem is that you have coupled the balance of resource-distance with the balance of carters. Once you separate these two problems, you should find it easier to obtain a suitable balance.
–
DeadMGMay 3 '11 at 0:16

Ok, I think I see what you're getting at. I'm not sure I agree that separating the two concerns can give me the behavior I want, but if you can give a concrete example I'm prepared to be convinced. I've added more explanation in the question in order to describe at a higher level the behavior I'm looking for.
–
Paul ZMay 3 '11 at 0:47