| Monday, November 01, 2004 - 11:40 pm |
That's what your more sophisticated approaches plus the ideas on setting delay times lead to: actual traffic with transport vehicles which may be free or en route defining everything, from transport capacity to shipping cost. That would surely be a lot of fun, but would probably put way too much load on the server, even if you model things sketchily
So the trick is to find a way to implement it without requiring much new server load.
I think you're right that trying to really model transport "positions" etc is *way* too much. But let's see what's needed *just* for implementing shipping and distance offsets.
I think it can be done without a huge new load in computation time, which I think would be *well* worth the substantial improvement it would provide in economic realism, strategy, and interest.
The only conceptually new thing is a "transport queue" to implement a delay between purchasing and acquiring. Everything else is a variation on existing themes and ought to be able to be integrated into data structures and code flow fairly easily.
A new "shipping index" is needed for countries, but that will be easy to model on existing indices like health or education.
New shipping industries should be added, but this is simply adding in additions to the industry tree.
An additional calculation step is needed to compute the actual price, offset by distance & shipping. This addition shouldn't be too difficult, but it depends on how the thing is coded.
Working backwards through the above list:
Effective price vs Production price
When trying to figure out the existing purchasing price from a given coorporation, rather than taking the flat production fee from that coorp, an additional computation is done to find out how much it costs the consuming coorperation to purchase the commodity.
Just add industries which produce truck transport & ship transport, which in turn require trucks and ships and so forth. (Modelled on air transport.) There also needs to be a new "shipping maintenance" coorp just as there is a road maintenance coorp.
Countries buy transport (air, truck, ship) in the same way they buy roads. A country has a "quantity" of shipping which it then must maintain with the new shipping maintenance industry. Like roads, shipping can be sold off.
The shipping index of a country is added to the "index" list and recomputed just as other indices are recomputed.
This index is a function of the quantity of shipping the country (or enterprise) maintains divided by the percentage of goods the country (or enterprise) imports. (I.e. the more internal consumption there is, the more useful the same "amount" of long-distance shipping is.)
This handles the delay between when a product is purchased and when it is delivered.
When the code gets to the existing "transfer commodity" step, rather than transfering it directly to the purchaser, it transfers it to a new "transport" data structure, noting in its entry: the delivery date, the producing country/enterprise, the purchaser, the commodity, the commodity production price, and the shipping surcharge.
Every game day, this new data structure is checked and all "arriving" commodities are "delivered" to the purchaser.
And that should do it.
Comments / Additional considerations:
Products ought to have a new field attached -- transport cost. Why should more expensive computers cost *more* to ship than less expensive iron ore? After all, the computers *weigh* less... should cost basically the same per ton, not the same for a ton of iron and one computer.
Accordingly, there should be a Pt associated with every kind of commodity which gives the base "shipping cost" of each kind.
The Fn which generates the shipping offset should be something along the lines of the following:
Pe = effective (purchasing) price
Pp = production price (and local-market cost)
Pt = transport price of the commodity
S = base per-mile shipping cost
D = miles between producer (A) and purchaser (B)
Ta = transportation index of A
Tb = transportation index of B
Sa = shipping index of A
Sb = shipping index of B
Thus Pe = Pp + Pt*Fn()
And Fn is something like:
Fn() = (S*D) * 6 / [ (Ta/100) + 2*(Sa/100) + 2*(Sb/100) + (Tb/100) ]
i.e. the (S*D) is offset by a factor computed from the transportation & shipping indexes of the two countries. If they're all 100 (representing 'average'), there's no offset.
I weighted the shipping indices twice that of the transportation indices to make international shipping have twice the impact of local transportation; this could easily be varied.
In fact, not much harder and even more realistic would be to weigh in the shipping indices *more* the further the distance: with D=0 (which would never happen, that's effectively the local market), Sa and Sb contribute zero; with D=infinity, Ta and Tb contribute zero.
Fn() = (S*D) * N / [ t*(Ta/100) + (s*m/D)*(Sa/100) + (s*m/D)*(Sb/100) + t*(Tb/100) ]
where N = (2t + 2D*m/s)
t = transportation index multiple
s = shipping index for maximum distance
m = max distance (i.e. 1/2 the globe)
Thus if t is 1, s is how many times that transportation value it should cost to shift half way around the globe, which ought to be related than the number of countries side-by-side it would take to get halfway round the globe on average.
For enterprises, there's no transportation index, so you just base it on shipping. Alternatively, enterprises don't own shipping at all and are dependent on the host-country's shipping for anything it buys from outside its "local" market. Or some other more realistic solution.
Some percentage of the shipping cost (Pe-Pp) is refunded to the shippers as profit to help offset the "maintain shipping" costs of a country.
This should reward the higher-shipping country proportionally more, so the refund for country A would be
refund = n% * [ Sa * (Pe-Pp) / (Sa + Sb) ]
This refund is given when a product is actually delivered to the producer. (Thus why I had remembering Pp and shipping cost entered into that queue above.)
Thus purchasing becomes:
* calculate actual purchase cost and decide to buy.
* buy: Take Pe $E from buyer and give Pp $E to producer. Put items from producer into transport queue.
* deliver: Distribute a percentage of (Pe-Pp) to both buyer & producer's shipping maintenance. Give items to buyer. Remove items from transport queue.
Actually, I think the only really difficult part of implementing this would be none of the above (after all, the only conceptually new thing is the "transport queue", which ought to be quite simple to plug into the code), but rather the integration of this into forecasting.
On this, please see the following message.
But, at least as a guess, the above doesn't strike me as additing too terribly much processing time, it's simply a few new data structures and a slightly more complicate equation. (Though the cumulative effect of computing Pe each time might be significant.)
I think the above ought to be fairly doable, the next question would be how to implement it without disrupting the game or crashing the economy.
Do it, I think, like this:
(A) Figure out what quantities of air transport, sea transport & land transport (trucking) will provide a 100 index.
(B) Give every country this quantity in stock, so everyone has an "average" shipping and isn't penalized. (This could be scaled back after a set time... e.g. warn people that in a real month they'll start losing a certain quantity per game month until this initial "startup" quantity is partially or completely recinded.)
(C) Warn players that "shipping maintenance" will be starting up in a month real-time. In the interim, allow countries to *earn* money buy buying maintenance. (i.e. until then maintenance is free and the maintenance they buy turns a profit.) This will stimulate economic production of that industry.
(D) Put some coorps producing the new industries in unowned countries. (Or if there is, as I imagine there must be, "dummy countries" which don't exist on the map and can't be player-controlled, have them start producing these new commodities.)
(E) Phase in the new shipping costs, to allow the market time to respond. Costs could be started, after one real month's delay, at 2% of their actual value and rise at 2% each game year until they reach the final 100% value. This should give plenty of time for the market to gradually shift from the less-realistic "everything is local" market to the more realistic "distance matters" market as transport costs/delays slowly become a factor.
Adjustments in the red/green supply bar, described in the next message, will help encourage players' economies to respond accordingly as well.