GGS - Production Model Suggestion

[Mark_Lipovrovskiy]

This is the result of a couple of ICQ sessions with J. It's rather incomplete, esp. that one crucial formula is evading us.

Factory/Corporations:

1. Each good has demand prognosis for the next turn, based on all sorts of stuff we'll work out.
2. Each corporation will attempt to produce to meet that prognosis.
In other to do that:
3. It'll hire workers.
4. Wages are calculated based on the number of available and needed workers.
5. Available workers is calculated by skills nessecary. This means that it'll be a lot harder to find workers for specialised production than for rudimentary production.
6. Skills are determined by prognosis info at the time of the worker's "education" (each turn when you add to pool, add accord. to prognosis). Skills are static (maybe later add something to change that)
7. At the end of turn you change supply and demand (add a random factor so you won't have correct prognosis all the time), and income, spending and so on is calculated.

Raw Materials Production:

Per Worker: tools*(tech-excavationfactor)/256 - since tech and excFctr can both be unsigned bytes, it would be best to treat them as a sort of percent from 0 to 255.
Then modify the corporation's efficiency factor by the number of workers on tile - the trick here is to lower the efficiency when you have too much workers, but not in a linear way, but like a y=ax^2+bx+c kinda eq. if you know what i mean. by a hitherto unknown formula, and apply to the Per Worker like thus: perworker*effic-modfactor/100. Efficiency is from 1 to 100, and therefore treated as percent, as you can see above.

Basically, the formula now goes like this:

corp.prjct.tools*(corp.tech-good.excFctr)/256*corp.effic-(insert by workers formula here)/100

Disclaimer: The following is based on my rather limited knowledge of OOP programming, mostly in Java.

As you have noticed, several objects (just suggesting):
corp - this represents the corporation, it's pretty much "top level" meaning it isn't an object of anything else if you know what I mean.
corp.prjct - this represents the project dealt with - can represent factories, mines etc..
corp.prjct.tools represents the number of tools available, some tools can be worth more than 1. It prob. needs some more hierarchy there.
corp.effic represents the corporation's efficiency level (maybe make that 256 instead of 100 too? Or is there any way to make new types in C++, 4 bits for example? Then again, it would be best to use all the numbers available, in an unsigned nibble - i think that that's the name - you have 0-127, right?)

Best wishes and may the Force be with you!

PS. this is starting to look like a business simulation lol
Eventually this will be a game that'll need a dual-processor pentium5 50gH with 32GB RAM with all the calculations we'll stuff in there

[The Joker]

We have already talked a bit about this. But I will think about it and post tomorrow.

[The Joker]

Ok. Basically I think we can divide the basic econ model into two parts: supply and demand.

Demand is based on the income that people have. I have worked out a way to do this; I will try to find that.

Supply is based on demand. In the long run supply and demand should match. But in stead of making the formula so supply will try to meet demand I think we should make a formula that will make the money invested in each sector dependant on the amount of money made in that sector per credit invested the last turn. So if some sector makes a lot of money and another one does not then money will flow from the second sector to the first. What formula to use here I am still not sure of. The trick is to make sure that supply will not "swing" back and forth over the demand, before an equilibrium is reached.

To create a good the following thing is required: Labour, capital (tools - this is always required, the amount, however, fluctuates from good to good) and raw materials (some of these may in fact be manufactured goods - like plastic or eletronics).

The difference between them are, that where raw materials are spent creating the good, labour and capital is not. Capital will only have to be bought once, but it will decay (be destroyed) by a certain amount - propably 20% - each turn. So to keep the same amount the factory will have to buy some every turn. Labour has to be payed every turn, and a factory can demand more or less labour every turn depending on how much is required.

