Friday Facts #225 - Bots versus belts (part 2)

[Therax]

My personal inclination is still to find a way to buff belts and inserters, but if that seems impractical and a nerf to robots is necessary, of all the suggested solutions I like the idea of a limitation on robot<->chest throughput.

I believe this could be implemented with a variant of the Token Bucket Algorithm, which would require storing a single additional int per logistics chest, and CPU-wise would entail an additional read & write when a robot adds/removes items from a chest, and a periodic increment to empty or refill the buckets for all containers on the map. This would probably be considerably cheaper UPS-wise than adding collision detection to bots, and cheaper than tracking "slots" per chest for robots to interact with a la roboports.

This would allow for bursts of activity, so use cases such as refilling a player's inventory or dropping off items from large construction orders are unaffected, but sustained throughput would diminish over time to a steady-state in a production line scenario.

This might also allow for some interesting new design space in bot-based setups: you could have large chests, with low throughput limits, and small chests with higher throughput. You could have technology that boosts chest throughput, either in conjunction with or as a replacement for robot cargo size research.

This would effectively cap bot throughput indirectly because the number of chests that can be placed next to an assembler or train is limited by inserter reach and beacon placement constraints. Boosting throughput would mean placing more assemblers, beacons, and/or train stations, to get more locations where logistics chests can be placed.

This has nice parallels to the current robot recharging mechanics: A fixed number of slots means robots queue, which requires more roboports, which takes up more space. The difference is that chests have additional placement constraints, since they need to be adjacent to the entities they are servicing.

[SilverWarior]

I see that suggestions about possible bot nerfing are still the same as they were in previous FF like increased power requirement, increased waiting times, lower carrying capacities. The problem with all these suggestions is that thy can easily be overcome by simply building more logistic robots, increasing power production or building more roboports.

Last weak I have posted a bit different suggestion whose main goal is to make sure that by increasing the number of logistic robots it actually becomes progressively harder to maintain them.
Since I knew my suggestion is quite unique I even went and posted it as a new thread under Suggestions section so that it could be seen by developers and perhaps even by other people but forum moderators moved it to FF224 thread where it was simply overlooked amongst all those posts. So now I'm quoting my suggestion here again hoping that this time it might actually bee seen.

Hi!

In Friday Facts 224 developers sad that they thing that logistics bots are to powerful and that for small time they even thinking about removing them.
I do agree with them that logistics bots are too powerful but I do not think they should be removed but instead nerfed a bit.

Now why are logistic bots so overpowered? That is because there is no limitation of how many of them you have. For instance when 100 logistic bots can't move items fast enough you simply build more. Yes this does increase the required power for their recharging but this can be easily solved by increasing your base power production. Most commonly people would use solar panels for this since they basically provide free energy (just initial investment). Another obstacle that player might encounter when increasing the number of logistic bots is that they can't recharge fast enough due to limitation of how many of them can be simultaneously recharging at one Roboport. But this is easily solvable by building more Roboports.

So how do we solve this?
Do we increase the logistics bots power requirements? No as this will be easily solvable by building more solar panels.
Do we limit the recharging or range? no as this would only lead to player building more Roboports.
Do we increase the cost for building logistic bots? No as this would only slow down the production of logistic bots from player and thus just take a little more time to reach same thing.

My suggestion would be to increase the costs for maintaining logistic bots by adding a limited lifespan of their battery. So let us say that after 1000 charges their battery capacity slowly starts lowering which would consequentially be lowering their range. This then continues to the point where logistic bot won't be even able to fly. At that time they player needs to ship that logistic bot back to the factory where it will be refitted with new battery.
So basically we add batteries to the required maintenance costs of logistic bots.

Any way I think that the best thing about my suggestion is that initially when player have small number of logistic bots it doesn't really makes much of a difference since at the point you unlock logistic bots you already have basic battery production setup which would probably be enough to support bot maintenance. But when you build more bots maintaining them becomes increasingly more difficult as it requires bigger battery production capabilities. So players would have to adjust their bases accordingly. And since this isn't so easily solvable as building a few more solar panels it will require more players involvement and thus become more interesting.

[ssilk]

This discussion is quite interesting, lot's of ideas. Some more ideas:


Nerf Long Range Transport

This nerfs when a robot needs to run long without pausing: A robot needs more and more rest between rechrching, cause the motor overheats. It can only cool completly down, if it parks into a roboport.


Logistic Area can Handle only 200 Bots per Area

