| Monday, November 01, 2004 - 11:40 pm |
Here's the "tricky" bit from the last message. Read that one (below) first. :-)
Before touching the "tricky" stuff, a comment on how cool all this would be.
See, what it would allow for is the creation of "regional" markets. I mean, it's not too realistic to have 10 countries all right next to each other producing the same high-demand commodity. I mean, in reality that would produce a local glut which would offset the demand. But not in the game as it currently stands.
Further, it adds a whole economic dimention to warfare as these local markets become a factor. Does the country have a production you really want? Or do you want just to destroy its factory which is producing a high-demand commodity you'd rather corner the market on.
Also, this allows enterprises to move one of their coorps from a low-demand region to a high-demand region, which gives that coorp-moving ability substantially more interest and economic impact.
But the "tricky" bit of all this is (a) forecasting supply and (b) reflecting local markets.
Coorps now need to keep track not just of their stock but the rate at which it's going to be refreshed. After all, with "instant" transport, you just need to buy enough to have it on hand. But with travel-delays, the coorp needs to look ahead -- it's not useful to have 10 months worth of a good coming in if you're out now and it's not going to arrive for 3 months.
Here's a solution, or at least ideas towards one:
(1) Allow coorps to have a "keep stockpile" field for each raw material. (A change I think ought to be implemented anyway.) This allows the player to build up higher reserves of more truculent commodities.
(2) For each coorp, add a new element to the data structure which tracks "anticipated delivery" of incoming goods. Entries are added when goods are purchased and deleted when they arrive. (A pointer to the associated field could be created in the "transport queue" entry, so it's easy to delete the entry upon arrival.)
(3) This allows coorps to forecast their incoming stock. In the "check quantity" portion of processing the company, instead of forecasting the upcoming quantity simply in terms simply of existing stock and projected use (as is the case now), forecast it in terms of current stockpile, plus what will be used by forecasted time T, plus what will have arrived by forecasted time T. Companies should look forward from the present time T up to time T+n, where n is the amount of time it would take goods to arrive from half-way around the world (i.e. longest time possible.)
This forecast could be done every month and for every month (up to T+n), but I think it would be better to have *weekly* forecasts which assume 25% of production is done every week and calculates anticipated stocks accordingly.
A coorp thus decides what to purchase not just by checking the "instantaneous" situation, but rather by checking the "instantaneous" situation for each of those forecasted-weeks and buying accordingly. Same basic computation as at present, just adding in the forecast/deley element.
[To "even out" processor time, divide all possible products into 7 groups and, every game day for the first 28 days of each game month, do the forecasting for one of those groups of commodities -- i.e. on the 1st check all coorps producing gold, soybeans, meat, etc... on the 2nd check out all coorps producing computers, iron, eggs, etc... and so forth.]
When coorps make a request for a good, they will need to also give a "maximum delivery time" value. I.e. if the coorp forcasts that it will need 1000 more computers in 2 months it should limit its purchasing to companies which are close enough to get it there by then.
Generally this should even out pretty well -- once the coorp has it's "forecast" fairly stable it will generally simply be buying for the furthest-ahead week -- but it does allow for coorps to be sensitive to regional supply.
Also means that if there's a sudden surge in production the coorp has to rely more heavily on regional markets to get its raw materials in time -- again, a whole new element of realism currently lacking.
Reflecting regional markets
All this will actually help build up those regional markets, making things much more realistic.
Eventually, this ought to be reflected in "demand." For example, if one country is the *only* producer of computers for 1000 miles, demand for its products will be *higher* than for an identical company surrounded by other companies.
Now, in terms of buying and selling this will already be taken care of simply by the shipping & transport algorhythms already described.
Eventually, though, it ought to be reflected somehow to the player -- so that the red/green bars don't give the worldwide supply/demand but reflect this more nuanced and realistic situation. Players ought to know, for example, that they can expect to charge more if they're the only regional producer of a commodity, since while they may produce it more expensively than a distant coorp, because of reduced shipping costs & delays they'll be more competitive.
Not knowing how things are coded, I can't say how this best would be done, but there would need to be some more complicated computation of "worldwide demand" to replace the current single-value generation.
I.e. what's relevant to the player is not what the "worldwide demand" is, but rather what the more regional demand is.
A quick and dirty solution would be to divide the world into a grid (with squares, say, of 50-100 miles a side) and calculate the "demand" separately for each grid. I.e. rather than one value for each commodity calculate several values, one for each grid location.
The calculation would be similar to what is done now, but closer companies would be weighted more heavily rather than treating them all equally.
I'm guessing at the moment demand is computed by scrolling through the existing coorporations to calculate supply and demand.
A quick-n-dirty way to reduce processing time to do this including distances would be the following:
Make the grid small enough so that no country is smaller than a grid square. As contries are already layed out in a fair grid-shape, this shouldn't be too hard.
Now assign each grid square to a country. No square would have more than one country (i.e. the one principly containing it) but countries could have more than one square.
When calculating the "distance", rather than doing it 'absolutely', simply use the grid squares to approximate distance. As each grid square will point to its unique country, it's each to scroll through the grid squares and check those companies for production. The only trick would be sure not to check any country twice.
Currently, I imagine, the calculation for supply and demand simply scrolls through all existing coorps.
The way it would work now would be to scroll, instead, through sets of grid squares, which in turn point to the countries and their coorps. (First you'd do the "nearby" squares which get weighted most, then those slightly further which get weighted slightly less, and so forth.)
If the code is more sophisticated and efficient, I suppose the supply and demand is constantly updated each time a company's production or demand changes rather than as a "housekeeping" recompute every game day or something.
If this is the case, the same quick-n-dirty solution can help.
Rather than updating the single worldwide-supply/demand value for the commodity, update that value in all the grid squares, with the appropriate weighting.
When companies want to find out what the "regional" market is for the red/green bars, they simply use the values in their country's grid square (or the average thereof, if a country 'owns' more than one square).
Anyway, I think this tracking of regional markets and projecting of coorporation supplies would be the only truly significant time/processing increase for computation.
Just implementing the distance/shipping stuff, as described in the previous msg, I think would be simply a matter of:
* a few new commodities (trucks, maintenance, etc)
* a new index & its support (like transportation or health care)
* a slightly more complicated purchasing algorhythm to factor in shipping costs
* a "transport queue" step between buying/acquiring