2 – Dactorio: Optimizations – Trying to make the goal of having 40k items in mobile work

So these two weeks (plus one extra week where I couldn’t do anything, not even write this post) I’ve been trying to make the belts as optimized as possible. I knew that my system would never be as optimized and great as Factorio’s system, because of number of reasons ranging from me being not as competent as their developers, not working on this full time, and not writing this is C++. So I opened up my medium sized factory and looked how many items were circulating through. I saw that only Iron made up about 40k items, so I set that as my goal to make it work on mobile.

I had some planned tricks to make it work, and they worked to varying degrees…

After watching some videos about Unity’s fancy new Data Driven Design implementation that is ECS (or DOTS, or Jobs, they all sort of come bundled together) I had high hopes. I did some testing to get a feel about how it works and integrated it to my project.

And the promises were true! ECS left me at a state were I could easily have tens of thousands of entities moving about, with my bottlenecks being actual position change logic (or belt slot update logic for the real thing) and rendering limits. Although ECS really does make the code have a lot more overhead, it is worth for the benefits.

I changed my ECS code some bunch to emulate what I am doing with the belt system, and did a stress test. I first calculated a benchmark for maximum amount of items I would like to process and render at the same time. I wanted my game ‘worlds’ to be about 6 times the size of Factory Idle’s world, which is 18000 blocks. After assuming some belt/other stuff and how much things will be on one belt on average, I arrived at 40000 items moving about in a world at a time, while 7500 being rendered at the same time. Then I did a stress test with 40000 items. The results were both promising and problematic:

As you can see, ECS can easily handle the vector movements and rendering of 40000 items! Also you can see the terrible spikes that are caused by my location update logic, that doesn’t use DOTS because it needs references with my current method

My next step will be to implement ECS with my other actual belt logic which is a lot more efficient than this dummy location update logic. Hopefully that will work and won’t be spiky like this. I have some strategies to draw out the belt update logic to multiple frames. If that achieves at least manageable performance I will happily move on.

Maybe I will even implement Factorio’s system in the future.