Friday Facts #224 - Bots versus belts

[Progman]

I will remind my idea about ropeway conveyors:
viewtopic.php?f=6&t=7977
[...]
This system could replace the logistic robots. The ropeway wagons loaded with the cargo (stored inside like in the chests) would be just moving along the line, and they will be able to unload by the long inserters. Basically the conveyor belt with the chests that interact with the ground in the minimal way.
[...]
Just the logistic bots are moving along the predefined line. It would be also perfectly fit the Factorio style.

Based on this comment by Cordylus I thought about nerfing the bots in the following way:

A provider chest can send the content to players as usual. But when a provider chest sends items to a different chest it can only send the items to an assigned chest configured in the provider chest (or other non-request chests). This way the provider chest does not simply distribute all the items to all available requester chest but instead only to one configured chest as the defined transfer "exit" node. This way you specify how the items are transfered instead of letting the "logistic network manager" control which item is send from which chest to which chest. You can keep all the research options and functionally as they are:

• Make them faster by research
• Let them take more by research
• Fly directly to the target (-> fly over structures/water)
• No collision (of bots)
• No loading/unloading time (-> instant pickup/drop)

But with this suggestion you remove the ability of "automatic distribution" of items to all requester chest. You are essentially building a transport network or transport routes/corridors. You build a transport graph on how the items are transported via logistic bots. You can even build a chain of transport routes.

Code: Select all

(P1) --->---\
             \
(P2) --->----(B1) ---> (R1)
             /
(P3) --->---/

In this example the provider chests P1 to P3 are configured to send their content to the buffered chest B1 when this chest request items. Since B1 can provide items themself you can configure it to send items to the requester chest R1. So when R1 is requesting item, it gets it from B1 and as B1 now requests items it gets them from P1 to P3. You get the challenge of building transport paths/graphs, just like for belts and trains, but you keep the advantages of fast, direct, collision-free (and UPS friendly?) transportation.

To summaries the changes:

• Chests which can provide items (provider, active, buffer (and maybe storage) chest) can be assigned a "target" chest, which can request items (requester and buffer chests).
• Chests still can provider players unrestricted.
• Chests can assign to only one "target" chest.
• (Requester) chests can still be provided by several provider chests
• (Requester) chests only get items from (provider) chests which are "assigned" to them.

[TiMatic]

- In real life throughput is increased by using crates/boxes/pallets. Maybe something like packing/unpacking machines can be introduced to "Pack" items into boxes and move those with belts. Packers will take empty boxes and the items and put it in "full boxes" and unpacker will do the reverse.

I think that's a very good and easy solution for the throughput limits of belts in mega bases, because boxes are scalable by research like the stack size or transport capacity of bots. So it may be a better solution than a green belt.
This mechanics is already used by other games, for example the Packer in Big Pharma. http://bigpharma.gamepedia.com/Packer
In Factorio it would be a simple factory that consumes a chest and some items and produces a bundle of this items, for example a circuit package. So we need only a new pack/unpack recipe for some intermediate products, to get belts usefull in very late game.
Additionaly, the bots should not be able to transport item packages, so it becomes a belt feature.

[GenBOOM]

the point is, if you are going to change robots you need to add something new to the game to fill the gap

there are those that do not have time to do everything themselves and want to play single player so bots are necessary and convenient

-add ropeway conveyors for medium sized bulk orders for medium distances (the ability to be used over an existing belt design is great)
-add pneumatic tubes for low volume but quick delivery over longer distances
-change it so that when a player placed something on a blueprint it saves data and wires just like when using robots
(these three means you can still build with blueprints quite easily without robots during mid game)

-make belts that can be upgraded easily throughout the game that go beyond the current speed limits
-change beacons so that they have a slightly bigger footprint, bigger range and also effect belt speed? and therefore the initial setup for bots would be an undesired expense in order to compete during mid game?
-move robo tech farther back for late game solution at purple/yellow science

this way you will have to use each type of tech to really setup a megabase

[TiMatic]

think about the devs they have to read all the double post...

Or they just ignore it. So far there is little discussion here. Mostly just people stating their opinion for or against and rehashing arguments made many times before.
Data mining this is going to be a headache.

