I have been playing a lot of Factorio and Satisfactory and was trying to replicate a simple version in Unity. Nothing too fancy just a few belts and machine moving thing around.

Does anyone have any insight on how they track and update the insane number of objects moving around at any given time?

Thanks

Likely they don't.

Everything at a belt moves with the same speed, so you can see the belt as a whole as a game element that has a number of boxes to draw. To draw, you only need the time that the box entered the belt (or probably better, when it will leave again), and the current time, and then you can compute the position at the belt where the box is supposed to be.

Since the belt is finite and fixed, you can use a round-robin list to store the times of the boxes at it.

Factorio's initial implementation I believe just saw regular item “entities” that move when on a belt tile. The expensive bit is each item must perform a collision check to see if the belt is backed up and it should stop moving.

They have spoken against ECS many times, my understanding is they have specific containers for each type (like a List<ItemEntity>).

This served them well for a long time, it is only really mega bases that are too much, where multiple rockets per minute or people using belts where trains were intended. The belt optimisation is more recent, my understanding is they combine a continuous series of belts into an “entity” which then stores the list of items on it with an “offset” distance since the start. It can then easily move all those items, maintaining a minimum distance between them.

I can't think of a similar Unity example I spent much time looking at. Terratech has belts, but it only takes very little to get poor performance.

EDIT: A positional offset is largely equivalent to the time @alberth suggested, and can be implemented probably either way (while following freely, given time, speed and offset, you could compute the other). The reason I think offset position is it more gracefully handles start/stopping, without having to go in and “fix” all the values. Once items on the belt are backed up, with an offset position it can just stop updating them.

For the current implementation, if you check out the debug overlay, you can see this for example, showing the “gaps” items can move into.

And the "transport lines". I believe white are “inactive” lines that are not being updated at all because the items are fully packed already and the end is blocked.