Alchemy Factory May Update Preview: Recipe Rebalance and Conveyor Belt Refactor

Hi everyone, D5 Copperhead here. Over the past few weeks, besides the recipe rebalance mentioned earlier, We've also carried out a major refactor of the underlying conveyor belt system, which is also why this month's update has been a bit delayed. I'd like to briefly share some details about these changes.

Recipe Rebalance:

In previous versions, advanced athanors had very low usage rates. To address this, we completely reworked all recipes for this device and introduced a new catalyst system. Players can now add different catalysts into advanced athanors to modify recipe results. This allows us to reduce the difficulty of basic recipes while giving players more options.

Cauldrons:

Cauldron recipes are generated procedurally, so some existing recipes may be affected after the rebalance. This mainly impacts certain reworked late-game recipes, such as Stardust. Early-game cauldron recipes like Clay and Coke are mostly unaffected.

Music:

We're also excited to share that Mikolai Stroinski, one of the composers of The Witcher 3: Wild Hunt, has composed a new theme track for the game. In addition, we've fully reworked the in-game BGM. Stay tuned.

Conveyor Belts:

This part gets a bit more technical. TL;DR: performance has been improved, and item movement on conveyor belts is now much more stable at high speeds.

Previously, we updated our conveyor belts in random orders. This approach had several advantages: the data structure was simple, players could freely place or delete conveyor belts without additional performance overhead, update tasks could be distributed directly across multiple threads, and workload balancing between threads was straightforward. We used this system for a long time, and it worked well when conveyor speeds were relatively low.

However, the downside of this approach was also quite obvious. Many players may have noticed that gaps between items start to widen once conveyor speeds become too high. This happens because unordered conveyor updates can only use data from the beginning of a key frame tick when moving items forward.

For example, imagine two items, A and B, located at positions A1 and B1 at the start of a key frame tick. Since updates are processed out of order, A and B are often simulated on different threads. When updating B, the system does not know whether A has already moved or where it has moved to, so B can only advance to position B2 based on the previous frame's data.

If A also moves during the same tick, for example from A1 to A2, a small gap will exist between A and B. The size of this gap is exactly equal to the distance an item travels during a key frame tick.

When conveyor speeds were low, these gaps were barely noticeable. However, as conveyor speeds increased, the gap size grew quadratically, far beyond our original expectations. To mitigate this issue, we previously reduced the conveyor key frame interval to 0.05s (while devices still ran at 0.1s), which obviously came with a significant performance cost. At the same time, we found that even with a 0.05s tick interval, logistics throughput still became unstable once conveyor speeds exceeded 360 items/min.

Because of this, we decided to finally solve the problem at its core. The solution was to replace unordered updates with the sequential update model commonly used in other automation games. Conveyor belts are now updated starting from the end of the network (usually a device input), proceeding step by step backward the beginning of the network (usually a device output).

Since our conveyor belts can be freely split and merged, we decide to use a