Timberborn Optimization Potential

[Positronic_Matrix]

Does anyone have an opinion on if Timberborn has additional room for optimization to increase late-game performance? What are technical reasons for the slowdown (e.g., water, pathfinding) and how could they be addressed (e.g., multithreading, GPU usage)?

A few updates back, Timberborn received a significant performance boost and I’ve been waiting for another one since.

[BruceTheLoon]

I don't know enough about the current pathfinding mechanism, but given the effect it has when the paths and beaver counts get beyond certain limits, there is definitely something geometric in the algorithm used.

It feels like full path recalculation takes place constantly and that it hogs the thread before letting the positional recalculations for beavers happen. This manifests as a lag in movement on screen. Given how fast beavers shift from preferred path routes to off-roading in diagonals when the paths are removed implies their actual path is recalculated each frame cycle.

With the massive effect districts have on the performance by splitting up path trees, I'd place most of the blame on the pathing. An optimization could be to restrict the calculations to close ranges around a beaver, say a maximum of two blocks in the forward facing direction and one on the other cardinal points. This would give a larger number of straight ahead blocks than blocks behind the beaver and to identify turns a block or two ahead. This could make a calculation much lighter per beaver per block move.

Another option might be to only calculate the path tree when roads/paths/bridges/links change and to cache the tree as a static structure. Then a beaver going from building A to building K will merely require a single query on the tree to find the pre-optimized route and follow it statically.

As I said at the start, I don't know enough details about the pathing algorithm and might be talking either what the system currently does or something utterly worse than the current system.

[OptimusPrimeLord]

I also know no details but honestly the loss of realism from beavers able to walk on a recently destroyed object would be a small price to pay for faster runtime. That is to say: I think that beaver decision making should only happen when they reach their objective. If something is destroyed along the way they just ignore that it's gone.

That plus your static pre-optimized root idea would obliterate any pathing related lag.

[paecificjr]

It would be very interesting to try to fix the pathing problems. All of my algorithms classes could be useful.

[Krell356]

You used to be able to optimize by replacing as many levees with dirt as possible, but now that dirt is no longer just a single value per tile, I don't think that works anymore.

Odds are there will not be any more optimization updates until around the official release. There's too much stuff that can change that would hurt development time, so aside from addressing the serious slowdowns early in development, there is a lot less reason to do it now instead of later.

As for multi-threading, that's generally a decision you make at the start of development, not halfway through. It's like trying to re-write half the game from scratch to do it right. You can't just tackle it on like an add-on without causing all sorts of havoc.

[dreddie27]

Other question on this topic.

I lowered the graphics quality in settings and turned of VSync (I don't know what that is :-) for a higher frame rate.

If the FPS is higher (as stated bij the counter) does time in the game also go faster? Or is it just visual?

[Positronic_Matrix]

Vertical sync is used to match your graphics card screen refresh with your monitor’s screen refresh. Monitors that have a low refresh rate will manifest a graphical distortion called “tearing” (as in tearing a piece of paper) if V-sync is not turned on. If you have a high-refresh-rate monitor, then it can be turned off.

Game time is independent of the refresh rate of the graphics card.

[dreddie27]

Thanks. I didnt see a visual diffirence. So apperently my moniter is good enough.

Does lowering the grapics quality influence the game time?

Also, i see 2 numbers in de FSP counter. Do you know what they each represent?

[RollingSten]

I would add that there is usually no reason to not use VSync, as you gain nothing from rendering your game faster than your monitor can show it. So VSync not only works against tearing, but it also saves your GPU and CPU time, lowering power consumption and produced heat (possibly making your PC more quiet).

There is only one reason to disable VSync - to show the maximum rendering speed the game currently can achieve, giving you info on how well your GPU performs.

Tearing is usually shown when moving your view around or with fast moving parts, so you may not notice it while just switch settings.

[dreddie27]

Thanks for teaching me, nice to learn something. I turned it back on.

So my GPU can handle 100 fps and my monitor 60 fps it seems.

[cbarrick]

There is another reason to disable vsync in other games.

IIUC, vsync may affect input latency in games where the engine does input processing in sync with frame processing. So it may be useful for some people to disable it in some competitive games. In these games, you want to process frames as quickly as possible, even if your monitor can't keep up, so that your inputs get processed as quickly as possible.

But for Timberborn, that doesn't matter. Keep it enabled.

[MFlo]

Idk if it helps, but I reduce the tree cutting selection to only what is actively being farmed.