Closed Itangalo closed 2 years ago
Perhaps the right approach is not to have resource as a class, but market. Then you could have types of resources defined in the market, as well as costs/conversion rates for various things.
(Thanks for Chuck L White Jr. for bringing up things that led to these thoughts.)
Ok, so here's a sketch of what a Market class could provide.
false
if the buy couldn't be made. Not the good itself, since it is already known to the buyer. Any special effects are taken care of by the resolver function, so that should be called when the good is bought.
Also: setPrice, getPrice, setQuantity and getQuantity methods.
A potential problem with the 'any' cost is that the payment might be made with another resource than the agent intended. Standard principle would be to take the most abundant resource after non-any resources are paid. If the agent wants to control it further, the resource list sent to the buy method should be set to only the resources used in the purchase.
Possible addition: managing goods costing a flexible amount of resources. (Pay X, get X+1, or something.)
Possible addition: Managing resource deduction from agents. This would require a standardised way of storing resources (such as sub properties of agent.resources).
And: Initial value for quantity. Perhaps a cap. And a method for restocking. (Good when markets are used for worker placement.)
Implemented, mostly. Still to do:
Closing this issue. See #30 and #31 for remaining issues.
Could it be useful, for providing methods for converting resources or managing prices? Or is it handled by add-on code just as well?