How the hell? - TECHNICAL

[mperrdev]

Wondering how the hell they managed to optimize the thousands of items going across a belt at once, merging together, moving 30mph, not having collision issues at that high speeds and also how it keeps track of each item along the belt, and how they are put into memory and organized.

All I really think about when i play is "how the hell does this game even function..."

I know that the items on the belt only care about the item in front of it, so it functions sort of like a line of people. BUT this doesn't explain how high speeds don't fuck up the belt, and how they are told to move and its like as if the computer isn't even working to move them all. Also, how are 50,000 items stored in memory accurately and are loaded up perfectly on saves? especially since it doesn't really use a coordinate system to move the items from what I can see, since they move and blend naturally between the belts as well as when they move 30mph they would be changing belt coordinates too fast for things to keep up.

Just kinda wondering how it all works.

[Grimakar]

Do you have experience in programming?

[mperrdev]

Do you have experience in programming?

Yes in c# and c++, and lua (although lua isn't really programming...) But aside from languages (any idiot can learn some syntax and play around with code long enough to "learn it") I'd like to think I have a pretty good understanding of programming in general.

I've built a good 2/3 of a game engine including some opengl stuff and I understand how it kinda works, just don't really know how he managed to make it work so well. that many thousands of things moving in general is pretty difficult for a computer to handle along with the hundreds of other objects doing their thing at the same time.

I don't have experience with allegro but essentially it seems like a framework for some basic functionality every game needs to avoid wasting your time on working with that.

EDIT: This game's performance is utterly magnificent. This next update is supposed to make it even better by leaps and bounds. I would really enjoy if he sat down and wrote a pretty long (4-5 pages) just on the many technical aspects of the game, along with his development process and how he went about creating the internal pieces of the game (while avoiding game breaking bugs and exploits along the way for the most part)

[Grimakar]

I am just a normal person, but I have an idea how that thing with the items on a belt could work. The logic behind that could be some sort of grid just like a dynamic list/array. And the only information that will be remembered there would be an item ID. The program checks the position of a grid and loads the sprite of the fitting ID there. The moving algorithm checks, if the next position of the grid is empty, if yes move. If no, stay there.
And btw. I find it very fascinating as well.

[mperrdev]

I am just a normal person, but I have an idea how that thing with the items on a belt could work. The logic behind that could be some sort of grid just like a dynamic list/array. And the only information that will be remembered there would be an item ID. The program checks the position of a grid and loads the sprite of the fitting ID there. The moving algorithm checks, if the next position of the grid is empty, if yes move. If no, stay there.
And btw. I find it very fascinating as well.

The problem with positions in all this is every time you want it to move you have to update 8000 positions at once many many times a second.

I do not think it works this way for that reason. I don't think it cares about positions until you load or save, since you won't interact with that position data if you aren't picking items up and an inserter isn't there. I think it just moves the items forward until it hits something in front of it, then groups that item with the one it hit and everything that item is also touching, and moves it forward and so on. If an inserter needs an item it will keep casting on that position until a usable item appears there, then it will delete that item, make one appear in the arm, and then "insert" into the machine.

It might group items that are touching together and move them as a cohesive unit since there's no real way they can be separated unless by a splitter.
I also think he could perhaps optimize it further by changing the "bounding box" to something else, as i think when it checks for collisions it will check the sides too (might be wrong there? not sure)

EDIT: by moving items forward without position data I mean it really isn't caring about coordinates and more about the order and space in between. If an item is grouped it will index it as a group and appears as a parent/child system.

Just my guess :3 100% sure it doesn't work exactly like this, as things like this always are more complicated than they appear to be and require lots of work to create them

[daniel34]

You should check out the devs' blog, the Factorio Friday Facts:
https://www.factorio.com/blog

Every Friday they make a post about what they are working on currently, how planned features will work, and most interestingly (at least for me): how it is all implemented.

Before 0.12 items on belts were actual entities in the game world, which was very heavy on collision-checking and items could get stuck.
How items on belts move since 0.12: https://www.factorio.com/blog/post/fff-82
Optimizations planned for transport belts in 0.15: https://www.factorio.com/blog/post/fff-148
(Note: It says 0.14 in the FFF, but has been postponed to 0.15)

In the game you can also show a lot of debug info and overlays using the F4/F5/F6/F7 keys.

[mperrdev]

You should check out the devs' blog, the Factorio Friday Facts:
https://www.factorio.com/blog

Every Friday they make a post about what they are working on currently, how planned features will work, and most interestingly (at least for me): how it is all implemented.

Before 0.12 items on belts were actual entities in the game world, which was very heavy on collision-checking and items could get stuck.
How items on belts move since 0.12: https://www.factorio.com/blog/post/fff-82
Optimizations planned for transport belts in 0.15: https://www.factorio.com/blog/post/fff-148
(Note: It says 0.14 in the FFF, but has been postponed to 0.15)

In the game you can also show a lot of debug info and overlays using the F4/F5/F6/F7 keys.

I like his blog posts but imo he keeps it a bit too simple, when skipping over entire features a bit and simply saying "it works" a lot.

I didn't know about the debug keys though, very interested to look at that, thank you!

[ssilk]

I updated lately this article: https://wiki.factorio.com/Transport_belts/Physics

The important part is after here https://wiki.factorio.com/Transport_bel ... s_yourself

[Grimakar]

The problem with positions in all this is every time you want it to move you have to update 8000 positions at once many many times a second.

Do not underestimate the power of your CPU. As you can read in the posted links (Thanks btw ) they use a rail system. Half a year ago I experimented with something similar, something with pointers and chains. So there are only two information that need to be remembered:
-the item type ID (Not for every item, but for every item type, so eg every iron ore has the same ID)
-the next position, which is some sort of address

So you make a simple array with these two variables. Then you can move along, by just reading the variable with the next position and jump there. If you add a belt, then you allocate new memory with more of that arrays. So all you need is the information where belts begin respectively ends, that depends on where you start to check the belts. I would begin at the end of a belt, because if the item in front is moved first, it clears the position and the next item can move up in the same tick and by tick I mean loop.

Because you make a loop, maybe a "do while"
There you let the items move by checking, if the next position is free. At this point you still do not see anything, it is just updating a database in the background. After all belts have been checked and the items repositioned, you let a function like "UpdateScreen" update what you actually see.

In another link they said something about a "virtual position", if I remember correctly.
I am pretty sure, that this is because they want the items to be moved smoothly.
They said something about 9 virtual positions. So if an item has the size of 9 virtual positions, you have to check the next 9 positions in the chain/rail, if there is another item before putting it there. When the actual item is moving, you check only the next position and if it is free, overwrite the one end of the array with the item ID 0, which means there is nothing now and the new nineth position gets the item ID of our iron ore. That way every item always has nine positions marked with its item ID.
If you do that consequently, the "UpdateScreen" firstly must check every position for items, but if it finds an item, I can jump over the next eight positions, because there can never be something else than this one item just found.

Hope I wasn't too complicated
But that would be the first approach as I would test it. And of course if there are 20 thousand items, you have to read over every of that. But the thing is, you do it by reading over the belts and there are much less and checking them will be done very quick by your CPU, no matter if there are 20 or 20 thousand items on it. Just try it yourself. Make some arrays, let them loop and add a timer to your program.

What you said about grouping items, would be an optimization as a next step. But the problem is you need an extra algorithm for the group handling, just like setting and disassembling those groups. First you have to develop it and if you win much by doing so, must be tested.