Belts and Tubes

An aim of Factropy is to only use 3D features that enhance the experience of building of a mostly 2D factory over flat terrain. Belts are one area where Factropy follows the elegant Factorio approach quite closely.

• Belts operate at ground level
• Belts are dual-laned in order to get many items within range of arms
• Underground belts already provide a pseudo-3D second elevation layer
• Belts can be accessed from anywhere by arms
• Belts can form intersections
• Belts can side-load
• Belts can be creatively balanced

Satisfactory belts are more complex graphically because they change elevation and can curve and slope, but they're also much simpler game-play constructs because they are effectively point-to-point single-lane connections between pre-configured structures with limited input and output choice. Dyson Sphere Program has belts somewhere in between: they can change elevation and are single-lane with limited input/output layouts on buildings, but also support interesting intersections and sorters are a fun alternative to inserters/arms.

Factropy takes a conservative approach by leaving belts on the ground and adding pneumatic tube towers to give five layers of elevation when combined:

• underground belts
• normal ground-level belts
• three tube tower heights 3m, 5m, 7m

(actually it's 5+N layers because tube towers can be placed on hills too)

The belt and tube systems are designed to work together:

• Belts and tubes of the same colour have the same throughput rate
• Belts and tubes are both uni-directional
• Tube towers come with a built-in belt
• Tube towers can be set to input from their belt, output, or both
• Belts are confined to the cardinal directions on the build grid
• Tubes can connect in any direction
• Tubes support 1:1 or N:1 connections

This mix leads to some interesting constructs.

Moving items on and off a main bus.

Tube fan-in or fan out.

Boosting belt throughput with a tube set to output-to-belt, or alleviating congestion with input-from-belt. Effectively a double-decker belt.

Design Decisions

The design of belts that are accessed by arms/inserters/sorters introduces some limitations:

• It must be fast for arms to check whether a belt has an item in range.
• Messaging or wait-lists needed to allow arms to avoid polling belt entities.
• A data structure needs to balance fast sequential access every tick...
• ...with fast random access at any point along its length on any tick...
• ...with fast range access by a renderer retrieving visible items...
• ...with consideration of modern CPU cache and memory bottlenecks.

Basically the fewer methods you give the player for moving items on and off belts, the more optimisation opportunities there are in the code. Factorio is simply amazing in this regard -- they've achieved an order of magnitude larger bases than most other games while still offering the player huge flexibility on belt access and layout.

Factropy stores belts in vectors. No matter how long the belt it's essentially a contiguous array of entity belt components. The output end of the belt is at the beginning of the array so iteration is opposite to item travel direction, because front items have to move before back items can do so! If the player removes, rotates or places a belt entity, only affected belts -- those the entity touches -- are rebuilt and reallocated in memory as necessary. The performance bottleneck is how efficiently the belt tick code can access memory 60 times a second, and layout changes are infrequent by comparison.

Factropy stores the offset of the first active entity on each belt, where active means some sort of activity or interaction with another entity occurred last tick -- item added, item removed, first gap arrived, polling event occurred etc. On each tick only the entities after the first active entity need to be iterated and/or updated. The thinking is that belts spend a lot of time either:

• congested at the end and rarely moving, or
• starved at the end and moving steadily

It's rare for a player to have perfectly balanced throughput along the whole length of the belt (no, not even Nilaus!) so we optimise for those two states while keeping the simplicity of a single vector per belt.

Factorio goes one better and manages to update only the first gap on each belt segment, with later items on the segment taking their offsets relative to the update. One belt is potentially many segments, which breaks up the problem of updating too many entities each tick while still supporting relatively fast access for adjacent inserters. It isn't clear yet whether maintaining a belt as a list of segments is the next step for Factropy too, or if the added complexity of that approach can be offset by other design decisions.

For example Factropy tubes do not allow external access to items except at towers. They are, in effect, very long point-to-point single-lane belts consisting of a segment per pair of towers. They can be updated very cheaply compared to real belts. If a Factropy base uses tubes in place of long featureless belts to mining outposts then the performance equation changes.