ValueRecorder, for keeping track of values over time.

[LikeLakers2]

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.

[Xrayez]

For reference, this sounds similar to what I've presented in godotengine/godot#16793 (comment) (at least the recording part).

Some Godot fellows also work on networked sync (this definitely has some overlap): godotengine/godot#37200.