Factorio and its optimisation

[POTTERMAN]

I hope this belongs in this category.

I recently took an assignment on my university regarding game development, specifically regarding optimisation in video games.
I was looking to write about Factorio, since there is a lot to talk about it in this context.

I already found Fiday Facts about the subject, notably #82, #117, #176, #204, #209, #281, #364 and the ones about porting the game on the Switch. The assignment is coming along nicely so far.

Do any of you have any other knowledge when it comes to how optimised Factorio is, from the side of game development curiosities or anegdotes/stories?

[Rseding91]

What kind of information are you looking for?

[bombasticjoe]

Well Factorio is written in C++. I don't have a lot of knowledge about coding/languages but C++ can (probably (to my knowledge)) access machine code directly.
That's (probably) why it can run on a potato. ( https://www.codingame.com/blog/which-is ... -versus-c/ )
Factorio is (probably) so fast because of C++. It doesn't have a middleman (translation) to slow it down (JVM).

A (probably) good place to start is it's code language.


(take my word with a grain of salt though - I don't have any coding experience to give good advice.)

[FuryoftheStars]

Well Factorio is written in C++. I don't have a lot of knowledge about coding/languages but C++ can (probably (to my knowledge)) access machine code directly.
That's (probably) why it can run on a potato. ( https://www.codingame.com/blog/which-is ... -versus-c/ )
Factorio is (probably) so fast because of C++. It doesn't have a middleman (translation) to slow it down (JVM).

A (probably) good place to start is it's code language.


(take my word with a grain of salt though - I don't have any coding experience to give good advice.)

I'm not an expert on the subject myself, but I feel like this isn't exactly correct.

I was doing a lot of research on the subject myself a while back to see if I ever decided to try creating a game that was more than a dumb simple thing, would the .NET language I know be enough, or would I need to learn C/C++. Of everything I was able to find and figure out, one of the responses to this reddit post sums it up nicely (I don't know how to link directly to a reddit response vs the OP, but I'll quote it below):

https://www.reddit.com/r/csharp/comment ... ared_to_c/

Language by itself can not be slower or faster. Technology used can be.

C and C++ are both compiled languages and they are compiled into machine code. CPU executes your code. So both of them have the same speed.

Basic (not vb.net), Python, JavaScript.. are not compiled languages. They are so called "interpreted language". They are never compiled to machine code. So they are slow since CPU executes interpreter and it in turn executes your code.

C# is a beast between. C# code is compiled to IL language. And then IL is compiled to machine code using JIT ( just-in-time). The very first .NET runtime hits the code, it compiles IL to machine code. So fist time method execution will be slower and subsequent execution will be as fast as C or C++.

BUT C# has more features and guards/protection. For example "out of boundaries" guard. You can not go outside of your array. It takes some CPU time to do the check every time you access element in array. Implement this feature in C or C++ and your code will be as slow as C#. C just allows your to "behave" bad by default.

With all that said you can skip all those checks. Just use "unsafe" keyword. And you will get same performance as C or C++. C# compiler will allow you to be "bad".

PS: JIT technology allows us to run our .NET code on different CPUs. 32 bit, 64 bit, ARM...

[Stringweasel]

Programming languages are all just different tools. It's like comparing hammers with screwdrivers. Different pro's and cons depending on what you want to build a how you want to build it.

I think what was a way more decision in Factorio was their decision to build their own game-engine. They could have used some existing engines, like Unity for example. It might have sped up development time even. But rather they built their own one that can be built to fit their game perfectly. Using a different engine will most likely have resulted in a less performant game, because the engine can't easily be tweaked.

• The Factorio game-engine is built to keep track of 100000's of dumb things constantly, while existing game engines are normally built to keep track offf 100s of very complex things.
• The Factorio is built to draw 10000s of things on your screen 60 times a second while normal engines are built to 100s of things.
• Factorio engine are built to have 10000s of conveyer belts moving items, and 1000s of inserters. Other engines won't be able to do that XD
• Their engine are built to allow 10s (even 100s!) of players to play together in multiplayer building enormous Factories. This is possible because the Factorio engine is designed to be completely deterministic, which allows it to run in lock-step which allows this. I don't know if other games also do this, but their engine is built specifically to allow this, while existing engines would probably not be deterministic enough. You can read more about how that works in this Alt-F4 article, it's really quite cool.

Then second decision was the language IMO. IIRC the first version was even written in Java. But for their application C++ was a good tool to choose.

• C++ gives you very fine control of what's happening. C++ vs Python for example is like Factorio vs Satisfactory. The structures you can create in Factorio can be orders of magnitude more complex and optimized than structures in Satsfactory. This means they can tweak their C++ engine to do exactly what they want.
• The trade-off is that C++ is slow to develop and you need really good programmers (which they do). Because C++ is so customizable it's easy to build something wrong if you don't know what you're doing. And building an optimized engine that can run Factories this fast took a lot of time. For example, it took Wube 5 years of optimizing their engine to get this megabse from running at 7 UPS to 70 UPS. And of course, they put in the time investment, found brilliant C++ programmers, and tweaked their engine to what it is today.

I'm just some guy though so I might be wrong. As a programmer myself these are just the points that stand out to me, but it's often that there are more things behind-the-scenes that are easy to miss.

[POTTERMAN]

What kind of information are you looking for?

Mainly if you recall any "roadblocks" or particularly hard spots when it came to how game is optimised. And how was it overcame in the end (not going too much into detail as I don't want to expose your process or anything). Something akin to Friday Facts #176 but on a much smaller scale of course.

The topic of my presentation is about quaint/interesting methods to optimise games in general. I thought this would be a good candidate on a simple basis on how many objects can be simulated at the same time with seemingly no impact.

[JimBarracus]

Do any of you have any other knowledge when it comes to how optimised Factorio is, from the side of game development curiosities or anegdotes/stories?

Well its hard to measure how well this game is optimized.
Only way I could think of is a benchmark megabase.

But some changes make it difficult to compare the versions.
New features like nuclear or the science overhaul.

It also depends on the machine. Sometimes the cpu limits the performance, sometimes its RAM speed, or both.

[Daid]

Do any of you have any other knowledge when it comes to how optimised Factorio is, from the side of game development curiosities or anegdotes/stories?

I am an hobby game developer. I use C++. And, my code generally starts to see slowdowns when I got a few 10000 "objects" in a game. Or much less if complex physics are involved. At the same time, Factorio does millions of objects and doesn't even break a sweat. It's not just that factorio is made in C++, it's also that is optimized like crazy in C++.

One of my biggest projects (EmptyEpsilon, not linking, as not looking to advertise, but you can google) features multiplayer. Getting that to work and stable was a proud achievement. Learning about multiplayer in Factorio was like "that shouldn't be possible!" IMHO, the multiplayer of factorio is one of those impossible feats that they achieved. It required very careful planning and coding and some amazing programming skills to pull this off.

Long version short: I'm a C++ dev, and Factorio makes me humble.

[Tertius]

There are different levels of optimization. In my computer science study, I was told the significant performance driver is using the algorithm with the least amount of iterations for a given task. For example, the bubblesort algorithm needs vastly more iterations than the quicksort algorithm. So choosing algorithms that require the least amount of iterations (loops) is essential.

What is often ignored is the hardware capabilities, since this is what all abstraction and generalization tries to hide from you. An algorithm should be agnostic to the hardware it runs on.
However, among other things Factorio tries to exploit a certain hardware capability - the small areas of the recently accessed main memory that is cached, therefore extremely fast to access. It seems from dev posts that if you have a list of things to process in a loop, arranging this list as array in memory in a way that it fits within the memory caches, is a significant performance boost. Same algorithm, but used on data that is specifically arranged so it fits the cache. It doesn't demand everything has to be stored within an array[] with the programming language, it's only important to collect the relevant objects in a small part of the memory, so it might be a thing with the internal memory allocator. Or it might actually be beneficial to organize objects in real arrays, while arrays in higher programming languages are often not any more large parts of consecutive memory but instead organized in multiple chunks distributed all over the process memory space (but not fitting the cache).

If you try to speed optimize a program, look at the working set. These are the memory pages the program accesses continuously. It's usually only a small part of the whole allocated memory of the process. The smaller the working set, the more of it fits into the cache, so the better the performance.