Capitalism Lab Post-Release Beta V7.0.03 full version installer now available

[David]

So if I understand it correctly, all the importer does is import but doesnt turn a profit?

I was able to make a profit with imports in by setting the Import Quality option to High. Are you using v7.0.03?

[cantdownloadit]

i think he was referring to the fact you cant change the pricing at the importer itself, so the import building always makes a loss.

[saffgee]

Haven't tried the new import office yet, but I certainly will. It does seem like it would be useful for my mod with all its complex chains, so thanks David !

I'm wondering though what criteria you have set for the AI to make use of such a feature ? I assume there has to be a logic currently for the AI to decide to build its own products instead of to sell someone else's, but I feel as though the categorisation of company type is still a bit broad to really make this shine. We have media, bank or insurance focussed companies, retail and internet focussed ones, etc, but in my mind we don't seem to differentiate well between the rest of them (which is frankly most of them).
With the introduction of the import office I'd take things a step further and tweak the AI behaviour based on some additional criteria:
- Add the company type "OEM"; this company does not invest in retail capability but specifically focusses on business to business sales by making products and inputs; the result would be both a prime user for sourcing required inputs using the import office, but also as an effective competition to the import office itself, making for a better game.
- Add restrictors to the import office to not allow certain goods types during game setup; eg. any retail goods, individual product groups, etc; I feel this would allow for greater steering of the impact of the office on each game and makes it more useful for creating interesting scenarios

Please bear with me if I'm made some bad assumptions above, as I haven't actually tested it myself yet....I will soon.

[rafaeltodero]

Haven't tried the new import office yet, but I certainly will. It does seem like it would be useful for my mod with all its complex chains, so thanks David !

I'm wondering though what criteria you have set for the AI to make use of such a feature ? I assume there has to be a logic currently for the AI to decide to build its own products instead of to sell someone else's, but I feel as though the categorisation of company type is still a bit broad to really make this shine. We have media, bank or insurance focussed companies, retail and internet focussed ones, etc, but in my mind we don't seem to differentiate well between the rest of them (which is frankly most of them).
With the introduction of the import office I'd take things a step further and tweak the AI behaviour based on some additional criteria:
- Add the company type "OEM"; this company does not invest in retail capability but specifically focusses on business to business sales by making products and inputs; the result would be both a prime user for sourcing required inputs using the import office, but also as an effective competition to the import office itself, making for a better game.
- Add restrictors to the import office to not allow certain goods types during game setup; eg. any retail goods, individual product groups, etc; I feel this would allow for greater steering of the impact of the office on each game and makes it more useful for creating interesting scenarios

Please bear with me if I'm made some bad assumptions above, as I haven't actually tested it myself yet....I will soon.

I really like your idea of ​​having a company focused specifically on products and inputs. At the same time, if there was a way to create contracts, where I contract an OEM company X quantity of product for a certain period. That would be really interesting, it would give a really cool dynamic.

[David]

- Add restrictors to the import office to not allow certain goods types during game setup; eg. any retail goods, individual product groups, etc; I feel this would allow for greater steering of the impact of the office on each game and makes it more useful for creating interesting scenarios

These are good ideas. Currently there is an option for restricting imports to semi products only. You may give it a try and see how it impacts the game.

[saffgee]

- Add restrictors to the import office to not allow certain goods types during game setup; eg. any retail goods, individual product groups, etc; I feel this would allow for greater steering of the impact of the office on each game and makes it more useful for creating interesting scenarios

These are good ideas. Currently there is an option for restricting imports to semi products only. You may give it a try and see how it impacts the game.

Then test it I shall - thanks David.

[saffgee]

David, can I make a suggestion that could get us closer to having a commodity market.

Using the logic of the import office, you could introduce a commodity exchange/marketplace, where the price that the good is offered at will fluctuate over time.
- To keep it fairly simple and reduce micro management, I would suggest a monthly cycle of price changes.
- This would allow for the player to "speculate" on the commodity market by buying when it is priced low, storing it in a warehouse and then selling it again when prices go up.
- To reduce randomness, I would say the monthly spread change should be between -40% to +40%; perhaps this sensitivity could be controlled by a slider for the player to decide how extreme he wants these movement to be
- The AI should be able to cope easily with this game addition as its in his nature to look for a cheaper alternative to his current pricing; it may not speculate on prices, but it would use them as needed
- The mechanic would allow for all commodities to be available at the beginning of the game and makes for a better game (and business) dynamic of finding a cheaper alternative by mining yourself as prices go up

Thoughts on how viable this may be to get coded, given that the import office is now in game ?

[David]

David, can I make a suggestion that could get us closer to having a commodity market.

Using the logic of the import office, you could introduce a commodity exchange/marketplace, where the price that the good is offered at will fluctuate over time.
- To keep it fairly simple and reduce micro management, I would suggest a monthly cycle of price changes.
- This would allow for the player to "speculate" on the commodity market by buying when it is priced low, storing it in a warehouse and then selling it again when prices go up.
- To reduce randomness, I would say the monthly spread change should be between -40% to +40%; perhaps this sensitivity could be controlled by a slider for the player to decide how extreme he wants these movement to be
- The AI should be able to cope easily with this game addition as its in his nature to look for a cheaper alternative to his current pricing; it may not speculate on prices, but it would use them as needed
- The mechanic would allow for all commodities to be available at the beginning of the game and makes for a better game (and business) dynamic of finding a cheaper alternative by mining yourself as prices go up

Thoughts on how viable this may be to get coded, given that the import office is now in game ?

Hi Simon, I would recommend that you create a new thread with a poll containing the above suggestions in the Suggestions or New DLC Suggestions forum.

[saffgee]

No offense but I think we have polled enough on whether players would like to have a commodity market or not. The answer to that is clearly "yes", from a great many recent polls.

I was only suggesting a simplified route of getting there based on largely existing coding, which I hope would ultimately make it easier to implement.

[David]

No offense but I think we have polled enough on whether players would like to have a commodity market or not. The answer to that is clearly "yes", from a great many recent polls.

I was only suggesting a simplified route of getting there based on largely existing coding, which I hope would ultimately make it easier to implement.

Ok. Noted.