How It Works

PlayRecorder has a component (called RecordComponent) and data (called RecordFrame) layout, where individual components are attached to your objects and control their own data stores and logic. Components are designed to only ever record information when there is a change, or are explictly told to do so, reducing the overall recording size. No information about the scene itself is recorded, only the interactions and changes, this makes it quick and easy to add to your project.

All recordings are stored within a Data object.

The RecordingManager controls when components record their updates, and eventually collates all the data from the components and saves it into binary files.

• RecordComponents control a RecordItem (the raw data).
• RecordItems in turn can have as many RecordPart as they wish.
• RecordParts store the individual RecordFrames for the recording.

The PlaybackManager loads recorded files back into the scene, sends the respective data to components, and then ticks through all changes. Ideally recordings are meant to be loaded back into the scene that they were recorded from, and the system will automatically understand how to assign objects, however as long as the type of RecordComponent matches between the recording and the scene then it can be played back.

• RecordComponents also control their playback logic.
  • This logic can be customised freely to match requirements of the component.

Both the RecordingManager and PlaybackManager operate a large portion of their logic within custom threads. This means at times you will not be able to make use of certain Unity functions, thus needing to cache certain updates. Both the RecordingManager and PlaybackManager provide update functions that happen within the main Unity thread allowing you to achieve this. All functions that are labelled with Tick happen within the custom thread, while functions that are labelled with Update happen within Unity's main update thread.