ValueRecorder, for keeping track of values over time.

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 a AutoValueRecorder 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, and add_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.
- Potentially, if the method specified by add_source_method returns nil, we could avoid recording that source for that update (though all other sources would still record as normal).
- I don't know how we should handle the possibility of sources being inaccessible. In my own notes, I wrote down that it could stop recording values altogether -- but perhaps there's a better way of handling that?
- Also, we should definitely make sure that the values it records are copies of the data.
recorder_length -- how many of the last n records that will be kept... perhaps nil 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.

godot-extended-libraries / godot-next