I’m not going to go fully into the implementation details yet because I’m still working through them, but future higher speeds are not intended to come solely from asking the computer to brute-force more and more individual ticks.
The longer-term plan is safe simulation compression. For example, if you are cultivating and nothing is happening for a stretch except predictable cultivation gains, the game does not necessarily need to calculate every individual 400ms tick one at a time.
Instead it can determine how long that uninterrupted state remains valid and process a chunk of that time together. So rather than doing something like:
cultivate → tick → cultivate → tick → cultivate → tick...
thousands of times, it may be able to determine that the next meaningful change is several hundred ticks away and resolve those cultivation gains as a single calculated block.
The size of that block would be variable. If nothing can interrupt you for a long time it can be large. If you are approaching an event, resource limit, age threshold, decision, combat, death, or anything else that can change the result, it would shrink the chunk or return to individual simulation before reaching that point.
Combat and other state-heavy situations are a good example of where this cannot simply be done blindly. Those still need much finer simulation because what happens on one tick can change what should happen on the next.
The Worker changes in 1.1.4 are part of laying the groundwork for this, but they are not the whole solution. The eventual goal is that something like 5,000x does not mean the computer literally has to calculate five times as many full individual ticks as 1,000x. At sufficiently high speeds, part of the gain needs to come from calculating straightforward stretches more efficiently rather than just demanding increasingly faster hardware.
I’m still working out exactly which systems are safe to compress and where the simulation needs to remain granular, so none of those details are written in stone yet. Correctness comes first.