The key to make all this work is to put the market mechanism (supply and demand equals price) into every aspect of the model. Not just with the consumer goods, but with capital (it is created as a good, and is considered a sector on it's own), raw materials and labour. Of cause making all these work together will prover pretty hard, but it is also the way to make the model work as it should.

And regarding the square roots I really think they are good. So have anyone found out how much time they will take for the computer to make, and whether it is possible to make it do millions of it per turn?

[Mark_Lipovrovskiy]

Joker man, but what about what I suggested?

[The Joker]

Sorry.

I just have to get my thoughts together.

To comment on the stuff you've made:


Factory/corporations:

1: Yeah.
2: Propably. But I think that in stead of making it try to meet a demand the private sector should put money into the sectors that gives the most profit. A sector might have the biggest demand in the world, but if noone made money on it last year noone will want to invest there. Of cause this is simplified, but that is how I think it should work.
3: Yeah.
4: Hmm. I think we have a supply/demand situation here as with the goods - so supply and demand should decide the wages.
5: Yes.
6: Possibly. It might be a bit complicated, but in the long run there should be some way to define workers' skills.
7: I don't think YOU would change supply and demand. You would just do what the government does - set tax rates, tariffs etc. The economy will run on it's own out of your control. Unless, of cause, you are a communist country. Then you COULD be in charge, or you could leave it to advisors.

Raw materials:
You are propably on to something here. I agree.


Furthermore I have thought about the algorithms needed.

And as last year I think that by dividing the econ model into bits it can be much easier to create.

So to create a basic model we need a demand/price part and a supply/production part.

The supply part is a bit tricky to create. But I think the demand part can be done fairly easy, as so:

The model starts with the supply part taking place - things are made, workers are paid and capitalists recieve the profit.

Then the demand part kicks into place - we now have to sell all these goods and use all these money.

Each class has an income, from the supply part. Furthermore the total amount of goods (totalgoods) is known, the total amount of money made by all classes that turn (totalincome) and the amount of people in the class is known.

Now to find the realincome per capita of each class (the amount of goods they can buy - this is needed to find their actual wealth) the following is done:

Realincome = (income * totalgoods) / (totalincome * people) * 1000

This shows the amount of goods that 1000 people in the class can consume. This is used to find out what goods they demand, based on their income. To do this we just need a list of income classes (0-5 goods per 1000 capita (from now on called PU - pop unit), 5-7, 7-9 etc). In modern times the income could be in 1000s of goods per PU. But for now we will just put in the first ones:

If income < 5; demand.food = income

If 5 < income < 7; demand.food = 5
demand.housing = income - 5

If 7 < income < 9; demand.food = income - 2
demand.housing = 2

etc.

Now, this creates a demand for all these goods.

The price is now calculated like so:

price.food = (totalincome * demand.food) / (totalgoods * supply.food)

The demand.food would be the added demand of all the classes.

This, I think, is much more elegant and propably just as good as my previous, clumsy algorithm.

But when I think of it it might not be good enough. I am worried that the price fluctuations will not be large enough. In 1973 the price of raw oil quadrubled. To make this happen with this algorithm the supply will have to shrink to one fourth of what it used to be. Which, in turn, means that the makers will earn just as much money on it no matter what they produce...

This, of cause, is not good. How to make a version that works, however, I am not sure of. But I should learn that soon enough at college.

[Mark_Lipovrovskiy]

That's a couple of things off the top of my head:
1. you are right about nr. 7... that's what i meant, just bad choice of words... you=the computer in that case

Now I think that the demand part should in tree fashion - first they buy the top hierarchy goods, then the second hierarchy if they have money left etc. Each branch will have a fraction, so that all the branches together = 1.
That means, that for example on level 1 you have food, water and clothes - the food will be 4, water will be 4 and clothes will be 2. This will influence the amount of each he buys, and what he'll buy first/more of if he doesen't have enough money.

[The Joker]

Yeah, that is another way to do it. It might very well work better than mine. The only thing I am concerned about is that when people get really wealthy, and buy 1000s of goods such an approach might prove way too slow, when it has to be done lots and lots of times.

But perhabs it can be optimized some way, to make it work fast no matter what.

That is something for us to look into!

[The Joker]

Mark and I had a great chat last night, where he finally convinced me that the hierarchial approach was the way to go. I then modified his suggestion a bit, and the result is what I am presenting here:

Concepts:

Income: Income of the class in money

Total income: Total income of all classes in money

Total goods: The total amount of goods sold for consumers that turn

Realincome: The amount of goods that a class can buy

RealincomeperPU: The amount of goods that one PU (1000 people) of the class can buy

Realincome = (income * totalgoods) / totalincome

Then we have to figure out how much of each good one PU from each class can buy. This means the amount of units of each good that the class can buy per capita. This will be done for each class for all goods:

RealincomeperPU.food = (Income * Totalgoods.food) / (Totalincome * People) * 1000

etc.

Then, starting with the class with the lowest realincome, the hierarchial approach kicks in. Basically there are a certain amount of income levels (not too much more than 20 totally). The model starts from the first:

Level 1: 6 food, 3 housing, 1 clothing.

Then there's made a check with the realincomeperPU.food, realincomeperPU.housing and realincomeperPU.clothing to see if they exceed the corresponding values for these goods in level 1.

If they are not (the class can not afford 6 food, 3 housing and 1 clothing per PU) then the class will not move on to the next level, and they will spend 6 / (6 + 3 + 1) = 60% of their income on food, 30% on housing and 10 % on clothing, and buy the amount they get for that.

If they do exceed these levels then the class will proceed to level 2: 10 food, 8 housing, 2 clothing.

The check is made again. If their income can meet these values then they proceed to level 3. If not then they spend 50 % of their income on food, 40% on housing and 10 % on clothing.

This is done for all the classes one after one, while storing the amount of money each class spends on each good.

Finally the amount of money spent by all classes on each good is added together, and the price on the good is found:

Price.food = (money spent on food) / supply.food.

etc.

This, I believe, would not only make a better demand function, it would also make the price mechanism much better.

Now comment!

[The Joker]

I think I will make a more thorough presentation of my model. Currently Mark is using another approach, but unfortunately I am still not sure that I understand how it will work, and from what I do understand I think that my version is more efficient.

So right now I feel I have little other choise than to proceed with my model. I hope that you, Mark, will do the same, so we can compare them and reach an agreement (which will not be hard, I assure you) soon.

I will be back.