ske wrote:The alternate recipies are optimal depending on the resource availability. E.g. in a level with lots of iron you would go a different route than you would in a level that is lacking iron.
I concede the point - when there is sufficient pressure on a resource (despite them technically being infinite -- i.e. some factor such as time, distance, biters, etc. makes acquiring more of the resource difficult, at least in the short term), then even just having fixed alternate recipes which favor different resources will result in the player having to think. However, that thinking is then just between "blueprint A" and "blueprint B" (or maybe "blueprint C") to suit the condition.
skey wrote:Having a set of recipes that randomly change will result in much more variation
Yes, and I think there's some critical point where there is sufficient variation that just picking the best blueprint from some set (rather than doing actual design) becomes suboptimal/infeasible enough that players would choose to actually do design. The game should support at least that much variation.
I was thinking about how this should work, and it's important to recognize that while variation is good, people also like familiarity - they like to take their knowledge from previous plays and apply it, and that would remain true even if some things were different so they had to do at least some new builds if they wanted to be anywhere near optimal. So it occurred to me there could be a "randomness setting" that goes from 0 to 1. At 0 you get vanilla as it exists now. At 1 everything is randomized (chaos!). Somewhere around 0.05 though, you get a game that has most of vanilla's existing recipes (and vanilla's existing ranges/speeds/resistances/etc.), but a few crucial things have changed (to some random input ingredient, to some random ingredient amount, etc). Those changed values could even be highlighted in the research and crafting UIs in some other color so it's easy for veterans of the game to see what the differences are this game. (There could also be a new summary screen which just lists all the differences for the current game.) As an example, just think what happens to all of your "mega factory" builds if just one critical setting changes, such as beacon range. It would only take 3 or so such major random tweaks (selected from a much larger pool of possible tweaks) to make each game involve significantly unique builds and at the same time let the player reuse most of their existing Factorio knowledge (and not feel nearly as lost as someone playing Bob's or Yuki's mods for the first time). Add in a few minor tweaks as well for flavor, and I think the experience would be a good one.
TheRaph wrote:The easiest way to solve this is to get an option to disable all global blueprints for an specific competitive session.
Your solution only changes it from "use premade blueprints" to "use memorized builds". It still does not require any actual thinking during the game. Furthermore, it does nothing to address the greater problem of the game being highly repetitive which includes single player. (Sadly, I often find
myself using the "use memorized builds" method, because there's simply no in-game reason to make a new build. So far I haven't really built up a blueprint library, probably in part because doing so would be admitting that Factorio will never be fixed and will always be repetitive.)
TheRaph wrote:The suggestion to have different recipes every time a game starts, effects booth - single player and multi player.
Yes, and that is the point. I don't care if PvP gets fixed - it doesn't affect me. I would really like to see single player fixed though, and single player suffers from the same repetitiveness as you are complaining about in PvP. (Though now I see that apparently you're not at all bothered by the repetitiveness and you just want people to memorize builds, and only for PvP which you don't even play.)
TheRaph wrote:You cannot train yourself how to setup things, but they alter to much in every game.
Yes, and that is the point. I don't want to just use memorized builds (or watch others use memorized builds). I want to have good in-game reasons for designing new builds. It need not affect every single build in the game (see my idea above for a randomness slider and where I suspect the sweet spot is), but it should significantly affect a number of builds so I have something new to do in every game.
TheRaph wrote:What about to have different recipes / ratios / efficiencies depending on what BIOME you're building in.
While I find those ideas to be interesting (and also ske's take on the biome idea), they don't really address the issue at hand. (I.e. they can be solved using multiple blueprints. Furthermore players will tend to locate each build in "prime biome" for the given item being produced in the mid to late game.)
Also note that there's a bit of a problem here (and with my earlier idea of making landfill and cliff explosives prohibitively expensive), and that is it gets in the way of scaling your factory in size via automated construction. I'm facing this issue now in my current play through - I've been going solar (no nuclear) with massive beaconing (large power requirements), and I would really like to have a nice automated system for sending trains full of materials to the solar area and having robots take those materials and expand not only the solar itself but all of the solar-creation infrastructure (tracks, stations, unloading, roboports, etc.). But those damn cliffs! I have to go out there and get rid of cliffs by hand before any of that can work, which means I can't scale the whole problem up with automation because there is a required manual step. Having builds change every time they hit a biome boundary would present similar issues. (Actually, solar is probably not an ideal example of the problem because in many cases cliffs won't matter much - most the time it just means some solar panels or accumulators don't get placed. But when it gets in the way of trains or robotports it causes major problems.)
TheRaph wrote:The whole benefit from that is, a player can learn and practice to have the best setup for every biome
Ugh, no. You're almost explicitly saying everyone should just memorize the best builds and then use them like mindless zombies. That's boring. I want to 1) come up with
totally new (for me anyways) builds that are optimal for the given game, and then 2) scale those solutions up via automated construction. And the next game I want to do it all over again. The only way I can do #1 is if what is "optimal for the given game" changes significantly from game to game.
TheRaph wrote:(And large array blueprints may not fit in strange shaped biomes
)
Right, which like I said above, means it breaks scaling up your factory via automated construction.
(And like I said, I'm of two minds on that - it does increase thinking not in terms of the builds themselves but in terms of logistics, but breaking automated construction is a big price to pay for that. Frankly, Factorio's logistics story is not good - the relative scale between train stations and resources/builds tends to be very bad and completely unrealistic. In the real world it would be like having simple train stations that are 100 square miles in size. And that makes having these types of logistics issues inserted into the game less fun than they could otherwise be. Plus, your original complaint, and my generalization of it, was about the builds themselves - logistics is a whole different topic.)
TheRaph wrote:But to get most effective base, a player need to know in which biomes hecan produce which thing (and not only which setup is the best for a given biome) - and that knowledge you can't store in blueprints.
Again, you are talking about memorization and recall as if that is compelling gameplay. It's not.
Furthermore, you're simply mistaken about "that knowledge you can't store in blueprints" - you can most certainly store that knowledge in blueprints and blueprint books via a simple naming/organization convention.
TheRaph wrote:why not put in two new options - "no blueprint library" and "radom reciepies"
Because the "no blueprint library" option already exists? Any player can choose to not have or not use a blueprint library for a given game. (And PvP games can have house rules - I'm not a follower of such games but surely there have been PvP games where they have house rules like "no solar", "no lasers", "no logi bots", etc.? Single players do such things all the time, as I have - it's one of the few ways to get real variation in vanilla.)