Fwurg

[Mercury]

Based on feedback from the player base, we are making some changes to make it easier for new players to start out.

First off, I have looked in detail at the tax scheme. A proposal was made to adjust the tax sets, so it was easier to step up from one tax set to another. Originally, this was deliberately not done as I wanted players to specialise, but without a large player base, this scheme does not work as well as intended, leading to a "buddy" system rather than an open economy.

I have studied the new idea where two tax sets of level 1 (tax set 1-4) would form a tax set of level 2 (tax set 5 and 6), but I am not happy with it. It widens the buddy options, but in the end I do not believe this adjustment resolves the underlying problem - it merely puts it off by a little.

Instead, I propose the following change:

instead of a number of predefined tax-sets, taxes can be generated by any combination of different products.

Three different products generate 1 , six different products generate 3 , nine different products generate 6 and a full set of twelve different products generate 9 .

Thus, you could combine 1 , 1 and 1 to generate 1 (but not 3 , since they have to be different).

This also makes the calculation of how much tax is generated easier: generate per 12 until you run out, then generate per nine, then per six and then per 3, based on the lowest number. Anything you want to use for other things, such as producing special goods, would be handled beforehand.

The advantage of this scheme is twofold:

1. the addition of a 9 product tax group makes the step between tax levels easier (3 additional products always gets you extra cash)
2. the lack of defined tax sets makes it easier to trade individual goods. So long as the trade partner does not have it yet, it doesn't matter what good they get - they aren't bound by having to complete a specific tax set

What do people think?

[Veolian Commonwealth]

I like it!

It removes vendor lock-in (i.e., the "buddy" system we see now) issues, and allows graceful degradation of tax income if trading partners default.

Nitpickery warning, skip at your leisure {
However, the statement on the ease of calculation is untrue. While the presented algorithm works if only the products are taken into account, it fails when we have to take into account the production of those products. This is because multiple products share a common material (e.g., in and ) with different ratio's of consumption.

Secondly, the 'lowest number of available products' is a terrible heuristic. Given a system with 200 and in abundance (e.g., 1000+) the amount of producible will always be lower than the producible . So any heuristic relying on 'lowest available number' will surely choose the product, which (unless you are making a size=12 tax set) is freely exchangeable with .
}

[Sundarian Federation]

I like this suggested change to the system aswell. While i shall leave the technical (taxtool) implication to others, i do see multiple benefits which rise from this new system.

As Brend already said, it offers more freedom in bases of production and causes less struggle in finding partners for a single good which is in overproduction. Futhermore it allows for players to chose more freely which goods they want to produce and thus creating the possibility of world building only 1 or 2 goods.

Furthermore it causes more trade as the new system in itself enables more option of trade and thus more traffic will follow to meet the base structure of economics, free market trade. This also makes it easier for new players to set in and play, as the trade economy will now follow a more natural patern which will make the rules ( mechanically) easier to understand.

[Mercury]

Glad to hear this idea is liked so far!

I had an algorithm idea to maximize tax output for a given set of raw materials:

1. Create a new (empty) set of products S
2. Add to S a product for which the following conditions hold:
   
   1. It is not already in S
   2. There is production capacity
   3. The raw materials for the product are available
   4. There exists no other product that meets these conditions for which more raw materials are available
3. Repeat 2 until there are no products left to add
4. Convert the product set S to taxes - return any leftovers (i.e. if there are 10 products instead of 9) last in first out to the resource pool
5. Repeat 1 until no further tax sets can be converted
   
