Ok, I've been kicking this can down the road for a while, time to give this some serious thought.
I build a widget. It comes out to 5₡. All of a sudden, there is an iron shortage and the resource cost of iron quadruples. Suddenly, I'm stuck with a widget that nobody wants to buy, and if I sell it for 1/4 the cost, it dings my performance.
The problem here is that we value resources and currency at the point of consumption, not at the point of inception. However, resource and currency costs are variable, and it would make for a very unstable economy to have these values shifting out from under us all the time based on the whims of the global currency system or resource shortages.
I believe it makes sense to aggregate and store resource/currency costs as an aggregate value inside the Costs object, and this aggregate value would be set at the moment the costs are created.
This makes things work a lot closer to how money does, and allows shifting the underlying resource/currency costs without putting too much strain on existing flows.
A nice piece of this is that cost/value conversion only needs to happen at the point of inception: we no longer need to worry about converting resource/currency cost values into credit values whenever we need to check a company's max costs, and a company's max costs is no longer variable depending on the shifts of the overall resource plan or banking snafus. This allows us to get rid of the CreditConverter and instead record the cost directly into the Costs object.
Implementation deets:
[x] Make costs moveable only in fractional chunks.
Right now, when I move costs between a chair and a toaster, I can cherry-pick which cost buckets go where and divide things up arbitrarily. This method will no longer work with an aggregate cost value, and instead we need to move costs as all-or-nothing fractional chunks. I can no longer move specific cost buckets, but rather 50% of the costs. I kind of always wanted this anyway.
Might make sense to implement this directly into Costs and do away with subtraction altogether, or at least provide a more robust interface for this so it's harder to do the wrong thing. Needs more thought, will probably figure it out when I open the hood. Ended up implementing this in the transaction layer as a new Ratio struct. Implementing in the Costs was a great idea, but ultimately a) i want going to probably implement this in the transaction layer anyway and b) the best way to check if a Costs is in proportion is to divide and them multiply again, but this is almost always lossy and never compares well, even when rounding
[x] Update any cost-moving transactions to move based on ratio (0 - 1), not absolute cost value. This shouldn't be an issue because the object we move costs to/from will already be full objects and have their costs listed anyway.
[x] Purge the matter-antimatter exhaust manifold. It has been getting gummed up lately, and the scrubbers are malfunctioning again.
[x] Do NOT mark this complete without rewriting the docs in the costs module and updating the unit tests.
Ok, I've been kicking this can down the road for a while, time to give this some serious thought.
I build a widget. It comes out to 5₡. All of a sudden, there is an iron shortage and the resource cost of iron quadruples. Suddenly, I'm stuck with a widget that nobody wants to buy, and if I sell it for 1/4 the cost, it dings my performance.
The problem here is that we value resources and currency at the point of consumption, not at the point of inception. However, resource and currency costs are variable, and it would make for a very unstable economy to have these values shifting out from under us all the time based on the whims of the global currency system or resource shortages.
I believe it makes sense to aggregate and store resource/currency costs as an aggregate value inside the
Costsobject, and this aggregate value would be set at the moment the costs are created.This makes things work a lot closer to how money does, and allows shifting the underlying resource/currency costs without putting too much strain on existing flows.
A nice piece of this is that cost/value conversion only needs to happen at the point of inception: we no longer need to worry about converting resource/currency cost values into credit values whenever we need to check a company's max costs, and a company's max costs is no longer variable depending on the shifts of the overall resource plan or banking snafus. This allows us to get rid of the
CreditConverterand instead record the cost directly into theCostsobject.Implementation deets:
Might make sense to implement this directly intoEnded up implementing this in the transaction layer as a newCostsand do away with subtraction altogether, or at least provide a more robust interface for this so it's harder to do the wrong thing. Needs more thought, will probably figure it out when I open the hood.Ratiostruct. Implementing in theCostswas a great idea, but ultimately a) i want going to probably implement this in the transaction layer anyway and b) the best way to check if a Costs is in proportion is to divide and them multiply again, but this is almost always lossy and never compares well, even when rounding0 - 1), not absolute cost value. This shouldn't be an issue because the object we move costs to/from will already be full objects and have their costs listed anyway.costsmodule and updating the unit tests.