Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

I have a number of friends who cannot consistently hit the highest speeds. We have been discussing and think that the current time simulation is going to have problems going forward. This patch note says that later content will require even higher acceleration.

Well if someone can't make 1,000 acceleration now, then the fact that it scales isn't going to help them when 5,000 acceleration is added. They'll be stuck at whatever the best their computer can handle is.

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.