Issues

If an input has a side-effect (e.g. starts an animation; schedules an event; etc.), then that side-effect needs to be able to be rolled back during a replay scenario

xaroth8088/NetworkStateManager#38 · opened

on Jul 18, 2024

1

Saw an instance on a shoddy network connection where the client requested a heavy, the server saw the client request it, but the client itself didn't (!), which led to a desync

xaroth8088/NetworkStateManager#37 · opened

on Jul 15, 2024

Race condition

xaroth8088/NetworkStateManager#36 · opened

on Jul 2, 2024

In GameStateManager::ReplayDueToEvents(), we can skip the replay entirely if the events we're receiving are identical to the ones we're replacing (over the affected time frame)

xaroth8088/NetworkStateManager#35 · opened

on Jul 1, 2024

RPCs should be stashed when received instead of acted on immediately, and then processed in bulk in the frame

xaroth8088/NetworkStateManager#34 · opened

on May 31, 2024

In SyncToServerState, if the state is in the future AND there are no events in-between now and the target, we can safely skip the first TimeTravelToEndOf() and directly apply the server state to the scene & jump the game time there

xaroth8088/NetworkStateManager#33 · opened

on May 31, 2024

In SyncToServerState(), if the server's frame is exactly the same as our frame in that spot and there's no changes to the events, then we don't need to replay at all

xaroth8088/NetworkStateManager#32 · opened

on May 31, 2024

Unit tests (first pass)

xaroth8088/NetworkStateManager#31 · opened

on May 21, 2024

Maybe make a component that uses reflection to see what other properties are on the component, and which can be used to auto-collect gamestate information

xaroth8088/NetworkStateManager#30 · opened

on Apr 21, 2024

The host can collect multiple inputs from clients before acting on them

xaroth8088/NetworkStateManager#28 · opened

on Apr 17, 2024

Abstract VerboseLog() into its own thing, use everywhere

xaroth8088/NetworkStateManager#26 · opened

on Apr 16, 2024

figure out what to do if the initial game state never arrives to the client

xaroth8088/NetworkStateManager#25 · opened

on Apr 16, 2024

Figure out the right behavior for NetworkStateManager when it receives an RPC before it's ready to process them

xaroth8088/NetworkStateManager#24 · opened

on Apr 16, 2024

1

In NetworkStateManager::ClientFixedUpdate(), figure out what we want to do when the client hasn't heard from the server in too long

xaroth8088/NetworkStateManager#23 · opened

on Apr 16, 2024

On the server, instead of immediately forwarding player inputs maybe gather up all incoming inputs over some span of time and then send them in batches, to reduce RPC calls

xaroth8088/NetworkStateManager#22 · opened

on Apr 16, 2024

In NetworkStateManager::SetPlayerInputsServerRpc(), exclude the client that sent its input to the server, since they've already got it

xaroth8088/NetworkStateManager#21 · opened

on Apr 16, 2024

prevent a client from sending input for a player they shouldn't be sending input for

xaroth8088/NetworkStateManager#20 · opened

on Apr 16, 2024

In NetworkStateManager::HostFixedUpdate(), there's an opportunity to be slightly more aggressive by skipping sending anything if the entire state frame is exactly the same (except for the realGameTick, of course).

xaroth8088/NetworkStateManager#19 · opened

on Apr 16, 2024

In NetworkStateManager::HostFixedUpdate(), if we're sending a frame update AND sending inputs, we can consolidate those into a single RPC instead of doing two of them

xaroth8088/NetworkStateManager#18 · opened

on Apr 16, 2024

If NetworkManager isn't ready yet, we should throw an error and refuse to start up.

xaroth8088/NetworkStateManager#17 · opened

on Apr 16, 2024

calling NetworkStateManager::PredictInputForPlayer() is an awkward thing to ask implementers to do; see if this can be improved

xaroth8088/NetworkStateManager#16 · opened

on Apr 16, 2024

If an event is being de-scheduled during a rollback when processing a client's input data, do the clients need to know about the de-scheduling?

xaroth8088/NetworkStateManager#15 · opened

on Apr 16, 2024

add documentation about the hows and whys on the custom Random handling

xaroth8088/NetworkStateManager#14 · opened

on Apr 16, 2024

some sort of configurable amount of player inputs into the past that we'll hang onto, to conserve runtime memory

xaroth8088/NetworkStateManager#13 · opened

on Apr 16, 2024

the server can maybe calculate a diff for the events buffer whenever something happens to make it change, and only send over those (instead of the whole history each time)

xaroth8088/NetworkStateManager#12 · opened

on Apr 16, 2024

Navigation Menu

Repository navigation

Issues

If an input has a side-effect (e.g. starts an animation; schedules an event; etc.), then that side-effect needs to be able to be rolled back during a replay scenario

Saw an instance on a shoddy network connection where the client requested a heavy, the server saw the client request it, but the client itself didn't (!), which led to a desync

Race condition

In GameStateManager::ReplayDueToEvents(), we can skip the replay entirely if the events we're receiving are identical to the ones we're replacing (over the affected time frame)

RPCs should be stashed when received instead of acted on immediately, and then processed in bulk in the frame

In SyncToServerState, if the state is in the future AND there are no events in-between now and the target, we can safely skip the first TimeTravelToEndOf() and directly apply the server state to the scene & jump the game time there

In SyncToServerState(), if the server's frame is exactly the same as our frame in that spot and there's no changes to the events, then we don't need to replay at all

Unit tests (first pass)

Maybe make a component that uses reflection to see what other properties are on the component, and which can be used to auto-collect gamestate information

The host can collect multiple inputs from clients before acting on them

Abstract VerboseLog() into its own thing, use everywhere

figure out what to do if the initial game state never arrives to the client

Figure out the right behavior for NetworkStateManager when it receives an RPC before it's ready to process them

In NetworkStateManager::ClientFixedUpdate(), figure out what we want to do when the client hasn't heard from the server in too long

On the server, instead of immediately forwarding player inputs maybe gather up all incoming inputs over some span of time and then send them in batches, to reduce RPC calls

In NetworkStateManager::SetPlayerInputsServerRpc(), exclude the client that sent its input to the server, since they've already got it

prevent a client from sending input for a player they shouldn't be sending input for

In NetworkStateManager::HostFixedUpdate(), there's an opportunity to be slightly more aggressive by skipping sending anything if the entire state frame is exactly the same (except for the realGameTick, of course).

In NetworkStateManager::HostFixedUpdate(), if we're sending a frame update AND sending inputs, we can consolidate those into a single RPC instead of doing two of them

If NetworkManager isn't ready yet, we should throw an error and refuse to start up.

calling NetworkStateManager::PredictInputForPlayer() is an awkward thing to ask implementers to do; see if this can be improved

If an event is being de-scheduled during a rollback when processing a client's input data, do the clients need to know about the de-scheduling?

add documentation about the hows and whys on the custom Random handling

some sort of configurable amount of player inputs into the past that we'll hang onto, to conserve runtime memory

the server can maybe calculate a diff for the events buffer whenever something happens to make it change, and only send over those (instead of the whole history each time)