I am not sure you are getting the point of this thread, which is to discuss what you do or do not like about this thought. In the original blog, the very last line is, literally "As always, let us know what you think on our forum." The devs WANT people to discuss this. If one person suggests something, and nobody else agrees or disagrees with that person on the grounds that the topic has already been discussed, then the devs don't know how important this is, and how many people want it. Maybe it's just one person who feels this way? If 100 people agree or disagree strongly, then the devs can say "Ok, this is important to many players".

Rylant

I think thats a problem of the forum features. Beacause there is no "agree"/"disagree" button, every user has to write a new post to say if he agrees or disagrees with a previous post. To simplify that we need a voting for the different suggestions.

[Stlyau]

It's like a car with a manual and an automatic mode (manual = belt, automatic = bots)
Maybe it is/can be more fun to drive manually, but maybe you just want to reach your goal in an easy way and focus on other stuff.

Focus on other stuff??? For example, a person's cellphone to check Facebook, Twitter, or every other media source instead of just focusing on the task at hand.... DRIVING!!! However, the difference between manual and automatic transmission is just how the gears are shifted up to posted limit. Most automobiles don't have more than 5 gears, thus making it a minor time difference. Belts having no upgrade research compared to Bots having infinite speed research is more like walking vs. jet engine.

[_Peter_]

I think bots are overpowered because they ignore space restrictions and make space a non-issue (for all other things, not only belts, planning for space is the main issue in Factorio).

If bots would occupy airspace and wait if space in front of them is not empty, then

• using bots for rare transports or for quick bugfixes would be without any change to the current situation.
• using bots for mass transportation would be possible if transport airways are organized properly by putting provider/requester locations appropriately so that flight paths do not cross.

Maybe additional airspace layers could be unlocked with research so that a bot will wait if it would overlap with 2 other bots, but it can fly through a single other bot.

To prevent deadlocks, it might be necessary to specify from which side bots should approach a chest and into which side they should depart.

[Mobius1]

To summaries the changes:

• Chests which can provide items (provider, active, buffer (and maybe storage) chest) can be assigned a "target" chest, which can request items (requester and buffer chests).
• Chests still can provider players unrestricted.
• Chests can assign to only one "target" chest.
• (Requester) chests can still be provided by several provider chests
• (Requester) chests only get items from (provider) chests which are "assigned" to them.

Basically you saying that any chest can only provide to only 1 chest, so you're literally nerfing the throughput of your entire factory to 1/3 of a belt. When you begin the phase of logistic bot building, you're essentially improving the productivity of your factory without going crazy on space usage, preserving FPS and UPS, but when you limit the chests like that, you're basically killing your factory UPS and FPS by forcing players to build belt-based factories, which are poorly productive and are huge in size but instead, you're not buffing the belt to be equivalent in effectiveness.

Belt - Bot comparison can be done as Intel 8080 = Belt factory, Intel Celeron = Bot Factory. Faster, smaller, more productive.

Just a quick way to prove my point: Do a 1 rocket per second factory. That level of productivity can be achieved with belts? is it playable?

[TiMatic]

I think bots are overpowered because they ignore space restrictions and make space a non-issue (for all other things, not only belts, planning for space is the main issue in Factorio).

I wholly agree with that.

[Squingy]

Of all the posts I've read regarding potential bot changes that to me make sense and would at the same time bring bots more in line with belts in planning, would be to keep them restricted from entering the same space. The idea that 1000 logistic bots can currently occupy exactly the location and entity simultaneously is the most disfunctional aspect of the mechanic of the logistic system IMHO. Maybe also only the adjacent tiles to an entity can at any one time interact with it?

[Progman]

To summaries the changes:

• Chests which can provide items (provider, active, buffer (and maybe storage) chest) can be assigned a "target" chest, which can request items (requester and buffer chests).
• Chests still can provider players unrestricted.
• Chests can assign to only one "target" chest.
• (Requester) chests can still be provided by several provider chests
• (Requester) chests only get items from (provider) chests which are "assigned" to them.

Basically you saying that any chest can only provide to only 1 chest, so you're literally nerfing the throughput of your entire factory to 1/3 of a belt.
[...]