6. (Dump everything that's left on the open market, from most expensive to least expensive as capacity last)

Step 2d is calculated for double resource products by adding the amount of that resource twice and for mixed resource products by adding the amount of one and the amount of the other together. Effectively the product which has the highest value for this is added first, then the next best, etc.

There might be a few edge cases where it goes wrong but I think this gives a very reasonable approximation of the maximum possible tax income?

[Veolian Commonwealth]

This evening a discussion was held with 75% of the players and the 100% of the adminstrators in attendance.

For the record: We have determined that the tax-tool should support this new system before switching over. Before completely switching, we will run both versions of the tool in paralel. This allows is to tweak the algorithm without breaking the flow of the game. After a few turns of testing, the tax-tool will be replaced.

On a more personal note, I think I can fit in the conversion of the tax tool before the end of this year. When I have a testing version up and running I will update you all through this thread.

[Praetorian Empire]

As representative of the 25 %, i am allowed to voice our opinion.

I am fine with the gradual switch between systems. I like the new idea, lets make it happen

[Veolian Commonwealth]

The first version of the Tax Collector β3 is available.

This new version implements the new tax model. The new tax model deprecates the following directives: reprioritize and surplus. The reprioritize directive is of no further use, as it was used to re-order tax sets. The surplus command is not feasible any more, since no economic process can be executed after tax generation.

The surplus directive has been replaced by the reserve directive. The reserve directive does exactly what the name implies: it reserves a set amount of products. These products will not be used in any further economic processes. No taxes will be generated from them, they will not be used as the ingredients of another product. Reserved goods are, in effect, removed from your economy.

Please take note of any broken situation, as we need to fix those before switching over.

Reserve Product Directive

Reserves X items of product Y.

---- dataentry [Directive 1] economic_directive ----
System_ref: Smi-Halek System
Directive: reserve
Product A_rule: Gasses
Amount: 20
----

The example reserves 20 gasses in the Smi-Halek economy.

EDIT: Note on known bug removed -> bug was fixed.

[Mercury]

Awesome, that was very quick! Does that mean that (barring bugs) the new system is already operational?

[Veolian Commonwealth]

It was reasonably quick. After an hour of debugging just now, because Chriz found a major UI bug (that made it seem as if magic or were produced from thin air), we think that most influential bugs are squashed.

The algorithm currently in use does not calculate the optimal tax profit, but it comes very close.


Nerdiness warning {
The current heuristic used to order products for tax set inclusion is as follows at the moment:

1. Is the product already available? score = 10000000
2. Can we actually make the product available through a production process (and thus implicitly checking the available raw material production etc.)? score = available production capacity of the product only. So we completely ignore the raw material availability.

We have also tried different heuristics, and compared those heuristics both on -profit and running time. I'll spare you the exact details of these different versions. The current heuristic performs 2 worse on Guaire than some of the other heuristics, and is literally 10 times as fast as the most -profitable heuristic.

For your information: the slowest heuristic went on for at least 4 seconds in FireFox 9.01 (on my Pentium i7).
}

[Mercury]

Why is that one used instead of the one I posted? I can't believe that the one I posted would take four seconds o_O

[Veolian Commonwealth]

Why is that one used instead of the one I posted? I can't believe that the one I posted would take four seconds o_O

It took four seconds due to bad implementation. After carefully reviewing the implementation (and judicious application of assumptions) we were able to get your algorithm working within an acceptable time limit.


However, now we have discovered an even better heuristic (product with highest score is selected):

1. Is the product already available?
   • score = 10000000
2. Can we actually make the product?
   • score = the minimum of the available production capacity, and the maximum amount of units that can be created with the available raw materials (i.e., available raw material / raw materials required per product.)
   • Example: assume 100 , 90 and plenty of production capacity are available. would score 90, while would score 50 (100 / 2)

This one scores slightly better with the last set assignments, as it tries to use up those products that are readily available, while saving rare things for later (where they can probably squeeze together in a tax set or two).

[Veolian Commonwealth]

I have updated the tax rules page, so it reflects the new system.

Please review and revise where necessary.

[Veolian Commonwealth]

I have changed the official tool to reflect the rules changes.

[Mercury]

New tax tool appears to be working perfectly! Nice!

[Freekjan]

However, now we have discovered an even better heuristic (product with highest score is selected):

1. Is the product already available?
   • score = 10000000
2. Can we actually make the product?
   • score = the minimum of the available production capacity, and the maximum amount of units that can be created with the available raw materials (i.e., available raw material / raw materials required per product.)
   • Example: assume 100 , 90 and plenty of production capacity are available. would score 90, while would score 50 (100 / 2)

This one scores slightly better with the last set assignments, as it tries to use up those products that are readily available, while saving rare things for later (where they can probably squeeze together in a tax set or two).

Could you please drop the score of available products to: the amount of products available + score per 2. ? With the current scores, imported products always get picked for the first few sets, even when imports << production. This means that while I am importing sufficient products to produce 20 9-sets, the tax tooler only wants to make 10 ( and should be in different sets)

[Brend]

Could you please drop the score of available products to: the amount of products available + score per 2. ? With the current scores, imported products always get picked for the first few sets, even when imports << production. This means that while I am importing sufficient products to produce 20 9-sets, the tax tooler only wants to make 10 ( and should be in different sets)

This looks like a most desirable improvement. I'll update my development version and see how it pans out before updating the official tool.

[Brend]

Tax tool updated!

I noted that not only does the tool now assign the tax-sets of Xi correctly (i.e. with a much higher yield), it also improved the tax income of Darya.

@Freekjan: Thanks for the suggestion! It might be interesting to sit together some time and see if there are even better heuristics -- Chris would be interested in that as well methinks.

[Freekjan]

After some thinking along the line of "There are only 18 really relevant things to optimize over and I don't care if it takes as much as 2^18 microseconds to solve the tax problem" I have tried to solve the full NP-hard system. This means I now have an integer linear program that is solved by a specialized solver (AIMMS 3.10) in as much as 0.02s.

The linear program takes the production capacities of all raw materials and products, and the open market trade capacity. It then computes:

1. How to deal with the open market
2. What products to give to your population as three-sets, six-sets, nine-sets and twelve-sets

It does not, at the moment, consider special goods, but nobody produces those for their direct -profit anyway. It also does not make the actual sets, but if it is known what products should be put in three-sets, the current tax-heuristic can correctly allocate them. The actual program is stated as:

• given:
  
  1. for all raw materials and products x: the production capacity prodcap(x)
  2. the open market trade capacity omcap
  3. for all raw materials r and all products p: the required ingredients req(r,p) (example: req( , )=0; req( , )=2
  4. for all raw materials and products x: the total net. amount imported from other star systems trade(x) (trade(x) is negative if x is exported
  5. for all raw materials and products x: the price to buy from the open market ombuyprice(x)
  6. for all raw materials and products x: the price to sell to the open market omsellprice(x)
• maximize: three+3*six+6*nine+9*twelve+floor(sum(x,omsellprice(x)*omsell(x)-ombuyprice(x)*ombuy(x)))-tax over all relevant variables
• such that:
  
  1. sum(p,three(p))>=3*three (read as sum over p, three(p);three is the amount of three-sets, three(p) is the amount of products p to be put in three-sets)
  2. for all products p: three(p)<=three
  3. sum(p,six(p))>=6*six
  4. for all products p: six(p)<=six
  5. sum(p,nine(p))>=9*nine
  6. for all products p: nine(p)<=nine
  7. for all products p: three(p)+six(p)+nine(p)+twelve<=prodcap(p)+trade(p)+ombuy(p)-omsell(p)
  8. for all resources r: sum(p,req(r,p)*(three(p)+six(p)+nine(p)+twelve-trade(p)-ombuy(p)+omsell(p))<=prodcap(r)+trade(r)+ombuy(r)-omsell(r)
  9. sum(x,ombuy(x)+omsell(x))<=omcap
  10. tax=(three+3*six+6*nine+9*twelve)/10+tier2/10+tier3/10+tier4/10+tier5/10
  11. tier2>=tier3>=tier4>=tier5>=0;three(p)>=0;six(p)>=0;nine(p)>0;twelve>=0;ombuy(p)>=0;omsell(p)>=0
  12. tier2>=three+3*six+6*nine+9*twelve-1000
  13. tier3>=three+3*six+6*nine+9*twelve-2500
  14. tier4>=three+3*six+6*nine+9*twelve-5000
  15. tier5>=three+3*six+6*nine+9*twelve-10000

Where all variables are integers. If Someone is interested in implementing this (and a solver) as a new tax tool, I will be glad to help explaining relevant algorithms and the details of the program.

[Brend]

Sounds interesting -- not sure if this is reasonably implementable in pure javascript. It might be interesting to run this on a server somewhere though. But before we start implementing -- some questions.

It does not, at the moment, consider special goods, but nobody produces those for their direct -profit anyway.

I take it this means: "I don't optimize for special goods that could produce tax if a buyer were available for them. Instead you can just take the required economic steps before applying this program to the leftovers of the economy."? As I really need my production to stay alive -- trades with others and such.

About the ombuyprice(x) and omsellprice(x): those are not integers, but there are explicit rounding rules for the sum of both values. How is this handled? (I assume that some scaling trick can be exploited here).

[Freekjan]

It doesn't factor in production and such. This means it doesn't know your production cap and you can just trade out 4x and 4x for every you wish to produce. (reserve directives are to be considered trades in this context)

Since ombuyprice(x) and omsellprice(x) are parameters instead of variables, nothing requires them to be integers. As far as I understand the open market trade rules, they boil down to "add up all costs and profits, then round to your disadvantage." So if negatives are handled as negatives, you always round down.

...
maximize: three+3*six+6*nine+9*twelve+floor(sum(x,omsellprice(x)*omsell(x)-ombuyprice(x)*ombuy(x)))-tax over all relevant variables
...

[Brend]

Thanks for the explanation; I missed the floor function ^_^