So... Let's talk about bots, and how to fix them properly...

[On_fire]

TLDR;

The real problem with bots isn't that they are too powerful, it's that they aren't as fun as they should be. The real problem with finding a solution, is that the problem wasn't ever properly defined. In the first section I go over what's really going on, and in the rest I go over my ideas on how to fix it. Feel free to skip to the idea sections if you just want to see what I have come up with, but please read the whole post before replying, thanks!

Defining the Problem

So, I think most Factorio players can agree that bots have plenty of room for improvement, we just can't seem to agree on what that improvement looks like. I think a large part of the problem here, is that the real problem hasn't even been properly defined, so let's start there.

Now, there are 3 types of transportation in Factorio: belts, rails, and bots. The main issue that many people see is that for several reasons, belts, rails, and bots are way out of balance. They were designed in a way where they should work together and complement each other, but instead bot's basically take over once you get them. Unfortunately, due to how well bots scale, no amount of nerfing can really fix that... But, while this is definitely a problem, it isn't the problem... You see in other circumstances, this wouldn't be a huge problem, if something is a better fit for most situations, use it, no big deal. The balance may be a bit off, but it won't really get in the way of having fun. Unfortunately, the issue with bots is that there are far fewer solutions available to solve problems with once you get them. (Need more iron smelting? Place down a blueprint with a bunch of robotic smelters! Too many bots to charge? Add more roboports! Bot network to slow? Add more bots or research upgrades that affect all of them! Tired of adding bots by hand? Automate it so you never have to think about it again! And that's about it...) The bots have an absurdly small number of problems and solutions to those problems, and, since most of the fun of Factorio comes from solving problems, there isn't nearly as much fun to be had once you get them... And that becomes a huge problem, because they aren't the first method of transport you get, they are the last, and they overshadow everything else for most situations.

So, while the balance between belts, rails, and bots is definitely something that needs to be fixed, it's not what is really causing the end game to be less fun than early and mid game. The only way to really fix this issue, is to make bots as fun as belts and trains are, and the only way to do that is by making them require more strategy, planning, and problem solving. I really don't think that there is an easy fix for this issue, so I wouldn't expect to see a fix for this for quite some time...

So, with all that said, I have a few ideas that I think would add more complexity and problem solving to bots, in order to make them way more fun. I definitely think this would be considerably better, but, I still don't think it is QUITE there yet... So, I really want to hear ideas from y'all about how to make more problems to solve in a fun way, and then I can compile all of our ideas into a coherent, solid suggestion to be posted.

Idea #1: Roboport extensions

Similar to Bob's modular roboports, but pretty different in actual implementation.
Instead of fixing roboport capacity issues by simply building more roboports in an area, have extensions to a roboport that you can build around a roboport. Each type of extension could have multiple levels, or for simplicity, you can just add modules to improve an extension... This adds additional solutions to problems, but also more problems to solve, as you can only fit so many extensions around a roboport.

• Antennas would increase the coverage area.
• Charging pads would increase the number of robots that can charge at the roboport.
• Bot Chests would increase the number of bots of a type can can be stored at a roboport.

Idea #2: Isolated Roboports

Make bots only work in the area of the roboport that they are stationed at, as if each roboport was it's own network. This allows you to have more control over how many bots of each type are in an area, as well as requiring more planning. Add a research to allow automating how many bots of each type are stationed at each roboport. Obviously by itself this would make bots nearly useless, however, that's where Idea #3 comes in.

Idea #3: Transporter Bots

Add a new class of bots that would transport items between roboports. This would allow optimizing speed vs quantity, as well as optimizing how items get moved over longer distances.
There would be 2 types of transporter bots:

• Transport bots: Small and very fast bots, but with a small stack size, designed for moving small quantities of items around the base as quickly as possible. (Great for supplying a field of assemblers.)
• Cargo bots: Large and very slow bots, but with a very large capacity of several stacks, designed for moving large quantities of a single item moderate distances very efficiently. (Great for supplying robotic smelting setups, or for chests that fill belts for production blocks.)

Idea #4: Shipping Lanes

Instead of transporter bots working in a certain square area like regular bots, move inside of "shipping lanes" to connect your roboports. To create a shipping lane, you would connect "beacons" to each other. Beacons would be provided by roboports and bot platforms as well as electric pole like towers, and would function like waypoints, telling the bots where to go next. Each segment between beacons would work like a rail segment, only able to have a certain number of bots on it. Upgraded beacons would be able to have multiple shipping lanes in each direction, and research could increase how many bots can be in a shipping lane. Roboports would report their requested and available items to their beacon, so that the transporter bots can fill the requests. While all of these ideas could be used seperately, shipping lanes are really the glue that holds the other ideas together. This would add additional depth to bots, as you would be able to optimize your network for delivery of certain things to certain places. While the other ideas provide tools to fix problems with, shipping lanes work to create more opportunities for problem solving, without making bots less powerful or useful.

Idea #5: Robot Docking Railcar

Ideally, bots shouldn't take the place of trains for long distance moving, they should enhance a rail network. A bot platform would contain a beacon, and could sit next to the tracks and request empty cargo bots or cargo bots carrying certain supplies, then place the bots loaded with their cargo on a docking railcar (Similar to an Intermodal railcar.) that is over the platform. This would allow a lot of problem solving to figure out the best way to get the items you need on the right train, without it being an exercise in optimizing belt and inserter configurations, since there are a lot of other places to do that...

Idea #6: Warehouse

A large buffer chest building, with a built in beacon, charging pads, and Transporter bot storage. It would primarily be used to keep large quantities of several types of items close to multiple roboports that would use them, ideal for a high throughput smelting or assembly area, or a train station with a robot platform, since it would be able to load directly onto and off of cargo bots.

[evildogbot100]

You are correct at nailing the real problem of bots. They just don't present enough problem to be fun. There is just not many optimisation tricks you can do with bots. Unfortunately, I still think that any change to bots except for complete overhaul won't cut it to raise its complexity. That's why of all ideas about bots, I support changing bots to cable car idea the most. The shipping lane idea is kind of similar to cable car so I dig on that. Also, I would like to see the square area of roboport to be a lot smaller than the current one as well.

[quinor]

What if there was an infinite research for max active robot count in one logistic area? It would allow small-scale fun while providing challenge when building big-scale installations (you'd have to split the factory into multiple smaller chunks if you wanna mass bots, not just throw enough bots into the system)

[HurkWurk]

ive always seen factorio as a game of learning to automate, with bots being the level of automation after belts, and not a complementary or competing technology, but rather a very expensive alternative that is required to scale up.

no one is complaining about how fast inserters replace burner inserters at the end game after all.

[pgriss]

if something is a better fit for most situations, use it, no big deal

I think your problem definition neglects an important fact: belts and trains are a lot of fun. So the problem is not that robots are boring on their own, rather that they are more efficient than other solutions that are more fun. Along the same lines, no one is complaining about how fast inserters replace burner inserters because no one cares about burner inserters (and as a side note I never felt the need to replace the burner inserters next to my boilers).

If you want to focus on solving the problem by making robots more fun, you will have to come up with ideas that outcompete belts and trains on the fun factor. I am not optimistic that you will succeed, especially considering how late we are in the development life cycle of Factorio. For example, the shipping lanes are interesting on their own, but when you consider it in the context of Factorio, it starts to look a lot like you just invented flying trains. Will the benefits justify the required development effort? It seems to me much smaller, incremental improvements are possible for trains that deliver more bang for our buck...

Instead of forcing the robots into a hard-to-win fun competition with belts and trains, it might be easier to make sure they don't compete at all. We can do this by finding a niche for them and making sure that they are really good in that area and not anywhere else. Note that construction robots achieved this perfectly.

I like the isolated roboports idea as it defines the logistics robot's niche as "delivers stuff within a small area". I like this idea on its own, I don't think it makes robots useless, as I can use trains or belts to connect my isolated roboports. Strictly speaking it doesn't even require any development effort, as I can just build the roboports a bit further away. Admittedly an option to isolate roboports regardless of distance would be nice.

[Triaxx2]

The problem as explained to me, is that when feeding into a chest, belts max out at being able to feed into three sides, and one out, while bots have no limits at all in their ability to access the chests. So you can have an infinite number of bots interacting with the chests.

[HurkWurk]

if i had to pick a solution to bots, there is a rather simple one. disallow free-form flight. force bots to follow existing belt or power wire paths. that at least forces players to think about routing, but honestly, its just that nothing is needed. the end game IS bots. thats the whole design of the game is to optimize over and over again until even belts arent needed.

the only way to prevent that is to add some function that is NOT game related at all, but rather, a role playing element as to why bots cannot operate outside a certain range of your base.
so fake up something (native air destroys bots).
fake up a solution (as you pollute the air you kill the microorganism that causes the destruction)
grant the player a way to implement this slowly. (go build a remote outpost with normal belts and start polluting until the pollution allows for bots)

congradulations, you not only solved the bot sprawl, but gave a whole point as to WHY we are fighting the natives.

[bazulu]

I think part of what makes bots not as challenging is that they don't require much logistics to setup and maintain. All you need to do is connect them up to the power grid and life is good.

My thought on this is why not try having the logistic bots use a liquid fuel instead of electricity. I suggest creating a new logistic robo port and fuel type only for logistic bots. The logistic robo port should have a fuel input and two small buffers to store the fuel. The fist buffer is from fuel input and the second is left over fuel from landed logi bots. The logistic bots would burn liquid fuel as they fly from point a to point b. If they run out of fuel they can go to electric mode which is a slower speed and automatically fly to the closest logi robo port. If they run out of electric power getting to the port then they can move at the snails pace that they currently do when they run out of power. Once a bot has landed in a logi robo port it can not leave the port until it has fuel.

Construction bots should continue to use power as I don't think they are an issue. The current robo ports should only work for construction robots.

This would allow for more thought needed when setting up your logistic network.

[CallMeCupid]

There is 1 simple change from a mechanics perspective (not sure how difficult to implement): Add bot collision. Limit the number of bots per block to somewhere between 1 and 4. This retains the usefulness of bots to do things that are low throughput and/or advanced tasks like making armor modules, things that are don't need to be mass-produced constantly, but become a chore for the player. This makes bots great for delivering artillery shells to your defences or helping you make mk2 shields, but much less suited for iron or copper smelting.
This can also be an opportunity to diversify the game. Almost all recipes in the game especially ones that need to be mass-produced are made from very simple and scalable components that require 4 ingredients at most. More complicated and specific components that require more ingredients can be added or recipes changed to accommodate this. Explosive uranium cannon shell, now maybe it requires solid propellant or timing fuses or any one of many things which could be added once the handicap of "each recipe needs to be 3 or 4 basic and common ingredients." Maybe you could add (shameless plug) cargo ships or tank modules! Bring the steel in on belts, bring the 6-8 ship specific components in by robot.
TL,DR: Add collision to robots so they can be effective at helping with annoying chores and less effective with mass production.
This also can be an opportunity to add more complex recipes to the game which were not feasible before because they relied on a belt web method for supplying components

[HerpicusMcDerpington]

I think the whole discussion is missing something

Even with changing bots to be more interesting, or more challenging to set up, it will not improve belts.
Whatever you do to bots, people will figure out a way to make it working again like it does now, and all you need to do is copy that "perfect" setup and stamp it down.

While trying hard to create a rail&belt only (somewhat mega-)base, i hit a wall time and time again:
When i want to fit in high throughput item supply via belt, between assemblers and beacons.
Beacons are the way to go. Yes, they need alot power, but thats easier than just running at standard speed, with no productivity (=less resources spent for the same output. Its actually get more for the same input, but afterall it comes down to the same thing)


Lets take aside that bots are (still?) more UPS friendly for truly megalomanic bases and just look at what you can do with one requester chest and a stack inserter

There are only 2 tiles per side to fit in belts and inserters between beacons. Maybe a bit more with belt weaving. But you still need an Output and waving belts limits throughput cos you need a slower type to get it working (so in reality, for maxing out its blue/red, with red being used for lowest demand input+ the needed output)
Now compare that to a requester and a stack inserter. The inserter can, from boxes&trains, grab a full stack instantly, and there is no limit to throughput, other than robot numbers (and maybe speed research for that matter. the faster they work, the less you need = less power needed)
Also there is no far side loading (only half a belt) for boxes

If bots would be changed, there will be someone who finds a way and i´d still be sitting here trying to figure out how to do that with belts.
And if bots were nerfed to the ground, i´d still be sitting here, trying with belts to do what WAS possible with bots.
It would not at all make me happier to know that people who used bots cant do that now either!


To give belts a chance, there needs to be changes to whats possible. Belt compression is something, but there could also be near inserters, lane changers etc.
But i think the easiest way is to give us more room between beacons (=make effected area larger) and take away something else, like machines they can power (or max out the number of signals machines can receive from beacons)
It could be the same throughput (in a factory, pure lane throughput is not te way to compare them as explained above) and everyone would be a bit happier

[evildogbot100]

No, you are the one missing the point here. No one intended to nerf bots for the sake of belts. Bot nerf advocates most likely want to nerf bots just for the sake of it. We just think bots are too cheaty so we don't use it at all. The idea here is to change something that is perceived as a cheat to a feature since bots in its current form are more like a cheat than a feature, at least for me.

[impetus maximus]

isn't there a thread on this subject already?

[5thHorseman]

isn't there a thread on this subject already?

Yes, at least 3 of them.

No one intended to nerf bots for the sake of belts.

The developers disagree with you, in the two "should we nerf bots so people will use belts" FFF's last month.

[HerpicusMcDerpington]

The idea here is to change something that is perceived as a cheat to a feature since bots in its current form are more like a cheat than a feature, at least for me.

i think the term was "boring"

you dont need to think about much when setting up a bot array

Im all for improving (and complicating, lets face it, everything is complicated when it comes to min/max ratios etc... but thats the challenge of this awesome game) bots

But people seem to come up with all kind of bots and belts improvments, when i think the real issue is the possibility to max an array of more than 5 AMs in a row, with belts between AMs and beacons.
I quite liked the ideas in the OP, but as I said, someone will find a way to make them much better than belts again, and we´d be back to that heated discussion. BPs will be more complicated than now, but the arrays will still be far better than with belts.

[golfmiketango]

if something is a better fit for most situations, use it, no big deal

I think your problem definition neglects an important fact: belts and trains are a lot of fun. So the problem is not that robots are boring on their own, rather that they are more efficient than other solutions that are more fun. Along the same lines, no one is complaining about how fast inserters replace burner inserters because no one cares about burner inserters (and as a side note I never felt the need to replace the burner inserters next to my boilers).

I think you've really stumbled onto something that needs serious consideration, pgriss... I never thought about it this way until you mentioned it, but.... ever tried playing factorio and seeing how much you can automate without any research whatsoever?

Without assembly machines you can really only do smelting, smelting and more smelting. But, with sufficient determination, you can do quite a bit of it, so long as your biters are by some means or another persuaded to leave you in peace.

Due to the need to fuel those burner inserters, in many cases, by having inserters inserting into other inserters, this "no-science factorio minigame" makes inserting in general a richer and more interesting gameplay experience than at any other time in the factorio gameplay progression. Without any research, and using nothing but regular transport belt and burner inserters, it is possible to implement the functional equivalent of splitters, and even, with a sufficiently clever build, undergrounds and filter inserters.

It seems that a layer of puzzle-solving is embedded into very-early-game factorio, that, in normal gameplay, is rarely explored or exploited. Why not? Well, it's not that interesting. You'd get bored of just that minigame pretty fast (at least, compared to the replay value of normal factorio). If we add assembly machine I's to our mini-game, it does become significantly more compelling, but I think most would agree that it's not more interesting than, say, the red-and-green-science-only minigame. Not by a long shot.

Anyhow, once we add red science tech to the mix, something wierd happens. Now we get underground belts and electric inserters and splitters and very suddenly, all of those burner inserters go from essential tech to outdated junk we can pretty-much put in a box and shoot. When we lose those burner inserters, however, we also lose that landscape of puzzles and challenges that came with fueling them. Well by now you know where this is heading ... Oh well. What's done is done. The 0.17 inserter nerf will be a bitter pill, but we must swallow it... if only there were some other way of looking at this unfortunate but unavoidable consequence of the progressive nature of vanilla factorio which would allow us to properly balance the game and preserve the existing joy of post-red-science factorio gameplay!

[Kazaanh]

Logi robots are not satysfying to use and make most of the game trivial.

Its like skipping most of the game content and fun imo

[draknor]

TLDR;

So, while the balance between belts, rails, and bots is definitely something that needs to be fixed, it's not what is really causing the end game to be less fun than early and mid game. The only way to really fix this issue, is to make bots as fun as belts and trains are, and the only way to do that is by making them require more strategy, planning, and problem solving.

This is a fascinating perspective on this problem. I hadn't thought about it this way, but it appears very insightful and can lead us down lots of interesting avenues to explore.

Let's expand upon the challenges here:
Belts

• + Great for short-distance because of low-cost / fast transport ("low latency" in network-speak)
• + Multiple tiers support different levels of throughput
• + Small footprint, high flexibility
• + 1 layer of "management" (routing the belts around things)
• - Have to manually build each route, from source to destination
• - Routes take up physical space, which introduces routing complexity

Trains

• + Great for long-distances, because of high-capacity / bulk transport
• + Lots of flexibility in achieving long-distance transport goal (short, faster trains vs longer, slower vs even-longer-but-still-fast trains)
• - 2 layers of "management" ((a) tracks & signals, (b) trains & stops)
• - Larger physical footprint, takes up even more space
• - Have to manually build each route (or path)
• - Too much overhead / size for "last mile" delivery (eg feeding assemblers)

So the way I've used logistics bots (in my "normal" sized bases - still haven't gotten to megabase stage), is really to address the challenges imposed by belts. Specifically the ability to get items from one location to another where I don't have room / space to route a physical belt. I haven't used them to get higher throughput than what I can get from belts, so my comments below reflect my experiences.

Idea #1: Roboport extensions

This is an interesting concept, but not one that I feel as great existing analogues in the game. I think an approach more inline with existing style would be 2 different types of roboports, and/or 2 different classes?

• Basic roboport - only supports construction bots, 4x charging ports
• Advanced roboport - only supports construction bots, 8x charging ports
• Logistics roboport - only supports logistics bots, 4x charging ports
• Advanced Logistics roboport - only supports logistics bots, 8x charging ports

Of course in the end game - it'd be all about the Advanced Logistics roboport and we're right back to this same discussion, but it stretches out the progression in the mid-game.

Idea #2: Isolated Roboports

This gets to the heart of the challenge - with belts, you have to manually build every path from source to destination. It takes up physical space, and you have to route around things. The strength in bots is - you skip that. You don't need to manually build a route, the bot can get to everything in the roboport's range. But by chaining robotports to expand the network area - now you've eliminated ANY physical space constraint.

By restricting a bot to it's home roboport (and we can certainly balance the size of the logistic network it covers), you reintroduce that physical size constraint and your base design has to take that back into account. Do I run belts into this roboport's range, and then feed my assemblers via bots?

Idea #3: Transporter Bots vs Cargo bots

I like this idea in theory, but I think we'd need to discuss more what role bots are trying to fulfill:

• Do we need more throughput because express belts aren't enough?
• Do we need ways to move materials without physically constructing routes from source to destination?

In my mind (and my limited experiences/style), bots are for the latter -- I want to eliminate spaghetti and weaving belts everywhere just because I want to refuel my train engines with wood / coal / solid fuel / rocket fuel. That's a low throughput, spatially simple need that logistics bots (or transport bots, in this idea) would fulfill.

I can see the appeal of cargo bots, too - maybe my train stations are too spread out for a single roboport to hit them all, and I need to get my fuel from the coal mine / chemical plant out to all my train stops. Without cargo bots, I could belt those fuels into range of each roboport, but now I've only eliminated a portion of the spaghetti. Cargo bot concept would let me transport my materials from the source to distribution point(s) where they would be distributed to the end-point by transport bots.

I'd see this working best if the cargo bots can only transport cargo between roboports:

• Cargo bots would be researched after logistics (transport) bots
• Roboports would have inventory slots for cargo supply / cargo receive
• You could set schedules on cargo bots (just like trains)
• Cargo bots would be fueled by electricity (giving them a simplicity advantage over trains)
• Cargo bots would not have "shipping lanes" or signals to worry about
• But that would have a maximum radius they could travel to another roboport
• Only one cargo bot could load/unload at a time (which reduces throughput)
• Cargo bots' speed, capacity, and loading/unloading speed would be balanced to somewhere between an express belt and 1-2 wagon train, so for medium-distances you could have some level of throughput parity for express belts vs cargo bots vs 1-wagon train

Idea #4: Shipping Lanes

I liked this idea when I first read it, but the more I think about cargo bots and making them a hybrid of between belts & trains, the less useful I think it becomes. The unique power of bots is their ability to fly anywhere (within range), so let's not take that away. Instead, let's make sure it's balanced by other constraints (speed, capacity, loading/unloading, etc)

Idea #5: Robot Docking Railcar

I have a different approach - instead of loading bots onto the railcar, I think we should have a special wagon that bots and directly load/unload from (like a logistics chest). Call it a "logistics wagon". Eliminates the needs for separate chests and inserters, and (in conjunction with my ideas above) could support both transport + cargo bots.

Idea #6: Warehouse

I think it makes more sense for this to just be a larger / advanced / mk2 roboport - more charging pads, more storage slots.


Great thoughts, and hopefully the developers can find some inspiration from this thread!

[MalcolmCooks]

The problem as explained to me, is that when feeding into a chest, belts max out at being able to feed into three sides, and one out, while bots have no limits at all in their ability to access the chests. So you can have an infinite number of bots interacting with the chests.

There is 1 simple change from a mechanics perspective (not sure how difficult to implement): Add bot collision. Limit the number of bots per block to somewhere between 1 and 4. This retains the usefulness of bots to do things that are low throughput and/or advanced tasks like making armor modules, things that are don't need to be mass-produced constantly, but become a chore for the player. This makes bots great for delivering artillery shells to your defences or helping you make mk2 shields, but much less suited for iron or copper smelting.
This can also be an opportunity to diversify the game. Almost all recipes in the game especially ones that need to be mass-produced are made from very simple and scalable components that require 4 ingredients at most. More complicated and specific components that require more ingredients can be added or recipes changed to accommodate this. Explosive uranium cannon shell, now maybe it requires solid propellant or timing fuses or any one of many things which could be added once the handicap of "each recipe needs to be 3 or 4 basic and common ingredients." Maybe you could add (shameless plug) cargo ships or tank modules! Bring the steel in on belts, bring the 6-8 ship specific components in by robot.
TL,DR: Add collision to robots so they can be effective at helping with annoying chores and less effective with mass production.
This also can be an opportunity to add more complex recipes to the game which were not feasible before because they relied on a belt web method for supplying components

I think this is right on the money. I think this would limit bots to cases where you need a low throughput, but you also need the flexibility that bots offer. I don't see it as a problem that bots can go long distances, but I think bots should effectively fill the role of a courier - you can send a courier with a parcel anywhere you like, and it will get there pretty quickly. But you can't use couriers for absolutely everything, because then there would be gridlock.

[GlassDeviant]

My low effort solution: just don't use logistic bots.

It's each players choice whether to use them or not.

Personally I use only constructions bots, a pile or two for building and clearing and some for maintaining (/repairing) defenses on my perimeter.

[Aeternus]

Unfortunately, due to how well bots scale, no amount of nerfing can really fix that...

Redefine the problem: Bots scale into infinity, mainly due to the fact that an infinite number of bots can load/unload from the same cargo transfer point (IE provider chest) at any single time, resulting in idiotic transfer rates.
Axe that ability - one, two or four bots per chest at most, with a 1 sec cargo transfer time (similar to an inserter cycle), and the bot infinity scaling is gone. And then belts with stack inserters become top dog again in cargo transfer rate.