Hi, we’d love to support the replay feature for our game, and thought Epic may be interested in our use cases and feedback.
Primary Use Cases:
- Allow players to view ongoing replay streams being broadcast on a time delay.
- Allow players to view old archived replay streams.
- Internally allow designers to review playtests.
- For debugging, have replay streams attached to bug reports to reproduce the issue.
For mass broadcasting, Epic has provided FHttpNetworkReplayStreamer, using web tech to scale this to 1000s of player is the way to go. Viewing archived streams is also straightforward, but it’s unlikely that we’d ever be able to support archives no longer compatible with the client.
For debugging, it’d be nice if the replay recording could gracefully handle an assert or crash and try its best to wrap up its business so that we get a usable replay to repro that crash.
Concerns:
- The replay stream does not record any client state. That means anything that occurs purely due to a client event may not happen in the playback. For example, a client only timer that changes the skybox, a client trigger that changes the music, or a client only ambient bug creature gets squished by a player. I get the feeling that for most games there will be several things like this.
- Time scrubbing is a testing nightmare. I don’t see it being feasible for us to harden all of our gameplay systems to function correctly when time is being scrubbed backwards or jumping to arbitrary points. We’ll likely just disable this. We’d still support pausing and time scaled playback.
- The observer of the replay may still have some sophisticated gameplay going on. For example, he may be chatting with other players, or browsing an in game store, or maybe he gets item drops for viewing a replay. It’s not clear how easy it’ll be to keep this game state separate from the replay. Perhaps the replay could take place in a separate UWorld? That may not be right, but it feels like it’d we want some sort of sand box to delineate actors that should not be touched by the replay.
To keep the feature robust and easier to maintain, we’ll need a middle ground like:
- When a demorec begins, serialize the client state into a ClientArchive.
- During recording it is possible to save additional client state snapshots, controlled by the game logic.
- When demo playback begins, it loads a client snapshot to initialize any state not associated with replicated actors.
- When playing back a demo, you can only begin from a client state snapshot. You can play forward from a snapshot, pause, or adjust playback speed.
- You can jump to any snapshot.
- You cannot scrub backwards.