Is 5 turns per second too many?

[Mercury]

Currently the default simulation turn length (DEFAULT_TURN_LENGTH) is 200ms. A higher number would reduce the number of turns per second and thus our total simulation load. For example setting 250ms would reduce simulation cost by 20%. The disadvantages I see are increased lag on input and between a unit finishing one task and beginning another. The input lag can be counteracted in multiplayer by reducing the number of turns commands are delayed(COMMAND_DELAY_MP). For example if COMMAND_DELAY_MP is reduced from 4 turns to 3 turns it would balance out increasing DEFAULT_TURN_LENGTH to 250ms. Single player COMMAND_DELAY is 1 so it can't be reduced. Would just have to accept the up to 50ms extra input lag here. I played a quick single player game and found both input lag and lag between queued tasks unnoticeable.

 

This patch:

https://code.wildfiregames.com/D4760

 

Implements these changes. Try it and see if it feels weird?

Edited August 14, 2022 by Mercury

[Feldfeld]

The turn length used to be 500ms before A24 or A25, and there was just as much if not more lag. The game was tested just before and just after the change to make sure of the lag impact.
It's safe to say turn length has a way smaller impact on lag, or at the very least it doesn't affect it linearly like you could expect.

@wraitiifor more details

[Mercury]

After being informed how things work, I'll revise my claims to a modest performance boost, maybe around 10%, and a reduction in network traffic around 10-18%, depending on player APM. Those things maybe worth 50ms in queued command lag / single player input lag.

500ms sounds like too much. The difference between 2 turns per second and 5 turns per second (300ms) is much more then between 5 and 4 (50ms).

Edited August 14, 2022 by Mercury

[Mercury]

Regarding lag being increased due to work piling up, my recent patch to the GC scheduling:
https://code.wildfiregames.com/D4758
should change the performance profile considerably by feeding all extra time in the simulation thread ( and sometimes more then that) into GC slice.

[wraitii]

I think if anything turns should be made shorter.

Average/total load is not the right metric: it's much better to spend 2 extra milliseconds on each frame (16 -> 18 remains smooth) than stopping for 20ms every 200 ms.

There are however other considerations:

• With shorter turns, we could potentially run some computations only on certain turns (this is tricky, but becomes possible. E.G. maybe we run short-range paths every two turns or something)
• With shorter turns, pathfinding behaves much better
• With shorter turns, there are generally fewer events per turn (the main source of 'stuff happening' are timers & range queries), so any individual turn tends to be faster. Note that I haven't actually done the math on this.

I think ideally we'd run turns every 50ms or so, with network delay in the 150ms range. This seems like what AoE 2 is able to achieve and it's very, very smooth.

[alre]

2 hours ago, wraitii said:

I think if anything turns should be made shorter.

Average/total load is not the right metric: it's much better to spend 2 extra milliseconds on each frame (16 -> 18 remains smooth) than stopping for 20ms every 200 ms.

There are however other considerations:

• With shorter turns, we could potentially run some computations only on certain turns (this is tricky, but becomes possible. E.G. maybe we run short-range paths every two turns or something)
• With shorter turns, pathfinding behaves much better
• With shorter turns, there are generally fewer events per turn (the main source of 'stuff happening' are timers & range queries), so any individual turn tends to be faster. Note that I haven't actually done the math on this.

I think ideally we'd run turns every 50ms or so, with network delay in the 150ms range. This seems like what AoE 2 is able to achieve and it's very, very smooth.

ideally very true. the problem is when more turns add slowdown to games that already last twice the simulation time.

[Mercury]

Ah I see now. I was under the impression that graphics and simulation ran in separate threads but have since learned otherwise. We should revisit this after that issue is resolved.

• Doing some expensive tasks only on every other turn is good but running them on turns where we have extra time to work with is better
• Repathing is probably the hard limit on what we can do here before things look off.
• There is some simulation overhead checking those timers and running those queries. I don't know how much either. Also some network overhead.

[hyperion]

Human reaction time is around 200ms, some gamer are even faster. 50ms with 150ms net delay sound like a very nice target indeed.

[wraitii]

15 hours ago, Mercury said:

Doing some expensive tasks only on every other turn is good but running them on turns where we have extra time to work with is better

Just keep in mind things need to be deterministic across players