#Looking for performance/design insight for a factorio-esque game

5 messages · Page 1 of 1 (latest)

livid pawn
#

Hey, I am making a factorio-esque game, and I'm wondering about my approach for rendering the many items that will be on conveyor belts.
Rn i'm split in between two ideas, but i'm sure there are other ways:

Idea A: Conveyor belts etc manage the items's data internally and then every frame they all write to a resource that has a big vec with all the positions, (sprite/mesh) types etc.. that draws all the items with instantiation. That vec is cleared every frame to be filled again.

Idea B: Each items has it's own enttity/transform/(sprite or mesh) and conveyor belts and the likes just act on them. They will get batch instantiated anyway with how bevy handles it by default.

I'm split between 2D/3D (leaning more on 3D) but it shouldn't matter for this topic.

Which solutions do you think would yield better performance and which would you recommend ?

I'm kinda scared that one entity per item would be slow when you have thousands of them in the world, but I don't have the experience to know for sure.
Also, solution B would make object to object interactions depend on the actual item's transform positions so it would be more costful for example to check if a conveyor belt has an item on it's than if that was just data.

frank vine
#

IIRC, factorio would be closer to B. Each item on a conveyor belt is an entity with a sprite transform and collider, but they are smart about it.

Instead of trying to collide with everything they are "on rails" and only check the distance of the next item.

Most entities are always "offline" by default. An inserter is not checking for possible items to grab every frame, instead it is asleep and it's awaken by other entities. For example, an inserter taking items from an empty chest is offline, when an item is added to the chest, the chest itself wakes up the inserter. This can also be applied to conveyor belt->inserter and inserter->assembly. This also kinda works the same for resources in a full belt. If they can't move they turn "off" and will only move when the resource in front of them wakes them up to move again.

The game is essentially a big "wake up" chain.

Pathfinding (biters and bots) is shared so it only runs once for a group and change to a dumb fast algorithm when it is close to the goal (this is why they all seem to move together towards the same point and split near the goal), train paths are cached ahead of time, etc..

livid pawn
frank vine
#

If you think it might be interesting, go for it.

Personally, i would stay away because it leads to madness and i am skeptical of the performance benefits.

#

In the end, if you think about it, for every 50 belts only one might be a "smart belt" that needs to know what it is carrying (next to inserters, splitters, etc..), keeping track of every belt item sounds more expensive doesn't it?
Resources don't even need to know what belt they are on, only "am i on a belt", "do i have space in front of me" and "what is my path". They aren't even aware they are on a splitter, their path and "next item pointer" will change and move on like nothing happened.