citizen2608
New member
This might not be all that interesting, but it will be informative! (And if I type it all out I'll have something to refer to, instead of being baffled by my own system).
The facts:
A resource is worth exactly what someone is willing to pay for it.
A resource can have multiple purposes and be worth different values to different buyers.
A resource changes value as it's supply changes.
A resource will lose value if a better example becomes available.
The problems:
A seller doesn't have all the information required to ask for the highest or fairest price.
The information needed changes with each day and each buyer.
Individually pricing each resource for each transaction is time consuming.
Varying prices for each transaction leads to customer dissatisfaction.
The SWG vendor system is not well suited to resource transactions.
The solution:
An automatic and standardized system that takes common factors into account when calculating a price.
An out of game storefront and ordering system.
Pricing factors:
Total supply - Unknown.
Total demand - Unknown but can be accounted for with a modifer.
My supply - Known and can be accounted for with a modifier.
Quality - Known and can be accounted for using a scheme.
Age - Known and can be accounted for using a scheme.
Pricing scheme:
For each 85% to 89% add : 0.5
For each 90% to 94% add : 1.0
For each 95% to 99% add : 1.5
For each 100 % add : 2.0
> 1 yr old add : 1.0
> 2 yr old add : 1.0
> 3 yr old add : 1.0
> 4 yr old add : 1.0
> 5 yr old add : 1.0
Price ceiling is : 5.0 (the calculated price cannot go above this value)
Price floor is : 2.5 (the calculated price cannot go below this value)
SB (Server Best) are : 6.0 (the price floor of a resource marked as SB will be this value)
Price modifier is a per-resource multiplication of the base value, within floor and ceiling limits.
Increased age doesn't increase price, but it could if desired.
Example using Aleowo Duralumin Aluminum:
First we figure out the percentage values for each attribute. The example shows that the OQ value is 96% and that none of the other attribute values are good enough to be considered.
Then we retrieve the values from the pricing scheme, which is 1.5cpu for an attribute value between 95% and 99%. The example pic also shows a value of 1cpu for the age, and a value of 1.0 for the modifier. That puts us at 2.5cpu which is equal to the price floor and below the price ceiling.
Finally we take either the sum of the pricing factors (2.5) or the price ceiling value (5.0), whichever is lower.
Then we multiply that by the price modifier (1.0).
Then we take that value or the price floor, which ever is higher. (In this case they are both 2.5)
Such a system requires 42 columns for each resource, which is not excessive for fans of Spreadsheet Wars Galaxies. I think it's about as fair and "low-effort" as I can make it. But maybe I missed something? What do you guys think?
The facts:
A resource is worth exactly what someone is willing to pay for it.
A resource can have multiple purposes and be worth different values to different buyers.
A resource changes value as it's supply changes.
A resource will lose value if a better example becomes available.
The problems:
A seller doesn't have all the information required to ask for the highest or fairest price.
The information needed changes with each day and each buyer.
Individually pricing each resource for each transaction is time consuming.
Varying prices for each transaction leads to customer dissatisfaction.
The SWG vendor system is not well suited to resource transactions.
The solution:
An automatic and standardized system that takes common factors into account when calculating a price.
An out of game storefront and ordering system.
Pricing factors:
Total supply - Unknown.
Total demand - Unknown but can be accounted for with a modifer.
My supply - Known and can be accounted for with a modifier.
Quality - Known and can be accounted for using a scheme.
Age - Known and can be accounted for using a scheme.
Pricing scheme:
For each 85% to 89% add : 0.5
For each 90% to 94% add : 1.0
For each 95% to 99% add : 1.5
For each 100 % add : 2.0
> 1 yr old add : 1.0
> 2 yr old add : 1.0
> 3 yr old add : 1.0
> 4 yr old add : 1.0
> 5 yr old add : 1.0
Price ceiling is : 5.0 (the calculated price cannot go above this value)
Price floor is : 2.5 (the calculated price cannot go below this value)
SB (Server Best) are : 6.0 (the price floor of a resource marked as SB will be this value)
Price modifier is a per-resource multiplication of the base value, within floor and ceiling limits.
Increased age doesn't increase price, but it could if desired.
Example using Aleowo Duralumin Aluminum:
First we figure out the percentage values for each attribute. The example shows that the OQ value is 96% and that none of the other attribute values are good enough to be considered.
Then we retrieve the values from the pricing scheme, which is 1.5cpu for an attribute value between 95% and 99%. The example pic also shows a value of 1cpu for the age, and a value of 1.0 for the modifier. That puts us at 2.5cpu which is equal to the price floor and below the price ceiling.
Finally we take either the sum of the pricing factors (2.5) or the price ceiling value (5.0), whichever is lower.
Then we multiply that by the price modifier (1.0).
Then we take that value or the price floor, which ever is higher. (In this case they are both 2.5)
Such a system requires 42 columns for each resource, which is not excessive for fans of Spreadsheet Wars Galaxies. I think it's about as fair and "low-effort" as I can make it. But maybe I missed something? What do you guys think?