How does this change reduce the throughput to 1/3 of a belt? You can place several provider chest for the same item and link them to one target chest. This way you build a 1-to-1 or N-to-1 connection between chests to control and manage the flow of items in the logistics network. But when you have N-to-N transfer (like the current logistics network) you don't control/manage anything, instead you just pumping items in the logistics network and let handle the "logistics network manager" the distribution of all provide/request orders in the net, which is very powerful to the point where it is OP.
You still can build bot based mega bases, but you have to plan now a route where the items go instead of "just add it to the network", which make them less OP/powerful.

[Ryba666]

Dont nerf bots, for new players creating a balanced bot production is quite difficult so bot is reward for good planning.

Good idea is give us early one use bots

[Alice3173]

It is not that black and white. The designers have a role to play in creating a well thought out, balanced and consistent game design. Putting in every feature imaginable and letting users pick which one to use and which to ignore is a bad way to go about that. If you were to install all available mods then the resulting game would be pretty bad, even when the majority of the mods by themselves add to the game.

Sometimes you need to stop, take a look back and ask yourself "does this still make sense?", "does the feature tie in well in the overall game design?". I do not think bots should go and according to twinsen in the FFF they are not going anywhere either.

The easy solution, as people have pointed out, is to make belts more viable rather than nerfing logistics bots. Especially if they nerf them into near-uselessness like they did barrels. Rather than defaulting to nerfing things the devs should consider whether the better item should be nerfed or if everything in its class should be boosted instead. In general, in a singleplayer game at least, defaulting to buffing the others should be the default position unless they examine that option and come to the conclusion that it'd legitimately be better to nerf one thing instead.

