Refactor to allow users to trigger capture/playback as-needed

[snendev]

What problem does this solve?

Right now, both the playback plugin and the capture plugin assume that they are only used in contexts that only execute playback or capture. This is pretty limiting: it does not allow e.g. pressing an editor button to initiate capture or playback, or live playback/capture game modes such as those implemented in modern "traditional fighter" games.

I considered going ahead and writing the PR for this, to have the discussion directly on the code, but I opted not to since there are a few possible APIs to provide and I am unsure that my preferred solution is everyone's.

What solution would you like?

Systems should only run capture/playback behavior when the user requests some capture/playback action. Then, systems can be configured to run conditionally using resource_added, resource_exists, and on_event. I suggest providing an Event-based API, whereby users send events that trigger internal systems to insert the appropriate resources, but there are several reasonable variations on this.

Just to briefly recount the resources currently attached by this crate:

Common:

• PlaybackFilePath
• TimestampedInputs
• FrameCount (but this should be replaced by Bevy's equivalent feature)

Capture:

• InputModesCaptured

Playback:

• PlaybackStrategy
• PlaybackProgress

Notably, no sub-combination of these resources needs to be available except when capture/playback are triggered. Additionally, only PlaybackFilePath, InputModesCaptured, and PlaybackStrategy need to be defined by the user, since the rest could be managed by internal systems.

I suggest defining two user-triggered Events with properties for PlaybackFilePath and each of InputModesCaptured (and an optional total FrameCount to capture) or PlaybackStrategy. This Event could be detected to insert and manage all the relevant Resources until playback is complete. (Some CaptureEnd event will also be necessary unless a total frame count is required.)

Equivalently, the user could insert the underlying properties of this suggested Event type as Resources themselves. However, this has the downside that users must insert/mutate multiple things to achieve one action. This provides unnecessary failure modes, e.g. allowing users to insert too-few of the required resources for playback.

The above also makes something of a case for joining the "request" Resources into larger structs, which would also imply an ideal candidate for the resource_exists run condition. The downside to the suggested Event-based approach is that the choice of which Resource(s) will act as the run_condition trigger seems somewhat arbitrary. But I mildly prefer the Event-based approach.

I'd be happy to implement any variation on this, just let me know.

Related work

I've made a prototype of this in geppetto which I used for a custom editor panel, and I would later like to replicate that in a new crate on top of this if possible. That work may also want additional enhancements, such as adding filters to the input capture to only capture specific windows, so I will have future suggestions here as well.

[alice-i-cecile]

That sounds lovely! Sorry for the delay, this got stuck in my "complex review backlog", for days where I have spare brain capacity. Given that this crate doesn't have a ton of active users currently, now is a great time to refactor it become more flexible.

[snendev]

Great. No problem, also; I know you have a lot of responsibilities to keep track of, and like you said, this crate has relatively low usage.

I'll be submitting a (probably draft) PR soon that should implement everything covered here; feel free to treat it like a proposal and let me know what you are/aren't interested in including.

[alice-i-cecile]

Awesome, I look forward to seeing it.