This makes only sense together with more layers of logistic network (for example "Colored logistic", see viewtopic.php?f=80&t=43460 ). Then this limitation is no problem and forces that belts get much stronger.

No shrinking of construction of course. And 200 is just a placeholder, but from experience I would say around into that range.


Buff Belts by Adding Loader (or similar) to Bring the Items Simpler to the Bots

Not much to say: The loader and/or a similiar device than Klonans Belt Buffer Mod (I find that too strong) would give more reasons to use belts instead of robots: A loader and a chest instead of some inserters and some chests for the same throughput.

Side effect:

I like such gameplay a lot, when you bring items with belts "as near as possible" to the target and then, when it gets too complex lets make robots the rest. Robots are nice, if you use them for short range transport and that makes also a lot of sense.

For that strategy it would be quite useful to have more layers of logistic network (see viewtopic.php?f=80&t=43460 ) and/or the above idea of nerfing long-range-transport. Then you can shrink/split the network into different parts to reduce the distances that the bots can run.


Nerf Robot Transport of Bulk-Items

In my opinion bots are only "missused", when we transport bulk items with it: iron(ore), copper(ore) and so on. A processing unit is much less "bulk" than that. And flying robot frame is even lesser bulk.

It depends on how much time needs to flow into producing an item and how many items are needed. In any case we can say: The less bulky, the more assembled the item is, the more it makes sense to transport it with robots.
Can also be seen from the other side: The more assembled an item is, the less sense does it make to transport it by belts, cause the belt works as a buffer and the chance, that you need so much items which are on the belts, is much lower.

So a simple shrink would be to nerf bulk transport via robots a lot:

Maybe even fully researched, a robot can transport only one iron-ore, iron, coal, stone and so on (how much is part of balancing).
Such changes would match fine into the gameplay, cause when the player just researched bots there is no, but the more robot-researches the player has, the more obvious it whould be.

That change would make robots for bulk items up to 5 times slower. Notice: This are not "heavy items". Or maybe other explained: The heavyness of items sinks with rising complexity of the item. Physically it can be eventually explained like that the more advanced items can be carried better. Maybe they have "handles" and can be stapeled better in the robots.

More nerfing: Transport of bulk-items
- needs more energy (not good to handle?).
- makes robots slower somehow (air resistance?).

Settler Robots

Idea comes from The Settlers: The robots are stationed in a roboport and cannot leave that area. So the first robot picks up something from a chest nearby and runs to the border the roboport area, where it give the items the next bot from the next roboport. And so on. That's why I thought about The Settlers. Takes about 2-4 times more robots to transport an item, but this can simple balanced by changing the ranges of a robot a bit.

Robots, that have nothing to do (in the roboports) can automatically change to a roboport, which needs more robots yet.

[Mestiff]

Don't forget to add research that will unlock option to filter via spliters. Prioritizing sides is ok but filtering is too overpowered for early game.

I would like to see the yellow inserter the same as now, the red inserter with prioritize option, the blue inserter with filter.

[Ohz]

My suggestion would be to either completely remove the Worker robot cargo size research, or more likely, to multiply the charging time several times - Kovarex

You got my words.

[blueblue]

So to throw in a suggestion I havent seen in this thread yet, I'd like to see changes to the way solar power or accumulators work. Right now they are a UPS-free power source in the late-game, which is necessary for bots to work better than belts in megabases. If every power source were associated with UPS-costs instead, belts and bots in mega bases could both be viable if the required energy for bots is balanced correctly; and mega base builders would have to keep an eye on tradeoffs like belts vs bots, number of beacons and efficiency modules more closely.

As one example change, accumulators could be replaced by electric boilers. This would also make solar power harder to set up and give it a nice interaction with steam setups but make it require a bit less space overall, both of which imo are a good thing.

I'd like to throw out other ideas for solar power overhauls but I dont have any good ones. Another idea was making accumulators require some kind of fuel, since real accumulators have a limited life time, or giving solar panels a limited life time, but that would probably just be tedious. But still, I think solar power needs some changes, it is very easy to set up and basically kills any late game power considerations. It's funny that for me the current power progression is steam -> nuclear -> solar, although the intended order was probably with nuclear last.

[Reika]

I am very open to the idea of bot nerfs - I am firmly in agreement that they trivialize too much of the logistics - but I do not like the idea of slowing their recharge. This is because of the effect it will have on personal roboports: Both kinds of robots can only charge 2-4 at a time, already taking several seconds per robot, and because walking tends to leave them behind, you are largely forced to stand still while they do so. If you have 100 robots, that can take more than a minute. Multiplying this already-irritating forced-downtime is not a desirable outcome at all.

