Page 1 of 1

Randomized production requirements instead of expensive setting

Posted: Tue May 02, 2017 1:08 pm
by Lav
Introduction of "expensive" recipes livened up the game somewhat, but as far as I can tell, players will eventually develop two optimized sets of production chains, and that's all to it.

So the suggestion is: instead of making recipes merely "expensive", make their price randomized within a certain range.

Using circuits as an example:

Code: Select all

  base_cost:
    iron = 1
    cable = 3
  difficulty_rate:
    iron = 2
    cable = 7
What this means is that base cost for a circuit is 1 iron and 3 cable (i.e. standard). An increase of recipe difficulty by 100% will inflate those costs by 2 iron and 7 cable on average, but actual increase for each individual game will be additionally randomized by +/- 50%. I.e. actual costs will be:

iron = base_cost.iron + difficulty_setting * difficulty_rate.iron * random(0.5, 1.5)
cable = base_cost.cable + difficulty_setting * difficulty_rate.cable * random(0.5, 1.5)

This allows setting recipe difficulty with a slider and makes all recipes unique for each game, forcing players to improvise and adapt.

Re: Randomized production requirements instead of expensive setting

Posted: Fri May 05, 2017 2:48 am
by AileTheAlien
I think if you're going to have randomization, you'd want to have it be more than just once per game, otherwise you'd only have to optimize / do some math once in that game. To keep the player improvizing throughout the game, you'd need some way of varying the recipes throughout the game. Perhaps regions of the map that have penalties or bonuses to certain recipes? Or a game entity like a beacon, where it's got a small radius of effect, except that effect is a bonus or penalty to recipe costs. (And that entity would be scattered around the map, just like everything else in the game.)

Re: Randomized production requirements instead of expensive setting

Posted: Fri May 05, 2017 5:08 am
by Lav
Varying regional complexity is a nice addition, but then making it variable in time would be even better.

Of course, that variability should occur at a specific underlying system, which the player would eventually be able to detect and adapt to, and then even exploit to his advantage, shifting production between different sections of his base depending on current local complexity levels.

Heh. Who will raise the bar further? :-)