Replay Manager

[albertok]

Just wondering if there would be any interest in having a replay system built into Netfox. Were already collecting most of what's needed to replay a game session from start to end and it would certainly be a handy feature for both players and developers play testing.

MultiplayerSpawner / RPCs / MultiplayerSynchronizer actions outside of tick code will likely pose a challenge. We could add simple listeners like the logging example or simply declare that as out of scope but provide a way to "add actions" to a replay on a certain tick.

[elementbound]

That's a fun idea, with some interesting use cases! Aside from helping with playtesting, rewinding and traditional replays ( like Doom demos from back in the day ) come to mind.

For starters, I think the API could expose more of the state- and input captures - currently it's fully opaque, RollbackSynchronizer just applies the right state in the background. Adding some basic get/set/enumerate/apply methods to this would be feasible for v2 or even v1.x.

I could see the replay system as a separate addon, like netfox.noray, that can attach on to that extended API.

Granted, the only way I can see this working is if the game is built with networking/replay in mind from the start. So this wouldn't be something that you could just plop onto your single-player game without much hassle for example.

[albertok]

Makes sense to separate the addons by their intent. netfox.replay ?

I'll have a go at it soon and see if I can make a PR complete with implementation in Forest Brawler. That seems fairly straightforward to do as a tick only replay scenario.

I don't think too much needs to change for a v1 other than stream final ticks to a file and then have a reader that orchestrates a replay.

[elementbound]

Sounds good! I'd be happy to take a look at the PR!

You're right, it can be done pretty much with the current version too, it's just not that nice to access the data required.

Also, to be clear, this is something you plan to use in the near future too, right? I wouldn't want to have you develop something and have it end up without users.

[albertok]

Yep, current plan was to implement it in my own game for a few purposes.

Play testing auto uploads would be amazing feedback but I think the real value will come from letting players viraly market for you if it's super easy to share matches on social media, maybe even leverage the MovieWriter class in Godot so it can encode and upload directly to platforms.

[elementbound]

Thanks @albertok! I'm happy to help with any questions or (draft) PR reviews. Recording gameplay replays is an interesting idea, excited to see where this goes!

[TheYellowArchitect]

With the merge of #251 it is closer to be implemented.

What is required after the above PR:

• Expand History Limit #248 -> Serialized inputs have the same history limit as every other variable (default 64), so history limit must be split for each variable (_inputs, _states, _serialized_inputs, _serialized_states) instead of one variable dictating the history limit for all.
• Some variable(s) to hold the initial/first state, and the tick the player joined. This is a good opportunity to create the singleton explained in Changed RPC strings to static functions #241
• Some inputs are not within _inputs, yet they change the state. See NetworkWeapon.fire() is not within Inputs. #253