[stokan]

After reading all the responses to this FFF and last weeks, you have motivated me to post my first ever FFF response.

Nerfing Bots
I am personally against nerfing bots; I recognize my personal opinion has very little matter but I want to be forthright with my bias. If you do nerf bots, please do pay attention to make it easily reversible via mods.

I am concerned that this change is aimed at just megabases or very long life bases. YCurrent bots and bot research (to me) feels a large reward for a very large investment. It feels great to unlock bots, and then unlock logistics, and after a few bot upgrades they then feel truly impactful. In the scope of a mega base, this portion of the game is basically just a prelude to a much larger game of ever growing throughput and optimization. For me personally and the several friends I have gotten into the game, unlocking those impactful upgrades is much closer to the end of the game. Launch a couple of rockets, maybe do the non infinite researches, run around and smite a bunch of biters then map over. Go on to a new map or different game for a while then come back somewhile later to a new map. I'd be curious to know if you have any data pertaining to average longevity of maps, total number of bots, or anything along those lines?

This is PURELY an assumption, but I would wager the megabases are by far the minority. If so, is it worth diminishing the impact of bots in order to influence the playstyle of megabases? My argument overall has strayed a little too close to 'appeal to emotion' for my comfort, but I think considering how changes make people feel has some weight, even if less weight than other consideration.

Buffing belts

I appreciate that this FFF covers some suggestions on buffing belts. I have seen the following suggestion batted around elsewhere so make no claim over it as my own but I didn't see it elsewhere in todays thread.

