4. Requests and Events

Handling Requests

If calling advance_frame() succeeds, GGRS will return a Vec<GGRSRequest>. Handling requests is mandatory. This sequence of requests is order-sensitive! You need to fulfill all requests in order. There are three types of requests: AdvanceFrame, LoadGameState and SaveGameState. Please see 👉BoxGame for a full code example. Note that it is not necessary to use the provided GameStateCell. You can easily create your own save state system, using the requests to tell you which frame to load and when to save.

AdvanceFrame

/// You should advance the gamestate with the `inputs` provided to you.
/// Disconnected players are indicated by having `NULL_FRAME` instead of the correct current frame in their input.
GGRSRequest::AdvanceFrame {
    /// Contains inputs and input status for each player.
    inputs: Vec<(T::Input, InputStatus)>,
}

Advance the frame with the provided inputs.

LoadGameState

/// You should load the gamestate in the `cell` provided to you. 
/// The given 'frame' is a sanity check: The gamestate you load should be from that frame.
GGRSRequest::LoadGameState {
    /// Use `cell.load()` to load your state.
    cell: GameStateCell<T::State>,
    /// The given `frame` is a sanity check: The gamestate you load is from that frame.
    frame: Frame,
},

SaveGameState

/// You should save the current gamestate in the `cell` provided to you. 
/// The given `frame` is a sanity check: The gamestate you save should be from that frame.
GGRSRequest::SaveGameState {
    /// Use `cell.save(...)` to save your state.
    cell: GameStateCell<T::State>,
    /// The given `frame` is a sanity check: The gamestate you save should be from that frame.
    frame: Frame,
}

Handling Events

Events are notifications from the session for the user. It is recommended to fetch events after every update. Most events are simply of informative nature, requiring no special action from the user. Please see the examples or refer to the documentation what kind of GGRSEvent can occur.

One exception to this is the WaitRecommendation event, which GGRS gives out when your local clients runs too far ahead of remote clients, leading to a lot of one-sided rollbacks on your end. A simple way to mitigate this discrepancy by skipping the indicated amount of frames. More elaborate means to synchronize the clients are described in the associated section.