gschup / ggrs

GGRS is a reimagination of GGPO, enabling P2P rollback networking in Rust. Rollback to the future!

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Provide information about the confirmation state of a frame advance

shelbyd opened this issue · comments

Is your feature request related to a problem? Please describe.
For a better UX, I may only want to play effects when an event in my game won't be unwound due to being out of sync. For example, in my fighting game, I only want to play the hit sound effect when I have all inputs from all players and my hit has definitely landed.

Describe the solution you'd like
My best idea of the interface would be an additional enum in the GGRSRequest::AdvanceFrame variant. Likely something like the following:

enum FrameConfirmation {
  LocalPrediction,
  FullyConfirmed,
  PartiallyConfirmed(Vec<PlayerHandle>),
}

Where the PartiallyConfirmed case includes the set of players that we have inputs for. The PartiallyConfirmed case is unnecessary, but may support some use cases.

An additional consideration is that we would likely want to run additional loads/updates that we otherwise might not to ensure that every frame advance is called at least (ideally exactly) once with FrameConfirmation::FullyConfirmed. Because of this additional cost, we may want this to be opt-in.

Describe alternatives you've considered
Alternatively, GameInput could include data about being either confirmed from the remote player or predicted based on their previous inputs (I assume ggrs is doing this). Then one could likely know that a game state will never be invalidated by checking that all GameInputs are confirmed.

Thanks for the issue! P2PSession already has a getter to retrieve the last confirmed frame. I pushed a quick update and made P2PSession::confirmed_frame() public. Hope that helps!

In addition, I will consider putting that information someplace else, but I am not quite sure where it would be best.

Thanks for the quick response.

Adding confirmed_frame is the minimum necessary to support these use cases. And I think there's nothing that no longer possible.

We might consider an option or always guaranteeing that every frame advance will be called at least / exactly once with fully confirmed inputs. That would result in more frame advances, but not require the client code to speculatively hold on to events that may get fired once confirmed. But that does add complexity to the ggrs interface, so maybe not worth it. It also assumes that ggrs would not re-call frame advances where the prediction was completely correct (which I'm not sure about the current behavior).

I'll have some more feedback about what would be the nicest way to get this support once I reach implementing something that requires this feature in my game.

This functionality is now provided via InputStatus given with every AdvanceFrame request.