Covered Belts:
- New belt entity, required similar level of research as the logistics network
- Inserters/players/bots/etc can not pick up or drop directly off the belt. Can not be directly connected to normal belts
- Second entity (similar to the splitter?) that is 'covered belt' speed on one half and blue belt speed on the other. The blue belt speed side is then available to inserters/player/connected to other belts
- Additional entity for underground covered belts
- Items are not visible on belt, although maybe a selection of items could be drawn near the edge of the entity to indicate contents
- Has an extremely high throughput but the item calculations can be done under the covers. I'd say to the tune of multiple blue belts worth of capacity
- Speed can be increased further through reasearch
- From a 'fantasy' perspective these could be a bunch of picker robots ( https://youtu.be/cajVzpJKjdw?t=93 ) inside the covered belt helping items along/moving them on/off the input/exits

As a final crazy suggestion for this, it would be neat if 'covered belts' could be placed underground at variable lenghts where it consumes units of the 'underground covered belt' until you place the entity. Similar to building several blocks of rail at the same time so you could have very long/short instances of the underground version with consistend resource costs.

Neither Belts nor Bots

Looking at examples of things provided by bother the devs and several other players, to me it feels like the real root cause of this issue is beacons. In kovarex's example he made the smelters very fast similar to the way may "overpowered" bot only bases are completely dependent on very fast assemblers stuffed in tight with many beacons. I personally find this playstyle very frustrating/unenjoyable (my bias) but I do think it contributes to the perceived imbalance between bots and belts because cramming in beacons makes it harder to bring in belts to reasonable setups.

Rather than repeat suggestions I've seen elsewhere in the thread I will just echo their link here: https://www.reddit.com/r/factorio/comme ... uce_tiers/

I will note that I am partial to suggestions in the comments of having beacons be transmitted via wire rather than "wifi" but that does drastically change the tetris style puzzle of beacons.

*Edit*: Added YouTube link of picker robots

[Ecu]

https://www.factorio.com/blog/post/fff-225

I've thought of another suggestion to solve the issue with robots being the best option, without eliminating robot only factories for those that love them.

It would be another overhaul to the way things work now, but perhaps that is not a bad thing.

[bobucles]

We hope, we are waiting. Stack-belt
Big gif

It's so purrty! But a 23MB Gif is a little meaty, isn't it? I wonder if the forum webm linker works.

Stack-belt.webm

smaller size of gif

(525.97 KiB) Downloaded 204 times

Welp. I tried.

[Sogrog]

My proposal: Dedicated High-throughput "Belt" system.

High-throughput Belt

High-throughputBelt.jpg (292.22 KiB) Viewed 9539 times

One or more loading stations connected to one or more unloading stations by pipe-like structure. Every pipe is capable of replacing 4 fully compressed belts. Items in the pipe don't interact with anything but the (un)loading stations. This structure could exist in three variants (yellow, red and blue) or their throughput can be increase by research (IMO better aproach).

Pros:
- Adding new toys is much more preferable solution than nerfing old ones.
- Addition of dedicated high-throughput "belt" increase potential variety of main bus designes.
- Creates viable alternative for trains for short to mid distances.
- Lack of collisions and interactions should allow better optimalization even for long distances.

Cons:
- Requires new graphics and at least some new code. (And lots of testing.)
- This system is not really a complete upgrade, part of versatility is sacrificed for throughput.

[scali]

One really interesting point in this FFF is the discussion of the Death spell in Baldur's Gate acting as a big point of progression. What it effectively does is it breaks down the game into effective tiers, where the Death spell lets you trivialize the early tiers of the game so you can focus on the current tier.

I'd like to start by prefacing this discussion with the idea that I might be discussing a different hypothetical game that would no longer be Factorio.

Factorio is a game of scaling vertically and horizontally. Vertical here implies progression ("better", tech tree), while horizontal implies throughput ("bigger", scale), with the player choosing which axis to focus on at any point in time, with some overlap (Research faster belts).

Vertically, the game's progression comes down resource acquisition/production and research, roughly broken down into:

- Resource: Get goods (belts)
- Resource: Get electricity (poles)
- Automate: Science Pack 1/2
- Resource: Get oil (pipes)
- Automate: Science pack 3
- Automate: Other Science Packs
- Rocket

What that tells me is that either bots could trivialize pre-Science-pack 3 workflows but not post-science-pack-3 (to allow the player to focus on late game content), or act as a resource type to gate off later content: In addition to providing fluids / power, X requires N Logistic Bots to work the assembler, and bots degrade over time. In this way, bots become a resource like power or oil.

Horizontally, the game's progression comes down to increasing scale and automating things to help you automate things further. There are a number of mini-progressions in the overall theme of automation:

- Goods at small scale at fine granularity: Yellow belts => Red Belts => Blue Belts and supporting structures for storage and management
- Fluids: Pipes and supporting structures for storage and management (and conversion to Goods via barrels)
- Power: Wooden Poles / Medium Power Poles / Large power poles / Substations and supporting structures for storage and management (A power cell good that can be drained into batteries might be cool here, like fluids and barrels)
- Goods at large scale at coarse granularity: Trains
- Goods at small scale at fine granularity: Bots

The issue is that while trains don't trivialize belts because they provide massive throughput at an extremely coarse granularity, bots trivialize them because bots are easy and scale linearly, while belts are fiddly and don't scale linearly due to taking up space and bots fill the same niche as belts. Here are a few possible ideas on how to resolve this:

- Restrict the set of items a bot can carry, making belts worthwhile again. Maybe add a bot progression to compete with belts ("You need V5 Logistic Bots to carry X, Y, or Z"), or leave the items bots can carry to a limited subset. I have no idea how to select what a bot can and can't carry, but the intention would be to trivialize pre-Science-pack 3 content with bots, but require belts for content past that.

- Alternatively, you can buff belts to make them more powerful. How about a 4th tier of belt that is like a blue belt, but it also carries electricity? What about a BeltPump that also provides a pipe that behaves like a belt, with built in pumps (with fluid "inserters" to put them back into normal pipes) A Belt stack (and an appropriate belt on-ramp / off-ramp structure) that allows you to build X belts on top of each other? A Feeder belt that acts as if it has inserters to place things into appropriate chests or assemblers next to it? Belts will, by definition, always be more fiddly than bots, so figure out what bots can't avoid (like a requester chest with an inserter to place the good in an assembler), and make belts that can get around those limitations.

Anyway, just my 2 cents, Factorio's still my favorite drug on the planet, thanks for making this game.

[Vandroiy]

Devs, this isn't the right perspective on the issue! The late-game is solely about optimizing CPU performance and player clicks, while in-game costs aren't even a concern!

It's borderline impossible to balance logistics features if everyone hates the main late-game types of cost you have. If you lack another solution, add a command resource with above-linear overall cost that limits the amount of stuff that's running at the same time, and give roboports a reasonable cost in that regard.

Also, the idea of ever more belts "being cool" is a design dead-end. The effect players feel is logarithmic in the amount of stuff, but the CPU cost is not! You have done enough, in fact, reign it in! UPS is a really bad type of in-game cost. Intended costs should stop expansion before real-life hardware limits do that.

Twinsen had the problem down in the last post: bots' costs don't work and belts have ugly costs due to tedious recipe complexity, sorting, and balancing. Solutions should address the core problems first. We need meaningful investments of in-game resources! For the typical player, researching bots is such a meaningful investment, so a strong nerf alone just trades a balance issue for a dynamics issue.

Some nerfing is in order here. But please remember, if balance alone made a good game, we'd already have a perfect game in rock-paper-scissors.

[ssilk]

And two more ideas:

Buff Belts by Adding a Copy/Paste Tool

It makes me crazy that this mod seems not work any longer: https://mods.factorio.com/mods/mickael9/cut-and-paste

Adding such a tool instead of quite unhandy blueprint makes constructions so much simpler.


Buff Belts by Making Construction Simpler

Set Start Belt, Click, Drag, Rotate: Belt is built from start to end under trains and other belts. More clever options will eventually move belts, that are in the way...

Useful also for pipes, poles, and much more.

[vipm23]

Regarding bot nerfs, an actual chest access cooldown may be worth a lot. An inserter can only access a chest so quickly, and you can only ever have four (well technically eight) inserters accessing a chest at a time. It doesn't have to be crippling, but it might go a long way towards making bots a situation for "Tricky configurations" - Hell, that might even be a reason to buff logistics bots in other respects - if they have to compete with inserters for speed, then they could maintain their use as a flexibility tool whilst leaving major hauling to belts, and then you could reduce their tech/production cost, maybe even make roboports smaller. That way trains -> belts -> bots could be about trading throughput for flexibility. Maybe. It's just a thought.

This. Part of the problem is that an infinite number of bots can be in any one tile, accessing the same chest, at the same time, so throughput is wholly dependent on number of bots. Chests having a cooldown between each time a bot can access it would throttle throughput from chest to chest, while not otherwise penalizing the player for having lots of bots.

More reasons for a chest cooldown:
1.Retains bot versatility
2.Easy to balance:Just change the length of the cooldown timer.
2a.Can be subject to infinite research.
3.Does not completely break existing designs, just causes slowdowns.
4.Presents a soft cap on how many bots are useful to have, not a hard cap on how many bots can be in the air.
4a.The cap can be raised by using more requester/provider chests as terminals, trading space for throughput.

Another idea: Instead of a chest cooldown, have it so only one bot can interact with a chest at a time, and it takes time to do so.(Can be presented as the bot flying down to the chest, grabbing or dropping cargo, and flying back up)

[WhiteFang34]

Don't forget to add research that will unlock option to filter via spliters. Prioritizing sides is ok but filtering is too overpowered for early game.

I would like to see the yellow inserter the same as now, the red inserter with prioritize option, the blue inserter with filter.

That's a good idea.

[kenken244]

I think the limitation that bots really need, is something that will make them more interesting, that could be overcome with clever design. also, simply reducing their cargo size, speed, or energy consumption will not help. as their throughput is still unlimited, you can always make more bots. I think something like a restriction on the number of bots per network, a limit on how many bots can load or unload at the same time, or something similar would be best.

[ps666]

You want constructive feedback?

Remove belts and implement a second bot tier. One that double the stack size and traveling speed.
Problem solved. There is only one way to have fun. No choice, no drama. Everyone will be happy.

When you kill my bots, I will stop spreading the word. Definitely

[sabriath]

Nerfing in order to balance a system is never optimal in game design, it shows to your audience that you've given up on ideas.....look at WoW for example, when they took away everyone's choice in the talent tree and gave them all cookie-cutter classes, which all end up with pretty much the same spells (different visuals, same damage).

What I'm saying is.....don't nerf robots, that isn't where the issue lies. If you force robots to charge more, then players will just build more solar panels.....and if you force them to have less inventory, then players will just make more robots. This doesn't solve the issue of separating the players from the robots....you given them no honey to distract them.

Some ideas:
1. When launching a rocket, there's a no-fly zone in a radius from the launchpad.....this will force at least the endgame to require belts to an offsite launching. This can be done by making sure no roboport zones are within a range, and it would be even nicer if robots are forced to stay within the markers (robots leaving a zone will "die" in midair without a signal, creating a robot entity on the ground to be picked up). This isn't exactly a nerf, as this pertains to the actual design nature of the robots themselves.....the roboports are supposed to be the signal transmitters for the robots.
2. Create a new type of transportation altogether, as this will give a new avenue for players to explore. Teleportation, monorails (1 block wide trains to completely replace belts?), AAI vehicle types, anything is better than "just faster belt" or "reduce bots".

[stretch611]

Hi there! Nice FFF! Can't even imagine you were talking about ending this blog few weeks ago...

I agree... if anything the response to last week's FFF and the quick number of responses to this week's FFF show that one or two people may still be reading them.