[Rejected] Complex economy in X-com

[Mrak]

Rejection reason: this is beyond/outside the scope of OXCE


Is this relevant?
The economy should add more options for flexible customization of the game with cash resources. And as a bonus, additional options complicate your life.

Project: Economics X-com

Tasks of the Economy:

// Change the price "total per month"
// Change the price "random per month"
// Change in price "events:
fixed> + price; -price;
percentage> * x% ""
// Change the price for the "people" position separately
// Change the price for the position of the "machine" separate
// Price balance in the range: from Minimum price to Maximum price.
// The fall in the price of goods over time "in the absence of its procurement"
// Price increase when buying a product for a limited time
// Rising hiring prices with the deaths of Agents, + x%
// Price fall while saving Agents / month, --x%
// Increase in the price of the maintenance of Agents depending on the ranks, + x% / rank
// Increase in the price of hiring Engineers and Scientists from their existing number, + x% / person
// Payments to relatives for the deaths of Agents
// Compensation payments upon dismissal of people monthly salary

//Inputs:
//Starting price
//Current price

//The coefficient of price change when recalculating from the current price to the new price

//Output:
//New price

// minimum share price of the starting price (by default, a quarter = 25%)
// maximum price increase (by default four times = 400%)

I use Google translator, therefore I ask you to write easier, without untranslatable slang.

And if you have ideas to complement this or wishes, write.
As a result, we can draw up a well-written technical task.
I can hardly write this code on my own. But I can try to write at least something.
What is possible (if Meridian of course, in general, wants to do this) will help him reduce development time.

[vadracas]

This would be fantastic!

[Bobit]

Discounts can already be implemented by getting a limited number of "coupon" items which can be manufactured into the desired items at reduced cost. They can also be randomly distributed.

Compensation to the dead already exists in the form of score.

I think it's a good abstract design for a campaign to have economic fluctuations. But there's no need to implement it twice.

[wcho035]

There is already a request like this.

https://openxcom.org/forum/index.php/topic,7500.0.html

Please check it before raising another one similar.

[Finnik]

I think the easiest and most necessary part here is the rule that the more you sell an item, the lower the selling price of that item. Maybe it makes sense to make a property in an object that introduces a coefficient to this formula. Say, selling trophy AK-47s after some time will not be so profitable, but rare and valuable mind probes will always be in price.
All this might be quite good for correcting a problem that I often hear about in XCF - in lategame the economy breaks down and the value of money is no longer there. Of course, this needs to be fixed in the mod itself, and only modifying the engine for this is not the clearest way. In addition, we will have to store in a save file a quantity for each sold item, and read this quantity every time the sale price is calculated.
By the way, if you store this data in a save file - we could do this - by buying an item we reduce the value in the counter, and by selling - we increase it. We can store negative numbers, right? Then one integer will be used to modify the price of buying and selling, and selling a lot of items, and then buying them, you could correct the dynamics.
But still, these rather massive changes in the mechanisms of the game, will only implement the simplest mechanics, price changes will be a constant parameter and there will be no relaxation of supply and demand, this is a separate mechanics.

I can't say that this is a priority thing, although in my opinion it would help solve some problems. If we define the design, I can work on the implementation, it seems not to hard - we need advance of the methods of getting the price and incrementing of new records on items in save after approving buy/sell (and output them in save).

[vadracas]

Am I correct in saying the main difficulty would be making the buying and selling of item's values mutable outside of .rul files?

[Finnik]

With that approach values from rules would be base for calculations, and in save there would be the only modification for that value. I don't think it's so hard to save an array of items, only case not that obvious for me at this point is forming that array after buying and selling, but it's possible to handle, I think. Btw, relaxation could be made with this - on monthly debriefing, we get all that value for each item and reduce it by some fixed factor. Its all should be optional ofc, under some global vars (one for enabling the model and one for relaxation factor)

[Solarius Scorch]

X-Com: Apoc has this feature. If you're interested, you can talk to OpenApoc people - or maybe even read their code, if it's already written (I don't know).

[Finnik]

More interesting question - would OXCE devs agree to have such optional feature