>>5829547
Why?
During Lockdown this spring we played 3 month Pyanodons in Multiplayer. Then we hit the Performance limit and UPS dropped below 60. CPU was never used more than 20% so I looked the official forums if there are plans to Multithread it. The deveopers said “not possible” because it is memory bandwidth limited. I couldn’t believe this so I started to write my own Factorio client.

Implementation:
I spend 4 Month during summer to reimplement the Factorio Engine. This is simpler as you might would think, because the basegame is shipped in sourcecode like all mods (LUA) and all resources (Images, Sounds) are also available. Total sourcecode is as today 276.660 Lines of c++ code, where I need to write only 44.385 LOC – rest is librarys and generated code. It all was more or less straight forward, nothing really fancy here. Lots of FFF helped finding out details.

The Base (Screenshots):
We play fully belt based Pyanodons. No logistic robots. But to help keep track with this 2500 different Items, we use Belt-Box-Mod. Every item can be converted to a Box with label and is then transferred via belt to the right recipient where it is unpacked. We handle Fluids with barrels.

Result:
We play this implementation now for 6 Weeks in Multiplayer, and reached science pack 3 in Pyanodons. This is about half the base size of our game in spring. Update time is currently about 2.5ms / Tick Multithreaded. With Threading disabled update time is about 8.5ms. So Multithreading on a 4 Core 8 Threads CPU (i7-4790K) makes things about 3.5 times faster. This is good result and about to be expected from Multithreading stuff (You never can reach exactly core count as speedup because of synchronisation overhead). I can confirm – my Factorio implementation is not memory bandwidth limited, it is memory latency limited. And therefore easy and efficient to multithread.

But because of the memory bandwidth “warning” from the developers, I tried to keep all objects as small as possible from the beginning. Example is the most used “Item on Belt” Object. Currently there are around 413.000 of them on the screenshots, where about 10.000 need to be updated per tick. Normally you would implement the “What type of object is this” with a pointer to its Prototype what would be 8 Bytes (64 Bit) alone. But I use a 2 Byte ID for this. 2 Bytes more for the position of the object. And for the Question “which type of item should be displayed, if there are multiple images of the item” I just use the memory storage address of this object as a stable (random) identifier. Therefore this object has only 4 Bytes. So only 1.6MB for all 413.000 Items on Belts. And only 40KB to update per Tick – this could even easily fit into CPU cache of my old CPU.

Unfortunately I now stuck what to do with this client.
Of course I still work on some parts and still have fun extending and optimizing it.
But developers made clear that they are not interested in multithreading Factorio.
I also cannot release it for obvious copyright problems which I will always fully respect.
As a side notice – all Multiplayer participants have a legal bought steam copy of the game.

I just can encourage you – write your own Multithreaded client, it’s easier as expected and a lot of fun! Even more fun than playing it ;). Any questions? Any special screenshots you want to see?

FAQ:

You may notice the missing power poles:
Currently all items are automatically connect to one electric network. We tailered the game what makes fun for us and what not. Building always the same powerpoles does not add benefit imho.

Is this working with Vanilla:
Of course. Pyanodons use much more features as the vanilla game does. We also played 4 completed Multiplayer vanilla runs with this during development until Py works well enough.

You have a Misspelling in the Sourcecode “Wroking”… instead of “Working”
Tnx – noticed in the screenshot J.