In this case, bots themselves aren't the issue. As people have repeatedly stated, logistics networks eat up a ton of power and quite a bit of resources as well and they're lategame only on top of that. The obvious consideration here would be that the primary alternative, belts, aren't viable in comparison. The belts only upgrade 13.33->26.66->40 items/sec with is very linear and doesn't scale well when your factory will grow more or less exponentially. On top of that belts can actually be fairly expensive. One a one-by-one basis they seem cheap but that very quickly adds up with how many belts you can very quickly eat through when building an assembly line. The best choice would be to either make each level of belt a bit cheaper or increase the number of belts crafted at once while keeping the cost the same. On top of that, expanding belts to either be faster for each upgrade or adding in a few extra levels would also help. (I'd personally go for two additional levels at 60 and 80 items per second or or buff the first three tiers to 15/level which would result in 15->30->45 then 60->75 if you still add two additional levels.)

[Ryba666]

Or add speed boost tech for belts like it speed boost for bots.

[DeathMers]

Remove logibots?? Wtf... Sure they seem cheaty and they take fun from belt contraptions, but in first place, they make things easy even when it looks ugly (same as drugs), but i really believe that factorio players are mature enough, so they can decide for themselves, whether use them or not.

Removing content from game is always step back, removing logibots from game is fucking with core player base (not new players) , that are used to logibots. You can see in this fff reactions, what storm this can create. You cannot force this, but you can do better - make achievements like:

-launch rocket without logibot
-launch 10 rockets without logibots
-launch 100....

[Chasseur-]

Nerfing bots stack size its nerf only for early stage of a game. When you have kinda big base (1k+ spm) you can build hundreds of thousands of them, so any throughput can be achieved. This nerf only means that you need 2x bots amount. So, I hope that instead of limiting bots cargo by 2, you add infinite research for it that will scale like speed research, so you will need insane amout of resources to research it after few levels. It will reduce amount of bots in megabases and increase game performance that is important for people like me with not high-end pc.

[Zavian]

Reading another dozen of pages here are some more comments from me.

So the main problem with bots is their iteraction with chests. They have just unlimited throughput. So something should be done to nerf this particular side of them. Limiting chest iteraction to make queues like roboport charging pads have is a nice thing to think about.

I disagree there. I think the main problem is that they are just so much simpler to design than an equivalent high throughput belt build, that people use bots rather than struggle attempting to build a high throughput belt system, especially if that want an 8x8 beaconed setup. That is especially so when you try to route belts for high throughput assemblers (eg green circuits) between long rows of beacons for an 8x8 beasconed setup. (For what is its worth, you only need 3 copper wire assemblers and 3 green circuit assemblers to make 43 green circuits/sec in an 8x8 beaconed setup (assuming you can feed and extract that fast). 6 machines is kind of short for an attractive 8x8 build).

Belts are not scalable as they have exactly fixed parameters and throughput. Bots are just like magic wand. You need to limit them somehow to strict throughput to force players scale up builds respectively.

Belts do iteract with stuff via inserters which are hard limit for throughput. Bots can go and just swarm a chest and instansly transfer its contents somewhere.

If you just limit chest throughput then people will just add more chests. There is room for 6 chests in an 8x8 beaconed setup. If you want 12 beacons per assembler then you can have 12 chests. (I saw someone just this week who said he wanted to use 12 beacons per assembler for copper wire, because he wanted that +540%). So limiting chest throughput probably won't achieve much, unless you really nerf it. Much better to try to find a way to make belts more attractive.

I do find boxing (palletizing, stacking whatever, similar to barreling) being the best solution to increase belt throughput dramatically. Not magically but through a special device (even if assembler).

I've been thinking maybe a new belt. Maybe only one lane, maybe two lanes, with slots maybe every 20 belt units (where one belt unit is the distance a yellow belt moves in one tick) rather than the 9 for normal belts at maybe red belt move speed (2 belt units/tick), that can accept items one "stack" at a time. Where "stack" could be either either anything up to a full stack of items (so 100 for iron plates), or the max a stack inserter can take. Stack inserters can put down or pick up as though it were a chest. At red belt speed, with only one lane, and with stacks limited to 12 items, you get 72 items per sec. Additionally being a new belt it could only accept items at the predefined spacing, and hence never get the problem that there are gaps inserters can't insert into. (Perhaps the graphics could add little trays or shallow boxes to make this clear).

If you instead used items stack sizes, then that would be 600 items/sec which is perhaps too much. If stacks were 100, then the last stack inserter would get only 4 items at a time, and would need to wait 6 ticks before the next stack was ready. For these reason I think stack size, as defined by max(item_stack_size, stack_inserter_capacity) is perhaps better. If the developers want more throughput, you could add more stack inserter capacity researches to increase belt throughput. You could also use blue belt speed or even faster, use two lane belts, and maybe smaller gaps between stacks.

If miners and normal inserters are allowed to pickup/dropoff, then a two lane version of this design could even upgrade existing belts. (2 lane design with items every 20 belt units, running at blue belt speed, would be 216 items per sec which should be enough for 15 copper wire assemblers, and 15 green circuit assemblers in an 8x8 setup. (This would also assume that you could somehow belt weave the necessary belts. We might want this new belt in different colours. Alternatively you could just use different lanes, one lane of copper would be enough for 9 copper wire assemblers, which is still much better than we can get now).

@Twinsen: I'm not sure what you meant by "stacked belt". Is this close ?

[Vandroiy]

Whoa! I'm late to the party, eh? I hope a dev still reads this.

Yes, bots are overpowered compared to belts. Yes, some recipes are pointlessly complex and do not add to the game. But yes, removing the logistics network would be overkill.

I'm not sure whether the alternate world without logistic bots would be better, because the core issue isn't the "logobots," but the game design not consistently aiming for the kinds of balance and dynamics that favor meaningful, strategic choices over repetitive details. IMO, if you understand what has gone wrong, you can make fixes that change things in the right direction (*cough* *cough* unlike the massive increase in science recipes).

1. First, consider the following list of roughly related facts

• There is an intuitive trade-off between bots and belts: flexibility versus throughput.
• Factorio might be the most optimized game I ever played, yet spams so insanely many objects that it still runs into performance issues.
• In real life, conveyor belts are THE high-throughput solution. NO ONE challenges them in throughput. Think Bagger 288. Making them low-throughput is extremely counter-intuitive, which also makes it hard to think about the game design in a sane way.
• Bots are always better for excessively tedious moving of many small amounts of things. There is nothing wrong with that.
• Real factories have workers, which can locally move things flexibly at low throughput. Bots currently fit that role and have no real alternative.
• Factorio has lots of recipes that add more complexity without adding new gameplay.
• Speedrun times have jumped up with 0.15. But did watching them become more interesting?
• The fact that a really high speed of a belts still technically caps throughput is the weirdest thing. Belts get high throughput by stacking bulk items into them; while a fun feature, the very first option shouldn't be to put the engine on overdrive.
• Similarly, using stack inserters to offload bulks of coal or ore from a train is weird. (But using flying robots is certainly weirder!)
• Good players are often limited by input speed or game performance instead of better strategy or build order.

See where I'm going? The game needs trimming down on "hard to learn, easy to master" complexity and instead add mechanics that involve meaningful investment decisions and the ability to move large chunks of material on the ground. Which brings us to:

2. Thoughts on design direction

• Generally, try to reduce object count to allow belt mechanics to handle bulk loads and to give some air in the escalating performance fight.
• Differentiate between short-range sorting or packaging of objects, which should be doable at least as well as with bots now, and longer-range supplying of assemblers with bulk loads, which should be really hard to do with flying robots.
• Give ways to make large investments to handle bulk resources.
• Move complexity to the combination of features. Move it away from having lots of different objects that all have to be built in similar ways.
• Create variety by allowing multiple solutions with different trade-offs. The power system and military do a good job at this, but the mining, smelting, and science not at all. Logistics is in between, but could absolutely be on the good side.

The bottom line here is: don't forget that construction games are related to strategy games and have similar needs. Strategy is not tactics, nor is it wiring a gazillion belts to solve the same problem again and again, with marginally different inputs. If the choice is either broken balance via bots or having players ragequit over having spaghetti forced on them, neither decision is a great choice. A better way is a strategic solution, with player investment beyond clicking time and a real choice between flexibility or raw power.

3. Concrete changes to consider

Here are things I'd try if I were suddenly turned into a Factorio game design dev:

• Add bulk objects for ores and plates that are denser on belts but cannot be flown by robots. This is the biggest code change: all consumers can use these as input, and as players tech up, buildings gain the ability to output them.
• Reduce item counts elsewhere too! It doesn't feel so different to move 5k instead of 10k of something over belts, but the higher numbers max out the belt mechanics, and thereby also game performance and design options for factories and train stations. Much of the granularity is only needed in the first few minutes of the game and messes with the entire rest! Bot carry capacity should be reduced accordingly.
• Slow down yellow and red belts a little, but not as much as object reduction, so they're effectively much more powerful starting with reds or the appearance of bulk items. Think 1:2:4 speed. If express stays at current speed, upgrading to them will be a huge step.
• Power up early-game smelters a little, so that smelting rows per belt get no longer than now. Increase their resource cost and crafting time to shift difficulty from placing countless smelters to automating their construction early. (But don't make their recipes more complex!)
• Remove production science and require large amounts of other science instead.
• Generally, remove items or recipes that excessively do more of the same. (For example, the redundancy between the g, r, b circuits, speed modules 1, rocket control units and high-tech science is absurd. Same for solid and rocket fuel, once you consider all the oils and that coal and wood and nuclear fuel are also used as train fuel. If it's generic enough to be burnt anywhere, keep it generic and kick the rocket fuel already!)
• To make up for some of the difficulty reduction from simpler recipes, increase costs for science and buildings. (But I'd aim for sub-2h speedrun times at reasonable settings; 0.14 was on the higher end IMO. The current situation is for no-lifers really.)
• Add large, expensive, late-game variants of mines and smelters that work on bulk items for suitable in- and outputs. (Maybe even a bulk assembler, for a little reduction in the repeating structures in late-game factories.)
• Remove the filter inserter types and just give the ability to fast, long, and stack inserters once researched.
• Enable the loader/unloader mechanics as a late-game research, but make them wide instead of long and have them automatically use bulk items and balance their outputs both within and between belts.
• Add a larger chest type, which has even size along at least one edge and allows filtering, and can be placed freely, not on rail grid, to give an alternative to bots when sorting or moving loads between trains. (And maybe nerf the smaller chests... I mean, they're crazy compact, which is good on bots' flight times. If you have the dev time, make the larger chest a bulk storage that has increased capacity for bulk items and is again off-limits for bots. Belts get access to some serious storage then, while pure bot-bases get pushed below current midgame amounts. As a neat side effect, storage bases to mine/smelt into become a more feasible concept.)
• Remove flying robot frames, they're again one of these complexity spam items. Make bots more expensive instead, so that their production too should consider belts.
• Finally, if still needed, nerf logistic bot recharge capacity per area (e.g. reduce roboport recharge rate).

Before the last point, bots have been implicitly nerfed a lot already, because belts are much stronger in the late-game and the the powerful bulk items are off-limits to bots.

Late-game belt factories look very different after these changes. Unlike now, not only can you beat a bot train-station in throughput, the belt version is much more beautiful, powerful, and rewarding. The effective belt throughput increase allows long, multi-platform train stations that tunnel goods through the next platform and move items between trains, while staying at massive performance in every sense of the word. Bots can still do a fairly powerful base for these purposes, and it is easier to plan and build, so they remain a viable choice to beat the game, but not overpowered: powergamers will do many things without bots for throughput, and newbies are already used to belts when bots appear, so together with the reduced recipe complexity, the learning curve to win with each strategy seems similar enough.

Powergamers might opt for bots in certain phases of the game, where they have the tech but aren't yet at full throughput, to rush things and scale them later. This is strategy! Rather than trying to "balance" it away, how about making the research tree reflect it? Just like with military science, have distinct research directions: pay lots of simpler science for bulk tech, or rush a smaller amount of complex science for high tech. Unlike the current "production science," re-ordering priorities would lead to different tech progression for belters and botters, adding some real variety.


I wonder if anyone's gonna go through this whole post and have an opinion, or if I just kinda wasted a few hours.

[Molay]

I would hate to see the nerfbat being used as a way to guide players towards what you find the desired way to play the game.
I'd much rather you focussed on offering alternative solutions that are as fun and fill a similar role as the bots do: that is, reward the player by reducing some micromanagement late game, to allow for the player to think bigger and go faster.
I do not have a solution for you, sadly. But I know for a fact that nerfing bots just would make me angry and I would not feel happy about being pushed into not using them. I've come to love them, and stripping them of their usefulness would be quite hurtful and "mean".
Now I wouldn't mind if they costed more energy or whatever, as that is not a nerf to their capabilities, but merely a nerf to "at what point they become really viable". If you decide to make energy cost so high that it takes an extra 6 hours of mindlessly plopping down solar panels to make them worth it, then so be it. But at that point, why not remove solar panels as well, as they sidestep the use of all the things that make factorio, factorio: using belts to transport ressources (coal) and consuming them. Clearly they are must be just as abhorrent, but they are as much an integral part of the game as bots are. And it is definitely too late to take the toys away from us without causing serious backlash. When you scrapped the plans for space platforms, at least it was done before we actually played with it and grew to love them; it hurt, but it was what it was. Bots? Bots are here already, they live, they breathe, they have little bot families and bot jobs and they deserve a right to existence!

Seriously though, don't remove them or I'll be very very sad.

[Froilen]

make belt base speed faster . and easy to scale

like make the yellow belt pass 14 or 16 items per second from the not so optimal 13.666 .

[SiC]

I think this is probably thinking too much into the 'problem'.

I've got over 200 hours of play in Factorio now but would consider myself a casual player. I don't tend to crunch the numbers, and seeing some of the bases and factories other people come up with is quite frankly just intimidating sometimes.
Hell, I'm still having trouble figuring out train signals, and only the game before this one did me and my friend figure out the potential uses of bots, or to build a factory that was designed well enough to produce enough of everything to automate almost everything.

The nice thing about the bots that some people might consider 'cheaty' is the requester chests and the like, but honestly, for more casual players these are a wonderful option in the late game, when your factory is probably quite dense and it's next to impossible to reroute things in a good way to make it all work without tearing everything down and building it up again. And honestly, if you want to talk about tedium, that to me is it. I want to build things, and if I mess up and things stop working out, I learn from my mistakes and generally try again on a new map where I'll run into new problems, and so on. But the requester chests allowed us to keep going a while longer and figuring out new solutions and new systems to set up. It was both something entirely new from what we've been doing for the past 40 hours, and an 'easy' fix to a problem that was too tedious to rebuild. That, and seeing all the robots flying around amongst the giant spaghetti mess we'd made just looked really cool.

Also, we had set up a system that auto-trashed any wood we might pick up, had it flown over to requester chests where it would be made into a useable product in a system that made the small electric poles, which would then be flown over to us to keep us stocked up on the things. To my knowledge, and correct me if I'm wrong, there is no way to designate where trashed items are brought to, and a system like that wouldn't be possible any longer. Which means we'd have to keep wood on our persons, bring it over manually, or craft these small electric poles by hand. I felt really good about figuring this system out, and now you want to take it out of the game? No please.