Open LikeLakers2 opened 3 years ago
For reference, this sounds similar to what I've presented in https://github.com/godotengine/godot/issues/16793#issuecomment-457845781 (at least the recording part).
Some Godot fellows also work on networked sync (this definitely has some overlap): godotengine/godot#37200.
Hi! I've had this idea sitting in my Notepad for a while, and I'm not sure what to do with it.
This idea is the ValueRecorder, which will record the values of all its sources every time a
update()
method is called on it. I've also included aAutoValueRecorder
node as part of this suggestion, which would handle a common (and easy to implement) use case of recording sources every frame.Below is a sort of summary of what I wrote down in my notes -- what I would consider my ideal ValueRecorder to be. There's no obligation to implement it exactly as I describe it, though.
Apologies for the long post, by the way -- I had a lot on my Notepad, and thought I might as well share what ideas I have for it already.
ValueRecorder
Every time a
update()
method is called on ValueRecorder, this takes in a number of sources (whether properties or methods) and keeps a record of the last so many values. A program can then access this record later and perform various actions based upon them.Potential use cases
Recording a drawing being drawn -- record what new and changed pixels exist every time we paint onto a canvas -- then be able to play it back without any pauses between actions.
Making trails behind a character -- this could easily be implemented by other means, but if you have a ValueRecorder, it will handle tracking of the positions for you.
Potential API for ValueRecorder
Multiple sources --
add_source(target: Object, property: NodePath)
for recording properties, andadd_source_method(target: Object, method: String)
for recording the result of a method (or for when a property just wouldn't make sense) -- and the relevant methods for removing sources.add_source_method
returnsnil
, we could avoid recording that source for that update (though all other sources would still record as normal).recorder_length
-- how many of the lastn
records that will be kept... perhapsnil
will infinitely record the sources?Potentially, a signal for whenever we hit
recorder_length
number of records -- this might allow us to... say, dump to disk the inputs we currently have recorded, such that we aren't doing IO every frame.Potentially, a means to save and load the recorded data -- or perhaps serialize it into an Animation for use in an AnimationPlayer?
AutoValueRecorder (Node)
This would be a utility node that automatically calls
update()
on an internal ValueRecorder every frame. I'm suggesting this simply because I think the use case of recording data on every frame would be a common use case for ValueRecorder, and so it'd just be easier to include a Node that does this for you.Potentially, instead of always recording every frame, a AutoValueRecorder could have some sort of
interval
property, where it will only record values every so often rather than every frame.Potential use cases
A input buffer -- Keep track of every input within the last 30 or so frames, and if a jump action occurs just before the player hits the ground, you can repeat the jump (even if the player was not pushing "jump" right as they hit the ground)
Replay recording -- Keep track of the player's actions as they play through a level -- then allow them to save a replay at the end of the level, that can later be played back.
Statistics over time -- for example, the ValueRecorder could be used to implement a graph that displays FPS over the last 15 seconds or so.